Release Team will meet this weekend
Hello, this is just a quick mail to let you know that the Release Team will be holding a meeting in Cambridge, UK, this coming weekend. The meeting will be attended by Luk Claes, Pierre Habouzit, Philipp Kern, Neil McGovern and myself. As mentioned in d-d-a, this meeting was originally planned for April, but it was impossible to find a date and it has had to be postponed until now. We have all the mails that were sent to feedb...@release.debian.org back then, and we hope to be able to come with some sensible proposals and intentions that we'll present to the Project for discussion, regarding our development cycles and the Squeeze cycle in particular. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Who uses @packages.d.o mail?
I haven't done an exhaustive survey, but it seems pretty clear so far that the domain does not get any significant amount of legitimate mail from machines other than the debian.org hosts. As I understand it, pkg@packages.d.o is the standard way of contacting the maintainers of a package in an easy and efficient way. I use it all the time when eg. reassigning a bug (reassign mails are supposed to be CC'ed to the destination maintainers), rather than go up and look who's listed as maintainer and uploader and CC them all. Plus, fortunately, packages.d.o has been sending a copy to the PTS for some time now, so even interested people who are not listed as maintainer/uploader will be able to read them. Personally, I think we should keep it open. If it becomes unsustainable, we could require a whitelist header for mail sent from non debian.org machines, like the PTS does. But if we do that, we could ditch it altogether and just use the PTS (for me, one of the main advantages of packages.d.o is not having to include the whitelist header). Does somebody know if the PTS is mailing the maintainers already? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Missing package on a debian mirror
Hello, Shams, thanks for your report. It seems that the ftp.is.debian.org mirror is very out of date: it was last updated on April 3rd, it seems! I’m CC'ing our mirror people so that they can decide what the next action is in this case, since something is obviously wrong with it. In the meantime, I suggest you use some other mirror. Again, thanks for your report. + Shams Fantar (Mon, 13 Apr 2009 21:18:45 +0200): Hi, There is a missing package on a debian mirror, http://ftp.is.debian.org/, the package in question is rhythmbox. The problem is only on that mirror, apparently. Maybe, that mirror is not synced on a primary mirror... The address : http://ftp.is.debian.org/debian/pool/main/r/rhythmbox/rhythmbox_0.12.0-2_i386.deb from http://packages.debian.org/sid/i386/rhythmbox/download I hope this mail is sent at the good address. Regards, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Genericly-named debian.net domains for private use
+ Peter Palfrader (Thu, 09 Apr 2009 00:39:01 +0200):
On Wed, 08 Apr 2009, Felipe Augusto van de Wiel (faw) wrote:
I'm just wondering if we should discuss more about the rules or
if DSA will propose rules for adoption with some migration
period.
While I personally thing many of the debian.net entries are
questionable, I certainly don't want to be the person that will have to
run after people if they violate some rules. I have better things to do
with my time.
Okay. Well, I’ve just put Daniel (owner of {git,backports}.debian.net)
on CC, so that he can take a look at this thread and see what their
peers think of this, and he can proceed as he considers appropriate.
After that, I don’t think I have much more to contribute to this thread.
Daniel, I’m not sure if you’re subscribed; the thread starts at:
http://lists.debian.org/debian-project/2009/03/msg00097.html
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Genericly-named debian.net domains for private use (was Re: Point to semi-official backported packages?)
+ Bernd Zeimetz (Wed, 01 Apr 2009 03:18:33 +0200): Stefano Zacchiroli wrote: On Sat, Mar 28, 2009 at 10:00:46AM +0100, Adeodato Simó wrote: Wouldn’t it be just better to point those domains to the respective project-wide efforts? I’d appreciate opinions on the matter. AOL. Looks like the rule is quite simple too: for any $X.debian.org, $X.debian.net should point to $X.debian.org. (A reasonable exception could be www.debian.net containing a list of .debian.net names.) Implementing this rule would be very appreciated. Adding DSA to the loop to see if this is something they want to standardize or regulate. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New contact address for the wanna-build team, and other bits
* Goswin von Brederlow [Mon, 30 Mar 2009 14:38:38 +0200]: Please create a new entry on http://www.debian.org/intro/organization for the debian-wb-team listing at least the major players. People looking for the email address will not find it here. Good suggestion, thanks. This should be visible in the next webwml run: http://cvs.debian.org/webwml/english/intro/organization.data?root=webwmlr1=1.326r2=1.327 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Genericly-named debian.net domains for private use (was Re: Point to semi-official backported packages?)
* Paul Wise [Sat, 28 Mar 2009 12:35:44 +0900]: On Fri, Mar 27, 2009 at 8:28 PM, Peter Pentchev r...@ringlet.net wrote: (And yes, I know about backports.d.n; maybe I'll get 'round to submitting or maintaining stuff there at some point, but for the present it is a bit easier for me to keep it all in a single repo :) I think you mean backports.org, backports.debian.net is not what you think it is. Despite its name, backports.d.n is a personal backports archive for Daniel Bauman. I really don’t get why it’s appropriate for a developer to use such generic names for their personal stuff. git.debian.net seems to be Daniel’s too. Wouldn’t it be just better to point those domains to the respective project-wide efforts? I’d appreciate opinions on the matter. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
New contact address for the wanna-build team, and other bits
Hello, As previously mentioned, the wanna-build team has been looking into moving to a public role address instead of a private alias. We now have a list on lists.debian.org for this purpose: debian-wb-t...@lists.debian.org This address should be used in preference over the old alias for any communication with us that doesn’t require privacy (you can still use wb-t...@buildd.debian.org in that case). This list is a role address, but will also host discussions related to the buildd infrastructure. For example, the discussions about the future “wannab” PostgreSQL database will move from debian-dak to here, and also any other discussions about future improvements to the software. Regarding requests for give-backs, etc., this is the new state of things: * Packages-arch-specific: still bug against ‘buildd.debian.org’ * Bin-NMUs: still debian-rele...@lists.debian.org * Chroot problems, package priority issues: still arch@buildd.debian.org * Give-backs and dep-waits: debian-wb-t...@lists.debian.org (including requests for experimental, but please mark them as such) The last point should be an improvement over the previous state where mailing arch@buildd.d.o, waiting, and then mailing debian-release was the preferred approach. Since now we have a public list, interested buildd admins will be able to follow it and act upon requests, but people with global access will be able to do the same simultaneously. Because of this, please always mention the architecture in the subject of your mail. Speaking of people with global access, we’re happy to announce that we’ve recently added Kurt Roeckx to the “wb-all” Unix group, which gives access to modifying the wanna-build database for all architectures. Kurt has been an amd64 buildd admin since the port entered in Debian, and he’ll be now proactively helping with general maintenance of the package status databases, as well as with maintainer requests sent to the list. Also, there have been a couple changes in the list of buildd maintainers that have not been announced yet. Peter De Schrijver is taking care of mips now, Martin Zobel-Helas of mipsel (as well as sparc, which he was already doing), and Philipp Kern and Luk Claes are doing alpha whilst the machines are prepared with new buildd and sbuild versions, at which point will be hopefully handed to somebody else. And that is all for now. P.S.: A short pointer to this mail will be added to the DeveloperNews wiki page for inclusion in the next issue. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009 at Debian needs you
* Obey Arthur Liu [Tue, 03 Mar 2009 00:56:58 +0100]: Hi, Hello, Obey, thanks for pushing this forward. I have a couple questions, not having ever been involved with this. The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page[2]. Is a list of ideas needed for the application, and/or something that gets evaluated and hence something we need to worry about with some urgency? (There's exactly one week until the organization application period closes AFAICS.) I don't think it'll be the case, but if Debian could potentially be left out for lack of a good list of ideas, maybe a call to d-d-a would be in order? (Just tryin to be cautious here.) Further in the spring: - Mentors, people to review proposals, do interviews - Ideas, Ideas, Ideas for Summer of Code projects I'd like to hear a bit about this process, and I'd appreciate if you or somebody else familiar with the process could answer my questions about it. In particular, as a potential mentor, I'm very interested in hearing how a student gets assigned to a project (do they just express interest on it? what do those interviews entail and who does them?), and if the mentors get any say/opportunity to review/ack the student chosen for their projects. Thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Why are you whispering? - Because I just think that no matter where she is, my mom can hear this conversation. -- Rory and Lane -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Google Summer of Code 2009 at Debian needs you
* Obey Arthur Liu [Fri, 06 Mar 2009 19:18:57 +0100]: Hello, Obey, thanks for your answers. Hello, Obey, thanks for pushing this forward. I have a couple questions, not having ever been involved with this. The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page[2]. Is a list of ideas needed for the application, and/or something that gets evaluated and hence something we need to worry about with some urgency? (There's exactly one week until the organization application period closes AFAICS.) The organization is supposed to have a list of ideas, but not necessarily exhaustive. Of course, because of the size and importance of Debian, we may get away with only a few ideas, but it makes us look bad. Okay. We (the wanna-build maintainers) will be adding to the wiki at least one item soon. More importantly, there's going to be a big rush of students looking at all the ideas list of all the organizations (they will be listed on the Google Summer of Code main page). If we have a limited ideas list, we may lose the interest of a lot of students, so it is important that we have a diversified list of ideas. d-d-a should be in order, soon, I think. Right, good point. Not sure if there're other DDs working closely with you on this. If you need sponsorship for your eventual post to d-d-a, feel free to mail me a draft. Students send a proposal for each particular project they would want to do with their interpretation of the work needed, how they plan to do it, their experience, etc. Which student gets assigned to each project is a collective decision between prospective mentors, admins and interested parties on the Debian side. The final student/project pairs are then ranked and the list submitted to Google. Google then says: We're going to fund the first X ones in your list. About the interviews, they should be done by mentors and admins again but the operational process hasn't been laid out yet. We'll figure that out when we start getting proposals from students. This clears up things, thanks. I'm pleased to hear mentors have an active role in the student assignation process. I think it's only understandable one would want to take precautions the time spent mentoring will be time well spent, and the result will be of satisfactory quality! Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Ana Belén - Puerto viejo -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Creating a public list for wanna-build team? Input needed.
* Raphael Hertzog [Wed, 18 Feb 2009 14:19:39 +0100]: I agree it would be useful, debian-rele...@l.d.o already started to collect binnmus request in the past and it would seem natural to me that such request (now properly directed at the wbadm team) get archived/discussed in the same spirit on a dedicated list hosted at lists.debian.org. (JFTR, and as hinted in [1], binNMUs are to still be handled by the release team, at least for now. If there's any change in this, we'll notify the appropriate lists.) [1]: http://lists.debian.org/debian-devel-announce/2008/11/msg6.html Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Creating a public list for wanna-build team? Input needed.
Hello, I'm sorry to use this list for this purpose, but I'm not sure where else I could go for interested parties to comment, since the set of people potentially interested in this is not concentrated in some other, less generic list. In #512780 (http://bugs.debian.org/512780), we've requested the creation of a debian-wbadm list to serve as a role address and discussion umbrella for the wanna-build team. The full rationale is in the bug report, but the bottom line is that we've realized a public role address is better from our past experiences with debian-release. Listmaster has asked us that we follow the standard procedure of getting people to express their interest on the requested list in the bug report. So, if you'd welcome the wanna-build maintenance team move to a public list as their role address, we would appreciate if you could send a quick mail to the bug report. Additionally, listmaster has also suggested that we use a teams.debian.net list for this purpose. I don't agree with this for the reasons stated in the bug report. Feel free to comment on this issue as well. Many thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Love in your heart wasn't put there to stay. Love isn't love 'til you give it away. -- Oscar Hammerstein II -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about the amount of security updates available
Hello, Thomas. We released a new version of Debian stable yesterday, which means that the stable name in our repositories (including security repositories) now point to this new version (which is named Lenny). You probably have references to stable in your /etc/apt/sources.list file. It is highly recommended that that file contains release code names, instead of symbolic names: that way, new releases don't affect your machines, and you just use the new name when *you* are ready to upgrade. In your case, since you're using the previous stable version, you should substitute occurrences of stable with etch in that file. The warning about the public key is a small hiccup in our release process that we're in the process of fixing. Thanks for your interest, and hope this mail clears up your doubts. --- Thomas Nguyen Van [Mon, 16 Feb 2009 12:02:17 +]: Morning, In our company, we hourly check security updates via the command apt-get update for several months. This morning, this command gave me the following result that I've never had until now: W: There is no public key available for the following key IDs: 4D270D06F42584E6 W: You may want to run apt-get update to correct these problems In addition, since this week end, I have almost 100 new debian packages available per server. I checked on the Debian's web site (http://www.debian.org/security/2009/) but only few security updates are available in comparison with the amount of security updates I have now whereas last week it was ok. My questions are: 1. Do you confirm the amount of new security updates? If yes, what is the link? 2. Did you change the public key available for security updates? Many thanks for your help. Regards, Thomas Nguyen-Van Senior IT Security Consultant - CEH Jumper Consulting Investment Ltd St. Doolaghs Park House Malahide Road Balgriffin Dublin 17 Tel. +353 1 847 7756 Fax. +353 1 847 7785 Mob. +353 87 905 5041 -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lenny release at epoche 1234567890 ?
* Don Armstrong [Sat, 14 Feb 2009 16:48:16 -0800]: / i~49862854.1070...@googlemail.com (~i, not i~, as can be seen in the manual URL that was included.) See http://www.mutt.org/doc/manual/manual-4.html#ss4.2 for details. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Ana Belén y Víctor Manuel - Isla de Palma -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft for lenny release announcement
Hey, Alexander, thanks for your work here! Some minor comments follow: supports a total of eleven processor architectures As per Riku's comment about armel being missing, this should be 12. A total of eleven architectures are supported including: Same here. Support for Macromedias Flash format is available via the swfdec plugin. Should Gnash be mentioned here? Is it ready for such a high profile mention? (Maintainers Bcc'ed.) pThe integration of OpenJDK, a free version of Sun's Java technology, into Debian GNU/Linux 5.0 made it possible to ship Java based applications in Debians main repository./p ^^^ Debian's 2.4.7, Iceweasel (an unbranded version of Mozilla Firefox 3.0.5), Icedove ^ 3.0.6 (will migrate soon) Iceape (an unbranded version of Mozilla Seamonkey 1.1.14), Iceape has been dropped (we only keep the -dev packages for Build-Dependencies), so please drop that bit from the announcement. PostgreSQL 8.3.5, This may be 8.3.6 in the end, I'll let you know if that's the case. MySQL 5.1.30 and 5.0.51a, GNU Compiler Collection 4.3.2, Linux kernel version 2.6.26, Apache 2.2.9, Samba 3.2.5, Python 2.5.2 and 2.4.6, Perl 5.10.0, PHP 5.2.6, Asterisk 1.4.21.2, Emacs 22, Inkscapoe 0.46, Nagios 3.06, Xen ^ Inkscape (typo) Hypervisor 3.2.1, OpenJDK 6b11 and more than 23,000 other ready to use software packages./p I don't know about the 23,000 figure. It is binary package based, and I'm not sure if that's really fair, because splitting an upstream into different .debs is after all an artifact of the distribution. (FWIW there are around 12,500 source packages in Lenny.) In any case, I'm happy to leave this issue to your discretion. pUpgrades to Debian GNU/Linux 5.0 from the previous release, Debian GNU/Linux 4.0 codenamed qetch/q, are automatically handled by the aptitude package management tool for most configurations, and to a certain degree also by the apt-get package management tool. This should be consistent with the Release Notes. I haven't been tracking the relevant section there very closely, but I thought apt-get was preferred now over aptitude. Could you investigate, and swap the order if that's the case? h2About Debian/h2 Was there going to be a brief mention of the dedication to Thiemo in the announcement? (I think I saw the idea thrown somewhere, I'm just not sure if something came out of it.) Thanks! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: new RT addresses
* Peter Palfrader [Thu, 05 Feb 2009 02:31:29 +0100]: Hi, FYI, Luca patched our exim and rt setup in such a way that you can now send email to existing tickets more easily. Great. The short version is that rt+...@rt.d.o and rt-comment+...@rt.d.o accept mail. Is there a difference between the two? Which one should be used, and when? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Contact address for wanna-build issues in experimental
Hello, it was noticed on #debian-devel request that we don't have an address to request dep-waits, give-backs, etc. on the experimental wanna-build (the arch@buildd.d.o addresses are not appropriate, since the buildd admins are different). Please use: experimen...@buildd.debian.org for such requests. (It is our intention to mention all the contact addresses in http://buildd.debian.org when we get to work on those pages. For now, we'll have to do with scattered mails.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
* MJ Ray [Fri, 16 Jan 2009 12:40:24 +]: What's a rant about zionism got to do with this? Is it spam? If so, why didn't the list admin block it? It took me a bit to figure out that you meant [1]. [1]: http://lists.alioth.debian.org/pipermail/mailvoting-devel/2009-January/00.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «Ara que ets la meva dona, te la fotré fins a la melsa, bacona!» -- Terenci Moix, “Chulas y famosas” -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the DPL
* Steve McIntyre [Tue, 13 Jan 2009 23:08:39 +]: Declassification of debian-private archives --- Back in December 2005, we agreed in a GR [16] that we should start declassifying (at least some of) the contents of the debian-private mailing list once three years had passed. Well, that's now... If we're going to follow through on that resolution, we will need volunteers to start working on this. If you're interested in joining a team to do that, please let me know. There's probably a lot of boring work to be done here, but I'm hoping we can find some way to automate much of it. :-) Since [1] got no negative feedback, I opened RT#993 to ask for the creation of declassify-t...@debian.org. (Unfortunately before I knew a call for a team would be made in the Bits mail, otherwise I would've waited.) But this was acked by leader@, and the alias is operative now. (It just goes to an mbox in master, nobody is behind the forward yet.) [1]: http://lists.debian.org/debian-project/2008/12/msg00149.html Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Oh my God, you're pimping me out for a new roof? - And windows! -- Andrew and Bree Van De Kamp -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Scheduling project-wide post-lenny discussions?
Hm. It seems we have a number of projet-wide discussions that we've more or less agreed to postpone until lenny is out. I have a moderate fear that once that happens, they are going to explode (the discussions) all over the lists. I suggested the creation of the DiscussionsAfterLenny wiki page a while ago, but that page is at the moment a bit of a mess. In particular, it's a dump of items without mentioning who's interested in having the discussion, and volunteering to starting and driving it. So, I'm interested in knowing if people would be fine with making a list of these big issues we have to discuss, and trying to give them slots, as in putting them in some order that makes sense. Also, IMHO, having one or two (per-topic) people responsible for starting them, and trying to/ensuring they get somewhere, by appropriately fostering and summarizing the progress of the discussion, would be very good too. Off the top of my head, these are some candidates for scheduling: * membership in Debian (see below about this one). * changes to the Constitution (I've read at least Steve Langasek and Matthew Johnson express interest in this). * changes to the Social Contract (I'm not sure if this one is going to happen?). * code of conduct (Miriam Ruiz and Ben Armstrong would know about this). * release management, freezes, RC bugs and the whole lot (I'd appreciate if nobody beats the release team to this one). * more...? (if this scheduling goes forward, now would be a good time to speak). Thoughts? --- Regarding the Membership in Debian discussion, this has always been my idea of what could work well: * designing a person or very small group of people as the drivers of the discussion; these people would have their opinion, of course, but not an agenda, and should be trusted by the project, and particularly by the people who feel vocal about this discussion. .oO(good luck...) * these drivers receive, in private, well-written platforms of solutions that (many) interested people would give to the problem; they read and dissect them, and work with the senders to present to -project a fair summary of them, highlighting the points where there's consensus, and the points where there is not. * discussion happens in -project, and the drivers regularly distil it into summaries, trying to come up with the axis of a small and coherent handful of options in a possible future vote, and receiving feedback on these. * once the axis of each option are set, the main proponents of that option work out a text. (I realize this is not very polished, but I thought I'd try, because I'm tired of inefficient and endless discussions. I also have a couple names in mind of possible good drivers for this matter, but I haven't talked to them, and anyway it's leader@ who should, I believe. Bcc'ed.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Will you just stand still? -- Luke Danes -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
* Robert Millan [Sun, 11 Jan 2009 08:22:58 +0100]: Currently, the only solution I see is that we ask the developers what they think, and hold another vote. Yes, I'm realizing myself there is not going to be another way. :-( Proposal: hand Robert Millan a nice cup of STFU. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org — Oh, George, you didn't jump into the river. How sensible of you! -- Mrs Banks in “Mary Poppins” -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
* Stephen Gran [Sun, 11 Jan 2009 17:17:33 +]: This one time, at band camp, Steve McIntyre said: If things go much further we'll end up with enough seconds to force a vote to hand Robert Millan a nice cup of STFU. I'm hoping that's not what anybody actually wants, but I can also understand why some people might be feeling that way. Dato didn't sign his proposal mail, so this can't be a valid GR proposal, AIUI. All I meant was that I second the feeling, rather than a formal proposal. ACK, I wasn't formally proposing a vote. I could've been more clear about that, but I tend to forget things may not always be as obvious on the other side of the screen. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: David Bowie - John, I'm only dancing -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* MJ Ray [Wed, 07 Jan 2009 10:04:50 +]: It's hard to prove that a group is ignoring something, but disproof is simple: please could all DDs reading this email mjr-possiblegr at debian.org. I'll count with from -f possiblegr.mbox | wc -l in a week. o/` I am speechless, speechless That's how you make me feel When I'm with you I am lost for words, I don't know what to say Helpless and hopeless, that's how I feel inside o/` -- Another MJ (In other words, I don't understand what possible correlation there could be between people following or not an experiment by you *deep buried in a thread pattern*, and people seconding an amendment they agree with, knowing it still needs, say, 12 seconds.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Justin Nozuka - After Tonight -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Ben Finney [Tue, 30 Dec 2008 11:43:44 +1100]: Don Armstrong d...@debian.org writes: You should not be proposing or seconding an option that you don't plan on ranking first. This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? I can't believe I'm reading this. You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. (On the other hand, I think seconding is different, and that it should be okay to second stuff even just because I think it's good for it to be on the ballot.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Ben Finney [Fri, 02 Jan 2009 09:17:28 +1100]: You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. The people who do care about such an option winning have at least as much freedom to decide as they did before the option was proposed. They can decide whether they want to propose their own wording, or to second the wording as already proposed, or anything else. No. In my opinion, an option in the ballot is (should be) a very scarce resource. Like you would in a situation of limited water supply in a boat shared with friends, you should act responsibly and not consume one unit unless painstakingly necessary. This is, of course, my opinion, and you're welcome to disagree. Also, I'll probably won't be interested in discussing this any further, so please don't take my lack of answer to your next message as lack of disagreement. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Vanessa-Mae - Doun -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Wouter Verhelst [Tue, 30 Dec 2008 18:21:58 +0100]: I'm still undecided whether I'm for Q, 2Q, or what. But: Well, I disagree on that point. I just had a look at the vote.debian.org pages, checking those votes where the number of seconds exceeded 10, and found only the following ones: I don't think that's a fair consideration. We all know a proposal needs 5 seconds, so if we see one we'd second has the 5 already, I think it's natural to pass. The popular proposal notwithstanding. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A hacker does for love what other would not do for money. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Email alias for the debian-private declassification team?
Hi, can we have an e-mail alias for the debian-private declassification team figure created by GR 2005/002? IMHO it's enough if it just points to a mbox for now, but it would be useful for people who want to preemptively mark some messages as not to be published (I'd like to do that, and cross it off my TODO file). Does declassify-t...@d.o sound good? Incidentally, the declassification GR was passed on 2006-01-01, which means next January (3 years after) there'll be material suitable for declassification (including two memorable threads). If somebody is keen on forming a declassification team, now it'd be a good time to talk to the DPL. (If a team is to emerge, and they prefer something else than mails to an alias for expressing one's wishes, I'm fine with waiting a bit, too.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Testing can show the presence of bugs, but not their absence. -- Dijkstra -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FINAL call for votes for the Lenny release GR
(Bcc secretary@ in case he doesn't follow -project and cares about this.)
Debian Project Secretary secret...@debian.org wrote:
When sending email from role addresses, I think it's better if the real
name of the person is used, together with the role address itself,
rather than using the role name (which is alread embedded in the
address). This gives you immediately information that otherwise you have
to obtain from the {gpg,} signature.
I'm just saying because I really believe this proposed way is better
(and what's always been the tradition?), but if most people disagree,
please ignore me.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The first step on the road to wisdom is the admission of ignorance. The
second step is realizing that you don't have to blab it to the world.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The Unofficial (and Very Simple) Lenny GR: call for votes
(Bcc: -project) They say forking in a Free Software project should only be done as a last resort, but that it is important that such option is always available. It's very sad we've come to this point with this vote... If you feel disenchanted about how the Lenny GR has been handled and, in particular, with the resulting ballot and its 7 options, I invite you to participate in this unofficial vote and, optionally, to show your discontent by ranking Further Discussion above all other options in the official vote (see below about this). If you've voted already, you can recast your vote as usual. This is an unofficial vote, but at least it will be easy to vote in. If FD wins in the official one, and depending on the participation on both, it may also give us a good approximation about what the developers think with respect to releasing Lenny. Ballot == Please vote by writing numbers between 1 and 2 in the boxes below, etc., and send your PGP-signed ballot to adeodato-gr_lenny_u...@debian.org (M-F-T and Reply-To set). - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- f2276370-dfd7-45db-92d5-2da0c179c569 [ ] Choice 1: Delay Lenny until known firmware issues are resolved [ ] Choice 2: Acknowledge the lenny-ignore tags as set by the release team - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Received ballot count and other statistics will show up at: http://master.debian.org/~adeodato/gr_lenny_unof/ Votes are processed and acknowledgements sent 2 minutes past each our. Vote key The temporary key used for this vote is 0x93544AEA (attached). You can encrypt your vote using this key, and replies will be sent signed with it (and encrypted to yourself). Voting period = Voting in this unofficial setup will close at the same time as in the official gr_lenny vote. At the moment, that's 2008-12-21 23:59 UTC, but there are signs that this could be a mistake and the date should be 2008-12-28 instead. If the official date changes, so will the unofficial one. Text for Choice 1 = The Debian Project unofficially decides that we should not release Lenny until all the bugs reported against linux-2.6 regarding firmware blobs without source that were reported before 2008-11-01 are resolved and the fix available in Lenny. Text for Choice 2 = The Debian Project unofficially states their agreement with the use of the lenny-ignore tag that the release team has applied to bugs in the linux-2.6 package. On ranking FD first in the official vote Participating in this vote should not imply that you are in disagreement with the official ballot: maybe you are not, but understand that other people are, and decide to participate in the unofficial vote nevertheless. Because of this, I recommend that you rank FD as your first choice in the official vote if you want to say, This ballot is not right. Here are some foreseeably frequent asked question about this procedure: Q: If I rank FD over option #5, won't option #1 be more likely to win? A: Not if you rank option #5 over option #1, even if both are below FD. Then, in the run between #5 and #1, your vote will go for #5 as if it had been above FD. Q: What if #5 does not reach quorum? A: If #5 does not reach quorum, it's hopefully because all people who would have ranked #5 above FD have ranked #5 *and* #1 below FD. In that case, FD will beat #1 if #5 was meant to beat #1 without the protest. Q: If FD wins, what happens? Can Lenny release, or do we have to redo the vote? A: Some people think that FD would mean that the release team is not overruled in their decision to proceed with releasing Lenny, and hence they'd be allowed to continue in this intent. For the details, please read: http://lists.debian.org/debian-vote/2008/11/msg00244.html Q: Doesn't ranking FD first make less likely that the 3:1 options reach quorum? A: Yes, certainly. If you liked these proposals, this is a price you have to pay for making your discontent heard. However, sometime after these votes we should hold separate votes for each orthogonal issue, eg. choice #6 and, if there's enough interest, #4. The discontent of the day, -- Adeodato Simó -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBElGP6gRBACvP6WM7imDVViHnnZiRx2q5jzG/R3IKVWgRFU7GChVP3VoPzqm hT44iw2shexiro5gAKDnjNlL+HsQDDN56PJ51MLmPOTVHhztKV3+o+GAjUZI6nXA KC0w1sDi4InYLknoROAg4Vsp9O1BIAFOc7GahvJJ/Q9PanWO7P9iegI2DwCguMeh 58SE8qNIFbNCVXyh1szqq48D/ijKBBKBCCk/8syzALbJOxa9gDZRP5zHWYOcj6UO qUxaAc/T+eyUONxrN46MEca1n1oAcBYNJykkMzhFXnbx8tqkCe+YXlHcokHZtXi7 gB4bluX7XNDnPdSzc56u935q/jv+aFsdUPLgkqyjYpS4ROUjqpFlXIaKg3b2h1Iz UVWwA/9Xp7yD1IxeMFgdSPbsN/uZBEkDzv09P23Ab2SAtpRMJMBAxCmqRzcUBPDl TmMZn/IEB5fnG+wdJaeHDsnRuEKgHdlj7DbUBuHVu2tmQWy0Zmw2Vlyubu92luf6 FHayr+rq3vFDNPi+mv3Tatr6grNjsrK2Bx3o/5z4g7PZtgVXqrRATGVubnkgVW5v
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
* Antti-Juhani Kaijanaho [Mon, 15 Dec 2008 19:32:40 +0200]: On Mon, Dec 15, 2008 at 05:37:33PM +0100, Adeodato Simó wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- f2276370-dfd7-45db-92d5-2da0c179c569 [ ] Choice 1: Delay Lenny until known firmware issues are resolved [ ] Choice 2: Acknowledge the lenny-ignore tags as set by the release team - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Why is there no Further Discussion option? Because I liked it better without, and nobody who read the draft drawed my attention on the lack of it, or the importance of it. I'll note that I circulated the draft on a debian channel you're in, and that you were active on it between my posting of the draft, and my sending it. (Not that I'm blaming you, but it's difficult for a single person to get everything right alone, and that's what you circulate a draft for. The assistant secretary also got to read it...) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org He who has not a good memory should never take upon himself the trade of lying. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
* Frans Pop [Mon, 15 Dec 2008 18:23:00 +0100]: How does this help? The only effect of voting FD on the official vote is to play into the hands of those who don't want any firmware support in Debian. That is not true, as it is (hopefully clearly enough) explained in the mail you replied to, section On ranking FD first in the official vote. I don't like either of these choices. So what do I do now? You don't vote, or you vote 11, or you raise your concerns, or you go for a walk. Is up to you, really, because I did the best I could, but it's impossible to please everybody. Main reason is that I don't think the RT has the right to decide whether or not to release with firmware that is, according to current interpretations of the DFSG, non-free. This is a decision that should be made by the project as a whole because that is only thing that is consistent with the way the question has been handled for Sarge and Etch, especially given the fact that the resolutions passed then explicitly limit the exception to a single release. This is a perfectly valid opinion, which I understand and respect. You can read this message of mine from 2008-10-30: http://lists.debian.org/debian-vote/2008/10/msg00288.html I acknowledged (thought admittedly very tersely) that such position is valid, and should get discussion, and later a GR. If it is important to you that the release team doesn't use suite-ignore tags on bugs regarding DFSG compliance, then go for it: propose a GR, and let's vote on it (I repeated this idea in the Unofficial GR mail, too). My opinion is that the release team should have the right to that use of suite-ignore tags, and then get overriden by a GR on a case-by-case basis, when people feel the tags have ben misused. But if developers show they don't want for it to work that way, then it is for us to accept that and move on, period. I very much don't want option 2, but option 1 would mean sanctioning the RT, which I very much also don't want to do. The official vote at least _does_ allow me to express my opinion. Hm. Can you ellaborate on what you mean by sanctioning the RT. If you mean to imply that option #1 in the unofficial vote inadvertently says RT should have the right for suite-ignore tags always, no matter what, that wasn't the intention and I don't think it says that. If you don't mean that, then I'm unsure what you mean and would like you to ellaborate. If you dislike the wording of the proposal, and would have liked something that didn't mention the RT at all, well... see above, I'm not perfect and you can't please anybody. (I circulated the draft in some of the channels I'm in, and nobody raised that concern.) IMO we _do_ need the current vote, only it should not have been contaminated with the options re. the release team powers and re. source requirement for firmware. Those issues should IMO have been handled as separate GRs _after_ the question what to do for Lenny had been settled. Fully agreed. (Though up to the first comma, I agree because there was an effort by a number of developers who wanted this vote to happen, not becaue it was needed no matter what, see above. But that way of thinking can of course change via a release team powers GR, to use your own words.) Thanks for increasing the mess we already have. I will personally ignore this additional vote which suffers from the same problem as the official one, namely that it is unacceptably colored by the person who is managing it. Peace to you too. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
* Adeodato Simó [Mon, 15 Dec 2008 21:35:44 +0100]: I believe developers, and particularly those holding key positions, should not ignore other developers even if their concerns don't come ^^ Er, should make an effort not to; I think the difference is important. in with a wrapping of sugar. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Love in your heart wasn't put there to stay. Love isn't love 'til you give it away. -- Oscar Hammerstein II -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
* Adeodato Simó [Mon, 15 Dec 2008 21:35:44 +0100]: Well, you'll have to understand that I'm not going to stop doing something which I don't believe to be wrong just because a fellow developer asks me to. I retract this paragraph. It was written in the first pass of the reply, before I my sat on reference happened (don't ask), and later on I didn't realize it no longer applied. Sorryp. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The true teacher defends his pupils against his own personal influence. -- Amos Bronson Alcott -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: More frequent dinstall runs and mirror pushes
* Joerg Jaspert [Fri, 05 Dec 2008 00:31:22 +0100]: Hi as the subject says, we are planning to increase the frequency of dinstall[1] runs. Our current plan is to have 4 runs a day, switching From the current [07|19]:52 schedule to the new [01|07|13|19]:52 schedule. All times are in UTC. Would it be bad to suggest a move to 0/6/12/18 UTC or something equally sensible? The rationale is that these times ought to be more easily remembered... -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Andrés Calamaro - No tan Buenos Aires -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Peter Palfrader's proposal [1] explicitly said, and I quote: | I'm hereby proposing the following general resolution. I don't think it's acceptable to bundle it up with the ongoing GR, since it was not proposed as an amendment to it. [1]: http://lists.debian.org/debian-vote/2008/11/msg00164.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The problem I have with making an intelligent statement is that some people then think that it's not an isolated occurrance. -- Simon Travaglia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE 4.x in Debian
* Sune Vuorela [Sat, 08 Nov 2008 10:49:23 +]: On 2008-11-08, Adeodato Sim?? [EMAIL PROTECTED] wrote: * Sune Vuorela [Fri, 07 Nov 2008 21:17:40 +]: On 2008-11-07, Gordon Haverland [EMAIL PROTECTED] wrote: Can someone make a reasonable approximation to an official comment on the timeline for KDE 4.x getting beyond experimental, and traversing unstable/testing/stable? unstable: within a week after lenny release Hopefully it's possible to coordinate with the release team on this. In Of course. Great. But with the big backlog of mails needing processing in -release, I thought I would wait a bit with taking release team time for coordination. If release team members feel like discussing it now, I'm open for that. Oh no, of course coordinating with the release team /after/ the release of Lenny. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Family - Al otro lado -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for data about development
* Paul Wise [Thu, 09 Oct 2008 11:04:51 +0800]: * Manoj Srivastava [Wed, 08 Oct 2008 14:19:36 -0500]: You possible want to CC Katharine, I'd say it's highly likely that she's not subscribed to -project. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- F. Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the use of epicene they in technical documents.
* MJ Ray [Fri, 15 Aug 2008 09:20:26 +0100]: Adeodato Simó [EMAIL PROTECTED] wrote: * Andreas Tille [Thu, 14 Aug 2008 16:15:56 +0200]: Yes, and the funny thing about this is that I've always seen men very engaged in this kind of discussion and I have the boring feeling that they are using this as kind of excuse for not doing something else to make sitation of genders equal. Whoa, is that a feeling or an accusation? I see feeling clearly there on the second line. Why suggest Andreas Tille is dishonest like that? Slapping prefixes around does not magically exempt you from taking responsibility for your words (and with this I don't mean Andreas wanted to do that, I'm merely replying to your comment). If I say on list I have the feeling MJ Ray would rape a baby if that'd make him member of the SPI board, it'd be moronic on my part to expect you to calmly reply No, that's not true instead of something else. HTH, -- Adeodato Simó -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the use of epicene they in technical documents.
* Andreas Tille [Thu, 14 Aug 2008 16:15:56 +0200]: Yes, and the funny thing about this is that I've always seen men very engaged in this kind of discussion and I have the boring feeling that they are using this as kind of excuse for not doing something else to make sitation of genders equal. Whoa, is that a feeling or an accusation? And about doing something else, I personally think my time in this thread is time well spent. So I'm not willing to play stupid tricks on the language until I see any evidence that the situation of woman became better because of doing this. They may be stupid tricks for you, but they sure are not for many other people, of all genders altogether. Also, if my first-hand experiences in other matters count, having people from the other side of the fence stand up besides you /already/ makes the situation better. (Everybody's MMV, of course.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The pure and simple truth is rarely pure and never simple. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the use of epicene they in technical documents.
* Charles Plessy [Thu, 14 Aug 2008 08:35:56 +0900]: please have some pity for the non-native speakers, who are taught that they is the third person plural pronoun. I'm not a native speaker, and of course the singular they was never mentioned to me in school, but I didn't find it particularly hard to understand when I first encountered it. I'll reckon it can be surprising at first but -honestly- do you think it's complicated enough that should be regarded as something better avoided when talking to non-natives? Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
objecting to +nmuX syntax (was DEP1: Non Maintainer Uploads (final call for review))
* Lucas Nussbaum [Mon, 11 Aug 2008 19:28:53 -0300]: The version must be the version of the last upload, plus +nmuX, I already objected to this in the past, and I'm loudly objecting again now. Some people on IRC shared this objection; I'm opening a subthread to see if I'm alone on this, or what. (Rest of feedback will go in the main thread in a minute.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - Love business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Non Maintainer Uploads (final call for review)
* Lucas Nussbaum [Mon, 11 Aug 2008 19:28:53 -0300]: Hi, these are some other, mostly minor bits: The version must be the version of the last upload, plus +nmuX, where X is a counter starting at 1. If the last upload was also an NMU, the counter should be increased. For example, if the current version is 1.5-1, then an NMU would get version 1.5-1+nmu1. If the current version is 1.5+nmu3 (a native package which has already been NMUd), the NMU would get version NMUed? Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry is special, it must be: * Non-maintainer upload Add trailing dot? If you upload a package to testing or stable, you sometimes need to fork the version number tree. This is the case for security uploads, for example. For this, a version of the form +debXYuZ should be used, where X is the current stable major release number, and Y is the current minor release number for a stable upload, or one higher than that for a testing upload. Z is a counter starting at 1. For example, while Etch (Debian 4.0) is stable, a security NMU to stable for a package at version 1.5-3 would have version 1.5-3+deb40u1, while a security NMU to Lenny would get version 1.5-3+deb41u1. This is the case even when it is already known that the next release will be a new major version ; for instance, Lenny will be released as Debian 5.0. Hm, this paragraph *really* feels out of place in this documment, even if they are uploads done by other people than the maintainer. 5.11.3. Using the DELAYED/ queue After asking the maintainer for the permission to upload your s/the// (or s/the/their/, see below). BinNMUs are usually done by porters. They add an entry to debian/changelog, explaining why the upload was needed and BinNMUs are usually triggered on the buildds via wanna-build. [An entry is added to debian/changelog, ...] would be more accurate. 5.11.6. NMUs vs QA uploads NMUs are uploads of packages which are owned by another maintainer. Can I has something else than owned, please? Maybe NMUs are uploads of packages by somebody else than their assigned maintainer.? * QA upload. If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned. When doing the first QA upload to an orphaned package, the maintainer should be set to Debian QA Group [EMAIL PROTECTED]. Orphaned packages which did not have a QA upload yet still have their old maintainer set. There is a list of them at http://qa.debian.org/orphaned.html. AFAIK, their PTS page will say they are orphaned, which may be handier than searching over then long list. Also, there are a couple places in the document where language it's not gender-neutral. If you care about that, I have a diff to move the document to use the singular they, please let me know if you're interested. Finally, let's hope this is the latest time in history we have to regulate NMUs, because we've ended up with something better. (FWIW I have the feeling NMUs are much more tolerated nowadays, so this document sounds a bit on the other side on the fence to me, but it's probably good after all since an environment where they are much tolerated may lead to the impression they can be taken lightly and prepared with less care, so thanks for pushing this DEP.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - Top of the world -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: objecting to +nmuX syntax (was DEP1: Non Maintainer Uploads (final call for review))
* Stefano Zacchiroli [Tue, 12 Aug 2008 17:18:40 -0300]: In addition, it has the advantage of being clearer, And the disadvantage of being less compact. Who do we /need/ to make it clearer for? Who that wouldn't be familiar with the old syntax could /benefit/ from this explicitness? (In the old thread the argument be consistent with NMUs to native packages was raised. For that matter, I also disagree about using +nmuX for native packages...) So, uhm, I guess the best we could do is give this sub-thread a bit of time to see if more people participate on either band. :-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - Plan Be -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deprecating (and deactivation) of an archive feature?!
* Julien Cristau [Wed, 06 Aug 2008 21:38:00 +0200]: On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote: Now, the idea would be to deprecate this feature, used by 8 packages in unstable, dropping complications in the database backend and the pool layout which we would want to avoid. Maybe you could tell us what the benefit of dropping this would be (as in, what are the changes you allude to, and why can't they work with this feature). I agree this would be useful. I do think that allowing packages in main to provide binaries in contrib is useful, so I'd like to hear what the benefits would be if we'd agree to lose it. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Luke Vibert - Harmonic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)
* Robert Millan [Tue, 05 Aug 2008 14:20:03 +0200]: I think the reason you (and the other minority of bashers in this thread) are annoyed is because the content of my message, not because its form. You are certainly entitled to believe that if it makes your day any brighter. -- Adeodato Simó -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)
* Robert Millan [Tue, 05 Aug 2008 15:13:17 +0200]: I'd rather believe something else if I could. Do you have a better explanation for: some people complain about my message being harsh by sending replies that are outright insulting. Yes, that your behavior was outraging (at least it was to me). (On the other hand, Ben's behavior on the thread has been exemplary, which I also feel needs saying.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)
* Robert Millan [Tue, 05 Aug 2008 23:17:10 +0200]: Then again, I don't see any judgement on _your_ behaviour in this mail. I just got scrutinized for using an (admittedly inappropiate) harsh tone, but apparently you don't think your own tone (which was outright insulting) deserves any kind of judgement. My tone is a bug: my internal operating systeam oopses horribly when users reach their quota; which fortunately seldom happens, thus not rendering the package completely unusable. On the other hand, while I should definitely be looking at geting my oopses fixed (and I will be!), maybe you should think for a minute if all those people trolling you (and not only in this thread) are actually trolling you, or there is something *else* to it. End of thread for me, with apologies to -project. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Polar - Don't want to be alone tonight -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iso's and everything missing?
* Ben Finney [Tue, 29 Jul 2008 14:01:38 +1000]: Shaun Crawford [EMAIL PROTECTED] writes: i noticed that everything is gone today! where are the iso's, packages, etc? something happen? Where did you last see it? Perhaps it's behind the couch. I'd be happier if nobody used such tone to communicate with users in the debian-project list. Thanks already, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Mecano - Cruz de navajas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDEquestion
* Sergio Franco [Thu, 22 May 2008 13:33:25 -0500]: Final question (curiosity), I read about a Linux application called Blender, this application needs glibc 2.3.6., which is the glibc version that comes with Debian 4.0r3? Etch has 2.3.6, you can find it out by visiting:o http://packages.debian.org/glibc Works for other packages, of course. ;-) In general, though, you need not worry about versions of libraries, and just check if the software you need is packaged for Debian; if that's the case, packagers will already have taken care of versions of dependencies. See: http://packages.debian.org/blender Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU versioning
* Mike Hommey [Tue, 29 Apr 2008 11:54:59 +0200]: FWIW, I think NMUing a package shouldn't end up with a sourceful upload but should instead have a .diff.gz, whether it's a native package or not. 100% agreed. (Assuming you mean a NMU should never, ever, create a new tarball, particularly applying to native packages.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: María Jiménez - La otra cara -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU versioning
* Bastian Blank [Tue, 29 Apr 2008 12:55:23 +0200]: On Tue, Apr 29, 2008 at 12:16:28PM +0200, Adeodato Simó wrote: * Mike Hommey [Tue, 29 Apr 2008 11:54:59 +0200]: FWIW, I think NMUing a package shouldn't end up with a sourceful upload but should instead have a .diff.gz, whether it's a native package or not. 100% agreed. (Assuming you mean a NMU should never, ever, create a new tarball, particularly applying to native packages.) It is valid to update to a new upstream release in a NMU, so this is bogus. Er, of course. I was mostly talking about normal NMUs to native packages. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: María Jiménez - Vuelve otra vez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU versioning (was: DEP1: Clarifying policies and workflows for Non Maintainer Uploads)
* Raphael Hertzog [Fri, 25 Apr 2008 16:16:34 +0200]: (reply-to set to debian-devel only) On Fri, 25 Apr 2008, James Vega wrote: On Thu, Apr 24, 2008 at 09:42:59PM +0200, Bas Wijnen wrote: This DEP is available on the Debian Wiki[1]. The version must be the version of the last upload, plus +nmuX, where X is a counter starting at 1. The above was added to the DEP to match dch but dch only uses that format for native NMUs as per the earlier discussion on -devel[0]. Is this an intended change to usk +nmuX for all NMUs or should the wording be updated to reflect current behavior? I want a consistent versioning scheme, thus +nmuX for both native and non-natives packages. I'd be very unhappy about that. For one, I think using such suffix in a field that forms part of users' everyday's life is, uhm, inappropriate or disruptive. What do they care if the version is a NMU or not? FWIW, I would've objected for native packages if I had read the thread at the time. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updated Debian Developers Keyring
* Joey Schulze [Fri, 18 Apr 2008 15:01:23 +0200]: Anthony Towns wrote: Not really an automated mail, but we can pretend. The following changes to the Debian keyring have been made: andete Added key: 062A20ADA62FF34A0DBE6FCD2A75E4D1B59BD712 [..] brlink Added key: 36471231FCDCB7A7DBBA935D5B3229580F1D92DA [..] micah Added key: 1130178AD4E90683B09B1EFF74905C458A5F4DA1 [..] toots Added key: 0872F2B38DEF6C06187342BD00B969AA1CA95D19 vanicat Added key: 9EBC79C5CECE61149C26FBD84669AAFCD09E8C0B vdanjean Added key: E71009150981FCD28A0BCA657EC8E2E36CC838D5 Do we now allow people who don't provide their realname to upload packages? Uh? The listing you quoted doesn't include their names, but you can of course read them in db.d.o, getent, or the keyring. (The reason why the listing didn't include the names is, I presume, because the code to generate it was different, and not prepared for that, as opposed to the names not being available.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: Introducing Debian Enhancement Proposals (DEPs)
Hi, Lars Wirzenius, Stefano Zacchiroli and myself are trying to introduce the concept of Debian Enhancement Proposals, which I had in mind for many months until purely by chance, in the Extremadura QA meeting last December, I brought it up to Lars, and together with Zack we produced an initial draft. After some feedback on that draft and some later work, we are now bringing it up for discussion here. The idea is simple and certainly not new, but we all thought it'd be good for Debian to have something like this, once tailored to Debian's own peculiarities. The goals we're aiming to are: 1. having clear indication of the status of ongoing proposals, particularly to settle that a certain design/implementation has been agreed upon, ensuring that time spent in that implementation will not by wasted, and dissipating fears of adopting such implementation (which should help to break the traditional wide adoption vs normative documents Debian loop) 2. having a central place/mechanism to document decisions and consensus reached in our traditional ways and forums, to which we can later refer to instead of yeah, *that* mailing list thread While writing the draft, we've tried to do things in a way that will adjust to the Debian way (TM). The draft is below. Now we'd like to receive feedback to improve it, and achieve consensus that it's good enough to try the idea with some real world examples. (Note that after that, and per the DEP0 text itself, it can be modified some more.) -8- Title: Introducing Debian Enhancement Proposals (DEPs) DEP: 0 State: DRAFT Date: 2008-01-15 Drivers: Stefano Zacchiroli [EMAIL PROTECTED], Adeodato Simó [EMAIL PROTECTED], Lars Wirzenius [EMAIL PROTECTED] URL: http://dep.debian.net/deps/dep0 Abstract: Workflow for managing discussions about improvements to Debian and archiving their outcomes. Introduction This is a proposal to organize discussions about Debian enhancements, reflect their current status and, in particular, to archive their outcomes, via a new lightweight process based on Debian Enhancement Proposals (DEPs). This idea is loosely based on existing similar systems such as RFCs and Python PEPs. It is also completely opt-in, and does not involve any new committees, powers, or authorities. Motivation -- Currently, when having discussions about improvements to Debian, it is not always clear when consensus has been reached, and people willing to implement it may start too early, leading to wasted efforts, or delay it indefinitely, because there's not clear indication it is time to begin. At the same time, potential adopters of an enhancement may not be able to easily assess whether they should use said implementation or not, because it's difficult to know whether it adjusts to the consensus reached during the discussion period. As our normative documents rely on wide adoption of a practice before documenting it, and adopters can be reluctant to make use of it before a clear indication that a practice has some consensus behind it, this creates a hard to break loop that this process hopes to alleviate, by providing a mechanism to reflect the status of each proposal, including whether it has reached consensus or not. Secondly, we lack at the moment a central index in which to list such proposals, which would be useful to see at a glance what open fronts there are at a given moment in Debian, and who is taking care of them and, additionally, to serve as a storage place for successfully completed proposals, documenting the outcome of the discussion and the details of the implementation. By using this process, people involved in developing any enhancement can help to build such index, with very little overhead required on their part. Workflow A Debian enhancement can be pretty much any change to Debian, technical or otherwise. Examples of situations when the DEP process might be or might have been used include: * Introducing new debian/control fields (Homepage, Vcs-*). * Making debian/copyright be machine parseable. * Agreeing upon a meta-package name or virtual package name. * Deciding on a procedure for the Debconf team for assigning travel sponsorship money. * Formalizing existing informal processes or procedures, e.g., the procedure for getting a new architecture added to the archive, or getting access to piatti.debian.org to run QA tests. The workflow is very simple, and is intended to be quite lightweight: an enhancement to Debian is suggested, discussed, implemented, and becomes accepted practice (or policy, if applicable), in the normal Debian way. As the discussion progresses, the enhancement is assigned certain states, as explaned below. During all the process, a single URL maintained by the proposers can be used to check the status of the proposal. The result of all this is: 1. an implementation of the enhancement and 2
Update #1 [RFC: Introducing Debian Enhancement Proposals (DEPs)]
remains open. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org It is by logic that we prove, but by intuition that we discover. -- Henri Poincaré -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preguntas acerca de la version
Hola Sergio. debian-project@lists.debian.org es una lista de correo en la que se habla en inglés. Por favor, dirígete a esta otra dirección de correo: [EMAIL PROTECTED] O bien escríbenos en inglés. ;-) (Por cierto, tu correo parece incompleto, como si se hubiera cortado.) cordial saludo escribo este mail para hacer una pregunta acerca de la debian 4.0 y debian sarge 3.1 lo que sucede es q (@-project: His email is cut without completing the question, so I cannot translate what it was about.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Los Fantasmas del Paraíso - La Bella Durmiente -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planet policy?
* Alexander Schmehl [Thu, 09 Aug 2007 10:40:35 +0200]: * Evan Prodromou [EMAIL PROTECTED] [070808 18:44]: I've heard from people who really like reading my blog posts on Planet Debian, and people who really hate them. [..] So, I've removed the feed. Old posts should roll off the end in a day or two, or if there's some sense of urgency, I guess Mako can clear them out by hand. Why? I must confess that I am more in the haters group, than in the lovers group, and as one of those, I really don't see a problem in skipping your blog posts, as I don't see a reason for you to remove your blog. From my, with all due respect, hater position, I think the same. Particularly if you have evidence *some* people enjoy reading you via Planet. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org One look at the From: understanding has blossomed .procmailrc grows -- Alexander Viro [EMAIL PROTECTED] on linux-kernel
Re: Concerns with Open/OS Corporate Linux ads?
* martin f krafft [Tue, 29 Aug 2006 19:17:39 +0200]: Then they go on to state that Debian is - reliable - secure - upgradeable - integrateable - preconfigured - remotely administratable and that they add support and maintenance, which adds the features - reliable release cycle - newest packages - security team - preselected packages - security administration - certification - software tests I'd be interested in what people think. Am I just overreacting? I think you're reacting in the wrong direction (or at least, in the wrong direction for a *first* reaction.) With this I mean that, if Debian initiates contact with this entity, I'd like for it to be to mention that, if they're interested, they can contact DPL-delegated Project Member Joe to work out and discuss possible ways to have some of their work go back to Debian. (See below) I'd offer myself, but while I know the Debian side well, I'm quite unfamiliar with the enterprise environment. I'd be happy to act as an assistant of the delegated person, should anybody step. :-) * * * Having their work go back to Debian may sound impossible to you if you think of straightaway, but it should be workable. To mention a couple ideas: * release the backports they produce (newest packages) after a while; eg. release backport for AppFrog X.Y.Z right after they've made X.Y.Z+1 available to their clients; or X.Y+1.0; or X+1.0.0. * allow the staff that prepares security updates for them, to spend 1 out of each X working hours preparing a patch for a vulnerability present in a stable package they don't support, coordinating with the Security Team as to not duplicate effort. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «Ara que ets la meva dona, te la fotré fins a la melsa, bacona!» -- Terenci Moix, “Chulas y famosas” signature.asc Description: Digital signature
NMUs and (auto-)subscription to the PTS
* Anthony Towns [Mon, 31 Jul 2006 10:29:57 +1000]: subscribe to the PTS ISTR a discussion about automatically subscribing NMUers to the PTS for the package, and dropping the subscription with the next upload of the package (be it a maintainer upload or not). I'd be interesting in hearing opinions about this functionality. I think it'd be good to have it, if implemented in a good way. (Guess somebody could come up with But I track bugs on my non-maintainer uploads by visiting the BTS via web everyday!, but well, conceivably so could say the maintainer, and he receives the mail anyway.) If there are no reasonable objections, I'll let this hang in my ~/TODO. :) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Capitalism is the extraordinary belief that the nastiest of men, for the nastiest of reasons, will somehow work for the benefit of us all. -- John Maynard Keynes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
* Hubert Chan [Mon, 31 Jul 2006 00:09:26 -0400]: Not having used the DELAYED queue before, is it possible for the maintainer to reject an upload without making their own upload? e.g. if the NMU is broken, but it will take me more than a week to test a proper fix. Or if I decide that the package shouldn't be changed after all. etc. No, there is not. If the NMU is horribly broken, telling that to the NMUer should get them into doing something (withdrawing it, or fixing it). If not, and it's really important that the upload does not make into the archive, you can e.g. just reupload the current version (e.g. 1.2-3 as 1.2-4, which is bigger than 1.2-3.1). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Branding for Debian derivatives -- Debian Distilled
* Anthony Towns [Sat, 29 Jul 2006 17:11:40 +1000]: Okay, so this is just my idea. Add grains of salt to taste, etc. The idea is to take the Debian official use logo [0] which we've never really made much use of, and declare it the logo for derivatives instead. Add the word distilled [1] underneath, and you could describe a derivative something like this: Foo Linux is Debian -- distilled. We've taken the best bits of Debian, removed some of the rough edges and bottled the result. We hope you'll like it. Coincidentally the official logo has a swirl without the Debian swirl's rough bits, and a bottle! And I think removing the rough edges and bottling it is a pretty fair description of the aims of many Debian derivatives to boot. And I don't think it's entirely unfair to say that developers and users who prefer Debian itself also tend to prefer the rough edges and raw flavour of Debian too. Anyway, it's just an idea that I thought was interesting, please do come up with your own ideas, or hack this one to pieces by changing the description or coming up with a different logo, or whatever. I personally like the bottled and unrough swirl ideas quite much, but I wouldn't like to loose the Official logo for that. But if someone with design abilities would prepare e.g. a transparent bottle with an unrough swirl inside, I'd be all for it. Just my opinion. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Michael Jackson - Can't let her get away -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
* Gustavo Franco [Fri, 28 Jul 2006 14:38:52 -0300]: * Promote NMU LowThreshold wiki list giving it some official status. And remember that (well done) NMUs are not only for bugs of RC severity. For example, I'm going to upload to 7-delayed a fix for #368917, sending the patch to the BTS at the same time. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Polar - It's so cold outside -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
* Gustavo Franco [Fri, 28 Jul 2006 18:01:26 -0300]: I've seen more problems of bad maintainers with bad packages, than of irrevertible broken NMUs. Yes shit happen, but well, if you don't move, things rot, which is not much better. Yes, and we need to remember that we're talking about broken stuff in sid that shouldn't hurt too much. No, no, no, no, no, no, no. No. No cookie for Gustavo. NMUs are to be done as if you'd be uploading to proposed-updates (e.g. in the amount of testing you've give them). Ideally, all uploads would get that amount of testing. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org It is impossible to make anything foolproof because fools are so ingenious. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
* Thomas Viehmann [Fri, 28 Jul 2006 23:40:19 +0200]:
If that is wanted, I'd consider it important enough information to have
it in debian/control.
A couple packages of mine ship already with an X-VCS-Bzr header in the
source. Example:
(Format: X-Vcs-${VCS}: ${URL})
X-Vcs-Bzr: http://people.debian.org/~adeodato/code/packages/taglib
Another, perhaps more parseable format, would be:
X-VCS-Url: ${VCS}:${URL}
X-Vcs-Url: bzr:http://people.debian.org/~adeodato/code/packages/taglib
Though you'd had to wonder what you'd do with a svn:// url.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
About 0-day NMUs and NMU policies (Re: package ownership in Debian)
* Joerg Jaspert [Fri, 28 Jul 2006 22:23:34 +0200]: Hi. I'm replying here because it seems it's where it started the 0-day idea that has been later repeated all over the thread. Simply change the NMUs to be always 0-day, for all bugs =normal. Which means - upload and mail to BTS at the same time. A NMU policy is defined by three variables: (days_until_uploadable, days_for_review, min_severity). This way, our current policy for RC bugs is (7, 0, serious), and the one you propose for this package ownership problem (X != 0, 0, normal). Personally, I think that if we want the experiment to be successful, you can't start with such a relaxed policy. For non-RC bugs, I think the set (21, 7, normal)+(14, 7, important) is a pretty healthy one. Lowering days_for_review I really believe (as Simon pointed out) having the NMU diff live a few days in the BTS before entering the archive does help QA, because there's room for peer review (from the maintainer, or PTS subscribers, or even person interested in that particular bug, and subscribed to it). Because of this, I don't think days_for_review should be lowered at all except if it's clear that doing so will really pay off. And for non-RC bugs, I think a week works just fine. Thoughts on our current RC NMU policy - When you do a delayed upload, there's always the possibility that the maintainer will upload themself, making you feel your effort, if not worthless, somehow dismissed. So with days_for_review != 0, you end up NMUing only for those bugs that you really care about, that you want fixed so badly that it doesn't matter where the fix finally comes from. IMHO this is good, because it means they'll be prepared with more care. But, OTOH, most RC bugs don't matter much to each of us individually, but only in the sense that they can delay the release. If it's going to be a big PITA to provide a fix for one of them, though, plenty of times it won't be enough. I don't know if it was its original intent or not, but if you ask me, it's precisely this what having days_for_review = 0 for RC bugs buys us, i.e., not so much having the fixes appear earlier in unstable and hence in testing, but acting as an incentive, since the uploader gets an immediate reward, which results in a bigger amount of uploads. Hopefully, when Etch gets released, we'll look back and confirm that giving up that bit of peer review was worth it, and that having that tool named 0-day NMUs available did really help our release process. It is important, though, to never forget that doing a 0-day NMU is a bit like driving an ambulance: you have the right to go fast when/if it's crucial for the person inside to arrive the hospital ASAP... alive. If you're carrying a minor injured, or you're a novel driver, or it's raining like hell, you still have the right to go fast, but it's maybe not the best thing to do. (a.k.a. nobody prevents you from uploading NMUs to DELAYED.) :) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Bug#345067: Draft of documenting the ide-generic problem
* Jonas Smedegaard [Wed, 08 Mar 2006 16:51:45 +0100]: I get similar response with my GPG-signed messages. The messages do show up in the BTS however (if anyone find interest in investigating the cause of the refusal). Perhaps same limitation as for the voting engine (Inline GPG signatures not treated as valid)? Frans' messages are PGP/MIME signed, so it seems that no signatures at all are accepted. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Bambino - Canción de orfeo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
* Reinhard Tartler [Tue, 17 Jan 2006 11:07:40 +0100]: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2005/05/msg00260.html Yah, zero luck: http://lists.debian.org/debian-devel/2005/05/msg00077.html http://lists.debian.org/debian-devel/2005/05/msg00080.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated testing - design and interfaces
* Ian Jackson [Fri, 18 Nov 2005 11:58:26 +]: This is a technical comment and ought to be discussed on -policy, rather than -project. Note that you posted to the wrong list first. -- Adeodato Simó EM: dato (at) the-barrel.org | PK: DA6AE621 So, irregular/impure/non-elegant syntax doesn't bother me. Shit, I speak English. Mainly I just want to type less. -- William Morgan, on [ruby-talk:131589] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why Debian Core Consortium ? Why not UserLinux? Why not Debian?
* Benj. Mako Hill [Wed, 24 Aug 2005 18:21:38 -0400]: FWIW, I've also heard people complain that we have unfairly played up our Debian roots. ;-) Now I'm curious, can you give some background about this? -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Ara que ets la meva dona, te la fotré fins a la melsa, bacona! -- Borja Álvaro a Miranda Boronat en «Chulas y famosas» -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion of bug #311683, default kde install shows porn
* R. Armiento [Fri, 03 Jun 2005 18:02:54 +0200]: I just want to bring bug #311683 to public awareness and discussion. Since it is a bit of a sociopolitcal and policy issue, I suspect there may be people out there who feel strongly about this one way or the other, and with the upcoming release of debian sarge, it might not be optimal if this feature makes it out to the official release under the radar without being publically discussed. 1. This is not getting fixed for Sarge, it has been reported too late. You may want to (try to) convince the Stable Release Manager that this is really suitable or even necessary for a point release. 2. The KDE team has already said (read the bug log) that we will provide a solution for this issue in our next upload. Either by not providing the Web Collage screensaver at all in the Control Center, or (preferably) by not letting Random mode pick it. Other solutions, like having Random mode let you pick what screensavers to use, are in upstream's realm. 3. If you're a system administrator and are concerned about this biting you and your users, do one of these: - don't install the kscreensaver-xsavers package - dpkg-divert --add --rename /usr/share/applnk/System/ScreenSavers/webcollage.desktop 4. If you're a KDE user and don't want Random mode to pick Web Collage, do one of these: - don't use Random mode - ask your sysadmin to perform one of the actions in (3) - drop the attached file in ~/.kde/share/applnk/System/ScreenSavers; do gunzip it first, but DO NOT rename it. (With it, whenever Web Collage would have been used, Blank Screen will be called instead. I attach the diff to the original file too.) 5. If you are reading the above and think Debian should deliver a good product by default, and neither (3) nor (4) are reasonable things to ask to our users, I agree, but the timing of this report has been very unfortunate. Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge. -- Erwin Knoll webcollage.desktop.gz Description: Binary data --- webcollage.desktop +++ webcollage.desktop @@ -1,9 +1,8 @@ [Desktop Entry] Encoding=UTF-8 -Exec=webcollage +Exec=kblankscrn.kss Icon=kscreensaver Type=Application -TryExec=xscreensaver Actions=InWindow;Root;Setup X-KDE-Category=Banners Pictures Name=Web Collage @@ -38,7 +37,7 @@ Name[zu]=Umdwebo wezithombe ze-Web [Desktop Action Setup] -Exec=kxsconfig webcollage +Exec=kblankscrn.kss -setup Name=Setup... Name[af]=Opstelling... Name[bg]=... @@ -94,7 +93,7 @@ Icon=kscreensaver [Desktop Action InWindow] -Exec=kxsrun webcollage -- -window-id %w +Exec=kblankscrn.kss -window-id %w Name=Display in Specified Window Name[bg]= Name[bs]=Prikai u navedenom prozoru @@ -134,7 +133,7 @@ NoDisplay=true [Desktop Action Root] -Exec=kxsrun webcollage -- -root +Exec=kblankscrn.kss -root Name=Display in Root Window Name[bg]= Name[bs]=Prikai u korijenskom prozoru signature.asc Description: Digital signature
Re: Taking a position on anti-patent licenses (was ' Re: Bug#289856: mdnsresponder: Wrong license')
[I'm trying to follow the discussion in hopes of better understanding the issue in order to form an opinion about it. Please excuse me if I need big amounts of cluebat with this...] * OSS [Wed, 26 Jan 2005 12:27:44 -0700]: Steve Langasek wrote: Matthew Garrett's subsequent message pinpoints where I am with this: terminating patent licenses in response to patent claims is fine, requiring distributors to allow royalty-free distribution if they're going to engage in distribution at all (as in the GPL) is fine, but terminating copyright licenses in response to defense of one's patent rights is not ok. Steve, If I follow you correctly A - writes program #49 and licenced under GPL-compliant-patent-defending-licence B - distributed program #49 to C-D (may or may not have made enhancement/change) C - determines their patent is infringed by program #49 and launches legal action (presumably against A, B, D) E - may have patents infringed by program #49, but is otherwise uninvolved takes no action F - determines their patent is infringed by program #49 and launches legal action (presumably against A, B, D) We know that no option is available to use the licence to defend against F, unless we use the unacceptable path of cross-contamination, etc. (ie any software patent defence terminates all software licences with patent defence clause) Josh wants C to lose their licence to use program #49 as a result of legal action as a mechanism to defend A, B D's rights to develop, distribute use program #49. You want C to lose any patent licences granted for program #49. How does that help defend program #49 and hedge software patents? If I understood correctly, C sues A over patent infringed by program #49, so if falls in the first group described by Josh, and so it would be fine that program #49's license terminates C's rights under this circumstances. (First group on Josh's mail, as I said.) Now imagine, to describe the second group: - D, to whom B provided a copy of p#49, sues A over a patent infringement NOT related to p#49 at all. As per Matthew Garrett's post, license may be of two kinds, each of them mandating that: (a) D's license to use any program written by A and licensed under License LA (or equivalent) terminates completely. (b) D's patent licenses, for patents holded by A and applicable not only in p#49, but in every program written by A and licensed under License LB (or equivalent), terminate. As Matthew said, (a) is not acceptable, and (b) may be (people were more or less happy with [it]). So I have a question: what is the _practical_ result of License LB in (b) above, that D can't use A's LB-licensed programs any more, unless D purchases the relevant patent licenses? (Or perhaps the can't use ... should read risks being sued by A over patent infringement). And: if D immediately stops using p#49 and the rest of affected programs, may A sue D too? Thanks, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Taking a position on anti-patent licenses (was ' Re: Bug#289856: mdnsresponder: Wrong license')
* Adeodato Simó [Thu, 27 Jan 2005 06:10:39 +0100]: So I have a question: what is the _practical_ result of License LB in (b) above, that D can't use A's LB-licensed programs any more, unless ^ uhm, that's probably wrong, then? (After re-reading Steve's mail, triggered by Josh's reply.) D purchases the relevant patent licenses? (Or perhaps the can't use ... should read risks being sued by A over patent infringement). -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 One way to make your old car run better is to look up the price of a new model. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When will KDE 3.3 be in Sarge?
Grace or Gnuplot). So if Sarge go without KDE 3.3, there would be great pity. For these applications, I have mixed some unstable packages into my system, so the apt system do not work unless 1. Someday KDE3.3 come to testing, 2. I dare myself to use complete source from Sid, 3. I hold back some package and downgrade the unstable packages(remove Kst and labplot, etc). So, I am eager to know when KDE 3.3 will be there. sarge will ship with KDE 3.3, and it will be available in that distribution real soon now. really. I think it can happen in the first half of January 2005. By the way, when will Sarge be releasedm and what is the codename of next release? Everyone is expecting to know... the Debian release after sarge will be called 'etch'. cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Ciao
* Emanuele Rocca [Mon, 27 Dec 2004 15:20:47 +0100]: Dai un'occhiata a: http://www.debian.org/doc/user-manuals#quick-reference Più in generale: http://www.debian.org/doc/ I was once told about the Debian GNU/Linux Desktop Survival Guide [1]. The table of contents seems (too?) comprehensive, and perhaps is worth mentioning (I haven't had time to read any chapter, so I can't talk about its quality). [1] http://www.togaware.com/linux/survivor/ hth, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 I don't want to achieve immortality through my work. I want to achieve immortality throguh not dying. -- Woody Allen
