Opened 14 years ago

Closed 2 years ago

#3360 closed defect (fixed)

Upgrade sympow to 2.023.6 (for GCC 10 support)

Reported by: mabshoff Owned by: mabshoff
Priority: critical Milestone: sage-9.2
Component: packages: standard Keywords: upgrade, sympow
Cc: slelievre, gh-timokau, saraedum, isuruf, arojas, mjo, embray, dimpase, tscrim Merged in:
Authors: Timo Kaufmann, Matthias Koeppe Reviewers: Dima Pasechnik
Report Upstream: Reported upstream. No feedback yet. Work issues:
Branch: 2e3dd4d (Commits, GitHub, GitLab) Commit: 2e3dd4d90d6eaef23746891bd03230485d30e1e3
Dependencies: Stopgaps:

Status badges

Description (last modified by mkoeppe)

Fork now maintained by the debian sympow maintainer (gh-jgmbenoit).

https://gitlab.com/rezozer/forks/sympow

Upstream URL: see checksums.ini

See also:

  • #25856 Elliptic curve failures in 8.3.rc0: sympow issue

Change History (139)

comment:1 Changed 13 years ago by mabshoff

  • Status changed from new to assigned
  • Summary changed from Upgarde sympow to the 1.019 release to Upgrade sympow to the 1.023 release and also fix Solaris/x86 problem

comment:2 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:3 Changed 9 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:4 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:5 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:6 Changed 4 years ago by slelievre

  • Cc slelievre added
  • Description modified (diff)
  • Keywords upgrade sympow added
  • Milestone changed from sage-6.4 to sage-8.3
  • Report Upstream set to N/A

comment:7 Changed 4 years ago by fbissey

Didn't realise there was a newer version. Considering sympow's code, an upgrade can only be an improvement.

comment:8 Changed 4 years ago by slelievre

See also #25099 "Add DESTDIR support for sympow".

comment:9 Changed 4 years ago by saraedum

sympow 1.023 segfaults (in Debian) on some inputs that used to work with 1.018

$ sympow -analrank -curve "[0,1,1,-2,0]"
sympow 1.023 RELEASE (Debian 1.023-8)  (c) Mark Watkins --- see README and COPYING for details
Minimal model of curve  is [0,1,1,-2,0]
At 389: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 389
sp 1: Conductor at 389 is 1+0, root number is -1
sp 1: Euler factor at 389 is 1-1*x
1st sym power conductor is 389, global root number is 1
NT 1d0: 43
Maximal number of terms is 43
0.0E+00
Done with small primes 1049
Segmentation fault (core dumped)

comment:10 Changed 4 years ago by saraedum

comment:11 Changed 4 years ago by gh-timokau

  • Cc gh-timokau added

comment:12 follow-up: Changed 4 years ago by gh-timokau

In an effort to update the sympow package in nix, I contacted the debian maintainer (Jerome Benoit).

He told me that he really did receive their tarball in a private email (how did you guys manage to find that file on his homepage?). He also told me that "the upstream author is responsive (and he did not have a GIT because the code was written before the GIT revolution)".

Debian adds sage's patches and some more[1], as for example the bug fix saraedum mentions. It seems like Debian effectively became the new upstream of this package. I asked the maintainer if he had considered making it official and forking it, which he declined.

[1] https://salsa.debian.org/science-team/sympow/tree/master/debian/patches

comment:13 in reply to: ↑ 12 Changed 4 years ago by saraedum

Replying to gh-timokau:

He told me that he really did receive their tarball in a private email (how did you guys manage to find that file on his homepage?).

In my case: I wrote a private email to the sympow author and he told me about the URL.

He also told me that "the upstream author is responsive (and he did not have a GIT because the code was written before the GIT revolution)". Debian adds sage's patches and some more[1], as for example the bug fix saraedum mentions. It seems like Debian effectively became the new upstream of this package. I asked the maintainer if he had considered making it official and forking it, which he declined.

[1] https://salsa.debian.org/science-team/sympow/tree/master/debian/patches

I was in correspondence with the sympow author about the recent segfault patch. Afterwards I proposed to move the project to github and basically take over maintenance but I have not heard back for a while since then.

comment:14 Changed 4 years ago by gh-jgmbenoit

Is the URL still valid ? Otherwise, after all, I may also consider to maintain a fork of sympow.

comment:15 Changed 4 years ago by gh-timokau

sympow still seems to be hosted at that URL. Its just not advertised anywhere. But there are still all those semi-mandatory patches flying around that should probably be upstreamed. Having the project in some public version control would be great.

comment:16 Changed 4 years ago by slelievre

My notes about the url at https://trac.sagemath.org/ticket/25099#comment:13 still hold. Public version control of the original code and the existing extra patches would definitely help, as well as a home page for the project.

comment:17 Changed 4 years ago by gh-jgmbenoit

I am on my way to fork sympow on gitlab. My concern will be only the unix part (read not the mathematical part) in view to harmonize related patches and integration in unix systems. Notes: My time being counted and limited, it would be question of weekends, rather of days.

comment:18 Changed 4 years ago by gh-timokau

Great! Thank you for doing that.

comment:19 Changed 4 years ago by gh-jgmbenoit

I have just rendered public my fork at GitLab: https://gitlab.com/rezozer/forks/sympow Please test and report !

comment:20 Changed 4 years ago by gh-timokau

  • Cc saraedum added

Updating from 1.018.1, this breaks the sage testsuite (looks like pretty much all the sympow interaction is broken):

sage -t --long /nix/store/7bi7v0bxwrcs5f510i1d54qqd5jqqj2r-sage-src-8.2/src/sage/lfunctions/sympow.py  # 13 doctests failed
sage -t --long /nix/store/7bi7v0bxwrcs5f510i1d54qqd5jqqj2r-sage-src-8.2/src/sage/modular/abvar/abvar.py  # 1 doctest failed
sage -t --long /nix/store/7bi7v0bxwrcs5f510i1d54qqd5jqqj2r-sage-src-8.2/src/sage/modular/hecke/submodule.py  # 1 doctest failed
sage -t --long /nix/store/7bi7v0bxwrcs5f510i1d54qqd5jqqj2r-sage-src-8.2/src/sage/schemes/elliptic_curves/ell_rational_field.py  # 17 doctests failed

Probably just some minor change in output formatting that breaks the parser. Before I investigate further, this is presumably already fixed on Debian? Julian do you know the cause?

comment:21 follow-up: Changed 4 years ago by gh-timokau

@gh-jgmbenoit does the original author know about the fork? Has he said anything about it?

comment:22 Changed 4 years ago by gh-jgmbenoit

@saraedum I am not surprised that it breaks the sage testsuite because the patched version runs more like any regular program. In fact it must break the sage related code itself: see the section [SYMPOW Data set](https://gitlab.com/rezozer/forks/sympow#sympow-data-setup) up for details. Otherwise, since it works on Debian, I guess it was fixed there. But I am not the one who did the fix. So you want to check the Debian patches. Feel free to send email to the Debian Sage Team: the person who did it may guide you.

Last edited 4 years ago by gh-jgmbenoit (previous) (diff)

comment:23 in reply to: ↑ 21 Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

@gh-jgmbenoit does the original author know about the fork? Has he said anything about it?

I sent an email to the upstream author just before I announced here my intention to fork it. So, far I got no feed back.

comment:24 follow-up: Changed 4 years ago by gh-timokau

So you want to check the Debian patches. Feel free to send email to the Debian Sage Team: the person who did it may guide you.

That's why I added saraedum (Julian Rüdth). I was under the impression that he is the Debian maintainer. Is he not?

I sent an email to the upstream author just before I announced here my intention to fork it. So, far I got no feed back.

Great. Please keep me posted (for example by posting here) in case you get feedback. It would be nice to be able to add that note to the update.

comment:25 in reply to: ↑ 24 Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

So you want to check the Debian patches. Feel free to send email to the Debian Sage Team: the person who did it may guide you.

That's why I added saraedum (Julian Rüdth). I was under the impression that he is the Debian maintainer. Is he not?

I sent an email to the upstream author just before I announced here my intention to fork it. So, far I got no feed back.

Great. Please keep me posted (for example by posting here) in case you get feedback. It would be nice to be able to add that note to the update.

It is a team work. To my knowledge, Julian is a new comer. Whatever, it was certainly fix a long time given that I wrote the Debian patches a long time ago, at least before that Stretch was frozen. Concerning Sage on Debian, the best is to send an email to the dedicated list:

debian-science-sagemath _at_ alioth-lists.debian.net

Last edited 4 years ago by gh-jgmbenoit (previous) (diff)

comment:26 follow-up: Changed 4 years ago by gh-timokau

I cross-posted to that mailing list and sage-packaging: https://groups.google.com/forum/#!topic/sage-packaging/B3yTZ8eIbwM

comment:27 follow-up: Changed 4 years ago by gh-timokau

By the way what is the forks in the URL to your repo? Does gitlab allow subfolders or something? I'm asking because I never saw that before (always only owner/repo) and our infrastructure currently doesn't support fetching source from such a subfolder.

comment:28 in reply to: ↑ 27 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

By the way what is the forks in the URL to your repo? Does gitlab allow subfolders or something? I'm asking because I never saw that before (always only owner/repo) and our infrastructure currently doesn't support fetching source from such a subfolder.

GitLab allows one to create groups and subgroups: rezozer is a group , forks a subgroup, sympow a project. My GitLab webpage is https://gitlab.com/jgmbenoit

comment:29 in reply to: ↑ 26 Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

I cross-posted to that mailing list and sage-packaging: https://groups.google.com/forum/#!topic/sage-packaging/B3yTZ8eIbwM

Thanks, I should do it. Anyway, I guess that the Debian maintainer for sympow was aware.

comment:30 in reply to: ↑ 28 ; follow-up: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

By the way what is the forks in the URL to your repo? Does gitlab allow subfolders or something? I'm asking because I never saw that before (always only owner/repo) and our infrastructure currently doesn't support fetching source from such a subfolder.

GitLab allows one to create groups and subgroups: rezozer is a group , forks a subgroup, sympow a project. My GitLab webpage is https://gitlab.com/jgmbenoit

Can that be nested further or is subgroup the limit?

Thanks, I should do it. Anyway, I guess that the Debian maintainer for sympow was aware.

Were they? I haven't received a reply yet (besides that my post is awaiting approval).

comment:31 in reply to: ↑ 30 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

By the way what is the forks in the URL to your repo? Does gitlab allow subfolders or something? I'm asking because I never saw that before (always only owner/repo) and our infrastructure currently doesn't support fetching source from such a subfolder.

GitLab allows one to create groups and subgroups: rezozer is a group , forks a subgroup, sympow a project. My GitLab webpage is https://gitlab.com/jgmbenoit

Can that be nested further or is subgroup the limit?

it can be nested further. I do not know the limit.

Thanks, I should do it. Anyway, I guess that the Debian maintainer for sympow was aware.

Were they?

at least, I am :-)

I haven't received a reply yet (besides that my post is awaiting approval).

Be patient, it is summer time.

Last edited 4 years ago by gh-jgmbenoit (previous) (diff)

comment:32 in reply to: ↑ 31 Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

By the way what is the forks in the URL to your repo? Does gitlab allow subfolders or something? I'm asking because I never saw that before (always only owner/repo) and our infrastructure currently doesn't support fetching source from such a subfolder.

GitLab allows one to create groups and subgroups: rezozer is a group , forks a subgroup, sympow a project. My GitLab webpage is https://gitlab.com/jgmbenoit

Can that be nested further or is subgroup the limit?

it can be nested further. I do not know the limit.

Alright, thanks.

Thanks, I should do it. Anyway, I guess that the Debian maintainer for sympow was aware.

Were they?

at least, I am :-)

I haven't received a reply yet (besides that my post is awaiting approval).

Be patient, it is summer time.

Of course :) I must've misunderstood your message, I thought you were referring to a reply to that email.

comment:33 follow-up: Changed 4 years ago by gh-timokau

Okay turns out I just messed up packaging. Its not strictly relevant for this ticket and I thought about just emailing you, but maybe the sage package upgrade will run into the same problems.

So nix installs every package in its own prefix. That means sympow would go into /nix/store/some-sympow-specific-folder-name/. Only the sympow files would be in that folder.

I'm currently achieving that by setting the install flag DESTDIR=$out ($out pointing to that sympow directory). However when launching an example from the README, it fails because it looks for the new_data script in /usr/local/lib/sympow. That script is in $out/usr/local/lib/sympow. Here's the error:

$ result/bin/sympow -sp 2p16 -curve "[1,2,3,4,5]"
sympow 2.023.2 RELEASE  (c) Mark Watkins --- see README and COPYING for details
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Minimal model of curve  is [1,-1,0,4,3]
At 11: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
At 941: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 10351
P02L not found in param_data file
Will compute data mesh file for `2'
Make data for  symmetric power 2
/bin/sh: /usr/local/lib/sympow/new_data: No such file or directory
**ERROR** [FAILED]
May be tried with 'sympow -new_data `2'

In the README I see that I can set the SYMPOW_PKGLIBDIR environment variable (although that shouldn't be necessary). After doing that, I get

$ result/bin/sympow -sp 2p16 -curve "[1,2,3,4,5]"
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Running the new_data script for -sp 2
Making the datafiles for -sp 2

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Rewarping param_data file /home/timo/.sympow/datafiles/param_data
Left with 0 entries in param_data file /home/timo/.sympow/datafiles/param_data
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Removing any old data files
removed '/home/timo/.sympow/datafiles/P02HM.txt'
removed '/home/timo/.sympow/datafiles/P02HS.txt'
removed '/home/timo/.sympow/datafiles/P02LM.txt'
removed '/home/timo/.sympow/datafiles/P02LS.txt'
Running the gp script

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
***   error opening input file: `/usr/local/share/sympow/standard1.gp'.
***   error opening input file: `/usr/local/share/sympow/standard2.gp'.
***   error opening input file: `/usr/local/share/sympow/standard3.gp'.
***   at top-level: coeffs(0)
***                 ^---------
***   not a function in function call
***   at top-level: coeffE(1)
***                 ^---------
***   not a function in function call
***   error opening input file: `/usr/local/share/sympow/standard1.gp'.
***   error opening input file: `/usr/local/share/sympow/standard2.gp'.
***   error opening input file: `/usr/local/share/sympow/standard3.gp'.
***   at top-level: coeffs(0)
***                 ^---------
***   not a function in function call
***   at top-level: coeffO(1)
***                 ^---------
***   not a function in function call

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Trimming the data files
trimmed `/home/timo/.sympow/datafiles/P02HM.txt'
trimmed `/home/timo/.sympow/datafiles/P02HS.txt'
trimmed `/home/timo/.sympow/datafiles/P02LM.txt'
trimmed `/home/timo/.sympow/datafiles/P02LS.txt'
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Rewarping param_data file /home/timo/.sympow/datafiles/param_data
Left with 0 entries in param_data file /home/timo/.sympow/datafiles/param_data
Finished with -sp 2
**ERROR** P02L not found in param_data file in second round
sympow 2.023.2 RELEASE  (c) Mark Watkins --- see README and COPYING for details
Minimal model of curve  is [1,-1,0,4,3]
At 11: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
At 941: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 10351
P02L not found in param_data file
Will compute data mesh file for `2'
Has computed data mesh file for `2'

Am I doing something wrong or is that an issue with the Configure script? I'm executing ./Configure without parameters. pari is included in the build dependencies.

Also in case you find the time, it would be great if you could add a handful of test cases. I see that you already have some tests in the debian package. Otherwilse I'll just take some from the README, but having them included in the package is better of course.

comment:34 in reply to: ↑ 33 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Okay turns out I just messed up packaging. Its not strictly relevant for this ticket

I guess it would be a relevant ticket for the fork.

and I thought about just emailing you, but maybe the sage package upgrade will run into the same problems.

So nix installs every package in its own prefix. That means sympow would go into /nix/store/some-sympow-specific-folder-name/. Only the sympow files would be in that folder.

I'm currently achieving that by setting the install flag DESTDIR=$out ($out pointing to that sympow directory). However when launching an example from the README, it fails because it looks for the new_data script in /usr/local/lib/sympow. That script is in $out/usr/local/lib/sympow. Here's the error:

$ result/bin/sympow -sp 2p16 -curve "[1,2,3,4,5]"
sympow 2.023.2 RELEASE  (c) Mark Watkins --- see README and COPYING for details
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Minimal model of curve  is [1,-1,0,4,3]
At 11: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
At 941: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 10351
P02L not found in param_data file
Will compute data mesh file for `2'
Make data for  symmetric power 2
/bin/sh: /usr/local/lib/sympow/new_data: No such file or directory
**ERROR** [FAILED]
May be tried with 'sympow -new_data `2'

In the README I see that I can set the SYMPOW_PKGLIBDIR environment variable (although that shouldn't be necessary

it is why it is written that they are meant mainly for development and debugging purpose

Here you are misusing PREFIX, VARPREFIX, and DESTDIR (see below)

). After doing that, I get

$ result/bin/sympow -sp 2p16 -curve "[1,2,3,4,5]"
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Running the new_data script for -sp 2
Making the datafiles for -sp 2

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Rewarping param_data file /home/timo/.sympow/datafiles/param_data
Left with 0 entries in param_data file /home/timo/.sympow/datafiles/param_data
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Removing any old data files
removed '/home/timo/.sympow/datafiles/P02HM.txt'
removed '/home/timo/.sympow/datafiles/P02HS.txt'
removed '/home/timo/.sympow/datafiles/P02LM.txt'
removed '/home/timo/.sympow/datafiles/P02LS.txt'
Running the gp script

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
***   error opening input file: `/usr/local/share/sympow/standard1.gp'.
***   error opening input file: `/usr/local/share/sympow/standard2.gp'.
***   error opening input file: `/usr/local/share/sympow/standard3.gp'.
***   at top-level: coeffs(0)
***                 ^---------
***   not a function in function call
***   at top-level: coeffE(1)
***                 ^---------
***   not a function in function call
***   error opening input file: `/usr/local/share/sympow/standard1.gp'.
***   error opening input file: `/usr/local/share/sympow/standard2.gp'.
***   error opening input file: `/usr/local/share/sympow/standard3.gp'.
***   at top-level: coeffs(0)
***                 ^---------
***   not a function in function call
***   at top-level: coeffO(1)
***                 ^---------
***   not a function in function call

**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Trimming the data files
trimmed `/home/timo/.sympow/datafiles/P02HM.txt'
trimmed `/home/timo/.sympow/datafiles/P02HS.txt'
trimmed `/home/timo/.sympow/datafiles/P02LM.txt'
trimmed `/home/timo/.sympow/datafiles/P02LS.txt'
**WARNING** failed to create data bin package cache folder /var/cache/sympow/datafiles/le64
Rewarping param_data file /home/timo/.sympow/datafiles/param_data
Left with 0 entries in param_data file /home/timo/.sympow/datafiles/param_data
Finished with -sp 2
**ERROR** P02L not found in param_data file in second round
sympow 2.023.2 RELEASE  (c) Mark Watkins --- see README and COPYING for details
Minimal model of curve  is [1,-1,0,4,3]
At 11: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
At 941: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 10351
P02L not found in param_data file
Will compute data mesh file for `2'
Has computed data mesh file for `2'

Am I doing something wrong or is that an issue with the Configure script? I'm executing ./Configure without parameters.

DESTDIR is mainly meant for packaging in custom Makefile (not for testing)

To do what you want, I guess that you have to set up PREFIX (and maybe VARPREFIX) as it is done with customary Makefile.

The patches I brought from Debian are meant to ease integration in Unix for maintainers and users (compare to the original version): DESTDIR, PREFIX, and VARPREFIX have the customary meaning.

Basically you cannot test in DESTDIR unless you set correctly the environment variables because PREFIXed paths are hard coded.

pari is included in the build dependencies.

Also in case you find the time, it would be great if you could add a handful of test cases. I see that you already have some tests in the debian package.

The test in debian/tests are not meant to run at building time but once sympow is installed; they are CI tests. I am considering to write a test script for checking at building in view to migrate to autotools.

Otherwilse I'll just take some from the README, but having them included in the package is better of course.

comment:35 in reply to: ↑ 34 ; follow-up: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

... Am I doing something wrong or is that an issue with the Configure script? I'm executing ./Configure without parameters.

DESTDIR is mainly meant for packaging in custom Makefile (not for testing)

To do what you want, I guess that you have to set up PREFIX (and maybe VARPREFIX) as it is done with customary Makefile.

Right, DESTDIR was a leftover from the old way to package sympow. Using PREFIX instead fixes the issue.

Thank you.

Also in case you find the time, it would be great if you could add a handful of test cases. I see that you already have some tests in the debian package.

The test in debian/tests are not meant to run at building time but once sympow is installed; they are CI tests. I am considering to write a test script for checking at building in view to migrate to autotools.

Yes, install checks is exactly what I'd want. To catch issues like this early. I assumed the sage interface was at fault, even though it was just faulty packaging. So after installation (which at least for nix is the same as packaging; the installation result can just be put in an archive and distributed), something like autotools make installcheck would be what I want.

What is the difference between /var/cache/sympow and ~/.sympow? When is which one used? Is it possible to disable the global cache in favor of the user one? The readme talks about "precomputed" for /var and "user computed" for ~/.sympow. Does that mean runtime write access to VARPREFIX is not actually necessary?

comment:36 in reply to: ↑ 35 Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

... Am I doing something wrong or is that an issue with the Configure script? I'm executing ./Configure without parameters.

DESTDIR is mainly meant for packaging in custom Makefile (not for testing)

To do what you want, I guess that you have to set up PREFIX (and maybe VARPREFIX) as it is done with customary Makefile.

Right, DESTDIR was a leftover from the old way to package sympow. Using PREFIX instead fixes the issue.

Thank you.

Also in case you find the time, it would be great if you could add a handful of test cases. I see that you already have some tests in the debian package.

The test in debian/tests are not meant to run at building time but once sympow is installed; they are CI tests. I am considering to write a test script for checking at building in view to migrate to autotools.

Yes, install checks is exactly what I'd want. To catch issues like this early. I assumed the sage interface was at fault, even though it was just faulty packaging. So after installation (which at least for nix is the same as packaging; the installation result can just be put in an archive and distributed), something like autotools make installcheck would be what I want.

What is the difference between /var/cache/sympow and ~/.sympow?

/var/cache/sympow/datafiles/ goes in pair with /usr/share/sympow/datafiles/ : 1] /usr/share/sympow/datafiles/ contains data files in clear which are assumed to be manage at the superuser scale (basically a set of precomputed data installed at installation time); 2] /var/cache/sympow/datafiles/le64 contains the associated binaries (which are architecture dependent) that are not distributed but computed on the fly when necessary by the first user.

~/.sympow/datafiles/ will contain data files (clear versions and binaries) generated by USER when the clear version whenever the clear version is not readable in /usr/share/sympow/datafiles/ . Behind this, there is a community policy: we can reuse data computed by other users.

The data in HOME/.sympow are autoritative over the one system-wide ones, and The data in SYMPOW_CACHEDIR and SYMPOW_CACHEDIR/sympow are authoritative over the ones in HOME/.sympow . Nothing special here from a UNIX user point of view.

My aim was to keep the spirit of the original version. Some data were distributed to avoid the user some maneuvers and to wait a while (at this glorious time, computers were extremely slow and the users have to run GP themselves: thanks to Intel and its competitors and to my patches, this time is over and we can now enjoy the full power of SYMPOW).

If you look the code, for the right to read or write, something inspired by openssh code was implemented (I do not remember the details, but I remember that I tested it heavily). For Debian, beside the historical data, extra data are provided (and guessed that I took the list from Sage (must be double checked)). We can image to provide more data. You can find the job and a script to generate jobs in the material provided by Debian. These data are computed at packaging time, somehow it is also a `check'.

Having said that, it is okay to distributed no precomputed data.

My point is that some examples or tests in the literature may depend on the historical data, so having them can speed up tests and keep the end users cool. I strongly suggest to distribute the historical precomputed data (and the Sage ones).

When is which one used? Is it possible to disable the global cache in favor of the user one? The readme talks about "precomputed" for /var and "user computed" for ~/.sympow. Does that mean runtime write access to VARPREFIX is not actually necessary?

Just cleanup /usr/share/sympow/datafiles/ to let the possibility to superuser to provide system wide data.

Jerome

comment:37 follow-ups: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

What is the difference between /var/cache/sympow and ~/.sympow?

/var/cache/sympow/datafiles/ goes in pair with /usr/share/sympow/datafiles/ :

  • /usr/share/sympow/datafiles/ contains data files in clear which are assumed to be manage at the superuser scale (basically a set of precomputed data installed at installation time);
  • /var/cache/sympow/datafiles/le64 contains the associated binaries (which are architecture dependent) that are not distributed but computed on the fly when necessary by the first user.

Dependant on the exact CPU model or just x86/aarch, 32/64 bits?

~/.sympow/datafiles/ will contain data files (clear versions and binaries) generated by USER whenever the clear version is not readable in /usr/share/sympow/datafiles/ . Behind this, there is a community policy: we can reuse data computed by other users.

The data in HOME/.sympow are autoritative over the one system-wide ones, and The data in SYMPOW_CACHEDIR and SYMPOW_CACHEDIR/sympow are authoritative over the ones in HOME/.sympow . Nothing special here from a UNIX user point of view.

My aim was to keep the spirit of the original version. Some data were distributed to avoid the user some maneuvers and to wait a while (at this glorious time, computers were extremely slow and the users have to run GP themselves: thanks to Intel and its competitors and to my patches, this time is over and we can now enjoy the full power of SYMPOW).

If you look the code, for the right to read or write, something inspired by openssh code was implemented (I do not remember the details, but I remember that I tested it heavily). For Debian, beside the historical data, extra data are provided (and guessed that I took the list from Sage (must be double checked)). We can image to provide more data. You can find the job and a script to generate jobs in the material provided by Debian. These data are computed at packaging time, somehow it is also a `check'.

If I read the debian post install scripts correctly, doesn't everybody just have r+w access to the /var/cache directory?

Having said that, it is okay to distributed no precomputed data.

I'm not having any problems with the /usr/share precomputed data. What isn't ideal is that the user needs runtime write-access to the /var/cache directory.

I strongly suggest to distribute the historical precomputed data (and the Sage ones).

So basically running sympow -new_data with all the arguments listed in debians precomputed_data-lisof_parameter.data? It looks like the debian package still calls gp manually. So that'd be

for data in 1d0 2 2d0h 3d0 3d1 4; do
	sympow -new_data "$data"
done

But that tries to access HOME/.sympow. So you're generating user-level cache files at install time?

When is which one used? Is it possible to disable the global cache in favor of the user one? The readme talks about "precomputed" for /var and "user computed" for ~/.sympow. Does that mean runtime write access to VARPREFIX is not actually necessary?

Just cleanup /usr/share/sympow/datafiles/ to let the possibility to superuser to provide system wide data.

Even after deleting that, sympow still gives a warning about not being able to write to /var/cache/sympow.

comment:38 in reply to: ↑ 37 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

What is the difference between /var/cache/sympow and ~/.sympow?

/var/cache/sympow/datafiles/ goes in pair with /usr/share/sympow/datafiles/ :

  • /usr/share/sympow/datafiles/ contains data files in clear which are assumed to be manage at the superuser scale (basically a set of precomputed data installed at installation time);
  • /var/cache/sympow/datafiles/le64 contains the associated binaries (which are architecture dependent) that are not distributed but computed on the fly when necessary by the first user.

Dependant on the exact CPU model or just x86/aarch, 32/64 bits?

endianness

~/.sympow/datafiles/ will contain data files (clear versions and binaries) generated by USER whenever the clear version is not readable in /usr/share/sympow/datafiles/ . Behind this, there is a community policy: we can reuse data computed by other users.

The data in HOME/.sympow are autoritative over the one system-wide ones, and The data in SYMPOW_CACHEDIR and SYMPOW_CACHEDIR/sympow are authoritative over the ones in HOME/.sympow . Nothing special here from a UNIX user point of view.

My aim was to keep the spirit of the original version. Some data were distributed to avoid the user some maneuvers and to wait a while (at this glorious time, computers were extremely slow and the users have to run GP themselves: thanks to Intel and its competitors and to my patches, this time is over and we can now enjoy the full power of SYMPOW).

If you look the code, for the right to read or write, something inspired by openssh code was implemented (I do not remember the details, but I remember that I tested it heavily). For Debian, beside the historical data, extra data are provided (and guessed that I took the list from Sage (must be double checked)). We can image to provide more data. You can find the job and a script to generate jobs in the material provided by Debian. These data are computed at packaging time, somehow it is also a `check'.

If I read the debian post install scripts correctly, doesn't everybody just have r+w access to the /var/cache directory?

yes but just to write the binary data, which the binary version of the clean data: 1] so whoever write it, the output must be the same ; 2] any USER can bypass them by writting their own clean file in HOME/.sympow 3] any USER can remove them; 4] if faulty binary are set, we can trace back the faulty USER ; 5] the superuser can create a specific group.

Having said that, it is okay to distributed no precomputed data.

I'm not having any problems with the /usr/share precomputed data. What isn't ideal is that the user needs runtime write-access to the /var/cache directory.

He does not: he will get a warning message, but sympow will continue. The USER can pass the -quiet option to silence the warnings. No warning will not be ideal: the user must be aware if the set up is not correct.

I strongly suggest to distribute the historical precomputed data (and the Sage ones).

So basically running sympow -new_data with all the arguments listed in debians precomputed_data-lisof_parameter.data?

There is no such file but a script in debian/adhoc/job which is called at packaging time and which complete the original armd.sh . I could merge them, but I will not because it will touch the math part (what I want to avoid).

It looks like the debian package still calls gp manually. So that'd be

for data in 1d0 2 2d0h 3d0 3d1 4; do
	sympow -new_data "$data"
done

But it is not.

A debian centric patch is applies to add the extra data: debain/patches/debianization.patch At packaging time, besides the original script armd.sh , the script debian/adhoc/job/sympow-new_data.job is launched : those scripts call gp (and not sympow).

But that tries to access HOME/.sympow. So you're generating user-level cache files at install time?

see above

When is which one used? Is it possible to disable the global cache in favor of the user one? The readme talks about "precomputed" for /var and "user computed" for ~/.sympow. Does that mean runtime write access to VARPREFIX is not actually necessary?

Just cleanup /usr/share/sympow/datafiles/ to let the possibility to superuser to provide system wide data.

Even after deleting that, sympow still gives a warning about not being able to write to /var/cache/sympow.

so it is a warning (an not an ERROR message followed but an exit(-1)): I would consider it as a feature but not as a bug. In fact, a couple of checks are performed to detect a corrupted folder set up and avoid surprises .

The bug is in the installation process: the correct privileges must be encoded in Configure : I will try to fix this the next week-end . And in the README.md file: I should document better this part.

For now, to silent this warning, just set the right privilege or pass the option -quiet : no will be write if /usr/share/sympow/datafiles is empty .

Let me know if you think that a mechanism must be implemented to avoid this warning message.

Jerome

comment:39 in reply to: ↑ 37 Changed 4 years ago by gh-jgmbenoit

But that tries to access HOME/.sympow. So you're generating user-level cache files at install time?

This is the behaviour of the original source, hence the patch.

comment:40 in reply to: ↑ 38 Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

What is the difference between /var/cache/sympow and ~/.sympow?

/var/cache/sympow/datafiles/ goes in pair with /usr/share/sympow/datafiles/ :

  • /usr/share/sympow/datafiles/ contains data files in clear which are assumed to be manage at the superuser scale (basically a set of precomputed data installed at installation time);
  • /var/cache/sympow/datafiles/le64 contains the associated binaries (which are architecture dependent) that are not distributed but computed on the fly when necessary by the first user.

Dependant on the exact CPU model or just x86/aarch, 32/64 bits?

endianness

So would it be reasonable to pre-compute and distribute all the /var/cache data?

~/.sympow/datafiles/ will contain data files (clear versions and binaries) generated by USER whenever the clear version is not readable in /usr/share/sympow/datafiles/ . Behind this, there is a community policy: we can reuse data computed by other users.

The data in HOME/.sympow are autoritative over the one system-wide ones, and The data in SYMPOW_CACHEDIR and SYMPOW_CACHEDIR/sympow are authoritative over the ones in HOME/.sympow . Nothing special here from a UNIX user point of view.

My aim was to keep the spirit of the original version. Some data were distributed to avoid the user some maneuvers and to wait a while (at this glorious time, computers were extremely slow and the users have to run GP themselves: thanks to Intel and its competitors and to my patches, this time is over and we can now enjoy the full power of SYMPOW).

If you look the code, for the right to read or write, something inspired by openssh code was implemented (I do not remember the details, but I remember that I tested it heavily). For Debian, beside the historical data, extra data are provided (and guessed that I took the list from Sage (must be double checked)). We can image to provide more data. You can find the job and a script to generate jobs in the material provided by Debian. These data are computed at packaging time, somehow it is also a `check'.

If I read the debian post install scripts correctly, doesn't everybody just have r+w access to the /var/cache directory?

yes but just to write the binary data, which the binary version of the clean data: 1] so whoever write it, the output must be the same ; 2] any USER can bypass them by writting their own clean file in HOME/.sympow 3] any USER can remove them; 4] if faulty binary are set, we can trace back the faulty USER ; 5] the superuser can create a specific group.

Having said that, it is okay to distributed no precomputed data.

I'm not having any problems with the /usr/share precomputed data. What isn't ideal is that the user needs runtime write-access to the /var/cache directory.

He does not: he will get a warning message, but sympow will continue. The USER can pass the -quiet option to silence the warnings. No warning will not be ideal: the user must be aware if the set up is not correct.

And then sympow will fall back to ~/.sympow and behave exactly as usual?

I strongly suggest to distribute the historical precomputed data (and the Sage ones).

So basically running sympow -new_data with all the arguments listed in debians precomputed_data-lisof_parameter.data?

There is no such file but a script in debian/adhoc/job which is called at packaging time and which complete the original armd.sh . I could merge them, but I will not because it will touch the math part (what I want to avoid).

It looks like the debian package still calls gp manually. So that'd be

for data in 1d0 2 2d0h 3d0 3d1 4; do
	sympow -new_data "$data"
done

But it is not.

A debian centric patch is applies to add the extra data: debain/patches/debianization.patch At packaging time, besides the original script armd.sh , the script debian/adhoc/job/sympow-new_data.job is launched : those scripts call gp (and not sympow).

So what does the debian version do differntly?

But that tries to access HOME/.sympow. So you're generating user-level cache files at install time?

see above

Does that mean I should use the debian scripts if I want to distribute the cached binaries?

When is which one used? Is it possible to disable the global cache in favor of the user one? The readme talks about "precomputed" for /var and "user computed" for ~/.sympow. Does that mean runtime write access to VARPREFIX is not actually necessary?

Just cleanup /usr/share/sympow/datafiles/ to let the possibility to superuser to provide system wide data.

Even after deleting that, sympow still gives a warning about not being able to write to /var/cache/sympow.

so it is a warning (an not an ERROR message followed but an exit(-1)): I would consider it as a feature but not as a bug. In fact, a couple of checks are performed to detect a corrupted folder set up and avoid surprises .

I would disagree. If I understand correctly the shared cache is only really useful in the nowadays nieche case where a lot of users use the same sympow instance on one PC. And even then it will not have a huge impact because computing power is usually sufficient. Not having the shared state makes things easier to reason about and in general global state is annoying to deal with for packaging.

The bug is in the installation process: the correct privileges must be encoded in Configure : I will try to fix this the next week-end .

What do you mean by that?

And in the README.md file: I should document better this part.

For now, to silent this warning, just set the right privilege or pass the option -quiet : no will be write if /usr/share/sympow/datafiles is empty .

Does -quiet have any other effects besides surpressing that message?

Let me know if you think that a mechanism must be implemented to avoid this warning message.

To make my motivations mroe clear: In nix, every package lives in an immutable subfolder of /nix/store after installation. The name of that subfolder contains a hash describing the recipe used to build the package and all its dependencies. That has a lot of advantages. Two relevant examples:

  • packages can be installed with user privileges. That is because installing a package only downlaods a couple of archives and unpacks that at /nix/store. It does not in any way affect other users. The issue with /var here is that we'd need superuser privileges at install time. Also nix doesn't even have the concept of install time scripts, so I'd have to do some ugly hack like creating a wrapper for sympow that sets up the /var folder on first use.
  • multiple versions of a package can be installed side-by-side. For example different users may have different versions of sympow. Again, global state is difficult in this situation.

So if it is not strictly necessary, I'd like to either

  • avoid the global cache and use the user cache instead or
  • pre-populate the cache at build time. The cache dir would then be read-only at runtime.

It sounds like currently I can kind of do the first option by writing a wrapper for sympow that always passes the -quiet option. Of course it would be nicer to just disable the shared state through a ./Configure option and even nicer to use option two instead.

Am I misunderstanding this?

Thank you again for not only taking the time to improve the state of the singular package, but also patiently explaining the details to me :)

comment:41 Changed 4 years ago by vdelecroix

  • Milestone changed from sage-8.3 to sage-8.4

update milestone 8.3 -> 8.4

comment:42 Changed 4 years ago by gh-timokau

@gh-jgmbenoit ping

comment:43 follow-up: Changed 4 years ago by gh-jgmbenoit

pong !

Does -quiet have any other effects besides surpressing that message? NO. Once again, the custom GNU/Linux behaviour are followed.

You only issue is that there is a Warning message: I guess it is not necessary to write a wrapper for that. Second, I guess sympow is mainly used by Sage, which acts as wrapper.

((Is it that hard to read C source file ?))

comment:44 in reply to: ↑ 43 ; follow-up: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Does -quiet have any other effects besides surpressing that message? NO. Once again, the custom GNU/Linux behaviour are followed.

You only issue is that there is a Warning message: I guess it is not necessary to write a wrapper for that. Second, I guess sympow is mainly used by Sage, which acts as wrapper.

That is the only blocking issue, but it would still be better to be able to pre-compute the global cache at build time instead of lazily computing it at runtime. You didn't respond to all of my questions, which is understandable considering what a monster of message that was. So I'll summarize:

  • could the global cache reasonably be pre-computed at build time?
  • does sympow without a global cache behave exatly as usual, just computing the cache per-user instead?
  • if the debian/adhoc/job file to pre-compute some data is recommended, I would prefer if you would include it in sympow proper. However I understand your reservations about touching the math.

((Is it that hard to read C source file ?))

Honestly yes, the sympow code is very hard to read for me. Its a mix of very non-standard formatting, a lack of comments and my limited C and domain knowledge. That is why I'm glad that you have taken up the maintenance.

I'll try a -quiet wrapper for now.

comment:45 in reply to: ↑ 44 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Does -quiet have any other effects besides surpressing that message? NO. Once again, the custom GNU/Linux behaviour are followed.

You only issue is that there is a Warning message: I guess it is not necessary to write a wrapper for that. Second, I guess sympow is mainly used by Sage, which acts as wrapper.

That is the only blocking issue, but it would still be better to be able to pre-compute the global cache at build time instead of lazily computing it at runtime. You didn't respond to all of my questions, which is understandable considering what a monster of message that was. So I'll summarize:

  • could the global cache reasonably be pre-computed at build time?

No for security reasons: those files are binary files: for security matter you want to avoid to distribute binary files. Anyway, their computation time is very short: the hard part is contained in the corresponding clear data.

  • does sympow without a global cache behave exatly as usual, just computing the cache per-user instead?

Yes.

  • if the debian/adhoc/job file to pre-compute some data is recommended, I would prefer if you would include it in sympow proper. However I understand your reservations about touching the math.

I plan to incorporated them latter: the issue is now time.

((Is it that hard to read C source file ?))

Honestly yes, the sympow code is very hard to read for me. Its a mix of very non-standard formatting, a lack of comments and my limited C and domain knowledge. That is why I'm glad that you have taken up the maintenance.

I'll try a -quiet wrapper for now.

I would forget it and spend my time else where.

I plan to change the verbosity level of this message (once I have time before me).

Jerome

Last edited 4 years ago by gh-jgmbenoit (previous) (diff)

comment:46 in reply to: ↑ 45 ; follow-up: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

  • could the global cache reasonably be pre-computed at build time?

No for security reasons: those files are binary files: for security matter you want to avoid to distribute binary files. Anyway, their computation time is very short: the hard part is contained in the corresponding clear data.

I don't understand what you mean. The sympow binary is also a distributed binary file. The data would be computed in the build script just as the executables would be. Any user could verify that by building it themselves.

I'll try a -quiet wrapper for now.

I would forget it and spend my time else where.

I plan to change the verbosity level of this message (once I have time before me).

Well it seems to break sages parsing, so I'll need to add that wrapper. After that sages tests still fail. I'm now trying to update sages spkg first to find out if thats a quirk with nix's build system or a parsing issue. However while packaging the spkg I've hit another issue: the ./Configure script now relies on autotools to generate the endian tuple. autotools apparently is an "experimental" package that currently isn't included in the sage distribution by default. I would replace it by this python script:

import sys
import platform

if sys.byteorder == "little":
    endian = "le"
else:
    endian = "be"

bits = platform.architecture()[0][:-3]

# for example "le64" or "be32"
print(endian + bits)

Is that correct?

comment:47 in reply to: ↑ 46 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

  • could the global cache reasonably be pre-computed at build time?

No for security reasons: those files are binary files: for security matter you want to avoid to distribute binary files. Anyway, their computation time is very short: the hard part is contained in the corresponding clear data.

I don't understand what you mean. The sympow binary is also a distributed binary file. The data would be computed in the build script just as the executables would be. Any user could verify that by building it themselves.

the data are stored as binary, so the data binary file can be detected as an arbitrary binary file, namely as a suspicious file.

On my box:

$ file ~/.sympow/datafiles/le64/P014M.bin

gives

$ /home/jgmb/.sympow/datafiles/le64/P014M.bin: data

For any regular binary files, file(1) should be able to identified.

I'll try a -quiet wrapper for now.

I would forget it and spend my time else where.

I plan to change the verbosity level of this message (once I have time before me).

Well it seems to break sages parsing, so I'll need to add that wrapper. After that sages tests still fail. I'm now trying to update sages spkg first to find out if thats a quirk with nix's build system or a parsing issue.

This is indeed an issue.

However while packaging the spkg I've hit another issue: the ./Configure script now relies on autotools to generate the endian tuple. autotools apparently is an "experimental" package that currently isn't included in the sage distribution by default. I would replace it by this python script:

import sys
import platform

if sys.byteorder == "little":
    endian = "le"
else:
    endian = "be"

bits = platform.architecture()[0][:-3]

# for example "le64" or "be32"
print(endian + bits)

Is that correct?

it looks correct.

comment:48 Changed 4 years ago by gh-timokau

  • Authors set to Timo Kaufmann
  • Branch set to u/gh-timokau/sympow-2.23.2
  • Commit set to c29badb7d9da504b97c98794d0811e4b74c62651

New commits:

3ff111fEnable fflas_ffpack tests
c29badbUpgrade sympow to 2.23.2

comment:49 Changed 4 years ago by git

  • Commit changed from c29badb7d9da504b97c98794d0811e4b74c62651 to 14dd58c287a7e21862188ae833f961b908d17a3c

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

14dd58cUpgrade sympow to 2.23.2

comment:50 Changed 4 years ago by gh-timokau

  • Description modified (diff)
  • Status changed from new to needs_review

New commits:

14dd58cUpgrade sympow to 2.23.2

comment:51 in reply to: ↑ 47 ; follow-ups: Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

I don't understand what you mean. The sympow binary is also a distributed binary file. The data would be computed in the build script just as the executables would be. Any user could verify that by building it themselves.

the data are stored as binary, so the data binary file can be detected as an arbitrary binary file, namely as a suspicious file.

Why is a binary data file any more suspicious than a binary executable?

However while packaging the spkg I've hit another issue: the ./Configure script now relies on autotools to generate the endian tuple. autotools apparently is an "experimental" package that currently isn't included in the sage distribution by default. I would replace it by this python script:

[...]

it looks correct.

I've implemented it. Its really a shame sagemath doesn't provide autotools by default.

comment:52 follow-up: Changed 4 years ago by gh-timokau

Points for reviewers to focus on I'm not sure about:

  • this creates a SAGE_LOCAL/var/cache folder. There is no precedence for that.
  • it also creates a .sympow folder in the user's home directory at runtime. Not sure if that was already the case before.

comment:53 in reply to: ↑ 51 ; follow-up: Changed 4 years ago by gh-jgmbenoit

Replying to gh-timokau:

Replying to gh-jgmbenoit:

Replying to gh-timokau:

I don't understand what you mean. The sympow binary is also a distributed binary file. The data would be computed in the build script just as the executables would be. Any user could verify that by building it themselves.

the data are stored as binary, so the data binary file can be detected as an arbitrary binary file, namely as a suspicious file.

Why is a binary data file any more suspicious than a binary executable?

A binary executable is recognized as such by file(1): so it recognisable as such.

However while packaging the spkg I've hit another issue: the ./Configure script now relies on autotools to generate the endian tuple. autotools apparently is an "experimental" package that currently isn't included in the sage distribution by default. I would replace it by this python script:

[...]

it looks correct.

I've implemented it. Its really a shame sagemath doesn't provide autotools by default.

comment:54 in reply to: ↑ 53 Changed 4 years ago by gh-timokau

Replying to gh-jgmbenoit:

Replying to gh-timokau:

Why is a binary data file any more suspicious than a binary executable?

A binary executable is recognized as such by file(1): so it recognisable as such.

Why does that matter? I don't understand why an executable that is recognized as such is any less suspicious or security relevant than a binary data file. The executable is arguably more security relevant.

comment:55 Changed 4 years ago by gh-timokau

  • Summary changed from Upgrade sympow to the 1.023 release and also fix Solaris/x86 problem to Upgrade sympow to the 2.023.2 release and also fix Solaris/x86 problem

comment:56 Changed 4 years ago by slelievre

  • Milestone changed from sage-8.4 to sage-8.7

comment:57 Changed 3 years ago by embray

  • Milestone changed from sage-8.7 to sage-8.8

Ticket retargeted after milestone closed (if you don't believe this ticket is appropriate for the Sage 8.8 release please retarget manually)

comment:58 Changed 3 years ago by embray

  • Milestone changed from sage-8.8 to sage-8.9

Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).

comment:59 Changed 3 years ago by embray

  • Milestone changed from sage-8.9 to sage-9.1

Ticket retargeted after milestone closed

comment:60 in reply to: ↑ 51 ; follow-up: Changed 2 years ago by mkoeppe

Replying to gh-timokau:

I've implemented it. Its really a shame sagemath doesn't provide autotools by default.

Autotools are supposed to be run by maintainers at "make dist" time, not at installation time

comment:61 follow-up: Changed 2 years ago by mkoeppe

  • Cc isuruf arojas added

What are other distributions doing about sympow?

Running into compilation errors on Fedora-32 (gcc 10) - https://github.com/mkoeppe/sage/runs/546662577?check_suite_focus=true

comment:62 Changed 2 years ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:63 in reply to: ↑ 60 ; follow-up: Changed 2 years ago by gh-jgmbenoit

Replying to mkoeppe:

Replying to gh-timokau:

I've implemented it. Its really a shame sagemath doesn't provide autotools by default.

Autotools are supposed to be run by maintainers at "make dist" time, not at installation time

This is true.

I have just tried to refresh my memory about: basically the Autotools part jsut run some c code: so I guess that we can replace it with a C source.

comment:64 in reply to: ↑ 61 ; follow-ups: Changed 2 years ago by gh-jgmbenoit

Replying to mkoeppe:

What are other distributions doing about sympow?

What do you mean ?

Running into compilation errors on Fedora-32 (gcc 10) - https://github.com/mkoeppe/sage/runs/546662577?check_suite_focus=true

I have just seen the merge request on gitlab. Next week I might be on vacation, I will a look then.

comment:65 in reply to: ↑ 64 Changed 2 years ago by mkoeppe

Replying to gh-jgmbenoit:

Replying to mkoeppe:

What are other distributions doing about sympow?

conda-forge, arch, etc. are packaging sage and the packages they need. Just wondering whether they are using the fork, and how they have adjusted the sage interface and doctests if necessary.

comment:66 Changed 2 years ago by isuruf

conda-forge switched to debian's fork more than a year ago.

comment:67 Changed 2 years ago by gh-timokau

nixpkgs is using the fork as well. I've switched it over here: https://github.com/NixOS/nixpkgs/commit/5e58c5f900e51c4dd89de8a4518c5bb13581f3c6

No patches to sage were necessary to pass the test suite. I still added a patch that puts the cache directory under the .sage directory though: https://github.com/NixOS/nixpkgs/commit/9ef44b34316cb47c0bda49f05c57ca2ea6c96816

comment:68 Changed 2 years ago by mkoeppe

Anything missing on this ticket other than rebasing?

comment:69 in reply to: ↑ 52 ; follow-up: Changed 2 years ago by gh-timokau

Replying to gh-timokau:

Points for reviewers to focus on I'm not sure about:

  • this creates a SAGE_LOCAL/var/cache folder. There is no precedence for that.
  • it also creates a .sympow folder in the user's home directory at runtime. Not sure if that was already the case before.

This is probably still relevant. Other than that, I don't remember. I won't continue working on this for now, so anybody else should feel free to pick this up.

comment:70 Changed 2 years ago by mkoeppe

  • Milestone changed from sage-9.1 to sage-9.2

comment:71 in reply to: ↑ 63 Changed 2 years ago by gh-jgmbenoit

Replying to gh-jgmbenoit:

Replying to mkoeppe:

Replying to gh-timokau:

I've implemented it. Its really a shame sagemath doesn't provide autotools by default.

Autotools are supposed to be run by maintainers at "make dist" time, not at installation time

This is true.

I have just tried to refresh my memory about: basically the Autotools part jsut run some c code: so I guess that we can replace it with a C source.

In version 2.023.6, the autotools dependency was discarded: the endianess is now determine via a C program. Please check it on exotic architectures if you can, and let me know if any issue arises.

comment:72 in reply to: ↑ 64 Changed 2 years ago by gh-jgmbenoit

Replying to gh-jgmbenoit:

Replying to mkoeppe:

What are other distributions doing about sympow?

What do you mean ?

Running into compilation errors on Fedora-32 (gcc 10) - https://github.com/mkoeppe/sage/runs/546662577?check_suite_focus=true

I have just seen the merge request on gitlab. Next week I might be on vacation, I will a look then.

I applied the patch in version 2.023.6 .

comment:73 Changed 2 years ago by mjo

  • Cc mjo added

comment:74 in reply to: ↑ 69 ; follow-up: Changed 2 years ago by mjo

Replying to gh-timokau:

Replying to gh-timokau:

Points for reviewers to focus on I'm not sure about:

  • this creates a SAGE_LOCAL/var/cache folder. There is no precedence for that.
  • it also creates a .sympow folder in the user's home directory at runtime. Not sure if that was already the case before.

This is probably still relevant. Other than that, I don't remember. I won't continue working on this for now, so anybody else should feel free to pick this up.

If sage-the-distribution still supports multi-user installs, that location will generally not be writable. The default of $HOME/.sympow is probably the best you can do. And given that this is binary data and the quality of the code, I'm not sure that it's wise to share the cache among a "sympow" group anywhere else. So FWIW I would leave it at the default.

comment:75 in reply to: ↑ 74 ; follow-ups: Changed 2 years ago by mjo

Replying to mjo:

If sage-the-distribution still supports multi-user installs, that location will generally not be writable. The default of $HOME/.sympow is probably the best you can do.

Actually, there are two different cache directories to worry about. The one that defaults to $HOME/.sympow is different from the one that goes under VARPREFIX. I'm not sure what to do about that one; a wrapper or launcher script (that overrides that directory and uses something under $HOME) is the only way I've been able to make it work so far. More details eventually on https://gitlab.com/rezozer/forks/sympow/-/issues/3

comment:76 in reply to: ↑ 75 Changed 2 years ago by mjo

Replying to mjo:

Replying to mjo:

If sage-the-distribution still supports multi-user installs, that location will generally not be writable. The default of $HOME/.sympow is probably the best you can do.

Actually, there are two different cache directories to worry about. The one that defaults to $HOME/.sympow is different from the one that goes under VARPREFIX.

This is true, but turns out to not be a problem. The fork tries to use the directory under VARPREFIX, and if that doesn't work, it falls back to using $HOME/.sympow for that data as well. The only "problem" with that is that a warning is displayed to the user if he runs sympow by hand.

So, the sage SPKG should leave VARPREFIX alone. In Gentoo I'm going to patch out the expected warning (see the gitlab issue), and that may make sense for sage as well since /var will not generally be writable by whoever is running sage. The data will ultimately get stored under $HOME/.sympow, and that's what we want in the SPKG.

comment:77 in reply to: ↑ 75 Changed 2 years ago by gh-timokau

Replying to mjo:

Replying to mjo:

If sage-the-distribution still supports multi-user installs, that location will generally not be writable. The default of $HOME/.sympow is probably the best you can do.

Actually, there are two different cache directories to worry about. The one that defaults to $HOME/.sympow is different from the one that goes under VARPREFIX. I'm not sure what to do about that one; a wrapper or launcher script (that overrides that directory and uses something under $HOME) is the only way I've been able to make it work so far. More details eventually on https://gitlab.com/rezozer/forks/sympow/-/issues/3

There was already quite a bit of discussion about this issue here, see the posts following this message: https://trac.sagemath.org/ticket/3360#comment:35

For nixpkgs, I decided to use a wrapper instead of a patch: https://github.com/NixOS/nixpkgs/blob/962f93c46b1eaaedbc118c06adfd439ce341a0db/pkgs/development/libraries/science/math/sympow/default.nix#L44

comment:78 Changed 2 years ago by mkoeppe

  • Description modified (diff)
  • Summary changed from Upgrade sympow to the 2.023.2 release and also fix Solaris/x86 problem to Upgrade sympow to 2.023.6

comment:79 Changed 2 years ago by mkoeppe

  • Priority changed from major to critical
  • Summary changed from Upgrade sympow to 2.023.6 to Upgrade sympow to 2.023.6 (for GCC 10 support)

comment:80 Changed 2 years ago by mkoeppe

  • Cc embray added
  • Description modified (diff)

comment:81 Changed 2 years ago by mkoeppe

  • Cc dimpase added

comment:82 Changed 2 years ago by mkoeppe

  • Branch changed from u/gh-timokau/sympow-2.23.2 to u/mkoeppe/sympow-2.23.2

comment:83 Changed 2 years ago by git

  • Commit changed from 14dd58c287a7e21862188ae833f961b908d17a3c to d1255d0470f88ee57a13e337f0edb05b4c80422a

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

d1255d0build/pkgs/sympow: Update to 2.023.6, add upstream_url

comment:84 Changed 2 years ago by git

  • Commit changed from d1255d0470f88ee57a13e337f0edb05b4c80422a to 61202922f683ebb9c6548a1205d1b1e5c8317d2d

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

6120292build/pkgs/sympow/patches/0001-Remove-the-ENDIANTUPLE-detection.patch: Remove

comment:85 Changed 2 years ago by git

  • Commit changed from 61202922f683ebb9c6548a1205d1b1e5c8317d2d to 8fd14222a656332d2e7a1a85c621dd2e748467cd

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

8fd1422build/pkgs/sympow: Remove old endiantuple configure workarounds

comment:86 Changed 2 years ago by mkoeppe

  • Authors changed from Timo Kaufmann to Timo Kaufmann, Matthias Koeppe
  • Status changed from needs_work to needs_review

comment:87 Changed 2 years ago by mkoeppe

Builds on macOS, haven't tested anything else yet.

comment:88 Changed 2 years ago by mkoeppe

  • Description modified (diff)

comment:89 Changed 2 years ago by mkoeppe

  • Description modified (diff)

comment:90 Changed 2 years ago by git

  • Commit changed from 8fd14222a656332d2e7a1a85c621dd2e748467cd to 2fede6f6ae077c086ff5ef4881d5e3cb07ecdbf5

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

539c182build/make/install: Do not depend on src/bin/sage-version.sh
761092cMerge branch 't/29987/build_make_install__do_not_depend_on_src_bin_sage_version_sh' into t/30064/fix_tox_docker_builds_broken_by__29884
f2efa6asrc/doc/bootstrap: Create the directory src/doc/en/reference/repl if it does not exist
b7bf43bbuild/bin/write-dockerfile.sh: ADD src/bin for bootstrapping, needed by src/doc/bootstrap after #29884
365ce61Merge branch 'u/mkoeppe/fix_tox_docker_builds_broken_by__29884' of git://trac.sagemath.org/sage into HEAD
1e7becctox.ini [debian-buster, -sid]: IGNORE_MISSING_SYSTEM_PACKAGES=yes because of libpython3.7-dev
fb61a31Merge branch 'u/mkoeppe/tox_ini__debian_bullseye___sid_have_python3_8_instead_of_3_7' of git://trac.sagemath.org/sage into 9.2.beta3+ci-fixes
2fede6fMerge branch '9.2.beta3+ci-fixes' into t/3360/sympow-2.23.2

comment:92 follow-up: Changed 2 years ago by mkoeppe

  [sympow-2.023.6]     File "/usr/lib/python3.6/urllib/request.py", line 1952, in http_error
  [sympow-2.023.6]       return self.http_error_default(url, fp, errcode, errmsg, headers)
  [sympow-2.023.6]     File "/cygdrive/d/a/sage/sage/build/bin/../sage_bootstrap/download/transfer.py", line 107, in http_error_default
  [sympow-2.023.6]       raise DownloadError(errcode, errmsg, url)
  [sympow-2.023.6]   OSError: [Errno socket error] [Errno 403] Forbidden: '//gitlab.com/rezozer/forks/sympow/-/archive/v2.023.6/sympow-v2.023.6.tar.gz'
  [sympow-2.023.6]   

comment:93 in reply to: ↑ 92 Changed 2 years ago by dimpase

Replying to mkoeppe:

  [sympow-2.023.6]     File "/usr/lib/python3.6/urllib/request.py", line 1952, in http_error
  [sympow-2.023.6]       return self.http_error_default(url, fp, errcode, errmsg, headers)
  [sympow-2.023.6]     File "/cygdrive/d/a/sage/sage/build/bin/../sage_bootstrap/download/transfer.py", line 107, in http_error_default
  [sympow-2.023.6]       raise DownloadError(errcode, errmsg, url)
  [sympow-2.023.6]   OSError: [Errno socket error] [Errno 403] Forbidden: '//gitlab.com/rezozer/forks/sympow/-/archive/v2.023.6/sympow-v2.023.6.tar.gz'
  [sympow-2.023.6]   

the link works from the browser for me.

comment:95 Changed 2 years ago by mkoeppe

Tests using a temporary github url at https://github.com/mkoeppe/sage/actions/runs/160116395

comment:96 Changed 2 years ago by mkoeppe

ubuntu-trusty-minimal (https://github.com/mkoeppe/sage/runs/844024596):

gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4) 
****************************************************
Package 'sympow' is currently not installed
No legacy uninstaller found for 'sympow'; nothing to do
CFLAGS for SYMPOW: -fno-fast-math -mfpmath=sse -Dx86 -ffp-contract=on 
The double precision of your FPU is 53 bits.
CFLAGS for SYMPOW:  -std=gnu11 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH 
The double precision of your FPU is 53 bits.
config/endiantuple.c:6:2: error: #error "require C11 or higher"
 #error "require C11 or higher"
  ^
Error: the command below failed:
gcc config/endiantuple.c -o config/endiantuple
********************************************************************************
Error configuring SYMPOW

Likewise on debian-jessie-minimal, linuxmint-17-minimal.

comment:97 Changed 2 years ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:99 Changed 2 years ago by git

  • Commit changed from 2fede6f6ae077c086ff5ef4881d5e3cb07ecdbf5 to acbc3e811fb011462b3ff78537b2fd8b2fda804f

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

bc60260build/pkgs/sympow/checksums.ini: Use a github URL for testing
acbc3e8build/pkgs/sympow/spkg-install.in: Remove upstreamed configuration bits

comment:100 Changed 2 years ago by git

  • Commit changed from acbc3e811fb011462b3ff78537b2fd8b2fda804f to 54038914043134c95a5b033e3c8dd30b8f7668bc

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

5403891build/pkgs/sympow/spkg-install.in: Remove upstreamed configuration C files

comment:101 Changed 2 years ago by mkoeppe

  • Report Upstream changed from N/A to Reported upstream. No feedback yet.

comment:102 Changed 2 years ago by git

  • Commit changed from 54038914043134c95a5b033e3c8dd30b8f7668bc to 1ef375ea861186460cb02f9cfce01000e206371b

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

1ef375ebuild/pkgs/sympow/patches/0001-Configure-Use-the-discovered-CFLAGS-for-the-next-tes.patch: New

comment:103 Changed 2 years ago by mkoeppe

  • Status changed from needs_work to needs_review

comment:105 Changed 2 years ago by mkoeppe

(comment for the wrong ticket)

Last edited 2 years ago by mkoeppe (previous) (diff)

comment:106 Changed 2 years ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:107 Changed 2 years ago by mkoeppe

  • Status changed from needs_work to needs_review

Tests look OK. Ready for review

comment:108 Changed 2 years ago by dimpase

do you test with gcc10?

comment:109 Changed 2 years ago by mkoeppe

Haven't yet. I trust upstream there

comment:110 Changed 2 years ago by mkoeppe

We can reuse #30067 as a GCC 10 upgrade test ticket

comment:111 follow-up: Changed 2 years ago by mkoeppe

or #29456

comment:112 Changed 2 years ago by git

  • Commit changed from 1ef375ea861186460cb02f9cfce01000e206371b to 283685ce1155daf1f0ae6169756917f797ff20a9

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

283685cMerge tag '9.2.beta4' into t/3360/sympow-2.23.2

comment:113 in reply to: ↑ 111 Changed 2 years ago by mkoeppe

Replying to mkoeppe:

or #29456

GCC10 testing is happening on #29456 now.

comment:114 Changed 2 years ago by mkoeppe

But this ticket does not need to wait for it -- ready for review.

comment:115 Changed 2 years ago by mkoeppe

  • Cc tscrim added

comment:116 follow-up: Changed 2 years ago by mkoeppe

sympow builds OK on all platforms (including with gcc 10 for fedora-32-minimal) at https://github.com/mkoeppe/sage/actions/runs/168165380

However, I see many test failures in sagelib that seem related to sympow in fedora-32-standard (https://github.com/mkoeppe/sage/runs/867731204) -- where sympow comes from the system after #29673!

**********************************************************************
File "src/sage/lfunctions/sympow.py", line 225, in sage.lfunctions.sympow.Sympow.modular_degree
Failed example:
    sympow.modular_degree(EllipticCurve('11a'))
Exception raised:
    Traceback (most recent call last):
      File "/sage/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 707, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/sage/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 1132, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.lfunctions.sympow.Sympow.modular_degree[0]>", line 1, in <module>
        sympow.modular_degree(EllipticCurve('11a'))
      File "/sage/local/lib/python3.7/site-packages/sage/lfunctions/sympow.py", line 241, in modular_degree
        raise RuntimeError("failed to compute modular degree")
    RuntimeError: failed to compute modular degree
----------------------------------------------------------------------
sage -t src/sage/lfunctions/sympow.py  # 10 doctests failed
sage -t src/sage/modular/abvar/abvar.py  # 1 doctest failed
sage -t src/sage/modular/hecke/submodule.py  # 1 doctest failed
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # 14 doctests failed
----------------------------------------------------------------------
Last edited 2 years ago by mkoeppe (previous) (diff)

comment:117 in reply to: ↑ 116 Changed 2 years ago by mkoeppe

Replying to mkoeppe:

I see many test failures in sagelib that seem related to sympow in fedora-32-standard (https://github.com/mkoeppe/sage/runs/867731204) -- where sympow comes from the system after #29673!

I have opened #30147 (Fix spkg-configure.m4 for sympow) for this.

The present ticket is ready for review.

comment:118 Changed 2 years ago by dimpase

  • Reviewers set to Dima Pasechnik

comment:119 Changed 2 years ago by dimpase

  • Status changed from needs_review to positive_review

lgtm

comment:120 Changed 2 years ago by mkoeppe

Thanks.

comment:121 Changed 2 years ago by vbraun

  • Status changed from positive_review to needs_work

I'm getting lots of errors of the form:

**********************************************************************
File "src/sage/schemes/elliptic_curves/ell_rational_field.py", line 3845, in sage.schemes.elliptic_curves.ell_rational_field.EllipticCurve_rational_field.congruence_number
Failed example:
    E.modular_degree()
Expected:
    16
Got:
    **WARNING** failed to create data bin package cache folder /home/buildbot/slave/sage_git/build/local/var/cache/sympow/datafiles/le64
    16
**********************************************************************

comment:122 Changed 2 years ago by mkoeppe

on what machine

comment:123 Changed 2 years ago by mjo

That "error" is expected, in general, and shouldn't be output at the default verbosity (in my opinion). I already patched it:

https://gitweb.gentoo.org/repo/gentoo.git/plain/sci-mathematics/sympow/files/sympow-2.023.6-no-pkgdatafilesbindir-warnings.patch

The discussion is here,

https://gitlab.com/rezozer/forks/sympow/-/issues/3

if you want to ask upstream about including it.

comment:124 Changed 2 years ago by mkoeppe

Let's just include your patch on this ticket

comment:125 Changed 2 years ago by git

  • Commit changed from 283685ce1155daf1f0ae6169756917f797ff20a9 to ae0f11358ebfa721a7bddde18db1ce258d2c4929

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

ae0f113build/pkgs/sympow: Add sympow-2.023.6-no-pkgdatafilesbindir-warnings.patch

comment:126 Changed 2 years ago by mkoeppe

  • Status changed from needs_work to needs_review

comment:127 Changed 2 years ago by dimpase

  • Status changed from needs_review to positive_review

over to the bots

comment:128 Changed 2 years ago by vbraun

  • Status changed from positive_review to needs_work
make[5]: Entering directory '/home/release/Sage/local/var/tmp/sage/build/sympow-2.023.6/src'
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o fpu.o fpu.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o analrank.o analrank.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o analytic.o analytic.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o compute.o compute.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o compute2.o compute2.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o help.o help.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o conductors.o conductors.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o disk.o disk.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o ec_ap.o ec_ap.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o ec_ap_bsgs.o ec_ap_bsgs.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o ec_ap_large.o ec_ap_large.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o eulerfactors.o eulerfactors.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o factor.o factor.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o generate.o generate.c
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o init_curve.o init_curve.c
generate.c: In function 'new_data':
generate.c:234:32: error: 'GP' undeclared (first use in this function)
  234 |  execlp(SH,SH,newdatascript,SH,GP,ARGS,NULL);}
      |                                ^~
generate.c:234:32: note: each undeclared identifier is reported only once for each function it appears in
gcc   -O3  -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o main.o main.c
make[5]: *** [Makefile:39: generate.o] Error 1

comment:129 Changed 2 years ago by mkoeppe

on what machine

comment:130 Changed 2 years ago by git

  • Commit changed from ae0f11358ebfa721a7bddde18db1ce258d2c4929 to f522ea6aa29f068c3fe6b25847aadb431b5961d8

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

f522ea6Merge tag '9.2.beta6' into t/3360/sympow-2.23.2

comment:132 Changed 2 years ago by mkoeppe

  • Status changed from needs_work to positive_review

Builds correctly on all platforms.

comment:133 follow-up: Changed 2 years ago by vbraun

Fedora 32 x86_64 for the record

comment:134 in reply to: ↑ 133 Changed 2 years ago by mkoeppe

Replying to vbraun:

Fedora 32 x86_64 for the record

Thanks. Works fine on both fedora-32-minimal and fedora-32-standard (see above link). Would need more information about the system where it fails.

comment:135 Changed 2 years ago by vbraun

  • Status changed from positive_review to needs_work

Still doesn't work. My build log has a

which: no gp in (/home/release/Sage/build/bin:/home/release/Sage/src/bin:/home/release/Sage/local/bin:/home/release/Sage/build/bin:/home/release/Sage/src/bin:/home/release/Sage/local/bin:/home/release/.local/bin:/home/release/opt/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/release/.composer/vendor/bin)
*WARNING*: Could not find gp --- will not be able to build new_data

thats not in yours; Build race with pari/gp? Seems like this would explain the error: 'GP' undeclared

comment:136 Changed 2 years ago by mkoeppe

Yes, seems like we may need to add pari as a dependency

comment:137 Changed 2 years ago by git

  • Commit changed from f522ea6aa29f068c3fe6b25847aadb431b5961d8 to 2e3dd4d90d6eaef23746891bd03230485d30e1e3

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

6173795Merge tag '9.2.beta7' into t/3360/sympow-2.23.2
2e3dd4dbuild/pkgs/sympow/dependencies: Add pari as an order-only dependency

comment:138 Changed 2 years ago by mkoeppe

  • Status changed from needs_work to needs_review

comment:139 Changed 2 years ago by vbraun

  • Branch changed from u/mkoeppe/sympow-2.23.2 to 2e3dd4d90d6eaef23746891bd03230485d30e1e3
  • Resolution set to fixed
  • Status changed from needs_review to closed
Note: See TracTickets for help on using tickets.