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-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
