Re: Bad dependencies list
On Mon, 31 Jul 2000, Paul Slootman wrote:
> I've pruned the even more obvious (i.e. the ones also present in
> the i386 dist.).
Hehehe...ok...and I've finished quite a few more already and pruned even
further (removing the suggests stuff since it really doesn't matter much
and many are virtual).
> Package guile-scsh version 1998.08.24-1.1 has an unmet dep:
> Suggests: scsh
Bombs. Removed since it's a suggests.
> Package tunnelv version 1.00-2 has an unmet dep:
> Depends: libstdc++2.9-glibc2.1
Non-US.
> * Package vgagamespack version 1.4-3.1 has an unmet dep:
> * Depends: libc6
> * Package libforms0.88-dev version 0.88.1-3 has an unmet dep:
> * Depends: libc6 (>= 2.1)
> * Package pike-mysql version 0.6.131-6 has an unmet dep:
> * Depends: libc6 (>= 2.1.2)
Done, binary NMUs.
> * Package locale-ko version 4-3 has an unmet dep:
> * Depends: libc6 (>= 2.1.1-1)
> * Package locale-vi version 1-3 has an unmet dep:
> * Depends: libc6 (>= 2.1.3-4)
Arch: all :-( Bug reports filed already.
> * Package twclock version 1.3-9 has an unmet dep:
> * Depends: libc6 (>= 2.1.2-12)
> *
> * libc6 ?!
Done...in incoming for a week now I think.
> Package custom-mule version 1.9962-3 has an unmet dep:
> Depends: mule2
Mule2's been sitting in incoming forever now, but I can't figure out
who compiled it or how. It bombs when compiling for me.
> * Package pcmcia-cs version 3.1.8-9 has an unmet dep:
> * Suggests: pcmcia-modules
> *
> * I think pcmcia-modules is a virtual package
pcmcia-modules can be compiled by the user, IMO. It's only valid for a
few older types of Alpha anyway. Good news is, though, that the woody
version works with kernels configured for "generic" types of alphas
(FINALLY), so we can probably build this for woody, but potato will have
to rely on the users to do this themselves.
> Package pilot-template version 1.31-1 has an unmet dep:
> Suggests: prc-tools
prc-tools will never compile on alpha until they use the newer patches
against gcc 2.95.2 (since this version is still reliant on gcc 2.7.x
sources that were unpatched for alpha).
> Package bb version 1.2-3.1 has an unmet dep:
> Depends: slang0.99.38
> Depends: slang1 (< 1.3)
This is a PITA. I sent in patches for bb to work and compile, but the
maintainer never did anything other than remove alpha from the arch
list. I've NMU'ed it anyway (binary) since a source NMU won't be accepted
unless I bump the importance of the bug. Screw it, this one is just one
we'll have to send patches to users who want to compile it from source on
Alpha... (this is getting REALLY old).
> Package amcl version 0.4.2-2 has an unmet dep:
> Depends: libglib1.1 (>= 1.1.3-1)
> Depends: libgtk1.1 (>= 1:1.1.2-1)
Working on this one. Requires that I install some old gtk/glib combo to
compile since it won't work with gtk1.2.
> Package guitar version 0.1.4-7 has an unmet dep:
> Suggests: rar
Ignored. rar is arch:i386 only due to asm in the source.
> Package php3-snmp version 3:3.0.16-2potato3 has an unmet dep:
> Depends: libsnmp4.0
Done.
> Package ssh-socks version 1.2.27-6 has an unmet dep:
> Depends: libsocks
Non-US.
> Package unzip-crypt version 5.40-1.0 has an unmet dep:
> Suggests: zip-crypt
Same.
> Package php3-cgi-snmp version 3:3.0.16-2potato3 has an unmet dep:
> Depends: libsnmp4.0
Done.
> * Package task-devel-common version 0.5 has an unmet dep:
> * Suggests: ltrace
> *
> * ltrace isn't ported to alpha yet.
Ignored anyway. It's a suggests :-)
> Package geda-gnetlist version 19991011-4 has an unmet dep:
> Depends: libguile6 (>= 1:1.3.4-3)
All affected geda- packages are NMU'ed and in incoming.
> Package gem version 0.81-7 has an unmet dep:
> Depends: libstdc++2.9-glibc2.1
> Package vice version 1.0-3 has an unmet dep:
> Depends: libstdc++2.9-glibc2.1
Done.
> Package ale-clone-cogliati version 0.11-1 has an unmet dep:
> Depends: ale-clone
ale-clone can't be run until the ZPixMap stuff is ported to 64-bit archs
(still not done in XFree86 4.0.x, fyi). It requires that extension before
it'll run (I've been down this road before). Since the ale-clone-cogliati
package is arch:all, I'm ignoring it.
> Package tochnog version 99.4.22-1 has an unmet dep:
> Depends: libstdc++2.9-glibc2.1
Done.
> Package lilypond version 1.2.2-1 has an unmet dep:
> Depends: libguile4 (>= 1:1.3-15)
Recommended for removal.
> * Package netstd version 3.07-17 has an unmet dep:
> * Suggests: wdsetup
> *
> * wdsetup can't be compiled on alpha, probably others are the same.
Yeah, it's a suggests anyway, so no big deal.
> Package emacs19 version 19.34-20.1 has an unmet dep:
> Depends: liblockfile0 (>= 0.1-1)
> Depends: liblockfile0
How long is emacs19 going to stick around? I know I use emacs20 and can't
imagine going back to emacs19 (which requires heavy patching to
compile). I have a patch for it somewhere, but it's a bit late at this
point to worry about. It's a shame, though...
> Package moonlight version 0.5.3-2 has an unmet dep:
> Depends: libstdc++2.9
Newer versions won't compile due to C++ errors. Will recommend for
removal.
> Package xmahjongg version 3.0b10-1 has an unmet dep:
> Depends: libstdc++2.9-glibc2.1
Done.
> Package w3-el-e19 version 4.0pre.46-7 has an unmet dep:
> Depends: emacs19 (>= 19.34-21)
See above.
> Package pavuk version 0.9pl24-1 has an unmet dep:
> Depends: libsocks
Non-US.
> Package ipmasq version 3.4.4 has an unmet dep:
> Suggests: midentd
??? Beats me. I can't find midentd anywhere for any arch.
> Package libdb2.6-dev version 2.6.4-6 has an unmet dep:
> Depends: libdb2.6 (= 2.6.4-6)
Oldlibs. This part of the report doesn't agree with my available list
either, so I'm ignoring it.
That's it. Everything's pretty much done except for the non-US stuff
(which I'm assuming I'll have to defer to Bart, who usually handles non-US
for us). Like I said, at this point, though, I'm binary NMU'ing
everything in sight since alot of patches were ignored or not submitted in
time and probably won't be important enough to change the momentum of
releasing potato. Figured we'll deal with the problems in a point release
afterwards (or in woody).
C
Reply to: