Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#29404 closed defect (fixed)

Fix build failures of pynac on macos with system python3

Reported by: Matthias Köppe Owned by:
Priority: blocker Milestone: sage-9.1
Component: packages: standard Keywords:
Cc: Dima Pasechnik, François Bissey, Vincent Delecroix, Julian Rüth, Isuru Fernando, Erik Bray Merged in:
Authors: Matthias Koeppe Reviewers: Dima Pasechnik
Report Upstream: Completely fixed; Fix reported upstream Work issues:
Branch: 7344e2d (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by Matthias Köppe)

https://github.com/mkoeppe/sage/runs/531095486

pynac:

checking whether sage-python23 version is >= 2.7... yes
checking for sage-python23 version... 3.7
checking for sage-python23 platform... darwin
checking for sage-python23 script directory... ${prefix}/lib/python3.7/site-packages
checking for sage-python23 extension module directory... ${exec_prefix}/lib/python3.7/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for python3.7... no
configure: error: Cannot find python3.7 in your system path

Fix in https://github.com/pynac/pynac/pull/351, https://github.com/mkoeppe/pynac/releases/tag/pynac-0.7.26.sage-2020-03-28

The "temporary upstream" tarball URL is in checksums.ini. To test the update on this branch: Use make SAGE_SPKG="sage-spkg -o" pynac-clean pynac; this will download the new upstream package automatically.

Attachments (1)

pynac-0.7.26.sage-2020-04-03.log (28.1 KB) - added by Dave Morris 2 years ago.
pynac did not download on Mac OS 10.15.3

Download all attachments as: .zip

Change History (77)

comment:1 Changed 3 years ago by Matthias Köppe

Cc: Dima Pasechnik added

pynac's python discovery should be fixed, this looks completely broken

comment:2 Changed 3 years ago by Matthias Köppe

Cc: François Bissey added
Summary: Fix build failures of pplpy on macos with system python3Fix build failures of pplpy and pynac on macos with system python3

comment:3 Changed 3 years ago by Dima Pasechnik

Cc: Vincent Delecroix added

This should be probably split into two tickets.

pplpy upstream is https://gitlab.com/videlec/pplpy - also in CC:

comment:4 Changed 3 years ago by François Bissey

Yes for the split. I am surprised that problem shows now in pynac. I would have expected it to happen much earlier. The AX_PYTHON_DEVEL macro is 5 years old - which probably doesn't help.

comment:5 Changed 3 years ago by François Bissey

Note that I don't think the problem is in the macro, but something in there may trigger. I suspect the problem is in AM_PATH_PYTHON and that PYTHON needs to be defined when calling configure in spkg-install.

comment:6 Changed 3 years ago by François Bissey

Which is already done. So I am not sure what happens to override it. Access to config.log would be helpful.

comment:7 Changed 3 years ago by Matthias Köppe

Yes, please go ahead with splitting the ticket.

comment:8 Changed 3 years ago by Dima Pasechnik

It looks from the log as here could be some mixing up happening between system python3 and Homebrew's python3 (unless Homebrew's python3 is using system's python3 headers by design).

comment:9 in reply to:  8 Changed 3 years ago by François Bissey

Replying to dimpase:

It looks from the log as here could be some mixing up happening between system python3 and Homebrew's python3 (unless Homebrew's python3 is using system's python3 headers by design).

Shouldn't happen. We pass PYTHON=sage-python23 explicitly to configure. That's what should be tested. https://github.com/sagemath/sage/blob/develop/build/pkgs/pynac/spkg-install.in#L14

My gut feeling is that something funny happened to that line during processing. But I need config.log to establish it.

comment:10 Changed 3 years ago by Dima Pasechnik

I don't have MacOS machine, but anyone with it may install Homebrew and try.

comment:11 Changed 3 years ago by François Bissey

It is more subtle than my implied gut feeling. The macro AX_PYTHON_DEVEL gets the right value for PYTHON and does its stuff based on that. I think AM_PATH_PYTHON doesn't like python with exotic names because it looks like it goes through a pre-defined list.

comment:12 Changed 3 years ago by Dima Pasechnik

isn't the location of Sage's Python exotic enough to choke it, if it were the case?

comment:13 Changed 3 years ago by François Bissey

It would be :)

Code inspection says I have it backwards. AM_PATH_PYTHON works and AX_PYTHON_DEVEL is the one failing.

comment:14 Changed 3 years ago by François Bissey

Toxic. This is with an old sage I have around

[pynac-0.7.14] checking whether sage-python23 version is >= 2.7... yes
[pynac-0.7.14] checking for sage-python23 version... 2.7
[pynac-0.7.14] checking for sage-python23 platform... linux2
[pynac-0.7.14] checking for sage-python23 script directory... ${prefix}/lib/python2.7/site-packages
[pynac-0.7.14] checking for sage-python23 extension module directory... ${exec_prefix}/lib/python2.7/site-packages
[pynac-0.7.14] checking for style of include used by make... GNU
[pynac-0.7.14] checking for gcc... gcc
[pynac-0.7.14] checking whether the C compiler works... yes
[pynac-0.7.14] checking for C compiler default output file name... a.out
[pynac-0.7.14] checking for suffix of executables... 
[pynac-0.7.14] checking whether we are cross compiling... no
[pynac-0.7.14] checking for suffix of object files... o
[pynac-0.7.14] checking whether we are using the GNU C compiler... yes
[pynac-0.7.14] checking whether gcc accepts -g... yes
[pynac-0.7.14] checking for gcc option to accept ISO C89... none needed
[pynac-0.7.14] checking whether gcc understands -c and -o together... yes
[pynac-0.7.14] checking dependency style of gcc... gcc3
[pynac-0.7.14] checking for python2.7... /home/fbissey/sagemath/sage/local/bin/python2.7
[pynac-0.7.14] checking for a version of Python >= '2.1.0'... yes
[pynac-0.7.14] checking for the distutils Python package... yes
[pynac-0.7.14] checking for Python include path... -I/home/fbissey/sagemath/sage/local/include/python2.7
[pynac-0.7.14] checking for Python library path... -L/home/fbissey/sagemath/sage/local/lib -lpython2.7
[pynac-0.7.14] checking for Python site-packages path... /home/fbissey/sagemath/sage/local/lib/python2.7/site-packages

As you can see, the first test (AM_PATH_PYTHON) use sage-python23 properly. But not the second that goes directly for pythonX.Y. Worse, that's by design of the macro.

	AC_PATH_PROG([PYTHON],[python[$PYTHON_VERSION]])
	if test -z "$PYTHON"; then
	   AC_MSG_ERROR([Cannot find python$PYTHON_VERSION in your system path])
	   PYTHON_VERSION=""
	fi

And for the cherry on the top of the cake, I believe PYTHON_VERSION is set by AM_PATH_PYTHON. Conclusion AX_PYTHON_DEVEL doesn't do exotic python name, and you better have a regular python executable in the PATH. Now, I'd like to know more about that setup that has sage-python23 in the PATH but not the matching pythonX.Y. Did something happen while I wasn't looking?

comment:15 Changed 3 years ago by François Bissey

Updating AX_PYTHON_DEVEL would still give the same result. There is probably something smarter to do.

comment:16 Changed 3 years ago by François Bissey

All the stuff found by AX_PYTHON_DEVEL could be found by snipping bits of it and using the results from AM_PATH_PYTHON. This is a substantial rewrite of upstream's configure.ac that we are looking at. We only need to lift the bits that figure PYTHON_CPPFLAGS and PYTHON_LDFLAGS (PYTHON_LIBS if lifted from the latest version of AX_PYTHON_DEVEL). The rest is provided by AM_PATH_PYTHON.

comment:17 in reply to:  4 Changed 3 years ago by Matthias Köppe

Replying to fbissey:

Yes for the split. I am surprised that problem shows now in pynac. I would have expected it to happen much earlier. The AX_PYTHON_DEVEL macro is 5 years old - which probably doesn't help.

It shows now because this is a test with system python3 (#27824) instead of building sage's own python3. On macOS, there is /usr/bin/python3 (which is Python 3.7) but no /usr/bin/python3.7.

comment:18 Changed 3 years ago by Dima Pasechnik

would it work with Homebrew's python3 ? https://formulae.brew.sh/formula/python

Python shipped with MacOS is dodgy, IMHO.

comment:19 in reply to:  16 Changed 3 years ago by Matthias Köppe

Replying to fbissey:

All the stuff found by AX_PYTHON_DEVEL could be found by snipping bits of it and using the results from AM_PATH_PYTHON. This is a substantial rewrite of upstream's configure.ac that we are looking at. We only need to lift the bits that figure PYTHON_CPPFLAGS and PYTHON_LDFLAGS (PYTHON_LIBS if lifted from the latest version of AX_PYTHON_DEVEL). The rest is provided by AM_PATH_PYTHON.

Yes, this sounds like the correct approach.

comment:20 Changed 3 years ago by Matthias Köppe

Description: modified (diff)
Summary: Fix build failures of pplpy and pynac on macos with system python3Fix build failures of pynac on macos with system python3

comment:21 in reply to:  3 Changed 3 years ago by Matthias Köppe

Replying to dimpase:

This should be probably split into two tickets.

pplpy upstream is https://gitlab.com/videlec/pplpy - also in CC:

pplpy is now #29408

comment:23 Changed 3 years ago by Dima Pasechnik

probably we should try replacement using python-config- except that the name should not start with AC_...

comment:24 Changed 3 years ago by Matthias Köppe

... and except that we do not have sage-python23-config

comment:25 Changed 3 years ago by François Bissey

In the same bag, you could be tempted to use python-X.Y.pc, AM_PATH_PYTHON identifies the python version correctly. I eliminated it from my solutions yesterday but that may be viable if it is shipped consistently. If not, the AX_PYTHON_DEVEL macro just runs python commands to get at sysconfig. It is a fairly valid strategy.

comment:26 Changed 3 years ago by Matthias Köppe

No python pkgconfig on macOS without homebrew

comment:27 Changed 3 years ago by François Bissey

Keep forgetting about that.

comment:28 Changed 3 years ago by François Bissey

And on my mac I have python3 but not python-config for it, just python 2.7. So Mac support (without homebrew) needs to probe the python interpreter directly - at the time of writing.

comment:29 Changed 3 years ago by Dima Pasechnik

let us try with Homebrew Python first. One can always add moar insanity later

comment:30 Changed 3 years ago by François Bissey

That's the path of less resistance but I consider AX_PYTHON_DEVEL broken (including the latest one) and in need of replacement.

comment:31 in reply to:  29 Changed 3 years ago by Matthias Köppe

Replying to dimpase:

let us try with Homebrew Python first. One can always add moar insanity later

Nothing try here. We already know precisely how it fails and what needs fixing: the use of that macro.

comment:32 Changed 3 years ago by Matthias Köppe

Cc: Julian Rüth Isuru Fernando added

comment:33 Changed 2 years ago by Matthias Köppe

I have a first version of a patch for pynac at https://github.com/pynac/pynac/pull/351

comment:34 Changed 2 years ago by Matthias Köppe

Branch: u/mkoeppe/fix_build_failures_of_pynac_on_macos_with_system_python3

comment:35 Changed 2 years ago by Matthias Köppe

Authors: Matthias Koeppe
Commit: c97807a2131a7c3d00db3451c18b1bfdfdbe95cd
Report Upstream: N/ACompletely fixed; Fix reported upstream

New commits:

c97807abuild/pkgs/pynac: Use 0.7.26.sage-2020-03-28

comment:36 Changed 2 years ago by Matthias Köppe

Description: modified (diff)
Status: newneeds_review

comment:37 Changed 2 years ago by Isuru Fernando

Status: needs_reviewneeds_work

You shouldn't link to the shared python library. If you do, you'll run into https://github.com/pynac/pynac/issues/337

comment:38 Changed 2 years ago by Matthias Köppe

Help with this is very welcome! I have to work on something else this weekend

comment:39 Changed 2 years ago by git

Commit: c97807a2131a7c3d00db3451c18b1bfdfdbe95cd6f2b3362bf0fe885916f7a233c1bb2cac7100186

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

6f2b336build/pkgs/pynac: Use 0.7.26.sage-2020-03-28a

comment:40 Changed 2 years ago by Matthias Köppe

Found a moment for this after all

comment:41 Changed 2 years ago by Matthias Köppe

Status: needs_workneeds_review

comment:43 Changed 2 years ago by Matthias Köppe

Priority: majorcritical

This seems to work well according to the tests. Needs review!

comment:44 Changed 2 years ago by Dima Pasechnik

Status: needs_reviewneeds_work

scipy build in macos-homebrew-standard fails with a similar error:

2020-03-29T03:07:22.1134510Z     g++ -sdk macosx clang -bundle -undefined dynamic_lookup -bundle -undefined dynamic_lookup -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/lib -D__ACCELERATE__ -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/include -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/include build/temp.macosx-10.14-x86_64-3.7/scipy/interpolate/src/_interpolate.o -Lbuild/temp.macosx-10.14-x86_64-3.7 -o build/lib.macosx-10.14-x86_64-3.7/scipy/interpolate/_interpolate.cpython-37m-darwin.so
2020-03-29T03:07:22.1135020Z     clang: error: unknown argument: '-sdk'
2020-03-29T03:07:22.1135400Z     clang: error: no such file or directory: 'macosx'
2020-03-29T03:07:22.1135790Z     clang: error: no such file or directory: 'clang'
2020-03-29T03:07:22.1137100Z     error: Command "g++ -sdk macosx clang -bundle -undefined dynamic_lookup -bundle -undefined dynamic_lookup -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/lib -D__ACCELERATE__ -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/include -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/include build/temp.macosx-10.14-x86_64-3.7/scipy/interpolate/src/_interpolate.o -Lbuild/temp.macosx-10.14-x86_64-3.7 -o build/lib.macosx-10.14-x86_64-3.7/scipy/interpolate/_interpolate.cpython-37m-darwin.so" failed with exit status 1
2020-03-29T03:07:22.1137680Z     Running setup.py install for scipy: finished with status 'error'

comment:45 in reply to:  44 Changed 2 years ago by Matthias Köppe

Status: needs_workneeds_review

Replying to dimpase:

scipy build in macos-homebrew-standard fails with a similar error

Wrong ticket, that's #29408.

comment:46 Changed 2 years ago by Dima Pasechnik

what do you mean, wrong ticket? I looked at the test results at comment:42 above (https://github.com/mkoeppe/sage/actions/runs/65556636)

comment:47 Changed 2 years ago by Matthias Köppe

This ticket is about pynac failing with configure: error: Cannot find python3.7 in your system path.

comment:48 Changed 2 years ago by Dima Pasechnik

Reviewers: Dima Pasechnik
Status: needs_reviewpositive_review

OK, this looks good. Sorry for confusion.

comment:49 Changed 2 years ago by Isuru Fernando

Status: positive_reviewneeds_work

Thanks for looking into this. This needs more work due to https://github.com/pynac/pynac/pull/351#discussion_r399846249.

comment:50 Changed 2 years ago by Matthias Köppe

Whether this is good enough for upstream is another question - and one that will not be answered soon. But the fix works for us.

comment:51 Changed 2 years ago by Isuru Fernando

Does it though? I assume that warning gets triggered in osx system python.

comment:52 Changed 2 years ago by Matthias Köppe

This is using the version with assert, and it's not failing. See logs above.

comment:53 Changed 2 years ago by Isuru Fernando

Status: needs_workpositive_review

I don't understand how it's going to work, but not going to hold up this ticket.

comment:54 in reply to:  53 Changed 2 years ago by Matthias Köppe

Replying to isuruf:

I don't understand how it's going to work

Just in case you'd like another look, here's the log from https://github.com/mkoeppe/sage/actions/runs/66127777, logs-commit-3fc71b184bd15f5b10e48334eccb73be63dd3033-tox-local-homebrew-macos-standard.zip . Note that this is NOT using the change from #29408.

pynac-0.7.26.sage-2020-03-28a
====================================================
Setting up build directory for pynac-0.7.26.sage-2020-03-28a
Finished extraction
No patch files found in ../patches
****************************************************
Host system:
Darwin Mac-1306.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64
****************************************************
C compiler: x86_64-apple-darwin13.4.0-clang
C compiler version:
clang version 9.0.1 
Target: x86_64-apple-darwin13.4.0
Thread model: posix
InstalledDir: /Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/bin
****************************************************
Package 'pynac' is currently not installed
No legacy uninstaller found for 'pynac'; nothing to do
Starting build...
Running build_pynac...
Configuring pynac-0.7.26.sage-2020-03-28a
...
checking whether sage-python23 version is >= 2.7... yes
checking for sage-python23 version... 3.7
checking for sage-python23 platform... darwin
checking for sage-python23 script directory... ${prefix}/lib/python3.7/site-packages
checking for sage-python23 extension module directory... ${exec_prefix}/lib/python3.7/site-packages
checking for Python preprocessor flags... -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/include/python3.7m -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/include/python3.7m -fno-strict-aliasing -Wsign-compare -Wunreachable-code -DNDEBUG -fwrapv -O3 -Wall -Wstrict-prototypes -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O3 -pipe -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda=/usr/local/src/conda-prefix -flto -Wl,-export_dynamic -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O3
checking for Python library flags... -bundle -undefined dynamic_lookup -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -flto -Wl,-export_dynamic -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/local/lib -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/local/lib -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/lib -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/include -D_FORTIFY_SOURCE=2 -mmacosx-version-min=10.9 -isystem /Users/runner/runners/2.165.2/work/sage/sage/.tox/local-conda-forge-macos-standard/conda/include
checking build system type... x86_64-apple-darwin19.3.0

comment:55 Changed 2 years ago by Matthias Köppe

Fails on cygwin (https://github.com/mkoeppe/sage/runs/548082943):

  [pynac-0.7.26.sage-2020-03-28a]   /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac-0.7.26.sage-2020-03-28a/src/ginac/numeric.cpp:175: undefined reference to `PyErr_Occurred'
  [pynac-0.7.26.sage-2020-03-28a]   /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: .libs/libpynac_la-numeric.o:/cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac-0.7.26.sage-2020-03-28a/src/ginac/numeric.cpp:502: undefined reference to `PyLong_FromLong'
  [pynac-0.7.26.sage-2020-03-28a]   /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: .libs/libpynac_la-numeric.o: in function `__static_initialization_and_destruction_0':
  [pynac-0.7.26.sage-2020-03-28a]   /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac-0.7.26.sage-2020-03-28a/src/ginac/numeric.cpp:503: undefined reference to `PyLong_FromLong'
  [pynac-0.7.26.sage-2020-03-28a]   /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: /cygdrive/d/a/sage/sage/local/var/tmp/sage/build/pynac-0.7.26.sage-2020-03-28a/src/ginac/numeric.cpp:504: undefined reference to `PyLong_FromLong'
  [pynac-0.7.26.sage-2020-03-28a]   collect2: error: ld returned 1 exit status
  [pynac-0.7.26.sage-2020-03-28a]   make[6]: *** [Makefile:558: libpynac.la] Error 1

comment:56 Changed 2 years ago by Matthias Köppe

Cc: Erik Bray added

comment:57 Changed 2 years ago by Matthias Köppe

Status: positive_reviewneeds_work

comment:58 Changed 2 years ago by git

Commit: 6f2b3362bf0fe885916f7a233c1bb2cac7100186db5074a5487edaa6ce153d5a7812387539fc8c7a

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

db5074aUse pynac-0.7.26.sage-2020-03-31a

comment:59 Changed 2 years ago by Matthias Köppe

Status: needs_workneeds_review

comment:60 Changed 2 years ago by Matthias Köppe

Status: needs_reviewneeds_work

comment:61 Changed 2 years ago by git

Commit: db5074a5487edaa6ce153d5a7812387539fc8c7adeb717fb4c53b2851a04fff610f98ca0ff80f84a

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

cb15a59Use pynac-0.7.26.sage-2020-04-02
deb717fuse pynac-0.7.26.sage-2020-04-03

comment:62 Changed 2 years ago by Matthias Köppe

Status: needs_workneeds_review

This fixes the build on cygwin.

comment:63 Changed 2 years ago by Dima Pasechnik

please squash the commits

comment:64 Changed 2 years ago by git

Commit: deb717fb4c53b2851a04fff610f98ca0ff80f84a7344e2df8bebecdab19924a14ff4dbe51cc514f9

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

7344e2dUse temporary upstream version pynac-0.7.26.sage-2020-04-03

comment:65 Changed 2 years ago by Matthias Köppe

squashed, needs review

comment:66 Changed 2 years ago by Matthias Köppe

comment:67 Changed 2 years ago by John Palmieri

It's good on OS X, built with various different Pythons (homebrew, system, Sage).

comment:68 Changed 2 years ago by Matthias Köppe

Let's get this one into the next beta please

comment:69 Changed 2 years ago by Dima Pasechnik

Status: needs_reviewpositive_review

looks good.

comment:70 Changed 2 years ago by Matthias Köppe

Thanks!

comment:71 Changed 2 years ago by Matthias Köppe

Priority: criticalblocker

Changed 2 years ago by Dave Morris

pynac did not download on Mac OS 10.15.3

comment:72 Changed 2 years ago by Dave Morris

I apologize if this is noise (I may have messed up my installation somehow), but I thought I should report that I had trouble building pynac in 9.1rc0 on Mac OS 10.15.3, even with this ticket:

Attempting to download from https://github.com/mkoeppe/pynac/releases/download/pynac-0.7.26.sage-2020-04-03/pynac-0.7.26.sage-2020-04-03.tar.bz2
[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
ERROR [transfer|run:135]: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)
************************************************************************

I merged #29408 and this ticket, and ran make build, then realized that the description of this ticket has a different make command, so I tried that, too. But pynac did not download. I am attaching the pynac-0.7.26.sage-2020-04-03.log log file from the more complicated build command, in case it is of use.

The build went smoothly after I manually downloaded pynac and put it in the upstream directory, so I want to say thanks for these patches! I never would have figured out how to fix the build errors on my own.

comment:73 Changed 2 years ago by Dima Pasechnik

this might be due to (system) python, more precisely its urllib module, being unable to provide correct certs...

does installing python 3.7 from python.org and also making sure it installs certs (there is a 2nd step in installation, iirc) fixes this?

comment:74 Changed 2 years ago by Dave Morris

Yes, that solved the problem. After installing python and certifi, pynac downloaded from mkoeppe's directory (and the build succeeded) when I used make SAGE_SPKG="sage-spkg -o" pynac-clean pynac. Thanks!

comment:75 Changed 2 years ago by Volker Braun

Branch: u/mkoeppe/fix_build_failures_of_pynac_on_macos_with_system_python37344e2df8bebecdab19924a14ff4dbe51cc514f9
Resolution: fixed
Status: positive_reviewclosed

comment:76 Changed 2 years ago by Matthias Köppe

Commit: 7344e2df8bebecdab19924a14ff4dbe51cc514f9

Follow up: #29872

Note: See TracTickets for help on using tickets.