Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
Ok please send along the patches. Sorry again for all the trouble. Do you know of some way I can check for libtool problems prior to making new releases? I think this is the 3rd time something like this has happened On 12/1/21 7:39 PM, Dirk Eddelbuettel wrote: On 1 December 2021 at 21:41, Sebastian Ramacher wrote: | Indeed, it will need a trip through NEW. So going via experimental would | be appreciated. But, once it passed NEW, you can then immediatly follow | up with the upload to unstable. I will take care of the binNMUs of the | reverse dependencies Done! And big thank you both. We should soon be in better shape with 2.7.1 as libgsl27 ! Patrick: I still have two local patches in the patches. One is one 'gsl-cblas' linkage (and I have forgotten the details, but I can probably dig them up) and a simple manual page edit. We should probably fold the manual page in, and can look into that before the next release. Dirk
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
All, I have uploaded a new GSL release (2.7.1) which I hope fixes the libtool version numbers On 11/21/21 3:27 PM, Dirk Eddelbuettel wrote: Hi Patrick, Can you please chime in (as you did in the earlier exchanges when Sebastian explained to us how to set valus triplet for libtool via configure.ac) ? On 21 November 2021 at 23:00, Sebastian Ramacher wrote: | On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote: | > | > On 8 November 2021 at 22:14, Sebastian Ramacher wrote: | > | Control: tags -1 moreinfo | > | Control: forwarded -1 https://release.debian.org/transitions/html/auto-gsl.html | > | | > | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote: | > | > | > | > Package: release.debian.org | > | > Severity: normal | > | > User: release.debian@packages.debian.org | > | > Usertags: transition | > | > | > | > GNU GSL 2.7 was release a few months ago, and we now realised (in the | > | > discussion of #993324 which also included upstream) that the upstream libtool | > | > instruction were in error by _not_ leading to a new sonumber. This was | > | > corrected in (source package) gsl upload 2.7-3 to experimental, which built | > | > well. | > | | > | What's the status of the fix upstream? Was there any progress? Otherwise | > | we're gonna repeat that with the next upstream release. | > | > Those are two distinct issues. Upstream, I think we all agreed in the thread | > also recorded in the BTS, made an omission in this release where a new soname | > was needed, but wasn't given. This happens. So now we need a new soname | > __because the ABI/API changed__. | | Yes, the ABI changed and we need a new SONAME. This would ideally be | done upstream, though. Even better would be a new release with that change. Yes or no. We could proceed with the patch based on your suggestion. That would be "lighterweight" as we would not require upstream work right now. | As far as I am aware, the bug report lacks any mail from Patrick which He did participate earlier. Some of it may have been private mail between him and myself; I'd have to check. | would currently mean that we'd have a Debian-specific SONAME. If we go | ahead with that, we will end up in on of the following cases: | | 1. Upstream bumps the SONAME as we discussed it in the bug report. | Given the changes in [1], the next release of gsl would then have a | SONAME of libgsl.so.26, but with an incompatible ABI compared to what we | would have in the archive. I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now would make it impossible to use that soname later :-/ | 2. Upstream bumps the SONAME to a version higher than 26. (That would be my stylistic preference. If the next GSL is 2.8, why not take 28? I may be unaware of other style 'customs' here.) | (3. Upstream simply ignores the issue) | | If 1. happens, we'd be unable to sync up with upstream's SONAME (there's | a good reason why we tend to avoid Debian-specific SONAMEs). | | Patrick, what are your planes? We're all ears :) Dirk | Best | Sebastian | | [1] https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07 | | > | > That has happened before, and that is why we had transitions in the past. | | | | > | > But not all previous releases had soname changes. I have maintained GSL here | > for about 20 years and I think this is about the third transition. I would | > call that defensible. | > | > The release team does of course have a broader view, and I am always keen to | > hear your thoughts. | > | > Cheers, Dirk | > | > | Cheers | > | | > | > | > | > I would like to ask for a formal transition. As we saw with failing tests in | > | > dependent packages, binNMUs will not work for all package (but possibly | > | > "most"). | > | > | > | > Tentative ben file below. | > | > | > | > - | > | > title = "gsl 2.7 transition"; | > | > is_affected = .depends ~ /libgsl-dev/; | > | > is_good = .depends ~ "libgsl26"; | > | > is_bad = .depends ~ "libgsl25"; | > | > - | > | > | > | > Let me know if I can help otherwise. | > | > | > | > Cheers, Dirk | > | > | > | > | > | > -- | > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | > | > | | > | -- | > | Sebastian Ramacher | > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature]
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
Hi all, sorry for all this trouble. I will try to make a new GSL release with the correct numbers. On 11/22/21 2:18 AM, Sebastian Ramacher wrote: On 2021-11-21 16:27:03, Dirk Eddelbuettel wrote: Hi Patrick, Can you please chime in (as you did in the earlier exchanges when Sebastian explained to us how to set valus triplet for libtool via configure.ac) ? On 21 November 2021 at 23:00, Sebastian Ramacher wrote: | On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote: | > | > On 8 November 2021 at 22:14, Sebastian Ramacher wrote: | > | Control: tags -1 moreinfo | > | Control: forwarded -1 https://release.debian.org/transitions/html/auto-gsl.html | > | | > | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote: | > | > | > | > Package: release.debian.org | > | > Severity: normal | > | > User: release.debian@packages.debian.org | > | > Usertags: transition | > | > | > | > GNU GSL 2.7 was release a few months ago, and we now realised (in the | > | > discussion of #993324 which also included upstream) that the upstream libtool | > | > instruction were in error by _not_ leading to a new sonumber. This was | > | > corrected in (source package) gsl upload 2.7-3 to experimental, which built | > | > well. | > | | > | What's the status of the fix upstream? Was there any progress? Otherwise | > | we're gonna repeat that with the next upstream release. | > | > Those are two distinct issues. Upstream, I think we all agreed in the thread | > also recorded in the BTS, made an omission in this release where a new soname | > was needed, but wasn't given. This happens. So now we need a new soname | > __because the ABI/API changed__. | | Yes, the ABI changed and we need a new SONAME. This would ideally be | done upstream, though. Even better would be a new release with that change. Yes or no. We could proceed with the patch based on your suggestion. That would be "lighterweight" as we would not require upstream work right now. | As far as I am aware, the bug report lacks any mail from Patrick which He did participate earlier. Some of it may have been private mail between him and myself; I'd have to check. I reply from Patrick isn't recored in the BTS and I also can't find one in my inbox. Cheers | would currently mean that we'd have a Debian-specific SONAME. If we go | ahead with that, we will end up in on of the following cases: | | 1. Upstream bumps the SONAME as we discussed it in the bug report. | Given the changes in [1], the next release of gsl would then have a | SONAME of libgsl.so.26, but with an incompatible ABI compared to what we | would have in the archive. I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now would make it impossible to use that soname later :-/ | 2. Upstream bumps the SONAME to a version higher than 26. (That would be my stylistic preference. If the next GSL is 2.8, why not take 28? I may be unaware of other style 'customs' here.) | (3. Upstream simply ignores the issue) | | If 1. happens, we'd be unable to sync up with upstream's SONAME (there's | a good reason why we tend to avoid Debian-specific SONAMEs). | | Patrick, what are your planes? We're all ears :) Dirk | Best | Sebastian | | [1] https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07 | | > | > That has happened before, and that is why we had transitions in the past. | | | | > | > But not all previous releases had soname changes. I have maintained GSL here | > for about 20 years and I think this is about the third transition. I would | > call that defensible. | > | > The release team does of course have a broader view, and I am always keen to | > hear your thoughts. | > | > Cheers, Dirk | > | > | Cheers | > | | > | > | > | > I would like to ask for a formal transition. As we saw with failing tests in | > | > dependent packages, binNMUs will not work for all package (but possibly | > | > "most"). | > | > | > | > Tentative ben file below. | > | > | > | > - | > | > title = "gsl 2.7 transition"; | > | > is_affected = .depends ~ /libgsl-dev/; | > | > is_good = .depends ~ "libgsl26"; | > | > is_bad = .depends ~ "libgsl25"; | > | > - | > | > | > | > Let me know if I can help otherwise. | > | > | > | > Cheers, Dirk | > | > | > | > | > | > -- | > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | > | > | | > | -- | > | Sebastian Ramacher | > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] | > | > -- | > 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
