On Thu, Aug 11, 2005 at 05:42:05PM -0700, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > On Thu, Aug 11, 2005 at 04:32:57PM -0400, Joey Hess wrote: > >> krb5 > >> 28 days old > >> FTBFS on m68k due to gcc ICE, needs followup > > Is this one that we should consider pushing into testing without the m68k > > binaries? > Mea culpa on the delay on this one. The build failed *right* before the > ftpmaster move in a way that meant there wasn't a build log available, so > I assumed that it was something the buildd admin was going to look at when > ftpmaster came back. I only discovered later that I could still get the > compilation failure. > I've already checked with the m68k team. It's not apparently a known ICE, > so the next step is probably to disable optimization on m68k and see if > that will build. I'm going to prepare a new upload with just that change, > but at this point a new upload to unstable would be stalled by the glibc > migration. > Given that, it might be best to push the existing build into testing > without m68k and I'll then upload a version with optimization disabled on > m68k once that's happened (so that I don't interfere with that process). > Alternately... > > So, we're probably going to be sitting here for a while waiting on glibc > > yet, and many of these packages have newer versions on all archs in > > unstable, which makes them candidates for uploads to t-p-u. Even hppa > > should be fine for t-p-u, though we may have to get things selectively > > reenabled on sarti for that. Is it time to start doing testing NMUs for > > some of the packages on this list? > ...I can prepare an upload for t-p-u with optimization disabled on m68k > instead. $ madison -a m68k -s testing,unstable libkrb53 libkrb53 | 1.3.6-3 | testing | m68k libkrb53 | 1.3.6-3 | unstable | m68k $ Since there's no newer build of krb5 in unstable on m68k, t-p-u is not an option here because katie will reject the newer m68k build if uploaded with testing as a target, and approving the t-p-u update into testing without the m68k build will actually result in the removal of the current m68k packages from testing. Approving the current unstable version is sure to give a better outcome, since the worst that could happen is that the old m68k packages are still in present, and *some* of them are uninstallable due to arch: all/any entanglement or library soname changes. In fact, though, I don't see any issues that would leave m68k any worse off than it is now if we push the update in on the other archs, so I'm going to go ahead and do this. Once it's in, the next step would have to be an upload to unstable that fixes the m68k build (or a fix for the m68k toolchain, if that happens sooner). Whether that should be followed by an upload to t-p-u probably depends on just how long it takes to get glibc sorted. > (Should such uploads follow the stable-style convention of > adding etchN to the Debian version?) Yes, that's the procedure. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I will move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature