Tradiddlydum.
Given the exciting currency of inter-dependency problems at the moment
(with perl/postgresql/python, ocaml, and libvorbis getting discussed),
this week's addition to the tasks will include one of those each (in most
cases it's a package that's trying to be removed from testing).
Some background is probably required for you to grok this
properly. Basically the way britney, the testing scripts, works is a
brute force analysis of which packages can be added to testing without
either being broken themselves or breaking other packages. Depends,
Pre-Depend and Conflicts are taken into account; Recommends, Suggests
and Build-Depends/Conflicts are not. As a full brute force analysis
would be exponential work (there are over 1000 valid candidates at the
moment, giving 2**1000 possible combinations), we use what's called a
greedy algorithm -- we take one, try it, and if it works, we accept it
immediately even if that means two other packages somewhere else won't
go in later.
But since we're doing things one at a time, that means that if you
have two packages, A and B which have versioned dependencies on each
other, neither will go in. For example, perl 5.8 modules will not
work with perl 5.6, and perl 5.6 modules won't work with perl 5.8; so
updating perl alone will break libterm-readline-gnu-perl; but updating
libterm-readline-gnu-perl will also leave libterm-readline-gnu-perl
broken.
There are three possible ways of dealing with this. One is to specifically
say "try perl; then try all the other packages in the usual greedy
manner, and see if you can get back into a state that's no worth than
the current. If you can - great, use it. If not, forget it, we'll
try again later". That's what's called "hinting" at a package, and is
expressed with a line like:
run.do_all(0,["ocaml"])
at the appropriate place in update_out.py. Another way, which is
only possible once we get the number of valid candidates back down
to something reasonable, is to just automatically try "hinting" every
valid candidate, and seeing if any work. This is already implemented,
but takes more than a day to run and usually OOMs if there's many more
than 100 valid candidates; 1000 is right out of the question. It'll kick
in automatically when we get the number of valid candidates to a low
enough level. The third possibility, which isn't implemented but should
be possible, is to do some automatic analysis of the "Depends: foo bar"
hints already listed in update_excuses, to work out which packages are
good candidates for hinting, and to automatically do some of those.
A good way to find packages that're worth looking into is something like:
grep '<li>Depends:' update_excuses.html | sed 's,</a>,,;s/.*>//' |
sort | uniq -c | sort -n | less
which at the moment ends with:
108 qt-x11-free
110 gconf2
138 python2.2
170 perl
222 gtk+2.0
606 gcc-3.3
indicating the top few packages that are holding other things back. We'll
use gtk+2.0 as a case study. It's excuse says:
* gtk+2.0 (2.0.6-3 to 2.2.1-4)
+ Maintainer: Akira TAGOH
+ 20 days old (needed 10 days)
+ out of date on alpha: gtk2.0-examples, libgtk2.0-0,
libgtk2.0-0png3, libgtk2.0-common, libgtk2.0-dbg,
libgtk2.0-dev (from 2.2.1-2)
+ out of date on arm: gtk2.0-examples, libgtk2.0-0,
libgtk2.0-0png3, libgtk2.0-common, libgtk2.0-dbg,
libgtk2.0-dev (from 2.2.1-2)
+ Not considered
On alpha, it hasn't been tried at all. Looking at the wanna-build info, via
http://buildd.debian.org/ -> statistics -> ALL: alpha; we see:
libs/gtk+2.0_2.2.1-4: Dep-Wait by rmurray-lully [optional:out-of-date]
Dependencies: xlibs-pic (>= 4.2.1-6)
Previous state was Building until 2003 Mar 04 18:21:42
that is, there's no point trying this package until xlibs-pic 4.2.1-6
or later is available on alpha. That's part of xfree86, and its build
log has been failing from a segfault in gzip, Bug#184057, now fixed,
and because flex changed. It's being held back because of that, because
of an RC bug about the same issue, and because of dependencies on gcc-3.3
packages. A fix to the flex issue seems unlikely, so we'll instead try
forcing it into testing, and getting it autobuilt there with the older
flex and older gzip. Moving xfree86 to testing has further problems,
since there's still some packages that depend on xlib6g, which has been
removed between xfree86 4.2.1-3 and 4.2.1-6. Amongst other things, this
breaks libforms0.88 and libforms0.89 which are only in testing because
other things depend on them without having been updated, so they need
to be fixed up too. LyX is one such package, but updating it brings in
the Qt/Postgresql/KDE/Perl/Python mess, so it's going to get temporarily
dropped from testing, unfortunately.
gtk+2.0 is also out of date on arm, because its build-dependencies failed
to install correctly on the autobuilder:
Re-checking for JadeTeX memory dumps ...
ERROR: JadeTeX memory dump (jadetex.fmt) cannot be found
ERROR: PDFJadeTeX memory dump (pdfjadetex.fmt) cannot be found
ERROR: JadeTeX/PDFJadeTeX memory dump not found
This package could not be installed.
This is Bug#183285 on jadetex, which hasn't seen much activity for a
while now, and is marked as normal, now upgraded to grave.
Obviously this can get horrendously complicated: there are lots of
ways problems can arise, dependencies can get tangled amongst many many
packages, and resolving the problems can require jumping from supplying
patches, ripping out packages, tweaking buildds, hacking on the toolchain,
and all sorts of things.
Basically, you need to work out what's breaking; why it's breaking;
and what can be done about it. If it's breaking in unstable, make sure
there're bugs filed, and see about fixing them. If it's breaking in
testing, see why the other packages aren't getting updated, and work
out what can be done about that.
So, there endeth the lecture. Homework is:
Neil Schemenauer
56472 followup: patch was accepted, but we've now got build
issues. So the saga gets continued in #188923.
80888 followup: work out what to do about this package
143852 followup: a patch needs to be written
142091/um-pppd followup: NMU needed? mark as MIA/orphaned?
182265/kaffe/ttthreeparser followup: NMU needed? mark as MIA/orphaned?
188343/amp followup: sparc/powerpc binaries need updating or dropping
148726 [ ] libsasl-gssapi-heimdal dependency problems
151753 [ ] korganizer: Rebuild with libpisock5
188923 [ ] ...(hppa/unstable): FTBFS: non-PIC in shared lib
153007 [ ] tripwire: should be in non-US/non-free
sced, xslideshow, devel-protocols
-alsa-driver-0.5
Colin Watson
146103 followup: any progress on 186299? any progress re: workaround?
188400/qcam followup: NMU? mark as MIA/orphaned?
188403/ipautofw followup: did the patch work?
149460 [ ] perhaps race condition when bringing multiple tap ...
153457 [ + ] inetutils: policy violation section 13.3
154155 [ ] lib-saxon-java: package well behind current stable ...
154727 [ ] libdb-ruby: Version conflict between db2 and db3.
155130 [ ] wvdial: pppd does not use provided password
155158 [ ] fp-units-gfx: Package dependecies list must be ...
mrouted, jpeg2ps, rumbagui
-alsa-lib-0.5
Steve Langasek
187905/hamfax followup: NMU? mark as MIA/orphaned?
124290/lodju followup: anything happening?
188120/astrolog followup: remove/update ia64/ppc/sparc bins?
144841 [ ] doesn't build on arm
155374 [P ] Where are Installation Manual and Release Notes
155472 [ ] icqv7-t_0.3.0pre2-3(hppa/unstable): FTBFS: non-PIC ...
156057 [ ] timidity-patches: copyright file does not state ...
156165 [ ] nscache: refuses to start
xmms-goom, bulkmail, ucbmpeg
-busybox-source-0.60.0
Federico Di Gregorio
123306 followup: NMU/remove? mark as MIA/orphaned?
143985 followup: NMU? mark as MIA/orphaned?
56713 [ ] dip: No cleanup after exit, duplicate route and ...
127604 [ + ] segfaults while building on alpha or ia64
156415 [ + ] installation breaks on devfs
156750 [ ] vdkbuilder_1.2.5-10(hppa/unstable): FTBFS: bad ...
icomlib, xbs, xsnow
-cervisia
James A Morrison
46709 followup: why is GNU Mach 2.0 still unpackaged/unreleased?
151071 followup: NMU needed?
151551 followup: get someone to test the patch
trn, font3d, xgobi followup: do any missing bins need to be removed?
143825 [P ] xutils: why is rstart.real a conffile?
156600 [ ] FTBFS: hurd should build-depend on autoconf2.13
156835 [ ] xfree86-tinyx_4.1.0-1(hppa/unstable): FTBFS: imake errors?
157158 [ ] FTBFS: Build failure of detect on i386
157394 [ ] pingus crashes when loading the first level
ldmud, xzx, giflib
yiff
Joey Hess
157913 [ ] FTBFS: conflicting declarations
158327 [ ] FTBFS: Build failure of tfm-arphic on i386
159165 [ R ] does not play anything
159494 [P ] current libwww-search-perl version unusable
159548 [ ] FTBFS: Build failure of hugs98 on i386
savant, snes9x, scm
-clanlib0
Don't be afraid to recommend removing things from testing or unstable;
but do make sure that there's either no drawbacks ("doesn't work anyway /
isn't be maintained") or that the drawbacks are clearly trivial compared
to the win (in which case, please list what they are).
If you run out of things to do, please feel free to take the initiative in
doing more stuff.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Attachment:
pgp0dhZUXFOdE.pgp
Description: PGP signature