Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 24 October 2021 at 11:38, Sebastian Ramacher wrote: | On 2021-10-23 19:44:49 -0500, Dirk Eddelbuettel wrote: | > | > I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly | > analysed by Sebastian) in new sonames '26' so I prepared a new version which | > just went out to unstable. | > | > Unless I am mistaken, I need to get the release team on board for a proper | > transition. Correct? | | Yes, the workflow is documented at | https://wiki.debian.org/Teams/ReleaseTeam/Transitions Thank you for the reminder. The last time I did this was likely for the previous libsglSO transition to 25. I also forgot, again, that a new libgslSO triggers NEW and wants a binary upload but corrected that by now so we should get some test builds. I will then reach out to the release team. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 2021-10-23 19:44:49 -0500, Dirk Eddelbuettel wrote: > > I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly > analysed by Sebastian) in new sonames '26' so I prepared a new version which > just went out to unstable. > > Unless I am mistaken, I need to get the release team on board for a proper > transition. Correct? Yes, the workflow is documented at https://wiki.debian.org/Teams/ReleaseTeam/Transitions Cheers > > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly analysed by Sebastian) in new sonames '26' so I prepared a new version which just went out to unstable. Unless I am mistaken, I need to get the release team on board for a proper transition. Correct? Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 16 October 2021 at 17:50, Sebastian Ramacher wrote: | On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote: | > | > On 15 October 2021 at 20:35, Sebastian Ramacher wrote: | > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote: | > | > | > | > Turns out this was fully my fault. The 2.7 release sets the SO number to 26, | > | > and I didn't use that. | > | | > | No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION | > | is 25. gsl 2.6 had current=25, age=0. Increasing current was correct, | > | increasing age wasn't. | > | > I will admit not fully understanding the three components used as eg in | > upstream's configuire.ac: | > | > dnl Library versioning (C:R:A == current:revision:age) | > dnl See the libtool manual for an explanation of the numbers | > dnl | > dnl gsl-1.0libgsl 0:0:0 libgslcblas 0:0:0 | > [...] | > dnl gsl-2.6libgsl 25:0:0 libgslcblas 0:0:0 | > dnl gsl-2.7libgsl 26:0:1 libgslcblas 0:0:0 | > | > and | > | > GSL_CURRENT=26 | > GSL_REVISION=0 | > GSL_AGE=1 | > | > If I understand you correctly we needed / need | > | > dnl gsl-2.7libgsl 26:0:0 libgslcblas 0:0:0 | > | > GSL_CURRENT=26 | > GSL_REVISION=0 | > GSL_AGE=0 | > | > Is that correct (as far as the Debian package goes) ? | | That would have been correct, yes. | | > What do you (ie Sebastian) suggest we do going forward? Be more careful | > about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick | > from GSL upstream now.) | | The change to CURRENT was fine. I would suggest following the rules from | https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html. | | Starting from GSL_CURRENT=25, GSL_AGE=0 from gsl 2.6 and ignoring | everything regarding GSL_REVISION. | | 4. If any interfaces have been added, removed, or changed since the last | update, increment current, and set revision to 0. | | => GSL_CURRENT=26, GSL_AGE=0 | | 5. If any interfaces have been added since the last public release, then | increment age. | | => GSL_CURRENT=26, GSL_AGE=1 | | 6. If any interfaces have been removed or changed since the last public | release, then set age to 0. | | => GSL_CURRENT=26, GSL_AGE=0 Thank you so much Sebastian, that was rather helpful. I think I will look into a package update for Debian, making this a local patch. As this will lead to a new soname I probably will have to upload to experimental first and then trigger a proper migration, correct. | It would be good to have a release of gsl with fixed values (e.g. a gsl | version 2.7.1). Other distributions will be affected by this issue as | well. Agreed. Any thoughts, Patrick? Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote: > > On 15 October 2021 at 20:35, Sebastian Ramacher wrote: > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote: > | > > | > Turns out this was fully my fault. The 2.7 release sets the SO number to > 26, > | > and I didn't use that. > | > | No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION > | is 25. gsl 2.6 had current=25, age=0. Increasing current was correct, > | increasing age wasn't. > > I will admit not fully understanding the three components used as eg in > upstream's configuire.ac: > > dnl Library versioning (C:R:A == current:revision:age) > dnl See the libtool manual for an explanation of the numbers > dnl > dnl gsl-1.0libgsl 0:0:0 libgslcblas 0:0:0 > [...] > dnl gsl-2.6libgsl 25:0:0 libgslcblas 0:0:0 > dnl gsl-2.7libgsl 26:0:1 libgslcblas 0:0:0 > > and > > GSL_CURRENT=26 > GSL_REVISION=0 > GSL_AGE=1 > > If I understand you correctly we needed / need > > dnl gsl-2.7libgsl 26:0:0 libgslcblas 0:0:0 > > GSL_CURRENT=26 > GSL_REVISION=0 > GSL_AGE=0 > > Is that correct (as far as the Debian package goes) ? That would have been correct, yes. > What do you (ie Sebastian) suggest we do going forward? Be more careful > about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick > from GSL upstream now.) The change to CURRENT was fine. I would suggest following the rules from https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html. Starting from GSL_CURRENT=25, GSL_AGE=0 from gsl 2.6 and ignoring everything regarding GSL_REVISION. 4. If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. => GSL_CURRENT=26, GSL_AGE=0 5. If any interfaces have been added since the last public release, then increment age. => GSL_CURRENT=26, GSL_AGE=1 6. If any interfaces have been removed or changed since the last public release, then set age to 0. => GSL_CURRENT=26, GSL_AGE=0 It would be good to have a release of gsl with fixed values (e.g. a gsl version 2.7.1). Other distributions will be affected by this issue as well. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 15 October 2021 at 20:35, Sebastian Ramacher wrote: | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote: | > | > Turns out this was fully my fault. The 2.7 release sets the SO number to 26, | > and I didn't use that. | | No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION | is 25. gsl 2.6 had current=25, age=0. Increasing current was correct, | increasing age wasn't. I will admit not fully understanding the three components used as eg in upstream's configuire.ac: dnl Library versioning (C:R:A == current:revision:age) dnl See the libtool manual for an explanation of the numbers dnl dnl gsl-1.0libgsl 0:0:0 libgslcblas 0:0:0 [...] dnl gsl-2.6libgsl 25:0:0 libgslcblas 0:0:0 dnl gsl-2.7libgsl 26:0:1 libgslcblas 0:0:0 and GSL_CURRENT=26 GSL_REVISION=0 GSL_AGE=1 If I understand you correctly we needed / need dnl gsl-2.7libgsl 26:0:0 libgslcblas 0:0:0 GSL_CURRENT=26 GSL_REVISION=0 GSL_AGE=0 Is that correct (as far as the Debian package goes) ? What do you (ie Sebastian) suggest we do going forward? Be more careful about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick from GSL upstream now.) Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote: > > Turns out this was fully my fault. The 2.7 release sets the SO number to 26, > and I didn't use that. No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION is 25. gsl 2.6 had current=25, age=0. Increasing current was correct, increasing age wasn't. Cheers > > So a new package will be forthcoming, and likely need a transition. That > means I should upload to experimental first, right, to then request the > transition? (I'll read up on it later today as a refresher but I guess > Graham is fully immersed in this practice?) > > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Turns out this was fully my fault. The 2.7 release sets the SO number to 26, and I didn't use that. So a new package will be forthcoming, and likely need a transition. That means I should upload to experimental first, right, to then request the transition? (I'll read up on it later today as a refresher but I guess Graham is fully immersed in this practice?) Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Graham, On 15 October 2021 at 13:34, Graham Inggs wrote: | > Yes. And I follow upstream. They didn't change :-/ | | Right, so please speak to your upstream. Dropping (or renaming) a Done. Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there and we get to do (yet another full) transition (which is really the best way to handle this under changes). | symbol is changing the ABI in a backward-incompatible way, and they | need to bump the SONAME (or revert the change). | | This is not something Debian-specific, this is how shared objects in | Unix work [1][2]. Thanks for the pointers. As you may imagine, I actually already have come across this practice in my 26 years with Debian . Best, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Hi Dirk > Yes. And I follow upstream. They didn't change :-/ Right, so please speak to your upstream. Dropping (or renaming) a symbol is changing the ABI in a backward-incompatible way, and they need to bump the SONAME (or revert the change). This is not something Debian-specific, this is how shared objects in Unix work [1][2]. Regards Graham [1] https://en.wikipedia.org/wiki/Soname [2] https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 14 October 2021 at 23:20, Sebastian Ramacher wrote: | On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote: | > | > Hi Sebastian, | > | > On 14 October 2021 at 22:46, Sebastian Ramacher wrote: | > | Hi Dirk | > | | > | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote: | > | > | > | > On 30 August 2021 at 23:42, Niko Tyni wrote: | > | > | Package: libgsl25 | > | > | Version: 2.7+dfsg-2 | > | > | Control: affects -1 libmath-gsl-perl | > | > | Severity: serious | > | > | | > | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: | > | > | | > | > |not ok 7 - use Math::GSL::Matrix; | > | > | | > | > |# Failed test 'use Math::GSL::Matrix;' | > | > |# at t/00-load.t line 14. | > | > |# Tried to use 'Math::GSL::Matrix'. | > | > |# Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. | > | > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. | > | > |# Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > | > |# BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > | > |# Compilation failed in require at t/00-load.t line 14. | > | > |# BEGIN failed--compilation aborted at t/00-load.t line 14. | > | > |ok 8 - use Math::GSL::Poly; | > | > |not ok 9 - use Math::GSL::MatrixComplex; | > | > | | > | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing | > | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from | > | > | entering testing because of this regression in libmath-gsl-perl_0.42-1. | > | > | | > | > | Looks like upstream Math-GSL-0.43 probably no longer references this | > | > | symbol, but it's not in Debian yet and I haven't built and verified that. | > | > | | > | > | Clearly at least something must be done on the libgsl side. Not sure if | > | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks | > | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) | > | > | > | > I am not fully sure what they are doing. They do increment values sometimes, | > | > sometimes they keep them. I mostly just followed along. | > | > | > | > We also for a time tried to accomodate lagging Debian packages. I do not | > | > think that that winnable strategy long term. | > | > | > | > I could add a versioned breaks for libmath-gsl-perl. Can you send me a | > | > preferred expression? | > | | > | No, that would just paper over the problem and wouldn't be a proper fix. | > | | > | There are two options to fix this issue: | > | | > | * Unbreak the ABI by reintroducing the removed symbols. | > | > I think we tried that a few gsl release ago and I don't think it was a success. | > | > | * Bump the SONAME and change the package name. This will trigger a | > | transition and the reverse dependencies will be rebuilt. | > | | > | In any case, the best idea is to talk to upstream. If removal of the | > | symbols was intentional, please ask them to bump the SONAME. | > | > It is AFAICR the opposite: upstream *did* the change years ago, we decided to | > paper over but at some point that becomes too much. Upstream is, in my book, | > the best judge of their code, and if they deprecated / changed something | > years ago then client packages need to (eventually) adapt. | | gsl 2.7 was released in June 2021. So the removal of this symbol is | recent. I see no patches that would have kept that symbol around for | longer than it was needed. In fact, diffing 2.6 and 2.7 suggests that | gsl_linalg_QR_TR_decomp was simply renamed to gsl_linalg_QR_UR_decmp. | | So I'm afraid I am unable to follow your reasoning. This is pretty clear | case of upstream forgetting to bump the SONAME. Yes, possibly. I also grep'ed after sending the email. We did have such an attempt at a 'managed' transition before, and it didn't work so well. | > If the Perl package needs a (deprecated in the library) function and cannot | > change its code, maybe it can stub it locally? | | libmath-gsl-perl will eventually need to be fixed. Still, if gsl removes | a symbol from its public ABI, it needs to bump its SONAME. That's why we | have them and even encode it in package names. Yes. And I follow upstream. They didn't change :-/ Dirk | Cheers | | > | > Dirk | > | > | > | Cheers | > | | > | > | > | > | I've also filed the separate bug #993323 about libmath-gsl-perl failing to | > | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. | > | > | > | > Right. | > | > | > | > Dirk | > | > | > | > | -- | > | > | Niko Tyni nt...@debian.org | > | > | > | > -- |
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote: > > Hi Sebastian, > > On 14 October 2021 at 22:46, Sebastian Ramacher wrote: > | Hi Dirk > | > | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote: > | > > | > On 30 August 2021 at 23:42, Niko Tyni wrote: > | > | Package: libgsl25 > | > | Version: 2.7+dfsg-2 > | > | Control: affects -1 libmath-gsl-perl > | > | Severity: serious > | > | > | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest > regressions: > | > | > | > |not ok 7 - use Math::GSL::Matrix; > | > | > | > |# Failed test 'use Math::GSL::Matrix;' > | > |# at t/00-load.t line 14. > | > |# Tried to use 'Math::GSL::Matrix'. > | > |# Error: Can't load > '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for > module Math::GSL::Linalg: > /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: > undefined symbol: gsl_linalg_QR_TR_decomp at > /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. > | > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line > 11. > | > |# Compilation failed in require at > /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. > | > |# BEGIN failed--compilation aborted at > /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. > | > |# Compilation failed in require at t/00-load.t line 14. > | > |# BEGIN failed--compilation aborted at t/00-load.t line 14. > | > |ok 8 - use Math::GSL::Poly; > | > |not ok 9 - use Math::GSL::MatrixComplex; > | > | > | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing > | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from > | > | entering testing because of this regression in libmath-gsl-perl_0.42-1. > | > | > | > | Looks like upstream Math-GSL-0.43 probably no longer references this > | > | symbol, but it's not in Debian yet and I haven't built and verified > that. > | > | > | > | Clearly at least something must be done on the libgsl side. Not sure if > | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks > | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) > | > > | > I am not fully sure what they are doing. They do increment values > sometimes, > | > sometimes they keep them. I mostly just followed along. > | > > | > We also for a time tried to accomodate lagging Debian packages. I do not > | > think that that winnable strategy long term. > | > > | > I could add a versioned breaks for libmath-gsl-perl. Can you send me a > | > preferred expression? > | > | No, that would just paper over the problem and wouldn't be a proper fix. > | > | There are two options to fix this issue: > | > | * Unbreak the ABI by reintroducing the removed symbols. > > I think we tried that a few gsl release ago and I don't think it was a > success. > > | * Bump the SONAME and change the package name. This will trigger a > | transition and the reverse dependencies will be rebuilt. > | > | In any case, the best idea is to talk to upstream. If removal of the > | symbols was intentional, please ask them to bump the SONAME. > > It is AFAICR the opposite: upstream *did* the change years ago, we decided to > paper over but at some point that becomes too much. Upstream is, in my book, > the best judge of their code, and if they deprecated / changed something > years ago then client packages need to (eventually) adapt. gsl 2.7 was released in June 2021. So the removal of this symbol is recent. I see no patches that would have kept that symbol around for longer than it was needed. In fact, diffing 2.6 and 2.7 suggests that gsl_linalg_QR_TR_decomp was simply renamed to gsl_linalg_QR_UR_decmp. So I'm afraid I am unable to follow your reasoning. This is pretty clear case of upstream forgetting to bump the SONAME. > If the Perl package needs a (deprecated in the library) function and cannot > change its code, maybe it can stub it locally? libmath-gsl-perl will eventually need to be fixed. Still, if gsl removes a symbol from its public ABI, it needs to bump its SONAME. That's why we have them and even encode it in package names. Cheers > > Dirk > > > | Cheers > | > | > > | > | I've also filed the separate bug #993323 about libmath-gsl-perl failing > to > | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. > | > > | > Right. > | > > | > Dirk > | > > | > | -- > | > | Niko Tyni nt...@debian.org > | > > | > -- > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | > | -- > | Sebastian Ramacher > | [DELETED ATTACHMENT signature.asc, application/pgp-signature] > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Hi Sebastian, On 14 October 2021 at 22:46, Sebastian Ramacher wrote: | Hi Dirk | | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote: | > | > On 30 August 2021 at 23:42, Niko Tyni wrote: | > | Package: libgsl25 | > | Version: 2.7+dfsg-2 | > | Control: affects -1 libmath-gsl-perl | > | Severity: serious | > | | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: | > | | > |not ok 7 - use Math::GSL::Matrix; | > | | > |# Failed test 'use Math::GSL::Matrix;' | > |# at t/00-load.t line 14. | > |# Tried to use 'Math::GSL::Matrix'. | > |# Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. | > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. | > |# Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > |# BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. | > |# Compilation failed in require at t/00-load.t line 14. | > |# BEGIN failed--compilation aborted at t/00-load.t line 14. | > |ok 8 - use Math::GSL::Poly; | > |not ok 9 - use Math::GSL::MatrixComplex; | > | | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from | > | entering testing because of this regression in libmath-gsl-perl_0.42-1. | > | | > | Looks like upstream Math-GSL-0.43 probably no longer references this | > | symbol, but it's not in Debian yet and I haven't built and verified that. | > | | > | Clearly at least something must be done on the libgsl side. Not sure if | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) | > | > I am not fully sure what they are doing. They do increment values sometimes, | > sometimes they keep them. I mostly just followed along. | > | > We also for a time tried to accomodate lagging Debian packages. I do not | > think that that winnable strategy long term. | > | > I could add a versioned breaks for libmath-gsl-perl. Can you send me a | > preferred expression? | | No, that would just paper over the problem and wouldn't be a proper fix. | | There are two options to fix this issue: | | * Unbreak the ABI by reintroducing the removed symbols. I think we tried that a few gsl release ago and I don't think it was a success. | * Bump the SONAME and change the package name. This will trigger a | transition and the reverse dependencies will be rebuilt. | | In any case, the best idea is to talk to upstream. If removal of the | symbols was intentional, please ask them to bump the SONAME. It is AFAICR the opposite: upstream *did* the change years ago, we decided to paper over but at some point that becomes too much. Upstream is, in my book, the best judge of their code, and if they deprecated / changed something years ago then client packages need to (eventually) adapt. If the Perl package needs a (deprecated in the library) function and cannot change its code, maybe it can stub it locally? Dirk | Cheers | | > | > | I've also filed the separate bug #993323 about libmath-gsl-perl failing to | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. | > | > Right. | > | > Dirk | > | > | -- | > | Niko Tyni nt...@debian.org | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Hi Dirk On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote: > > On 30 August 2021 at 23:42, Niko Tyni wrote: > | Package: libgsl25 > | Version: 2.7+dfsg-2 > | Control: affects -1 libmath-gsl-perl > | Severity: serious > | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest > regressions: > | > |not ok 7 - use Math::GSL::Matrix; > | > |# Failed test 'use Math::GSL::Matrix;' > |# at t/00-load.t line 14. > |# Tried to use 'Math::GSL::Matrix'. > |# Error: Can't load > '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for > module Math::GSL::Linalg: > /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: > undefined symbol: gsl_linalg_QR_TR_decomp at > /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. > |# Compilation failed in require at > /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. > |# BEGIN failed--compilation aborted at > /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. > |# Compilation failed in require at t/00-load.t line 14. > |# BEGIN failed--compilation aborted at t/00-load.t line 14. > |ok 8 - use Math::GSL::Poly; > |not ok 9 - use Math::GSL::MatrixComplex; > | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from > | entering testing because of this regression in libmath-gsl-perl_0.42-1. > | > | Looks like upstream Math-GSL-0.43 probably no longer references this > | symbol, but it's not in Debian yet and I haven't built and verified that. > | > | Clearly at least something must be done on the libgsl side. Not sure if > | it needs to restore the symbol or bump its SONAME, or if just a Breaks > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) > > I am not fully sure what they are doing. They do increment values sometimes, > sometimes they keep them. I mostly just followed along. > > We also for a time tried to accomodate lagging Debian packages. I do not > think that that winnable strategy long term. > > I could add a versioned breaks for libmath-gsl-perl. Can you send me a > preferred expression? No, that would just paper over the problem and wouldn't be a proper fix. There are two options to fix this issue: * Unbreak the ABI by reintroducing the removed symbols. * Bump the SONAME and change the package name. This will trigger a transition and the reverse dependencies will be rebuilt. In any case, the best idea is to talk to upstream. If removal of the symbols was intentional, please ask them to bump the SONAME. Cheers > > | I've also filed the separate bug #993323 about libmath-gsl-perl failing to > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. > > Right. > > Dirk > > | -- > | Niko Tyni nt...@debian.org > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
On 30 August 2021 at 23:42, Niko Tyni wrote: | Package: libgsl25 | Version: 2.7+dfsg-2 | Control: affects -1 libmath-gsl-perl | Severity: serious | | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: | |not ok 7 - use Math::GSL::Matrix; | |# Failed test 'use Math::GSL::Matrix;' |# at t/00-load.t line 14. |# Tried to use 'Math::GSL::Matrix'. |# Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. |# Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. |# BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. |# Compilation failed in require at t/00-load.t line 14. |# BEGIN failed--compilation aborted at t/00-load.t line 14. |ok 8 - use Math::GSL::Poly; |not ok 9 - use Math::GSL::MatrixComplex; | | It seems that the 2.7 upload broke the ABI of libgsl25 by removing | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from | entering testing because of this regression in libmath-gsl-perl_0.42-1. | | Looks like upstream Math-GSL-0.43 probably no longer references this | symbol, but it's not in Debian yet and I haven't built and verified that. | | Clearly at least something must be done on the libgsl side. Not sure if | it needs to restore the symbol or bump its SONAME, or if just a Breaks | on older libmath-gsl-perl versions is enough. (See policy 8.6.2) I am not fully sure what they are doing. They do increment values sometimes, sometimes they keep them. I mostly just followed along. We also for a time tried to accomodate lagging Debian packages. I do not think that that winnable strategy long term. I could add a versioned breaks for libmath-gsl-perl. Can you send me a preferred expression? | I've also filed the separate bug #993323 about libmath-gsl-perl failing to | build with GSL 2.7. That should be fixed just by upgrading it to 0.43. Right. Dirk | -- | Niko Tyni nt...@debian.org -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Package: libgsl25 Version: 2.7+dfsg-2 Control: affects -1 libmath-gsl-perl Severity: serious gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: not ok 7 - use Math::GSL::Matrix; # Failed test 'use Math::GSL::Matrix;' # at t/00-load.t line 14. # Tried to use 'Math::GSL::Matrix'. # Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. # � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. # Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. # BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. # Compilation failed in require at t/00-load.t line 14. # BEGIN failed--compilation aborted at t/00-load.t line 14. ok 8 - use Math::GSL::Poly; not ok 9 - use Math::GSL::MatrixComplex; It seems that the 2.7 upload broke the ABI of libgsl25 by removing the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from entering testing because of this regression in libmath-gsl-perl_0.42-1. Looks like upstream Math-GSL-0.43 probably no longer references this symbol, but it's not in Debian yet and I haven't built and verified that. Clearly at least something must be done on the libgsl side. Not sure if it needs to restore the symbol or bump its SONAME, or if just a Breaks on older libmath-gsl-perl versions is enough. (See policy 8.6.2) I've also filed the separate bug #993323 about libmath-gsl-perl failing to build with GSL 2.7. That should be fixed just by upgrading it to 0.43. -- Niko Tyni nt...@debian.org
