Tobias Hansen <tobias.han@gmx.de> (04/06/2012): > I thought removing allegro4.2 would be the next step. But now that you > say it, that's not necessary, because liballegro4.2-dev was replaced, > right? Also alogg and allegro-demo-data, but they're also no obstacle > for the transition, except that alogg will FTBFS with allegro4.4. Since that's a new source package, there are no “out-of-date” binaries, which is the usual case (source packages dropping binaries, meaning they need to be removed from unstable once packages are binNMUd to link against new packages). That can be checked on the excuses page: http://release.debian.org/britney/update_excuses.html#allegro4.4 As for alogg/allegro-demo-data, we'll see what to do with those when allego4.4 becomes a candidate for migration. Right now, I'm a little worried about the ia64 FTBFS. allegro4.2 was building fine there, so we're likely to have packages that won't be buildable any more. That should be solvable by getting those packages removed on ia64 only, until the ICE (Internal Compiler Error) is fixed; but we'll have to check what happens with reverse dependencies… There might be better ways, though. (Trying to reproduce the ICE and filing a bug report in both the debian/upstream bug tracker would be nice in any case.) Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature