Hi all,
This is a quick note to let you know that things are nearly ready to allow
updates of apt, libsigc++1.2, gtkmm2.0, and related packages into etch as
part of the C++ ABI transition. At this point, the main blocker is perl,
which is expected to be a candidate for testing soon once a new upl
On Sun, Oct 16, 2005 at 04:05:17PM -0700, Thomas Bushnell BSG wrote:
> The png/imlib transition is now done, I believe. All the packages
> that directly depend on png or the other libraries in turn are
> uploaded, and once they have been built by the lagging autobuilders
> and aged, they can be h
Package: ftp.debian.org
Greetings,
Apparently, someone hand-built version 3.1-2 of my parmetis package for
mips, and this is one of the blockers for about 20 packages going into
testing. Please remove that version (and/or build 3.1-3 for mips :-).
Thanks,
-Adam
--
GPG fingerprint: D54D 1AEE B1
On Sun, 2005-10-16 at 13:51 +0200, Frank Lichtenheld wrote:
> On Sun, Oct 16, 2005 at 04:40:31AM -0700, Steve Langasek wrote:
> > FWIW, we're very close now to being able to get everything into testing.
> > The remaining blockers are:
> >
> > rmpi needs built on arm and hppa
> > scalapack needs bu
On Sun, Oct 16, 2005 at 03:25:42PM -0400, Nathanael Nerode wrote:
> So bin-NMUs are appropriate for packages which are waiting for new libpng
> and which are blocking something else. Pity I can't do them yet. :-)
But if you know of such dependencies blocking something, you can tell this
list ab
The big elephant being swallowed by the snake of the gcc-4 transition
is currently the KDE libraries, right? This impacts me because
gnucash/libofx/opensp can't move into testing until kmymoney2 is
ready, which ties it in with all of the KDE transition.
Is there a web page that tracks the curren
The png/imlib transition is now done, I believe. All the packages
that directly depend on png or the other libraries in turn are
uploaded, and once they have been built by the lagging autobuilders
and aged, they can be hinted in.
But there is a hiccup. One package that directly depends on libpn
vorlon wrote:
This is better fixed by reuploading the packages currently blocked on
libpng, such that they get built with a libpng that doesn't require bumped
shlibs.
Oh ah. I somehow hadn't quite figured out that rebuilds against the new
libpng would *downgrade* the
dependency, although it
Hmm, a list of binary packages would probably be more useful for purposes
of
checking out what warrants a rebuild.
OK, I'll work on it. :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Oct 16, 2005 at 03:09:13AM +0200, Frank Lichtenheld wrote:
> Hi there.
>
> Quite a few RC bugs against packages exist that refer to #317475
> as possible cause for FTBFS on m68k. AFAIK this could be fixed with
> gcc 4.0.2. How should this be tested? Will you just requeue them
> or should w
On Mon, Sep 19, 2005 at 06:32:24PM +0200, Steinar H. Gunderson wrote:
> I just uploaded evms 2.5.3-2, but it can't reach testing since it has an
> udeb. Please add the appropriate hint so it can enter testing when it's time.
> Thanks :-)
Well, you need to let the package sit for 10 days without r
On Sun, Oct 16, 2005 at 04:40:31AM -0700, Steve Langasek wrote:
> FWIW, we're very close now to being able to get everything into testing.
> The remaining blockers are:
>
> rmpi needs built on arm and hppa
> scalapack needs built on arm, hppa, mipsel, and sparc
> octave2.1 needs built on arm
> oct
Hi Steffen,
On Wed, Oct 12, 2005 at 01:17:07PM +0200, Steffen Moeller wrote:
> On Wed, Oct 12, 2005 at 02:08:21AM -0700, Steve Langasek wrote:
> > On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> > > Here is the current status of the mpich/hdf5/lam migration.
> > > Only one package
On Wed, Sep 21, 2005 at 09:19:04PM +0900, Adam C Powell IV wrote:
> On Thu, 2005-09-08 at 20:18 -0400, Adam C Powell IV wrote:
> > Status report:
> > * petsc: done a long time ago
> > * parmetis: fixed and done last week.
> > * illuminator: finally got time to finish and upload ye
Hi,
Luk Claes wrote:
>>>0-day NMUs are fine, as long as it is emphasized that it's only
>>>appropriate if the usual maintainer doesn't work on the issue. I.e. you
>>>either need to try to contact the developer or only operate on
>>>reasonably "old" bugs; better both.
>>>
>>>Otherwise things like
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Stigge wrote:
> Hi,
Hi
> thanks for the update.
>
> Steve Langasek wrote:
>
>>NMU policy
>>~~
>>After lots of experimentation with NMU policies during the sarge release
>>process, it's pretty clear that permissive NMU policies had a
Hi,
thanks for the update.
Steve Langasek wrote:
> NMU policy
> ~~
> After lots of experimentation with NMU policies during the sarge release
> process, it's pretty clear that permissive NMU policies had a HUGE,
> positive impact on our ability as a project to cope with outstanding
> rele
On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> Hello,
>
> Now that we have a solution for the ramdisk generation tool mess, we can go
> ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do
> the same with 2.6.14 shortly after that, while 2.6.12 is safely i
On Sat, Oct 15, 2005 at 04:03:48PM -0400, Nathanael Nerode wrote:
> For libpng. I think this is all that's needed. gdk-pixbuf can't
> go in in advance of libpng because it has a too-high versioned dependency
> on some architectures.
This is better fixed by reuploading the packages currently bloc
19 matches
Mail list logo
