Re: Work-needing packages report for Jul 13, 2012
On 07/13/2012 02:25 AM, w...@debian.org wrote: The following packages have been orphaned: ginspector (#681284), orphaned today Installations reported by Popcon: 52 ... For the following packages help is requested: apt-xapian-index (#567955), requested 892 days ago Description: maintenance tools for a Xapian index of Debian packages Installations reported by Popcon: 55290 > ... These lists should be ordered by age... or rather by popcon instead of name... you know so the packages that need more help show up first... In case some just picked the mail and can read the important stuff first. Packages showing first are more likely to get love just because they have more exposition. I know, you can go to the web and order them yourself... but so can you regarding this remainder mail :) my 0.02 € Greets! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/439a.4040...@qindel.com
Re: Change default PATH for Jessie / wheezy+1
On 08/08/2012 09:43 AM, Bernd Zeimetz wrote: Experienced users should be able to do this easily. And those who don't knwo what to do with the tools in */sbin/* probably don't want/need them in $PATH. I think the topic in here is good defaults for debian/"more common case" no if debian/users are able to handle such changes. :) I also add sbin to path as one the first steps after installation and i think is a good thing. Not sure whats the best technical approach tho ( merge directories, add to path... link to bin only for those binaries that make sense there...) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50222327.9090...@qindel.com
Re: Change default PATH for Jessie / wheezy+1
On 08/08/2012 12:14 PM, Thomas Goirand wrote: On 08/08/2012 04:28 PM, Alberto Fuentes wrote: On 08/08/2012 09:43 AM, Bernd Zeimetz wrote: Experienced users should be able to do this easily. And those who don't knwo what to do with the tools in */sbin/* probably don't want/need them in $PATH. I think the topic in here is good defaults for debian/"more common case" no if debian/users are able to handle such changes. :) I also add sbin to path as one the first steps after installation and i think is a good thing. Not sure whats the best technical approach tho ( merge directories, add to path... link to bin only for those binaries that make sense there...) Exactly what do you need from sbin as a user? If you have some examples, then please file bugs... Thomas blkid, brctl, ifconfig, route, run-level are my main reasons. There might be more... Other distros looked for similar functionality using the easier way to do it, that is, adding path to $PATH but im not sure if thats the best technical solution (nor i know what that would be) Since we are not lazy and pursue technical excellence, we can think of what makes more sense. Maybe add a few links to bin for the binaries that make sense is more than enough. In any case we should unify criteria. Mount seems to rest in /bin instead of /sbin for example... Maybe merge directories is what makes more sense nowadays... I dont know :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50224611.6050...@qindel.com
Re: Change default PATH for Jessie / wheezy+1
On 08/08/2012 12:59 PM, Gergely Nagy wrote: But, you know what those commands do, and I think we can agree, that most - if not all - of them are quite close to being tools for the admin, even if they don't necessarily require root. A 'regular' user on a multi-user system will not likely need any of them. It *might* make sense to (optionally) add */sbin to the PATH of the first user installed. I wouldn't add it for everyone else too, however. Where do you put the line there? what does average non admin joe want/need? I dont think is up to us to decide what will the user want/need to use/know. We should allow to run any binary that makes sense to run by default without root permission and there is no need to be that condescending with the user [extra non usuful comments] Those commands without root permissions are not dangerous. ifconfig seems the most obvious that a non expert would want to run. ipconfig/ifconfig eth0 are easy to run/remember. ip addr show eth0 is not. ip has too many switches/options. Its nice and its my tool of choice as an admin, but i would not say is user friendly and i understand it will be hard to kill (if it is ever killed) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50224fbc.5000...@qindel.com
Re: Change default PATH for Jessie / wheezy+1
On 08/09/2012 11:43 PM, Carlos Alberto Lopez Perez wrote: """ As of DebianSqueeze, if you ask for the Desktop task during the installation, that pulls in sudo with a default configuration that automatically grants sudo-ing rights to any member of the sudo group. Depending on what user accounts you set up during the install, it's still possible that you may not have been added to that group - you can check by running groups. """http://wiki.debian.org/sudo So, how can be the we add the first user of the system to sudoers and we don't add sbin to his default paths? For the record and at least up to squeeze, you do have a sudo group but you are *not* added to that group. Second thing I do in a new installation after adding sbin to path is adding myself to sudo group... but that being a default is more debatable ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5024b020.6070...@qindel.com
Re: Debian XDG basedir compliance
On Sat, Oct 12, 2013 at 4:10 AM, Russ Allbery wrote: > To add on to what Lars said, users still often use the same home directory > on multiple systems (via NFS, AFS, etc.) and expect, when running the same > application on different systems, for programs to find their configuration > files in the same places. The FHS doesn't pose the same issue, since > those directories are generally (albeit not always) local to each system. Good point, although for me this is a good argument for the opposite of what you intend. I want to be able to share my homes, but i do not want to share configurations. Different versions of programs behave differently. With XDG I can separate my data from my configuration. Thats it, i can have my pdfs and photos and downloads separated from my configuration. You could argue that I could have a directory under my Desktop called stuff, to pour my personal data only there and treat that separately. I much rather go with the standard :) Greets -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calkubt6jjd_oza-qc4eentbr2bkf1wjw+fjq+hyy-gx8dso...@mail.gmail.com
Re: Introducing codesearch.debian.net, a regexp code search engine
2 words: Awe some roughly speaking, how does it work internally? On Tue, Nov 6, 2012 at 7:05 PM, Michael Stapelberg wrote: > Hi, > > I hereby announce a new Debian project: Debian Code Search. > > Debian Code Search is a search engine for program source code within > Debian. > > It allows you to search all ≈ 17000 source packages, > containing 130 GiB of FLOSS source code (including Debian > packaging) with regular expressions. > > You can use the search engine at http://codesearch.debian.net/ > Here are a few sample queries: > • http://codesearch.debian.net/search?q=workaround+package%3Alinux > • http://codesearch.debian.net/search?q=XCreateWindow > • http://codesearch.debian.net/search?q=AnyEvent%3A%3AI3+filetype%3Aperl > > The corresponding thesis (and source code, of course) will be released > soon (2013-01-15 being the deadline, but I hope I can do it > earlier). > > I hope you find it useful and would love to hear your feedback. > > -- > Best regards, > Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calkubt69c2xtzf9qvn2shkfrkor+d0tz8t-kjgjsdetjkob...@mail.gmail.com
Re: Introducing codesearch.debian.net, a regexp code search engine
On Tue, Nov 6, 2012 at 9:06 PM, Michael Stapelberg wrote: > Hi alberto, > > alberto fuentes writes: >> roughly speaking, how does it work internally? > It uses a trigram index and the RE2 regular expression engine. > > My work is based on Russ Cox’s ideas and code published at > http://swtch.com/~rsc/regexp/regexp4.html That read was enough to satiate my questions on how it works. :) Now some actual details would be appreciate. Like size of database, size on memory, engine running, kind of machine, number of nodes, etc... Have you run any benchmark? greets aL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calkubt7iuvm8r0jgkajfzl4d-nrxalpinurfpdr4-t8cysa...@mail.gmail.com
installation/live-cd
So I was wondering why this has not being done (or at least suggested, i could not find anything in the archive) since ubuntu has been doing it for so long I find the ubuntu live-cd + installation to be very handy and i always carry around an usb stick... I much rather be carrying around a debian stick ;) too late for wheezy cycle, but maybe its worth to take a look to make live-cd dissapear and merged as a release goal for jessie? greets! aL
Re: installation/live-cd
Yeah i definitely missed that :) Somehow related, the link is kinda hidden in the download page. The link is even under buy a computer with debian preinstalled... witch i think is silly. I guess its worth to have link to the image in the debian logo at debian.orgnext to the netboot install as well. At least for most popular arch? There is also 4/8 live-images, 3/6 of witch are the hybrid/iso/usb image. 4/8 means 2 architectures for each image. Kinda confusing if you are starting. Is it hard/worth to merge them? thanks On Sun, Dec 16, 2012 at 4:17 PM, David Prévot wrote: > Hi, > > Le 16/12/2012 11:03, alberto fuentes a écrit : > > So I was wondering why this has not being done > > Missed http://www.debian.org/CD/live/#live-install-stable maybe? > > Regards > > David > > >
Time to merge back ubuntu improvements!
Ubuntu has done some poor decisions but it has done some other that are
okay. We should consider merging some of them back.
Im thinking about the 6 months release thing. Without further ado, here's
the proposal pre-draft:
_Proposal_:
Add a new release stage between stable and testing. Called usable or
whatever name we find fit for it
stable <- <- testing <- sid
Migrate packages after a period* in testing without RC bugs.
*a 2-4 weeks seems reasonable to me
_Motivation_:
I cant recommend anybody that wants a reasonable up-to-date desktop and is
technically-impaired to use debian because occasionally, it breaks badly. I
can not but to redirect them to ubuntu. This has to change
_Rationale_:
In current state, stable has packages that are too old.
Testing, as usable as usually is, occasionally breaks. It broke 3 times
more or less this year to me. These breakages render a poor desktop user
experience.
Usable would be more "stable" than testing ("stable" meaning less bugs)
Usable would be less "stable" than stable ("stable" meaning it changes)
_Current half-backed solutions to this problem_:
The only ways to prevent this if you are running the more or less
up-to-date testing are:
* Pin packages with RC bugs on upgrade. This is:
- Non trivial: it makes you understand how bad the bug is and know how
the pinning system works
- Ineffective: its a matter of luck that the bug is found before you
upgrade the package. In the worst case scenario, the package entered
testing one second before you tried to upgrade and has not being broadly
tested yet to find those pesky RC bugs.
- Useless if you are trying to install a new package and the bug
already hit testing
* Stable backports: This is okay, but its manually done. Somebody has to
be interested in the particular package and do it. One of the benefits of
usable is that is automatically generated. Requiring less hand-made man
labour in general. I guess It adds a little overhead for FTP masters.
Request for comments!
Re: Time to merge back ubuntu improvements!
Im adding the cut-team to the loop. Original message: http://lists.debian.org/debian-devel/2013/01/msg00082.html On Thu, Jan 3, 2013 at 8:15 PM, Carlos Alberto Lopez Perez wrote: > AFAIK there is already an ongoing effort to provide an usable updated > rolling release of Debian. > > http://joeyh.name/code/debian/cut/ > > http://cut.debian.net/ > > > Isn't this (more or less) what you are asking for? I watched the bof 2 years ago, and had it on my initial pre-draft, but since i didnt heard much about it and looking at the page/mailing list it looked dead so i removed it. Even the repository links [0] gave 404 [1]. After closer looking, there must have been some change in s.d.o that needs the url ended in / for the link to work [2]. So I guess is not that dead afterall, it has just not having enough attention after the freeze for obvious reasons. I have not tried myself, so i cant really talk. CUT is kind of more ambitious than what i was asking for, since it tries to provide a working installer as well as working snapshot of debian. Not sure of the criteria for the snapshot tho. Does it just look for a complete working dependence graph or does it look for RC bugs as well? The few people on the list seems happy with it. If this is working well, it needs a little more love on debian.org and a 'testing-cut' link in the repos pointing to latest cut, so it can be set on sources.list and forgotten. On Thu, Jan 3, 2013 at 11:45 PM, gregor herrmann wrote: > On Thu, 03 Jan 2013 19:18:27 +0100, alberto fuentes wrote: > >> The only ways to prevent this if you are running the more or less >> up-to-date testing are: >> * Pin packages with RC bugs on upgrade. This is: >> - Non trivial: it makes you understand how bad the bug is and know how >> the pinning system works > > No and yes. > > No, because apt-listbugs exists and provides a nice interface so users > don't have to care about pinning details for themselves. > > Yes, because from my very practical experience users are often > confused when apt-listbugs presents them a bug subject. > My point with this proposal is to make testing 'usable' for a larger audience. So yes, you agree with me, its non trivial to use. >> - Ineffective: its a matter of luck that the bug is found before you >> upgrade the package. In the worst case scenario, the package entered >> testing one second before you tried to upgrade and has not being broadly >> tested yet to find those pesky RC bugs. > > Pesky RC bugs are usually reported within few hours after they enter > unstable, no danger for testing here. I usually put off the whole upgrade when apt-listbugs reports some RC that I think it can hit me instead of pinning. I did not know the pinning was automatically removed when fixed, but I didnt want the latest of the latest that bad, so putting off the whole thing was okay for me... Even doing this I was hitted with about 3 bugs this year that affected my desktop experience badly. I would dig my own examples, but i think we can agree that testing is usable most of the time. Cases are rare, but it does happen from time to time. 'usable' intends to remove those rare cases. >> - Useless if you are trying to install a new package and the bug >> already hit testing > > Use apt-listbugs. apt-listbugs just will prevent me to install the software. Witch is so so. With 'usable' you still will be able to install a previous version of the software. So what i meant is, it's useless if you really want to install the software. On Fri, Jan 4, 2013 at 7:30 AM, Reinhard Tartler wrote: > On Thu, Jan 3, 2013 at 7:18 PM, alberto fuentes wrote: >> _Rationale_: >> In current state, stable has packages that are too old. >> Testing, as usable as usually is, occasionally breaks. It broke 3 times more >> or less this year to me. These breakages render a poor desktop user >> experience. > > Why did testing break for you? Why do you think that adding another > stage, in which packages migrate automatically after some time period, > will magically prevent that? > > I'm convinced it will not. You can help here much more by improving > testing instead of making our release process much more complicated > than needed. I think that these bugs will be caught up before it hits 'usable'. It will try to do so by being 2-4 weeks behind testing. Adding it between stable and testing will make it more complicated, i guess... but if this seems like nightmare for the release process, it could be added as a branch hanging from testing without anything else added. Thats it, just leaving it out of the chain stable <- testing <-sid I think it overall involves less work than other solutions and I fail to see how me helping in test
Re: Crypto export
On 04/11/2013 08:27 AM, Joerg Jaspert wrote: > > https://ftp-master.debian.org/crypto-in-main/ > > Plus one mail for *every* NEW accepted package. Each and every time. > Send to them.[1] See the dak git repo for the bxa stuff. > > > [1] Nowadays only stored in a mailbox from us, at request from them, but > available if requested. Okay. *that* is crazy. Crazy as in insane. Crazy as in coocoo For so many reasons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51668c1c.3070...@qindel.com
Bug#737072: ITP: KeySigningPartyTools -- create a better formatted list in PDF format by reading a FOSDEM key list
Package: wnpp Severity: wishlist Owner: Alberto Fuentes * Package name: KeySigningPartyTools Version : n/a Upstream Author : Vadim Trochinsky * URL : https://github.com/vatral/KeySigningPartyTools * License : AGPL v3 Programming Lang: Perl Description : create a better formatted list in PDF format by reading a FOSDEM key list Key signing is really in need of a program that eases interchange of keys. KeySigningPartyTools generates a pdf with qr codes and visual hints for the fingerprints that allows faster processing and avoid manual errors. It process the qr codes afterwards with the help of a webcam as well. It also automatically checks that the keys scanned match the keys downloaded before you sign them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140129213915.19184.71942.reportbug@tachikoma
the importance of defaults (was: Debian default desktop environment)
tl;dr go to [0] On Thu, Apr 10, 2014 at 1:06 PM, Ghislain Vaillant wrote: > My vote would be on GNOME 3 classic for now, but XFCE with sensible and > visually appealing defaults would do it for me too. You are all facing different experiences with end-users because end-users are probably different. Some likes shiny, others like useful, some are computer illiterate, others are experts, most are in between I had to leave gnome with gnome3 because it disrupted my workflow so much i couldn't cope In my case I like shiny but not at the cost of useful. xfce4 felt like a less polished gnome2 but at least it didn't disrupt my workflow. Some numbers with my free interpretation from ubuntu popcon: unity is installed in 605_209 machines, but its used regularly only by 46_210 Thats a very low number by all metrics for a default desktop [0]. People dislike it. People dislike disruptive My point is that gnome3 is even more disruptive than unity. Do we want to attract users or scare them away? Those who like disruptive desktops will still be able to do it by install it them. The next less disruptive thing after gnome2 is xfce. I used ubuntu instead of debian to make my point because i think is more representative for several reasons: - their numbers are one order of magnitude bigger than debian's - the user base is more average than debian's (its debatable what average even means) [0] Please watch this ted talk about the importance of defaults http://www.ted.com/talks/dan_ariely_asks_are_we_in_control_of_our_own_decisions -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calkubt7s+qtkij-lk3s-p3xbqodmo6vajlkytglb3puzrt8...@mail.gmail.com
Re: the importance of defaults (was: Debian default desktop environment)
On Sat, Apr 12, 2014 at 1:15 PM, Jonas Smedegaard wrote: >> Some numbers with my free interpretation from ubuntu popcon: >> unity is installed in 605_209 machines, but its used regularly only by >> 46_210 >> >> Thats a very low number by all metrics for a default desktop [0]. >> People dislike it. People dislike disruptive > > ...or those people simply do not use a desktop on those installations? > > Only if popcon numbers for xfce/kde/whatever add up to somewhere near > the missing amount can you reasonably conclude distaste for a particular > desktop as reason, I believe. The number of the rest of the desktops are severely skewed towards defaults. Thus, is very hard to add up the rest of the desktops vs the default. The point was very well illustrated with Ariely ted talk if you know or have watched the talk I think that the number being low says something already. if people is not going to run a desktop at all, they would install ubuntu server. if you know enough not to run desktop you know enough not to install desktop at all People installing regular ubuntu desktop and those very low numbers, even if that means no desktop at all, says something about the default. It also match my experience that people dont like disruptive and dont being disruptive would be a good default confirmation bias? it very well might be. These are all free interpretation of the already skewed popcon data anyway Can you pull data from popcon in the past to add some more numbers and graphs to my free interpretation? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calkubt7uqdznyya04yvkd9+ttwds3t7s97xv9mwnxlnsb1a...@mail.gmail.com
Re: DebConf22 registration and call for proposals are open!
Literally search on your favourite search engine: how to unsubscribe from In this case, debconf-announce, and click on the first link If you have any other questions in life such as how to walk or how to boild an egg, dont hesitate to use search engines They are great! On Fri, 25 Mar 2022 at 16:54, YS wrote: > Sorry. How to unsubscribe this thread? > > Paulo Henrique de Lima Santana 於 2022年3月25日 週五 23:33 寫道： > >> Hi, >> >> Registration for DebConf22 [1] is now open. >> The the 23rd edition of DebConf [2] will take place from July 17th to >> 24th, >> 2022 at the Innovation and Training Park (ITP) [3] in Prizren, Kosovo, >> and will >> be preceded by DebCamp, from July 10th to 16th. >> >> [1] https://debconf22.debconf.org >> [2] https://www.debconf.org >> [3] https://itp-prizren.com >> >> Along with the registration, the DebConf content team announced the call >> for >> proposals [4]. Deadline to submit a proposal to be considered in the main >> schedule is April 15th, 2022 23:59:59 UTC (Friday). >> >> [4] https://debconf22.debconf.org/cfp >> >> DebConf is an event open to everyone, no matter how you identify yourself >> or >> how others perceive you. We want to increase visibility of our diversity >> and >> work towards inclusion at Debian Project, drawing our attendees from >> people >> just starting their Debian journey, to seasoned Debian Developers or >> active >> contributors in different areas like packaging, translation, >> documentation, >> artwork, testing, specialized derivatives, user support and many other. In >> other words, all are welcome. >> >> To register for the event, log into the registration system [5] and fill >> out >> the form. You will be able to edit and update your registration at any >> point. >> However, in order to help the organizers have a better estimate of how >> many >> people will attend the event, we would appreciate if you could access the >> system and confirm (or cancel) your participation in the conference as >> soon as >> you know if you will be able to come. The last day to confirm or cancel >> is July >> 1st, 2022 23:59:59 UTC. If you don't confirm or you register after this >> date, >> you can come to the DebConf22 but we cannot guarantee availability of >> accommodation, food and swag (t-shirt, bag, and so on). >> >> [5] https://debconf22.debconf.org/register >> >> For more information about registration, please visit registration >> information >> [6]. >> >> [6] https://debconf22.debconf.org/about/registration >> >> ## Submitting an event >> >> You can now submit an event proposal [7]. Events are not limited to >> traditional >> presentations or informal sessions (BoFs): we welcome submissions of >> tutorials, >> performances, art installations, debates, or any other format of event >> that you >> think would be of interest to the Debian community. >> >> [7] https://debconf22.debconf.org/talks/new >> >> Regular sessions may either be 20 or 45 minutes long (including time for >> questions), other kinds of sessions (workshops, demos, lightning talks, >> and so >> on) could have different durations. Please choose the most suitable >> duration >> for your event and explain any special requests. >> >> In order to submit a talk, you will need to create an account on the >> website. >> We suggest that Debian Salsa account holders (including DDs and DMs) use >> their >> Salsa [8] login when creating an account. However, this isn't required, >> as you >> can sign up with an e-mail address and password. >> >> [8] https://salsa.debian.org >> >> ## Bursary for travel, accommodation and meals >> >> In an effort to widen the diversity of DebConf attendees, the Debian >> Project >> allocates a part of the financial resources obtained through sponsorships >> to >> pay for bursaries (travel, accommodation, and/or meals) for participants >> who >> request this support when they register. >> >> As resources are limited, we will examine the requests and decide who will >> receive the bursaries. They will be destined: >> >> * To active Debian contributors. >> * To promote diversity: newcomers to Debian and/or DebConf, especially >> from >>under-represented communities. >> >> Giving a talk, organizing an event or helping during DebConf22 is taken >> into >> account when deciding upon your bursary, so please mention them in your >> bursary >> application. >> >> For more information about bursaries, please visit applying for a bursary >> to >> DebConf [9]. >> >> [9] https://debconf22.debconf.org/about/bursaries >> >> Attention: the registration for DebConf22 will be open until the >> conference >> starts, but the deadline to apply for bursaries using the registration >> form >> before May 1st, 2022 23:59:59 UTC. This deadline is necessary in order to >> the >> organizers use time to analyze the requests, and for successful >> applicants to >> prepare for the conference. >> >> DebConf would not be possible without the generous support of all our >> sponsors, >> especia
