Hint 'lam'
hint lam/7.0.4-2 Won't work until scalapack builds on mips, but that appears to be just a matter of time. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: Package removal proposals
Josip Rodin wrote: > On Sat, Mar 20, 2004 at 03:22:20PM -0500, Nathanael Nerode wrote: >> remove dict-jargon/4.4.4-4 >> FTBFS (#229435). Eventually it will be fixed and it can go in again, of >> course. > > Um. It's Architecture: all. So what? It still has source and object files, since it generates stuff from XML. > Surely not all problems need to be resolved with an axe? As I said, "Eventually it will be fixed and it can go in again, of course." Do you want to release with packages which don't build from source? That is the only question here. No prejudice against the package. -- Make sure your vote will count. http://www.verifiedvoting.org/
Package removal proposals
I'm getting more aggressive as time goes on. All of these have RC bugs which affect the package in Sarge and have been open since at least January. I ignored patched and pending bugs, although I'll probably send a different message to a different list asking for NMUs of those. I also ignored bugs in some packages which can't reasonably be removed (like glibc, util-linux, ssh...) :-( Some of these expose, uh, "non-technical" problems preventing fixed versions from going in, but I can't say what to do about those; only that the current versions are not OK for release, and will probably release if they aren't removed. :-P Of course, it's also possible that some of these bugs shouldn't be release-critical; I leave it to debian-release to decide if some of these should be downgraded (I didn't think so). remove atmelwlandriver/2.1.1-3.3 #229159, maintainer apparently doesn't have time to work on it. Also 205419, 210559, 214775, 207182,... Three consecutive NMUs, too. remove dict-jargon/4.4.4-4 FTBFS (#229435). Eventually it will be fixed and it can go in again, of course. remove dovecot/0.99.10.4-2 #225048 (data loss). remove drivel/0.9.1-4 #226492. There's a packaged new upstream version, and if someone will sponsor an upload, it will be fixed, but in the meantime remove gkrellongrun/0.6.1-2.2 #190882 (doesn't work) remove kronolith/1.1-1 #227461 remove cal3d/0.9-1.3 library packaged without proper soname (#213588) remove libpng-dylan/2.3.10-4 #221074 (FTBFS), ignored by maintainer also #238928, which makes it unreleasable remove gnome-db2/0.12.1-2 #228893 remove mirrormagic/2.0.2-3 #229747 remove pointless/0.4-3 #221342 (latex2html, maintainer not doing anything) remove sendmail/8.13.11.Beta0-1 #227464 (doesn't respect DEBIAN_FRONTEND=noninteractive or use debconf) Also #232664 remove zope/2.6.4-1 #222443 That is all. (xemacs21 would be on this list, but the last versions in sarge actually don't have any of the current RC bugs. Which is a sort of victory for the 'testing' scripts. Of course, this is because no version has gotten into 'testing' since woody) -- Make sure your vote will count. http://www.verifiedvoting.org/
Upgrade only supported from most recent point release
Adrian Bunk wrote: > This will ensure _nothing_. > > It's supported that users upgrade from Debian 3.0r0 to 3.1. Unfortunately, I think that already isn't supported. If I'm not very much mistaken, there are several things which simply will not work without an intermediate upgrade to 3.0r2 -- or, indeed, in some cases, the not-yet-released 3.0r3. Most notably, support for real i386 machines. I believe support for MIPS has a similar problem. (These are due to interactions between the kernel and libc, such that a newer kernel than is present in 3.0r0 is required in order to upgrade libc successfully. I believe that in the case of i386, the newer kernels are not yet present in woody, only in woody-proposed-updates.) So I think it's sufficient to document all cases where this is required in the release notes for 3.1. Disgusting though it is. > I don't know much about the PostgreSQL packaging, but a working upgrade > from Debian 3.0r0 to Debian 3.1 is definitely a must, Too late. :-( > and a non-working > database upgrade is without question RC. -- Make sure your vote will count. http://www.verifiedvoting.org/
Suggest removing irssi-plugin-icq from sarge
remove irssi-plugin-icq/0.2-2 #232702, request of maintainer -- Make sure your vote will count. http://www.verifiedvoting.org/
remove wesnoth from testing (copyright issues)
remove wesnoth/0.6.99.4-1 Bug #238191 -- Make sure your vote will count. http://www.verifiedvoting.org/
Suggest removing gkrellongrun
remove gkrellongrun/0.6.1-2.2 Bug #190882. -- Make sure your vote will count. http://www.verifiedvoting.org/
Remove svn-devscripts from sarge?
remove svn-devscripts/0.3.5 See bug number #237077 -- this is now a dummy package and was never a real package in Sarge, existing only for upgrades of people using sarge or sid it sounds like a good candidate for removal. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: More removal suggestions
Igor Genibel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Le Friday 12 March 2004 02:27, Nathanael Nerode a écrit : > >> remove dovecot/0.99.10.4-2 >> #225048 (data loss) and #232832 > > Could you explain your motivation about dovecot ? > The upstream seems to be active and aware > ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225048 ) > and the maintainer too ... > The package is up to date (same as the upstream). I don't think it's reasonable to release the current version, and the bug has sat at 'grave' since February 11 (a full month) with no visible progress. There has to come some point at which one decides that a package with grave bugs shouldn't be included in the release, doesn't there? If you think it's just fine to release sarge containing dovecot in this data-lossy condition, well, then it shouldn't be removed from sarge. However, it sounds like a bad idea to me. -- Make sure your vote will count. http://www.verifiedvoting.org/
More removal suggestions
remove boot-icons/0.2 Request of the maintainer, a.k.a. bug 235862 remove dovecot/0.99.10.4-2 #225048 (data loss) and #232832 -- Make sure your vote will count. http://www.verifiedvoting.org/
Suggest removal of icecast2 from testing
remove icecast2/1.9+2.0alphasnap2+20030802-1.2 Bug #229720; the 'license-clean' version still hasn't been uploaded, and the 'license-dirty' version shouldn't be released. -- Make sure your vote will count. http://www.verifiedvoting.org/
Cycle preventing removal
* cl-uncommonsql can't be removed because it breaks cl-local-time-db * cl-local-time-db is from the cl-local-time source package (only in testing) * cl-local-time can't be removed because it breaks cl-metadata * cl-metadata is from the cl-uncommonsql source package in testing We appear to have deadlock. Is it possible to hint a joint removal? If not, this may require manual intervention. -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
More removal suggestions
I see that all my earlier suggestions have been dealt with. Cool! ==> remove kmusicdb/0.8.2-4 KDE2 dependency, uninstallable. ==> remove ksensors/0.7-6 KDE2 dependency, uninstallable. A new version can eventually go in when the lm-sensors mess is sorted out (which see below), but it's not clear whether that will happen before or after sarge releases. Aurelien Jarno <[EMAIL PROTECTED]> is dealing with the lm-sensors mess. * He adopted the related packages and uploaded new packages which are now waiting in NEW. * He filed a removal request for the obsolete i2c packages (#235490). * http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg02038.html includes an outline of the remaining steps, which need to wait for the NEW packages to be accepted. --- The other uninstallable packages on i386 are mostly dependent on postgresql via nagios and should hopefully clear up when new postgresql goes in. The exception is vlc-arts. For a new version of vlc to go in, new arts, xfree86, and libggi have to get in, all of which have their own problems. Hopefully those will clear up too, though... -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Removal-from-testing proposals, current version
I've been suggesting removals, because at the moment, all the major hintable logjams for packages entering have been cleared. (Which is quite cool.) (You can tell this by noticing that most of the packages at the top of http://bjorn.haxx.se/debian/toplist.html are there because they have actual RC bugs.) So, on to removing packages which simply shouldn't release with sarge. First, the new ones. -- These were found by analyzing the packages which were uninstallable in testing on i386. I skipped those which were due to out-of-date binaries, and those involved in the nagios/netsaint and lm-sensors messes; although I might look at those later, at the moment they appear to be 'in progress'. I also skipped those where some binaries were installable and others weren't, on the grounds that that would do more harm than good. remove libmail-cclient-perl/1.5-2 Unsatisfiable (depends on long-ago-removed package). Also, out of date. remove python-pcgi/1.999a5-3 Uninstallable (depends on removed package). remove showimg/0.7-3 Uninstallable (depends on kde 2 libs) -- The following were found by trawling the RC bug list starting with packages beginning with 'l'. I still skipped bugs reported in February (there are a lot of them!) By the way, there's a messy issue with gtkgl2 -- it appears to be breaking everything linked with it. See 227477. remove pgeasy/1:3.0.1-2 No copyright. Now, this is probably going to be cleared up eventually, but you don't want to release sarge with it in this state. remove gnome-db2/0.12.1-2 "Constantly crashes" for one submitter (#228893); "doesn't do anything" for another (#222960); nasty coding error likely to kill all 64-bit arches (#226524); plus more bugs. No maintainer reply to any of them for long periods. Only downside is that gnome-office depends on it. But it doesn't work, so remove netsaint-nrpe/1.2.4-4 Already supposed to be removed. Also being removed from unstable. Apparently stalled because it's non-US, perhaps? remove sleuthkit/1.61-4 #205313 (FTBFS). Also, there's been a newer release for a long time (#221713), plus #196834 (improper directory search locations) and other bugs. The maintainer hasn't replied to any of the bug trails, and may be MIA. remove xfdeskmenu4/4.0.0+cvs.20021222-2 #229943, plus, without xfce in sarge, what's the point? -- And these are from researching the old removal suggestions, and existing non-functioning removals: remove gnopernicus/0.7.1-1 This is needed in order to remove gnome-mag. It's "still experimental" and there is no official release yet, so this shouldn't be a terrible loss in its current state. remove erlang-slang/1.0-3 See below; 1.0-2 was not the correct target version. :-P Unfortunately it's non-US... -- Now, the old ones, from http://lists.debian.org/debian-release/2004/debian-release-200402/msg00060.html: remove amavis-ng/0.1.6.2-1 Note that this will also allow the removal of suidmanager to work. remove anubis/3.6.2-2.1 remove cl-uncommonsql/1.1.8.5-1 remove debian-guide/1.1.0 remove debian-guide-zh/0.6 remove erlang-mode/2.3-2 remove erlang-slang/1.0-2 Looks like this worked -- but it was the wrong version... see above remove gnome-mag/0.10.2-1 'vorlon' has a note saying that this 'can't be removed', but see above remove kernel-image-2.4.18-i386bf/2.4.18-5 remove kernel-patch-2.4.17-s390/0.0.20020816-2 remove kernel-image-2.4.17-s390/2.4.17-3 remove rcconf/1.6 -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Removal-from-sarge proposals
This is based on a trawl of the RC bug list from http://bts.turmzimmer.net/list.html. * I skipped all bugs reported in February. * I skipped some bugs related to latex2html (mostly out of laziness). * I skipped 'pending' bugs. Out of the remaining ones, I looked at them by hand to see which ones appeared to merit immediate removal from sarge. remove amavis-ng/0.1.6.2-1 Too many RC bugs, open too long. remove anubis/3.6.2-2.1 #217148. Also #218471. The maintainer, [EMAIL PROTECTED], appears to be MIA as well. remove cl-uncommonsql/1.1.8.5-1 #217709. Orphaned and dead upstream. Adam di Carlo (ex-maintainer) is planning to ask to have this removed from unstable. remove debian-guide/1.1.0 #229425. Osamu noted that it was for Potato, as well. remove debian-guide-zh/0.6 #229425, and see debian-guide. remove erlang-mode/2.3-2 #215198: It's obsolete. remove erlang-slang/1.0-2 #201151 (FTBFS). Maintainer apparently MIA. remove gnome-mag/0.10.2-1 #218776: "Does not work". remove kernel-image-2.4.18-i386bf/2.4.18-5 #201459 (FTBFS) and 225604 (removal). This appears to be a boot-floppies kernel, which is useless in sarge. Also, the maintainer isn't replying to the bug trails (boo hiss). remove kernel-patch-2.4.17-s390/0.0.20020816-2 #212099 (unsatisfiable build-depends). Maintainer failed to comment for months. Also #203521 (fails to apply). remove kernel-image-2.4.17-s390/2.4.17-3 Build-depends on the above. I ran out of time around 'l' except for this one I happened to notice: remove rcconf/1.6: #218951 Thomas Hood described it as "an experimental POS with potential". -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Stronger hint suggestions
Thanks to Riku Voipio for the basis of these suggestions (http://lists.debian.org/debian-qt-kde/2004/debian-qt-kde-200402/msg00222.html) These should not really be done immediately; as noted below, there are two days left to wait even if all these hints are used, including the impossible 'urgent' hint, and who knows, maybe lots of other stuff will be fixed by then (though I doubt it). ==> remove redland/0.9.14-5 Having the jack-audio-connection-kit transition linked to the perl problems is just not a good idea. This breaks that otherwise-unnecessary piece of linkage. After jack goes in, redland will just wait for perl. ==> remove libjackasyn/0.9-2 The new version has to wait ten days and be rebuilt on all architectures; and we have to hope that no new bugs show up in that time. In contrast, if it's removed from testing, the new version will probably go in just as quickly *after* jack, but it will not hold up anything else. ==> urgent gst-plugins/0.6.4-4 This would let it go in sooner than 7 days from now, if such a hint was available. ;-) Ardour and gst-plugins have their missing builds happening right now, which should therefore be done fairly soon, hopefully within the week. That would leave the 2-day wait on spiralsynthmodular, which will probably be done by the time the ardour and gst-plugins builds are uploaded. If I sound over-eager to get this done, it's because of this: once the jack-audio-connection-kit mess goes in, kdebase and kdegames 3.1.5 will go in, and then kdeaddons 3.1.5 will go in -- and kdeaddons is still at version 2.2.2 in sarge. In other words, this will allow there to be a version of KDE 3 entirely present in sarge for the first time, accomplishing an important release goal and allowing everyone to relax. :-) -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Hints, round n of m
First of all, thanks to Colin Watson, Steve Langasek, and the other hard-working people who have implemented my suggestions for all their good work. :-) ==> remove mindi/0.86-2 Contains sourceless binaries for GPL'ed programs in the source package -- hence, not DFSG-free and likely undistributable in its current form. Apparently the maintainer and someone else are "working on it", so Martin apparently has decided not to file ftp.debian.org bugs yet. However, the current version really, really, should *not* be released. It's mostly intended for use with mondo anyway, which isn't in testing and won't be until it's repackaged (for similar reasons plus others). ==> urgent libjackasyn Um, yeah, I know there isn't such a hint yet, but if there was, this would be a good idea. Otherwise we have to wait another 10 days when all that changed was a Build-Depends. -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
New hint suggestions
==> easy python-qt3/3.8-3 sip-qt3/3.8-2 qscintillia/1.2-4 Should work immediately, now that qt-x11-free is in. ==> remove libhydrogen/0.8.0-4 Needed for jack-audio-connection-kit transition, which holds up a lot of stuff. I have suggested those before. ;-) Thanks to Steve Langasek, my other previous suggestions have all gone in and been successful. :-) ==> remove logtrend-visuapache/0.82.2-1 Necessary to remove libgd-perl. (Although, come to think of it, why was libgd-perl being removed again?) -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Breaking the jack-audio-connection-kit deadlock...
So, from update_output.txt, these are the packages which 'need work' for the jack-audio-connection-kit hint to work. (Each item has underneath it the items upon which it depends, like an outline.) A lot of packages needed requeuing. I sent messages for the arm, mips, mipsel, and s390 packages which appeared to need it. One package needs to be removed from testing (libhydrogen, as mentioned before). Two packages appear to have actual build bugs (and I filed the bugs). * ardour-gtk, ardour-ksi, libardour0, libardour0-dev (source package ardour): -- needs build on arm needs requeue -- waiting for libxml2, which should go in tomorrow -- waiting for raptor waiting for curl, which should go in in 3 days * ecamegapedal -- needs build on arm needs requeue -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up -- needs build on s390 needs requeue * ecawave -- needs build on arm needs requeue -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up -- needs build on m68k in progress -- needs build on s390 needs requeue * gstreamer-jack, gstreamer-plugins (source gst-plugins) -- needs build everywhere actual build problem; I filed a bug. -- waiting for mpeg2dec, which should go in in 6 days * hydrogen -- needs build on mips needs requeue -- may need Ryan Murray to wake up -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up * jack-rack -- needs build on mips needs requeue -- may need Ryan Murray to wake up -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up * libhydrogen0, libhydrogen0-dev (source package libhydrogen) -- According to Junichi, this needs to be *removed*. > remove libhydrogen/0.8.0-4 * meterbridge -- needs build on mips needs requeue -- may need Ryan Murray to wake up * qjackctl -- needs build on mips needs requeue -- may need Ryan Murray to wake up -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up * rezound -- needs build on mips needs requeue -- may need Ryan Murray to wake up * spiralsynthmodular -- needs build on s390 My goodness! An actual build problem! I filed a bug. I won't worry about the other buildd issues for now, since a new version will presumably need to be uploaded. * tapiir -- needs build on mipsel needs requeue -- may need Ryan Murray to wake up * terminatorx -- waiting for libxml2, which should go in tomorrow * zynaddsubfx -- needs build on m68k not tried yet, queued -- needs build on mips queued -- needs build on mipsel built, needs upload -- may (or may not) need Ryan Murray to wake up -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
More obsolete hints
These hints are also all obsolete. >Hint from ajt: perl/5.8.2-2 > Version mismatch, perl 5.8.2-2 != 5.8.3-1 >Not using hint >Hint from ajt: zlib/1:1.2.1-3 > Version mismatch, zlib 1:1.2.1-3 != 1:1.2.1-4 >Not using hint >Hint from ajt: pilot-link/0.11.8-7 >leading: pilot-link >Hint from ajt: mozilla/2:1.5-3 > Version mismatch, mozilla 2:1.5-3 != 2:1.6-1 >Not using hint >Hint from ajt: jack-audio-connection-kit/0.75.0-2 alsa-lib/0.9.8-2 > Version mismatch, jack-audio-connection-kit 0.75.0-2 != 0.94.0-1 > Version mismatch, alsa-lib 0.9.8-2 != 1.0.1-1 >Not using hint -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Obsolete hints
These hints have all worked and are done and can be removed. >Easy hint from ajt: glibc/2.3.2.ds1-10 linux-kernel-headers/2.5.999-test7-bk-9 >linuxtv-dvb/1.0.1-6 > Version mismatch, glibc 2.3.2.ds1-10 != 2.3.2.ds1-11 > Version mismatch, linux-kernel-headers 2.5.999-test7-bk-9 != > 2.5.999-test7-bk-15 >Not using hint >Easy hint from ajt: nurbs++/3.0.11-3 innovation3d/0.66+0.20030401-1 > Version mismatch, nurbs++ 3.0.11-3 != 3.0.11-4 > Version mismatch, innovation3d 0.66+0.20030401-1 != 0.66.1-1 >Not using hint >Easy hint from ajt: ghc5/5.04.3-6 c2hs/0.12.0-1 >leading: ghc5,c2hs >Easy hint from ajt: aspell-pt/0.50-2-2 br.ispell/2.4.really.3.0.beta4-4 > Version mismatch, aspell-pt 0.50-2-2 != 0.50-2-3 > Version mismatch, br.ispell 2.4.really.3.0.beta4-4 != 2.4.really.3.0.beta4-5 >Not using hint >Easy hint from ajt: webmin/1.121-1 -webmin-core/1.100-1 -webmin-raid/1.100-1 > Version mismatch, webmin 1.121-1 != 1.130-1 >Not using hint >Easy hint from ajt: vim/1:6.2-149+1 vim-latexsuite/0.20031113-1 > Version mismatch, vim 1:6.2-149+1 != 1:6.2-214+1 >Not using hint >Easy hint from ajt: krb4/1.2.2-10 cyrus-sasl2/2.1.15-6 heimdal/0.6-4 > Version mismatch, heimdal 0.6-4 != 0.6-5 >Not using hint >Easy hint from ajt: ire/0.90.0-2 ire-rotj/1.02-3 ire-the-flat/0.90.0-3 > Version mismatch, ire-rotj 1.02-3 != 1.02-4 >Not using hint >Easy hint from ajt: php4/4:4.3.3-4 mm/1.3.0-1 smstools/1.12.5-1 > Version mismatch, php4 4:4.3.3-4 != 4:4.3.3-5 > Version mismatch, smstools 1.12.5-1 != 1.13-1 >Not using hint >Easy hint from vorlon: libpcd/1.0.1 fbi/1.28 > Version mismatch, fbi 1.28 != 1.30 >Not using hint --- (The following hints have not yet worked, and need to be kept): >Easy hint from rmurray: opie-base-fb/1.0.1.1snapshot20030828-2 >opie-applets-fb/0.9.1-0.snapshot.20030303-2 >opie-apps-fb/1.0.1.1snapshot20030828-2 >opie-comnet-fb/1.0.1.1snapshot20030828-1 >opie-games-fb/1.0.1.1snapshot20030828-1 >opie-inputmethods-fb/1.0.1.1snapshot20030828-2 >opie-multimedia-fb/1.0.1.1snapshot20030828-5 opie-pim-fb/0.9.3-1 >opie-settings-fb/0.9.1-0.snapshot.20030303-2 >opie-themeing-fb/0.9.1-0.snapshot.20030303-3 >opie-tools-fb/0.9.1-0.snapshot.20030303-2 >leading: >opie-base-fb,opie-applets-fb,opie-apps-fb,opie-comnet-fb,opie-games-fb,opie-inputmethods-fb,opie-multimedia-fb,opie-pim-fb,opie-settings-fb,opie-themeing-fb,opie-tools-fb >Easy hint from vorlon: openmotif/2.2.2-6 motv/3.88-1 >leading: openmotif,motv -- Nathanael Nerode US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/
Mipsel not keeping up?
The lone mipsel buildd appears to be suffering all manner of problems. Perhaps it's time to admit that mipsel isn't keeping up right now? :-P -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: 3.0r3
Martin Schulze wrote: >Joel Konkle-Parker wrote: >> According to http://people.debian.org/~joey/stable.html, 3.0r3 is due to >> be cut pretty soon. >> >> How's it looking? > >It'll probably be mid or end of February. > >Regards, > >Joey Is it possible to get the boot-floppies from unstable (which are the ones *used* in woody) pushed into this release? Or if new boot-floppies are going to be used, to make sure they're actually *in* woody? The problem here is that the boot-floppies package currently needs to stay in unstable because it's apparently the only copy of the source for the version used in woody. It would be desirable to remove it from sid, but that can't really be done unless this is dealt with. See debian-boot for more details. Thanks for your time.
Hinting suggestions, latest edition
Renders all previous editions obsolete. ;-) ==> remove ida/0.12 ==> easy libpcd/1.0.1 fbi/1.28 ==> easy openmotif/2.2.2-6 motv/3.88-1 ida is the linchpin which makes this such a mess. It's also a contrib extra package, and version 0.12 is two years out of date. The other four have been held up for wy too long by a complex web of dependencies, and if you wait, they'll probably get enmeshed in more dependencies. :-P Once they're cleared up, new ida (0.20) can go in as soon as new curl does (which needs 10 days and builds). ==> remove encompass/0.4.99.30-5 Allows neon & subversion in. There's a new encompass already, but it has to wait for gtkhtml3.0 -- breaking the link is worthwhile. ==> remove iraf/2.11.3-2 See previous messages -- you might already have done this. ==> easy petsc/2.1.6-2 illuminator/0.6.9-2 The maintainer is really frustrated that these aren't in yet, after all his hard work. And they do need to go in together, not one at a time. According to bjorn.haxx.se, illuminator is out of date on mipsel. But it's already built there (on Monday), and is apparently just waiting for some buildd person to upload the file. :-P ==> remove libhydrogen/0.8.0-4 Junichi Uekawa wrote "this package is going to be removed". I don't know if he meant from testing or from testing & unstable, but it certainly wouldn't hurt the process to remove it from testing. ==> easy sip-qt3/3.8-2 python-qt3/3.8-3 qscinitilla/1.2-4 These need to go in together. (This presumably won't work until qt-x11-free/3:3.2.3-2 goes in -- see below) ==> wait for qt-x11-free/3:2.3-2 to go in It currently needs * two days * a build on mipsel (it's second in the needs-build queue) * an upload on arm (it's built but not uploaded, it seems?...) ==> somehow, complete jack-audio-connection kit 0.94 transition Ow. This requires: * the removal of libhydrogen * builds of a *lot* of packages * waiting for new curl to go in (10 days & builds) * some complex hint which isn't worth worrying about until the above happens KDE depends on this mess (via alsa-lib), sadly. :-( Hopefully thanks to Junichi's freeze there will be no new uploads of anything in this mess (except to fix build failures or RC bugs) until kdemultimedia gets in. :-) -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Removing encompass from testing?
>IMHO encompass should be dropped from testing. > >Opinions? I suggested this several days (weeks?) ago because I *anticipated* encompass keeping neon (and hence subversion) out of sarge. Note that apart from whatever problems encompass itself has, it is stuck until gtkhtml3.0 is fixed, and gtkhtml3.0 seems to have had a *lot* of trouble. And I noticed that a while ago too. :-) Of course encompass should be removed from testing (just for now, in order to allow more important things in). => remove encompass/0.4.99.30-5
Testing scripts & hints not publically available any more
http://ftp-master.debian.org/testing/update_out_code/ http://ftp-master.debian.org/testing/hints/ "Forbidden". Please (a) reenable these, and (b) link them from somewhere appropriate (such as http://www.debian.org/devel/testing). Thank you. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Consider removing iraf from testing
==> remove iraf/2.11.3-2 #223543: FTBFS -- requires a bootstrap process which doesn't autobuild #223532: Major FHS violation -- files under /usr/iraf #218793: ships /usr/bin/xpp, conflicting with xpp package (with no Conflicts, even). Oh, it also has installation errors (#223528), dangling symlinks (#138086), and bad dependencies (#168867). The maintainer is supposedly working on these issues with someone who he "hopes" will become the future maintainer. As of December. God only knows when that will happen. The current version just isn't releasable; it needs to be removed from sarge. It may be more reasonable to remove the package entirely, from sid as well, despite the maintainer's statements of intent -- that's why this is CC:ed to QA. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Revised hinting suggestions
These hints really should go in ASAP; I'm waiting to see how things work out on some of the other groups, which still have RC bug issues. ==> easy libdumbnet/1.7-3 libevent/0.7c-1 farpd/0.2-4 fragroute/1.2-7 honeyd/0.6a-4.1 labrea/2.5-stable-1 trickle/1.06-4 stegdetect/0.5-5 This should work *now*. And all of these except honeyd have been waiting quite a while. (If it doesn't work, try "hint libdumbnet/1.7-3 libevent/0.7c-1") ==> remove ida/0.12 This package ties up libpcd, openmotif, fbi, motv. I had suggested some easy hints for getting them all in, but since then a new ida has been uploaded, and a new curl (on which ida depends) has been uploaded with RC bugs. Dammit. If ida is removed, at least libpcd, openmotif, fbi, and motv, which have all been ready to go for MONTHS, can get in. :-P ==> easy petsc/2.1.6-2 illuminator/0.6.9-2 The maintainer is really eager to get these in and has fixed oodles of other packages in order to get it working (his packages themselves have been in good shape for a long, long time). Currently it needs a build on mips and six days; by the time you get to this I expect that will have happened. ==> force nvidia-graphics-drivers/1.0.5328-4 The problem is that this is non-free with unsatisfiable depends and will *never* go in manually. 5328 is needed for out-of-the-box 2.6 kernel support, which is worth having for sarge. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Force nvidia-graphics-drivers in
==> force nvidia-graphics-drivers/1.0.4496-10 The testing scripts still don't recognize that non-free packages can depend on packages not in Debian, so there's no other way to get this in. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Suggest hinting libdumbnet, libevent
==> hint libdumbnet/1.7-3 libevent/0.7c-1 These two need to go in together becuase honeyd, fragroute, and farpd depend on both. Honeyd has some build problems due to timestamp skew/automake invocation issues, so the hint won't work until that's fixed, but that should be fixed pretty soon. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Suggest removing encompass to allow neon in
==> remove encompass/0.4.99.30-5 This will allow neon/0.24.4-1 to go in. (Which subversion depends upon.) Theoretically, encompass/0.5.99.3-2 can then be allowed in, but it depends on gtkhtml3.0, which is broken. I don't particularly feel like telling subversion people that their package will need to be kept out because gtkhtml3.0 is broken. :-P -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Consider hinting libpcd, openmotif
hint libpcd/1.0.1 openmotif/2.2.2-6 These two need to go in together because of ida. It won't work until ida/0.20 gets built on arm and m68k, but hopefully that will happen soon.
Getting jack & company in
For jack-audio-connection-kist to go in, assuming nothing is removed, a lot of stuff *still* has to happen first. I'm going to draw this as a dependency tree, where under each item are the items which need to happen first. ==> hint jack-audio-connection-kit/0.75.0-2 alsa-lib/0.9.8-2 ladcca/0.4.0-1 ==> Build gem 0.87cvs20031021-1.1 on all arches ==> Build linux-kernel-headers on alpha, hppa, ia64, s390 ==> Get puredata 0.37.cvs-10/s390 (built) into the pool ==> Build ecasound2.2/2.3.1-1 on arm, sparc, m68k, s390 ==> Get python2.3/2.3.3-4 compiled on arm, sparc, m68k, s390 ==> Fix fftw3 build bug #225960 If you want to get jack-audio-connection-kit in *today*, on the other hand, I believe you have to do the following. I checked and there don't seem to be any packages depending on the packages I suggest removing, so this should work. # This needs new linux-kernel-headers before building. remove gem/0.87-5.2 # These two depend on ecasound2.2, which waits for python2.3. remove ecamegapedal/0.4.1-3 remove ecawave/1:0.6.0-6 # This depends on fftw3, which still needs work remove freqtweak/0.4.8-1 # It looks like if these three libraries go in, everything else # will become installable, even puredata and pd-externals. hint jack-audio-connection-kit/0.75.0-2 alsa-lib/0.9.8-2 ladcca/0.4.0-1 This is almost certainly worth it, given the sheer number of packages waiting for alsa-lib and jack-audio-connection-kit (including significant parts of GNOME and KDE). -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
How to get emacs20 removed from testing
I notice emacs20 has been trying to be removed for a while. In order to make this work, you need to remove eshell/2.4.2-6 remove w3-el/4.0pre.46-18 remove emacs20/20.7-13.1 W3-el and eshell are packages for emacs20 (only). The packages serve no function with emacsen other than emacs20. Eshell is now part of the core of emacs21, while there is a separate w3-el-e21 package for using w3-el in emacs21.
More hinting (simple removal) suggestions.
==> remove rocks-n-diamonds/2.0.0-0.2 May not be distributable; see bug #210233 ==> remove mindi-kernel/1.0-1 No source; see bug #217160 ==> remove kernel-image-3.4.18-i386bf Boot-floppies image, useless in sarge ==> remove iraf/2.11.3-2 FTBFS, major FHS violation, binary with same name as one in other package, plus more. The maintainer is "working on" things with a person who he "hopes" will become the new maintainer. If that accomplishes something, a new version can always go in; the current version is just not acceptable, and there's no timetable for the fix.
Re: clearer hinting suggestions.
On Wed, Dec 31, 2003 at 02:01:34AM -0500, Nathanael Nerode wrote: ==? Ignore RC bugs for kdebase/4:3.1.4-1 Neither of the RC bugs are present in sid (only in woody); it seems to be a failing of the current 'testing' scripts that they don't recognize this, given that both bugs are tagged 'woody'. Actually, those ones are being ignored. Look down to the "pending upload" bugs; those are the problems. I'm confused. Ah! Found it. The kdm bugs. OK. :-)
Clearer hinting suggestions.
AJ, thanks for the pointer to http://ftp-master.debian.org/testing/hints/README; I'd never seen it before, because it isn't linked to by anything. ==? reassign bug 224599 (and mergee 224602) to nvidia-glx or something These are known not to be bugs in the python-qt3 package. The maintainer is currently waiting for feedback from the submitter to figure out which package it needs to be reassigned to (probably nvidia-glx). ==> easy python-qt3/3.8-2.1 sip-qt3/3.8-2 qscintilla/1.2-3 This can be done after the reassignment. ==? Solve lm-sensors / i2c nightmare Yeah, not really the problem of -release -- I sent a message to the maintainer and debian-devel about this after about six hours of working out what was wrong. ==? Ignore RC bugs for kdebase/4:3.1.4-1 Neither of the RC bugs are present in sid (only in woody); it seems to be a failing of the current 'testing' scripts that they don't recognize this, given that both bugs are tagged 'woody'. ==> hint libdumbnet/1.7-3 libevent/0.7b-1 The two libraries need to go in at once to let the dependencies go in. Which are: farpd trickle stegdetect honeyd fragroute labrea. (honeyd appears to have some build problems on arm and sparc -- apart from those architectures being ignored right now, the problems look like the fault of automake and/or libtool, so it's likely to clear up on its own anyway. The others are all happy and have been waiting way too long.) ==> remove xawtv/3.72 xawtv is the only link between the 'jack-audio-connection-kit' stuff and the below packages. Breaking the link is likely desirable. The new xawtv will then go in with the 'jack-audio-connection-kit' stuff. ==> hint libpcd/1.0.1 openmotif/2.2.2-6 Immediately after the removal of xawtv. Should let in fbi and ida as well. ==> easy gnome-ruby/0.34-1 tictactoe/0.8-3 rsjog/1.1-2.1 rsjog has only waited 8 out of its 10 days; the other two are the usual library dependency thing. ==? Fix 225190 (apparently simple dependency bug in illuminator) ==> easy petsc/2.1.6-2 illuminator/(new version) (Once the illuminator bug is fixed) ==> force chasen Chasen has two alternative dependencies: one is the non-free and not-compiled-everywhere ipdadic -- but the other is the perfectly free, compiled-everywhere, and present in 'testing', chasen-cannadic. So why isn't chasen being allowed in? (Hmm. The non-free dependency should come second rather than first, I guess -- perhaps a bug report worth filing?) ==> remove encompass/0.4.99.30-5 Encompass depends on a huge mess of GNOME packages which will presumably get fixed eventually (although they seem to keep popping new bugs up). However, it also singlehandedly keeps libelysium and neon out of testing (by depending on them), and they deserve to go in. Alternatively, ==? fix bug 224715 in gtkhtml3.0 ==? fix bug 201000 in libgtkhtml3.0-2 ==? rebuild it on all architectures ==? rebuild libbonoboui on mips, mipsel with newly fixed gcc ==? build libgnomeprint on m68k ==? after that, build libgnomeprintui on m68k ==? finally, rebuild encompass on m68k, mips, mipsel ==? then do some as-yet-unclear hinting to get libelysium and neon in together with the gnome packages ==> remove libgtkada/1.2.12-8 This is libgtkada1, which is orphaned and dead upstream; now there is libgtkada2. If it is to be kept it would need to be recompiled with new gnat (bug 225060), but nobody seems to care enough to even do that, and even the bug reporter suggested removing it. ==> hint gnat/3.15p-4 (After libgtkada is removed and some waiting periods have passed.)
Whee! And hinting suggestions
Woo-hoo; beautiful hinting. :-) Nice to see zlib in. Looks like s390, arm, and sparc were put on the out-of-date architecture list, right? Lots of stuff should start going in automatically, such as apache. -- So, it's time to hint mozilla in together with its locale packages. I have been so looking forward to a recent mozilla in sarge. :-) -- Looks like the jack chain still has to wait for various rebuilds, and at least one actual unsolved bug. (Unless some packages are removed, or some are forced in.) * fftw3 has a build failure on a platform (powerpc) which the maintainer doesn't have access to. freqtweak depends on it. (Could remove freqtweak, or force fftw in. Or someone with a powerpc who understands Fortran and Fourier transforms could fix it -- like that's likely.) * pd-externals: FTBFS on hppa right now, almost (but not quite) fixed in experimental. See the bug. * gem: Waiting for rebuilds against newer linux-kernel-headers on hppa and powerpc. (Could force it in.) * puredata: Waiting for build on m68k; now needs tk8.4 and tcl8.4 to wait 7 more days too. (Could let it and tk/tcl in anyway.) * ecasound2.2: Waiting for build on m68k. (Could let it in anyway.) * wine: Not old enough. Looks *pretty* good. I've nagged the maintainer of pd-externals and gem again. ;-) I have no idea how to solve the powerpc build failure for fftw3 (I have no powerpcs and don't know fortran), but it seems to be the main actual holdup at the moment. -- Suggestion: Let qscintilla, sip-qt3, python-qt3 go in. The python-qt3 bugs are *not* bugs in python-qt3 but instead in a libGL.so provider such as nvidia-glx; they are still open against python-qt3 only because the maintainer is trying to find out *which* package they need to be reassigned to. :-/ -- ire, ire-rotj, and ire-the-flat need to be hinted in together.
Packages to consider removing from testing
libcache-cache-perl: See bug 215107; the (new) maintainer apparently does not want it in testing until he fixes it. Yet it is already in testing kernel-image-2.4.18-i386bf: Boot-floppies kernel image. Boot-floppies won't be in sarge. iraf: Three serious policy violations. (223543, 223532, 218793). Apparently, these are hard to fix. Meanwhile, maintainership is changing. Sure, these might be fixed before sarge releases, but it can always go back into 'testing' then. :-) netsaint-nrpe: Doesn't work with nagios (new netsaint) and old netsaint has been removed from unstable (as of October). If it gets fixed to work with nagios, it can always go back in. netsaint-plugins: Four RC bugs: two FTBFS, one post-installation script failure, netsaint-plugins-ldap can't connect to slapd 2.1. Oh, yeah, and the newest of these bugs is from June. The maintainer is very busy (has way too many packages), but this is still not OK for release. Again, if it gets fixed, it can always go back in. orp: Crashes on startup (!) and doesn't compile with current glibc (!). Bugs from January and March. Oh, and it's got older (non-RC) bugs too. Definitely not releasable material. rocks-n-diamonds: Copyright problems. Didn't I mention this one before? Current version may not be distributable, so definitely shouldn't be released.
libpam-heimdal vs. new krb4 & friends?
From bjorn.haxx.se: ># Updating krb4 makes 1 packages uninstallable on alpha: libpam-heimdal ># Updating krb4 makes 3 packages uninstallable due to depending on >krb4: arla, heimdal, cyrus-sasl2 So it looks like libpam-heimdal is the only thing preventing the arla/heimdal/cyrus-sasl2/krb4 group from going in. (Of course they have to wait for heimdal to build on the the three arches whose buildds are still down, too. And I could be missing an arch-specific issue.) I don't use it myself. :-) However, I'm guessing one of two things is true: * It doesn't break when krb4, heimdal, and cyrus-sasl2 go in together, and the scripts are just overly conservative. This would be the case if it currently works in unstable. * It does break. In this case it must also be broken in unstable. (libpam-heimdal hasn't been uploaded since 2002.) In this case it probably just needs a rebuild. Although if it breaks, it's been broken for a while; since its maintainer also maintains the heimdal package, and libpam-heimdal has no open bugs against it, that would seem surprising and unlikely to me. I'm not comfortable installing and testing it to find out which is true. Maybe someone just happens to know, of course. Either way it looks like this set is nearly ready for hinting in.
Re: Hopes and dreams
Colin Watson wrote: zlib's going to be a little while due to missing buildds, and a lot of the rest depends on that ... I think we might have to remove some packages for jack-audio-connection-kit. IRC conversations are a bit timezone-lagged though. It's really hard to tell until the buildds are back up (at least 1 for each arch), since there are a lot of packages in that web which need to be built on various architectures. :-/
Re: Hinting openmotif & friends?
Adrian Bunk wrote: On Fri, Dec 19, 2003 at 09:15:00PM -0500, Nathanael Nerode wrote: Adrian Bunk wrote: Independent of this, they are not ready: xawtv depends on new zlib zlib has build failures on several architectures This should hopefully be fixed ASAP as it's holding up mozilla. xawtv depends on new alsa-lib alsa-lib depends on new jack-audio-connection-kit jack-audio-connection-kit has to go in at the same time as: alsaplayer ecamegapedal ecawave fluidsynth freqtweak alsa-lib puredata (which needs to finish building on all archs) soundtracker freqtweak (which is waiting for fftw3, which is broken on some arches) gem which needs new linux-kernel-headers to be built on hppa and powerpc, and installed on the buildds, and then needs to be built on those arches :-P pd-externals which seems not to have a working new version in unstable yet! Perhaps the 'experimental' version is the new one? Or perhaps it just needs a rebuild against the libraries in unstable? You've forgotten at least wine. No... I didn't think wine needed to go in at the *same* time as that lot; it looked like it could go in *after* it. But I guess I could be wrong. * find out what the HECK is up with pd-externals ... Noone filed a bug that the dependencies need to be updated? It's been pointed out that the current version in unstable probably actually works, in which case I'm sorry for worrying about it. :-) I haven't really been able to tell, myself.
Re: Hinting openmotif & friends?
>> * get new linux-kernel-headers on the buildds > >Your long mails in the corresponding RC gem bug didn't include the >suggestion to let gm build depend on an appropriate version of >linux-kernel-headers. Unless I'm mistaken, new versions of glibc and linux-kernel-headers are *not* automatically installed by buildds when required, along with a few other packages like gcc. If so the dependency would not really do much except to prevent the buildds from trying to build it. Am I mistaken?
Hopes and dreams
-- First, at least one buildd for each architecture goes up, allowing new versions of arch-dependent packages to get into testing. The buildds get new linux-kernel-headers installed, allowing lots of related problems to go away. Chris Cheney or someone uploads kdemultimedia 3.1.4. fftw3 is fixed so it builds on all arches. Amazingly, none of the rest of this seems to require currently open bugs to be fixed, or the removal of anything from testing. :-) So ideally it could *all* happen 10 days after the above items get done! -- Second, the following packages build successfully on all architectures with no new RC bugs (I wish) (for far too many reasons) * zlib * sympa (for perl) * apache * libogg * libvorbis (after libogg) * libxml2 (after zlib) * gnutls7 (after zlib) (for the jack dependency web) * gem * puredata * fftw3 * freqtweak (after fftw3) * ecasound2.2 (for kde 3.1.4) * kdeartwork * kdemultimedia * kdeaddons (for gnome) * swfdec * gnome-system-tools * gnome-applets * galeon (after mozilla) -- Third: then the following dependency chains go in: * zlib * libxml2 (after zlib) * gnutls7 (after zlib) * mozilla (after zlib) * libogg * libvorbis (after libogg) The Jack stuff: * fftw3 (which unclogs freqtweak) * The following all at the same time (after fftw3): jack-audio-connection-kit alsaplayer alsa-lib ecasound2.2 ecawave ecamegapedal puredata gem freqtweak ladcca fluidsynth soundtracker (I think this is the correct minimal list to go in in one lump, but I'm not 100% sure due to the complexity of this chain.) * The following all at the same time (after zlib and the jack chain): openmotif, libpcd, xawtv, fbi, ida, motv The perl stuff: * perl * apache (after perl) * The following at the same time (after perl): pilot-link jpilot jpilot-backup linpqa malsync sylpheed sylpheed-claws * libmal (after the pilot-link group, hence after perl) * The following at the same time (after zlib and apache [& thus perl]): mm php4 smstools (There's something odd here in that new mm apparently breaks snui, but I don't see why.) KDE: * kdepim (after libmal, hence after perl & pilot-link) * kdeartwork * kdemultimedia (after libvorbis, hence libogg; also after the jack chain) * kdeaddons (after kdemultimedia) * meta-kde (after all of the above kde bits) GNOME: * swfdec (after mozilla) * gst-plugins (after the jack chain and swfdec) * gnome-media, nautilus-media, sound-juicer (after gst-plugins) * gnucash (after zlib) * gnome-system-tools (after gnutls7, libxml2) * rhythmbox (after gnutls7, libxml2, gst-plugins, libvorbis) * gnome-applets (after gnutls7, libxml2) * galeon (after mozilla) Plus presumably lots of other dependencies of zlib, gnutls7, libxml2, mozilla, jack-audio-connection-kit, pilot-link, apache, and so on. :-) -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Hinting openmotif & friends?
Adrian Bunk wrote: >Independent of this, they are not ready: > >xawtv depends on new zlib > zlib has build failures on several architectures This should hopefully be fixed ASAP as it's holding up mozilla. >xawtv depends on new alsa-lib > alsa-lib depends on new jack-audio-connection-kit jack-audio-connection-kit has to go in at the same time as: alsaplayer ecamegapedal ecawave fluidsynth freqtweak alsa-lib puredata (which needs to finish building on all archs) soundtracker freqtweak (which is waiting for fftw3, which is broken on some arches) gem which needs new linux-kernel-headers to be built on hppa and powerpc, and installed on the buildds, and then needs to be built on those arches :-P pd-externals which seems not to have a working new version in unstable yet! Perhaps the 'experimental' version is the new one? Or perhaps it just needs a rebuild against the libraries in unstable? Clearly the priorities here are: * Fix fftw3, or remove freqtweak from testing * get new linux-kernel-headers on the buildds * find out what the HECK is up with pd-externals -- However, if the old motv was temporarily removed from testing, it would break the linkage between xawtv and four of the packages I mentioned. Then openmotif, fbi, ida, and libpcd could go in, and they've been waiting long enough it's probably worth it. :-/ Then new motv would only be waiting for xawtv, which would only be waiting for zlib and alsa-lib, and they would presumably go in when the jack-audio-connection-kit logjam unjams. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Hinting openmotif & friends?
I just noticed a rather complicated interdependency web: new fbi depends on new libpcd new ida depends on new openmotif *and* new libpcd new motv depends on new openmotif *and* new xawtv new libpcd breaks old fbi and old ida new openmotif breaks old ida and old motv Presumably new xawtv will break old motv xawtv just built on the last missing architecture (ia64) today. (All others are up to date and free of RC bugs.) fbi is 62 days old. ida is 62 days old. xawtv is 62 days old. libpcd is 142 days old. motv is 246 days old. openmotif is 374 days old. I think there needs to be joint hinting to get this cluster in. It looks like if all six go in at once, it will work, but I don't see any way for any subset to go in. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Bug#219545: Proposed packages to remove from testing
(Moving from debian-release -- followups probably belong in debian-project) Steve Langasek (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00010.html): > "Not buildable" -> "not releasable." This is not a new concept. Steve Langasek (http://lists.debian.org/debian-release/2003/debian-release-200312/msg8.html): >Is it currently releasable? If not, then there's no reason to keep it >in testing, is there? This sums up why I proposed its removal from testing (*not* from unstable). There really is no argument against this given that "testing" is supposed to be in a "releasable state" at all times! (Admittedly, that doesn't often happen, but it's certainly better to try than not to try!) Steve Langasek (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00010.html): >Removing packages from testing is the domain of the release manager; >removing packages from unstable (and NEW queue processing) is the domain >of the ftp-master team at large. Unless you mean for the release >manager to prioritize the general queue management work above the >specific release management work, I don't see how the two are much >related. Sven Luther (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00011.html), regarding the release manager: >Which is also an ftp-master, OK, this is a valid point. I agree that general queue management work *should* be prioritized over specific release management work. This might best be accomplished by having more people who aren't release manager as ftpmasters. :-) Sven Luther (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00011.html): >Yep, or at least provide some feedback about the issue. Right now, they >are like a black hole where nothing ever comes out, and the only way to >get attention is to make a week long rant on the public mailing lists, >which worked for aj some month back, but is lost on elmo, which has me >black-listed anyway. He's far from the only person to complain about non-responsiveness of the ftpmasters. Probably this should move to debian-policy, since it's gotten off-topic for debian-release. Sven Luther (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00011.html): >parted is used for debian-installer, >without which we cannot release, while advi is probably used by less >than 1% of our users, and nobody will really miss it if it is removed in >the last minute. Quite right. So nobody will miss it if it is removed now, either. From *testing*, mind you; a fixed version in unstable will propagate to testing *as usual* even if the current version is removed from testing. OK? Anyway, the RM claimed that sarge would be released *already*, so claims that the release is "far away" are very questionable. I have not proposed removals from unstable without great thought and lots of evidence. Removals from testing are another matter. Sven Luther (http://lists.debian.org/debian-release/2003/debian-release-200312/msg00011.html): >And seriously, i am a bit demotivated. I past hours and days compiling >powerpc kernels, each build needing 6 hours of compile time, working >around bugs and bad design in kernel-package, and loosing time i could >otherwise have spent on other stuff, just to have the package die in the >NEW queue limbo. What good is my participation into debian if my work is >threated like shit ? Not to speak about the time last year when i >suddenly, on the 30 of december, receive a mail from elmo telling me >that the way we handle api changes in the ocaml package was not >acceptable to the buildd, without further explanation, and i, instead of >passing a nice sylvester, ask him for details, i get killfiled by him, >and let to wonder in the dark ? And all this, just to see other packages >do exactly the same thing a few months later ? See previous complaints. Debian clearly has some serious problems; I personally credited some of them to James Troup once. The surprising part about that was that I was then told by several other people, "Well, you've prevented yourself from ever becoming a Debian Developer now; he'll never let you in." I hope that that is not true, and personally I have no reason to believe that it's true. However, the fact that several Debian Developers -- ones who have not discussed the topics on public mailing lists, apparently out of fear of blacklisting! -- *believe* it to be true is very disturbing, and provides in and of itself evidence of serious communication problems. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Proposed packages to remove from testing
advi: Maintainer won't fix the RC bug until he fixes "other" problems, which he hasn't gotten around to. Packages which FTBFS should not be in sarge. Accordingly, remove it until the maintainer gets around to fixing his bugs. (or, yell at the maintainer with authority ;-) amavis-ng: Totally unacceptable data-loss bug (#219044), really nasty fails-to-work bug (#223774), plus another RC bug. This should absolutely not be allowed in a release under any circumstances. They are being worked on, but this is just way too nasty to allow in a release. If the bugs get fixed, it can always go back in. encompass: Uninstallable for months (so no loss!). If it becomes installable, it can always go back in. iraf: Three serious policy violations, one of which (#218793) is really unacceptable and open since November 2. If this ever gets fixed it can go back in, of course. Also, the last upload was in the year 2000 (!) and discussed an incomplete (!) transition to proper building from source. iraf-ibin, iraf-noaobin, x11-iraf: Intimately linked to and dependent on iraf. Maintainer doesn't seem to be paying attention to any of the iraf packages, despite which they haven't been orphaned. (These, like iraf, are all contrib, incidentally.) kernel-image-2.2.20-reiserfs-i386, kernel-image-2.4.18-i386bf: Neither build from source due to failure to upgrade the build-depends. (Since July.) I've suggested in the bug trails that the maintainer may want to remove these packages from unstable as well, since they probably aren't useful any more. rocks-n-diamonds: Copyright problems for quite a while. (#210233). Make sure this doesn't get into a release! It's orphaned, and when/if the new maintainer (or QA) uploads a clean version, it can go back in. (Incidentally, its (ex-)maintainer Charles Briscoe-Smith is utterly MIA and should probably be locked out of all Debian machines for now, until he reappears. I wish there was a good way to see the list of all Debian Developers who have been marked MIA and locked out already) -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Attempted "testing propagation status" report
So, things look pretty good actually. KDE 3: Frustratingly slow. * Still waiting for kdebase 3.1.4 upload which is fully installable (including kdebase-dev, and therefore ksysguard). This is probably keeping other kde packages out indirectly; when their -dev Build-Dependencies are uninstallable, they can't build. * Also, kdemultimedia needs 3.1.4 uploaded (and will then wait for various other things). GNOME 2: All the libraries need to pass their 10-day wait times, and then most of it should go in at once, probably leaving only a couple of packages to fix. perl: Just waiting for its wait time to go. jack-audio-connection-kit & friends: * Waiting for gem, which is waiting for a glibc headers fix. * Also breaks pd-externals, which has the newest version in 'testing'. This is probably not a real issue (pd-externals depends on pd, which depends on jack-audio-connection-kit). (Also, pd Replaces: pd-externals.) pd-externals also FTBFS on hppa. Anyway, pd-externals might need a new upload; I don't know. mozilla: All the old RC bugs are stamped out, and now it's FTBFS on m68k and mipsel. * On mipsel this is due to a bug in nut. * On m68k it looks like it's just waiting for a bunch of other things to build. So it should hopefully go in soon (yay). postgresql: Waiting for perl. pilot-link: Waiting for perl. cyrus-sasl2, krb4, arla, heimdal: I still find these very hard to decipher. I still can't believe that they really break 56 packages when going in *together*. Supposedly they're waiting for postgresql, presumably because 'old' postgresql depends on something which is going away (although I cannot actually figure out what). But are they waiting for anything else? Is it possible to suggest that the testing scripts do a recur with this combo in order to see what still breaks when they go in together? Or does the Release Manager already know? ;-) After the above things get dealt with, it will probably be time to make a reassessment and see what (if anything) else involving complicated dependencies and version transitions really "ought" to go into sarge. I suspect that there won't be much more and it will become appropriate to try to figure out how to fix all the "uninstallable in sarge" bugs at that time. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Time to push qt-x11 and friends into testing?
Wouldn't it be more effective if you would try to fix these packages instead of proposing to remove them? No, it wouldn't. (1) I couldn't care less about these packages. I'm not competent to fix them and I don't really want to. (2) nurbs++ has been failing to build on HPPA since July, while innovation3d has been failing to build on arm since July. If the mainttainer doesn't know about the problem, he's derelict. If he does know and doesn't care, his packages should be removed from testing. If he does care, why is there zero evidence? nurbs++: ICE on hppa. It would be effective if you would tell the maintainer about this issue The maintainer should know, assuming he's not MIA or grossly irresponsible. and/or send a bug report against gcc-3.3 (needs access to hppa since the gcc maintainers want preprocessed source). No HPPA access. innovation3d: checking for QT moc (moc)... yes checking for QT uic (uic)... no configure: error: Cannot find proper QT Needs further investigation, you could at least send a RC bug report to notify the maintainer. The maintainer should damn well know about this problem; it's been occurring for months. --Nathanael
Time to push qt-x11 and friends into testing?
These are the qt2 packages. Currently they are held up because they break innovation3d and nurbs++ -- both of these have newer, c102 versions in unstable which use qt3. They FTBFS on some architectures, so they can't go in, but if they were removed from 'testing', it looks like the qt2 packages could propagate. I think. :-)
arla/heimdal/krb4/cyrus-sasl2 ?
Are these four ready to be hinted in together, or am I missing something?
Time to push libsigc++ and friends in?....
It looks like libsigc++ is ready to go. All the packages which it would render uninstallable are just waiting for it (or have been deleted from unstable). xgsmlib needed a build on m68k, which is apparently done (I don't know if it's been uploaded yet; if not, that should happen first of course). Now I guess libsigc++, gtkmm, gnomemm, fwbuilder, cdrdao, cheesetracker, guikachu, ickle, libicq2000, vdk, and xgsmlib should go in together, today or tomorrow. Right?
Suggest shoving nvidia-graphics-drivers into 'testing'.
This is a non-free package. It won't go in due to unsatisfiable 'depends', but that's the way it's designed; it seems to be a false issue. It will break horribly when unstable glibc gets into 'testing' unless its new unstable version is pushed into testing. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Attempted anaylsis of testing progression issues
libgc - * oo2c has to wait 6 more days. * w3m has an RC security bug (#200028) which has not been fixed (apparently due to some stupid arguments). * Then, joint hinting will presumably do the trick. Summary: w3m should not be setuid root. It needs to be setuid root because /dev/MAKEDEV in nmakedev 2.3.1-63 creates the framebuffer devices without read permission for the 'video' group. (!) (devfsd does give read permission.) The need for read permission cannot be easily avoided and there's no reason not to give it to users with write permission. The bug has not been fixed in makedev, and apparently hasn't been reported there in the BTS. (There's also a confused argument about the correct use of the groups, but for the time being, the 'video' group is the correct group.) Conclusion: The root of this is a bug in makedev. This should probably be reported as a bug in makedev and fixed as soon as possible. Then this can be fixed by the maintainer of w3c. libsigc++ - Waiting for new yehia, which is waiting for libgc. Then, joint hinting will presumably do the trick. kde --- Still waiting for fixed kdelibs and kdebase to be uploaded. (Aaargh... if I were a DD I'd start to consider NMUing them) Pretty much nothing can progress here until those two get uploaded. Aaargh! mozilla --- RC bugs! Dunno what's being done about them! Looks like nothing! glibc - Apparently new, spiffy glibc is well on its way to going in and should go in smoothly. perl Test failures prevent build from finishing on mips, mipsel, m68k. (Everything else seems to be fixed.) I don't know if anything is being done about this; I don't see any evidence that anything is being done. cyrus-sasl2, krb4, heimdal -- Need to wait at least 8 more days. Then joint hinting will probably do the trick. gnome packages -- Looking in good shape. atk1.0 should go in in a day or so, and take a lot of stuff in with it.
icu ready to go in?
http://bjorn.haxx.se/debian/testing.pl?package=icu The three 'uninstallable' packages aren't in unstable. It looks like 'xerces' and 'xerces20' should stay gone. Not sure about 'xerces21', but if it should stay, it should be hinted in together with icu, which looks like it will make everything work.
Re: libsgc++ & friends need hint
Oh, right, forget it; I just noticed that libsigcx is slated to vanish. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: libsigc++ & friends need testing?
Colin Watson wrote: >On Fri, Oct 17, 2003 at 01:55:28PM -0400, Nathanael Nerode wrote: >> It looks from >> http://bjorn.haxx.se/debian/testing.pl?package=libsigc%2B%2B&expand=1 >> as though libsigc++ and the packages which depend on it are ready to go in, >> but have to be hinted together. > >They aren't ready yet; yehia/testing is still a problem, and upgrading Hmm. Really? It looks like yehia depends on libsigcx, but it also looks like libsigcx can survive an upgrade of libsigc++ (and all its other friends) without breaking. Which would certainly simplify things. >that needs another complicated situation to be resolved first, namely >libgc. That's waiting for fixes to oo2c, stalin, stklos, and w3m. > >libsigc++ has been wedged solid since before I started paying attention >to these things back in May or June. :( -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
libsigc++ & friends need hint?
It looks from http://bjorn.haxx.se/debian/testing.pl?package=libsigc%2B%2B&expand=1 as though libsigc++ and the packages which depend on it are ready to go in, but have to be hinted together. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Getting libxml2/lixslt into testing -- remove suggestions
OK, I'm trying to figure out the holdups with this. So much depends on libxml2 that it seems worth removing a few things from 'testing' to get it in ASAP. rubrica --- Ties the whole thing into the python2.3 transition. Suggestion: Remove from testing temporarily to allow these transitions to be independent. libgda2, libgnomedb2 Ties the update to the postgresql update, which is dependent on python2.3 and perl as well as libxml2. Suggestion: Remove from testing temporarily to allow these transitions to be independent. gdome2-xslt, gmetadom - Ties the update to ocaml. Suggestion: Contact ocaml people to see what the status of the hppa and m68k build failures is, and whether they will be resolved soon. If they *will*, wait. If they *won't*, pull from testing temporarily. --- All the others look like they just need to go in at the same time as libxml2. Hope this helps. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Suggest removing autoinstall, autoinstall-i386 from testing
This is not meant as any sort of slight on the maintainers of these packages; they just seem to be in bad enough shape that sarge would be better off without them. If they improve in 'unstable', they can always go back in again. Suggest removal from testing: autoinstall -- problems with build setup, lots of unfixed-long-time bugs. autoinstall-i386 -- doesn't build, hasn't for a long time. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Attempted analysis of remaining release holdups...
What seems to need to be done before release (apart from the usual bug-squashing / buggy package removal, etc.): * glibc 2.3.2 which works on hppa needs to be finished and uploaded. (Carlos is apparently close to done with this) * gcc 3.3 which works on arm needs to be finished and uploaded. (This was a Pascal-only problem last I checked -- haven't heard any status info. Actually, I'm a little confused by this, since GCC isn't listed as out-of-date for any architecture in testing -- is it already fixed or something?) * buildd's need to get the new toolchain in place to avoid problems with building other packages. * lcms dependency chain needs to get in. (Colin Watson is working on this.) * libsgc++ dependency chain should get in. (This will probably go in on its own if everything just sits for a few more days -- there appear to be no actual bugs holding it out right now) * KDE 3 needs to get in. -- qt-x11-free needs to be built on mips (timeout problem) -- buildd's need new gcc in place for kdemultimedia -- arts needs libtool update for arm -- Chris Cheney & others need to upload rest of kde 3.1.4 * python2.3 transition needs to go on (many people are working on this). * Mozilla 1.4 going in. -- 2 RC bugs -- still isn't building on ia64 and arm apparently -- should probably sarge-ignore the 4 woody-only RC bugs after the above are fixed This needs more attention from porters than it's getting. :-( * Other Gnome 2 issues -- I don't know about these; I don't use gnome. * debian-installer -- I'm still unclear on what needs to be done, but apparently powerpc and i386 are the only two which really work right now What would be really nice if it was done: * glibc which doesn't use stock kernel headers finished and uploaded. * c102 transition finished, or all untransitioned packages removed: see http://people.debian.org/~willy/gcc-transition/ Things are close, really close. (I wish willy would upload an updated db2 which drops db2++ already.) * Out-of-date-binaries-in-testing fixed up (there are not very many) http://ftp-master.debian.org/testing/testing_outdate.txt * Uninstallable binaries in testing fixed up (a list of reasons for each one wouldn't hurt in dealing with this....) http://ftp-master.debian.org/testing/testing_probs.html -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Would lcms really break 309 packages?
From bjorn.haxx.se: 20 packages wait for lcms (63 days old, Valid candidate, breaks 309 pkgs) Really? This seems unlikely. Perhaps it needs hinting?
Re: updating gcc-3.3 to the final gcc-3.3.2 release for sarge
Anthony Towns wrote: >FYI: Note that I've forced the current version of gcc-3.3 into testing >for tomorrow's dinstall; in spite of it being broken on arm, and unbuilt >on m68k. This will ease a bunch of problems, but is still causing major >hassles for Qt and KDE, so we still need a properly fixed gcc-3.3 ASAP. I don't know of any gcc-3.3 bugs directly affecting Qt/KDE at this point (version 3.3.2pre4). If there are any, I wish I knew about them m68k appears to have built, so maybe it should be put into testing with the rest. arm is failing on a pascal-specific part, which isn't anything to do with upstream gcc. :-/ Evil gpc. hppa is toast due to glibc, so I don't even know what to say about KDE there. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
HPPA still *ed...
HPPA doesn't have updated glibc yet (still). No ETA. That means that the fixed GCC 3.3 won't build on HPPA, so it can't go into 'testing'. Which means that lots of stuff can't go into testing. Is the plan to hold up everything until HPPA is fixed? Or should the latest gcc-3.3 perhaps be hinted in despite the HPPA problem (that's what I'd guess)? -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: m68k isn't keeping up? nevermind? (gnome2?)
>What does the comment "but m68k isn't keeping up, so nevermind" mean, >and is it still true? I dunno, but m68k *is* behind. There's a bug in kdelibs which is m68k-specific (a crash in 'meinproc'), which needs to be tracked down before kde can go into testing. This exhibits itself during building of kdeedu. All kde builds are currently delayed until the latest qt package is built on m68k (the only arch it currently needs). That's building right now, and has been for about 12 hours... It'll probably be days before we even have verification that the bug still exists. This is the last genuine bug which has been keeping most of kde out of testing since openldap2 went in (the others are NMU-fixed). If it does still exist, there will likely have to be more kde rebuilds to test fixes. kdebase apparently takes upwards of 100 hours (!) to build on m68k... So m68k has become the bottleneck for KDE to get into testing. If a concerted effort is made to deal with that, it will probably slow down the building of everything else on m68k, of course... I'm sure it will catch up eventually, but it does seem to be behind right now. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
