Re: packages missing from sarge
Steve Langasek wrote: With the delays in getting t-p-u built across architectures, that's not long enough for me to be comfortable. I didn't realize t-p-u took so long. But I suppose that's the way it is. Thanks for the explanation, and thank you for your work on getting Sarge out the door! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Mon, May 16, 2005 at 05:39:42PM -0400, Anthony DeRobertis wrote: > On May 15, 2005, at 22:16, Steve Langasek wrote: > >Still, the concerns about re-adding this software version (which > >has been > >out of testing for months) via t-p-u remain. > Its hard to see it being any worse than freeswan, which has been > abandoned for a while by its upstream. And if it turns out to be a > problem, it could just be removed again, right? It could be removed again, but only if someone finds out that it's broken *before* we release. There is a very small window for this to happen, because packages don't get widespread testing while they're in testing-proposed-updates, so the only testing that will happen will be between the time the package is pushed into testing (once it's built everywhere it needs to be) and the release date. With the delays in getting t-p-u built across architectures, that's not long enough for me to be comfortable. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On May 15, 2005, at 22:16, Steve Langasek wrote: Still, the concerns about re-adding this software version (which has been out of testing for months) via t-p-u remain. Its hard to see it being any worse than freeswan, which has been abandoned for a while by its upstream. And if it turns out to be a problem, it could just be removed again, right? racoon doesn't have all the features that freeswan and openswan have; not sure about isakmpd and pipsecd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
I demand that Steve Langasek may or may not have written... > On Sat, May 14, 2005 at 05:44:33PM -0400, François-Denis Gonthier wrote: >> On May 7, 2005 09:03 pm, Joey Hess wrote: >>> erlang >> Erlang and the related erlang-manpages and erlang-doc-html are being put >> up-to-date by me. I have a package ready which should be uploaded by my >> sponsor in the coming week. >> I guess that means that the package that reverse depends on Erlang would >> also be allowed back on: > No, this is a package that was not in woody, so it's going to be too late > to get it (and its reverse-deps) into sarge. The release team is not going > to spend its time hand-holding packages that were nowhere near releasable > at the time of freeze when there are still 50+ RC bugs that need to be > fixed before we release. gxine? Possibility of 0.4.4 in sarge? There are bugs other than the RC bug (in the Debian BTS) which really should be fixed in unstable, preferably (IMO) by uploading 0.4.4 - I suggest that you use the packaging in http://zap.tartarus.org/~ds/debian/> as a starting point. Any changes which you don't think should go into sarge - tell me and I'll (probably) tell you why it should :-) (It's probably still safe to assume that the maintainer doesn't have enough time to prepare and upload the package.) -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Say NO to software patents Be happy with the real pleasures in life. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 15, 2005 at 10:49:10PM +0200, Adrian Bunk wrote: > On Wed, May 11, 2005 at 09:33:36PM -0700, Steve Langasek wrote: > > On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > > > Steve Langasek schrieb: > > > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > > > >>not just get 2.3.x pushed into sarge? Are there any other big issues > > > >>with it, that weren't in 2.2.x? Some people might certainly like the > > > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > > > >>fine for me though --- anything but 2.1.x for me :-) > > > Mainly because 2.3.x causes other openswan boxes to crash in some > > > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > > > keep bugging upstream with it for at least 3 months. No fix until now, > > > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > > > even 2.2.0-5). > > > > > > Because 2.2.3 is no longer in the archive, and resurrecting new > > > > binaries via > > > > t-p-u gives us even less than the usual protection against breakage > > > > caused > > > > by a lack of testing. :/ > > > Does that mean that the only way to get the known stable 2.2.0-x back > > > into testing is an upload to unstable with an epoch? I really wouldn't > > > like to go that route if I can avoid it > > Well, AFAIK openswan has never actually been in testing /before/, so it's > > not a matter of getting it /back/; but yes, the upshot is that I'm not > > comfortable adding packages to testing via t-p-u. > That's wrong, openswan was in testing earlier this year. Read e.g. [1]. Ah, ok. I couldn't seem to find any references to that the last time the question came up, and whichever member of the release team did the actual removal apparently didn't leave a trace. Still, the concerns about re-adding this software version (which has been out of testing for months) via t-p-u remain. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:33:36PM -0700, Steve Langasek wrote: > On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > > Steve Langasek schrieb: > > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > > >>not just get 2.3.x pushed into sarge? Are there any other big issues > > >>with it, that weren't in 2.2.x? Some people might certainly like the > > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > > >>fine for me though --- anything but 2.1.x for me :-) > > Mainly because 2.3.x causes other openswan boxes to crash in some > > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > > keep bugging upstream with it for at least 3 months. No fix until now, > > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > > even 2.2.0-5). > > > > Because 2.2.3 is no longer in the archive, and resurrecting new binaries > > > via > > > t-p-u gives us even less than the usual protection against breakage caused > > > by a lack of testing. :/ > > Does that mean that the only way to get the known stable 2.2.0-x back > > into testing is an upload to unstable with an epoch? I really wouldn't > > like to go that route if I can avoid it > > Well, AFAIK openswan has never actually been in testing /before/, so it's > not a matter of getting it /back/; but yes, the upshot is that I'm not > comfortable adding packages to testing via t-p-u. That's wrong, openswan was in testing earlier this year. Read e.g. [1]. > Steve Langasek cu Adrian [1] http://lists.debian.org/debian-release/2005/01/msg00181.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, May 14, 2005 at 11:07:36AM +0200, Thomas Hood wrote: > On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote: > > Completely MIA maintainers are one part of the problem. > > > > But then there's the class of maintainers who manage to upload a new > > upstream version and perhaps fix some RC bugs every few months but are > > not able to properly handle all bugs in their packages. > > > In part this is a consequence of scarce manpower. In part it is a > consequence of the institution of package ownership and other > organisational flaws. If you agree with this diagnosis then I am curious > to know which of the following you plan to do. > > 1. continue to participate in the Debian project despite its >dysfunctional organisation; > 2. push for changes to the organisation; > 3. participate in another project instead. > > (There are other possibilities, of course.) Some years ago the only choice for me was 1) since 2) was not possible for an average Debian maintainer. I was glad to hear if this had changed since I left. > Thomas Hood cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, May 14, 2005 at 05:44:33PM -0400, François-Denis Gonthier wrote: > On May 7, 2005 09:03 pm, Joey Hess wrote: > > erlang > Erlang and the related erlang-manpages and erlang-doc-html are being put > up-to-date by me. I have a package ready which should be uploaded by my > sponsor in the coming week. > I guess that means that the package that reverse depends on Erlang would also > be allowed back on: No, this is a package that was not in woody, so it's going to be too late to get it (and its reverse-deps) into sarge. The release team is not going to spend its time hand-holding packages that were nowhere near releasable at the time of freeze when there are still 50+ RC bugs that need to be fixed before we release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On May 7, 2005 09:03 pm, Joey Hess wrote: > erlang Erlang and the related erlang-manpages and erlang-doc-html are being put up-to-date by me. I have a package ready which should be uploaded by my sponsor in the coming week. I guess that means that the package that reverse depends on Erlang would also be allowed back on: wings3d manderlbot ejabberd devel-protocols (I tested wings3d with my package and it works fine!) I would like to know if it still possible to get it into Sarge and what if yes, what do I need to verify? BTW, if Erlang 10.B.5 gets into Sarge, the package libxmerl-erlang will be obsoleted. xmerl has been integrated in the main Erlang distribution since version 10. I think I will check with the maintainer. François-Denis Gonthier pgptJzeUglqL2.pgp Description: PGP signature
Re: packages missing from sarge
On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote: > Completely MIA maintainers are one part of the problem. > > But then there's the class of maintainers who manage to upload a new > upstream version and perhaps fix some RC bugs every few months but are > not able to properly handle all bugs in their packages. In part this is a consequence of scarce manpower. In part it is a consequence of the institution of package ownership and other organisational flaws. If you agree with this diagnosis then I am curious to know which of the following you plan to do. 1. continue to participate in the Debian project despite its dysfunctional organisation; 2. push for changes to the organisation; 3. participate in another project instead. (There are other possibilities, of course.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > Steve Langasek schrieb: > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > >>not just get 2.3.x pushed into sarge? Are there any other big issues > >>with it, that weren't in 2.2.x? Some people might certainly like the > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > >>fine for me though --- anything but 2.1.x for me :-) > Mainly because 2.3.x causes other openswan boxes to crash in some > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > keep bugging upstream with it for at least 3 months. No fix until now, > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > even 2.2.0-5). > > Because 2.2.3 is no longer in the archive, and resurrecting new binaries via > > t-p-u gives us even less than the usual protection against breakage caused > > by a lack of testing. :/ > Does that mean that the only way to get the known stable 2.2.0-x back > into testing is an upload to unstable with an epoch? I really wouldn't > like to go that route if I can avoid it Well, AFAIK openswan has never actually been in testing /before/, so it's not a matter of getting it /back/; but yes, the upshot is that I'm not comfortable adding packages to testing via t-p-u. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: [Baghira] :: Re: packages missing from sarge
Vadim Petrunin wrote: > Sorry, but looks like there is no rc bugs in the "baghira" package. > There was only one bug "Serious policy violations" but it is resolved now. > Why it is out of release? As you can see in update-excuses: baghira (- to 0.6f-1) Maintainer: Jose Luis Tallon Too young, only 2 of 5 days old Not touching package, as requested by freeze (contact debian-release if update is needed) Not considered Depends: baghira kdelibs (not considered) The new kdelibs is actually on its way into testing (missing an m68k build ATM). After that point and once it's 5 days old, it would only need an approval by debian-release to get back in. -- see shy jo signature.asc Description: Digital signature
Re: [Baghira] :: Re: packages missing from sarge
Vadim Petrunin wrote: > Sorry, but looks like there is no rc bugs in the "baghira" package. > There was only one bug "Serious policy violations" but it is resolved > now. > Why it is out of release? http://packages.qa.debian.org/b/baghira.html Ask the maintainer. It was not in Sarge because of that one RC bug. The fixed version was uploaded just two days ago so... Sarge has frozen a while before that. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Baghira] :: Re: packages missing from sarge
Sorry, but looks like there is no rc bugs in the "baghira" package. There was only one bug "Serious policy violations" but it is resolved now. Why it is out of release? p/s Also baghira is a source package for kwin-baghira. Is it means that kwin-baghira will be refused too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Lionel Elie Mamane wrote: > On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: > > > polyxmass-doc > > That's the documentation for binaries that _are_ in sid; it was a few > days late for sarge. I find this to be quite sucky, that Debian ships > the program, but not the documentation. > > (Let's note that I'm not the maintainer, and the maintainer thinks > along the lines of "not important, as the documentation can be > downloaded from the upstream website anyway"; as the doc on the > upstream website is that of the last version, which may change > between sarge and etch, I tend to disagree.) There's no particular reason we can't let this documentation package in, but it is up to its maintainer. -- see shy jo signature.asc Description: Digital signature
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:50:48AM +0200, Wouter Verhelst wrote: > On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote: > > On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: > > > On Tue, 10 May 2005, Adrian Bunk wrote: > > > >How often does a quick NMU that gives a fast improvement in the RC > > > >bugs metric hide the real problem that the maintainer is completely or > > > >partially MIA? > > > Actually what is your opinion how to improve the QA process? > > > > It might sound strange, but I'd suggest to completely disallow NMUs > > without maintainer permission. > > > > This would make it take longer until RC bugs are fixed, but it would > > help on speeding up the finding of maintainers who are for any reason > > not able to properly maintain their packages. > > What are we trying to do, then? > > Release Debian, or find MIA maintainers? Based on your previous mails, I > thought you wanted the first. That will go a *lot* easier if we don't Both belong together. The release team plans with a < 1 month freeze and a big emphasis on the RC bugs metric. To be honest, I was very surprised if the release team would miss it's own release date by less than one month. E.g. there will always be problems like bugs with a too low severity or wrong tags that will show up late in the freeze. If there was more focus on the many other problems like maintainers not properly maintaining their packages instead of only on the RC bugs metric both before and during the freeze, the resulting release was better and some negative surprises were less likely. This might seem to defeat the goal of super-short freezes, but I have yet to see at least one freeze that was not only announced as super-short, but that was actually as short as it was announced... > have buggy packages anymore, for which NMU's can be helpful under > certain circumstances. This depends on how you define "buggy packages". If you count only RC bugs you are correct. But non-RC bugs aren't the only bugs. Many annoying things like segfaults under specific circumstances are not considered RC. As an example, look at how many segfaults in the texinfo source package are unfixed for several months. And the last NMU didn't include e.g. my upstream-approved one-line patch for the #259561 segfault. Well, this bug is only "important"... RC bugs are a metric to measure the quality of Debian. But as it is a well-known fact about metrics, work on improving the metric often only improves the metric but not what it was supposed to measure. > If, however, you are indeed intent on finding MIA maintainers for some > to me obscure reason, then I think it'd be nice if you'd talk to those > people actually doing that work at this moment, to see whether they > agree with you that NMU's make their work harder. My guess is that > you'll find they don't, but then of course I haven't asked either. Completely MIA maintainers are one part of the problem. But then there's the class of maintainers who manage to upload a new upstream version and perhaps fix some RC bugs every few months but are not able to properly handle all bugs in their packages. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote: > On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: > > On Tue, 10 May 2005, Adrian Bunk wrote: > > >How often does a quick NMU that gives a fast improvement in the RC > > >bugs metric hide the real problem that the maintainer is completely or > > >partially MIA? > > Actually what is your opinion how to improve the QA process? > > It might sound strange, but I'd suggest to completely disallow NMUs > without maintainer permission. > > This would make it take longer until RC bugs are fixed, but it would > help on speeding up the finding of maintainers who are for any reason > not able to properly maintain their packages. What are we trying to do, then? Release Debian, or find MIA maintainers? Based on your previous mails, I thought you wanted the first. That will go a *lot* easier if we don't have buggy packages anymore, for which NMU's can be helpful under certain circumstances. If, however, you are indeed intent on finding MIA maintainers for some to me obscure reason, then I think it'd be nice if you'd talk to those people actually doing that work at this moment, to see whether they agree with you that NMU's make their work harder. My guess is that you'll find they don't, but then of course I haven't asked either. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: > polyxmass-doc That's the documentation for binaries that _are_ in sid; it was a few days late for sarge. I find this to be quite sucky, that Debian ships the program, but not the documentation. (Let's note that I'm not the maintainer, and the maintainer thinks along the lines of "not important, as the documentation can be downloaded from the upstream website anyway"; as the doc on the upstream website is that of the last version, which may change between sarge and etch, I tend to disagree.) -- Lionel signature.asc Description: Digital signature
Re: packages missing from sarge
> > Proposal: allow 1.3.7 into sarge, on the following basis - > > * woody has 1.3.0, ie it's used by current users of stable > > This doesn't deal with questions of possible bit rot (which your tests > address to some extent, but not completely). It also doesn't provide a > smooth upgrade path for users of sarge==testing who have a no-longer-present > version of apt-proxy 1.9 installed on their systems. While support for urk. yes, that is a problem. > upgrades within testing are not "release-critical" because there's no > release involved, I'd rather that sarge users have apt-proxy show up under > "obsolete" than be caught running an unsupported, *newer* version with no > indication of trouble; and I feel strongly enough about this to not let > 1.3.7 back in via t-p-u. okay. That clarifies the situation for me. > That means that if people want apt-proxy 1.3 in sarge, it should go through > unstable with an epoch, possibly kicking 1.9 out to experimental for the > duration. If people pursued this path, would it make sense to rename the packages to apt-proxy-shell and apt-proxy-python (both would Provide: apt-proxy) to avoid future RCs in one implementation clobbering the other? This is all starting to sound like "etch" work to me. However I'll shut up now and defer to the maintainers. Thanks for your reply Vince -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Hi Vince, On Wed, May 11, 2005 at 08:22:28AM +1000, Vincent McIntyre wrote: > apt-proxy comes in two flavours - the old shell-based one and a new shiny > python one. The most recent shell-based one is apt-proxy-1.3.7, in t-p-u. > The most recent python-based one is apt-proxy-1.9.28, in unstable. > Currently, the package is held out because of #304182. However, that is > against the python version, 1.9.28. AFAICT the shell version is fine. > Proposal: allow 1.3.7 into sarge, on the following basis - > * woody has 1.3.0, ie it's used by current users of stable This doesn't deal with questions of possible bit rot (which your tests address to some extent, but not completely). It also doesn't provide a smooth upgrade path for users of sarge==testing who have a no-longer-present version of apt-proxy 1.9 installed on their systems. While support for upgrades within testing are not "release-critical" because there's no release involved, I'd rather that sarge users have apt-proxy show up under "obsolete" than be caught running an unsupported, *newer* version with no indication of trouble; and I feel strongly enough about this to not let 1.3.7 back in via t-p-u. That means that if people want apt-proxy 1.3 in sarge, it should go through unstable with an epoch, possibly kicking 1.9 out to experimental for the duration. > * I don't understand hinting-foo, but it appears it's been hinted in: >http://ftp-master.debian.org/testing/hints/ajt That was a test hint; nothing below 'finished' is processed by britney. > The package was removed from sarge in November, for some other RC problem. > JoeyH is concerned that there has been so much flux since then that > allowing the shell version back in will cause more problems than it's > worth. Indeed, that's still a concern that I have; I've heard before that apt-proxy works flawlessly for some people, and not at all for others. :/ -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
re: packages missing from sarge (apt-proxy)
sorry to followup my own post, but... I did a few apt-proxy-import tests by removing a random set of .debs out of the cache tree and importing again. This worked correctly. Cheers Vince -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re: packages missing from sarge
Hi I'd like to raise the question of apt-proxy. I discussed offlist with JoeyH and he wasn't keen, but now I've done a few tests and have more confidence that this is worth raising. apt-proxy comes in two flavours - the old shell-based one and a new shiny python one. The most recent shell-based one is apt-proxy-1.3.7, in t-p-u. The most recent python-based one is apt-proxy-1.9.28, in unstable. Currently, the package is held out because of #304182. However, that is against the python version, 1.9.28. AFAICT the shell version is fine. Proposal: allow 1.3.7 into sarge, on the following basis - * woody has 1.3.0, ie it's used by current users of stable * I don't understand hinting-foo, but it appears it's been hinted in: http://ftp-master.debian.org/testing/hints/ajt The package was removed from sarge in November, for some other RC problem. JoeyH is concerned that there has been so much flux since then that allowing the shell version back in will cause more problems than it's worth. To try to allay these fears, I made a few tests. So far it looks ok. 1. clean install of an x86 box with d-i rc3, just base. 2. install apt-proxy-1.3.7 from t-p-u, and then take t-p-u out of sources.list again 3. install a bunch o' packages on the host, with sources.list pointed at the proxy service (http://localhost:). This worked pretty well once I got apt-proxy.conf set up properly. The only problem I could see in /var/log/apt-proxy.log was warnings from /usr/bin/stat about using a deprecated argument. So Joey was right to worry. I've attached a patch that addresses the warnings. 4. clean install a second x86 machine (d-i rc3 again), using the proxy. This worked well, installing 400+ packages without missing a beat. 5. try a couple of simultaneous installs (eg rhythmbox & tons of depends) Again, things worked smoothly. The above doesn't exercise all the code paths in apt-proxy. For one, I haven't tried apt-proxy-import. The other main question mark I guess is the rsync functionality, I don't know how much rsync has changed over this period. Would someone care to try these things out? Since it's a shell script, I'm going to assume there are no arch-specific bugs... Thanks for reading. I have the apt-proxy.log if that's needed. Vince diff -ruN apt-proxy-1.3.7.orig/usr/sbin/apt-proxy apt-proxy-1.3.7/usr/sbin/apt-proxy --- apt-proxy-1.3.7.orig/usr/sbin/apt-proxy 2005-05-10 23:11:30.0 +1000 +++ apt-proxy-1.3.7/usr/sbin/apt-proxy 2005-05-10 10:55:51.0 +1000 @@ -80,12 +80,12 @@ # file_size(file name) # if [ -x $STAT ] && - [ "`$STAT -tl /dev/null | sed "s,/dev/null 0 .*,PASSED,"`" = "PASSED" ] + [ "`$STAT -tL /dev/null | sed "s,/dev/null 0 .*,PASSED,"`" = "PASSED" ] then file_size() { [ -z "$1" -o ! -f "$1" ] && return 1 - set -- `$STAT -tl "$1"` + set -- `$STAT -tL "$1"` [ -z "$2" ] && return 1 echo $2 }
Re: packages missing from sarge
On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: > On Tue, 10 May 2005, Adrian Bunk wrote: > > Speaking as somebody who is quite unrelated to release issues (except > that I keep my packages bug free) I have some questions: > > >were at the correct severity and tagged correctly, your release > >management is based on an assumption that isn't true. > Interesting statement but what is your suggestion to improve this? > > >And since you say the package maintainers were responsible for correct > >bug severities: > > > >How often does a quick NMU that gives a fast improvement in the RC > >bugs metric hide the real problem that the maintainer is completely or > >partially MIA? > Actually what is your opinion how to improve the QA process? It might sound strange, but I'd suggest to completely disallow NMUs without maintainer permission. This would make it take longer until RC bugs are fixed, but it would help on speeding up the finding of maintainers who are for any reason not able to properly maintain their packages. > >BTW: In case anyone of the release team takes the announced 30 May 2005 > >release date (that already got some media coverage) seriously, I'd > >be glad to bet some some Euros against it... > What is the lesson whe should learn from this? I might be wrong and the release team really thinks this is a date they will reach. But otherwise, the problem seems to be that in any other area I know the quality of release management is in a big part measured in how it manages to reach the goals. Debian release management has the big advantage to setting their own goals. But the last date (September 2004) set by the current release management failed because security support for sarge that was assumed to be ready six days after the announcement took more than six months. I asked: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? but noone of the release team did bother to answer. > Just curious > >Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, 10 May 2005, Adrian Bunk wrote: Speaking as somebody who is quite unrelated to release issues (except that I keep my packages bug free) I have some questions: were at the correct severity and tagged correctly, your release management is based on an assumption that isn't true. Interesting statement but what is your suggestion to improve this? And since you say the package maintainers were responsible for correct bug severities: How often does a quick NMU that gives a fast improvement in the RC bugs metric hide the real problem that the maintainer is completely or partially MIA? Actually what is your opinion how to improve the QA process? BTW: In case anyone of the release team takes the announced 30 May 2005 release date (that already got some media coverage) seriously, I'd be glad to bet some some Euros against it... What is the lesson whe should learn from this? Just curious Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: > [Adrian Bunk] > > The entry "packages:" was a bug in my quick&dirty scripting... > > Thanks for making a nice summary of the relevant packages. :) > > Feel free to include the script to generate the list when you generate > dynamic list of packages like this. It would make it easier for all > of us to re-generate it on demand. :) To be honest, I do not like to make ugly 5 minute hacks public. I can send it to you privately, but is seems Javier has already sent a better looking script. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 03:54:46AM -0700, Steve Langasek wrote: > > Yes, it's called "garbage in, garbage out". If people aren't going to file > bugs at the proper severity, and if package maintainers aren't going to > treat release-critical bugs with the appropriate urgency when they *are* > filed at the wrong severity, there's no way in hell anyone is going to know > there's a problem. > > It's not the metric that's broken here. If your release management is based on the assumption all bugs in Debian were at the correct severity and tagged correctly, your release management is based on an assumption that isn't true. See #302282 for an example where even you yourself tagged a bug wrongly as "sid"... And since you say the package maintainers were responsible for correct bug severities: How often does a quick NMU that gives a fast improvement in the RC bugs metric hide the real problem that the maintainer is completely or partially MIA? > Steve Langasek cu Adrian BTW: In case anyone of the release team takes the announced 30 May 2005 release date (that already got some media coverage) seriously, I'd be glad to bet some some Euros against it... -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, 7 May 2005, Joey Hess wrote: > So here is a list (from update-excuses) of all 491 packages that is > being held out of sarge[1]. If you've already done all you can on the RC > bugs on packages in sarge, take a look over it and if you spot anything > important or generally worth fixing, point it out, or just work on it. > Remember that due to the freeze you'll need to ask on debian-release to > get any fixed packages accepted back into sarge. > [...] > pgp4pine I fixed the RC and other bugs in this several weeks ago but it is in contrib so does it need a nudge to be autobuilt? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Steve Langasek schrieb: >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why >>not just get 2.3.x pushed into sarge? Are there any other big issues >>with it, that weren't in 2.2.x? Some people might certainly like the >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is >>fine for me though --- anything but 2.1.x for me :-) Mainly because 2.3.x causes other openswan boxes to crash in some (reproducable) cases - that's a pretty bad regression from 2.2.0 and I keep bugging upstream with it for at least 3 months. No fix until now, so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or even 2.2.0-5). > Because 2.2.3 is no longer in the archive, and resurrecting new binaries via > t-p-u gives us even less than the usual protection against breakage caused > by a lack of testing. :/ Does that mean that the only way to get the known stable 2.2.0-x back into testing is an upload to unstable with an epoch? I really wouldn't like to go that route if I can avoid it with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, May 10, 2005 at 04:17:41AM -0400, Anthony DeRobertis wrote: > On Tue, May 10, 2005 at 09:32:49AM +0200, Rene Mayrhofer wrote: > > Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis: > > > Seconded! The only RC-bug in openswan is for a newer version of the > > > kernel which will not ship with Sarge. > > Yes, that's true. I have to admit that I messed up in not marking this bug > > sid. My current best solution would be to put 2.2.0-4 back into testing > > (which got removed because of that RC bug that's for 2.3.0). What is the > > general opinion on this? > If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > not just get 2.3.x pushed into sarge? Are there any other big issues > with it, that weren't in 2.2.x? Some people might certainly like the > agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > fine for me though --- anything but 2.1.x for me :-) Because 2.2.3 is no longer in the archive, and resurrecting new binaries via t-p-u gives us even less than the usual protection against breakage caused by a lack of testing. :/ -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On Tue, May 10, 2005 at 09:32:49AM +0200, Rene Mayrhofer wrote: > Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis: > > Seconded! The only RC-bug in openswan is for a newer version of the > > kernel which will not ship with Sarge. > Yes, that's true. I have to admit that I messed up in not marking this bug > sid. My current best solution would be to put 2.2.0-4 back into testing > (which got removed because of that RC bug that's for 2.3.0). What is the > general opinion on this? If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why not just get 2.3.x pushed into sarge? Are there any other big issues with it, that weren't in 2.2.x? Some people might certainly like the agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is fine for me though --- anything but 2.1.x for me :-) > > with best regards, > Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis: > Seconded! The only RC-bug in openswan is for a newer version of the > kernel which will not ship with Sarge. Yes, that's true. I have to admit that I messed up in not marking this bug sid. My current best solution would be to put 2.2.0-4 back into testing (which got removed because of that RC bug that's for 2.3.0). What is the general opinion on this? with best regards, Rene pgpOPG0kUiSok.pgp Description: PGP signature
Re: packages missing from sarge
On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: > [Adrian Bunk] > > The entry "packages:" was a bug in my quick&dirty scripting... > > Thanks for making a nice summary of the relevant packages. :) > > Feel free to include the script to generate the list when you generate > dynamic list of packages like this. It would make it easier for all > of us to re-generate it on demand. :) FWIW, I've recovered a little script I wrote for the potato -> woody release and have improved it so that it can be useful for others (location of mirror can be adjusted, releases can be selected, etc...) The output header looks like this: -- Comparison details from 'woody' to 'sarge' -- Total packages for woody: 8747 Total packages for sarge: 15778 Added packages: 9034 Removed packages: 2003 Changed packages: 6444 Unchanged packages (no version update): 298 -- and it also provides detailed information on what has precisely changed. Regards Javier #!/usr/bin/perl # Find which packages have been changed by tacking a # look at Packages.gz files (well, should be already # de-compressed) # # Javier Fernandez-Sanguino Peña # Distributed under the GNU GPL use Getopt::Std; # Options: # -d = debug # -p release = previous release 'release' # -r release = current release 'release' # -m dir = use mirror directory 'dir' # -a arch= use architecture 'arch' getopts('dp:r:m:a:'); # Debug my $debug = $opt_d || 0; # Releases and path location my $prevrelease = $opt_p || "woody"; my $currelease = $opt_r || "sarge"; my $mirrordir = $opt_m || "/home/mirrors/debian/debian.org"; my $arch= $opt_a || "i386"; my @releases = ( $currelease, $prevrelease ) ; my @components = ("main", "contrib", "non-free") ; # Initialise my @added, @removed, unchanged; $packchanged=0; my %changed ; foreach $releasei (0 .. $#releases ) { my $release = $releases[$releasei]; foreach $componenti (0 .. $#components ) { my $component = $components[$componenti]; $release{$release}{$component}=$mirrordir."/dists/".$release."/".$component."/binary-".$arch."/Packages"; die "Cannot read $release{$release}{$component}" if ! -r $release{$release}{$component}; print "Found component '$component' for release '$release' at $release{$release}{$component}\n" if $debug; } } # Global (ugly) $totalnumbers{$currelease}=0; $totalnumbers{$prevrelease}=0; # For each release read all the files and make a *Big* hash foreach $file ( keys(%{$release{$prevrelease}}) ) { read_file($prevrelease,$release{$prevrelease}{$file}); } foreach $file ( keys(%{$release{$currelease}}) ) { read_file($currelease,$release{$currelease}{$file}); } # Once this is done compare all the packages found and their description # or version and if they have changed say so. #If the package does not exist add: REMOVED foreach $package ( keys(%{$packages{$prevrelease}}) ) { if ( defined $packages{$currelease}{$package} ) { my $status=check_packages($packages{$currelease}{$package},$packages{$prevrelease}{$package}) if $packages{$currelease}{$package} ne $packages{$prevrelease}{$package}; if ( $status eq "" ) { push @unchanged, $package; } else { $packchanged++; $changed{$package}=$status; } } else { push @removed, $package; } } # of the foreach # The other way around (currelease vs prevrelease) foreach $package ( keys(%{$packages{$currelease}}) ) { if ( ! defined $packages{$prevrelease}{$package} ) { push @added, $package; } } # of the foreach # Summary $header="Comparison details from '$prevrelease' to '$currelease'"; print $header."\n"; print "-" x length($header); print "\n"; # Final numbers: foreach $release ( keys(%totalnumbers) ) { print "Total packages for ".$release.": ".$totalnumbers{$release}."\n"; } # of the foreach print "Added packages: $#added\n"; print "Removed packages: $#removed\n"; print "Changed packages: $packchanged\n"; print "Unchanged packages (no version update): $#unchanged\n"; print "\nDetailed information\n\n"; print "\n--\n"; print "ADDED packages"; print "\n--\n"; foreach my $packi ( 0 .. $#added ) { print $added[$packi]."\n"; } print "\n--\n"; print "REMOVED packages"; print "\n--\n"; foreach my $packi ( 0 .. $#removed ) { print $removed[$packi]."\n"; } print "\n--\n"; print "CHANGED packages"; print "\n--\n"; foreach my $pack ( keys %changed ) { print "$pack -> $changed{$pack}"; } print "\n--\n"; print "UNCHANGED packages"; print "\n--\n"; foreach my $packi ( 0 .. $#unchanged ) { print $unchanged[$packi]."\n"; } exit 0; sub check_packages { # Checks two packages text to see if they are the same # and determines what has changed (version, description...) # Description cha
Re: packages missing from sarge
Anthony DeRobertis wrote: > Seconded! The only RC-bug in openswan is for a newer version of the > kernel which will not ship with Sarge. Doesn't #291274 also affect the 2.6.8 kernel? Also, what of the mail in that bug report stating that even once it's patched to build, it doesn't really work? -- see shy jo signature.asc Description: Digital signature
Re: packages missing from sarge
On May 8, 2005, at 08:36, Andreas Henriksson wrote: Hi everybody! Although I guess there's no chance for it to make it in, Openswan is the one on my personal wishlist. Seconded! The only RC-bug in openswan is for a newer version of the kernel which will not ship with Sarge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: > [Adrian Bunk] > > The entry "packages:" was a bug in my quick&dirty scripting... > > Thanks for making a nice summary of the relevant packages. :) > > Feel free to include the script to generate the list when you generate > dynamic list of packages like this. It would make it easier for all > of us to re-generate it on demand. :) Actually, I'd like this to be available in the release-notes documentation CVS since it can be useful as an addendum to the RN or to generate valid numbers (X packages were updated, Y packages were removed ...) Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
[Adrian Bunk] > The entry "packages:" was a bug in my quick&dirty scripting... Thanks for making a nice summary of the relevant packages. :) Feel free to include the script to generate the list when you generate dynamic list of packages like this. It would make it easier for all of us to re-generate it on demand. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, 2005-05-07 at 21:03 -0400, Joey Hess wrote: > So here is a list (from update-excuses) of all 491 packages that is > being held out of sarge[1]. ... > eglade There are no open bugs. Can it be put back in? -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA Do you want to know God? http://www.lfix.co.uk/knowing_god.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, 8 May 2005, Goswin von Brederlow wrote: I agree completely here that all bugs should be fixed and the fact that a bug should be RC but is not marked as such qualifies also for removal If a bug is RC but not marked such then mark it. Then it is RC and marked such and any discussion about qualifying or not is pointless. Sure. Not marking a RC bug apropriately is a bug which definitely should be fixed by a correct mark. But not handling an incorrectly marked bug by the release team would be an even worse error. If the release team would forget to mark the bug apropriately which would leave a trace about the reason is only a documentation bug which sounds like wishlist - which is no excuse. But the initial problem was caused by a maintainer who did not care for his package ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Andreas Tille <[EMAIL PROTECTED]> writes: > On Sun, 8 May 2005, Steve Langasek wrote: > >> Yes, it's called "garbage in, garbage out". If people aren't going to file >> bugs at the proper severity, and if package maintainers aren't going to >> treat release-critical bugs with the appropriate urgency when they *are* >> filed at the wrong severity, there's no way in hell anyone is going to know >> there's a problem. > I agree completely here that all bugs should be fixed and the fact that > a bug should be RC but is not marked as such qualifies also for removal If a bug is RC but not marked such then mark it. Then it is RC and marked such and any discussion about qualifying or not is pointless. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, 8 May 2005, Steve Langasek wrote: Yes, it's called "garbage in, garbage out". If people aren't going to file bugs at the proper severity, and if package maintainers aren't going to treat release-critical bugs with the appropriate urgency when they *are* filed at the wrong severity, there's no way in hell anyone is going to know there's a problem. I agree completely here that all bugs should be fixed and the fact that a bug should be RC but is not marked as such qualifies also for removal of the package. On the other hand the bug is fixed now and as I said it is a quite funny and attractive program for exhibition boothes and thus I would personally vote for shipping it with Sarge. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Andrew Vaughan wrote: > > partimage > Bug: #294953 partimage - refuses to restore image on i386 which is > created on s390. > > Synopsis: partimage seems to be i386 only, yet is still built for other > arches. The changelog for 0.6.4-10 says: > > partimage (0.6.4-10) unstable; urgency=low > * Change to i386 only! Closes: #268248 > -- Sergio Rua <[EMAIL PROTECTED]> Wed, 13 Oct 2004 12:16:25 +0100 > > So it seems that the changes in 0.6.4-10 were insufficient to really fix > #268248. Contrary to the changelog, partimage's control file still claims it's Architecture: any. -- see shy jo signature.asc Description: Digital signature
Re: packages missing from sarge
Ola Lundqvist wrote: > On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: > ... > > mnemo2 > This package was 10 days old when sarge was frozen. It contain just one > minor bug. I think it can be safely added. Sorry, I don't think it's a net win to accept packages that were NEW just before the freeze. I say, even though my package of rscrobbler is the same. If it could wait this long for the first upload to unstable, it will have to wait for etch.. -- see shy jo signature.asc Description: Digital signature
Re: packages missing from sarge
> At the bottom is a complete list of the 2070 binary packages present in > woody but not in sarge (including nun-US and contrib/non-free). Correction: 2069 binary packages The entry "packages:" was a bug in my quick&dirty scripting... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 03:07:44PM +0200, Petter Reinholdtsen wrote: > [Joey Hess] > > So here is a list (from update-excuses) of all 491 packages that is > > being held out of sarge[1]. > > I would be even more interested in seeing which packages in woody are > now missing in sarge. Anyone have such a list available? >... At the bottom is a complete list of the 2070 binary packages present in woody but not in sarge (including nun-US and contrib/non-free). Most interesting might be the following list of 129 binary packages present in both woody and sid but not in sarge: abuse abuse-frabs abuse-lib abuse-sdl abuse-sfx apt-proxy autorespond barrendero bb blootbot bookview cce configlet-frontends coq-doc crystalspace crystalspace-dev crystalspace-doc cursel debget dhcp-dns directory-administrator divine doomlegacy-data doom-wad-shareware doxymacs eglade eroaster ext2resize falconseye falconseye-data filler freewrl gkdial gkdial-gnome gnokii gnome-chess gnome-pim goldedplus gpsim-led grunch gsnes9x gwydion-dylan gwydion-dylan-dev ibm-jdk1.1-installer id-utils innovation3d innovation3d-dev innovation3d-plugins install-doc interchange interchange-cat-foundation interchange-ui ipac-ng ipmenu jswat kannel kernel-patch-openmosix kernel-patch-uml kimberlite kimberlite-doc l2tpd ldmud lftp libapache-mod-interchange libavalon-excalibur-java libavalon-excalibur-java-doc libflash0 libflash-dev libgcrypt1 libgcrypt-dev libgcrypt-doc libgd-perl libmail-cclient-perl libroxen-floatingcode libsoap-java libsoap-java-doc mailscanner mercury mindy mp3burn murasaki ndtpd nvclock ohphone ohphone-basic oops openmosix opustex p2c panorama partimage partimage-server phpdoc ploticus plucker python-configlet python-parted python-pcgi qmail-src r5rs-doc rootstrap saxon-catalog scilab sformat siege-ssl smail stella symlinks tcl8.0-ja t-gnus tk8.0-ja tleds trn tth ultrapoint unrar user-mode-linux wap-wml-tools watchdog xa+cv xfractint xmms-wmdiscotux xtux xtux-client xtux-common xtux-server yh zmailer zope-popyda cu Adrian All packages in woody but not in sarge: 3270-common 3dwm-clock 3dwm-csgclient 3dwm-geoclient 3dwm-pickclient 3dwm-server 3dwm-texclient 3dwm-vncclient a52dec a52dec-dev abc2mtex abiword-gtk abuse abuse-frabs abuse-lib abuse-sdl abuse-sfx acl-dev adbbs addressbook admwebuser aegis3 aegis3-doc aegis3-tk aegis3-web aethera agbrowser agsatellite alsaconf alsa-headers-0.4 alsa-headers-0.5 alsa-modules-2.4.16-386 alsa-modules-2.4.16-586 alsa-modules-2.4.16-586tsc alsa-modules-2.4.16-686 alsa-modules-2.4.16-686-smp alsa-modules-2.4.16-k6 alsa-modules-2.4.16-k7 alsa-source-0.4 alsa-source-0.5 alsa-utils-0.4 alsa-utils-0.5 althea althea-ssl amavis-postfix amaya-dict-de amaya-dict-en amaya-dict-es amaya-dict-fr amaya-dict-it amaya-dict-ne amaya-dict-se ami-gnome amiwm amp am-utils-dev anti-aliasing-howto apt-localepurge apt-proxy arch argante aris-extractor ari-yahoo arpack++ arpack2 arpack2-dev asd4 asd4-clients asmodem asnparser attr-dev autoinstall autoinstall-i386 automake automake1.5 autorespond awe-drv awe-midi awe-netscape-libc5 awe-netscape-libc6 axyftp-doc axyftp-gtk axyftp-lesstif barrendero basilix bass battstat-applet bb bblaunch bbpal beaver bigloo-runtime-2.4b binutils-sparc blackened blatte blootbot blt8.0-dev blt-common bnc bonobo-python bookmarker bookview bpowerd bsd-ftpd btoa bulkmail busybox-source-0.60.0 c3270 captain casio catalog caudium-php4 cbb cce ccf cdbakeoven cdebconf-dev cdindex-client cdrecord-dev cedictb5 cedictgb cedicttools cern-httpd cfitsio2 cfitsio-dev cfitsio-doc chaos chpp cil cim clanlib clanlib0-common clanlib0-common-dev clanlib0-display-fbdev clanlib0-display-ggi clanlib0-display-glx clanlib0-display-svga clanlib0-display-x11 clanlib0-docs clanlib0-utils clanlib-dev clanlib-gl clanlib-gui clanlib-jpeg clanlib-mikmod clanlib-network clanlib-png clanlib-sound clanlib-ttf clanlib-vorbis cl-imho cl-local-time cl-local-time-db cl-metadata cl-uncommonsql cl-uncommonsql-mysql cl-uncommonsql-oracle cl-uncommonsql-postgresql cocoon cocoon2 cocoon2-doc cocoon2-example cocoon-doc cocoon-example cocoon-lib communicator communicator-base-477 communicator-nethelp-477 communicator-smotif-477 communicator-spellchk-477 configlet-frontends console-tools-libs cooledit coolicon coolman coq-doc cost courier-debug cpp-3.0 cpp-3.0-doc cqcam crystalspace crystalspace-demos crystalspace-dev crystalspace-doc cucipop cupsys-pstoraster curl-ssl cursel cvs-conf cvs-pcl cvsup cvsupd cxhextris cyrus-nntp d4x-gnome-applet dbf2pg dcopperl dcoppython ddt-client ddt-server debconf-tiny debget debian-guide debian-guide-es debian-guide-zh-s debian-guide-zh-t debian-test debrecipes-es debwrap devhelp-book-ggad devhelp-book-gnome devhelp-book-gtk dhcp-dns directory-administrator distributed-net-pproxy ditty divine dmachinemon-gtkiface dmapi dmapi-dev dmbt docbook-xml-jrefentry docbook-xml-simple docbook-xml-slides docbook-xml-website docbook-xsl-stylesheets doc-es-misc doc-jakarta-ja doc-linux-fr doc-linux-zh-s
Re: packages missing from sarge
[Joey Hess] > So here is a list (from update-excuses) of all 491 packages that is > being held out of sarge[1]. I would be even more interested in seeing which packages in woody are now missing in sarge. Anyone have such a list available? It would be nice to have some working upgrade path for those packages, to make sure the users of the woody packages are not left with an unmaintained package after upgrade. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Hi everybody! Although I guess there's no chance for it to make it in, Openswan is the one on my personal wishlist. Yes, the package is still buggy but AFAIK the bugs are eighter on the kernel-patches (I don't use KLIPS in favor of the in-kernel ipsec layer, and since they seem to be a real burden I'd suggest not packaging them at all.) or some long-standing well-known issues upstream that noone seem to care about... I'd suggest to write down "known problems" and lower the severity to wishlist. Thanks for all the hard work! Lets hope we'll see a release soon! :) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 12:21:05PM +0200, Julien Cristau wrote: > On 08/05/2005-10:35, Joey Hess wrote: > > ocaml-getopt > According to [1], this package was removed because of bug#306074, which > is now fixed. ocaml-getopt in unstable is now 12 days old, so I think it > can be allowed back in testing. Approved. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
Hi all, The following two packages are the only ones not in testing that I currently use. Note that both are in woody, so it would be good they also shipped with sarge. (packages maintainers cced, in the hope they might fix these themselves). (Note: I'm not a dd, so I can't fix these myself.) > apt-proxy Bug: #304182 apt-proxy-v1tov2 generates empty timeout value. (Tags: patch, pending - has been pending for 2 weeks now.) Synopsis: The script that upgrades old conf file to the new conf file generates fault config. > partimage Bug: #294953 partimage - refuses to restore image on i386 which is created on s390. Synopsis: partimage seems to be i386 only, yet is still built for other arches. The changelog for 0.6.4-10 says: partimage (0.6.4-10) unstable; urgency=low * Change to i386 only! Closes: #268248 -- Sergio Rua <[EMAIL PROTECTED]> Wed, 13 Oct 2004 12:16:25 +0100 So it seems that the changes in 0.6.4-10 were insufficient to really fix #268248. Thanks Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Hello On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: ... > mnemo2 This package was 10 days old when sarge was frozen. It contain just one minor bug. I think it can be safely added. ... Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 12:36:16PM +0200, Adrian Bunk wrote: > On Sun, May 08, 2005 at 08:45:21AM +0200, Andreas Tille wrote: > > On Sat, 7 May 2005, Joey Hess wrote: > > >bb > > I did not checked your complete list but our most frequently used > > programs at exhigition boothes. It currently has no RC bug (the only > > grave bug was solved two weeks ago. > > So something is wrong either with your list of with the removal. > That's a funny example of the result of the release team's focus only on > the RC bugs metric: > This package had a more than six years old "normal" bug stating that bb > crashes on alpha (#32160). > Last month, a second bug for exactly the same issue was sent with > severity "grave" (#304434). This second bug report included a trivial > one line fix for this bug. > You might think the second bug made the situation better because it > included a patch for a more than six years old bug that made the package > unusable on 64bit machines. > But in the logic of your release team, the first non-RC bug didn't show > in their RC bugs metric while the second bug did. Yes, it's called "garbage in, garbage out". If people aren't going to file bugs at the proper severity, and if package maintainers aren't going to treat release-critical bugs with the appropriate urgency when they *are* filed at the wrong severity, there's no way in hell anyone is going to know there's a problem. It's not the metric that's broken here. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On Sun, May 08, 2005 at 08:45:21AM +0200, Andreas Tille wrote: > On Sat, 7 May 2005, Joey Hess wrote: > > >bb > I did not checked your complete list but our most frequently used > programs at exhigition boothes. It currently has no RC bug (the only > grave bug was solved two weeks ago. > > So something is wrong either with your list of with the removal. That's a funny example of the result of the release team's focus only on the RC bugs metric: This package had a more than six years old "normal" bug stating that bb crashes on alpha (#32160). Last month, a second bug for exactly the same issue was sent with severity "grave" (#304434). This second bug report included a trivial one line fix for this bug. You might think the second bug made the situation better because it included a patch for a more than six years old bug that made the package unusable on 64bit machines. But in the logic of your release team, the first non-RC bug didn't show in their RC bugs metric while the second bug did. bb was therefore removed from testing a few days after the second bug was sent (really not many days since the fixed package was uploaded 12 days after the second bug report was sent). > Kind regards > > Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On 08/05/2005-10:35, Joey Hess wrote: > ocaml-getopt According to [1], this package was removed because of bug#306074, which is now fixed. ocaml-getopt in unstable is now 12 days old, so I think it can be allowed back in testing. Thanks, Julien Cristau [1] http://ftp-master.debian.org/testing/hints/vorlon signature.asc Description: Digital signature
Re: packages missing from sarge
Joey Hess wrote: [snip] > doctorj Seem to just be a SPARC buildd issue holding this out of sarge, as reported to [EMAIL PROTECTED] and [EMAIL PROTECTED] previously. Can someone with access to a SPARC do a binary-NMU to get this into sarge, please? [1] http://lists.debian.org/debian-sparc/2005/04/msg00244.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, 7 May 2005, Joey Hess wrote: bb I did not checked your complete list but our most frequently used programs at exhigition boothes. It currently has no RC bug (the only grave bug was solved two weeks ago. So something is wrong either with your list of with the removal. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
packages missing from sarge
The release team has been fairly agressive for many months now about removing RC buggy packages from sarge. I'm glad of this policy since we now have a maneagable number of RC bugs. However, there's the possibility this means some packages that are important to many people have been dropped and there may still be time to fix it before sarge is released. So here is a list (from update-excuses) of all 491 packages that is being held out of sarge[1]. If you've already done all you can on the RC bugs on packages in sarge, take a look over it and if you spot anything important or generally worth fixing, point it out, or just work on it. Remember that due to the freeze you'll need to ask on debian-release to get any fixed packages accepted back into sarge. For example, lftp is a big item on this list but already (mostly) dealt with; doom-wad-shareware is a good example of a package that was removed due to an easily fixable problem (nmu in progress); bb is a good example of a package that seems fit to re-enter sarge but hasn't yet due to the freeze (RA now reviewing); boot-floppies is a good example of a package we really don't want in sarge. abuse-frabs abuse-lib abuse-sdl abuse-sfx adonthell adonthell-data amavis-ng amule aoetools approx apt-proxy apt-rpm argouml aspectj-anttasks aspseek asterisk-chan-misdn asterisk-spandsp-plugins autorespond avalon-excalibur avifile babel baghira bandersnatch barrendero battfink bayonne bb bbconf blam blootbot bookview boot-floppies boot-icons boson-base boson-data boson-music cabot cce ccs cegui-mk2 charva chdrv childsplay childsplay-plugins cl-photo cman cman-kernel coco-cs configlet convertfs coq-doc crystalspace crystalspace-data cursel cxx cycle daapd darcs-buildpackage dbmail debbuggtk debget debpartial-mirror dhcp-dns directory-administrator divine dlm-kernel doctorj doodle doom-wad-shareware doomlegacy doomlegacy-data doxymacs dresden-ocl drip drpython dvr ec-fonts-mftraced eclipse eclipse-nls-sdk eglade ejabberd elastic erlang eroaster evolution-data-server1.2 ext2resize f-spot falconseye fcalendar fence fenris filler fmultivar forrest fportfolio freebsd-sendpr freewrl fyre gabber2 gal2.4 gambas gamin gcc-m68hc1x gcc-snapshot gcjwebplugin gecko-sharp gerris gfs gfs-kernel ggz-client-libs ggz-docs ggz-gnome-client ggz-grubby ggz-gtk-client ggz-gtk-games ggz-kde-client ggz-kde-games ggz-server ggz-txt-client ggz-utils gkdial gkrelldnet glob2 gnat-gps gnbd gnbd-kernel gnome-art gnome-chess gnome-pim gnu-smalltalk gnue-appserver gnumach gnumach1 gnuradio gnuradio-examples gnurobbo gnutls10 gnutls7 goldedplus golem gonzui gpsim-led gr-audio-alsa gr-usrp gr-wxgui graph-includes grub2 grubconf grunch gsnes9x gtk-sharp gtkhtml3.6 gtksourceview-sharp gutenbrowser gwydion-dylan gwydion-dylan-sgml gxine haskell-http horgand howl ibm-jdk1.1-installer icheck icukrell id-utils iddev ifrit ikvm imapsync imgtex inform innovation3d innovation3d-plugins interchange ion3-mod-ionflux ipac-ng ipmenu irssi-plugin-icq irssi-snapshot jabberoo jakarta-log4j jetty jmeter jmp jpilot-mail jswat jswat2 kannel kernel-image-2.4.25-amiga kernel-image-2.4.25-atari kernel-image-2.4.25-bvme6000 kernel-image-2.4.25-mvme147 kernel-image-2.4.25-mvme16x kernel-image-2.4.26-amiga kernel-image-2.4.26-atari kernel-image-2.4.26-bvme6000 kernel-image-2.4.26-mvme147 kernel-image-2.4.26-mvme16x kernel-image-2.4.26-q40 kernel-image-2.4.27-hppa kernel-image-2.6.10-alpha kernel-image-2.6.10-amd64 kernel-image-2.6.10-hppa kernel-image-2.6.10-i386 kernel-image-2.6.10-ia64 kernel-image-2.6.10-s390 kernel-image-2.6.10-sparc kernel-image-2.6.11-amd64 kernel-image-2.6.11-i386 kernel-image-2.6.11-ia64 kernel-image-2.6.11-s390 kernel-image-2.6.9-amd64 kernel-image-sparc-2.4 kernel-latest-2.6-s390 kernel-patch-2.4.19-arm kernel-patch-2.6.10-hppa kernel-patch-acl kernel-patch-exec-shield kernel-patch-nfs-swap kernel-patch-powerpc-2.6.10 kernel-patch-powerpc-2.6.11 kernel-patch-scanlogic kernel-patch-uml kernel-source-2.4.24 kernel-source-2.4.25 kernel-source-2.4.26 kernel-source-2.6.10 kernel-source-2.6.11 kimberlite kstart ktrack kurush l2tpd langband langband-data lasso ldmud lftp libaqbanking libaqhbci libcddb libcgi libchipcard2 libflash libgcrypt libgd-perl libgdiplus libgef-java libggz libgig libgwenhywfar libi18n-java liblingoteach libmail-cclient-perl libnsuml-java libopengl-dylan libpam-ccreds libpng-dylan libroxen-floatingcode libsafe libsdl-erlang libsem libspoon-perl libspork-perl libstatgrab libsvn-notify-perl libtext-wikiformat-perl libvpopmail-perl libxmerl-erlang licq-plugin-jonsgtk lids-2.4 lingoteach-lesson lingoteach-sound lingoteach-ui linphone linux-kernel-di-hppa linux-kernel-di-m68k-2.6 linux-wlan-ng linuxsms lmbench localechooser ltp magma magma-plugins mailscanner manderlbot mcs mdbtools mercury micro-inetd micro-proxy mig minit mldonkey mmix mnemo2 mod-mono modxslt mol-modules mol-modules-2.6.10 mol-modules-2.6.11 mono monodevelop monodoc mooix mozilla-locale-it mozilla-locale-lt mozilla-locale-z