Bug#508882: ITP: xdemorse -- GTK+ Morse Code Decoding Software
Package: wnpp Severity: wishlist Owner: Joop Stakenborg pa3...@debian.org * Package name: xdemorse Version : 1.3 Upstream Author : Neoklis Kyriazis neoklis.kyria...@gmail.com * URL : http://5b4az.chronos.org.uk/pages/morse.html * License : GPL Programming Lang: C Description : GTK+ Morse Code Decoding Software xdemorse is a GTK+ graphical version of demorse, using the same decoding engine. It has an FFT-derived waterfall display of the incoming audio signal's spectrum, as well as a 'scope-like display of the audio detector's output and status of the mark/space discriminator (slicer). xdemorse also has CAT for the FT-847 and this can be used to net the receiver's frequency to the incoming signal, by clicking near its trace in the waterfall display. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre mathieu.malate...@gmail.com * Package name: dicom3tools Version : 1.0.20081122 Upstream Author : David A. Clunie dclu...@dclunie.com * URL : http://www.dclunie.com/dicom3tools/workinprogress/ * License : BSD Programming Lang: C, C++ Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. - System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. What are DICOM, ACR, NEMA, SPI? -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Christian Perrier wrote: (…) So, I had another idea: open foo-backports at the moment foo is frozen so that maintainers can upload the latest bleeding edge versions of their packages there, when using experimental is not possible for some reasons. And make backports an official service of Debian? Hopefully, that discussion (in backports-us...@lists.b.o) could lead to somethingwe'll see. Yes. Hopefully. But maybe after Lenny's release (and parties ;) ). -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
* Russ Allbery [Mon, 15 Dec 2008 11:09:45 -0800]: Thomas Weber thomas.weber.m...@gmail.com writes: Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre: I've been talking with Manoj already, in private to try and avoid flaming. I specifically asked him to delay this vote until the numerous problems with it were fixed, and it was started anyway. I'm *really* not happy with that, and I'm following through now. Uh, I don't quite get this: you shortened the discussion period, but at the same time asked the secretary to delay the vote? Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Le Tuesday 16 December 2008 16:50:52 Adeodato Simó, vous avez écrit : Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? I don't read shorten in this link, only start. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Le Tuesday 16 December 2008 16:52:55 Romain Beauxis, vous avez écrit : http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? I don't read shorten in this link, only start. Woops, sorry I misread discussion with vote. The problem with this quote is that it was used to justify the shortening of the *voting* period too. This was already raised by Cyril. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote: Didier Raboud schrieb: ? Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. That sounds like ubuntu. But speaking of them, how come they are able to do this so much more frequently than we are? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 08:58:40AM -0600, John Goerzen jgoer...@complete.org wrote: On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote: Didier Raboud schrieb: ? Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. That sounds like ubuntu. But speaking of them, how come they are able to do this so much more frequently than we are? Freezing is called releasing, for Ubuntu, and the first point release, or second one, is the actual release. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Hi, On Dienstag, 16. Dezember 2008, Lucas Nussbaum wrote: I agree. It's clear that most people don't work on RC bugs instead of working on their packages: during freezes, they just stop working on Debian, since it's judged socially incorrect to work on one's packages in unstable or experimental during the freeze. We should really think of ways to allow people to continue improving unstable during freezes, while making sure that this doesn't affect the release (ie, lower buildd priority for unstable packages, for example). Besides what Neil said, I disagree with your conclusion. IMO we should make more people work on finishing the release, so that we then all can move on in unstable. That some people are not interested in making the release happen, is a real problem IMO. We shouldnt encourage such behaviour ;-) regards, Holger P.S.: /me throws in a herding cats and we are all volunteers for completion. signature.asc Description: This is a digitally signed message part.
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 05:13:59PM +0100, Holger Levsen wrote: That some people are not interested in making the release happen, is a real problem IMO. We shouldnt encourage such behaviour ;-) Then why are you posting to mailing lists instead of releasing lenny? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On 2008-12-16 15:58 +0100, John Goerzen wrote: On Mon, Dec 15, 2008 at 10:52:53PM +0100, Bastian Venthur wrote: Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. That sounds like ubuntu. But speaking of them, how come they are able to do this so much more frequently than we are? I'm not involved with them, but I guess the reasons are: - Reduced number of supported architectures - Reduced number of supported packages - No notion of release-critical bugs -- release when the deadline comes, no matter what. In other words, reduced quality standards. Especially the last point is important and probably shared by other distros that also have fixed release schedules (e.g. Fedora). For users, the rule of thumb is don't touch this in the first six weeks after the release if you're prudent because many severe bugs are discovered and/or fixed _after_ the release, not before it. Whether Debian's higher quality standards really compensate for the lack of up-to-dateness is another question, of course. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 02:21:09PM +0100, Bastian Venthur wrote: I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, What was the bug-fix rate for the last two releases? I thought that the bug fix rate for etch was faster than the rate for sarge. I also thought that we've been fixing them faster during this freeze than during etch. it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). Why won't fixing bugs faster work? stew signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Hi, Bastian Venthur wrote: Holger Levsen schrieb: Hi, On Montag, 15. Dezember 2008, Bastian Venthur wrote: Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. That's the way it is. Have you fixed an RC bug today or at least this week? I mean, are you contributing that this _temporarily disconnect_ is really temporarily? To be honest, I'm actually counterproductive by developing reportbug-ng, a tool which helps users to write bugreports instead of fixing them... ^ bad Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On 16/12/08 at 14:21 +0100, Bastian Venthur wrote: I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). So what's the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? I agree. It's clear that most people don't work on RC bugs instead of working on their packages: during freezes, they just stop working on Debian, since it's judged socially incorrect to work on one's packages in unstable or experimental during the freeze. We should really think of ways to allow people to continue improving unstable during freezes, while making sure that this doesn't affect the release (ie, lower buildd priority for unstable packages, for example). -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508891: ITP: lighty-stats -- httpd log analyzer
Hi Dne Tue, 16 Dec 2008 11:41:17 +0100 Maximilian Gaß m...@cloudconnected.org napsal(a): Package: wnpp Severity: wishlist Owner: Maximilian Gaß m...@cloudconnected.org * Package name: lighty-stats Version : 0.3 Upstream Author : Daniel Friesel d...@derf.homelinux.org * URL : https://derf.homelinux.org/~derf/lighty-stats 404 - Not Found I guess you mean https://derf.homelinux.org/~derf/projects/lighty-stats/ * License : ISC Programming Lang: Perl Description : httpd log analyzer lighty-stats is a lighttpd logfile analyzer written in perl Unlike most other tools it does not generate fancy HTMLs, but instead outputs the stats to STDOUT. Despite the name, it's not Lighttpd-specific but can parse all the Apache-like formats. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: problems with the concept of unstable - testing
Holger Levsen schrieb: Hi, On Montag, 15. Dezember 2008, Bastian Venthur wrote: Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. That's the way it is. Have you fixed an RC bug today or at least this week? I mean, are you contributing that this _temporarily disconnect_ is really temporarily? To be honest, I'm actually counterproductive by developing reportbug-ng, a tool which helps users to write bugreports instead of fixing them... Sarcasm aside, that is a question I hear very often when speaking about Lenny's release. It's like the sledgehammer argument, to silence those who dare to criticize. I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). So what's the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? I find it very strange to see people complaining about the long freeze, instead of working on making it shorter. I actually made a suggestion how to avoid a freeze in unstable, since looking at the length of the freeze times of the last two releases and the current one it seems that this model doesn't scale very well. I'm not going around, telling people hurry up, fix your bugs so we can release! I know that it will take a certain time to fix the current number and that's ok. I just don't want unstable to be frozen during this time. If we decouple the freeze from development in unstable, the result will that less people will be working on releasing, thus the freeze will take even longer. I don't know if that will happen, but I'm pretty sure that if we get an even longer unstable-freeze period in our next release, users will just walk away to a more modern distro. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508891: ITP: lighty-stats -- httpd log analyzer
Package: wnpp Severity: wishlist Owner: Maximilian Gaß m...@cloudconnected.org * Package name: lighty-stats Version : 0.3 Upstream Author : Daniel Friesel d...@derf.homelinux.org * URL : https://derf.homelinux.org/~derf/lighty-stats * License : ISC Programming Lang: Perl Description : httpd log analyzer lighty-stats is a lighttpd logfile analyzer written in perl Unlike most other tools it does not generate fancy HTMLs, but instead outputs the stats to STDOUT. Despite the name, it's not Lighttpd-specific but can parse all the Apache-like formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16, 2008 at 04:52:55PM +0100, Romain Beauxis wrote: Le Tuesday 16 December 2008 16:50:52 Adeodato Simó, vous avez écrit : Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? I don't read shorten in this link, only start. From that mail: So, we now have a discussion period of two weeks, though I would prefer to actually start the vote Sunday 00:00:00 UTC (on November 23th, or, if the DPL desires to shorten the discussion period, november 16th). We've had more than enough discussion about this - please start ASAP. I would hope that's clear enough from the context quoted: shorten the discussion == start ASAP. I did *not* explicitly ask for the voting period to be shortened. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On 16/12/08 at 09:46 -0500, Mike O'Connor wrote: What new graphics cards are supported by xorg 7.4 that arean't already supported by unstable? the intel, ati, radio, nv drivers don't support any newer cards afaict. Intel GM45 (found in laptops shipped since ~ september 2008) is unsupported in unstable/testing, works fine with experimental's X. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
On 16/12/08 at 14:34 +, Neil McGovern wrote: On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote: On 16/12/08 at 14:21 +0100, Bastian Venthur wrote: I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). So what's the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? I agree. It's clear that most people don't work on RC bugs instead of ^ working on their packages: during freezes, they just stop working on Debian, since it's judged socially incorrect to work on one's packages in unstable or experimental during the freeze. Could you justify those two please? I've seen no evidence, let alone any degree of clarity that supports the statement. clear that most people don't work on RC bugs instead of working on their packages: I don't have any data on that, it's mostly based on perception. Let's try to gather data on something relevant: Number of distinct posters per month on debian-bugs...@lists.d.o: 200801 944 200802 997 200803 1390 200804 1238 200805 1070 200806 1013 200807 1068 200808 1032 200809 975 200810 946 200811 724 200812 401 (partial results, obviously) So, the number of people working on RC bugs has significantly decreased since the beginning of the freeze. it's judged socially incorrect to work on one's packages in unstable or *experimental* during the freeze. I'm not sure if a difference is made between unstable and experimental by people complaining about people doing something else than fixing RC bugs. Is the concern purely technical, ie working on unstable packages makes thing harder for the release? Or social, ie you should work on the release instead of doing $FOO. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 2:06 PM, Yves-Alexis Perez cor...@debian.org wrote: On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. What are DICOM, ACR, NEMA, SPI? =O Those are extremely well know file format in the medical imaging world. Next time you go get an MRI / CT, ask for your DICOM CD with your images (in most countries, you do not get films anymore). ACR-NEMA used to refer to the previous standard (before DICOM 1993). And SPI is a proprietary format (used by Siemens/Philips) in pre 1993 PACS system. -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote: On 16/12/08 at 14:21 +0100, Bastian Venthur wrote: I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). So what's the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? I agree. It's clear that most people don't work on RC bugs instead of ^ working on their packages: during freezes, they just stop working on Debian, since it's judged socially incorrect to work on one's packages in unstable or experimental during the freeze. Could you justify those two please? I've seen no evidence, let alone any degree of clarity that supports the statement. Neil -- Yoe is _that_ gunnar? weasel yes Yoe what happened to his tires? towersbe He's shrunk. I think his wife washed him at too high a temperature. signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Hi! Bastian Venthur schrieb: Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. Sounds like what was done before testing was introduced, which worked even less, with even longer freeze periods, where you couldn't even upload to experimental. How does your proposal solve the issues we had back then? Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Quoting Bastian Venthur (vent...@debian.org): Is that important? Unstable is frozen for nearly 1/2 year now, that's a problem we should try to solve if we don't want to degrade ourselves to a server-only distribution. While I don't see such a big issues in this, there is maybe room for improvements for sure. It could be by promoting experimental a different way we are doing it right now...or by adding an intermediate stage between unstable and experimental. For that latter case, I somewhat fear the (human) resource problem we would end up with as it would need more people to take care of the whole mess^W organization. What I wanted to add also is that the problem pointed here does not only affect desktop environments as most contributors pointed. For instance, the samba packaging team is currently facing an interesting dilemna: - our upstream is now providing 3 different branches (3.0, 3.2, 3.3) - we have upstream 3.3.* series in experimental since upstream published the first pre-releases. This helps both our users and upstream to fiddle with brand new shiny features. As this is the version we'll want to ship with squeeze, it helps preparing the work. - we have upstream 3.2.* series in unstable/testing, as the normal path to have it in lenny. We will stop at 3.2.5, which is the version that will be shipped with lenny However, upstream released 3.2.6 a few days ago and will release more and more 3.2.* bugfixes only versions. Those however introduce too many changes for us to safely consider this for lenny. So, where could we upload up-to-date 3.2.* packages for the benefit of our users who prefer having the last bug fix releases? We can't do it in experimental as 3.3 is already using it. When lenny is released, backports.org is the appropriate place for this, imho. However, lenny-backports will only open when lenny is released and should indeed have packages backported from unstable at that moment. For us, that will be 3.3.* So, I had another idea: open foo-backports at the moment foo is frozen so that maintainers can upload the latest bleeding edge versions of their packages there, when using experimental is not possible for some reasons. Hopefully, that discussion (in backports-us...@lists.b.o) could lead to somethingwe'll see. signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Hi, Bastian Venthur wrote: What I'd like to see is a solution where unstable is *never* frozen, maybe by replacing the current frozen unstable with something temporary and putting it between unstable and testing, where all the fixes go while all the new stuff can still go into unstable but cannot enter the next step while we're in the freeze: Bastian, this is a brilliant idea!! Debian needs those excellent people like you who have splendid ideas and all ready to implement them!!! You are the most valuable person in Debian right now! Because you contribute a lot!!! You should start this super-unstable today!!! When it works out later, Debian should integrate it as official repository! Do not delay starting it! No one else in Debian has your brains, so no one else can do this!!! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
2008/12/16 Bastian Venthur vent...@debian.org: I actually made a suggestion how to avoid a freeze in unstable, since looking at the length of the freeze times of the last two releases and the current one it seems that this model doesn't scale very well. I share your concerns and I support your position too. I know many sid users that we must also care about, not only those using stable. Your proposal would help us to please both groups. Greetings, Miry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Thomas Viehmann wrote: Hi, Bastian Venthur wrote: What I'd like to see is a solution where unstable is *never* frozen Bastian, this is a brilliant idea!! Debian needs those excellent people like you who have splendid ideas and all ready to implement them!!! You are the most valuable person in Debian right now! Because you contribute a lot!!! You should start this super-unstable today!!! When it works out later, Debian should integrate it as official repository! Do not delay starting it! No one else in Debian has your brains, so no one else can do this!!! Kind regards T. Thomas, Many thanks for this constructive answer. I really appreciate the tone used and the fact that you seem to belittle the fight of ideas. No really, I love how people seem to think that if you think you can't work and if you work, you can't think. Or s/think/communicate your ideas/g Indulgent regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 06:48:08PM +0100, Thomas Viehmann wrote: Bastian, this is a brilliant idea!! Debian needs those excellent people like you who have splendid ideas and all ready to implement them!!! You are the most valuable person in Debian right now! Because you contribute a lot!!! You should start this super-unstable today!!! When it works out later, Debian should integrate it as official repository! Do not delay starting it! No one else in Debian has your brains, so no one else can do this!!! The strength of a community rests in its ability to work together as a group. I wish we could all show a bit more respect for each other on the mailing lists. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
2008/12/16 Thomas Viehmann t...@beamnet.de: Hi, Bastian Venthur wrote: What I'd like to see is a solution where unstable is *never* frozen, maybe by replacing the current frozen unstable with something temporary and putting it between unstable and testing, where all the fixes go while all the new stuff can still go into unstable but cannot enter the next step while we're in the freeze: Bastian, this is a brilliant idea!! Debian needs those excellent people like you who have splendid ideas and all ready to implement them!!! You are the most valuable person in Debian right now! Because you contribute a lot!!! You should start this super-unstable today!!! When it works out later, Debian should integrate it as official repository! Do not delay starting it! No one else in Debian has your brains, so no one else can do this!!! I don't think this kind of attitude helps anyone. Harassing people for having ideas different than yours will only make people to stop sharing them. We should seriously reconsider what kind of Debian we want. Seriously. On the proposal's side, I DO think it's a good idea, and it would be good to discuss it after the release, as someone proposed. Greetings, Miry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, 2008-12-16 at 13:38 +0100, Holger Levsen wrote: Hi, On Montag, 15. Dezember 2008, Bastian Venthur wrote: Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. Have you fixed an RC bug today or at least this week? I mean, are you contributing that this _temporarily disconnect_ is really temporarily? +1 /me shakes head. +1 Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Johannes Wiedersich wrote: Didier Raboud wrote: Yes. But there is a bunch of non-DD people that strongly want to use Debian and prefer the recent software over the stabilized one. These are called 'users of unstable' or 'users of testing'. Fair enough. With the new laptops coming out every two weeks, having the latest kernel, Xorg or hal is no caprice, it's needed⊠I think that the three existing flavours of debian already provide more than is needed to offer comfort for both users with stability needs and users with desire for new software. Actually, I would agree if you consider the 4th flavour: experimental. Just to name some important ones which are only there: OpenOffice.org, amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the freeze). Having the latest OO.o is more than confort… At the times of a freeze, I guess the available resources would be better spent on trying to keep that time as short as possible, instead of having to explain to users that there is one more section that they could use in their sources.list. I don't think that it only helps geeky users ot have one more section. My guess is that it'll help keeping the fun for the Developers as well… It would be great, if the remaining RC bugs were solved faster so that lenny could be released sooner, allowing newer versions in squeeze faster, allowing earlier testing of newer software, speeding up the release of squeeze, leading I agree that with a shorter freeze it would solve it all. Just don't forget that the amount of packages is growing faster than the number of workers (DD's) [not counting how many users flew to Ubuntu and that don't report and fix in Debian…]. So, the potential source of bugs is becoming bigger, while the forces to solve the issues is not (at least not fast enough). Thus the bigger freeze time. Another solution would be to reduce the number of packages, but this is reducing the fun (and the _universal_ity) too… With a less jungle experimental which you could trust as the unfrozen unstable or with a constantly unfrozen unstable, this would not be an issue. With a faster fixing of RC bugs and a faster release, all this would not be an issue. Agreed. But fixing RC bugs faster is not possible. You can't ask people to work more than their fun threshold. And with the low rate of new DD's compared to the high rate of new upstreams and ITP's and so the growing rate of new packages, and so the rate of bugs, I think that reducing the freeze time is not possible. So there is a need for something else. Cheers, Johannes - -- speaking as a user, who believes that debian's way is close to perfect for _both_ stability and new software. Thanks to all for their great work! Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, 2008-12-16 at 18:07 +0100, Lucas Nussbaum wrote: On 16/12/08 at 14:34 +, Neil McGovern wrote: On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote: On 16/12/08 at 14:21 +0100, Bastian Venthur wrote: I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we actually started the freeze with much more RC-bugs than before. So it was foreseeable that the freeze will take longer this time. We can't solve the problem by fixing bugs faster (that won't work anyways). So what's the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? I agree. It's clear that most people don't work on RC bugs instead of ^ working on their packages: during freezes, they just stop working on Debian, since it's judged socially incorrect to work on one's packages in unstable or experimental during the freeze. Could you justify those two please? I've seen no evidence, let alone any degree of clarity that supports the statement. clear that most people don't work on RC bugs instead of working on their packages: I don't have any data on that, it's mostly based on perception. Let's try to gather data on something relevant: Number of distinct posters per month on debian-bugs...@lists.d.o: 200801 944 200802 997 200803 1390 200804 1238 200805 1070 200806 1013 200807 1068 200808 1032 200809 975 200810 946 200811 724 200812 401 (partial results, obviously) So, the number of people working on RC bugs has significantly decreased since the beginning of the freeze. Or there are fewer and fewer bugs in Lenny ? Or have we returned to [winter|regular] bug rate ? Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 02:14:29PM +0100, Michael Hanke wrote: On Tue, Dec 16, 2008 at 02:06:40PM +0100, Yves-Alexis Perez wrote: On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. What are DICOM, ACR, NEMA, SPI? Medical image data formats. Given that the description should be appropriate for a potential user those names should be ok -- but Mac and Windows are surely not meaningful in this context. I also find of help having that info in the long description, and even part in the short one, so people is aware if they are not potential users. Something like Description: DICOM medical image files manipulation and conversion tools. Command line utilities for creating, modifying, dumping and validating files of DICOM attributes. Support conversion of some proprietary medical image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. -- Agustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Lucas Nussbaum lu...@lucas-nussbaum.net (16/12/2008): Number of distinct posters per month on debian-bugs...@lists.d.o: [ figures ] So, the number of people working on RC bugs has significantly decreased since the beginning of the freeze. The less RC bugs, the less people working on it. Nice point you made. Mraw, KiBi. signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
Romain Beauxis wrote: Honnestly, this discussion takes place at every freeze. As many others: firmware, dfsg-freeness, … ;) First of all, you probably should propose such thing *after* the release, not now. Secondly, I'm still wondering what new arguments were brought here. For instance, if you want to do a serious proposal, you probably could come up with links to previous discussions on the topic, and explain how that changed and how your point differs from the point already mentioned in the previous discussions. Until then, I don't really see the point in discussing this... Romain Agreed. That's what I think too : http://lists.debian.org/debian-devel/2008/12/msg00599.html Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Mon, Dec 15, 2008 at 10:16:05PM +0100, Bastian Venthur wrote: I support that request. Not only is unstable quite outdated already (bleeding edge?) it also becomes more and more a problem since the kernel and Xorg aren't updated anymore in unstable. That means that newer hardware (especially Laptops) don't fully work anymore (WLAN, Graphic, Sound). The latest alsa source is in unstable. 'm-a a-i alsa' would install it. What new graphics cards are supported by xorg 7.4 that arean't already supported by unstable? the intel, ati, radio, nv drivers don't support any newer cards afaict. Since we're making it very hard for our users to get their new hardware working seamlessly, unstable becomes more and more unattractive compared to other distributions. Is attracting users with brand new hardware to use unstable a goal of ours? Some suggest to cherry pick packages from experimental, but first some packages like the kernel aren't even available there The kernel is available elsewhere: http://kernel-archive.buildserver.net/ and second, since experimental is not part of the unstable testing stable flow, it has the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault. And officially we don't even recommend using unstable, aren't we? So for me that argument is invalid. If we don't recommend using unstable, doesn't that make YOUR argument invalid? stew signature.asc Description: Digital signature
Re: First call for votes for the Lenny release GR
On Mon, Dec 15, 2008 at 11:13:41AM -0800, Russ Allbery wrote: Adeodato Simó d...@net.com.org.es writes: What does §4.1.7 mean, then? Can't it be read to mean that the DPL may appoint a new Secretary not at end of term, if there's disagreement between them? I believe this only applies in the context of 7.2 (replacing the secretary). This was discussed some on debian-vote earlier. My reading of this is that 7.2 is an example or clarification of when 4.1.7 can be applied. If this is a bug in the constitution, or the original intention of it or not is open to debate, as is the interpretation of course. Neil -- Tolimar Debian women - porting the most succesfull operating system to the most unknown architecture signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Didier Raboud wrote: Romain Beauxis wrote: You can't get both recent *and* stabilized software. For a solid release to be done, one needs to hold new improvements for a while. Yes. But there is a bunch of non-DD people that strongly want to use Debian and prefer the recent software over the stabilized one. These are called 'users of unstable' or 'users of testing'. With the new laptops coming out every two weeks, having the latest kernel, Xorg or hal is no caprice, it's needed… I think that the three existing flavours of debian already provide more than is needed to offer comfort for both users with stability needs and users with desire for new software. At the times of a freeze, I guess the available resources would be better spent on trying to keep that time as short as possible, instead of having to explain to users that there is one more section that they could use in their sources.list. Just one example: IMHO it might be better to speed up the testing and fixing of bugs in the present kernel versions, instead of adding one more kernel version to the archives, that will have to be tested and fixed as well. I don't imply here that the kernel team or anyone else is doing a bad job. I just feel that if there is anything to improve it would be more efficient to just speed up existing work flows instead of _adding_ to the existing ones. That's not a problem from Debian stable users, who need a stable before all release. But for the FLOSS community and the geeky users, I guess that it is in fact a problem. It would be great, if the remaining RC bugs were solved faster so that lenny could be released sooner, allowing newer versions in squeeze faster, allowing earlier testing of newer software, speeding up the release of squeeze, leading With a less jungle experimental which you could trust as the unfrozen unstable or with a constantly unfrozen unstable, this would not be an issue. With a faster fixing of RC bugs and a faster release, all this would not be an issue. Cheers, Johannes - -- speaking as a user, who believes that debian's way is close to perfect for _both_ stability and new software. Thanks to all for their great work! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklHqdoACgkQC1NzPRl9qEXL3wCfQFo2ETzA5VeEasWgOwiQRa1D 5okAn1ol9z5Ff0htx5FLgTYSF2UZU/s8 =rOcY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Hi, On Montag, 15. Dezember 2008, Bastian Venthur wrote: Something like that, I don't really care about the name. The important thing is, that unstable is never frozen, but temporarily disconnected from the unstable testing stable flow. That's the way it is. Have you fixed an RC bug today or at least this week? I mean, are you contributing that this _temporarily disconnect_ is really temporarily? I find it very strange to see people complaining about the long freeze, instead of working on making it shorter. If we decouple the freeze from development in unstable, the result will that less people will be working on releasing, thus the freeze will take even longer. /me shakes head. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 02:06:40PM +0100, Yves-Alexis Perez wrote: On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. What are DICOM, ACR, NEMA, SPI? Medical image data formats. Given that the description should be appropriate for a potential user those names should be ok -- but Mac and Windows are surely not meaningful in this context. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On 16/12/08 at 19:15 +0100, Frank Lin PIAT wrote: On Tue, 2008-12-16 at 18:07 +0100, Lucas Nussbaum wrote: clear that most people don't work on RC bugs instead of working on their packages: I don't have any data on that, it's mostly based on perception. Let's try to gather data on something relevant: Number of distinct posters per month on debian-bugs...@lists.d.o: 200801 944 200802 997 200803 1390 200804 1238 200805 1070 200806 1013 200807 1068 200808 1032 200809 975 200810 946 200811 724 200812 401 (partial results, obviously) So, the number of people working on RC bugs has significantly decreased since the beginning of the freeze. Or there are fewer and fewer bugs in Lenny ? You might not be aware that debian-bugs-rc@ includes bugmail for all RC bugs, not just lenny's. Also, it's true that there are fewer RC bugs in lenny, but they are likely to be harder to fix, thus requiring more discussion. Or have we returned to [winter|regular] bug rate ? 2007 doesn't exhibit a similar behaviour. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Le Tuesday 16 December 2008 14:55:29 Didier Raboud, vous avez écrit : I think that the three existing flavours of debian already provide more than is needed to offer comfort for both users with stability needs and users with desire for new software. Actually, I would agree if you consider the 4th flavour: experimental. Just to name some important ones which are only there: OpenOffice.org, amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the freeze). Having the latest OO.o is more than confort… Honnestly, this discussion takes place at every freeze. First of all, you probably should propose such thing *after* the release, not now. Secondly, I'm still wondering what new arguments were brought here. For instance, if you want to do a serious proposal, you probably could come up with links to previous discussions on the topic, and explain how that changed and how your point differs from the point already mentioned in the previous discussions. Until then, I don't really see the point in discussing this... Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On mar, 2008-12-16 at 14:12 +0100, Mathieu Malaterre wrote: Those are extremely well know file format in the medical imaging world. Next time you go get an MRI / CT, ask for your DICOM CD with your images (in most countries, you do not get films anymore). It may be worth adding “medical imaging” somewhere in the long desc., because not everybody knows about that stuff. Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Adeodato Simó d...@net.com.org.es writes: * Russ Allbery [Mon, 15 Dec 2008 11:09:45 -0800]: Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? Yeah, sorry, he did indeed. Mea culpa; I was confusing discussion and vote in my head. Apologies for the resulting noise. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Miriam Ruiz wrote: I don't think this kind of attitude helps anyone. Harassing people for having ideas different than yours will only make people to stop sharing them. We should seriously reconsider what kind of Debian we want. Seriously. Yeah, my post was more than inappropriate. But while you bring it up: I want a Debian where every Developer can cough up a minimal commitment to help with releasing. That is what Have you fixed an RC bug today is about?. If all developers had fixed one RC bug in the months that we have been frozen, we would have run out. The other way round works, too: Removing people who don't have that minimal commitment from the project and their packages from the archive would also allow us to release (a lot less) in a timely fashion. Bastian's contributions have a theme of telling other people how to do work that he does not want to do: What information they should want in their bug reports, how to release, how negligent the assistant secretary is and why he is even doing the secretary's, and now what to do with unstable in the meantime (as other's have pointed out, not a new idea, so the contribution is rehasing of the idea). To be honest, I'd prefer if Bastian applied his skills to helping a project I'm not a member of. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Le Tuesday 16 December 2008 20:30:22 Thomas Viehmann, vous avez écrit : But while you bring it up: I want a Debian where every Developer can cough up a minimal commitment to help with releasing. That is what Have you fixed an RC bug today is about?. If all developers had fixed one RC bug in the months that we have been frozen, we would have run out. The other way round works, too: Removing people who don't have that minimal commitment from the project and their packages from the archive would also allow us to release (a lot less) in a timely fashion. I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. And I won't explain my reasons, it is private for me. However the packages are open for any contribution. Maybe yours ? Bastian's contributions have a theme of telling other people how to do work that he does not want to do: What information they should want in their bug reports, how to release, how negligent the assistant secretary is and why he is even doing the secretary's, and now what to do with unstable in the meantime (as other's have pointed out, not a new idea, so the contribution is rehasing of the idea). To be honest, I'd prefer if Bastian applied his skills to helping a project I'm not a member of. I don't agree with Bastian on his proposal but I would never express myself in that way. I won't fall into the easy agressive answer, but your attitude is clearly inapropriate. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Alexander wrote: Hi! Bastian Venthur schrieb: Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. Sounds like what was done before testing was introduced, which worked even less, with even longer freeze periods, where you couldn't even upload to experimental. How does your proposal solve the issues we had back then? I'm curious about that myself. We've tried that in the past, and a 3-year release cycle was what happened. Experience tells us that we have much too big a system to suddenly one day declare release without a lot of preparation beforehand. -- Steve McIntyre, Cambridge, UK.st...@einval.com I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Bastian Venthur wrote: Holger Levsen schrieb: I find it very strange to see people complaining about the long freeze, instead of working on making it shorter. I actually made a suggestion how to avoid a freeze in unstable, since looking at the length of the freeze times of the last two releases and the current one it seems that this model doesn't scale very well. I'm not going around, telling people hurry up, fix your bugs so we can release! I know that it will take a certain time to fix the current number and that's ok. I just don't want unstable to be frozen during this time. I'm curious - why do you think that our process can't scale for fixing bugs and releasing? There's plenty of scope for more people to join in and help fix them. Many people have, in fact, done so. I have a great deal of sympathy for Holger's attitude - an important part of Debian for me is achieving releases and I'd *hope* that most people would agree with that. -- Steve McIntyre, Cambridge, UK.st...@einval.com I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Steve McIntyre schrieb: Alexander wrote: Hi! Bastian Venthur schrieb: Another way to see it is that unstable is constantly flowing and we're just forking a stable distribution from it from time to time. Sounds like what was done before testing was introduced, which worked even less, with even longer freeze periods, where you couldn't even upload to experimental. How does your proposal solve the issues we had back then? I'm curious about that myself. We've tried that in the past, and a 3-year release cycle was what happened. Experience tells us that we have much too big a system to suddenly one day declare release without a lot of preparation beforehand. Actually, I don't know since I'm not long enough involved to know what happened back then. Did testing at some point in time fork from unstable and developed slowly into stable while unstable was still developing concurrently? Did uploads go directly to testing or to something before testing (like the current frozen unstable)? What was the problem that lead to a slow development back then? Was it that it was still possible to upload into unstable and so noone was actually interested in fixing RC bugs? What I see *now* is that the freezes during the last two and the current release are getting longer and longer (~1,5 months, ~4 months and for Lenny at least 5 months). For me this seems to be a serious problem we should not ignore. Important software is outdated in unstable and current hardware doesn't work anymore without resorting to grab packages from experimental or unofficial sources. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Romain Beauxis wrote: I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. How about once per year? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 08:30:22PM +0100, Thomas Viehmann wrote: But while you bring it up: I want a Debian where every Developer can cough up a minimal commitment to help with releasing. That is what Have you fixed an RC bug today is about?. If all developers had fixed one RC bug in the months that we have been frozen, we would have run out. Regardless of your wishes, the attitude you displayed in your previous email is actually detrimental to Debian and the community that other people work so hard to foster. I cannot see how you would think one justifies the other. The other way round works, too: Removing people who don't have that minimal commitment from the project and their packages from the archive would also allow us to release (a lot less) in a timely fashion. I think you need to read some of the stuff by Clay Shirky. He demonstrates that the power of new media and Internet based organisations such as the Linux developers, Debian, Flickr, Digg, and Wikipedia actually gain their massive organisational power by having close to zero barrier to entry for contributions from occasional users. When you look at the statistics for these groups you see majority overwhelming amount of work consists of one-time contributions, and the frequency of contribution increases in ever smaller amounts. By trying to artificially raise the barrier to entry for contributions to Debian, you would be inadvertently crippling one of the most crucial parts to its continued success. Bastian's contributions have a theme of telling other people how to do work that he does not want to do: What information they should want in their bug reports, how to release, how negligent the assistant secretary is and why he is even doing the secretary's, and now what to do with unstable in the meantime (as other's have pointed out, not a new idea, so the contribution is rehasing of the idea). To be honest, I'd prefer if Bastian applied his skills to helping a project I'm not a member of. I am not going to comment on his behaviour, your comments may very well be justified. But I do think it would do the project some good if we all learnt to embrace each others commitment levels, attitudes and opinions -- without resorting to rudeness, unkindness, or personal attacks. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote: Romain Beauxis wrote: I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. How about once per year? Kind regards people can decide to not contribute to a volunteer project for many reasons: hostile work environment, discouragement when expressing ideas are 2. A project as huge as Debian has a hard enough time keeping the 'fun' but making the atmostphere for people unplesent will not only discourage current people but also future contributer. -K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 12:29:21AM +0100, Didier Raboud wrote: Look for example at the upcoming KDE4.2 : KDE4.0 (public beta) went out in january 2008. Since then and 'because' of the unstable-to-testing pipe, KDE4.0 has only lived in experimental with the big fat blinking red WARNING sign above. KDE4 was then hard to test for testing users that don't play with apt-pinning and KDE4 will not be part of Lenny (even if it could…), roughly 15 months after its release. That's not a problem from Debian stable users, who need a stable before all release. But for the FLOSS community and the geeky users, I guess that it is in fact a problem. With a less jungle experimental which you could trust as the unfrozen unstable or with a constantly unfrozen unstable, this would not be an issue. Please, next time pick up an example you know better. KDE 4.0 totally belonged to experimental, 4.1 has never been uploaded to unstable because lenny was planned to be released with KDE 3.5, and even there was an update to this series a few months ago. Furthermore, Lenny users can test it from http://kde4.debian.net KDE 4.2 has not being release *yet*. I encourage you to (co)maintain packages in Debian. It will give you a better idea of how some stuff works and I think it could change some of the points of view I have read from you in this thread. Ana -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: Actually, I don't know since I'm not long enough involved to know what happened back then. It's called research. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote: On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: Actually, I don't know since I'm not long enough involved to know what happened back then. It's called research. It's called manners. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: Steve McIntyre schrieb: I'm curious about that myself. We've tried that in the past, and a 3-year release cycle was what happened. Experience tells us that we have much too big a system to suddenly one day declare release without a lot of preparation beforehand. Actually, I don't know since I'm not long enough involved to know what happened back then. Did testing at some point in time fork from unstable and developed slowly into stable while unstable was still Pretty much. What used to happen was that at some point the release manager decided to freeze unstable, creating a new distribution called frozen. This was a straight fork of unstable, there was no technical link between them once the fork was done. developing concurrently? Did uploads go directly to testing or to something before testing (like the current frozen unstable)? What was Uploads were done directly to frozen. Uploads could be done simultaneously to both (ie, you could upload to frozen unstable - you'll see such uploads in older changelogs) or to one distribution only. the problem that lead to a slow development back then? Was it that it was still possible to upload into unstable and so noone was actually interested in fixing RC bugs? Well, one of the problems was that you could end up with substantial divergence between the two distributions which tended to end up causing breakage so there was still some attempt to keep things broadly in sync. A search through the list archives from the time AJ introduced testing and after the first release using it should turn up plenty of discussion around the issue. What I see *now* is that the freezes during the last two and the current release are getting longer and longer (~1,5 months, ~4 months and for Lenny at least 5 months). For me this seems to be a serious problem we should not ignore. Important software is outdated in unstable and current hardware doesn't work anymore without resorting to grab packages from experimental or unofficial sources. Of course, these problems would all also apply to a frozen distribution like we used to have. My recollection of those times is that the long freezes we had back then had pretty similar effects on general development - the win from testing is in theory that testing should be in much better shape at any given moment than a random snapshot of unstable would be so we should have much more chance of getting the freeze over quickly. I certainly agree that we should be looking at ways of reducing the freeze time but I'm not sure that the freeze mechanism is an important factor in this. In terms of reducing the freeze time I think things like the availability of people willing to work on core packages is more of a limiting factor than anything else. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, 16 Dec 2008 15:55:40 -0500 Kevin Mark kevin.m...@verizon.net wrote: On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote: Romain Beauxis wrote: I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. How about once per year? Kind regards people can decide to not contribute to a volunteer project for many reasons: hostile work environment, discouragement when expressing ideas are 2. A project as huge as Debian has a hard enough time keeping the 'fun' but making the atmostphere for people unplesent will not only discourage current people but also future contributer. That works both ways - those who do contribute and help Debian across a wide range of areas should be valued and supported, even if they show that frustration from time to time. Everyone makes mistakes but why must the most active contributors be the first target of criticism when they criticise others who do little to help Debian? What about those who simply obstruct other developers? Isn't there any wider consideration that uploading packages that are unfit for purpose and refusing to fix problems identified by more active, more respected members is only going to frustrate those who do care? Those who criticise Thomas' reaction need to also consider the causes instead of only blaming one side of the issue. There are two sides to the argument and I've made my position clear already. [0] Where's the criticism of the original post that brings nothing useful or new to the discussion and comes from someone who has done nothing positive to further the release of Lenny? It's laughable. Why must we always blame the responder and not the initiator? Don't criticise unless you've done something positive - don't pick holes unless you have at least some *original* ideas that could help - don't pretend that you thought of something that has been discussed to death in the past. I get criticised for being rude or direct - well here's the news: I don't care if people think I'm rude, deal with it. At least I do what I can to fix stuff, I apologise when I do make mistakes and I do not recommend something I have not done myself. Would that more contributors were as active. BTW, I'm perfectly happy with the concept of unstable-testing with the ability to upload to experimental during the freeze. [1] Now is not the time to deal with the actual details but equally, now is the time everyone needs to support those who are actually doing the work, not those who just complain and obstruct those who would improve things. Maybe it is the people who only complain who should be criticised and thinking about retirement themselves. Overly long freezes are a pain but the solution is not to complain, the solution is to fix the RC bugs, help with the debian-installer, help with the translation team and get the release finished. That's what I'm trying to do, that's what Thomas was doing. Stop moaning. [0] http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/119-reportbug-ng-unfit-for-purpose-Absolutely..html (hmm, must do something about those extra long URLs!) [1] http://lists.debian.org/debian-mentors/2008/12/msg00180.html -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpULJXSQ98h7.pgp Description: PGP signature
Re: problems with the concept of unstable - testing
On Tue, 16 Dec 2008 21:41:58 + Noah Slater nsla...@tumbolia.org wrote: On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote: On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: Actually, I don't know since I'm not long enough involved to know what happened back then. It's called research. It's called manners. Yes, manners relating to actually thinking whether the idea has been considered before and typing something into Google? How hard is that? Manners involves consideration for others - that includes what is likely to have happened before some arbitrary point in time and considering that people more knowledgeable than yourself may just have considered the problem at some point before you became aware of the problem, maybe? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp5SpVqelzyO.pgp Description: PGP signature
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:57:15PM +, Neil Williams wrote: On Tue, 16 Dec 2008 21:41:58 + Noah Slater nsla...@tumbolia.org wrote: On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote: On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: Actually, I don't know since I'm not long enough involved to know what happened back then. It's called research. It's called manners. Yes, manners relating to actually thinking whether the idea has been considered before and typing something into Google? How hard is that? Manners involves consideration for others - that includes what is likely to have happened before some arbitrary point in time and considering that people more knowledgeable than yourself may just have considered the problem at some point before you became aware of the problem, maybe? Of course! I'm not going to argue with that. However, just because one person has made a faux pas, does not give blanket permission for other people to follow suit. This inevitably causes a chain reaction of rudeness and flames. As a community, we would do well to be a little more tolerant of others, and that includes their mistakes. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: What I see *now* is that the freezes during the last two and the current release are getting longer and longer (~1,5 months, ~4 months and for Lenny at least 5 months). For me this seems to be a serious problem we should not ignore. Important software is outdated in unstable and current hardware doesn't work anymore without resorting to grab packages from experimental or unofficial sources. Like your regression analysis of the bug closure rates, this is a facile analysis of the release process that shows you're lacking even a reasonable amount of historical context for the past two releases, let alone going back far enough to understand how the release process worked before testing was instituted. In particular, by looking only at the length of the full archive freeze, you have ignored: - the length of the release cycle as a whole - the length of the base freeze - the rate of RC bug churn - because the rate at which the RC bug count is reduced != the rate at which RC bugs are closed - the degree to which a freeze is effective at containing new RC bugs in unstable where they don't impact the upcoming release -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:46:41PM +, Mark Brown wrote: Of course, these problems would all also apply to a frozen distribution like we used to have. My recollection of those times is that the long freezes we had back then had pretty similar effects on general development - the win from testing is in theory that testing should be in much better shape at any given moment than a random snapshot of unstable would be so we should have much more chance of getting the freeze over quickly. Reading this (and following the idea of not introducing new stuff or archives but releasing faster) it sounds as simple as testing needs to be more strict and rigorous in accepting packages to be *indeed* always in a seriously better shape than unstable so that releases can be done with shorter freeze times, right? I certainly agree that we should be looking at ways of reducing the freeze time but I'm not sure that the freeze mechanism is an important factor in this. In terms of reducing the freeze time I think things like the availability of people willing to work on core packages is more of a limiting factor than anything else. Yep, maybe it's not the freeze time to be improved but the time before that... But to be clear, I don't have any suggestions for new rules for packages to get into lenny, unfortunately. Hauke signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
On Tue, 16 Dec 2008 21:58:52 + Noah Slater nsla...@tumbolia.org wrote: On Tue, Dec 16, 2008 at 09:53:58PM +, Neil Williams wrote: I get criticised for being rude or direct - well here's the news: I don't care if people think I'm rude, deal with it. At least I do what I can to fix stuff, I apologise when I do make mistakes and I do not recommend something I have not done myself. Would that more contributors were as active. I think you should care about upsetting people, and so should others. Well, that's your viewpoint - mine is different. I care about getting things done and helping people who are motivated, not those who only ever complain and obstruct wider development. When you work for an organisation like Debian, work? We're all volunteers and we have to motivate ourselves. People like Thomas motivate me to continue contributing. the community is the most valuable asset it has going for it. Rude and abrasive characters who contribute a lot of code, but who upset the community, waste time by drawing fire or starting flame wars, or scare away new contributers do not deserve to be excused for such behaviour. There has to be some support for those who come under fire despite being active contributors. If the community is left with inactive and inoffensive members who make no positive contributions, Debian itself will dissolve from the inside. Debian exists because things get done - eventually. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpvPb6sT3qV9.pgp Description: PGP signature
Re: problems with the concept of unstable - testing
Noah Slater nsla...@tumbolia.org wrote: Hi, suit. This inevitably causes a chain reaction of rudeness and flames. As a community, we would do well to be a little more tolerant of others, and that includes their mistakes. And that includes cutting some slack to people when they vent off, as people occasionally do. BTW, that community thing is really overrated and totally overinflated these days. Everybody refers to the community all the time for everything. It doesn't mean anything anymore. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 03:55:40PM -0500, Kevin Mark wrote: On Tue, Dec 16, 2008 at 09:34:39PM +0100, Thomas Viehmann wrote: Romain Beauxis wrote: I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. How about once per year? people can decide to not contribute to a volunteer project for many reasons: hostile work environment, discouragement when expressing ideas are 2. A project as huge as Debian has a hard enough time keeping the 'fun' but making the atmostphere for people unplesent will not only discourage current people but also future contributer. The single largest factor in making the atmosphere unpleasant is people who aren't contributing to Debian running their mouths on our development lists. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Jan Hauke Rahm i...@jhr-online.de wrote: Hi, Reading this (and following the idea of not introducing new stuff or archives but releasing faster) it sounds as simple as testing needs to be more strict and rigorous in accepting packages to be *indeed* always in a seriously better shape than unstable so that releases can be done with shorter freeze times, right? When testing was introduced, people moved from using unstable to using testing to get the latest and greatest. At that time, unstable was sometimes pretty wild, prone to serious breakages way more often that today (be it after a release - which was a horrible time, really - or during heavy development). Also new users have a tendency to go with testing and don't use unstable much these days. The net effect is that there aren't enough people left using unstable to uncover enough problems. Hence bugs silently make it to testing. Being stricter wrt testing migration is hardly going to help. What will help is having more people actually use unstable so bugs are uncovered before they hit testing. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 06:07:25PM +0100, Lucas Nussbaum wrote: clear that most people don't work on RC bugs instead of working on their packages: I don't have any data on that, it's mostly based on perception. Let's try to gather data on something relevant: Number of distinct posters per month on debian-bugs...@lists.d.o: [snip] So, the number of people working on RC bugs has significantly decreased since the beginning of the freeze. Accountable by ther being less RC bugs (obviously) and perhaps vote_002 and vote_003 taking up peoples time. it's judged socially incorrect to work on one's packages in unstable or *experimental* during the freeze. I'm not sure if a difference is made between unstable and experimental by people complaining about people doing something else than fixing RC bugs. Is the concern purely technical, ie working on unstable packages makes thing harder for the release? Or social, ie you should work on the release instead of doing $FOO. Work on very disruptive changes in unstable is discouraged as this may mean that packages which mean to go through to lenny aren't able to. The release team actively encourages the use of experimental to avoid these problems. I would also note that working on unstable != working on release. The RC bugs still need fixing. Neil -- * toresbe wonders what would happen if Ted Walther and Amaya were put in the same room Amaya toresbe: blood, sweat, tears and finally castration -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 09:53:58PM +, Neil Williams wrote: I get criticised for being rude or direct - well here's the news: I don't care if people think I'm rude, deal with it. At least I do what I can to fix stuff, I apologise when I do make mistakes and I do not recommend something I have not done myself. Would that more contributors were as active. I think you should care about upsetting people, and so should others. When you work for an organisation like Debian, the community is the most valuable asset it has going for it. Rude and abrasive characters who contribute a lot of code, but who upset the community, waste time by drawing fire or starting flame wars, or scare away new contributers do not deserve to be excused for such behaviour. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tuesday 16 December 2008 10:06, Romain Beauxis to...@rastageeks.org wrote: Is that important? Unstable is frozen for nearly 1/2 year now, that's a problem we should try to solve if we don't want to degrade ourselves to a server-only distribution. You can't get both recent *and* stabilized software. For a solid release to be done, one needs to hold new improvements for a while. I think it would be good if we could take time to stabilise the server version while continuing to work on development versions. The Fedora vs RHEL model that Red Hat uses has some benefits. If we were to follow that idea then we could skip most of the X stuff from the server variant. My observation is that it's pretty common to use GNOME and a KVM switch (or similar functionality such as HP ILO) to manage RHEL servers while for Debian servers most people just use command-line utilities with SSH. Note that I am not strongly advocating the Fedora vs RHEL model, because it does involve a moderate amount of extra work. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tuesday 16 December 2008 23:38, Holger Levsen hol...@layer-acht.org wrote: I find it very strange to see people complaining about the long freeze, instead of working on making it shorter. If we decouple the freeze from development in unstable, the result will that less people will be working on releasing, thus the freeze will take even longer. There are however some benefits to decoupling which can reduce the time taken to fix some bugs. If a package has a bug in testing but a newer version in unstable doesn't have the bug, then it makes it easier for the person who reports the bug to discover this fact and note it in the bug report. Then the maintainer can diff the packages to try and find the fix. This could in some situations allow the maintainer to fix a bug that they can't reproduce. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 11:22:29PM +0100, Julien BLACHE wrote: Being stricter wrt testing migration is hardly going to help. What will help is having more people actually use unstable so bugs are uncovered before they hit testing. Sounds reasonable... so, we have to encourage (competent) users to stick with sid and extensively report bugs which means to generally recommend sid for experienced users. Some might object but it could indeed shorten the freeze time since RC bugs would have been found much earlier. Hauke signature.asc Description: Digital signature
Bug#508955: ITP: php-kolab-filter -- Postfix filters for the Kolab server
Package: wnpp Severity: wishlist Owner: Mathieu Parent math.par...@gmail.com * Package name: php-kolab-filter Version : 0.1.3 Upstream Authors : * Gunnar Wrobel (Lead) * jarosch (Lead) * chuck (Lead) * Jan Schneider (Lead) * URL : http://pear.horde.org/index.php?package=Kolab_FreeBusy * License : LGPL Programming Lang: PHP Description : Postfix filters for the Kolab server I will clone this bug for all php-kolab-* packages -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Ana Guerrero wrote: On Tue, Dec 16, 2008 at 12:29:21AM +0100, Didier Raboud wrote: Look for example at the upcoming KDE4.2 : KDE4.0 (public beta) went out in january 2008. Since then and 'because' of the unstable-to-testing pipe, KDE4.0 has only lived in experimental with the big fat blinking red WARNING sign above. KDE4 was then hard to test for testing users that don't play with apt-pinning and KDE4 will not be part of Lenny (even if it could…), roughly 15 months after its release. That's not a problem from Debian stable users, who need a stable before all release. But for the FLOSS community and the geeky users, I guess that it is in fact a problem. With a less jungle experimental which you could trust as the unfrozen unstable or with a constantly unfrozen unstable, this would not be an issue. Please, next time pick up an example you know better. KDE 4.0 totally belonged to experimental, 4.1 has never been uploaded to unstable because lenny was planned to be released with KDE 3.5, and even there was an update to this series a few months ago. Furthermore, Lenny users can test it from http://kde4.debian.net KDE 4.2 has not being release *yet*. Point understood. I apologize for that. I encourage you to (co)maintain packages in Debian. It will give you a better idea of how some stuff works and I think it could change some of the points of view I have read from you in this thread. Ana Thanks for the encouragement. Didier -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
2008/12/17 Luca Niccoli lultimou...@gmail.com: But I use XFS, which seems to have some problems with d_type [1] I'm not really sure this is the source of the problem, but I thought it was worth giving a try... A second after posting I thought I could try mounting ~/.ssh on tmpfs for a test, and it worked. The problem seems to be with XFS indeed. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
2008/12/16 Luca Niccoli lultimou...@gmail.com: I can't really see what I'm doing wrong... Maybe I have a clue: ++file_filter(const struct dirent *dir) ++{ ++ return (DT_REG == (DT_REG dir-d_type)) || ++ (DT_LNK == (DT_LNK dir-d_type)) ; ++} But I use XFS, which seems to have some problems with d_type [1] I'm not really sure this is the source of the problem, but I thought it was worth giving a try... Cheers, Luca [1] http://nerdfortress.com/2008/09/19/linux-xfs-does-not-support-direntd_type/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Wed, Dec 17, 2008 at 09:31:13AM +1100, Russell Coker wrote: On Tuesday 16 December 2008 10:06, Romain Beauxis to...@rastageeks.org wrote: Is that important? Unstable is frozen for nearly 1/2 year now, that's a problem we should try to solve if we don't want to degrade ourselves to a server-only distribution. You can't get both recent *and* stabilized software. For a solid release to be done, one needs to hold new improvements for a while. I think it would be good if we could take time to stabilise the server version while continuing to work on development versions. The Fedora vs RHEL model that Red Hat uses has some benefits. The Fedora and RHEL is: Fedora: a somewhat equivalent of Debian Testing. The rules for updating a package even after a version is released are way more laxed than Debian Stable. RHEL: Much less software. You can't expect to maintain the whole archive of Debian Stable for 5 or 7 years without it. There are many packages I miss in the CentOS archive. Also note that none of those distribution has a distinction between server and desktop in the release cycle management. Ubuntu has a server variant, but it is merely a way to package different packages and defaults into the installation CD. RHEL has a distinction between server and desktop, but I figure that this is because supporting a server instance costs more (or that people are willing to pay more for it). This is somewhat like Ubuntu's LTS: it is a guarantee for 5 years, but only for Ubuntu's Main, and not for Ubuntu's Universe. And I figure that sure, the model of RHEL would work well for us. Only if the Stable release includes *my* pet packages. Just as much as: 'Sure we can release Lenny tommorow. Just as long as *my* pet bugs get fixed'. Regards, -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
Luca wrote: 2008/12/16 Luca Niccoli lultimou...@gmail.com: I can't really see what I'm doing wrong... Maybe I have a clue: ++file_filter(const struct dirent *dir) ++{ ++ return (DT_REG == (DT_REG dir-d_type)) || ++ (DT_LNK == (DT_LNK dir-d_type)) ; ++} But I use XFS, which seems to have some problems with d_type [1] I'm not really sure this is the source of the problem, but I thought it was worth giving a try... I don't know about the exact state today, but at least in the past many filesystems have not filled in d_type in readdir() calls. If you want to see the type of a filesystem object safely and portably, you'll need to call stat() or similar on each file. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
Le mardi 16 décembre 2008 à 23:55 +, Tzafrir Cohen a écrit : Fedora: a somewhat equivalent of Debian Testing. The rules for updating a package even after a version is released are way more laxed than Debian Stable. For what I’ve seen, Fedora rawhide is more similar to Debian experimental – and I don’t mean experimental as it is right now, as a replacement for unstable during the freeze. And I figure that sure, the model of RHEL would work well for us. Only if the Stable release includes *my* pet packages. Just as much as: 'Sure we can release Lenny tommorow. Just as long as *my* pet bugs get fixed'. Quite true indeed. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: problems with the concept of unstable - testing
Le mardi 16 décembre 2008 à 23:22 +0100, Julien BLACHE a écrit : Also new users have a tendency to go with testing and don't use unstable much these days. The net effect is that there aren't enough people left using unstable to uncover enough problems. Hence bugs silently make it to testing. Maybe that’s because I maintain packages with a large audience, but I don’t find that effect very important. More annoying are these effects: * Bugs that trigger with a specific combination of packages. In unstable they are fixed very quickly, but even when adding a Conflict, one of the packages can migrate to testing long before the others and keep testing in a broken state. * Testing users don’t check whether a bug is fixed in unstable. It’s not that bugs silently make it to testing, but they are fixed much more quickly in unstable. That could be improved with reportbug being stricter about bugs against testing packages with newer versions in unstable. Being stricter wrt testing migration is hardly going to help. What will help is having more people actually use unstable so bugs are uncovered before they hit testing. Actually I don’t think we should recommend testing at all to desktop users. Except during freeze times, I find unstable to be much more usable, and keep testing for (non-production) servers. However it is important to keep a large testing userbase, since developers don’t (at least, they aren’t supposed to) use it. Some bugs triggering with some package combinations only appear in testing and during the etch freeze, some very nasty bugs were detected this way. (This didn’t happen with lenny since unstable has remained almost the same as testing.) Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: problems with the concept of unstable - testing
Romain Beauxis to...@rastageeks.org (16/12/2008): I think you completely forgot about the fact that this project is run by people who aren't payed for that. They aren't paid for repeatedly ranting about the fact we have not released yet, either. Which is something Bastian does, and which is what was answered to. (And yes, I've been busy ranting lately, too, but I guess it's a bit of a different story.) And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. Why not documenting that in those bugreports so that people looking at them can see that (without having to notice it through the quotes by Raphael)? In addition to a quick mail to the bugs, you could tag them help, too. And I won't explain my reasons, it is private for me. Sure, However the packages are open for any contribution. Maybe yours ? but please communicate on their being open for contribution, especially because you won't be able to deal with them. Particularly helps debian-bugs-rc@ readers. Mraw, KiBi. signature.asc Description: Digital signature
Re: problems with the concept of unstable - testing
On Wed, Dec 17, 2008 at 01:17:33AM +0100, Josselin Mouette wrote: Le mardi 16 décembre 2008 à 23:55 +, Tzafrir Cohen a écrit : Fedora: a somewhat equivalent of Debian Testing. The rules for updating a package even after a version is released are way more laxed than Debian Stable. For what I’ve seen, Fedora rawhide is more similar to Debian experimental – and I don’t mean experimental as it is right now, as a replacement for unstable during the freeze. Just to clarify: I was relating to Fedora releases. I'll also point out that I'm not much familiar with Fedora. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Tue, Dec 16, 2008 at 4:34 PM, Josselin Mouette j...@debian.org wrote: Le mardi 16 décembre 2008 à 23:22 +0100, Julien BLACHE a écrit : Also new users have a tendency to go with testing and don't use unstable much these days. The net effect is that there aren't enough people left using unstable to uncover enough problems. Hence bugs silently make it to testing. Maybe that's because I maintain packages with a large audience, but I don't find that effect very important. More annoying are these effects: * Bugs that trigger with a specific combination of packages. In unstable they are fixed very quickly, but even when adding a Conflict, one of the packages can migrate to testing long before the others and keep testing in a broken state. * Testing users don't check whether a bug is fixed in unstable. It's not that bugs silently make it to testing, but they are fixed much more quickly in unstable. That could be improved with reportbug being stricter about bugs against testing packages with newer versions in unstable. Obviously, having more users test unstable is good. However, I agree that it's not necessarily a big issue. A good deal of RC-bugs are related to FTBFS, security advisories, package conflicts, and the like. These bugs can pop up independently of how much testing a package receives in unstable, so focusing on just increasing the number of unstable users would produce diminishing returns. Being stricter wrt testing migration is hardly going to help. What will help is having more people actually use unstable so bugs are uncovered before they hit testing. Actually I don't think we should recommend testing at all to desktop users. Except during freeze times, I find unstable to be much more usable, and keep testing for (non-production) servers. I think this is true as well, especially in the context of other non-Ubuntu distributions that track Debian. Sidux, which tracks Sid, is able to keep almost complete compatibility with the main Debian repositories with the exception of kernels. In contrast, distributions that track testing often have to have much more complete supplementary repositories. In part, this is due to ideological differences, but I think it's also due to the fact that desktop users can get more mileage from unstable. Cheers, Daniel -- Daniel Moerner dmoer...@gmail.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
On Wed, Dec 17, 2008 at 12:57 AM, Steve McIntyre st...@einval.com wrote: Luca wrote: 2008/12/16 Luca Niccoli lultimou...@gmail.com: I can't really see what I'm doing wrong... Maybe I have a clue: ++file_filter(const struct dirent *dir) ++{ ++ return (DT_REG == (DT_REG dir-d_type)) || ++ (DT_LNK == (DT_LNK dir-d_type)) ; ++} But I use XFS, which seems to have some problems with d_type [1] I'm not really sure this is the source of the problem, but I thought it was worth giving a try... Reading the man page of readdir you should alway test for DT_UNKNOWN, and fallback to stat if DT_UNKNOWN is set. And you should guard this test by #ifdef _DIRENT_HAVE_D_TYPE Moreover if you read getdents manpage, you will read that d_type is only filled since 2.6.4! In all the case I think we need to open a bug for getdents manpage it does not specify that d_type is DT_UNKNOW before 2.6.4 (backward compatibilty). I will fill a bug report. Perhaps filling a bug to manpage will be appropriate because wording is not clear. Please beware that they are issue with link and directory. Like for instance in http://mail.kde.org/pipermail/kdelibs-bugs/2008-March/001006.html d_type is an optimization not a thing that alway work. Bastien I don't know about the exact state today, but at least in the past many filesystems have not filled in d_type in readdir() calls. If you want to see the type of a filesystem object safely and portably, you'll need to call stat() or similar on each file. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
On Wed, Dec 17, 2008 at 2:11 AM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Wed, Dec 17, 2008 at 12:57 AM, Steve McIntyre st...@einval.com wrote: Luca wrote: 2008/12/16 Luca Niccoli lultimou...@gmail.com: I can't really see what I'm doing wrong... Maybe I have a clue: ++file_filter(const struct dirent *dir) ++{ ++ return (DT_REG == (DT_REG dir-d_type)) || ++ (DT_LNK == (DT_LNK dir-d_type)) ; ++} But I use XFS, which seems to have some problems with d_type [1] I'm not really sure this is the source of the problem, but I thought it was worth giving a try... Reading the man page of readdir you should alway test for DT_UNKNOWN, and fallback to stat if DT_UNKNOWN is set. And you should guard this test by #ifdef _DIRENT_HAVE_D_TYPE Moreover if you read getdents manpage, you will read that d_type is only filled since 2.6.4! In all the case I think we need to open a bug for getdents manpage it does not specify that d_type is DT_UNKNOW before 2.6.4 (backward compatibilty). I will fill a bug report. I should add that man page specify that DT_UNKNOW should be handled see http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html Perhaps filling a bug to manpage will be appropriate because wording is not clear. Please beware that they are issue with link and directory. Like for instance in http://mail.kde.org/pipermail/kdelibs-bugs/2008-March/001006.html d_type is an optimization not a thing that alway work. Bastien I don't know about the exact state today, but at least in the past many filesystems have not filled in d_type in readdir() calls. If you want to see the type of a filesystem object safely and portably, you'll need to call stat() or similar on each file. -- Steve McIntyre, Cambridge, UK. st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The firmware GR
On Mon, 15 Dec 2008, Ben Finney wrote: Romain Beauxis to...@rastageeks.org writes: Unfortunately you forgot to also mention this bug for instance: http://bugs.debian.org/494120 Which has been prematurely archived on 2008-08-15 while in mid-discussion, by one party in that discussion. Uh... it was archived on 2008/09/6 by the BTS itself after the bug had been closed on 2008/8/7 and the last message was on 2008/8/8. So no, it wasn't prematurely archived, and more than 28 days with no discussion certainly is not mid-discussion. Don Armstrong -- I was thinking seven figures, he said, but I would have taken a hundred grand. I'm not a greedy person. [All for a moldy bottle of tropicana.] -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.] http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: problems with the concept of unstable - testing
The other way round works, too: Removing people who don't have that minimal commitment from the project and their packages from the archive would also allow us to release (a lot less) in a timely fashion. Right... And it would also help releasing timely to remove all buggy packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: problems with the concept of unstable - testing
That works both ways - those who do contribute and help Debian across a wide range of areas should be valued and supported, even if they show that frustration from time to time. Everyone makes mistakes but why must the most active contributors be the first target of criticism when they criticise others who do little to help Debian? What about those who simply obstruct other developers? Isn't there any wider consideration that uploading packages that are unfit for purpose and refusing to fix problems identified by more active, more respected members is only going to frustrate those who do care? What packages do you have in mind? Where's the criticism of the original post that brings nothing useful or new to the discussion and comes from someone who has done nothing positive to further the release of Lenny? It's laughable. Why must we always blame the responder and not the initiator? Your questions assume several things I disagree with: the original post comes from someone who has done nothing positive to further the release of Lenny we always blame the responder and not the initiator Overly long freezes are a pain but the solution is not to complain, the solution is to fix the RC bugs, help with the debian-installer, help with the translation team and get the release finished. That's what I'm trying to do, that's what Thomas was doing. I didn't realize either mail did that. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: problems with the concept of unstable - testing
The single largest factor in making the atmosphere unpleasant is people who aren't contributing to Debian running their mouths on our development lists. I disagree, though I know relatively well how much people contribute. I'd rather blame the mailing lists if simple enthusiasts caused too much noise. What bores me more than non-contributors running their mouths is people choking during a marathon. http://lists.debian.org/debian-devel/2008/12/msg00229.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The firmware GR
Don Armstrong d...@debian.org writes: On Mon, 15 Dec 2008, Ben Finney wrote: Romain Beauxis to...@rastageeks.org writes: http://bugs.debian.org/494120 Which has been prematurely archived on 2008-08-15 while in mid-discussion, by one party in that discussion. Uh... it was archived on 2008/09/6 by the BTS itself after the bug had been closed on 2008/8/7 and the last message was on 2008/8/8. I checked carefully before sending the above message; the dates on the bug discussion and control messages *were* as I described. Yet today, they're as you describe. I have no ready explanation for that discrepancy. This thread certainly isn't the place to discuss strange observed debbugs behaviour, though, so I'll leave it at that for now. -- \ “I object to doing things that computers can do.” —Olin Shivers | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted moodle 1.8.2.dfsg-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 20:24:27 +1300 Source: moodle Binary: moodle Architecture: source all Version: 1.8.2.dfsg-1 Distribution: unstable Urgency: high Maintainer: Moodle Packaging Team moodle-packag...@catalyst.net.nz Changed-By: Francois Marier franc...@debian.org Description: moodle - Course Management System for Online Learning Closes: 507947 508593 Changes: moodle (1.8.2.dfsg-1) unstable; urgency=high . * Replace html2text with a GPL alternative (closes: #507947) * Fix XSS in the wiki module (CVE-2008-5432, closes: #508593) * Add Dan Poltawski to the uploaders field Checksums-Sha1: 550bd3e04422d3c9b28326febb5f43c5f8fa0dbe 1362 moodle_1.8.2.dfsg-1.dsc 28298d5b8916387091c2e411d6757c48669ae26a 10162497 moodle_1.8.2.dfsg.orig.tar.gz 69f8d7ae7e964477530e035fdd3c226f56992d79 33471 moodle_1.8.2.dfsg-1.diff.gz 8fba3fc32c66710516da323514b3523d3776175d 8720910 moodle_1.8.2.dfsg-1_all.deb Checksums-Sha256: 1ff40fb4cd5e799dd748ea2339322b9f5da1ee6f5adf1d8d1591f185e6efd018 1362 moodle_1.8.2.dfsg-1.dsc c67ebeba04320ab43f7ade9f1c685cfcdb327184428382c10b02fb4a2a76e7a2 10162497 moodle_1.8.2.dfsg.orig.tar.gz b1541914fa82591f7a34f1ef863444ec76ca9bf47c701b8b27b8c3ccb7e35a68 33471 moodle_1.8.2.dfsg-1.diff.gz f35a953425e8d6249d5e780acd6596b68acea826dd044a7b2f66ce14d13669c3 8720910 moodle_1.8.2.dfsg-1_all.deb Files: bcb0cfde4b6f1ca0766032ddd64266c0 1362 web optional moodle_1.8.2.dfsg-1.dsc d116f83641c70216a94168aa2c303004 10162497 web optional moodle_1.8.2.dfsg.orig.tar.gz 5741d3630ecfab96f43861853370281f 33471 web optional moodle_1.8.2.dfsg-1.diff.gz 7f49682873006f3145bc2ab5a815c8e5 8720910 web optional moodle_1.8.2.dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHWCgACgkQScUZKBnQNIa1KgCbBOMeRrzxNGwIPMh58NlwxaJd 4+AAnRfsv/yEnvWGuex+wDZqSjAKTa3X =tHi5 -END PGP SIGNATURE- Accepted: moodle_1.8.2.dfsg-1.diff.gz to pool/main/m/moodle/moodle_1.8.2.dfsg-1.diff.gz moodle_1.8.2.dfsg-1.dsc to pool/main/m/moodle/moodle_1.8.2.dfsg-1.dsc moodle_1.8.2.dfsg-1_all.deb to pool/main/m/moodle/moodle_1.8.2.dfsg-1_all.deb moodle_1.8.2.dfsg.orig.tar.gz to pool/main/m/moodle/moodle_1.8.2.dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted network-manager-applet 0.7.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 06:50:06 +0100 Source: network-manager-applet Binary: network-manager-gnome Architecture: source i386 Version: 0.7.0-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: network-manager-gnome - network management framework (GNOME frontend) Closes: 446963 458332 480039 482107 485651 494148 Changes: network-manager-applet (0.7.0-1) experimental; urgency=low . * New upstream release. - Notification popups can be disabled. (Closes: #446963) - Notification applet correctly handles panel restarts. (Closes:# 458332) - The nm-editor tool has been replaced by nm-connection-editor. (Closes: #494148, #482107, #485651) - Show the correct configuration for WPA Enterprise setups in nm-connection-editor (Closes: #480039) . [ Sjoerd Simons ] * debian/patches/02-nm-api-update.patch: - Removed. Fixed upstream * debian/control: Tighten build-depends on nm related libraries . [ Michael Biebl ] * debian/copyright - More updates to the copyright file. The polkit-helper bits are licensed under the LGPL. * debian/control - Add network-manager-pptp-gnome to Suggests. Checksums-Sha1: 76e8214534a04a849e37f77cfbad8db905ab1ea7 1761 network-manager-applet_0.7.0-1.dsc e402160b23a5d6e78978385f3c767fe8b401fe0e 1120090 network-manager-applet_0.7.0.orig.tar.gz 9d03e887225fb019bf950c45b694955d49f7fcee 5695 network-manager-applet_0.7.0-1.diff.gz a9b2facace856b6d4a81dc4799980b7a17f0aa02 648378 network-manager-gnome_0.7.0-1_i386.deb Checksums-Sha256: 12215187410266b6b775f21562598480acc89faa4a6bff2bd6273c6eb3755f9a 1761 network-manager-applet_0.7.0-1.dsc bee1dc341ac7c1506c2016980a0c4d35be35fbc90fbef1c8b454ea18b2f76013 1120090 network-manager-applet_0.7.0.orig.tar.gz 6d1f6ebd6d3bfd413daa592e338dbc10c72d01d197c58eaca4c6ec195652b650 5695 network-manager-applet_0.7.0-1.diff.gz 03fa4ca5daecd6127d284f2dd1d2712d5d59affe493d89e4c697832fb1c3ff24 648378 network-manager-gnome_0.7.0-1_i386.deb Files: d2f3e9dd99bef409ca3de1e3d87efd4f 1761 gnome optional network-manager-applet_0.7.0-1.dsc 7a30e9682ab2c83d8902c428d4e3d715 1120090 gnome optional network-manager-applet_0.7.0.orig.tar.gz 62474877edae93c082215c7d9f02a60b 5695 gnome optional network-manager-applet_0.7.0-1.diff.gz 0ae8f406d1620ca77b522fecd18c62d8 648378 gnome optional network-manager-gnome_0.7.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHcvoACgkQh7PER70FhVQEmwCfRlOhtYJSx7jDfeSAHx7t7F0/ +hUAoL/b8LE4v9/dsnEFnZAxdHn9Byji =I/oE -END PGP SIGNATURE- Accepted: network-manager-applet_0.7.0-1.diff.gz to pool/main/n/network-manager-applet/network-manager-applet_0.7.0-1.diff.gz network-manager-applet_0.7.0-1.dsc to pool/main/n/network-manager-applet/network-manager-applet_0.7.0-1.dsc network-manager-applet_0.7.0.orig.tar.gz to pool/main/n/network-manager-applet/network-manager-applet_0.7.0.orig.tar.gz network-manager-gnome_0.7.0-1_i386.deb to pool/main/n/network-manager-applet/network-manager-gnome_0.7.0-1_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted gsl 1.12+dfsg-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 06:17:55 -0600 Source: gsl Binary: libgsl0ldbl libgsl0-dev gsl-bin libgsl0-dbg libgsl0-prof Architecture: source i386 Version: 1.12+dfsg-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel e...@debian.org Changed-By: Dirk Eddelbuettel e...@debian.org Description: gsl-bin- GNU Scientific Library (GSL) -- binary package libgsl0-dbg - GNU Scientific Library (GSL) -- debug symbols package libgsl0-dev - GNU Scientific Library (GSL) -- development package libgsl0-prof - GNU Scientific Library (GSL) -- Profiling Libraries libgsl0ldbl - GNU Scientific Library (GSL) -- library package Changes: gsl (1.12+dfsg-1) unstable; urgency=low . * New upstream version released today . * doc/*: As before, removed the 'non-free' documentation to create a source package that complies with Debian's interpretation of what is free. Checksums-Sha1: 6a612f90b598bbc1b608a25ffbca6530ea35c1b4 1118 gsl_1.12+dfsg-1.dsc d02693f78e84613397128e5a17e3e77c4e0c172f 1889281 gsl_1.12+dfsg.orig.tar.gz 0406f064a35bcd88258457d861badc8d25aa 16783 gsl_1.12+dfsg-1.diff.gz 6ef99d9345b90052cbd213ba1189e8fa8ff40ec0 880030 libgsl0ldbl_1.12+dfsg-1_i386.deb ddc492591df3dde7a92b945ff1f3738ff3b1d4b0 1130688 libgsl0-dev_1.12+dfsg-1_i386.deb 34474da2e62905835a5f4c730c9c76b30a03c47d 28580 gsl-bin_1.12+dfsg-1_i386.deb 1e599ef53f84de9dbe61f4c552c66728a219f22c 1353204 libgsl0-dbg_1.12+dfsg-1_i386.deb Checksums-Sha256: fbab19b0cdcd2ad90041c81404d6c84dbd9d47467363a3f1f7acc5937dfa8c03 1118 gsl_1.12+dfsg-1.dsc fc7601192f55941c6991de11764f16d2aa8cb52e5a48c67cb8ba574839feb869 1889281 gsl_1.12+dfsg.orig.tar.gz 6e069e4c63bcd47163c2f1e91c74fa4c76007790e2012283fa8383106d6bb6df 16783 gsl_1.12+dfsg-1.diff.gz cde84ee498ba60e4ef8a4ac674c957e34fc13f9bdc0c1068b6ad89026201e565 880030 libgsl0ldbl_1.12+dfsg-1_i386.deb 1b7963888f2925c4498b04b6af8873c37b6f9e024e5d54279ba18f3cd94fec14 1130688 libgsl0-dev_1.12+dfsg-1_i386.deb 4e5da2db8f9d18c135926e5019d8618c18774447713ae79a0b7804823c24226e 28580 gsl-bin_1.12+dfsg-1_i386.deb 83431c452321dea929f51593ec9e4423f37b4c33a4cefcf810e127e624142c59 1353204 libgsl0-dbg_1.12+dfsg-1_i386.deb Files: 11268663292802d6d6fbbfa76afe472f 1118 math optional gsl_1.12+dfsg-1.dsc b8aedc4630c075a73b9f3686ce17a382 1889281 math optional gsl_1.12+dfsg.orig.tar.gz d91345209301e9f7cbd33966d4e38f7a 16783 math optional gsl_1.12+dfsg-1.diff.gz 0bfc820c9bf22310015b31d20d32effa 880030 math optional libgsl0ldbl_1.12+dfsg-1_i386.deb 12cba3b72eb5fcbd33fe0fc9713e81e5 1130688 libdevel optional libgsl0-dev_1.12+dfsg-1_i386.deb d8d6b2f2797fb6578f2c8fb4a96043a8 28580 math optional gsl-bin_1.12+dfsg-1_i386.deb f0eacaa6aec5f4c8cd5a7074f9632e18 1353204 libdevel extra libgsl0-dbg_1.12+dfsg-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD4DBQFJR54cCZSR95Gw07cRAsSNAJoD/iIcmgje/VQwJ65JzyxzQnJT/ACYuj6D cnP13oHhN+bQUkeLRMdSew== =3bXU -END PGP SIGNATURE- Accepted: gsl-bin_1.12+dfsg-1_i386.deb to pool/main/g/gsl/gsl-bin_1.12+dfsg-1_i386.deb gsl_1.12+dfsg-1.diff.gz to pool/main/g/gsl/gsl_1.12+dfsg-1.diff.gz gsl_1.12+dfsg-1.dsc to pool/main/g/gsl/gsl_1.12+dfsg-1.dsc gsl_1.12+dfsg.orig.tar.gz to pool/main/g/gsl/gsl_1.12+dfsg.orig.tar.gz libgsl0-dbg_1.12+dfsg-1_i386.deb to pool/main/g/gsl/libgsl0-dbg_1.12+dfsg-1_i386.deb libgsl0-dev_1.12+dfsg-1_i386.deb to pool/main/g/gsl/libgsl0-dev_1.12+dfsg-1_i386.deb libgsl0ldbl_1.12+dfsg-1_i386.deb to pool/main/g/gsl/libgsl0ldbl_1.12+dfsg-1_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted python-soappy 0.12.0-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 29 Nov 2008 20:20:44 +0100 Source: python-soappy Binary: python-soappy Architecture: source all Version: 0.12.0-4 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Changed-By: Bernd Zeimetz b...@debian.org Description: python-soappy - SOAP Support for Python Closes: 498928 Changes: python-soappy (0.12.0-4) unstable; urgency=low . * Restructuring the two patches which both touched the 'from future' imports, removing all of them now. That really closes: #498928 now. Checksums-Sha1: 96999f9f50e557db903155e338d7087dff95fa8c 1398 python-soappy_0.12.0-4.dsc cb251bb36b001189b1c7a4f1fa6374b85c1d6b1d 6449 python-soappy_0.12.0-4.diff.gz 47c2f204bf89ae8eb9d184337ab21b46efb857ef 128672 python-soappy_0.12.0-4_all.deb Checksums-Sha256: 45f8b0e0532622e7be429aae911c57f8c9db44d0797f5c7065f4a898a6842eb9 1398 python-soappy_0.12.0-4.dsc c412ba9175d8282ce24ce32b19a384006475f0b990f0e4087d56fe60eedca939 6449 python-soappy_0.12.0-4.diff.gz 647f983eaffca1ce621b05a841fa5f2fefc2cad98a7ed705ddc3eb45e709d0dd 128672 python-soappy_0.12.0-4_all.deb Files: b4bfa6390174d82db4569a0d688685d9 1398 python optional python-soappy_0.12.0-4.dsc b7574745c985945c0532a6608822452f 6449 python optional python-soappy_0.12.0-4.diff.gz a6562d1c08e70f99964bae8e89c8f057 128672 python optional python-soappy_0.12.0-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHuF0ACgkQBnqtBMk7/3n8PgCfdH7pKKmesLRmJyfSfE4etLf3 SgMAnRRGJV/yVvG+3crTAui8jxRCKPQe =nTJv -END PGP SIGNATURE- Accepted: python-soappy_0.12.0-4.diff.gz to pool/main/p/python-soappy/python-soappy_0.12.0-4.diff.gz python-soappy_0.12.0-4.dsc to pool/main/p/python-soappy/python-soappy_0.12.0-4.dsc python-soappy_0.12.0-4_all.deb to pool/main/p/python-soappy/python-soappy_0.12.0-4_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ftp.app 0.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Fri, 05 Dec 2008 13:22:47 +0100 Source: ftp.app Binary: ftp.app Architecture: source i386 Version: 0.2-1 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün gur...@phys.ethz.ch Changed-By: Gürkan Sengün gur...@phys.ethz.ch Description: ftp.app- File transfer protocol application for GNUstep Changes: ftp.app (0.2-1) unstable; urgency=low . * New upstream version. * Update my email address. * Update debian/copyright. * Add GNUstep maintainers to Uploaders in debian/control. Checksums-Sha1: 6f1d2e48183d8a50956fb2451bfce08b9ed26fae 1107 ftp.app_0.2-1.dsc 05a8899ce7daade13c5a1d0b0bba73401f75bbfa 105516 ftp.app_0.2.orig.tar.gz 4654a06f094516794742a2b21d702f0687c0 2647 ftp.app_0.2-1.diff.gz 737f4c0408838bc1247892bc0af117027cb2438c 56594 ftp.app_0.2-1_i386.deb Checksums-Sha256: d4dfdff0a23fc69b9893df8dc70c9c36c12753c1143efa7ead7aebe7722fa2bb 1107 ftp.app_0.2-1.dsc 54b0f60fe990c47e0dcc065824706f7149599fc7ce00470476b343a73e076e0c 105516 ftp.app_0.2.orig.tar.gz 842961c98a452d45383584d6432d3cbde8be01770cfd73a44b9b2e42fe6fb0fa 2647 ftp.app_0.2-1.diff.gz 4270565889f7f4ffda076096bf838f8ef9e9e8187a65af616c34a16c790c023a 56594 ftp.app_0.2-1_i386.deb Files: 045d4627113c7acb3833fe17216278a1 1107 net optional ftp.app_0.2-1.dsc ee5d52ecf426b69b6553b52978054dec 105516 net optional ftp.app_0.2.orig.tar.gz 160943544ca6d00356c65b6cdbb812ec 2647 net optional ftp.app_0.2-1.diff.gz 0b1f36f3b0cb0b9b91b5b64382854f32 56594 net optional ftp.app_0.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJR6qNrynHGRJLYfoRAyF5AJ9GoqP96Qm1oRcRv3UtKBZnAf2LEgCfZEYF eAIlwLEpLg3X++G89fwQxRc= =CbvM -END PGP SIGNATURE- Accepted: ftp.app_0.2-1.diff.gz to pool/main/f/ftp.app/ftp.app_0.2-1.diff.gz ftp.app_0.2-1.dsc to pool/main/f/ftp.app/ftp.app_0.2-1.dsc ftp.app_0.2-1_i386.deb to pool/main/f/ftp.app/ftp.app_0.2-1_i386.deb ftp.app_0.2.orig.tar.gz to pool/main/f/ftp.app/ftp.app_0.2.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted initramfs-tools 0.92m (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 16:01:44 +0100 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.92m Distribution: unstable Urgency: medium Maintainer: Debian kernel team debian-ker...@lists.debian.org Changed-By: maximilian attems m...@debian.org Description: initramfs-tools - tools for generating an initramfs Closes: 426465 502056 502058 503216 504555 505440 507059 507619 Changes: initramfs-tools (0.92m) unstable; urgency=medium . [ Colin Watson ] * scripts/functions: Call ipconfig with a one-minute timeout. * Make debug option write to /dev/.initramfs/initramfs.debug, so that it can be retrieved after boot. . [ Julien Danjou ] * scripts/functions: Wrong check for udevadm in functions. (closes: #507059) . [ maximilian attems ] * scripts/functions: fix not set break variable. (closes: #502058) * MODULES=dep fix for ida devices. * hook-functions: alphebetize net drivers, fix typhoon typo. * Add atl1e, cxgb, ixgb, ixgbe, mlx4_core, netxen_nic, sfc, tehuti to net module list. (closes: #503216) * nuke 0.92k goof clean up. * postrm: set -e flag. * Revert framebuffer: Let udev create fb devices. * scripts/functions: comment fix path to moved linux-2.6 Documentation. * init: Don't leak initramfs-tools exported variables. (closes: #426465, #505440) . [ dann frazier ] * Fix MODULES=dep for cciss devices. (closes: #507619) . [ Michal Pokrywka ] * framebuffer: Add support for uvesafb. (closes: #502056) . [ Andres Salomon ] * fix redboot partition support. (closes: #504555) Checksums-Sha1: 702a221cda8521293cc4f4a6b7f3ae7dbf293f73 1004 initramfs-tools_0.92m.dsc beb9f30b6faf92ced331b8b68883c2dd0e344428 68035 initramfs-tools_0.92m.tar.gz 674de477133f0a777c655dda29dfa09475ae3b3e 74958 initramfs-tools_0.92m_all.deb Checksums-Sha256: db2603b500bb231840c51a328ce778e1058ff42b8776b85e0e67ab633b5ca099 1004 initramfs-tools_0.92m.dsc 8978327526fc60e5d8ce03fa1abfbc66c57850800cae5b78838018c6c3a85cb4 68035 initramfs-tools_0.92m.tar.gz 319731ec24a4d819985424e4ccd4c047f6c809084982a091baf45712c32c7c67 74958 initramfs-tools_0.92m_all.deb Files: 38551370f0e1471b0d98e5a6c150d08a 1004 utils optional initramfs-tools_0.92m.dsc f5abdcdcce11c76d5c56c3480da884b9 68035 utils optional initramfs-tools_0.92m.tar.gz 4194efef739007352dba29ddc51a4abb 74958 utils optional initramfs-tools_0.92m_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHxQAACgkQeW7Lc5tEHqhy8ACfVpYJICSK1g8Q5UJlXEzQcOKT s7QAoKAdT3zEX83hdT06im7Up8+BqtGT =hhrO -END PGP SIGNATURE- Accepted: initramfs-tools_0.92m.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.92m.dsc initramfs-tools_0.92m.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.92m.tar.gz initramfs-tools_0.92m_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.92m_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted libmodule-corelist-perl 2.15-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 14:42:38 +0200 Source: libmodule-corelist-perl Binary: libmodule-corelist-perl Architecture: source all Version: 2.15-3 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Damyan Ivanov d...@debian.org Description: libmodule-corelist-perl - what modules shipped with versions of perl Closes: 508876 Changes: libmodule-corelist-perl (2.15-3) unstable; urgency=low . [ gregor herrmann ] * debian/control: Changed: Switched Vcs-Browser field to ViewSVN (source stanza). . [ Damyan Ivanov ] * add fix_missing-EU-Miniperl.patch, adding ExtUtils::Miniperl to the list of core Perl modules. (Closes: #508876) + include quilt in the build process * add myself to Uploaders * Bump Standards-Version to 3.8.0 + add README.source because of quilt usage Checksums-Sha1: b983f6852d073895d65c474fc8e9b9397d000502 1588 libmodule-corelist-perl_2.15-3.dsc d61ed75575c6a140e6a4ece242a11bb2561b8fe7 3944 libmodule-corelist-perl_2.15-3.diff.gz f562faaec92bf5c419c2b970dd9f2525bf73b99d 51124 libmodule-corelist-perl_2.15-3_all.deb Checksums-Sha256: dad9bfad9c7d390cd8d98f9746577bdb08d50aca9b73f2a39b1bdfb2f7efa1ce 1588 libmodule-corelist-perl_2.15-3.dsc 29dcae3782461b24766f824540861b962c0c52e1c343116bc3cb2abae17d3093 3944 libmodule-corelist-perl_2.15-3.diff.gz 6ea4ee7959b0cb88522a6a22d8ee0941c103def93e76028aef8a492979a82fa2 51124 libmodule-corelist-perl_2.15-3_all.deb Files: 82e4f747893d38843445f2b49dacbefe 1588 perl optional libmodule-corelist-perl_2.15-3.dsc 4134823f34a515645705323cb229e702 3944 perl optional libmodule-corelist-perl_2.15-3.diff.gz 993293a3223be3153e8fcbe8eca4b425 51124 perl optional libmodule-corelist-perl_2.15-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHo3sACgkQHqjlqpcl9judVQCeIV2OspiI7+S9Q3Iq6awaMx3c kQgAoIqJSUTCJLTDQkpQVjrclDuol932 =fw5p -END PGP SIGNATURE- Accepted: libmodule-corelist-perl_2.15-3.diff.gz to pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.15-3.diff.gz libmodule-corelist-perl_2.15-3.dsc to pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.15-3.dsc libmodule-corelist-perl_2.15-3_all.deb to pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.15-3_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted openerp-server 5.0.0~rc1.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 13:08:00 +0100 Source: openerp-server Binary: openerp-server Architecture: source all Version: 5.0.0~rc1.1-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann dan...@debian.org Changed-By: Daniel Baumann dan...@debian.org Description: openerp-server - Enterprise Resource Management (server) Changes: openerp-server (5.0.0~rc1.1-1) unstable; urgency=low . * Merging upstream version 5.0.0~rc1.1. Checksums-Sha1: 8bee56710243185906d0efb24e40077b5cb94266 1290 openerp-server_5.0.0~rc1.1-1.dsc 23910d0f8c33dc7ce3315d4ad7bc9af181a8c4aa 7401334 openerp-server_5.0.0~rc1.1.orig.tar.gz 2692333afae2579f701617544ae20816152d1d3f 9354 openerp-server_5.0.0~rc1.1-1.diff.gz 417f25a2fce5cd7b86a98c45b311029b34f87ef7 14878278 openerp-server_5.0.0~rc1.1-1_all.deb Checksums-Sha256: c73b9b10703ce295e8fca87346fe05a5044d17f5a1db6d398227ff19f73c7c83 1290 openerp-server_5.0.0~rc1.1-1.dsc 1322f7ada58c1a208a7df1dfe92ccc8a689e819c53f048977801bd83063f2cb8 7401334 openerp-server_5.0.0~rc1.1.orig.tar.gz 343415e034969913ce8a70a077daf443b73d5cc7d0a384ecdb8157a876da9c90 9354 openerp-server_5.0.0~rc1.1-1.diff.gz 82dbe59e6d0f2665f1a44f0ef51cbdce8f8a3ce7c64be356630ca068677e3426 14878278 openerp-server_5.0.0~rc1.1-1_all.deb Files: 9f7555b12f231674f937e57f3710ac24 1290 net optional openerp-server_5.0.0~rc1.1-1.dsc 5daf2c2bbe738853fe69823194ab75df 7401334 net optional openerp-server_5.0.0~rc1.1.orig.tar.gz 9b823ee5ef39180dc0ccb43c28ee8d30 9354 net optional openerp-server_5.0.0~rc1.1-1.diff.gz 8a1531c1f1e5475c2da6a3268dcbedc1 14878278 net optional openerp-server_5.0.0~rc1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHmrMACgkQ+C5cwEsrK57CFQCeIvJcaDVuHBAq13wtgojWsbfg Sq4AoKf6bv16N6McOSYb4i67Yu8ZeXjB =dqNR -END PGP SIGNATURE- Accepted: openerp-server_5.0.0~rc1.1-1.diff.gz to pool/main/o/openerp-server/openerp-server_5.0.0~rc1.1-1.diff.gz openerp-server_5.0.0~rc1.1-1.dsc to pool/main/o/openerp-server/openerp-server_5.0.0~rc1.1-1.dsc openerp-server_5.0.0~rc1.1-1_all.deb to pool/main/o/openerp-server/openerp-server_5.0.0~rc1.1-1_all.deb openerp-server_5.0.0~rc1.1.orig.tar.gz to pool/main/o/openerp-server/openerp-server_5.0.0~rc1.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted openerp-client 5.0.0~rc1.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 13:19:00 +0100 Source: openerp-client Binary: openerp-client Architecture: source all Version: 5.0.0~rc1.1-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann dan...@debian.org Changed-By: Daniel Baumann dan...@debian.org Description: openerp-client - Enterprise Resource Management (client) Changes: openerp-client (5.0.0~rc1.1-1) unstable; urgency=low . * Merging upstream version 5.0.0~rc1.1. Checksums-Sha1: 10980d49b297032866e24681f9fafd6f4e9bbb22 1266 openerp-client_5.0.0~rc1.1-1.dsc 1d664e0f701a1ecbb4e7d9969fc9dc12a424a245 958754 openerp-client_5.0.0~rc1.1.orig.tar.gz b2581b5088d66889ea324a4d7997cf911dce5012 4634 openerp-client_5.0.0~rc1.1-1.diff.gz 8a40fc4cf35d97fe7f982e0401311cbdf9777dba 433228 openerp-client_5.0.0~rc1.1-1_all.deb Checksums-Sha256: 8a9c5724c2107ca2d63aeee359294a8943931c50b427ac1348545c02f2c68506 1266 openerp-client_5.0.0~rc1.1-1.dsc ce6903ff4755ebbc641326996bfc0a67462722900ee96fa6d423094c5f2b4dde 958754 openerp-client_5.0.0~rc1.1.orig.tar.gz cb779454983649ee682949d3ecce7dc588a650ce873491c0d176c75038b3f4a6 4634 openerp-client_5.0.0~rc1.1-1.diff.gz 55de769dc31c1fcd1f2d61b35dedd6a33ceec8104bfda9d9ff675373fece894f 433228 openerp-client_5.0.0~rc1.1-1_all.deb Files: 9e2031f0d09edb07fa1a6fe6df21a4f5 1266 x11 optional openerp-client_5.0.0~rc1.1-1.dsc e52ffece7ca5b73f9c1ebdf655cef44e 958754 x11 optional openerp-client_5.0.0~rc1.1.orig.tar.gz 2e26096bd7605c900fc3dc6932fd772f 4634 x11 optional openerp-client_5.0.0~rc1.1-1.diff.gz 006f8e32ab2d5d81506192198bde32d6 433228 x11 optional openerp-client_5.0.0~rc1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHnRkACgkQ+C5cwEsrK55SqACeLPSQnOfByokqezaRE2KZYz9+ zMYAoJAZZhaJxXCtpddasJYwVO+ojkfi =2BCs -END PGP SIGNATURE- Accepted: openerp-client_5.0.0~rc1.1-1.diff.gz to pool/main/o/openerp-client/openerp-client_5.0.0~rc1.1-1.diff.gz openerp-client_5.0.0~rc1.1-1.dsc to pool/main/o/openerp-client/openerp-client_5.0.0~rc1.1-1.dsc openerp-client_5.0.0~rc1.1-1_all.deb to pool/main/o/openerp-client/openerp-client_5.0.0~rc1.1-1_all.deb openerp-client_5.0.0~rc1.1.orig.tar.gz to pool/main/o/openerp-client/openerp-client_5.0.0~rc1.1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted openerp-server 5.0.0~rc1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 12:51:00 +0100 Source: openerp-server Binary: openerp-server Architecture: source all Version: 5.0.0~rc1-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann dan...@debian.org Changed-By: Daniel Baumann dan...@debian.org Description: openerp-server - Enterprise Resource Management (server) Changes: openerp-server (5.0.0~rc1-1) unstable; urgency=low . * Merging upstream version 5.0.0~rc1. * Removing openerp.dpatch, went upstream. * Rediffing shebang.dpatch. * Removing workaround for import_xml.rng, not needed anymore. Checksums-Sha1: 472eebfdb838ce2ace706792581ef0aa0c0861d7 1276 openerp-server_5.0.0~rc1-1.dsc f8692be8def3be14d44fd0319967f1f4578d6716 6796770 openerp-server_5.0.0~rc1.orig.tar.gz 7c512e45b2de63f791c5fbaaf57d6805ac2eb8cb 9336 openerp-server_5.0.0~rc1-1.diff.gz 006a3b49ddef6724886b95af3ccd655e05c0ad88 2330238 openerp-server_5.0.0~rc1-1_all.deb Checksums-Sha256: b10e38b8f88097956b1418b724582fa4922e784522500af6c6f1961448ec8481 1276 openerp-server_5.0.0~rc1-1.dsc 2e07507bc0fa632847f0d328d469b162014dca90d722522b5278083b815b0ef2 6796770 openerp-server_5.0.0~rc1.orig.tar.gz 2ca99398bf115ce5b034b03f998933752971327ea0fbefaad7b4285d300b5b84 9336 openerp-server_5.0.0~rc1-1.diff.gz 96321b6a10172b7815eed4db40f3cdf9fb9ca6aefaab1c793f5bf44ac2d8ebfc 2330238 openerp-server_5.0.0~rc1-1_all.deb Files: bb18b7bd6e870df3c97ac9ec5ab05b34 1276 net optional openerp-server_5.0.0~rc1-1.dsc 1cac7cec928090b8995210f1c9726bf5 6796770 net optional openerp-server_5.0.0~rc1.orig.tar.gz f8e5bce38a2e0fd283d60b518ad60f1c 9336 net optional openerp-server_5.0.0~rc1-1.diff.gz acc238f12577eac1d88eff19748e70bd 2330238 net optional openerp-server_5.0.0~rc1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklHlowACgkQ+C5cwEsrK55S2gCg4J9N/35/4CMndBgVu2Tt2c3h f08AnRC7wJBoJ2jENPaEyd1FIkXcxuMl =ePug -END PGP SIGNATURE- Accepted: openerp-server_5.0.0~rc1-1.diff.gz to pool/main/o/openerp-server/openerp-server_5.0.0~rc1-1.diff.gz openerp-server_5.0.0~rc1-1.dsc to pool/main/o/openerp-server/openerp-server_5.0.0~rc1-1.dsc openerp-server_5.0.0~rc1-1_all.deb to pool/main/o/openerp-server/openerp-server_5.0.0~rc1-1_all.deb openerp-server_5.0.0~rc1.orig.tar.gz to pool/main/o/openerp-server/openerp-server_5.0.0~rc1.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted xcb-util 0.3.2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Dec 2008 14:47:17 +0100 Source: xcb-util Binary: libxcb-atom1 libxcb-atom1-dev libxcb-aux0 libxcb-aux0-dev libxcb-event1 libxcb-event1-dev libxcb-image0 libxcb-image0-dev libxcb-keysyms0 libxcb-keysyms0-dev libxcb-property1 libxcb-property1-dev libxcb-render-util0 libxcb-render-util0-dev libxcb-reply1 libxcb-reply1-dev libxcb-wm0 libxcb-wm0-dev libxcb-icccm1 libxcb-icccm1-dev Architecture: source amd64 Version: 0.3.2-1 Distribution: experimental Urgency: low Maintainer: Julien Danjou a...@debian.org Changed-By: Julien Danjou a...@debian.org Description: libxcb-atom1 - utility libraries for X C Binding -- atom libxcb-atom1-dev - utility libraries for X C Binding -- atom libxcb-aux0 - utility libraries for X C Binding -- aux libxcb-aux0-dev - utility libraries for X C Binding -- aux libxcb-event1 - utility libraries for X C Binding -- event libxcb-event1-dev - utility libraries for X C Binding -- event libxcb-icccm1 - utility libraries for X C Binding -- icccm libxcb-icccm1-dev - utility libraries for X C Binding -- icccm libxcb-image0 - utility libraries for X C Binding -- image libxcb-image0-dev - utility libraries for X C Binding -- image libxcb-keysyms0 - utility libraries for X C Binding -- keysyms libxcb-keysyms0-dev - utility libraries for X C Binding -- keysyms libxcb-property1 - utility libraries for X C Binding -- property libxcb-property1-dev - utility libraries for X C Binding -- property libxcb-render-util0 - utility libraries for X C Binding -- render-util libxcb-render-util0-dev - utility libraries for X C Binding -- render-util libxcb-reply1 - utility libraries for X C Binding -- reply libxcb-reply1-dev - utility libraries for X C Binding -- reply libxcb-wm0 - utility libraries for X C Binding -- wm libxcb-wm0-dev - utility libraries for X C Binding -- wm Changes: xcb-util (0.3.2-1) experimental; urgency=low . * New upstream release * Add ${misc:Depends} on -dev packages Checksums-Sha1: 8800d5e153ad248ff065beca18948bba0829fef6 1651 xcb-util_0.3.2-1.dsc faef95bb732d1a1fd727fb750238e1dba9e94f69 419549 xcb-util_0.3.2.orig.tar.gz d00b4ca63dda6ac9994fb5164186959a545152f7 26134 xcb-util_0.3.2-1.diff.gz 0e3bea081cef6677ae5768181e778ad631b5922e 9790 libxcb-atom1_0.3.2-1_amd64.deb 58a5481f553931a22add4b9e966d432d354dcbed 9362 libxcb-atom1-dev_0.3.2-1_amd64.deb 779043c050933c84fad8c9f025de2ded6983a2b7 8554 libxcb-aux0_0.3.2-1_amd64.deb d6f72194e73b5f156e88f42ab4e8740ac5b2f0e1 8610 libxcb-aux0-dev_0.3.2-1_amd64.deb f965a9219f6ca061e8e2a655dc46c885b52f54a7 6528 libxcb-event1_0.3.2-1_amd64.deb 2e2255f9f338280e4fed00c4c8bba44b747f24fe 7504 libxcb-event1-dev_0.3.2-1_amd64.deb 24f91741a04cbdbbea2436b3075f7cd0255fd6dc 12054 libxcb-image0_0.3.2-1_amd64.deb 7384eda7e5a97e74490207f168b8f9321379d12f 17200 libxcb-image0-dev_0.3.2-1_amd64.deb 57f1b3a203aef9507dd9f756c1457dbc6d708eba 7804 libxcb-keysyms0_0.3.2-1_amd64.deb 85a391318202aa15be5710e323570106870acba9 7486 libxcb-keysyms0-dev_0.3.2-1_amd64.deb 5b5a4e942b4e6212dfbe1c6587489d00713aba31 6814 libxcb-property1_0.3.2-1_amd64.deb 62084d41b03925bea2112b0c2fb067c53040b9e5 7184 libxcb-property1-dev_0.3.2-1_amd64.deb 9f2dd7827c1cc023765b334921e21816dbec85fa 9624 libxcb-render-util0_0.3.2-1_amd64.deb 92fb510bb4ba136e897294cfc70d23176efa0e24 9550 libxcb-render-util0-dev_0.3.2-1_amd64.deb d6c9533044a593069b115ccd739882fe54c8ee1b 7152 libxcb-reply1_0.3.2-1_amd64.deb 0331ae0416a2b0245d8c6ff86d3eecbc50ca47ff 7062 libxcb-reply1-dev_0.3.2-1_amd64.deb bff3f12256d3de37c0ca9b89f10e18225a124f4f 8056 libxcb-wm0_0.3.2-1_amd64.deb d78099d692fa0fb79846528f36c6256b9393c63c 7556 libxcb-wm0-dev_0.3.2-1_amd64.deb fdfb6581df22065ab1a0f32900f905d1c70dc73a 10254 libxcb-icccm1_0.3.2-1_amd64.deb 381b7fc2f068ae210c18994c1e43b3c215670fe8 12488 libxcb-icccm1-dev_0.3.2-1_amd64.deb Checksums-Sha256: c247d06ad756a9e659a35f0210852c804678879f4a082b1052b208942e8453ba 1651 xcb-util_0.3.2-1.dsc 90d13eaaa7bc5638fee6b56e648c6f64283a0b4bc8ec83b2889f38b79853256a 419549 xcb-util_0.3.2.orig.tar.gz 70dd5483518cec5373caa50b06dfb4e329d1140cc37505e154f90be2e35a02e7 26134 xcb-util_0.3.2-1.diff.gz f930a0df7e210f29cf6ecaf67b2c6cd82b4379fd13c8335952167a938bab314a 9790 libxcb-atom1_0.3.2-1_amd64.deb 5292b17b3190efdbb271edb2eaf7a25c0cf2c9f9d6d28104e8c75daa03ff9744 9362 libxcb-atom1-dev_0.3.2-1_amd64.deb 236e76858e870cfccd81de17fb5f9d1d977f43c25480a2a684916532b182e42a 8554 libxcb-aux0_0.3.2-1_amd64.deb 6de175287469b035c86f1474c652ae672214ac193994914002653f64f99c 8610 libxcb-aux0-dev_0.3.2-1_amd64.deb 064bdee50ccd74c33c0acf3242081c9eaad61d0ad94cfaa6b852a1cc9b5f9bbb 6528 libxcb-event1_0.3.2-1_amd64.deb 2a3a8f6485d046e4eef17a65c200a0b7bbcac31e580d5db875216bae08a1f78a 7504 libxcb-event1-dev_0.3.2-1_amd64.deb 1f056ce0077a968a04857d63005d6098115eb7d94c48154963c986f6ac4ea939 12054 libxcb-image0_0.3.2-1_amd64.deb