Upgrade: GAP 4.12
Closed this issue · 155 comments
GAP 4.12.1 fixes critical bugs in 4.12.0
GAP 4.12.0 was released in August 2022.
We should upgrade our corresponding spkgs:
- gap
- gap_packages
- libsemigroups
Previous upgrades:
Upstream: Completely fixed; Fix reported upstream
CC: @antonio-rojas @dimpase @slel @tornaria @kiwifb @collares @tscrim
Component: packages: standard
Keywords: spkg, upgrade, gap, libsemigroups
Author: Antonio Rojas, Dima Pasechnik
Reviewer: Dima Pasechnik, Antonio Rojas, Mauricio Collares, François Bissey
Issue created by migration from https://trac.sagemath.org/ticket/34391
Having upgraded downstream, here is a list of issues:
-
Build fails because a garbage collector needs to be specified via a preprocessor macro when using gap's headers. This is included in the CPPFLAGS in gap's own
sysinfo.gap, but Sage doesn't read it when building. -
Build fails due to API changes in
OpenOutputStreamandCloseOutput -
Colored prompt is on by default, which breaks the pexpect interface.
-
The
NaturalHomomorphismfunction, used ingroups.abelian_gps.abelian_group_gap, has been removed. -
The functions
IsPrimitiveandIsTransitivechanged behavior and now return false if the group does not act on the given set, breaking some tests:
File "/usr/lib/python3.10/site-packages/sage/groups/perm_gps/permgroup.py", line 4363, in sage.groups.perm_gps.permgroup.PermutationGroup_generic.is_transitive
Failed example:
G.is_transitive([1,4,5])
Expected:
True
Got:
False
**********************************************************************
File "/usr/lib/python3.10/site-packages/sage/groups/perm_gps/permgroup.py", line 4428, in sage.groups.perm_gps.permgroup.PermutationGroup_generic.is_primitive
Failed example:
G.is_primitive([1,2,3])
Expected:
True
Got:
False
-
Computation of permutation group generators has changed, breaking some tests. In particular, using
algorithm=smallernow does not make any difference in many examples. -
Several trivial test failures due to different choice of generators or minor syntax changes.
Branch: u/arojas/upgrade__gap_4_12
The branch fixes (2), (3), (4) and (7). For (5), we need to decide whether we want to follow the new behavior in GAP, or reimplement the old behavior in some other way. For (6), some tests need to be updated or removed.
New commits:
aeff992 | Adapt to API changes in OpenOutputStream and CloseOutput |
c3367b4 | Disable colored prompt as it breaks the pexpect interface |
3b63e99 | Port NaturalHomomorphism uses |
bc40764 | Fix tests with GAP 4.12 |
Commit: bc40764
Author: Antonio Rojas, ...
regarding (5), I don't think we need to reimplement, as transitive and primitive are dealing with group action on a domain, and are not defined, mathematically, for arbitrary subsets of the domain.
(perhaps we should have a deprecation, in case False is returned, printing a warning about the change in behavior)
How about (1) - should spkg-install source sysinfo.gap ?
Replying to @dimpase:
regarding (5), I don't think we need to reimplement, as
transitiveandprimitiveare dealing with group action on a domain, and are not defined, mathematically, for arbitrary subsets of the domain.How about (1) - should
spkg-installsourcesysinfo.gap?
I think that is fine for gap packages but not for downstream packages. I guess it is a stop gap, but a standard way of setting the flags should be provided. A .pc file or at least a config utility. You shouldn't have to search for settings in an obscure internal file. This is a genuine upstream defect in my opinion.
By the way, sysinfo.gap is not in the tarball, it is generated by doing make sysinfo.gap, so this should be easy to incorporate. But it has GAP_CPPFLAGS rather than CPPFLAGS, at least on an install I'm trying this.
So this looks that our build somehow manages to avoid running make sysinfo.gap.
I am seeing a bunch of segfaults on aarch64 with GAP 4.12.0 and this branch. The following patch, which copies the output string before calling GAP_Leave, seems to fix almost all of the segfaults, but not 100% of them (see NixOS/nixpkgs#192548 (comment) for more details):
diff --git a/src/sage/libs/gap/element.pxd b/src/sage/libs/gap/element.pxd
index a1bf8118d4..9a28de87ca 100644
--- a/src/sage/libs/gap/element.pxd
+++ b/src/sage/libs/gap/element.pxd
@@ -29,9 +29,9 @@ cdef GapElement_Boolean make_GapElement_Boolean(parent, Obj obj)
cdef GapElement_Function make_GapElement_Function(parent, Obj obj)
cdef GapElement_Permutation make_GapElement_Permutation(parent, Obj obj)
-cdef char *capture_stdout(Obj, Obj)
-cdef char *gap_element_str(Obj)
-cdef char *gap_element_repr(Obj)
+cdef str capture_stdout(Obj, Obj)
+cdef str gap_element_str(Obj)
+cdef str gap_element_repr(Obj)
cdef class GapElement(RingElement):
diff --git a/src/sage/libs/gap/element.pyx b/src/sage/libs/gap/element.pyx
index e2681165a2..482f74bbcf 100644
--- a/src/sage/libs/gap/element.pyx
+++ b/src/sage/libs/gap/element.pyx
@@ -120,7 +120,7 @@ cdef Obj make_gap_matrix(sage_list, gap_ring) except NULL:
return l.value
-cdef char *capture_stdout(Obj func, Obj obj):
+cdef str capture_stdout(Obj func, Obj obj):
"""
Call a single-argument GAP function ``func`` with the argument ``obj``
and return the stdout from that function call.
@@ -152,12 +152,12 @@ cdef char *capture_stdout(Obj func, Obj obj):
CALL_1ARGS(func, obj)
CloseOutput(&output)
- return CSTR_STRING(s)
+ return char_to_str(CSTR_STRING(s))
finally:
GAP_Leave()
-cdef char *gap_element_repr(Obj obj):
+cdef str gap_element_repr(Obj obj):
"""
Implement ``repr()`` of ``GapElement``s using the ``ViewObj()`` function,
which is by default closest to what you get when displaying an object in
@@ -169,7 +169,7 @@ cdef char *gap_element_repr(Obj obj):
return capture_stdout(func, obj)
-cdef char *gap_element_str(Obj obj):
+cdef str gap_element_str(Obj obj):
"""
Implement ``str()`` of ``GapElement``s using the ``Print()`` function.
@@ -761,7 +761,7 @@ cdef class GapElement(RingElement):
if self.value == NULL:
return 'NULL'
- s = char_to_str(gap_element_str(self.value))
+ s = gap_element_str(self.value)
return s.strip()
def _repr_(self):
@@ -783,7 +783,7 @@ cdef class GapElement(RingElement):
if self.value == NULL:
return 'NULL'
- s = char_to_str(gap_element_repr(self.value))
+ s = gap_element_repr(self.value)
return s.strip()
cpdef _set_compare_by_id(self):I think the other segfaults happen because gap_element_repr and gap_element_str (the two capture_stdout callers) call GAP_ValueGlobalVariable but don't use GAP_Enter/GAP_Leave.
As a proof of concept, I applied the above patch but also moved the try/GAP_Enter/finally/GAP_Leave block from capture_stdout to gap_element_repr/gap_element_str (patch), and I didn't see a single crash in two test runs (it used to happen every time).
Replying to Mauricio Collares:
I think the other segfaults happen because
gap_element_reprandgap_element_str(the twocapture_stdoutcallers) callGAP_ValueGlobalVariablebut don't useGAP_Enter/GAP_Leave.As a proof of concept, I applied the above patch but also moved the try/GAP_Enter/finally/GAP_Leave block from
capture_stdouttogap_element_repr/gap_element_str(patch), and I didn't see a single crash in two test runs (it used to happen every time).
Feel free to push your changes, I can only test on x86_64 where I haven't seen any such issue so far.
I have tested the last commmit (a6c293d) using system gap 4.12.0, on x86_64, x86_64-musl and i686 (void linux) with all long tests passing.
I don't have aarch64 to test.
this branch should bump up the version of GAP, etc
diff --git a/build/pkgs/gap/checksums.ini b/build/pkgs/gap/checksums.ini
index 066e943308..7f083710ca 100644
--- a/build/pkgs/gap/checksums.ini
+++ b/build/pkgs/gap/checksums.ini
@@ -1,5 +1,5 @@
tarball=gap-VERSION.tar.gz
-sha1=4ecdd281b8f430282fb9b12690b06e0a26abde10
-md5=85dc9e459d5b6c66fcad9f468afd3e3e
-cksum=1351843158
+sha1=b8b2d803c43dc6ea4413b5a378689a2087c3658a
+md5=6772845916c31de880792c7bb1672f81
+cksum=3760719912
upstream_url=https://github.com/gap-system/gap/releases/download/vVERSION/gap-VERSION.tar.gz
diff --git a/build/pkgs/gap/package-version.txt b/build/pkgs/gap/package-version.txt
index d782fca8f6..815588ef14 100644
--- a/build/pkgs/gap/package-version.txt
+++ b/build/pkgs/gap/package-version.txt
@@ -1 +1 @@
-4.11.1
+4.12.0We should wait for 4.12.1 which will include a fix for issue (1) and additional fixes for make install so we can switch spkg-install to use it.
meanwhile, rebased over the latest beta, and all the fixes for spkg-install needed so far.
New commits:
6f3b455 | Adapt to API changes in OpenOutputStream and CloseOutput |
31aaa12 | Disable colored prompt as it breaks the pexpect interface |
d9da790 | Port NaturalHomomorphism uses |
86a34a0 | Fix tests with GAP 4.12 |
3b8283f | Adapt test to new is_transitive and is_primitive behavior |
754b7b1 | Mark test as random. With gap 4.12 on x86_64 it is no longer 2 |
6e3e8da | Remove test that is now redundant, all seeds give the same answer |
09f4df2 | install gap 4.12.0 |
Changed branch from u/arojas/upgrade__gap_4_12 to u/dimpase/upgrade__gap_4_12
running tests on Apple M1 (aka aarch64).
I'm getting
In file included from sage/coding/codecan/codecan.c:5227:
/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/include/gap/gasman_intern.h:17:2: error: #error This file must only be included if GASMAN is used
17 | #error This file must only be included if GASMAN is used
what's the fix here?
That's precisely issue (1). Fixed upstream in gap-system/gap@276eb56
OK, one needs to patch GAP, as in https://patch-diff.githubusercontent.com/raw/gap-system/gap/pull/5077.diff
Branch pushed to git repo; I updated commit sha1. New commits:
5a0f6e9 | add GAP upstream PR 5077 |
we also need to upgrade libsemigroups, and gap_packages. I'm doing this now.
not yet done, as local/share/gap/sysinfo.gap needed a manual addition of
-I$SAGE_LOCAL/include/gap to GAC_CFLAGS.
Branch pushed to git repo; I updated commit sha1. New commits:
2e3f54b | also, fix the package names etc |
There are also failing doctests in sage/algebras/quantum_groups/quantum_group_gap.py, like this:
sage -t --warn-long 37.8 --random-seed=5244030565037623767917974460011040182 src/sage/algebras/quantum_groups/quantum_group_gap.py
**********************************************************************
File "src/sage/algebras/quantum_groups/quantum_group_gap.py", line 1812, in sage.algebras.quantum_groups.quantum_group_gap.TensorProductOfHighestWeightModules.__init__
Failed example:
TestSuite(T).run() # optional - gap_packages
Expected nothing
Got:
doctest:warning
File "/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/src/bin/sage-runtests", line 154, in <module>
err = DC.run()
...
DeprecationWarning: implementations of Modules().TensorProducts() now must define the method tensor_factors
Changed author from Antonio Rojas, ... to Antonio Rojas, Dima Pasechnik
Perhaps Travis can fix these missing methods tensor_factors in sage/algebras/quantum_groups/quantum_group_gap.py, so that there won't be a need to patch these doctests.
Work Issues: simplify spkg-install to use GAP make install to $prefix
wip on simplifying spkg-install
Attachment: s.patch.gz
with this, and gap-system/gap#5091 it mostly works (package installation is broken though) We'll wait for 4.12.1, where also needed package upgrades are done.
In case it's useful, here are the patches I had to use for gap 4.12.0 on void linux:
I think two of those are PR 5077 and PR 5091 already mentioned in this ticket. The third patch I needed to fix something in atlasrep package.
Note also that:
a. package names have changed (at least the name of the directories changed case and removed version numbers)
b. sysinfo.gap used to be installed in /usr/share/gap and now is installed in /usr/lib/gap.
Sagemath (9.7 and 9.8.beta2) is working fine with this, but note I only install the minimal set of packages that are standard in sage.
The atlasrep issue is gap-system/gap#5015 and will also be fixed in GAP 4.12.1.
Replying to Gonzalo Tornaría:
In case it's useful, here are the patches I had to use for gap 4.12.0 on void linux:
I think two of those are PR 5077 and PR 5091 already mentioned in this ticket. The third patch I needed to fix something in atlasrep package.
Note also that:
a. package names have changed (at least the name of the directories changed case and removed version numbers)
b.sysinfo.gapused to be installed in/usr/share/gapand now is installed in/usr/lib/gap.
For Sage's installed GAP, this will be $SAGE_LOCAL/lib/gap/
Sagemath (9.7 and 9.8.beta2) is working fine with this, but note I only install the minimal set of packages that are standard in sage.
Try packages which build executables and/or GAP kernel extensions (the latter need gac)
E.g. grape and crypting.
Changed branch from u/dimpase/upgrade__gap_4_12 to u/dimpase/packages/gap/4_12_1
GAP package liepring now depends on a GAP package singular, so we should be installing it ahead of liepring.
Branch pushed to git repo; I updated commit sha1. New commits:
02b6b4b | install GAP package singular - new dependency of liepring |
while more simplifications may be done on spkg-install files for gap, and gap_packages, this branch appears to work just fine.
utils and autodoc are now dependencies of atlasrep so they need to move from gap_packages to gap.
Max Horn also pointed out that radiroot is now a dependency of polenta, one of the autoloaded packages. Also, although not strictly necessary, atlasrep uses io as the preferred method for fetching files over the network (but it will fall back to running wget if that's not available).
done what's requested in comment:41 and comment:42, please review.
Replying to Antonio Rojas:
Feel free to push your changes, I can only test on x86_64 where I haven't seen any such issue so far.
I think I will submit my changes in a separate ticket, since the present update seems ready and does not make things any worse on aarch64 as far as I can tell. What is the best way to submit a ticket/change which depends on an open one and touches the same lines of code? I think I will just branch off this one and mark the ticket as a dependency.
Edit: Opened #34701, sorry for the noise!
Replying to Mauricio Collares:
What is the best way to submit a ticket/change which depends on an open one and touches the same lines of code? I think I will just branch off this one and mark the ticket as a dependency.
yes, that's how this is normally done.
Forwarding another suggestion from Max Horn (in NixOS/nixpkgs#192548 (comment)): config.h is not meant to be installed anymore. The corresponding line in spkg-install.in can just be removed, I think.
Replying to Mauricio Collares:
Forwarding another suggestion from Max Horn (in NixOS/nixpkgs#192548 (comment)):
config.his not meant to be installed anymore. The corresponding line inspkg-install.incan just be removed, I think.
This will solve itself once we switch to make install. Let's get this is as is and move that to a follow-up ticket (there are some non-trivial adjustments needed for gap-packages, and probably the GAP_ROOT variable should be rethought or removed completely)
In #34711 we will switch to using GAP's make install. Meanwhile I'm giving this a positive review.
Reviewer: Dima Pasechnik, Antonio Rojas, Mauricio Collares
I spoke too soon - tested with unclean SAGE_LOCAL :-(
With everything clean, while building gap_packages, I get
gcc -g -O2 -fPIC -MQ gen/src/crypting.o -MMD -MP -MF gen/src/crypting.d -g -O2 -Wno-implicit-function-declaration -Wno-implicit-function-declaration -o gen/src/crypting.o -I/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap/build -I/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap/src -I/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap -DUSE_GASMAN=1 -c src/crypting.c
In file included from /home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap/src/gap_all.h:51,
from /home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap/src/compiled.h:26,
from src/crypting.c:5:
/home/scratch/scratch2/dimpase/sage/sagetrac-mirror/local/share/gap/src/modules.h:19:10: fatal error: version.h: No such file or directory
19 | #include "version.h"
| ^~~~~~~~~~~
compilation terminated.
The problem is that version.h gets installed into SAGE_LOCAL/include/gap - a location unknown to crypting package makefile.
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
061b6fb | Mark test as random. With gap 4.12 on x86_64 it is no longer 2 |
a5a4423 | Remove test that is now redundant, all seeds give the same answer |
af5f91b | install gap 4.12.0 |
46ef5f8 | upgrade libsemigroup and gap_packages |
d57f502 | add GAP upstream PR 5077 |
34b03ed | also, fix the package names etc |
60ac451 | update GAP to 4.12.1 |
412fec4 | install GAP package singular - new dependency of liepring |
f3ce16d | moved install of radiroot to gap from gap_packages |
a1e6e43 | moved install of autodoc and utils to gap from gap_packages |
rebased over latest beta, 9.8.beta3
Branch pushed to git repo; I updated commit sha1. New commits:
72d57e0 | don't use SAGE_LOCAL/share/gap, switch to GAP's "make install" |
the current issue is to fix gap's spkg-check - currently broken due to a mess
in some GAP's packages we install, see
gap-packages/crypting#21 (comment)
libgap doesn't find any package
sage: from sage.tests.gap_packages import all_installed_packages
sage: all_installed_packages()
()
Changed branch from u/dimpase/packages/gap/4_12_1 to u/arojas/packages/gap/4_12_1
Ideally libgap should know where to look for its files without needing to pass the paths with -l, but apparently that's not the case (it works fine in the gap command line though, GAPInfo.RootPaths returns both paths, lib and share).
New commits:
16c2ccb | Search for files in both lib/gap and share/gap |
There's still one test failure
sage -t --long --random-seed=259290265121646386777269003923470404522 src/sage/tests/gap_packages.py
**********************************************************************
File "src/sage/tests/gap_packages.py", line 8, in sage.tests.gap_packages
Failed example:
test_packages(pkgs, only_failures=True) # optional - gap_packages
Exception raised:
Traceback (most recent call last):
File "/home/antonio/Software/sage/sage-gap/src/sage/doctest/forker.py", line 695, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/home/antonio/Software/sage/sage-gap/src/sage/doctest/forker.py", line 1093, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.tests.gap_packages[2]>", line 1, in <module>
test_packages(pkgs, only_failures=True) # optional - gap_packages
File "/home/antonio/Software/sage/sage-gap/src/sage/tests/gap_packages.py", line 71, in test_packages
output = libgap.LoadPackage(pkg)
File "sage/libs/gap/element.pyx", line 2524, in sage.libs.gap.element.GapElement_Function.__call__
sig_on()
sage.libs.gap.util.GAPError: Error, no method found! Error, no 1st choice method found for `Filename' on 2 arguments
The 1st argument is 'fail' which might point to an earlier problem
Error, was not in any namespace
Error, was not in any namespace
**********************************************************************
It happens when libgap tries to load the packagemanager package
sage: libgap.LoadPackage("packagemanager")
---------------------------------------------------------------------------
GAPError Traceback (most recent call last)
Input In [1], in <cell line: 1>()
----> 1 libgap.LoadPackage("packagemanager")
File ~/Software/sage/sage-gap/src/sage/libs/gap/element.pyx:2524, in sage.libs.gap.element.GapElement_Function.__call__()
2522 try:
2523 sig_GAP_Enter()
-> 2524 sig_on()
2525 if n == 0:
2526 result = CALL_0ARGS(self.value)
GAPError: Error, no method found! Error, no 1st choice method found for `Filename' on 2 arguments
The 1st argument is 'fail' which might point to an earlier problem
Error, was not in any namespace
Error, was not in any namespace
It (seems to) work fine the second time
sage: libgap.LoadPackage("packagemanager")
true
Do you need to look for packages in share/gap? There should not be any.
That's why I doubt your line from 16c2ccb:
s = str_to_bytes(sage.env.GAP_LIB_DIR + ";" + sage.env.GAP_SHARE_DIR, FS_ENCODING, "surrogateescape")
Replying to Dima Pasechnik:
Do you need to look for packages in
share/gap? There should not be any.
That's why I doubt your line from16c2ccb:
That is not only for packages. Without this, libgap can't find the lib/init.g file which is installed under share/gap and just crashes on initialization.
Replying to Antonio Rojas:
It happens when libgap tries to load the
packagemanagerpackage
Looks like packagemanager expects a lib/gap/bin dir to exist, which is not created by make install
https://github.com/gap-packages/PackageManager/blob/master/gap/PackageManager.gd#L294
Simply creating an empty bin subdir fixes the test.
Branch pushed to git repo; I updated commit sha1. New commits:
3abfbd0 | Create lib/gap/bin on install |
Something is fishy with PackageManager in another way, too: gap-packages/PackageManager#106
Replying to @sagetrac-git:
Branch pushed to git repo; I updated commit sha1. New commits:
3abfbd0 | Create lib/gap/bin on install |
but we don't need lib/gap/bin, it's an upstream bug.
Replying to Dima Pasechnik:
Replying to @sagetrac-git:
Branch pushed to git repo; I updated commit sha1. New commits:
3abfbd0 Create lib/gap/bin on installbut we don't need lib/gap/bin, it's an upstream bug.
It breaks a test. We either need to work around this, or we need to stop testing loading the package.
Replying to Antonio Rojas:
Replying to Dima Pasechnik:
Do you need to look for packages in
share/gap? There should not be any.
That's why I doubt your line from16c2ccb:That is not only for packages. Without this,
libgapcan't find thelib/init.gfile which is installed undershare/gapand just crashes on initialization.
I feel like it is an oversight upstream. They should move that code under lib/gap too to be consistent. It is probably just a matter of fixing the install target in the makefile.
Replying to François Bissey:
I feel like it is an oversight upstream. They should move that code under lib/gap too to be consistent. It is probably just a matter of fixing the install target in the makefile.
Technically it is the correct place. Arch-independent files belong in share.
Replying to Antonio Rojas:
Replying to François Bissey:
I feel like it is an oversight upstream. They should move that code under lib/gap too to be consistent. It is probably just a matter of fixing the install target in the makefile.
Technically it is the correct place. Arch-independent files belong in
share.
I cannot argue with that. I know I had complaint that in previous gap version, gap packages installed binaries and libraries under share which is not right of course. But gap packages are a mixed bag. Do we need to sort them out or to make sure only the binary bits get shipped under lib? It may become complicated very fast. I feel like the right decision is just to put everything under lib. Python does it, that's a big example to follow.
Actually, the bin/gap script created by make install contains both paths
https://github.com/gap-system/gap/blob/v4.12.1/Makefile.rules#L582
My commit is just replicating that for the libgap call in sage.
Do we need to sort them out or to make sure only the binary bits get shipped under
lib? It may become complicated very fast. I feel like the right decision is just to put everything underlib.
This is something for upstream to figure out when they integrate package installation in make install, which I believe is planned. Until then every distro will manually install packages where they choose to, so we need to search both paths.
Replying to Antonio Rojas:
Actually, the
bin/gapscript created bymake installcontains both pathshttps://github.com/gap-system/gap/blob/v4.12.1/Makefile.rules#L582
That, I noticed when I packaged 4.12.0. I only thought of it as a backward compatible move though. It didn't quite percolate into my brain that it would be needed for the stuff that ship with gap itself.
another issue is that make gap-clean does not seem to work.
And installing GAP with SAGE_CHECK=yes hangs for me at gap-4.12.1/src/tst/testinstall/grp/basic.tst
Does it hang if you disable your internet connection? atlasgrp fetches precomputed data from the network (using either the io GAP package or the wget binary) if available, so connection failures/slowness may cause hangs occasionally. It falls back to local computation if there's no internet access.
Replying to Mauricio Collares:
Does it hang if you disable your internet connection?
atlasgrpfetches precomputed data from the network (using either theioGAP package or thewgetbinary) if available, so connection failures/slowness may cause hangs occasionally. It falls back to local computation if there's no internet access.
This might be useful: https://github.com/void-linux/void-packages/blob/master/srcpkgs/gap/patches/atlasrep-dont_use_network_by_default.patch
Replying to Dima Pasechnik:
another issue is that
make gap-cleandoes not seem to work.
The install script does not use DESTDIR staging (sdh_make install installs directly into the prefix)
Replying to Matthias Köppe:
Replying to Dima Pasechnik:
another issue is that
make gap-cleandoes not seem to work.The install script does not use DESTDIR staging (
sdh_make installinstalls directly into the prefix)
hmm, is this a GAP bug then? Or a Sage bug?
Try changing sdh_make install to sdh_make_install.
Description changed:
---
+++
@@ -1,3 +1,8 @@
+GAP 4.12.1 fixes critical bugs in 4.12.0
+
+[GAP 4.12.1 release page](https://www.gap-system.org/Releases/4.12.1.html)
+
+
GAP 4.12.0 was released in August 2022.
- [GAP 4.12.0 release announcement](https://lists.uni-kl.de/gap/arc/forum/2022-08/msg00031.html)Replying to Matthias Köppe:
Try changing
sdh_make installtosdh_make_install.
right, thanks - this worked after I removed build/pkgs/gap/spkg-prerm.in as well. I'll post a new branch.
Changed branch from u/arojas/packages/gap/4_12_1 to u/dimpase/packages/gap/4_12_1
With gap_packages, cleaning is still not 100% right. Namely, compiled GAP packages, e.g. cohomolo, leave a skeleton directory after make gap_packages-clean. It's harmless in this particular case though.
Let's leave this to another ticket.
Branch pushed to git repo; I updated commit sha1. New commits:
97dc1ea | with SAGE_CHECK=yes, one needs io installed to prevent hangs |