Upgrade gf2x to 1.3

[mkoeppe]

Upstream autotoolized tarball : ​https://prod-gitlab.inria.fr/gf2x/gf2x/uploads/c46b1047ba841c20d1225ae73ad6e4cd/gf2x-1.3.0.tar.gz

Warning: do not use https://gitlab.inria.fr/gf2x/gf2x/-/archive/gf2x-1.3.0/gf2x-gf2x-1.3.0.tar.gz

[tmonteil]

Since gf2x-1.3.0 does not provide a configure script anymore (only configure.ac) i called autotools (and removed touching files that was related to some patch that does not exist anymore). Tell me if it is the correct way to do.

Self-tests work well for me.

---

New commits:

​2e4d97c	#30412 : remove old patch
​3d9b3bb	#30412 : update package version
​3c9c8f2	#30412 : gf2x does not provide a configure script anymore

[mkoeppe]

Can't run autotools in spkg-install.

[tmonteil]

If o do not add those lines, i got :

[gf2x-1.3.0] /opt/sagemath/sage-source/build/bin/sage-dist-helpers: line 165: ./configure: No such file or directory

So, what is the good way ?

[dimpase]

one needs to prepare a tarball (or a patch) with all the stuff produced by autoreconf -ivf or something like this.

[mkoeppe]

That's right. See ​https://doc.sagemath.org/html/en/developer/packaging.html#when-to-patch-when-to-repackage-when-to-autoconfiscate -- it falls in the case as "If you have to make changes to configure.ac or other source files of the autotools build system..."

It's an unfortunate trend that upstream maintainers don't prepare actual release tarballs any more...

After the autoreconf as suggested by Dima, run ./configure && make distcheck.

Put these instructions into an spkg-src script. The tarball can be put as an attachment on the ticket.

[dimpase]

I'll try to ping gf2x people on this - but first one needs to get an account on the INRIA GitLab server (I just asked for one).

By the way, did you check that none of the tarballs/zipfiles they offer contains ./configure ?

[tmonteil]

Replying to dimpase:

I'll try to ping gf2x people on this - but first one needs to get an account on the INRIA GitLab server (I just asked for one).

I am about to do the same (by direct email). For me, they forgot to produce the file since the README still speaks about running ./configure.

By the way, did you check that none of the tarballs/zipfiles they offer contains ./configure ?

No. I will do that in case.

[tmonteil]

Replying to tmonteil:

Replying to dimpase:

By the way, did you check that none of the tarballs/zipfiles they offer contains ./configure ?

No. I will do that in case.

None of the archives contain a configure script.

[tmonteil]

I sent an email to Emmanuel Thomé and Paul Zimmermann (also Cc-ed on the ticket). I would prefer to ship an upstream traball than an ad-hoc one.

[thome]

thanks for the heads up.

yes of course you're right.

when ditching gforge in favor of gitlab a few weeks ago, I accidentally forgot the implication that the tarballs that are attached to git tags no longer contain the autotools-generated configure scripts.

I'll try to fix that (and first, find out what is "the right way" to do it).

As regards the sponsorship wall on the inria gitlab account, this has recently been forced on us, and I have only limited hope that we can do something about it. I'm not at all confident that I have the right to create "normal" invitee accounts :-(. All I can do is hope that the sponsorship maze that they have invented is at least possible to work out if you have the will to try (and as for me, I'm 100% fine with ticking yes for anyone who wants to contribute to issue trackers)

[dimpase]

Replying to thome:

thanks for the heads up.

yes of course you're right.

when ditching gforge in favor of gitlab a few weeks ago, I accidentally forgot the implication that the tarballs that are attached to git tags no longer contain the autotools-generated configure scripts.

I'll try to fix that (and first, find out what is "the right way" to do it).

unlike GitHub, gitlab does not seem to allow attaching binary blobs to releases, only links can be added. Thus you can create a tarball and post it somewhere. E.g. clone the gitlab repo to a public GitHub, and post the tarball there in a release. Then you could make a link to it in GitLab. Or just put it somewhere else on the web.

As regards the sponsorship wall on the inria gitlab account, this has recently been forced on us, and I have only limited hope that we can do something about it. I'm not at all confident that I have the right to create "normal" invitee accounts :-(. All I can do is hope that the sponsorship maze that they have invented is at least possible to work out if you have the will to try (and as for me, I'm 100% fine with ticking yes for anyone who wants to contribute to issue trackers)

This is ludicrous (good luck explaining to your bosses that it goes against the whole concept of open source...). Why couldn't you host a de facto main repo somewhere that allows the public to comment, provide patches/pull requests, etc?

[thome]

Replying to dimpase:

unlike GitHub, gitlab does not seem to allow attaching binary blobs to releases, only links can be added. Thus you can create a tarball and post it somewhere. E.g. clone the gitlab repo to a public GitHub, and post the tarball there in a release. Then you could make a link to it in GitLab. Or just put it somewhere else on the web.

As a matter of fact, you can add file attachments to the release notes. While this is a manual process that has some some obvious shortcomings, it will do for the time being. I searched a bit for a process that would ship a "make dist"-generated tarball as part of gitlab's ci/cd pipelines, but that does not seem to be possible as of now. Maybe in the future.

For the time being, I did just that, and attached tar.gz for the existing releases (exactly the same tarballs as the ones that used to exist on gforge).

I'm not entirely satisfied, and at this point the url to download these files is too long. Hopefully I'll figure out a way to do that better. But the tar.gz files themselves won't change.

[saraedum]

Replying to thome:

I'm not entirely satisfied, and at this point the url to download these files is too long. Hopefully I'll figure out a way to do that better. But the tar.gz files themselves won't change.

Not sure if that's what you are looking for but if you create these tar.gz files during one of the GitLab CI steps and treat them as build artifacts, they automatically get a reasonable public URL. Here's for a example a log file that is created during the build-from-clean step of the GitLab CI that SageMath is using:

​https://gitlab.com/sagemath/sage/builds/artifacts/9.2.beta3/file/gitlab-build-docker.log?job=build-from-clean

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​a0049e3	#30412 : new upstream tarball that ships configure script
​cd5d292	#30412 : do not run autotools in spkg-install

[tmonteil]

Thanks for providing an antotoolized tarball. I updated the branch (needs review).

[dimpase]

please update upstream_url: to point to the correct tarball

[slelievre]

Note: the url starts with prod-gitlab but starting with the simpler gitlab without prod- seems to work too.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d3772f6

#30412 : link to updated upstream tarball location

[tmonteil]

Done, i was thinking the generic URL is useful when updating for next release.

[dimpase]

lgtm