Re: How to get KDE in: total analysis
- To: email@example.com
- Subject: Re: How to get KDE in: total analysis
- From: Nathanael Nerode <firstname.lastname@example.org>
- Date: Mon, 31 Oct 2005 16:25:31 -0500
- Message-id: <email@example.com>
- References: <20051029210749.GA13137@twcny.rr.com> <20051031014421.GC13701@tennyson.dodds.net>
Steve Langasek wrote:
> In any case, please see
> http://ftp-master.debian.org/~vorlon/KDE-missing-bysource.txt for a
> separate analysis.
With reference to that :-), please note the following; after going through
that and the hints file these are the only notable omissions I found (in
rough order from blatant to minor):
* bibletime/1.4.1-2.1 *will not* be removed from testing unless
bibletime-i18n/1.4.1-1 (yes, this is a different source package)
is also removed. So the removal hint needs to be fixed.
* kismet, which is under "other packages needing investigation", depends on
new libstdc++ (on *every* architecture for which the current version
built), so whether or not it needs a new upload on MIPS is kind of
irrelevant; it will have to be removed from testing, since breaking it
on every architecture is obviously worse. (Old version broken by new
KDE.) No reverse depends.
* You didn't notice lincvs (non-free); depends on libstdc++ on ia64,
old version broken by new qt-x11-free, probably removable
* hplip (not noted) definitely needs further investigation. Old version
(0.9.3-3) of hplip-base is broken by new net-snmp. New version
(0.9.6-1) of hplip doesn't produce hplip-base anymore, and has
changed hplip from arch:all to arch:any. (melanie needs to remove
hplip-base 0.9.5-4, perhaps?) New hplip depends on new libstdc++ on
i386 and powerpc. hpijs (same source package) didn't build on sparc.
Make of this what you can, as I am still confused. :-P
* dvdauthor and cheops, which are just waiting for sparc builds, have in
fact already built on sparc (Friday) and are just waiting for the packages
to be uploaded by the buildd maintainer.
* wine/0.9-1 is too young (2/10 days). (Old version broken by new JACK.)
It *doesn't* depend on libstdc++. The new version is RC-bug-free
and in fact the first upstream beta (as opposed to alpha), so a good