On Sat, Oct 15, 2005 at 04:30:28PM -0400, Nathanael Nerode wrote:
> [EMAIL PROTECTED] wrote:
> > Please note that libssl0.9.7 and libssl0.9.8 have a different
> > SONAME. There can only be a problem when a program (indirectly)
> > links to both of them. In that case, there isn't even an option
>
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 we do manual builds on crest? Or is the bug known to not
be fixed at all?
Here
[EMAIL PROTECTED] wrote:
> Please note that libssl0.9.7 and libssl0.9.8 have a different
> SONAME. There can only be a problem when a program (indirectly)
> links to both of them. In that case, there isn't even an option
> not to install both of them.
>
> If a program is linked to both of them,
The following packages appear to have been built against openssl 0.9.8
without versioned symbols, and libraries or programs from them will
accordingly misbehave if libssl0.9.7 ever ends up linked into the same
program as one of them:
crypt-ssleay
curl
newpki-lib
sqlrelay
cogito
fireflier
nag
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.
Anyway, it should give good output.
# 207756, 328338, 331082
remove amaya/9.5-1
# dillo's tied up with openssl
remove dillo/0.8.3-1.1
On Sat, Oct 15, 2005 at 03:39:08PM -0400, Nathanael Nerode wrote:
> > > Packages built against the unversioned libssl0.9.8 will, when run on a
> system
> > > with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7
> > > (wrong) or not find their symbols (segfault). Accordingly,
> > Packages built against the unversioned libssl0.9.8 will, when run on a
system
> > with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7
> > (wrong) or not find their symbols (segfault). Accordingly, all packages
> > linked against the current libssl0.9.8 are in trouble an
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 09:00:38PM +0900, Horms wrote:
> > > > The other issue is that 2.6.14 is scheduled for release in the not so
> > > > distant
> > > > future, so we may skip uploading .13-3 to unstable and go for .14-1
> > > > directly,
> > > > depending on status of newly introduced breaka
On Sat, Oct 15, 2005 at 01:11:17PM +0200, Kurt Roeckx wrote:
>
> What I'm wondering about was the need for a Conflict between
> libssl0.9.7 and libssl0.9.8. I think we should do it, but it's
> going to make migration to testing alot harder, but hopefully the
> last time.
Having talked to with th
On Sat, Oct 15, 2005 at 01:13:31PM +0200, Sven Luther wrote:
> On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote:
> > On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> > > the plan for solving the ramdisk issues is done in three stages, current
> > > svn
> > > 2.6.13 packa
Hi Enrique, Wesley, Martin, Guenter,
This note is to let you know that the source packages freqtweak,
cheesetracker, fireflier, and seq24 are being dropped temporarily from
testing in order to split the wxwindows2.4 and libsigc++-1.2 ABI transitions
from the Qt and JACK ABI transitions which aren'
On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote:
> On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> > the plan for solving the ramdisk issues is done in three stages, current svn
> > 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> > initramf
On Fri, Oct 14, 2005 at 04:38:53PM -0700, Steve Langasek wrote:
> On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote:
> > > Finally, are there any plans to alleviate testing migration issues for
> > > packages held up by this, and if so, how?
>
> The way to alleviate testing migrati
On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> the plan for solving the ramdisk issues is done in three stages, current svn
> 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
>
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 in etch.
As mentioned in :
...
the plan for solving the ramdisk iss
* Steve Langasek ([EMAIL PROTECTED]) [051015 01:39]:
> On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote:
> > > Finally, are there any plans to alleviate testing migration issues for
> > > packages held up by this, and if so, how?
>
> The way to alleviate testing migration issues i
17 matches
Mail list logo
