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
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 URL: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 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
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 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 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, 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 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 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 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
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 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
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
[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: [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]
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: 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: 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 quickdirty 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 jfs_at_debian.org
# 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 changes should imply version change but not
# the other way around. Since
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 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
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
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 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
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 Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: [Adrian Bunk] The entry packages: was a bug in my quickdirty 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 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 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
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 (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 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
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
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
[Adrian Bunk] The entry packages: was a bug in my quickdirty 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 Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: [Adrian Bunk] The entry packages: was a bug in my quickdirty 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
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
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 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]
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 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
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 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
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
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
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 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
[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
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
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 quickdirty 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
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
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
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
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, 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]
