Bug#972758: ABI breakage without soname bump
On 2020-10-23 15:32:48, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote: > > If we want to support the interim versions that have never been in a > > stable release, then I think the only way is to bump the minmum > > version in liburing shlibs and symbols files to 0.7, then rebuild the > > couple of packages built with 0.6 against 0.7, and then add Breaks in > > liburing against the old dependent package versions using the previous > > liburing releases. > > Well, seemingly there are people who run old sid, and then only > “apt update ; apt install plocate” -- which will pull in newer plocate > but not liburing1 :-) Yes, but those people know (or should know) that this is somewhat risky, always. I do that sometimes, but I'm not surprised when things do break. > But all that _must_ be supported as per Policy is upgrades from stable to > stable, I believe? Not entirely sure how strict it is. It helps that > liburing1 has never been in stable (only stable-bpo). +1 here, stable-to-stable should be enough.
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote: > If we want to support the interim versions that have never been in a > stable release, then I think the only way is to bump the minmum > version in liburing shlibs and symbols files to 0.7, then rebuild the > couple of packages built with 0.6 against 0.7, and then add Breaks in > liburing against the old dependent package versions using the previous > liburing releases. Well, seemingly there are people who run old sid, and then only “apt update ; apt install plocate” -- which will pull in newer plocate but not liburing1 :-) But all that _must_ be supported as per Policy is upgrades from stable to stable, I believe? Not entirely sure how strict it is. It helps that liburing1 has never been in stable (only stable-bpo). > Otherwise I'll just package the new upstream release and request a > rebuild of reverse dependencies, and we could just ignore 0.7 as if > it never existed. :) Yes, a soname bump would certainly do the trick for unstable. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
Control: forwarded -1 https://github.com/axboe/liburing/issues/228 Hi! On Fri, 2020-10-23 at 12:20:30 +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > > seems to have bumped SONAME upstream. > > That would fix it, yes, but it seems to have missed the kflags change > (the commit says all added padding is at the end). > > The kflags change was made a month or so before 0.7 release: > > > https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 Ouch, right, missed that one. :/ Thanks for the report and analysis. On Fri, 2020-10-23 at 12:47:00 +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote: > > All that's needed is a 0.8 release I guess. Reported and requested this upstream. > Yes, that would fix it. Optionally, one would require something like > a Breaks: liburing (<< 0.7-2) added on all packages compiled against > liburing, plus versioned Breaks on liburing1 on all packages in the > archive ever built against pre-0.7. :-/ If we want to support the interim versions that have never been in a stable release, then I think the only way is to bump the minmum version in liburing shlibs and symbols files to 0.7, then rebuild the couple of packages built with 0.6 against 0.7, and then add Breaks in liburing against the old dependent package versions using the previous liburing releases. Otherwise I'll just package the new upstream release and request a rebuild of reverse dependencies, and we could just ignore 0.7 as if it never existed. :) Thanks, Guillem
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote: > All that's needed is a 0.8 release I guess. Yes, that would fix it. Optionally, one would require something like a Breaks: liburing (<< 0.7-2) added on all packages compiled against liburing, plus versioned Breaks on liburing1 on all packages in the archive ever built against pre-0.7. :-/ /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 12:20:30PM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > > seems to have bumped SONAME upstream. > > That would fix it, yes, but it seems to have missed the kflags change > (the commit says all added padding is at the end). > > The kflags change was made a month or so before 0.7 release: > > > https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 > Yeah, I'm not saying the commit message is accurate, just that that change will end up fixing this bug. :) All that's needed is a 0.8 release I guess. Cheers, Julien
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > seems to have bumped SONAME upstream. That would fix it, yes, but it seems to have missed the kflags change (the commit says all added padding is at the end). The kflags change was made a month or so before 0.7 release: https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 10:47:57AM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote: > > If this were somehow only about newer functionality or critical fixes, it > > could > > be fixed by bumping the versioned dependency, but rhis goes both ways; if > > you > > build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, > > you get a similar crash. So it would seem there's hidden ABI breakage here > > that > > needs a soname bump. > > It seems there's a new “unsigned *kflags;” added in the middle of > struct io_uring_cq that would explain this. > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd seems to have bumped SONAME upstream. Cheers, Julien
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote: > If this were somehow only about newer functionality or critical fixes, it > could > be fixed by bumping the versioned dependency, but rhis goes both ways; if you > build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, > you get a similar crash. So it would seem there's hidden ABI breakage here > that > needs a soname bump. It seems there's a new “unsigned *kflags;” added in the middle of struct io_uring_cq that would explain this. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
Package: liburing1 Version: 0.7-1 Severity: grave Tags: upstream Hi, I've had a number of reports from people who are having problems with plocate, that can be traced to differing versions of liburing1. Specifically, plocate is built in sid against liburing1 0.7-1 (which gets a versioned dependency only on liburing1 >= 0.4), but if people instead have liburing1 0.6-3 on their systems, they crash: kos:~> plocate plocate md5sums /home/sesse/nmu/plocate-1.0.2/debian/.debhelper/plocate/dbgsym-root/DEBIAN/md5sums /home/sesse/nmu/plocate-1.0.2/debian/plocate/DEBIAN/md5sums /var/lib/dpkg/info/plocate-dbgsym.md5sums /var/lib/dpkg/info/plocate.md5sums kos:~> sudo dpkg -i liburing1_0.6-3_amd64.deb [...] kos:~> plocate plocate md5sums zsh: segmentation fault plocate plocate md5sums If this were somehow only about newer functionality or critical fixes, it could be fixed by bumping the versioned dependency, but rhis goes both ways; if you build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, you get a similar crash. So it would seem there's hidden ABI breakage here that needs a soname bump. /* Steinar */
