Anthony Towns wrote:
> Joey Hess
> 157913 [ ] FTBFS: conflicting declarations
This bug is not reproducible on unstable ia64. There are plenty more
though, that make it fail to build. Pavel Tcholakov is already being
tracked by MIA tracking. I have NMU'd hylafax (5-day delayed), fixing
the FTBFS, and have closed this bug.
NOTE: Still need to fix the grave bug #173024. Seems to have been fixed
before as bug #113849 and reverted. Have mailed Karsten to see if
it is still a problem with 4.1.2.
> 158327 [ ] FTBFS: Build failure of tfm-arphic on i386
Reproduced bug by removing tetex-bin; added tetex-bin to build-dep and
uploaded to 7-day delayed. Maintainer is busy at work.
> 159165 [ R ] does not play anything
Only in non-US/stable these days, tagged bugs for woody.
> 159494 [P ] current libwww-search-perl version unusable
Already fixed a while ago, now closed.
> 159548 [ ] FTBFS: Build failure of hugs98 on i386
Isaac Jones is in the process of taking this package over. Brought the
bug to his attention, he fixed it and all the other bugs in hugs too.
TODO: the new upload got a new FTBFS bug, make sure it is followed up on
- Isaac (NM) just needs to be able to test his fix.
> savant,
Dale Martin will be putting a new upstream release in debian that fixes
all known problems, in "the next week or so". Has to get clutils in
first.
> snes9x
snes9express and gsnes9x are in contrib and built for more architectures
than their dependency, snes9x, in non-free, ever will be. In leu of a
general fix for this type of problem, I recommend that we (this menas
you, aj) force snes9x into testing. This will only make gsnes9x and
snes9express fail to install on one more architecture, s390. They already
fail on alpha, arm, hppa, ia64, mips, mipsel, and sparc.
snes9x is ready for testng now aside from the above.
> scm
NMU'd with patch in bug #191171, to 7-day delayed queue. Maintainer
thinking about orphaning.
> -clanlib0
clanracer in testing depends on clanlib0, and the unstable version of
clanracer cannot go into testing until the new clanlib package does.
clanlib is in turn held up by the race package, that depends on an old
version of it. race is not fixable until clanlib 0.7 gets into debian
(#178447). That could take some time (#188449).
The new clanlib (libclan2-vorbis) also depends on libvorbis0a which is
not in testing. libvorbis0a is blocked from testing by many, many
packages. For example, audacity blocks it, and will not go into testing
until wxwindows2.4 is fixed to build on hppa.
If we really wanted to get rid of clanlib0 for some reason, we could
remove race, trophy, clanracer, pingus, and clanbomber from testing.
Does not seem to be worth it; clanlib0 is not causing any problems by
remaining in testing for now, is it?
--
see shy jo
Attachment:
pgp0qTKSJ7iJH.pgp
Description: PGP signature