Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28

[Dirk Eddelbuettel]

Package: release.debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: transition

GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
experimental was has now cleared NEW.

I checked my email folder, and the last time this happened (gsl 2.7, early
2021) we attempted an automatic transition but some things got in the way it
seems. Help from Graham (CC'ed) was invaluable then,

I am easy either way: a formal or automatic transition works for me, so
please advise as to what you preferred course of action is. The package has a
fair number of reverse dependencies but rebuilds "should" work cleanly.

Tentative ben file below.

-----------------------------------------------------------------------------
title = "gsl 2.8 transition";
is_affected = .depends ~ /libgsl-dev/;
is_good = .depends ~ "libgsl28";
is_bad = .depends ~ "libgsl27";
-----------------------------------------------------------------------------

Let me know if I can help otherwise.

Cheers, Dirk

[Sebastian Ramacher]

Control: tags -1 moreinfo

Post by Dirk Eddelbuettel
Package: release.debian.org
Severity: normal
Usertags: transition
GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
experimental was has now cleared NEW.
I checked my email folder, and the last time this happened (gsl 2.7, early
2021) we attempted an automatic transition but some things got in the way it
seems. Help from Graham (CC'ed) was invaluable then,
I am easy either way: a formal or automatic transition works for me, so
please advise as to what you preferred course of action is. The package has a
fair number of reverse dependencies but rebuilds "should" work cleanly.

Did you perform test builds of the reverse dependencies? If so, have
bugs been filed for those failing to build?

Cheers

[Dirk Eddelbuettel]

On 21 June 2024 at 10:43, Sebastian Ramacher wrote:
| Control: tags -1 moreinfo
|
| On 2024-05-27 12:01:45 -0500, Dirk Eddelbuettel wrote:
| >
| > Package: release.debian.org
| > Severity: normal
| > User: ***@packages.debian.org
| > Usertags: transition
| >
| > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| > experimental was has now cleared NEW.
| >
| > I checked my email folder, and the last time this happened (gsl 2.7, early
| > 2021) we attempted an automatic transition but some things got in the way it
| > seems. Help from Graham (CC'ed) was invaluable then,
| >
| > I am easy either way: a formal or automatic transition works for me, so
| > please advise as to what you preferred course of action is. The package has a
| > fair number of reverse dependencies but rebuilds "should" work cleanly.
|
| Did you perform test builds of the reverse dependencies?

Mo, how wow I trigger this?

| If so, have bugs been filed for those failing to build?

See above.

Dirk

|
| Cheers
| --
| Sebastian Ramacher

[Dirk Eddelbuettel]

On 21 June 2024 at 05:34, Dirk Eddelbuettel wrote:
|
| On 21 June 2024 at 10:43, Sebastian Ramacher wrote:
| | Control: tags -1 moreinfo
| |
| | On 2024-05-27 12:01:45 -0500, Dirk Eddelbuettel wrote:
| | >
| | > Package: release.debian.org
| | > Severity: normal
| | > User: ***@packages.debian.org
| | > Usertags: transition
| | >
| | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| | > experimental was has now cleared NEW.
| | >
| | > I checked my email folder, and the last time this happened (gsl 2.7, early
| | > 2021) we attempted an automatic transition but some things got in the way it
| | > seems. Help from Graham (CC'ed) was invaluable then,
| | >
| | > I am easy either way: a formal or automatic transition works for me, so
| | > please advise as to what you preferred course of action is. The package has a
| | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| |
| | Did you perform test builds of the reverse dependencies?
|
| Mo, how wow I trigger this?

Ok, now with more coffee and after an early morning bike ride:

"No, how would I trigger this?" Happy to help but will need a hint.

Dirk

| | If so, have bugs been filed for those failing to build?
|
| See above.
|
| Dirk
|
| |
| | Cheers
| | --
| | Sebastian Ramacher
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | ***@debian.org

[Sebastian Ramacher]

Post by Dirk Eddelbuettel
|
| | Control: tags -1 moreinfo
| |
| | >
| | > Package: release.debian.org
| | > Severity: normal
| | > Usertags: transition
| | >
| | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| | > experimental was has now cleared NEW.
| | >
| | > I checked my email folder, and the last time this happened (gsl 2.7, early
| | > 2021) we attempted an automatic transition but some things got in the way it
| | > seems. Help from Graham (CC'ed) was invaluable then,
| | >
| | > I am easy either way: a formal or automatic transition works for me, so
| | > please advise as to what you preferred course of action is. The package has a
| | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| |
| | Did you perform test builds of the reverse dependencies?
|
| Mo, how wow I trigger this?
"No, how would I trigger this?" Happy to help but will need a hint.

https://wiki.debian.org/MassRebuilds has a few pointers, but
essentially one of the following:

* You do them yourself with a tool like ratt or others.
* Contact Lucas do to it for you on AWS.
* http://debomatic-amd64.debian.net/
* https://debusine.debian.net/ - but not sure if it is ready to do run
the test builds.

Cheers

[Dirk Eddelbuettel]

Salut Lucas,

On 23 June 2024 at 13:09, Sebastian Ramacher wrote:
| On 2024-06-21 09:51:39 -0500, Dirk Eddelbuettel wrote:
| >
| > On 21 June 2024 at 05:34, Dirk Eddelbuettel wrote:
| > |
| > | On 21 June 2024 at 10:43, Sebastian Ramacher wrote:
| > | | Control: tags -1 moreinfo
| > | |
| > | | On 2024-05-27 12:01:45 -0500, Dirk Eddelbuettel wrote:
| > | | >
| > | | > Package: release.debian.org
| > | | > Severity: normal
| > | | > User: ***@packages.debian.org
| > | | > Usertags: transition
| > | | >
| > | | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| > | | > experimental was has now cleared NEW.
| > | | >
| > | | > I checked my email folder, and the last time this happened (gsl 2.7, early
| > | | > 2021) we attempted an automatic transition but some things got in the way it
| > | | > seems. Help from Graham (CC'ed) was invaluable then,
| > | | >
| > | | > I am easy either way: a formal or automatic transition works for me, so
| > | | > please advise as to what you preferred course of action is. The package has a
| > | | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| > | |
| > | | Did you perform test builds of the reverse dependencies?
| > |
| > | Mo, how wow I trigger this?
| >
| > Ok, now with more coffee and after an early morning bike ride:
| >
| > "No, how would I trigger this?" Happy to help but will need a hint.
|
| https://wiki.debian.org/MassRebuilds has a few pointers, but
| essentially one of the following:
|
| * You do them yourself with a tool like ratt or others.
| * Contact Lucas do to it for you on AWS.

Could I ask you for a favour and bulk test with this GSL 2.8 transition?

Amicalment, Dirk (who was out traveling for two weeks so this fell a little to the side)


| * http://debomatic-amd64.debian.net/
| * https://debusine.debian.net/ - but not sure if it is ready to do run
| the test builds.



|
| Cheers
| --
| Sebastian Ramacher

[Lucas Nussbaum]

Post by Dirk Eddelbuettel
Salut Lucas,
| >
| > |
| > | | Control: tags -1 moreinfo
| > | |
| > | | >
| > | | > Package: release.debian.org
| > | | > Severity: normal
| > | | > Usertags: transition
| > | | >
| > | | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| > | | > experimental was has now cleared NEW.
| > | | >
| > | | > I checked my email folder, and the last time this happened (gsl 2.7, early
| > | | > 2021) we attempted an automatic transition but some things got in the way it
| > | | > seems. Help from Graham (CC'ed) was invaluable then,
| > | | >
| > | | > I am easy either way: a formal or automatic transition works for me, so
| > | | > please advise as to what you preferred course of action is. The package has a
| > | | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| > | |
| > | | Did you perform test builds of the reverse dependencies?
| > |
| > | Mo, how wow I trigger this?
| >
| >
| > "No, how would I trigger this?" Happy to help but will need a hint.
|
| https://wiki.debian.org/MassRebuilds has a few pointers, but
|
| * You do them yourself with a tool like ratt or others.
| * Contact Lucas do to it for you on AWS.
Could I ask you for a favour and bulk test with this GSL 2.8 transition?
Amicalment, Dirk (who was out traveling for two weeks so this fell a little to the side)

Hi Dirk,

Since we are only talking about approximately 294 source packages to
rebuild, isn't that something that you could do on your own machine?

Typically with sbuild and a setup-script that does:
#!/bin/bash
set -e -x
echo deb http://127.0.0.1:12990/debian experimental main > /etc/apt/sources.list.d/experimental.list
cat <<-EOF > /etc/apt/preferences.d/pin
Package: src:gsl
Pin: release o=Debian,a=experimental
Pin-Priority: 999
EOF
apt-get update
apt-get -y dist-upgrade

Best,

Lucas

[Dirk Eddelbuettel]

On 11 July 2024 at 17:37, Lucas Nussbaum wrote:
| On 11/07/24 at 07:00 -0500, Dirk Eddelbuettel wrote:
| >
| > Salut Lucas,
| >
| > On 23 June 2024 at 13:09, Sebastian Ramacher wrote:
| > | On 2024-06-21 09:51:39 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > On 21 June 2024 at 05:34, Dirk Eddelbuettel wrote:
| > | > |
| > | > | On 21 June 2024 at 10:43, Sebastian Ramacher wrote:
| > | > | | Control: tags -1 moreinfo
| > | > | |
| > | > | | On 2024-05-27 12:01:45 -0500, Dirk Eddelbuettel wrote:
| > | > | | >
| > | > | | > Package: release.debian.org
| > | > | | > Severity: normal
| > | > | | > User: ***@packages.debian.org
| > | > | | > Usertags: transition
| > | > | | >
| > | > | | > GNU GSL 2.8 was released a few days ago, and I uploaded a new version to
| > | > | | > experimental was has now cleared NEW.
| > | > | | >
| > | > | | > I checked my email folder, and the last time this happened (gsl 2.7, early
| > | > | | > 2021) we attempted an automatic transition but some things got in the way it
| > | > | | > seems. Help from Graham (CC'ed) was invaluable then,
| > | > | | >
| > | > | | > I am easy either way: a formal or automatic transition works for me, so
| > | > | | > please advise as to what you preferred course of action is. The package has a
| > | > | | > fair number of reverse dependencies but rebuilds "should" work cleanly.
| > | > | |
| > | > | | Did you perform test builds of the reverse dependencies?
| > | > |
| > | > | Mo, how wow I trigger this?
| > | >
| > | > Ok, now with more coffee and after an early morning bike ride:
| > | >
| > | > "No, how would I trigger this?" Happy to help but will need a hint.
| > |
| > | https://wiki.debian.org/MassRebuilds has a few pointers, but
| > | essentially one of the following:
| > |
| > | * You do them yourself with a tool like ratt or others.
| > | * Contact Lucas do to it for you on AWS.
| >
| > Could I ask you for a favour and bulk test with this GSL 2.8 transition?
| >
| > Amicalment, Dirk (who was out traveling for two weeks so this fell a little to the side)
|
| Hi Dirk,
|
| Since we are only talking about approximately 294 source packages to
| rebuild, isn't that something that you could do on your own machine?
|
| Typically with sbuild and a setup-script that does:
| #!/bin/bash
| set -e -x
| echo deb http://127.0.0.1:12990/debian experimental main > /etc/apt/sources.list.d/experimental.list
| cat <<-EOF > /etc/apt/preferences.d/pin
| Package: src:gsl
| Pin: release o=Debian,a=experimental
| Pin-Priority: 999
| EOF
| apt-get update
| apt-get -y dist-upgrade

I think I pass on that.

While I regularly run reverse dependency checks for R packages at CRAN (just
shipped another Rcpp release after testing against 2800+ packages) I feel I
won't have it in me to set this up for another (Debian this time) package.
Some dependents are non-trivial.

Maybe time I pass GSL on to someone with more appetite for this as I've been
at it since 1999.

Dirk

| Best,
|
| Lucas

[Yavor Doganov]

Post by Dirk Eddelbuettel
| Since we are only talking about approximately 294 source packages to
| rebuild, isn't that something that you could do on your own machine?
I think I pass on that.

I volunteer to do test rebuilds of the rdeps (but have in mind that my
most powerful machine is rather slow, so it'll take a while) and to
report bugs (severity: important) that are blockers to this bug
against any package that FTBFS with the new GSL version.

In case you accept my proposal, we only have to agree about the
usertag and whether I should X-Debbugs-CC you in the bug reports.
What about:

User: ***@debian.org
Usertags: gsl_2.8-transition
Tags: sid trixie ftbfs

[Dirk Eddelbuettel]

On 11 July 2024 at 19:44, Yavor Doganov wrote:
| Dirk Eddelbuettel wrote:
| > On 11 July 2024 at 17:37, Lucas Nussbaum wrote:
| > | Since we are only talking about approximately 294 source packages to
| > | rebuild, isn't that something that you could do on your own machine?
| >
| > I think I pass on that.
|
| I volunteer to do test rebuilds of the rdeps (but have in mind that my
| most powerful machine is rather slow, so it'll take a while) and to
| report bugs (severity: important) that are blockers to this bug
| against any package that FTBFS with the new GSL version.

I appreciate that! (Coincidentally, I also test for CRAN on an old and
dated and slow 1U instance I have access too. But it's a batch job so ...)

| In case you accept my proposal, we only have to agree about the
| usertag and whether I should X-Debbugs-CC you in the bug reports.
| What about:
|
| User: ***@debian.org
| Usertags: gsl_2.8-transition
| Tags: sid trixie ftbfs

Works for me!

Dirk

[Lucas Nussbaum]

Post by Dirk Eddelbuettel
| > | Since we are only talking about approximately 294 source packages to
| > | rebuild, isn't that something that you could do on your own machine?
| >
| > I think I pass on that.
|
| I volunteer to do test rebuilds of the rdeps (but have in mind that my
| most powerful machine is rather slow, so it'll take a while) and to
| report bugs (severity: important) that are blockers to this bug
| against any package that FTBFS with the new GSL version.
I appreciate that! (Coincidentally, I also test for CRAN on an old and
dated and slow 1U instance I have access too. But it's a batch job so ...)

Thanks Yavor!

If it ends up that you cannot do it, let me know and I can do it.
But the cost of starting a rebuild and analyzing the failures is quite
high in my case, so I'd rather not do it for small-scale rebuilds.

I should work on improving my tooling so that such rebuilds are less
time-consuming. I'll think about it.

Best

Lucas

[Yavor Doganov]

On Fri, 12 Jul 2024 22:58:25 +0300,

Post by Lucas Nussbaum
If it ends up that you cannot do it, let me know and I can do it.

Fortunately this was not necessary.

Here are the results of my attempt (apologies that it took me so long).
These packages have issues with the new GSL version:

cpl-plugin-xshoo #1076251 FTBFS (not in testing)
libmath-gsl-perl #1076470 not binNMUable due to a strict
libgsl-dev B-D; maintainer ready to upload a
fixed new upstream release
ruby-gsl #1076659 FTBFS (patch available)

These packages have troubles of their own and are currently not
buildable:

coot #1076203 unsatisfiable B-D (builds fine with
python3-distutils removed from B-D)
inkscape #1073348 FTBFS (compiles and links fine with the patch
available but then I hit #1050236, testsuite failure)
sagemath #1056885, #1042683 FTBFS (not in testing)

I couldn't build this package (can you do it yourself, Dirk?):

deal.ii Out of memory; g++ killed (a machine with > 4 GB needed)

[Dirk Eddelbuettel]

On 25 July 2024 at 13:41, Paul Gevers wrote:
| On 25-07-2024 13:22, Dirk Eddelbuettel wrote:
| > I have built it, but in haste and error left the source-only flag from a
| > recent upload to NEW on so I have to wait for the queue to purge before I can
| > re-upload the corrected source-only batch. Worst case I make a -3.
|
| -2 is in the archive now, you'll need a -3.

Ah yes of course of course. I forgot it would not get autorejected. Will do.

Dirk

[Dirk Eddelbuettel]

On 25 July 2024 at 10:50, Emilio Pozuelo Monfort wrote:
| Control: tags -1 confirmed
|
| On 21/07/2024 11:09, Yavor Doganov wrote:
| > On Fri, 12 Jul 2024 22:58:25 +0300,
| > Lucas Nussbaum wrote:
| >> If it ends up that you cannot do it, let me know and I can do it.
| >
| > Fortunately this was not necessary.
| >
| > Here are the results of my attempt (apologies that it took me so long).
| > These packages have issues with the new GSL version:
| >
| > cpl-plugin-xshoo #1076251 FTBFS (not in testing)
| > libmath-gsl-perl #1076470 not binNMUable due to a strict
| > libgsl-dev B-D; maintainer ready to upload a
| > fixed new upstream release
| > ruby-gsl #1076659 FTBFS (patch available)
| >
| > These packages have troubles of their own and are currently not
| > buildable:
| >
| > coot #1076203 unsatisfiable B-D (builds fine with
| > python3-distutils removed from B-D)
| > inkscape #1073348 FTBFS (compiles and links fine with the patch
| > available but then I hit #1050236, testsuite failure)
| > sagemath #1056885, #1042683 FTBFS (not in testing)
| >
| > I couldn't build this package (can you do it yourself, Dirk?):
| >
| > deal.ii Out of memory; g++ killed (a machine with > 4 GB needed)
|
| This looks like it's in a good shape. Let's go ahead with the transition.

I concur. It's a stable and slow-changing project. But big thanks to Yavor
to running the checks!

Anything we/I need to do or will this work as an auto-transition? I presume
we need a basic ben file this?

-----------------------------------------------------------------------------
title = "gsl 2.8 transition";
is_affected = .depends ~ /libgsl-dev/;
is_good = .depends ~ "libgsl28";
is_bad = .depends ~ "libgsl27";
-----------------------------------------------------------------------------

We had issues in the 2.7 transition because of a difference between the
release name and major.minors used but that should be good. gsl27 use
'so.27' and gsl28 uses 'so.28' as I just checked.


Best, Dirk

|
| Cheers,
| Emilio

[Dirk Eddelbuettel]

On 25 July 2024 at 12:56, Emilio Pozuelo Monfort wrote:
| On 25/07/2024 12:48, Dirk Eddelbuettel wrote:
| > Anything we/I need to do or will this work as an auto-transition? I presume
| > we need a basic ben file this?
| >
| > -----------------------------------------------------------------------------
| > title = "gsl 2.8 transition";
| > is_affected = .depends ~ /libgsl-dev/;
| > is_good = .depends ~ "libgsl28";
| > is_bad = .depends ~ "libgsl27";
| > -----------------------------------------------------------------------------
| >
| > We had issues in the 2.7 transition because of a difference between the
| > release name and major.minors used but that should be good. gsl27 use
| > 'so.27' and gsl28 uses 'so.28' as I just checked.
|
| We already have one: https://release.debian.org/transitions/html/auto-gsl.html

Perfect :)

| But there's no automatic transition. At least gsl needs to be uploaded to
| unstable as a source-only upload. Then we can schedule the binNMUs.

I have built it, but in haste and error left the source-only flag from a
recent upload to NEW on so I have to wait for the queue to purge before I can
re-upload the corrected source-only batch. Worst case I make a -3.

Dirk

[Sebastian Ramacher]

Now that the s390x builds found their way to the mirrors, most of the
autopkgtest regressions got fixed. The remaining autopkgtest regressions
for packages that could not be rebuilt during the transition will need a
little help to unblock the testing migration of gsl and its rdeps.

With the force-skiptest hint britney attempted the migration, but because
libgsl27 & libgsl28 are not co-installable due to their dependency on exact
versions of libgslcblas0 this failed.
gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from
testing.
ipe on i386 is a little problematic as it cannot be removed without removing
cgal and its rdeps.
Kind Regards,

This is now blocked on the recent upload of qgis.

Cheers

[Sebastian Ramacher]

Post by Sebastian Ramacher

Now that the s390x builds found their way to the mirrors, most of the
autopkgtest regressions got fixed. The remaining autopkgtest regressions
for packages that could not be rebuilt during the transition will need a
little help to unblock the testing migration of gsl and its rdeps.

With the force-skiptest hint britney attempted the migration, but because
libgsl27 & libgsl28 are not co-installable due to their dependency on exact
versions of libgslcblas0 this failed.
gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from
testing.
ipe on i386 is a little problematic as it cannot be removed without removing
cgal and its rdeps.

This is now blocked on the recent upload of qgis.

Which you can hint out of testing.

Done

Cheers

[Dirk Eddelbuettel]

On 3 August 2024 at 21:07, Sebastian Ramacher wrote:
| On 2024-08-03 20:12:12 +0200, Sebastiaan Couwenberg wrote:
| > On 8/3/24 7:56 PM, Sebastian Ramacher wrote:
| > > On 2024-07-31 09:50:40 +0200, Sebastiaan Couwenberg wrote:
| > > > On 7/30/24 5:17 AM, Sebastiaan Couwenberg wrote:
| > > > > Now that the s390x builds found their way to the mirrors, most of the
| > > > > autopkgtest regressions got fixed. The remaining autopkgtest regressions
| > > > > for packages that could not be rebuilt during the transition will need a
| > > > > little help to unblock the testing migration of gsl and its rdeps.
| > > >
| > > > With the force-skiptest hint britney attempted the migration, but because
| > > > libgsl27 & libgsl28 are not co-installable due to their dependency on exact
| > > > versions of libgslcblas0 this failed.
| > > >
| > > > gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from
| > > > testing.
| > > >
| > > > ipe on i386 is a little problematic as it cannot be removed without removing
| > > > cgal and its rdeps.
| > >
| > > This is now blocked on the recent upload of qgis.
| >
| > Which you can hint out of testing.

Thank you both for keeping the wheels greased.

Dirk

| Done
|
| Cheers
| --
| Sebastian Ramacher

[Dirk Eddelbuettel]

On 10 August 2024 at 14:51, Sebastian Ramacher wrote:
| On 2024-08-03 14:54:29 -0500, Dirk Eddelbuettel wrote:
| >
| > On 3 August 2024 at 21:07, Sebastian Ramacher wrote:
| > | On 2024-08-03 20:12:12 +0200, Sebastiaan Couwenberg wrote:
| > | > On 8/3/24 7:56 PM, Sebastian Ramacher wrote:
| > | > > On 2024-07-31 09:50:40 +0200, Sebastiaan Couwenberg wrote:
| > | > > > On 7/30/24 5:17 AM, Sebastiaan Couwenberg wrote:
| > | > > > > Now that the s390x builds found their way to the mirrors, most of the
| > | > > > > autopkgtest regressions got fixed. The remaining autopkgtest regressions
| > | > > > > for packages that could not be rebuilt during the transition will need a
| > | > > > > little help to unblock the testing migration of gsl and its rdeps.
| > | > > >
| > | > > > With the force-skiptest hint britney attempted the migration, but because
| > | > > > libgsl27 & libgsl28 are not co-installable due to their dependency on exact
| > | > > > versions of libgslcblas0 this failed.
| > | > > >
| > | > > > gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from
| > | > > > testing.
| > | > > >
| > | > > > ipe on i386 is a little problematic as it cannot be removed without removing
| > | > > > cgal and its rdeps.
| > | > >
| > | > > This is now blocked on the recent upload of qgis.
| > | >
| > | > Which you can hint out of testing.
| >
| > Thank you both for keeping the wheels greased.
|
| The old binary packages got removed from testing. Closing

Awesome -- thank you again.

Dirk

| Cheers
| --
| Sebastian Ramacher