Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 02:27:02AM +0200, Emilio Pozuelo Monfort wrote: On 03/07/14 19:50, Aurelien Jarno wrote: On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote: 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. Thanks. I don't use s390x either, but clearly there are people who do, and broken upgrades for a few weeks don't seem acceptable to me. So do I wait until poppler is done? Please ping me when it's OK to upload. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... -- Niko Tyni nt...@debian.org -- 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/20140705064844.GA8315@estella.local.invalid
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 05/07/14 08:48, Niko Tyni wrote: On Sat, Jul 05, 2014 at 02:27:02AM +0200, Emilio Pozuelo Monfort wrote: 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. Thanks. I don't use s390x either, but clearly there are people who do, and broken upgrades for a few weeks don't seem acceptable to me. So do I wait until poppler is done? Please ping me when it's OK to upload. I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Emilio -- 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/53b7c92c.9010...@debian.org
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: On 05/07/14 08:48, Niko Tyni wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. I'm not very enthusiastic about this. It's basically lying: we don't offer the old ABI anymore so we should be straight about it. An uninstallable package seems better than a broken one. But I can see it would help the transition, and it wouldn't cause a regression, it would just make the fix take longer. So yes, I can do that if you want. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Sure, fixing them is certainly preferrable :) It's just that I've recently rebuilt the same set of packages for the 5.20 transition and ISTR encountering quite a few known long-standing FTBFS bugs. I suppose those packages aren't in testing anymore, though; I didn't look at that part much in my tests. -- Niko Tyni nt...@debian.org -- 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/20140705163118.GA5299@estella.local.invalid
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Control: reassign -1 perl-base,release.debian.org Control: user release.debian@packages.debian.org Control: usertags -1 transition On 05/07/14 18:31, Niko Tyni wrote: On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: On 05/07/14 08:48, Niko Tyni wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. I'm not very enthusiastic about this. It's basically lying: we don't offer the old ABI anymore so we should be straight about it. An uninstallable package seems better than a broken one. But I can see it would help the transition, and it wouldn't cause a regression, it would just make the fix take longer. It would make the fix only take longer for people who do partial uploads, right? The users who do a dist-upgrade and get all the updated perl modules that we have binNMUed should be fine, right? And then after things have been rebuilt and any potential FTBFS have been fixed, we drop the old perlapi Provides, and then partial upgrades won't be possible (thus fixing that case as well). The alternative is delaying the migration until everything has been rebuilt and all the FTBFS bugs have been fixed. I think keeping the provides for now is a better option, but I don't know Perl so I may be missing something. If you want to drop them now, that's fine with me. So yes, I can do that if you want. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Sure, fixing them is certainly preferrable :) It's just that I've recently rebuilt the same set of packages for the 5.20 transition and ISTR encountering quite a few known long-standing FTBFS bugs. I suppose those packages aren't in testing anymore, though; I didn't look at that part much in my tests. I suppose you don't have a list? #735623 could be a problem. #742409 as well. That's not an exhaustive list and I haven't checked if those could be removed from testing (if they are leaf packages). That's why I think a smooth transition (i.e. keeping the provides for now) would be preferable. That said, feel free to upload perl now. Regards, Emilio -- 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/53b832cc.1070...@debian.org
