Warning: glibc 2.3.1 entering testing soon
Sorry about the cross posting. glibc 2.3.1-14 should be entering testing tomorrow (sometime around 30 hours from now, depending on your mirror). Along with it, some 800 other source packages and all their binaries are expected to be updated. For those of you running testing systems, please take care of the next few days' upgrades, as a number of things *will* break. php4 will be broken on all architectures. This will be fixed by the removal of the Conflicts: line from the libc6 packages in a forthcoming revision. It can be worked around by not upgrading until that version of libc6 is available; by upgrading to php4 from unstable; or by manually forcing the dependencies (and not using apt). On sparc, the libc6-sparc64 package has been removed; this will mean you'll be unable to install the versions of gcc-3.0, gcc-3.2, and a number of related packages in testing. This can be worked around by not using the versions of those packages from unstable, or by not upgrading libc6 until new versions of the affected packages have entered testing. On hppa, a number of programs that make use of the __clz_tab symbol will fail to find it. That this symbol is visible was a bug in the toolchain, that has been fixed; unfortunately the fix breaks old software, including, eg, wget, lftp and other programs that link against libcrypto. You can work around this problem by avoiding using the affected programs, by rebuilding them from source, or by not upgrading libc6. Some compatability code will be introduced in the next version of glibc so that this isn't an issue. Similar problems related to other symbols might appear on hppa or other architectures. The problem is believed to have been fixed on i386, but may not have been entirely addressed. Please report problems you find in the usual manner. There may be undiscovered interactions between the software that isn't being updated yet, and the 800 packages that are being updated. Given that so many packages are being updated in a single hit, and that a number of core packages (gcc, perl, python, gnome, kde) will differ between testing and unstable, this is significantly more likely than usual. In short, please take care administering any testing systems you rely on over the next few days. If you wish to put libc6 on hold, you can do so at the command line by: # echo libc6 hold | dpkg --set-selections or by using dselect or aptitude or similar. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] Debian Release Manager pgpMak8aEoSGl.pgp Description: PGP signature
Re: Making sparc CDs bootable?
On Wed, May 01, 2002 at 10:40:35AM -0400, Ben Collins wrote: On Wed, May 01, 2002 at 05:56:03PM +1000, Anthony Towns wrote: On Tue, Apr 30, 2002 at 03:18:28PM -0400, Ben Collins wrote: Yes, read the CVS log. The latest boot-floppies will have this file. Uh, what are these latest boot-floppies of which you speak? Current CVS. I was under the impression that there would be one more boot-floppies release. Uh, no. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpJLGQNAsFrA.pgp Description: PGP signature
Re: Making sparc CDs bootable?
On Tue, Apr 30, 2002 at 03:18:28PM -0400, Ben Collins wrote: Yes, read the CVS log. The latest boot-floppies will have this file. Uh, what are these latest boot-floppies of which you speak? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpFoYYPTe4fl.pgp Description: PGP signature
alpha and sparc boot-floppies
Hi Guys, ] woody/main/disks-alpha/3.0.17-2001-11-20 ] woody/main/disks-arm/3.0.19-2002-02-12 ] woody/main/disks-hppa/3.0.19-2002-02-17 ] woody/main/disks-i386/3.0.19-2002-02-07 ] woody/main/disks-ia64/3.0.19-2002-02-17 ] woody/main/disks-m68k/3.0.19-2002-02-09 ] woody/main/disks-mips/3.0.19-2002-02-12 ] woody/main/disks-mipsel/3.0.19-2002-02-17 ] woody/main/disks-powerpc/3.0.19-2002-02-09 ] woody/main/disks-s390/3.0.19-2002-02-09 ] woody/main/disks-sparc/3.0.16-2001-10-27 Pick the odd architectures out. Be aware that if alpha and sparc boot-floppies aren't uploaded in a timely fashion (and 3.0.19 hasn't been), then any bugfixes y'all may need before release just plain won't be happening. Please upload and test new boot-floppies _right now_. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey pgphvNKMpd4xh.pgp Description: PGP signature
sparc and alpha boot-floppies
Hrm, ] woody/main/disks-sparc/3.0.16-2001-10-27 ] woody/main/disks-alpha/3.0.17-2001-11-20 The current version is 3.0.19 from 2002-02-07. Need I say more? If so, Please get the latest boot-floppies built and uploaded pronto. For reference, mipsel is also significantly out of date, but I at least know someone's doing something about it. hppa and ia64 are a version out of date too. HTH, HAND, TIA. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey pgp9bqCLeEYxb.pgp Description: PGP signature
boot-floppies 3.0.8!
(Huge Cc list, followups to just -release to limit the carnage please) Hi all, Could someone (David? Adam?) please do what's necessary to tag boot-floppies 3.0.8, for initial ia64 and basedebs support? There's still no i386 pcmcia-modules that can be used on boot-floppies! Could someone (Herbert? Randolph? anyone?) *please* build some ASAP? The current pcmcia-modules-2.2.19* in unstable doesn't work with the kernel-image-2.2.19 in unstable. Once these are done, updated b-f's for i386 would be nice. It's not much good getting all this nifty stuff done (basedeb support, task fixups, etc) if no one can use them. It doesn't matter if stuff turns out to be broken: the -testing folk are there to find that out. arm, m68k and sparc boot-floppies are a bit out of date (2.3.6 instead of 3.0.7), and may or may not work anymore. An update would be nice, especially for arches where there's no problem with CPU time (hi Ben :). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpMkzpgFJwNs.pgp Description: PGP signature
dh_suidregister bugs
# netkit-base severity 83022 wishlist severity 84827 wishlist tag 84827 - wontfix merge 83022 84827 # xcdroast severity 83755 wishlist severity 84497 wishlist # (84497 seems a weird bug to have been reassigned) # cgiwrap severity 83834 wishlist # innfeed severity 83859 wishlist # inn severity 84271 wishlist # (also bug 84383, merged) # masqmail severity 84506 wishlist # poppassd severity 84551 wishlist # mailman severity 84554 wishlist # netselect severity 84565 wishlist # ircd severity 84567 wishlist # hanterm severity 84580 wishlist # jfbterm severity 84585 wishlist # opie severity 84590 wishlist # typespeed severity 84672 wishlist # mutt severity 84826 wishlist # osh severity 84870 wishlist # rawrec severity 85195 wishlist thanks These bugs are all package with suid binaries use dh_suidregister, which is now obsolete. This stopped packages from building with debhelper versions = 2.2.12 and 3.0.0. Since the debhelper in testing is 2.2.12, and the debhelper in unstable is 3.0.0, this should mean all these packages should be buildable again, which means none of the above bugs need to be serious anymore (though not all of them were). Using statoverride instead of suidmanager is still a Good Thing, though, so they ought to stay open as wishlist requests. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Autobuilder log pages
Hello world, Please Cc me, I'm not on most of these lists. I guess most (all?) of the ports have autobuilders now days, and I guess most (all?) of them have build logs on the web somewhere. I'd like to add links to build logs from http://auric.debian.org/~ajt/update_excuses.html so that, eg, + aout of date on m68k/a: slocate(2.2-0.0) is a link to the m68k build logs for version 2.4-1 of the slocate source package (or, ideally, a The autobuilder hasn't tried building this package yet because... page when appropriate) to explain why this hasn't built and maybe make it obvious what needs to be fixed. So is there any chance of people telling me urls I can use for this? Something like: http://m68k.debian.org/buildd/logs/slocate_2.4-1_20001201-0800 almost works, except for the _20001201-0800... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 pgpzWI2ywkhmk.pgp Description: PGP signature
Potato revision 2
Hello world, In the next day or so, Ben Collins [EMAIL PROTECTED] will be creating a list of show stoppers for potato revision two. This list will hopefully be maintained for future revisions, and be treated more or less as the release critical bug list has been during the freeze [0]. If there's anything that needs to be done, or that's in the process of being done, that we should be waiting for for r2 rather than leaving until r3 or later, please make sure Ben knows about it. r2 will happen ASAP after that list is emptied. The more detailed the information you can send the better: we need new boot-floppies is better than no! we can't release yet, and I'm preparing new boot-floppies for i386 to fix bugs 32343 55643 and 76432, which will be ready in a day; updates for powerpc are also needed (bug 65653) and Daniel Jacobowitz is taking care of that, but I don't know how long it will take; updates for other architectures aren't urgent is better still. Who's doing it, how long it will take, why it's needed, and why it won't cause new problems would be ideal. For reference, you can consider the list to currently be: Show stoppers for potato r2 ~~~ * Show stopper list needs to be created (Ben Collins) (will be done by around (2000/11/21 12:00 UTC) * 2.2.18 boot-floppies for i386 (Adam di Carlo) (will be done by around (2000/11/22 12:00 UTC) Note further that r2 is expected to happen fairly soon now (days, not weeks) [1]. Cheers, aj [0] ie, we'll try to make sure there aren't any left; but if there are some that don't appear to have any hope of ever being fixed, they'll eventually just get ingored. [1] cf http://lists.debian.org/debian-announce-00/msg00011.html -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpx1mRZ9WSLl.pgp Description: PGP signature
Package pools, testing, 2.2r2
Hello world, debian-cd folk: 2.2r1 is final, even if that'll make some of the powerpc and security folk (justifiably) unhappy. If you'd like to update the potato CD images, that'd probably be a good thing. All who're interested: katie (ie, the new dinstall, ie package pools) will be rolled out when James has enough time to cope with any unforseen problems. Hopefully in the next week or two. testing will be rolled out shortly afterwards, in all probability. debian-cd folk: when katie is rolled out, the debian-cd scripts will probably break [0], it'd be very helpful if this can be fixed ASAP, otherwise we won't be able to provide official CDs for 2.2r2... Porters, X folks, etc: 2.2r2 is likely to come out relatively quickly. Please consider this as your notification, and upload any ports or security fixes or new versions that should make it into r2 sooner rather than later. For those who're interested: we'll see about handling 2.2r2 in a more transparent manner. I'll try to keep auric:~ajt/which-updates as an up to date list of which will get accepted and why others will get rejected, and have it posted automatically to -release once a week. Comments etc should go to -release. Cheers, aj [0] Since the Packages files will start referencing packages and sources in the pool, rather than under dists/potato/... This is actually unavoidable, but we'll try to make sure there are at least symlinks from dists/potato to the pool for anything missing, FWIW. The Packages/Sources files may or may not end up pointing at the symlinks rather than the pool. This will probably first happen sometime after the changeover, but will definitely happen during 2.2r2. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpVQEuiTAISz.pgp Description: PGP signature
2.2r1 recompiles deadline
Hello world, I'm going to stop waiting for updates for 2.2r1 on Saturday this weekend, so anything not uploaded by then will have to wait 'til r2. I'd really appreciate having these compiles done, if possible: I don't like having to treat released architectures as second class :( Anyway, this is the last nag you'll all be getting 'til r2, so that's at least good news, I guess. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp3r8u0FnQRF.pgp Description: PGP signature
2.2r1
Hi guys, I believe quinn-diff is now correctly handling proposed-updates, so if you could please get as much of it autobuild for your respective architectures as possible, it'd be appreciated. The current built/not-built table looks like: barcode: - -i386 m68k powerpc - base-config: - -i386 m68k powerpc - base-passwd: alpha -i386 m68k powerpc - boa: alpha -i386 m68k powerpc - cfengine: alpha -i386 m68k powerpc sparc console-apt: - -i386 m68k powerpc - debconf: - -i386 - -- debiandoc-sgml: - -i386 - -- dedit:alpha -i386 m68k powerpc - dhcp: alpha -i386 m68k powerpc - doc-debian: - -i386 - -- dvi2ps-fontdata: - -i386 - -- emacs20-dl: alpha -i386 m68k -- eruby:- -i386 - powerpc - ethereal: - -i386 m68k powerpc sparc gettyps: alpha -i386 m68k powerpc - glibc:alpha arm i386 m68k powerpc sparc jtex-base:- -i386 - -- kernel-image-2.2.17-alpha:alpha -- - -- kernel-image-2.2.17-compact: - -i386 - -- kernel-image-2.2.17-i386: - -i386 - -- kernel-image-2.2.17-idepci: - -i386 - -- kernel-patch-2.2.17-ide: - -i386 - -- kernel-source-2.2.17: - -i386 - -- liblockfile: - -- - -sparc libpaper: - -i386 m68k powerpc - libtabe: alpha -i386 m68k powerpc - liece:alpha -i386 m68k powerpc - locale-ja:- -i386 - -- locale-zh:- -i386 - -- maildrop: - -i386 m68k powerpc - make: - -i386 m68k powerpc - makedev: - -i386 - -- manpages-ko: - -i386 - -- mew: alpha -i386 - powerpc - mgetty: - -i386 m68k powerpc - modutils: - -i386 m68k powerpc - mule-ucs: - -i386 - -- mule2:- -i386 m68k -- netkit-ntalk: - -i386 m68k powerpc - netkit-telnet:- -i386 m68k powerpc - netscape4.75: - -i386 - -- netscape4.base: - -i386 - -- nis: - -i386 m68k powerpc - ntop: alpha -i386 m68k powerpc - osh: alpha -i386 m68k -- pcmcia-cs:alpha -i386 - -- powerpc-utils:- -- - powerpc - procmail: - -i386 m68k powerpc - readline2:- -i386 m68k -- screen: alpha -i386 m68k powerpc - sendmail-wide:- -i386 m68k powerpc - task-x-window-system-core:alpha -i386 m68k powerpc - tmpreaper:alpha -i386 m68k powerpc - traceroute: alpha -i386 m68k powerpc - xchat:alpha arm i386 m68k powerpc sparc xcin: alpha -i386 m68k -- xfonts-baekmuk: - -i386 - -- xfree86-1:- -i386 m68k powerpc sparc xlockmore:alpha -i386 m68k powerpc - xpdf: alpha -i386 m68k -- yaboot: - -- - powerpc - zope: - -i386 m68k powerpc - zsh: alpha -i386 m68k powerpc - There may be some false positives in that table is multiple versions of a package have been uploaded, and only an older version of the package has been build for an architecture. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp0qFvk0a7Nt.pgp Description: PGP signature
potato
Hi guys, Since both dark and I have been absent for the last week or so the number of RC bugs has ballooned outrageously, and some of your uploads and such have been left sitting in incoming, and as such the release hasn't gotten significantly closer. Sorry about that. :( In any event, we'll hopefully get incoming cleared out shortly, and have i386 done in a day or two. Hopefully. How does this leave everyone else? A few days ago sparc needed to do a whole bunch of recompiles. Have these been done? Are there any similar things that other archs have only just discovered they need to do and are just doing now? At this point, as far as i386 is concerned I expect most problems will be ignored, save for maybe a couple of removals, a couple of upgrades, and a handful of security fixes which will probably still be being added at a fairly late stage. On an only marginally related matter, I'd appreciate it if y'all could get woody autobuilders happening fairly promptly and effectively by the time potato releases. If there are hardware or bandwidth problems, it'd be nice to resolve these ASAP, rather than JIT... Please note the excessive cross-posting, and edit your followups to suit. I'm not on most of these lists, so if there's something I need to know that's not appropriate for -release, please cc me. Thanks. Cheers, aj (acting release manager) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpuGxtNhTrBs.pgp Description: PGP signature
.debs uploaded to frozen/unstable only going into unstable?
Hello world,
(Cc'ed to the two ports that are most affected)
It seems that some of the autobuilt packages intended for frozen and
unstable both are only getting added to unstable.
For example:
[EMAIL PROTECTED] ~]$ ls
{woody,potato}/main/{binary-alpha,source}/*/alevt*.???
potato/main/binary-alpha/x11/alevt_1.5.1-3.deb
potato/main/source/x11/alevt_1.5.1-4.dsc
woody/main/binary-alpha/x11/alevt_1.5.1-4.deb
woody/main/source/x11/alevt_1.5.1-4.dsc@
Note that the sources are the same (and even symlinked appropriately), but
the potato .deb is out of date. The .diff.gz includes frozen unstable
in the changelog, so I can't see any *obvious* reason why this would
happen.
The stats (numberr .deb's in woody that should be in potato as well) are:
157 alpha
0 i386
21 m68k
19 powerpc
203 sparc
Anyway, the complete list of .debs (as generated by [0]) is at
http://master.debian.org/~ajt/woody-not-potato.txt
Cheers,
aj
[0] for a in woody potato; do
for b in alpha i386 m68k sparc powerpc; do
echo $a $b;
(cat $a/main/binary-$b/Packages; echo) |
sed 's/^source: \([^ ]*\) (\([^)]*\))$/source: \1 \2/' |
awk '/^Package:/ {P=$2; S=P} /^Version:/ {V=$2; SV=V};
/^source:/ {S=$2; if (NF == 3) SV=$3}
/^$/ { print S, SV, P, V }' |
sort $a.$b;
done;
done
for a in woody potato; do
echo $a;
(zcat $a/main/source/Sources.gz; echo) |
awk '/^Package:/ {S=$2} /^Version:/ {SV=$2} /^$/ {print S, SV}' |
sort $a.source;
done
for a in potato woody; do
for b in i386 alpha sparc m68k powerpc; do
echo $a $b;
perl -e 'open S, potato.source;
while(S) { chomp; @x = split / +/;
$srcv{$x[0]} = $x[1]; }
close(S);
while() { chomp; @x = split / +/;
if ($x[1] eq $srcv{$x[0]}) { print $_\n; }
}' $a.$b $a.$b.match;
done;
done
for a in alpha i386 m68k powerpc sparc; do
diff potato.$a.match woody.$a.match | sed -n 's/^ //p' diff.$a;
done
for a in alpha i386 m68k powerpc sparc; do
echo $a:;
cat diff.$a |
while read s sv p v; do
printf %s %s\n $p $v;
done |
sort;
echo;
done
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgpWcnVUxWCWT.pgp
Description: PGP signature
netbase 3.15-4 ports?
Hello world, Is netbase 3.15-4 failing to compile on sparc and/or alpha, or have the build daemons simply not gotten around to it yet? If the former, are there any failure logs I can check? Thanks, aj, who notes that m68k seem to have the power... ;) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpcP4OeuaIsS.pgp Description: PGP signature
