Re: Freeze exceptions: parmetis, ccc, babel, illuminator; please be considerate to busy developers
- To: Steve Langasek <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: Freeze exceptions: parmetis, ccc, babel, illuminator; please be considerate to busy developers
- From: Adam C Powell IV <firstname.lastname@example.org>
- Date: Thu, 02 Jun 2005 14:38:49 -0400
- Message-id: <email@example.com>
- In-reply-to: <20050528074308.GL11298@mauritius.dodds.net>
- References: <firstname.lastname@example.org> <20050519144037.GI5158@mauritius.dodds.net> <email@example.com> <20050528074308.GL11298@mauritius.dodds.net>
On Sat, 2005-05-28 at 00:43 -0700, Steve Langasek wrote:
> On Thu, May 26, 2005 at 11:17:24AM -0400, Adam C Powell IV wrote:
> > > > * babel: closes FTBFS bugs on arches where it works and adds a new
> > > > package; if accepted, I'll upload 0.10.2-2 specifying build only
> > > > for successful arches (i386, powerpc, sparc).
> > > Er, this package has an open RC bug in unstable.
> > Right, please read what I wrote: it builds fine on those three arches,
> > and I'd upload it specifying only those (closing the bug) if accepted.
> > Its failure to build on others is the fault of kaffe, not this package.
> > I don't think uploading an architecture-restricted version to unstable
> > is the right thing to do, since the toolchain is still evolving (it's
> > supposed to work everywhere). But I don't know if that will change your
> > mind.
> Ah. It wasn't clear to me that you meant the currently open RC bug was
> related to this, and I didn't look.
> Looking at that bug, I don't see how it's babel's fault at all; it's
> definitely not RC given that babel doesn't seem to have ever built on s390,
> and I don't see any reason to reupload just to lock out the possibility of
> the build succeeding on one of these other architectures later.
> If you downgrade the bug, I think we can let 0.10.2-1 into testing as-is.
Done early yesterday. Can you please let it in now? Thanks.
> > > > * illuminator: 0.9.1 has better dependencies on new petsc and
> > > > mpich package structure than 0.9.0; 0.9.0 closed important bugs
> > > > in 0.8.9. An old kernel bug on the sparc buildd prevented --
> > > > and continues to prevent -- it from building there. If
> > > > accepted, I'll add options to dh_shlibdeps to work around sparc
> > > > buildd brokenness.
> > > This is a new upstream version that was uploaded at the beginning of the
> > > freeze, so I don't see that it would be appropriate to push into sarge at
> > > this point.
> > A new upstream with only a small change, whose preparation/testing had
> > been in the works for months but got rushed by the sudden freeze. The
> > only reason 0.9.0-1 isn't in sarge is because of a broken sparc buildd;
> > 0.8.9-2 in testing has an important bug in documentation (255908) and a
> > bloated binary which breaks prelink because of ancient static-linked
> > mpich code (whose fix took two months to get through the NEW queue).
> > Should I upload 0.9.0-2.sarge.1 into testing, with a workaround for the
> > broken sparc buildd?
> No, testing-proposed-updates doesn't get enough testing for it to be sanely
> used for pushing new upstream versions. If you can fix the two bugs you
> describe with an upload of 0.8.9 to t-p-u, that would be ok.
Okay, uploaded yesterday, looks like someone let it in, though the
buildd page doesn't list it. I'll wait another day and see if it gets
Thanks very much!
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!