Am 04.06.2012 01:05, schrieb Cyril Brulebois: > 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. allegro4.4 is now a migration candidate and I didn't get access to a porterbox yet. Can we continue the transition? Best regards, Tobias
Attachment:
signature.asc
Description: OpenPGP digital signature