[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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).


> 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: