On 03/07/14 19:50, Aurelien Jarno wrote:
On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote:
On Thu, Jul 03, 2014 at 08:48:37AM +0200, Aurelien Jarno wrote:
On Wed, Jul 02, 2014 at 11:29:58PM +0200, Bastian Blank wrote:
The problem is a missmatch between the jmp_buf size in perl vs. modules.
Aka the build against glibc 2.19 changed the public ABI of perl.
Yes, jmp_buf had to be increased to support new CPUs. This has been done
using symbol versioning, but unfortunately it doesn't work when jmp_buf
is embedded in a struct like in perl.
Upstream consider this as a non-issue and recommend to do the upgrade of
all the perl packages in a lockstep.
I see. A bit of googling turns up the related
https://bugzilla.redhat.com/show_bug.cgi?id=1064271
I note that Carlos O'Donell says there
I expect Ruby is going to fail also since it embeds jmp_buf similarly.
Has anybody noticed similar issues with Ruby?
So far I haven't, but as symbol versioning is used, until we start
mixing versions, the problem won't appear.
How do we want to fix this so upgrades won't barf in the users face?
The problem only concerns the jessie to jessie partial upgrades,
dist-upgrades should be fine. wheezy to jessie upgrades are also fine,
due to the perl 5.14 to 5.18 transition. If we want to fix that for
jessie to jessie, one way is to start the perl 5.20 transition.
So all libc6 reverse dependencies have been binNMU'd on s390x for this
in early June? It looks like some have a confusing changelog entry. I
checked libterm-readline-gnu-perl and libreadonly-xs-perl, which state
Rebuild against perl 5.18.
I could make a sourceful perl upload incrementing perlapi-5.18.2 to
for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x
only. This would make ~500 reverse dependencies of perlapi-5.18.*
uninstallable and require a new binNMU round for them. As libperl5.18
has a tight dependency on perl-base, I don't think we'd need to
do anything on the libperl side.
I think this would work fine. From the buildds point of view, the 500
binNMUs should not pose any problem, we have enough build power there.
I think this would be the right way fix this, but I suppose it would
affect ongoing transitions and the like. I'm cc'ing the release team
for advice.
I have come up with:
https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html
Although I would prefer to wait a bit and do 5.20 directly, I'm not affected by
this breakage as I don't have any s390x machines. So if you think this is
important enough, we could go ahead and do it now. The only conflict I see right
now is gdal with the poppler transition, but that one should be finished in two
or three days if everything goes well.
Emilio
It'll still take at least a few weeks before we can do a clean perl 5.20
transition. See #753529.
--
Niko
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b74656.3050...@debian.org
