Opened 21 months ago
Closed 21 months ago
#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: |
Description (last modified by )
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 21 months ago by
- Branch set to u/tmonteil/upgrade_gf2x_to_1_3
comment:2 Changed 21 months ago by
- Commit set to 3c9c8f20e134aaa385b444aacfe3e32bbeb8eb27
- Status changed from new to needs_review
comment:3 Changed 21 months ago by
Can't run autotools in spkg-install
.
comment:4 Changed 21 months ago by
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 ?
comment:5 Changed 21 months ago by
one needs to prepare a tarball (or a patch) with all the stuff produced by autoreconf -ivf
or something like this.
comment:6 Changed 21 months ago by
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: ↓ 8 Changed 21 months ago by
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: ↓ 9 Changed 21 months ago by
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 21 months ago by
comment:10 Changed 21 months ago by
- 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: ↓ 12 Changed 21 months ago by
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: ↓ 13 Changed 21 months ago by
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: ↓ 14 Changed 21 months ago by
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 21 months ago by
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:
comment:15 Changed 21 months ago by
- Commit changed from 3c9c8f20e134aaa385b444aacfe3e32bbeb8eb27 to cd5d292893604193ec03e67a14cfb11f8024da95
comment:16 Changed 21 months ago by
- Description modified (diff)
Thanks for providing an antotoolized tarball. I updated the branch (needs review).
comment:17 Changed 21 months ago by
please update upstream_url:
to point to the correct tarball
comment:18 Changed 21 months ago by
Note: the url starts with prod-gitlab
but starting with
the simpler gitlab
without prod-
seems to work too.
comment:19 Changed 21 months ago by
- 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 21 months ago by
Done, i was thinking the generic URL is useful when updating for next release.
comment:21 Changed 21 months ago by
- Reviewers set to Dima Pasechnik
- Status changed from needs_review to positive_review
lgtm
comment:22 Changed 21 months ago by
- Branch changed from u/tmonteil/upgrade_gf2x_to_1_3 to d3772f64daaaac38db5ef84d1f2bd3eef2ba2209
- Resolution set to fixed
- Status changed from positive_review to closed
Since
gf2x-1.3.0
does not provide aconfigure
script anymore (onlyconfigure.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:
#30412 : remove old patch
#30412 : update package version
#30412 : gf2x does not provide a configure script anymore