On Sat, Jul 02, 2011 at 10:25:51PM +0300, Niko Tyni wrote:
> On Fri, Jul 01, 2011 at 02:28:12PM -0500, Jonathan Nieder wrote:
> > Niko Tyni wrote:
>
> > > Maybe go back to specifying plibpth manually to Configure for a while
> > > (overriding the upstream change of parsing 'gcc -print-search-dirs'
On Thu, Jun 30, 2011 at 10:28:31PM +0300, Niko Tyni wrote:
> Based on this, I think it's feasible for libc6 to Break just perl-modules.
> Of course, this can be revisited in case it causes actual upgrade problems.
One more note on this: I think it would be better for libc6 to Break
perl and not p
On Fri, Jul 01, 2011 at 02:28:12PM -0500, Jonathan Nieder wrote:
> Niko Tyni wrote:
> > Maybe go back to specifying plibpth manually to Configure for a while
> > (overriding the upstream change of parsing 'gcc -print-search-dirs'),
> > and Build-Depend on
> > gcc-4.6 (>= 4.6.0-13) | gcc-4.4 (>=
Niko Tyni wrote:
> A couple of quick notes:
>
> - a sourceful change to make sure the multiarch paths are included
> in libpth is still necessary. The powerpc build of 5.12.4-1 was done
> on a buildd that with an old enough gcc + libc6 that it's still not
> multiarch enabled
>
> https://
On Thu, Jun 30, 2011 at 10:28:31PM +0300, Niko Tyni wrote:
> That means the gcc-4.6 build dependency option is looking better again.
> Build-Depends: gcc-4.6 (>= 4.6.0-13) [!sparc], gcc-4.4 (>= 4.4.6-4) [sparc]
A couple of quick notes:
- a sourceful change to make sure the multiarch paths are
On Tue, Jun 21, 2011 at 10:37:57PM +0300, Niko Tyni wrote:
> On Tue, Jun 21, 2011 at 10:03:29AM -0500, Jonathan Nieder wrote:
> > Aside from "perl -V::libpth" itself and the perl build process, the
> > only code I can find that cares about libpth is the DynaLoader module
> > (and hence ExtUtils::E
On Tue, Jun 21, 2011 at 10:03:29AM -0500, Jonathan Nieder wrote:
> Niko Tyni wrote:
>
> > I'd really like to avoid a situation where a perl binNMU may render
> > upgrades from squeeze impossible.
> >
> > The only broken functionality that we're currently aware of
> > (ExtUtils::Embed) is actually
Niko Tyni wrote:
> Clarification: I don't think this works because it leaves
> /lib/x86_64-linux-gnu out.
Sorry, mails crossed. It's in libgcc.
> I guess we could also patch Configure not to check the existence of the
> directories but that doesn't seem very elegant to me...
Actually, that see
Niko Tyni wrote:
> I'd really like to avoid a situation where a perl binNMU may render
> upgrades from squeeze impossible.
>
> The only broken functionality that we're currently aware of
> (ExtUtils::Embed) is actually in perl-modules.
Aside from "perl -V::libpth" itself and the perl build proces
On Tue, Jun 21, 2011 at 03:21:44PM +0300, Niko Tyni wrote:
> On Tue, Jun 21, 2011 at 01:46:32AM -0500, Jonathan Nieder wrote:
> > Ah, here we go. Based on how Configure computes libpth, what I should
> > have said is gcc-4.6 (>= 4.6.0-12).
>
> Because that would also make sure there's something
On Tue, Jun 21, 2011 at 01:46:32AM -0500, Jonathan Nieder wrote:
> Niko Tyni wrote:
> > I wonder if there's a danger of an unrelated future change (in either
> > perl or eglibc) bumping the version constraint and causing problems.
> > However, I don't think we should worry about that overmuch at t
Niko Tyni wrote:
> On Mon, Jun 20, 2011 at 04:05:49PM -0500, Jonathan Nieder wrote:
>> unpack new perl-base
>> unpack multiarchified libc
>> configure multiarchified libc
>> configure new perl-base
>
> I wonder if there's a danger of an unrelated future change (in either
> perl
Package: perl
Version: 5.12.3-7
Severity: important
At some point we need to look at the implications of multiarch
changes for squeeze->wheezy partial upgrades.
The libc upgrade that moved libc.so.6, libdl.so.2 and so forth
to the multiarch directories broke at least ExtUtils::Embed
from perl-mod
13 matches
Mail list logo
