#30412 closed enhancement (fixed)

Upgrade gf2x to 1.3

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-9.2
Component: packages: standard Keywords:
Cc: slelievre, dimpase, zimmerma Merged in:
Authors: Thierry Monteil Reviewers: Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: d3772f6 (Commits, GitHub, GitLab) Commit: d3772f64daaaac38db5ef84d1f2bd3eef2ba2209
Dependencies: Stopgaps:

Status badges

Description (last modified by tmonteil)

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

Change History (22)

comment:1 Changed 23 months ago by tmonteil

  • Branch set to u/tmonteil/upgrade_gf2x_to_1_3

comment:2 Changed 23 months ago by tmonteil

  • Authors set to Thierry Monteil
  • Commit set to 3c9c8f20e134aaa385b444aacfe3e32bbeb8eb27
  • Status changed from new to needs_review

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

comment:3 Changed 23 months ago by mkoeppe

Can't run autotools in spkg-install.

comment:4 Changed 23 months ago by tmonteil

If i 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 ?

Last edited 23 months ago by tmonteil (previous) (diff)

comment:5 Changed 23 months ago by dimpase

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

comment:6 Changed 23 months ago by 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.

comment:7 follow-up: Changed 23 months ago by 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 ?

comment:8 in reply to: ↑ 7 ; follow-up: Changed 23 months ago by 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.

comment:9 in reply to: ↑ 8 Changed 23 months ago by 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.

Last edited 23 months ago by tmonteil (previous) (diff)

comment:10 Changed 23 months ago by tmonteil

  • Cc zimmerma added

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.

comment:11 follow-up: Changed 23 months ago by 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)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 22 months ago by 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?

comment:13 in reply to: ↑ 12 ; follow-up: Changed 22 months ago by 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.

comment:14 in reply to: ↑ 13 Changed 22 months ago by 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

comment:15 Changed 22 months ago by git

  • Commit changed from 3c9c8f20e134aaa385b444aacfe3e32bbeb8eb27 to cd5d292893604193ec03e67a14cfb11f8024da95

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

comment:16 Changed 22 months ago by tmonteil

  • Description modified (diff)

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

comment:17 Changed 22 months ago by dimpase

please update upstream_url: to point to the correct tarball

comment:18 Changed 22 months ago by slelievre

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

comment:19 Changed 22 months ago by git

  • Commit changed from cd5d292893604193ec03e67a14cfb11f8024da95 to d3772f64daaaac38db5ef84d1f2bd3eef2ba2209

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

d3772f6#30412 : link to updated upstream tarball location

comment:20 Changed 22 months ago by tmonteil

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

comment:21 Changed 22 months ago by dimpase

  • Reviewers set to Dima Pasechnik
  • Status changed from needs_review to positive_review

lgtm

comment:22 Changed 22 months ago by vbraun

  • Branch changed from u/tmonteil/upgrade_gf2x_to_1_3 to d3772f64daaaac38db5ef84d1f2bd3eef2ba2209
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.