Re: testing security blockers
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. (Should such uploads follow the stable-style convention of
adding etchN to the Debian version?)
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: