Fixes for the conda-for-Sage-developers installation method, add GH Actions workflow

[mkoeppe]

Add github action workflow that checks the build of sage in a conda environment, completely bypassing the installation of any sage package. This is based on the steps outlined at ​https://wiki.sagemath.org/Conda.

This also tests that the generated src/environment*.yml files work correctly. (See documentation added in #28745)

Run: ​https://github.com/sagemath/sagetrac-mirror/actions/workflows/ci-conda.yml

Fixes:

• #33330: primecountpy is not installed in the conda env because its not listed in environment.yml
• environment-optional: lcalc 1 is installed and then not recognized / leads to error

  building 'sage.libs.lcalc.lcalc_Lfunction' extension
      cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
      In file included from sage/libs/lcalc/lcalc_Lfunction.cpp:740:
      sage/libs/lcalc/lcalc_sage.h:1:10: fatal error: lcalc/L.h: No such file or directory
          1 | #include "lcalc/L.h"
            |          ^~~~~~~~~~~
      compilation terminated.
  

• environment-optional: probably related, pari 2.11.4 is installed by conda instead of the newest 2.13.2. This version is then rejected by configure as being too old.
• Disable conda distro information for gdb because it is broken on macOS.
• Add conda distro information for lrcalc_python
• Filter out conda-specific ld warnings in doctests
• In the feature test for sage_spkg, check whether any Sage packages are actually installed
• Include an upper version bound for ptyprocess in sagemath-standard's install-requires

Follow-ups: See Meta-ticket #33331

[mkoeppe]

Hoping we can make progress on this ticket this week - ​https://wiki.sagemath.org/days111

[gh-tobiasdiez]

Something like ​https://github.com/tobiasdiez/sage/blob/public/build/conda_gh/.github/workflows/ci-conda.yml?

This currently fails with

configure: creating ./config.status
config.status: creating build/make/Makefile-auto
config.status: creating build/make/Makefile
config.status: creating src/bin/sage-env-config
config.status: creating src/bin/sage-src-env-config
config.status: creating build/bin/sage-build-env-config
config.status: creating build/pkgs/sage_conf/src/sage_conf.py
config.status: creating build/pkgs/sage_conf/src/setup.cfg
config.status: executing depfiles commands
config.status: executing mkdirs commands
config.status: creating directory /home/runner/work/sage/sage/logs/pkgs
config.status: creating directory 
mkdir: cannot create directory '': No such file or directory
config.status: error: could not create 
Error: Process completed with exit code 1.

​https://github.com/tobiasdiez/sage/runs/1594237745?check_suite_focus=true Any idea what could be the reason and how to fix it?

[gh-tobiasdiez]

New commits:

​c68d262	Add first version of workflow
​9af4614	Try with sudo (why is this needed now?!)

[git]

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

​5ac74ee	Try with conda-incubator
​a178b56	Run in the conda shell

[git]

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

​199886c	Install more conda dependencies
​10de3f5	Fix conda env name
​86411b8	Remove unnececesary install of conda dep

[gh-tobiasdiez]

Managed to fix the above error, just to be stuck two lines further down:

configure: creating ./config.status
config.status: creating build/make/Makefile-auto
config.status: creating build/make/Makefile
config.status: creating src/bin/sage-env-config
config.status: creating src/bin/sage-src-env-config
config.status: creating build/bin/sage-build-env-config
config.status: creating build/pkgs/sage_conf/src/sage_conf.py
config.status: creating build/pkgs/sage_conf/src/setup.cfg
config.status: executing depfiles commands
config.status: executing broken-gcc commands
config.status: executing mkdirs commands
config.status: creating directory /home/runner/work/sage/sage/logs/pkgs
config.status: creating directory /usr/share/miniconda/envs/sage-build
config.status: creating directory /usr/share/miniconda/envs/sage-build/bin
config.status: creating directory /usr/share/miniconda/envs/sage-build/etc
config.status: creating directory /usr/share/miniconda/envs/sage-build/include
config.status: creating directory /usr/share/miniconda/envs/sage-build/lib
config.status: creating directory /usr/share/miniconda/envs/sage-build/lib/pkgconfig
config.status: creating directory /usr/share/miniconda/envs/sage-build/share
config.status: creating directory /usr/share/miniconda/envs/sage-build/var/lib/sage/installed
config.status: error: Cannot perform incremental update, run "make distclean && make"
config.status: /usr/share/miniconda/envs/sage-build/lib64 is not a symlink, see Trac #19782
Error: Process completed with exit code 1.

​https://github.com/tobiasdiez/sage/runs/1594601374?check_suite_focus=true

[gh-tobiasdiez]

Found a hack that fixed it by removing the lib64 folder. It only contained libcc1.so (not sure where/how this is needed).

[gh-tobiasdiez]

Made a bit more progress, but it currently errors while compiling gcc. Moreover, there is a problem in the detection of the conda/system gcc because "sage-env-config" doesn't exist. ​https://github.com/tobiasdiez/sage/runs/1594867631?check_suite_focus=true

[git]

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

​53503dc	Try remove lib64 folder by hand
​e530ac0	Add c++ compiler to conda
​ab47f5e	Install directly on top of conda
​741c55a	Make autogen work

[mkoeppe]

The direct variant should use src/environment.yml - which installs the Python packages of Sage in addition to what is listed in environment.yml

[mkoeppe]

The lib64 looks like a conda packaging bug to me - @isuruf, can you help?

[mkoeppe]

environment.yml already includes compilers -- I don't think adding cxx-compiler should be necessary

[git]

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

​1231a24	Add env logging and fix SAGE_SRC
​be024f8	Fix build
​8a46d04	Improve output of print_env
​9802c56	Improve print statement
​3aba048	Use correct conda env file

[mkoeppe]

Replying to gh-tobiasdiez:

Made a bit more progress, but it currently errors while compiling gcc. Moreover, there is a problem in the detection of the conda/system gcc because "sage-env-config" doesn't exist. ​https://github.com/tobiasdiez/sage/runs/1594867631?check_suite_focus=true

This is now #31097.

[isuruf]

I don't see a lib64 folder. Which package is that coming from?

[gh-tobiasdiez]

It contains libcc1.so so I guess gcc, g++ or some other compiler package.

[git]

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

​d853f14	Ok, then install setup.py relative to src
​cb5e284	Add tests
​1cf3de4	build/pkgs/gcc/spkg-configure.m4: Fix SAGE_BROKEN_GCC test
​1bc9c29	Merge branch 'u/mkoeppe/build_pkgs_gcc_spkg_configure_m4__fix_sage_broken_gcc_test' of git://trac.sagemath.org/sage into public/build/conda_gh
​c57d615	Correct bootstrap command
​e85f1ba	Fix venv config
​e29a9ab	Correct test command
​483de62	Install autotools
​8237b2c	Install gettext
​e9cb77b	Force configure to not install gcc

[gh-tobiasdiez]

Current status:

• Building sage using make on top of conda fails, since gcc is not found and the custom build of gcc fails.
• Installing sagelib on top of a conda works, but many doctests fail.

​https://github.com/sagemath/sagetrac-mirror/actions?query=workflow%3A%22Build+%26+Test+using+conda%22

I let somebody else with more experience in conda/the intricacies of sage's build system take over from here.

[mkoeppe]

Thanks for getting this started!

[mkoeppe]

Unfortunately the runs do not give the config.log

[mkoeppe]

Now I finally realize that for on-top-of-spkg you were trying to do ./configure --prefix=$CONDA_PREFIX -- that can't work.

[git]

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

​9857e36

Without the prefix

[git]

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

​b50ae6a

Remove conda gcc distro again

[git]

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

​68080fa

Cleanup workflow

[gh-tobiasdiez]

Replying to mkoeppe:

Now I finally realize that for on-top-of-spkg you were trying to do ./configure --prefix=$CONDA_PREFIX -- that can't work.

Thanks! Removing the prefix part indeed fixed the gcc issue. Now we are further in the build, and find this beautiful error:

2020-12-22T21:44:17.7966259Z [cvxopt-1.2.5]   x86_64-conda_cos6-linux-gnu-gcc -pthread -shared -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/usr/share/miniconda/envs/sage-build/lib -L/usr/share/miniconda/envs/sage-build/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/usr/share/miniconda/envs/sage-build/lib -L/usr/share/miniconda/envs/sage-build/lib -Wl,-rpath-link,/home/runner/work/sagetrac-mirror/sagetrac-mirror/local/lib -L/home/runner/work/sagetrac-mirror/sagetrac-mirror/local/lib -Wl,-rpath,/home/runner/work/sagetrac-mirror/sagetrac-mirror/local/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,-rpath,/usr/share/miniconda/envs/sage-build/lib -Wl,-rpath-link,/usr/share/miniconda/envs/sage-build/lib -L/usr/share/miniconda/envs/sage-build/lib -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /usr/share/miniconda/envs/sage-build/include -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /usr/share/miniconda/envs/sage-build/include build/temp.linux-x86_64-3.8/src/C/lapack.o -L/usr/share/miniconda/envs/sage-build/lib -lopenblas -lopenblas -o build/lib.linux-x86_64-3.8/cvxopt/lapack.cpython-38-x86_64-linux-gnu.so
2020-12-22T21:44:17.7974135Z [cvxopt-1.2.5]   building 'umfpack' extension
2020-12-22T21:44:17.7979362Z [cvxopt-1.2.5]   /usr/share/miniconda/envs/sage-build/bin/x86_64-conda-linux-gnu-cc -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O2 -Wall -Wstrict-prototypes -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /usr/share/miniconda/envs/sage-build/include -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /usr/share/miniconda/envs/sage-build/include -fPIC -I/usr/include -I/home/runner/work/sagetrac-mirror/sagetrac-mirror/local/include -I/usr/share/miniconda/envs/sage-build/include/python3.8 -c src/C/umfpack.c -o build/temp.linux-x86_64-3.8/src/C/umfpack.o
2020-12-22T21:44:17.7990748Z [cvxopt-1.2.5]   In file included from /usr/share/miniconda/envs/sage-build/include/python3.8/Python.h:11:0,
2020-12-22T21:44:17.7991831Z [cvxopt-1.2.5]                    from src/C/cvxopt.h:22,
2020-12-22T21:44:17.7992613Z [cvxopt-1.2.5]                    from src/C/umfpack.c:22:
2020-12-22T21:44:17.7993750Z [cvxopt-1.2.5]   /usr/include/limits.h:26:10: fatal error: bits/libc-header-start.h: No such file or directory
2020-12-22T21:44:17.7994924Z [cvxopt-1.2.5]    #include <bits/libc-header-start.h>
2020-12-22T21:44:17.7995741Z [cvxopt-1.2.5]             ^~~~~~~~~~~~~~~~~~~~~~~~~~
2020-12-22T21:44:17.7996470Z [cvxopt-1.2.5]   compilation terminated.
2020-12-22T21:44:17.7997728Z [cvxopt-1.2.5]   error: command '/usr/share/miniconda/envs/sage-build/bin/x86_64-conda-linux-gnu-cc' failed with exit status 1
2020-12-22T21:44:17.7999070Z [cvxopt-1.2.5]   Building wheel for cvxopt (setup.py): finished with status 'error'

Could this be related to the fact that libcc1 is installed in lib64?

[isuruf]

This is known. ​https://trac.sagemath.org/ticket/30710

[gh-tobiasdiez]

Ah thx for the pointer!

[gh-tobiasdiez]

I guess the main objective of this ticket was to add a workflow verifying that sagelib installed on top of conda works. Since this is accomplished, I'll put it as ready for review.

Fixing the doctests and the build using make can be done later (e.g by resolving #30710).

[mkoeppe]

As on-top-of-spkg turns out to be a variant of local-conda-forge-ubuntu-standard, I think I would want to implement this variant using tox.

[mkoeppe]

I have opened #31099 for this.

[gh-tobiasdiez]

Replying to mkoeppe:

As on-top-of-spkg turns out to be a variant of local-conda-forge-ubuntu-standard, I think I would want to implement this variant using tox.

I thought about using tox as well, but there are

a) problems setting up conda on github actions (this is why the workflow uses a special action for the conda setup)

b) difficulties with conda and tox environment interactions (which I guess are handled by the tox-conda plugin, but I didn't wanted to dive into this)

c) I still think tox is not the right tool for managing the user's environment beyond the Python environment.

[mkoeppe]

local-conda-forge-ubuntu-standard has been running for months on GH Actions, see for example ​https://github.com/sagemath/sage/runs/1553907433 for 9.3.beta4.

#31099 is just a matter of creating a variant that uses conda env create -f environment.yml instead of conda install ....

[chapoton]

red branch => needs work

[mkoeppe]

Moving this ticket to 9.4, as it seems unlikely that it will be merged in 9.3, which is in the release candidate stage

[git]

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

​103f78b

.github/workflows/ci-conda.yml: New

[mkoeppe]

I have reduced the branch to one of the jobs, direct, to remove the duplication with the existing workflows.

[mkoeppe]

Still needs updating to follow the steps of "Conda for Sage Developers" - ​https://wiki.sagemath.org/Conda - help welcome

[gh-tobiasdiez]

Last 10 new commits:

​65e1b49	Fix workflow syntax
​85c31c3	Make workflow at least try to compile sage
​fd484d8	Github needs sudo
​909cd9e	Add a few missing python packages
​a91da81	Run in parallel
​d4945e5	Install gap manually
​3171f82	Split in more jobs
​b87f2bc	Reuse existing bootstrap
​eec7abc	Delete env-python from gitignore again
​68e8330	Try with prefix instead of building ecl and gap

[gh-tobiasdiez]

Okay, this is now ready for review.

Any pointers to the two open issues are welcome. I looked for open tickets in these directions, but couldn't find one.

[git]

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

​b408f9e

Cleanup workflow

[mkoeppe]

In ​https://github.com/sagemath/sagetrac-mirror/runs/5146995129?check_suite_focus=true I see

I see

building 'sage.libs.lcalc.lcalc_Lfunction' extension
    cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
    In file included from sage/libs/lcalc/lcalc_Lfunction.cpp:740:
    sage/libs/lcalc/lcalc_sage.h:1:10: fatal error: lcalc/L.h: No such file or directory
        1 | #include "lcalc/L.h"
          |          ^~~~~~~~~~~
    compilation terminated.
    building 'sage.libs.libecm' extension

[gh-tobiasdiez]

Good observation. I think, however, this is not the reason why the build terminates as this error occurs somewhere in the middle (and I had similar error messages with gap before). I've added it to the list of "issues" in the ticket description.

[mkoeppe]

This is the reason for the failure. There's no mystery there.

[isuruf]

Do you get lcalc>=2 with conda?

[gh-tobiasdiez]

Replying to mkoeppe:

This is the reason for the failure. There's no mystery there.

Could be. But the point of this ticket is to add the github action, so that one can fix these issues in follow-up tickets and have a direct verification. It might take quite some time until this workflow is green, especially since there are probably quite a few tests that fail.

So except if you think that there is something fundamentally flawed with the current steps which result in the lcalc error, this should be ready for review.

[gh-tobiasdiez]

Replying to isuruf:

Do you get lcalc>=2 with conda?

Nope, its installing lcalc 1.23 h0d16fac_1004 conda-forge. That's probably the reason why its not working.

[mkoeppe]

So build/pkgs/lcalc/distros/conda.txt should be changed

[mkoeppe]

Replying to gh-tobiasdiez:

the point of this ticket is to add the github action

Well, it fails early, so we cannot see whether the later steps work.

[gh-tobiasdiez]

Replying to mkoeppe:

So build/pkgs/lcalc/distros/conda.txt should be changed

I don't think it will be that easy to solve:

mamba install lcalc=2.0.5 -n sage-dev
 > package libeantic-1.0.2-hf1f868f_1 requires antic >=0.2.4,<0.3.0a0, but none of the providers can be installed

mamba install libeantic=1.1.0 -n sage-dev
 > package libeantic-1.1.0-h52e3b27_0 requires arb >=2.21.1,<2.22.0a0, but none of the providers can be installed

mamba install arb=2.21.1 -n sage-dev
 > package e-antic-1.0.2-hf1f868f_0 requires arb >=2.19.0,<2.20.0a0, but none of the providers can be installed

I appears that there is a funny cyclic dependency thing going on.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

the point of this ticket is to add the github action

Well, it fails early, so we cannot see whether the later steps work.

Should I un-comment the last test step for now?

[mkoeppe]

Try switching from src/environment-optional.yml to src/environment.yml. e_antic is an optional package for Sage. Let's try without optional packages first.

[git]

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

​051b7b5

Don't use -optional env

[gh-tobiasdiez]

That should indeed work to get loalc 2.0.5. Good suggestion.

For the record: first installing environment.yml and then updating the env to environment-optional.yml yields the following downgrade of packgages:

  Downgrade:
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  - arb                                               2.22.1  hbbd85db_0              installed
  + arb                                               2.19.0  h7e34412_0              conda-forge/linux-64        7MB
  - boost-cpp                                         1.77.0  h359cf19_1              installed
  + boost-cpp                                         1.74.0  h312852a_4              conda-forge/linux-64     Cached
  - cvxopt                                             1.2.7  py310h9fd565e_1         installed
  + cvxopt                                             1.2.6  py38h55e5319_0          conda-forge/linux-64     Cached
  - cysignals                                         1.11.2  py310h15010d2_0         installed
  + cysignals                                         1.10.3  py38hd3cf888_0          conda-forge/linux-64     Cached
  - eclib                                           20210625  h52f5ea4_4              installed
  + eclib                                           20190909  h5b7fb09_3              conda-forge/linux-64       36MB
  - gap-core                                          4.11.1  h1725ef4_2              installed
  + gap-core                                          4.11.0  h1725ef4_7              conda-forge/linux-64       67MB
  - gap-defaults                                      4.11.1  ha770c72_2              installed
  + gap-defaults                                      4.11.0  ha770c72_7              conda-forge/linux-64       88MB
  - gsl                                                  2.7  he838d99_0              installed
  + gsl                                                  2.6  he838d99_2              conda-forge/linux-64     Cached
  - harfbuzz                                           3.3.1  hb4a5f5f_0              installed
  + harfbuzz                                           3.1.1  h83ec7ef_0              conda-forge/linux-64     Cached
  - icu                                                 69.1  h9c3ff4c_0              installed
  + icu                                                 68.2  h9c3ff4c_0              conda-forge/linux-64     Cached
  - lcalc                                              2.0.5  h8cd7e2e_0              installed
  + lcalc                                               1.23  h0d16fac_1004           conda-forge/linux-64     Cached
  - libclang                                          13.0.1  default_hc23dcda_0      installed
  + libclang                                          11.1.0  default_ha53f305_1      conda-forge/linux-64     Cached
  - libflint                                           2.8.4  hd3cd37b_ntl_100        installed
  + libflint                                           2.6.3  h6b702e8_0              conda-forge/linux-64       11MB
  - libpq                                               14.2  hd57d9b9_0              installed
  + libpq                                               13.5  hd57d9b9_1              conda-forge/linux-64     Cached
  - libuv                                             1.43.0  h7f98852_0              installed
  + libuv                                             1.42.0  h7f98852_0              conda-forge/linux-64     Cached
  - pari                                              2.13.3  h82e6b41_1_pthread      installed
  + pari                                              2.11.4  hddaffa3_2              conda-forge/linux-64     Cached
  - python                                            3.10.2  h85951f9_3_cpython      installed
  + python                                            3.8.12  ha38a3c6_3_cpython      conda-forge/linux-64     Cached
  - python_abi                                          3.10  2_cp310                 installed
  + python_abi                                           3.8  2_cp38                  conda-forge/linux-64     Cached
  - r-base                                             4.1.2  hde4fec0_0              installed
  + r-base                                             4.1.1  hb67fd72_0              conda-forge/linux-64     Cached
  - singular                                        4.2.1.p3  haca423c_0              installed
  + singular                                        4.1.1.p2  ha188dad_4              conda-forge/linux-64       22MB

[mkoeppe]

There must be some outdated pins / version constraints in the conda-forge packaging. Likely related to the fact that the Sage distribution has fallen behind upstream regarding e_antic/normaliz (see #31588).

[mkoeppe]

@isuruf, I think Sage works fine with current upstream versions of normaliz/pynormaliz that use the e_antic 1.x series, so it should be safe to remove such constraints. (We just can't yet update within the Sage distribution because of portability bugs in e_antic, see #31588.)

[mkoeppe]

Replying to mkoeppe:

So build/pkgs/lcalc/distros/conda.txt should be changed

... to say "lcalc >=2"

[mkoeppe]

Regarding the pari issue mentioned in the ticket description, we should probably use configure --with-system-pari=force so the error is signalled earlier

Let's also keep the instructions in ​https://wiki.sagemath.org/Conda updated.

[mkoeppe]

Oh, and configure --with-system-lcalc=force too...

[gh-tobiasdiez]

Replying to mkoeppe:

Regarding the pari issue mentioned in the ticket description, we should probably use configure --with-system-pari=force so the error is signalled earlier

Let's also keep the instructions in ​https://wiki.sagemath.org/Conda updated.

With the basic env, its now also using pari 2.13.3.

I guess some of the optional packages is lagging behind a bit and still requiring some older version of some package. This then leads to these various downgrades of arb, ecl, pari, lcalc etc

[mkoeppe]

Yes, and we are missing many of the version constraints that are in ​https://github.com/conda-forge/sage-feedstock/blob/master/recipe/meta.yaml

[mkoeppe]

Many of these should be added to the conda.txt files, so that they will be included in our src/environment*.yml.

[git]

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

​bd65274

Fix test command

[gh-tobiasdiez]

Okay, after using environment.yml the build now succeeds. The tests fail almost immediately at the import of sage.all, because primecountpy is not installed in the conda env (it is also in neither environment file).

I propose to get this ticket in and then work on the improvements to fix the various issues.

[mkoeppe]

Just add build/pkgs/primecountpy/distros/conda.txt

[mkoeppe]

At the current pace, it will take months before this ticket is merged. Little point in waiting for that to happen. There's a momentum now to fix it.

[mkoeppe]

comment:70, comment:71, comment:76, comment:82 are actionable

[mkoeppe]

Also, the ticket description claims that it follows ​https://wiki.sagemath.org/Conda; but that uses pip install -r src/requirements.txt, which would install the missing primecountpy too.

[isuruf]

It's better to not use pip.

[gh-tobiasdiez]

Replying to mkoeppe:

At the current pace, it will take months before this ticket is merged. Little point in waiting for that to happen. There's a momentum now to fix it.

That's sadly true, but follow-up tickets can easily depend on this ticket here to run the CI.

[gh-tobiasdiez]

Replying to mkoeppe:

Oh, and configure --with-system-lcalc=force too...

Do you really think we should add a --with-system-xyz=force for every system package?

[mkoeppe]

I don't have a better solution at the moment, but at least there's a reasonably short way to write it as configure --with-system-{gcc,lcalc}=force...

[mkoeppe]

Or generate it as $(for pkg in $(./sage -package list :standard: --has-file spkg-configure.m4); do echo --with-system-$pkg=force; done)

[isuruf]

Why do you need --with-system-lcalc=force?

[mkoeppe]

So that it is an immediate error if the system package is not usable. Here we are testing the workflow that does not run make at all.

[gh-tobiasdiez]

Replying to mkoeppe:

Or generate it as $(for pkg in $(./sage -package list :standard: --has-file spkg-configure.m4); do echo --with-system-$pkg=force; done)

But doesn't this trigger errors as soon as a system package is rejected? That currently happens with a lot of packages as you can see in the github workflow.

Moreover, we have complete control over which versions we install in the conda systems, so one could actually skip the whole system check that ̀ configure` currently performs.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Or generate it as $(for pkg in $(./sage -package list :standard: --has-file spkg-configure.m4); do echo --with-system-$pkg=force; done)

But doesn't this trigger errors as soon as a system package is rejected? That currently happens with a lot of packages as you can see in the github workflow.

Yes, that's the idea. For packages that have an spkg-configure.m4, our configure script knows which versions work. It should fail early if there is something that cannot be accepted.

[mkoeppe]

Replying to gh-tobiasdiez:

Moreover, we have complete control over which versions we install in the conda systems, so one could actually skip the whole system check that ̀ configure` currently performs.

That is something that is best left to the downstream packagers.

[mkoeppe]

Replying to gh-tobiasdiez:

That currently happens with a lot of packages as you can see in the github workflow.

python3 is rejected because your script doesn't follow the instructions at ​https://wiki.sagemath.org/Conda - --with-python=$CONDA_PREFIX/bin/python is missing.

[mkoeppe]

And many others fail because you use --without-system-gcc, which is a bad idea.

[git]

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

​8a297af

Remove without gcc, add with python

[gh-tobiasdiez]

Replying to mkoeppe:

And many others fail because you use --without-system-gcc, which is a bad idea.

Otherwise configure fails with

 configure: error: 

    Given --with-system-gcc=force, but no system package could be used.
    That's an error.  Please install the indicated package to continue.
    (To override this error, use ./configure --without-system-gcc)

[git]

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

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Moreover, we have complete control over which versions we install in the conda systems, so one could actually skip the whole system check that ̀ configure` currently performs.

That is something that is best left to the downstream packagers.

The section has the title "Conda for Sage Developers" so downstream packagers are not involved here.

[gh-tobiasdiez]

Replying to mkoeppe:

Just add build/pkgs/primecountpy/distros/conda.txt

This is now #33330.

[dimpase]

I undestand that the GH run on #33330 uses this branch, so it looks good to me.

[gh-tobiasdiez]

Also here, thanks for the review.

[gh-tobiasdiez]

I've now created #33331 for the follow-up issues.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Moreover, we have complete control over which versions we install in the conda systems, so one could actually skip the whole system check that ̀ configure` currently performs.

That is something that is best left to the downstream packagers.

The section has the title "Conda for Sage Developers" so downstream packagers are not involved here.

Exactly, so in other words we should not attempt to skip configure's checks.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

And many others fail because you use --without-system-gcc, which is a bad idea.

Otherwise configure fails with

 configure: error: 

    Given --with-system-gcc=force, but no system package could be used.
    That's an error.  Please install the indicated package to continue.
    (To override this error, use ./configure --without-system-gcc)

Why does it reject gcc?

[mkoeppe]

comment:98 still unaddressed

[dimpase]

Replying to mkoeppe:

comment:98 still unaddressed

It is addressed in comment:100 (commit ​8a297af), no?

[mkoeppe]

That commit is not on the current branch

[gh-tobiasdiez]

Yes, I had to revert that commit since the workflow didn't passed. ​https://github.com/sagemath/sagetrac-mirror/actions/runs/1836383017

That conda's python is rejected is #31539. And since sage is not invoking python during the workflow run, it also shouldn't matter if its rejected or not.

[mkoeppe]

That failure was from gcc, not python. So why back out the fix for python?

[mkoeppe]

Replying to gh-tobiasdiez:

since sage is not invoking python during the workflow run

Hm?

[gh-tobiasdiez]

Replying to mkoeppe:

That failure was from gcc, not python. So why back out the fix for python?

Since it is working without this "fix".

[mkoeppe]

Also, could you please add some steps that package up the logs, like the three last steps of local-ubuntu in tox.yml?

Right now we cannot see what went wrong in the gcc detection, as we cannot see config.log

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

That failure was from gcc, not python. So why back out the fix for python?

Since it is working without this "fix".

But what does it test? Currently certainly not installation steps that we could recommend to developers. The configure run should really reflect the system configuration.

[git]

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

​3e49a2e	Merge branch 'develop' of https://github.com/sagemath/sage into public/build/conda-runci
​c1423cd	Force python
​7b76d0b	Print logs

[gh-tobiasdiez]

Replying to mkoeppe:

Also, could you please add some steps that package up the logs, like the three last steps of local-ubuntu in tox.yml?

Right now we cannot see what went wrong in the gcc detection, as we cannot see config.log

Done.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

That failure was from gcc, not python. So why back out the fix for python?

Since it is working without this "fix".

But what does it test? Currently certainly not installation steps that we could recommend to developers. The configure run should really reflect the system configuration.

I still don't understand why it's so important that sage's configure script accepts conda's python, but I've added the explicit --with-python argument.

[dimpase]

I still don't understand why it's so important that sage's configure script accepts conda's python

How else would you expect to be using Conda's Python packages in Sage, if you used another Python?

[gh-tobiasdiez]

The workflow is completely bypassing the make-scripts of sage. So using Conda's python packages follows the 'usual' strategy:

• Create (virtual) python environment (done by conda)
• Install other python packages (done by conda)
• Install sagelib into the same environment (done via pip install)

So sage is not managing the python installation nor the python environment. It is simply a normal python package that gets installed in an existing environment. In this context, it is pretty non-standard to pose more requirements at the python installation then a simple version requirement (which is checked by pip). Ideally, you wouldn't even want to call configure, a simple pip install -e src should be enough (and that's for example the workflow numpy and scipy are using), but that's of course currently not possible.

[dimpase]

OK, but note that ./bootstrap and ./configure still need to be run to install various things and fill in *.in templates. Passing wrong parameters to ./configure is not a good idea, IMHO.

[mkoeppe]

Replying to gh-tobiasdiez:

Since it is working without this "fix".

But what does it test? Currently certainly not installation steps that we could recommend to developers. The configure run should really reflect the system configuration.

I still don't understand why it's so important that sage's configure script accepts conda's python

As I said before in comment:70, comment:92, etc., the configure script should really be invoked with --with-system-xyz=force for all packages for which we have spkg-configure.m4.

[mkoeppe]

Replying to mkoeppe:

• Documentation doesn't mention the use of --prefix=$CONDA_PREFIX (without this things like ecl-config are not found)

For example, this one about ecl-config is the result of the misconfiguration. The configure script does not accept system ecl because of the misconfiguration --without-system-gcc. So the configuration reflects use of an ECL built using SPKG (which is not done because make is not involved).

[gh-tobiasdiez]

Replying to dimpase:

OK, but note that ./bootstrap and ./configure still need to be run to install various things and fill in *.in templates. Passing wrong parameters to ./configure is not a good idea, IMHO.

Sure, I agree with this!

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Since it is working without this "fix".

But what does it test? Currently certainly not installation steps that we could recommend to developers. The configure run should really reflect the system configuration.

I still don't understand why it's so important that sage's configure script accepts conda's python

As I said before in comment:70, comment:92, etc., the configure script should really be invoked with --with-system-xyz=force for all packages for which we have spkg-configure.m4.

Not sure if that's really a good idea or if it would be better to just exclude versions of conda packages that are known to not work. But regardless, adding these force statements doesn't currently work.

[mkoeppe]

Replying to gh-tobiasdiez:

adding these force statements doesn't currently work.

You reported that --with-system-gcc=force does not work; what else does not work?

[mkoeppe]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

adding these force statements doesn't currently work.

You reported that --with-system-gcc=force does not work

... and we can fix it if you show us the config.log

[gh-tobiasdiez]

I didn't check the force argument, but ecl, arb, ntl, ppl are not recognized.

[mkoeppe]

yes, because of the misconfigured gcc (I just explained it in comment:130)

[mkoeppe]

Replying to gh-tobiasdiez:

the configure script should really be invoked with --with-system-xyz=force for all packages for which we have spkg-configure.m4.

Not sure if that's really a good idea or if it would be better to just exclude versions of conda packages that are known to not work.

Both.

[git]

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

​9af27b5

Fix log output

[git]

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

​5940d76

Try again with system gcc

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

the configure script should really be invoked with --with-system-xyz=force for all packages for which we have spkg-configure.m4.

Not sure if that's really a good idea or if it would be better to just exclude versions of conda packages that are known to not work.

Both.

What's the point of the force except that the workflow fails early? Wouldn't it make more sense to let it run through and see what error it produces?

[mkoeppe]

Replying to gh-tobiasdiez:

What's the point of the force except that the workflow fails early?

Failing early is good.

Wouldn't it make more sense to let it run through and see what error it produces?

No, because we do not want to send developers to manually diagnose build or run problems that have already been diagnosed and codified in our configure tests.

[gh-tobiasdiez]

Replying to git:

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

​5940d76

Try again with system gcc

Locally this fails, output can be found at ​https://github.com/sagemath/sagetrac-mirror/runs/5189468934?check_suite_focus=true in a bit.

It accepts the conda gcc if I remove the --prefix=$CONDA_PREFIX part. But then a few other packages are still not properly recognized: ecl bdw-gc libhomfly (which was the reason why I added the prefix in the first place). Nothing of this is specific to the github action and can easily be investigated after creating a conda env locally.

But can we do this error analysis and corresponding improvements please in a follow-up ticket? The version using prefix works with almost no test failures (apart from giac, which is broken and has already a ticket). Moreover, in this ticket, I tried to codify the instructions of the wiki in a github workflow. The instructions didn't work for me verbatim in a fresh clone, nor via the github action. The current version works relatively well in my eyes. I'm happy to try a different combination of commands, but then please check yourself that these work locally for you.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

What's the point of the force except that the workflow fails early?

Failing early is good.

Wouldn't it make more sense to let it run through and see what error it produces?

No, because we do not want to send developers to manually diagnose build or run problems that have already been diagnosed and codified in our configure tests.

What about adding a warning annotation in the github workflow when a system package is not recognized? Then you still get the information that the config didn't work as expected but keep the benefit of seeing error messages. This should become helpful down the road, as the conda packages are quite up to date and thus may fail to be recognized for the simple reason that they are too new.

[mkoeppe]

comment:121 - the workflow should be testing something that we can recommend to developers. As of the current branch it's "let's misconfigure creatively so that configure does not end with an error; please ignore everything that the configure script says because it does not matter. There may be errors in build and run later, YMMV."

[mkoeppe]

Replying to gh-tobiasdiez:

I'm happy to try a different combination of commands, but then please check yourself that these work locally for you.

I've already offered to fix the problem with --with-system-gcc=force

[mkoeppe]

Replying to gh-tobiasdiez:

It accepts the conda gcc if I remove the --prefix=$CONDA_PREFIX part. But then a few other packages are still not properly recognized: ecl bdw-gc libhomfly (which was the reason why I added the prefix in the first place).

These reports would be more useful if you attach the config.log

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

I'm happy to try a different combination of commands, but then please check yourself that these work locally for you.

I've already offered to fix the problem with --with-system-gcc=force

Can you please give the full commands that create a working conda env and are able to recognize gcc and ecl. As you can see here with-system-gcc doesn't work: ​https://github.com/sagemath/sagetrac-mirror/runs/5189468934?check_suite_focus=true

[mkoeppe]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

It accepts the conda gcc if I remove the --prefix=$CONDA_PREFIX part. But then a few other packages are still not properly recognized: ecl bdw-gc libhomfly (which was the reason why I added the prefix in the first place).

These reports would be more useful if you attach the config.log

((Yes, it's available now at ​https://github.com/sagemath/sagetrac-mirror/runs/5189468934?check_suite_focus=true)

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

It accepts the conda gcc if I remove the --prefix=$CONDA_PREFIX part. But then a few other packages are still not properly recognized: ecl bdw-gc libhomfly (which was the reason why I added the prefix in the first place).

These reports would be more useful if you attach the config.log

Now attached to the ticket.

[mkoeppe]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

It accepts the conda gcc if I remove the --prefix=$CONDA_PREFIX part.

OK, here's why it does not accept it when the (questionable, but perhaps currently necessary) option --prefix=$CONDA_PREFIX is given: build/pkgs/gcc/spkg-configure.m4 has these lines:

    if test -f "$SAGE_LOCAL/bin/gcc"; then
        # Special value for SAGE_INSTALL_GCC if GCC is already installed
        SAGE_INSTALL_GCC=exists
        # Set yes since this implies we have already installed GCC and want to keep
        # it selected
        sage_spkg_install_gcc=yes

        # Check whether it actually works...
        # See https://trac.sagemath.org/ticket/24599
        SAGE_CHECK_BROKEN_GCC()
[...]

[mkoeppe]

I'll work on a fix for this later today.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

These reports would be more useful if you attach the config.log

Now attached to the ticket.

Thanks. From config.log:

## --------------------------------------------------- ##
## Checking whether SageMath should install SPKG gc... ##
## --------------------------------------------------- ##
configure:19428: checking whether any of libatomic_ops is installed as or will be installed as SPKG
configure:19437: result: no
configure:19440: checking whether we run on WSL
configure:19444: result: yes; disabling using of system gc
configure:19693: no suitable system package found for SPKG gc

This is why ecl and homfly are not used.

[dimpase]

ecl is rejected because gc is rejected on WSL, see #30629: Reject system libgc that breaks ECL build on WSL

This rejection should not happen if ECL is already provided, I think. (ditto for the other consumers of gc - libhomfly)

[mkoeppe]

Replying to dimpase:

This rejection should not happen if ECL is already provided, I think. (ditto for the other consumers of gc - libhomfly)

This one is pretty subtle. gc is used by both ECL and libhomfly. So only if BOTH can be used from the system, then we do not need to build gc itself.

[dimpase]

Actually, Jammy already has fixed gc. ​https://launchpad.net/ubuntu/+source/libgc ​https://bugs.launchpad.net/ubuntu/+source/libgc/+bug/1897371/comments/1

[mkoeppe]

So we need an improved test

[dimpase]

is it gc from Conda (it should be OK, right?)

[gh-tobiasdiez]

Replying to dimpase:

is it gc from Conda (it should be OK, right?)

Yes it's bdw-gc 8.0.4, which is probably to old. There is a PR updating to 8.0.6 but that's unmerged for quite some time now ​https://github.com/conda-forge/bdw-gc-feedstock/pull/17

[git]

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

​970b01e

Remove conda prefx

[dimpase]

Conda's gc would only be too old if it were built with a particular option.

They probably use it to build ecl, and it won't fly if it was broken!

[git]

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

​9799fd7

build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better

[mkoeppe]

Here's an attempt, not really tested yet

[git]

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

​dcf3dde	Revert "Remove conda prefx"
​757bd73	build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better (fixup)

[mkoeppe]

Tested locally with EXTRA_CONFIGURE_ARGS=--prefix=/opt/conda tox -e docker-conda-forge-standard -- config.status

[mkoeppe]

Replying to mkoeppe:

I don't have a better solution at the moment, but at least there's a reasonably short way to write it as configure --with-system-{gcc,lcalc}=force...

Now I have a better solution: With #33345, we can use configure --with-system-standard-packages=force.

[git]

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

​613198a	Add primecountpy
​566664d	Merge #33330
​dda3c48	configure --with-system-standard-packages: New option
​bc8aaa3	Merge #33345
​b4f76aa	.github/workflows/ci-conda.yml: Use configure --with-system-standard-packages=force

[git]

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

​3bbaf44	bootstrap: Only use SPKG_USE_SYSTEM_STANDARD_PACKAGES for packages with spkg-configure.m4
​2998104	Merge #33345
​a9812f3	.github/workflows/ci-conda.yml: Use configure --with-system-standard-packages=force

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

These reports would be more useful if you attach the config.log

Now attached to the ticket.

Thanks. From config.log:

## --------------------------------------------------- ##
## Checking whether SageMath should install SPKG gc... ##
## --------------------------------------------------- ##
configure:19428: checking whether any of libatomic_ops is installed as or will be installed as SPKG
configure:19437: result: no
configure:19440: checking whether we run on WSL
configure:19444: result: yes; disabling using of system gc
configure:19693: no suitable system package found for SPKG gc

This is why ecl and homfly are not used.

That makes sense. Sorry, should have investigated this before deviating from the instructions outlined in the wiki. Thanks for your patience and investigation.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to mkoeppe:

I don't have a better solution at the moment, but at least there's a reasonably short way to write it as configure --with-system-{gcc,lcalc}=force...

Now I have a better solution: With #33345, we can use configure --with-system-standard-packages=force.

​https://trac.sagemath.org/ticket/30845#comment:143 ?

[dimpase]

Replying to gh-tobiasdiez:

Replying to dimpase:

is it gc from Conda (it should be OK, right?)

Yes it's bdw-gc 8.0.4, which is probably to old. There is a PR updating to 8.0.6 but that's unmerged for quite some time now ​https://github.com/conda-forge/bdw-gc-feedstock/pull/17

Upstream says one has to check that

strings /usr/lib/x86_64-linux-gnu/libgc.so | grep "Wrong __data_start/_end pair"

does not find anything. But this rules out all 8.0.4 (and possibly earlier) installations of libgc, not only broken ones.

[mkoeppe]

Replying to gh-tobiasdiez:

What about adding a warning annotation in the github workflow when a system package is not recognized?

We don't have a mechanism for that, see discussion in #29499.

[mkoeppe]

Replying to gh-tobiasdiez:

the conda packages are quite up to date and thus may fail to be recognized for the simple reason that they are too new.

That's not really specific to conda-forge but also true for various cutting-edge distributions including archlinux and gentoo

[mkoeppe]

How about adding another job (via matrix) that uses src/environment-optional.yml?

[mkoeppe]

Also, adding jobs that test other python versions could probably be useful

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

What about adding a warning annotation in the github workflow when a system package is not recognized?

We don't have a mechanism for that, see discussion in #29499.

One could add a problem matcher for "no suitable system package; standard, will be installed as an SPKG" for now.

[gh-tobiasdiez]

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Probably wait with this until this workflow here passes without errors. There is not much of an advantage in having 5 different matrix flows fail.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

the conda packages are quite up to date and thus may fail to be recognized for the simple reason that they are too new.

That's not really specific to conda-forge but also true for various cutting-edge distributions including archlinux and gentoo

But in this case the workflow does not simply fail because the package is not accepted, right?

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Replying to gh-tobiasdiez:

What about adding a warning annotation in the github workflow when a system package is not recognized?

We don't have a mechanism for that, see discussion in #29499.

One could add a problem matcher for "no suitable system package; standard, will be installed as an SPKG" for now.

No, the problem is that the configuration variables need to be set for the accepted system packages. ​https://trac.sagemath.org/ticket/29499#comment:3

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Probably wait with this until this workflow here passes without errors.

Just reduce the errors in the ptest to warnings. This would be in line with the entire portability test suite.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Replying to gh-tobiasdiez:

the conda packages are quite up to date and thus may fail to be recognized for the simple reason that they are too new.

That's not really specific to conda-forge but also true for various cutting-edge distributions including archlinux and gentoo

But in this case the workflow does not simply fail because the package is not accepted, right?

That's right, Sage will just build the SPKG.

[mkoeppe]

When a Sage user/developer follows our (to-be-updated) instructions with --with-system-standard-packages=force and it gives the configure error regarding the unsuitable system package, there is a clear recourse: Find and install a version that works.

When Sage developers see this in the CI run, there is also a clear course of action: Adjust the conda-specific version constraints in conda.txt files if possible; or file a conda bug report.

Seeing error messages from using a system package that configure knows to reject does not help. It only leads to developers engaging in unproductive guesswork.

For updating Sage and our spkg-configure.m4 scripts to work with new versions, local development and testing on many platforms is necessary anyway; it does not help if there's 1 platform that already speculatively displays some errors.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Replying to gh-tobiasdiez:

What about adding a warning annotation in the github workflow when a system package is not recognized?

We don't have a mechanism for that, see discussion in #29499.

One could add a problem matcher for "no suitable system package; standard, will be installed as an SPKG" for now.

No, the problem is that the configuration variables need to be set for the accepted system packages. ​https://trac.sagemath.org/ticket/29499#comment:3

I meant as a github annotation. Just run configure without -with-system = force. Then configure will print "no suitable system package; standard, will be installed as an SPKG", which is detected and reported in the action overview.

[mkoeppe]

Replying to gh-tobiasdiez:

I meant as a github annotation. Just run configure without -with-system = force. Then configure will print "no suitable system package; standard, will be installed as an SPKG", which is detected and reported in the action overview.

Sure, +1 on that, that's a good idea.

[mkoeppe]

I have some of this in tox.yml, matching configure warnings and error

[git]

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

​c1c9e61	Add matrix
​6ff193f	Add problem matcher

[git]

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

​3a25ddb

Fix path to problem matcher

[git]

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

​a3fd48c

Improve problem matcher

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

I meant as a github annotation. Just run configure without -with-system = force. Then configure will print "no suitable system package; standard, will be installed as an SPKG", which is detected and reported in the action overview.

Sure, +1 on that, that's a good idea.

Okay, this is now implemented. See ​https://github.com/sagemath/sagetrac-mirror/actions/runs/1852417654

[gh-tobiasdiez]

The tests now fail with the following error:

************************************************************************
It seems that you are attempting to run Sage from an unpacked source
tarball, but you have not compiled it yet (or maybe the build has not
finished). You should run `make` in the Sage root directory first.
If you did not intend to build Sage from source, you should download
a binary tarball instead. Read README.txt for more information.
************************************************************************

Is this a consequence of me merging the latest develop branch, or did I accidentally misconfigured something? How can one overwrite this check?

[gh-tobiasdiez]

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Done, but it is currently failing (as reported before). Also added a minimal matrix for python versions 3.8 + 3.9

[mkoeppe]

Replying to git:

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

​c1c9e61	Add matrix
​6ff193f	Add problem matcher

This nuked my changes, intended?

[mkoeppe]

Replying to gh-tobiasdiez:

Dependencies #33330, #33345 deleted

?

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Dependencies #33330, #33345 deleted

?

No longer needed.

[isuruf]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Done, but it is currently failing (as reported before). Also added a minimal matrix for python versions 3.8 + 3.9

Should be fixed with #33358

[mkoeppe]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

I meant as a github annotation. Just run configure without -with-system = force. Then configure will print "no suitable system package; standard, will be installed as an SPKG", which is detected and reported in the action overview.

Sure, +1 on that, that's a good idea.

Wait, I missed that you said "run configure without -with-system = force".

I was +1 on adding the problem matchers.

[mkoeppe]

In comment:181 I explained why we DON'T want to have it run anyway and produce mysterious errors that send developers into doing unproductive guesswork.

[gh-tobiasdiez]

Replying to mkoeppe:

In comment:181 I explained why we DON'T want to have it run anyway and produce mysterious errors that send developers into doing unproductive guesswork.

When Sage developers see this in the CI run, there is also a clear course of action: Adjust the conda-specific version constraints in conda.txt files if possible; or file a conda bug report.

This is still accomplished with the current problem matchers, and even easier. Developer looks at the workflow run, sees that system packages are not accepted and can take action. In addition, she can directly see what errors result from not accepting the system package.

I don't see any advantage in hiding useful information (what does break because of the missing package).

[gh-tobiasdiez]

Replying to isuruf:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Done, but it is currently failing (as reported before). Also added a minimal matrix for python versions 3.8 + 3.9

Should be fixed with #33358

Thanks!

[gh-tobiasdiez]

Any idea on how to fix ​https://trac.sagemath.org/ticket/30845#comment:189?

[mkoeppe]

Replying to gh-tobiasdiez:

I don't see any advantage in hiding useful information

I've already explained that it's not useful for those who know how to update our configure tests.

[mkoeppe]

Replying to gh-tobiasdiez:

Any idea on how to fix ​https://trac.sagemath.org/ticket/30845#comment:189?

Yes, you didn't install the Sage library where you promised that it would be installed. SAGE_LOCAL (set by --prefix) defaults to SAGE_ROOT/local and SAGE_VENV defaults to a subdirectory of it. But you installed the Sage library instead into the system site-packages.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

In comment:181 I explained why we DON'T want to have it run anyway and produce mysterious errors that send developers into doing unproductive guesswork.

When Sage developers see this in the CI run, there is also a clear course of action: Adjust the conda-specific version constraints in conda.txt files if possible; or file a conda bug report.

This is still accomplished with the current problem matchers, and even easier.

But it misses the criterion of comment:121 - does it test what we would recommend to developers.

[mkoeppe]

Also comment:178.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Any idea on how to fix ​https://trac.sagemath.org/ticket/30845#comment:189?

Yes, you didn't install the Sage library where you promised that it would be installed. SAGE_LOCAL (set by --prefix) defaults to SAGE_ROOT/local and SAGE_VENV defaults to a subdirectory of it. But you installed the Sage library instead into the system site-packages.

And how does one fix it without using prefix (which according to you isn't desired)?

[mkoeppe]

For now, using --prefix is the best option. That's why I provided commits 9799fd7/757bd73.

[git]

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

​7666019	Back to using prefix for now
​8a0f319	Fix for rename of conda e-antic package to libeantic
​c8a7b0f	Merge remote-tracking branch 'trac/u/isuruf/eantic' into public/build/conda-runci
​613198a	Add primecountpy
​8426d2d	Merge remote-tracking branch 'trac/public/build/conda-addpackages-runci' into public/build/conda-runci

[gh-tobiasdiez]

Replying to isuruf:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

How about adding another job (via matrix) that uses src/environment-optional.yml?

Done, but it is currently failing (as reported before). Also added a minimal matrix for python versions 3.8 + 3.9

Should be fixed with #33358

It is indeed correctly using lcalc 2 now. Thanks!

[gh-tobiasdiez]

Replying to mkoeppe:

For now, using --prefix is the best option. That's why I provided commits 9799fd7/757bd73.

Thanks. I've reverted to using --prefix (with --without-system-gcc). Let's put your improvements to the gcc detection script in a follow-up ticket.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

I don't see any advantage in hiding useful information

I've already explained that it's not useful for those who know how to update our configure tests.

There are also people that don't know much about these configure scripts but still want to work on the conda environment.

The point of this ticket (at least for me), is having a CI infrastructure to confirm that updates to the conda evniroment such as #33330 and #33358 indeed have a positive impact. For this it is not helpful if the workflow exists early because some conda package got updated in the meantime and now the corresponding "system" package is rejected by sage.

To be honest, I feel tired by this discussion and think we already invested more time discussing pros and cons then developer will ever spend while chasing mysterious bugs potentially coming from this. If its so important to you, I would like to ask you to implement it in a follow-up ticket.

[gh-tobiasdiez]

It's now working: build succeeds and most tests pass in all tested configs. ​https://github.com/sagemath/sagetrac-mirror/actions/runs/1854640215

Let's move potential improvements (like removing --prefix, --without-system-gcc, fixes to giac, updates to the docs etc) to follow-up tickets.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

Replying to gh-tobiasdiez:

I don't see any advantage in hiding useful information

I've already explained that it's not useful for those who know how to update our configure tests.

There are also people that don't know much about these configure scripts but still want to work on the conda environment.

Yes, and they can do that as I explained in comment:181. They don't need to see the errors if they don't want to work on the configure scripts.

[mkoeppe]

Replying to gh-tobiasdiez:

It's now working: build succeeds and most tests pass in all tested configs.

It still doesn't pass the criterion of comment:121 - does it test what we would recommend to developers.

[mkoeppe]

Replying to gh-tobiasdiez:

If it's so important to you, I would like to ask you to implement it in a follow-up ticket.

I already did, but you removed the commits that implemented it.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

It's now working: build succeeds and most tests pass in all tested configs.

It still doesn't pass the criterion of comment:121 - does it test what we would recommend to developers.

C'mon, according to your own information using --prefix is the best way currently. Without any changes to gcc detection or whatever (which is not the point of this ticket), this only works with --without-system-gcc.

[isuruf]

@gh-tobiasdiez, can you restore @mkoeppe's commits that fixed the gcc detection? Then we can use --prefix.

[mkoeppe]

I'll put these commits on #33361 now

[git]

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

​d547541	build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better
​ce6f8fd	build/pkgs/gcc/spkg-configure.m4: Handle the case of SAGE_LOCAL = a system directory with gcc better (fixup)
​5ba1005	Merge remote-tracking branch 'trac/u/mkoeppe/configure__handle_the_case_of_sage_local___a_system_directory_with_gcc_better' into public/build/conda-runci
​1c2c97e	Remove without-system-gcc

[gh-tobiasdiez]

Replying to mkoeppe:

I'll put these commits on #33361 now

Thanks

[gh-tobiasdiez]

Replying to isuruf:

@gh-tobiasdiez, can you restore @mkoeppe's commits that fixed the gcc detection? Then we can use --prefix.

Done by merging #33361. (For the record, I initially removed these commits because it seemed like the whole prefix thing wasn't necessary).

Still a bit confused why #33361 couldn't just be a follow-up on top of this ticket, but, well, I guess I'm used to a different developing/merging strategy.

[gh-tobiasdiez]

Seems to work well, no gc errors anymore and all standard conda packages are detected successfully (even with the `environment-optional.yml).

So should be good to go now.

[dimpase]

How is there no gc error any more? What has changed in this respect?

[gh-tobiasdiez]

Replying to dimpase:

How is there no gc error any more? What has changed in this respect?

#33361 fixed it.

[dimpase]

Replying to gh-tobiasdiez:

Replying to dimpase:

How is there no gc error any more? What has changed in this respect?

#33361 fixed it.

this must be close a miracle - as only gcc was touched there.

[mkoeppe]

gc was rejected via SPKG_DEPCHECK on gcc.

[dimpase]

Replying to mkoeppe:

gc was rejected via SPKG_DEPCHECK on gcc.

Does this mean that somehow #33361 is blessing gcc's deps? Hmm, not sure I follow.

[dimpase]

no, that's really weird. gc is not used by gcc... OK, this is a Church of gcc spkg, and I'm a non-believer...

[mkoeppe]

Replying to mkoeppe:

gc was rejected via SPKG_DEPCHECK on gcc.

Sorry, I was wrong - I misremembered

[mkoeppe]

There was no problem with gc except within Tobias's WSL install.

[gh-tobiasdiez]

Sorry for the missing c and the confusion it caused :-)

[mkoeppe]

Replying to mkoeppe:

Or generate it as $(for pkg in $(./sage -package list :standard: --has-file spkg-configure.m4); do echo --with-system-$pkg=force; done)

With dependency #33361 positively reviewed, but #33345 (configure --with-system-standard-packages=force) stalled, let's use the above as a solution.

[mkoeppe]

@isuruf - --with-system-lrcalc=force fails because conda-forge does not provide lrcalc 2.x yet

[slelievre]

Fixed by

• ​https://github.com/conda-forge/lrcalc-feedstock/pull/7

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to mkoeppe:

Or generate it as $(for pkg in $(./sage -package list :standard: --has-file spkg-configure.m4); do echo --with-system-$pkg=force; done)

With dependency #33361 positively reviewed, but #33345 (configure --with-system-standard-packages=force) stalled, let's use the above as a solution.

If a system package is not used, then an error message is displayed in the github flow, so these force arguments are not necessary (or can later be added as part of #33345) .

Can we please get this ticket in?

[git]

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

​9ea6061	Merge tag '9.6.beta5' into t/30845/public/build/conda-runci
​574c6df	.github/workflows/ci-conda.yml: Use configure --with-system-...=force

[mkoeppe]

Replying to gh-tobiasdiez:

Can we please get this ticket in?

Working on it, as you can see

[mkoeppe]

Replying to slelievre:

Fixed by

• ​https://github.com/conda-forge/lrcalc-feedstock/pull/7

Great, now I see that lrcalc 2.1. Still need ​https://pypi.org/project/lrcalc/ in conda-forge, or we need to install it with pip.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Can we please get this ticket in?

Working on it, as you can see

Can you please revert 574c6df thanks!

[mkoeppe]

I'm also getting

Checking whether SageMath should install SPKG singular...
checking whether any of gmp ntl flint readline mpfr cddlib is installed as or will be installed as SPKG... no
checking for Singular... /usr/share/miniconda/envs/sage-build/bin/Singular
checking for SINGULAR... no
...
configure: error: 

    Given --with-system-singular=force, but no system package could be used.
    That's an error.  Please install the indicated package to continue.
    (To override this error, use ./configure --without-system-singular)

(​https://github.com/mkoeppe/sage/runs/5575546912?check_suite_focus=true)

[git]

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

​a01bdd9

build/pkgs/lrcalc/distros/conda.txt: Set version bound >= 2

[git]

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

​739e4cd

build/pkgs/singular/distros/conda.txt: Set version lower bound

[isuruf]

Working on both lrcalc and singular issue. Can you add python-lrcalc as the name for conda package for lrcalc_python?

[mkoeppe]

Will do, thanks!

[git]

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

​587f57a	build/pkgs/lrcalc_python/distros/conda.txt: New
​8af68a0	build/pkgs/singular/distros/conda.txt: Change version specification

[isuruf]

Can you also do singular>=4.2.1.p3? Apparently conda thinks 4.2.1.p3 is a development version and is <4.2.1

[git]

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

​9cbee4c

build/pkgs/singular/distros/conda.txt: Use singular>=4.2.1.p3

[gh-tobiasdiez]

Replying to mkoeppe:

I'm also getting

Checking whether SageMath should install SPKG singular...
checking whether any of gmp ntl flint readline mpfr cddlib is installed as or will be installed as SPKG... no
checking for Singular... /usr/share/miniconda/envs/sage-build/bin/Singular
checking for SINGULAR... no
...
configure: error: 

    Given --with-system-singular=force, but no system package could be used.
    That's an error.  Please install the indicated package to continue.
    (To override this error, use ./configure --without-system-singular)

(​https://github.com/mkoeppe/sage/runs/5575546912?check_suite_focus=true)

Can we please do this in a follow-up ticket (i.e. remove the force for now). This has nothing to do with the github action action in this ticket.

Similarly, the changes to the conda package versions / package names should go to their own tickets (based on this ticket here to check if they indeed work as intended).

---

New commits:

​9cbee4c

build/pkgs/singular/distros/conda.txt: Use singular>=4.2.1.p3

[mkoeppe]

Replying to gh-tobiasdiez:

Can we please do this in a follow-up ticket (i.e. remove the force for now). This has nothing to do with the github action action in this ticket.

Similarly, the changes to the conda package versions / package names should go to their own tickets (based on this ticket here to check if they indeed work as intended).

Please, Tobias, an author repeatedly demanding that the ticket goes in "as is" is not helpful and is not part of the collaborative workflow of the Sage project.

[mkoeppe]

Replying to isuruf:

Can you also do singular>=4.2.1.p3? Apparently conda thinks 4.2.1.p3 is a development version and is <4.2.1

Thanks, this works.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Can we please do this in a follow-up ticket (i.e. remove the force for now). This has nothing to do with the github action action in this ticket.

Similarly, the changes to the conda package versions / package names should go to their own tickets (based on this ticket here to check if they indeed work as intended).

Please, Tobias, an author repeatedly demanding that the ticket goes in "as is" is not helpful and is not part of the collaborative workflow of the Sage project.

That's not what I'm saying. I just don't see the need that these changes, that then need further changes etc need to be part of this ticket. I'm happy to adjust the github workflow if you have any comments/suggestions on this.

[mkoeppe]

I see that python-lrcalc 2.1 is now available in the conda-forge channel. Thanks @isuruf!

Tests running at ​https://github.com/mkoeppe/sage/actions/runs/1996031338

[mkoeppe]

There's something wrong with libgiac, in the doctests of src/sage/calculus/calculus.py it looks like infinite recursion

[git]

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

​9f8cb1d

.github/workflows/ci-conda.yml: Also test on macos-latest

[mkoeppe]

I have also added tests on macos-latest. This reproduces an error that I saw on my machine: ppl is rejected by the configure script.

see ​https://github.com/mkoeppe/sage/runs/5581501610?check_suite_focus=true

[dimpase]

Replying to mkoeppe:

I have also added tests on macos-latest. This reproduces an error that I saw on my machine: ppl is rejected by the configure script.

see ​https://github.com/mkoeppe/sage/runs/5581501610?check_suite_focus=true

this looks to me like a bug in m4/ppl.m4. They extract -L, etc, flags into PPL_LDFLAGS but forget to append them to LDFLAGS for testing in AC_RUN_IF_ELSE. Something like this should make it work (assuming these flags are getting into PPL_LDFLAGS at all):

m4/ppl.m4

@@ -96 +96 @@
   if test "x$enable_ppltest" = xyes
   then
     ac_save_CPPFLAGS="$CPPFLAGS"
+    ac_save_LDFLAGS="$LDFLAGS"
     ac_save_LIBS="$LIBS"
     CPPFLAGS="$CPPFLAGS $PPL_CPPFLAGS"
     LIBS="$LIBS $PPL_LIBS"
+    LDFLAGS="$LDFLAGS $PPL_LDFLAGS"
 
 dnl Now check if the installed PPL is sufficiently new.
 dnl (Also sanity checks the results of ppl-config to some extent.)
@@ -238 +240 @@
 
     CPPFLAGS="$ac_save_CPPFLAGS"
     LIBS="$ac_save_LIBS"
+    LDFLAGS="$ac_save_LDFLAGS"
   fi
 fi
 
@@ -261 +264 @@
       echo "*** Could not run PPL test program, checking why..."
       CPPFLAGS="$CPPFLAGS $PPL_CPPFLAGS"
       LIBS="$LIBS $PPL_LIBS"
+      LDFLAGS="$LDFLAGS $PPL_LDFLAGS"
       AC_LINK_IFELSE([AC_LANG_PROGRAM([[
 #include <ppl.hh>
 using namespace Parma_Polyhedra_Library;
@@ -287 +291 @@
 ])
       CPPFLAGS="$ac_save_CPPFLAGS"
       LIBS="$ac_save_LIBS"
+      LDFLAGS="$ac_save_LDFLAGS"
     fi
   fi
   PPL_CPPFLAGS=""

Untested.

[git]

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

​7bb23f9

Try again without lower limit for singular

[git]

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

​886d895

...and without lrcalc lower bound

[isuruf]

No, it's a bug in the conda package with binary relocation. Will fix shortly.

Replying to dimpase:

Replying to mkoeppe:

I have also added tests on macos-latest. This reproduces an error that I saw on my machine: ppl is rejected by the configure script.

see ​https://github.com/mkoeppe/sage/runs/5581501610?check_suite_focus=true

this looks to me like a bug in m4/ppl.m4. They extract -L, etc, flags into PPL_LDFLAGS but forget

[gh-tobiasdiez]

I've reverted the changes to the lower bounds to singular and lrcalc since for me they were not necessary. It also looks like on github lcalc 2.1 and singular 4.2.1.p3 are used automatically. This is also expected since conda always tries to use the most recent versions and only in very rare instances lower bounds are necessary (essentially only if there are two different branches in the dependency resolution tree, and conda would choose the 'wrong' one). Why did you added these lower bounds?

[gh-tobiasdiez]

Replying to mkoeppe:

I have also added tests on macos-latest. This reproduces an error that I saw on my machine: ppl is rejected by the configure script.

see ​https://github.com/mkoeppe/sage/runs/5581501610?check_suite_focus=true

And which advantages does one now gain from the fact that the github workflow already quits after the configure step, and doesn't run build and tests?

Moreover, after the change with the force parameter the github matcher is no longer working correctly since now " no suitable system package; this is an error" is displayed in the logs.

[git]

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

​a93b236

.github/workflows/ci-conda.yml: Reorder matrix

[mkoeppe]

Replying to gh-tobiasdiez:

I've reverted the changes to the lower bounds to singular and lrcalc since for me they were not necessary

Yes, they are not needed any more, thanks.

[mkoeppe]

@isuruf, on macos with environment-optional.yml (​https://github.com/mkoeppe/sage/runs/5586815094?check_suite_focus=true), I am getting an error from gdb

Warning: ERROR conda.core.link:_execute(699): An error occurred while installing package 'conda-forge::gdb-11.1-py38h36b043a_3'.
  
  ERROR conda.core.link:_execute(699): An error occurred while installing package 'conda-forge::gdb-11.1-py38h36b043a_3'.
  Rolling back transaction: ...working... done
  Warning: 
  LinkError: post-link script failed for package conda-forge::gdb-11.1-py38h36b043a_3
  location of failed script: /usr/local/miniconda/envs/sage-build/bin/.gdb-post-link.sh
  ==> script messages <==
  <None>
  ==> script output <==
  stdout: Warning: GDB is not codesigned.
  Generating and installing gdb_codesign certificate
  
  stderr: cat: /usr/local/miniconda/envs/sage-build/etc/gdb/.messages.txt: No such file or directory
  error: Something went wrong when installing the certificate
  
  return code: 1
  
  ()
  
  
  
  LinkError: post-link script failed for package conda-forge::gdb-11.1-py38h36b043a_3
  location of failed script: /usr/local/miniconda/envs/sage-build/bin/.gdb-post-link.sh
  ==> script messages <==
  <None>
  ==> script output <==
  stdout: Warning: GDB is not codesigned.
  Generating and installing gdb_codesign certificate
  
  stderr: cat: /usr/local/miniconda/envs/sage-build/etc/gdb/.messages.txt: No such file or directory
  error: Something went wrong when installing the certificate
  
  return code: 1
  

[mkoeppe]

@isuruf, on macos I see lots of warnings ld: warning: -pie being ignored. It is only used when linking a main executable in the doctests. I see this is coming from LDFLAGS in the conda environments. Is this something that can be fixed, or should we silence this warning in our doctest machinery?

[mkoeppe]

Replying to mkoeppe:

There's something wrong with libgiac, in the doctests of src/sage/calculus/calculus.py it looks like infinite recursion

This one is specific to Linux; it's fine on macos.

[git]

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

​ed0967c

.github/workflows/configure-systempackage-problem-matcher.json: Also match 'no suitable system package; this is an error'

[gh-tobiasdiez]

Replying to git:

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

​ed0967c

.github/workflows/configure-systempackage-problem-matcher.json: Also match 'no suitable system package; this is an error'

Error: Unable to process command '::add-matcher::.github/workflows/configure-systempackage-problem-matcher.json' successfully. Error: After parsing a value an unexpected character was encountered: {. Path 'problemMatcher[0]', line 15, position 8.

[gh-tobiasdiez]

Is there something else that is left to do?

[isuruf]

Replying to mkoeppe:

@isuruf, on macos I see lots of warnings ld: warning: -pie being ignored. It is only used when linking a main executable in the doctests. I see this is coming from LDFLAGS in the conda environments. Is this something that can be fixed, or should we silence this warning in our doctest machinery?

Not easy to do. It's better to silence in the doctest machinery

[mkoeppe]

OK, I'll do that so that the noise from these warnings does not hide real failures

[isuruf]

Can you open an issue in ​https://github.com/conda-forge/gdb-feedstock/?

Replying to mkoeppe:

@isuruf, on macos with environment-optional.yml (​https://github.com/mkoeppe/sage/runs/5586815094?check_suite_focus=true), I am getting an error from gdb

Warning: ERROR conda.core.link:_execute(699): An error occurred while installing package 'conda-forge::gdb-11.1-py38h36b043a_3'.
  
  ERROR conda.core.link:_execute(699): An error occurred while installing package 'conda-forge::gdb-11.1-py38h36b043a_3'.
  Rolling back transaction: ...working... done
  Warning: 
  LinkError: post-link script failed for package conda-forge::gdb-11.1-py38h36b043a_3
  location of failed script: /usr/local/miniconda/envs/sage-build/bin/.gdb-post-link.sh
  ==> script messages <==
  <None>
  ==> script output <==
  stdout: Warning: GDB is not codesigned.
  Generating and installing gdb_codesign certificate
  
  stderr: cat: /usr/local/miniconda/envs/sage-build/etc/gdb/.messages.txt: No such file or directory
  error: Something went wrong when installing the certificate
  
  return code: 1
  
  ()
  
  
  
  LinkError: post-link script failed for package conda-forge::gdb-11.1-py38h36b043a_3
  location of failed script: /usr/local/miniconda/envs/sage-build/bin/.gdb-post-link.sh
  ==> script messages <==
  <None>
  ==> script output <==
  stdout: Warning: GDB is not codesigned.
  Generating and installing gdb_codesign certificate
  
  stderr: cat: /usr/local/miniconda/envs/sage-build/etc/gdb/.messages.txt: No such file or directory
  error: Something went wrong when installing the certificate
  
  return code: 1
  

[mkoeppe]

A minor thing to fix: Installing sagelib downgrades scipy, networkx via install-requires; that's now #33520.

[git]

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

​d7dfa69

sage.features.pkg_systems.SagePackageSystem: Check if there are any installation records

[git]

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

​07545e9	Fix sage_setup doctests
​aa971bd	Fix doctest in sage_docbuild/__init__.py. Most of the test rely on location that are writable or the presence of documentation sources.
​54bd2f5	Merge branch 'develop' into distro_doctests
​6c1dc29	replace optional build tag with sage_spkg
​18308fc	get rid of the last optional build tag
​e2c9eea	Merge branch 'develop' into distro_doctests
​5382264	make doctest in find_extra_files more robust by sorting the result so that the order is stable.
​6b24c05	Merge #33141

[git]

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

​a408a00

.github/workflows/configure-systempackage-problem-matcher.json: Fix syntax

[git]

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

​8631ae1

src/sage/doctest/parsing.py: Filter out ld warnings on macOS conda

[git]

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

​acf80df

build/pkgs/gdb/distros/conda.txt: Disable

[mkoeppe]

Replying to isuruf:

Can you open an issue in ​https://github.com/conda-forge/gdb-feedstock/?

Will do. For now I've disabled it

[mkoeppe]

I've opened ​https://github.com/conda-forge/gdb-feedstock/issues/53

[git]

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

​b431edb

.github/workflows/configure-systempackage-problem-matcher.json: Fix 'Duplicate owner name'

[gh-tobiasdiez]

Replying to git:

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

​b431edb

.github/workflows/configure-systempackage-problem-matcher.json: Fix 'Duplicate owner name'

echo "::remove-matcher owner=configure-systempackage::" in the workflow has to be probably be changed as well now.

[gh-tobiasdiez]

Btw, the new workflow is running in the sagetrac-mirror repo (​https://github.com/sagemath/sagetrac-mirror/actions/workflows/ci-conda.yml) so you don't have to run this manually in your own fork.

[mkoeppe]

macos-latest-3.8-environment: ​https://github.com/mkoeppe/sage/runs/5591728773?check_suite_focus=true

sage -t --random-seed=295057506920321218473335936870781003380 src/sage/env.py  # 1 doctest failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/interfaces/expect.py  # 40 doctests failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/interfaces/gap.py  # 75 doctests failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/interfaces/mwrank.py  # 6 doctests failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/interfaces/quit.py  # 6 doctests failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/repl/interpreter.py  # 2 doctests failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/repl/interface_magic.py  # 1 doctest failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/repl/ipython_kernel/install.py  # 1 doctest failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/structure/coerce_actions.pyx  # 1 doctest failed
sage -t --random-seed=295057506920321218473335936870781003380 src/sage/tests/cmdline.py  # 2 doctests failed

[mkoeppe]

I think the many failures from sage.interfaces are the failure of too recent versions of ptyprocess (#32147).

[mkoeppe]

@isuruf unfortunately, the only working version of ptyprocess (0.5.1) on macOS is only available on outdated python versions in conda-forge.

ptyprocess                     0.5.1          py27_0  conda-forge         
ptyprocess                     0.5.1          py34_0  conda-forge         
ptyprocess                     0.5.1          py35_0  conda-forge         
ptyprocess                     0.5.1          py36_0  conda-forge         

[git]

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

​6f9a2d0

src/setup.cfg.m4: Add ptyprocess to install-requires to get version constraint

[mkoeppe]

Replying to gh-tobiasdiez:

Btw, the new workflow is running in the sagetrac-mirror repo (​https://github.com/sagemath/sagetrac-mirror/actions/workflows/ci-conda.yml) so you don't have to run this manually in your own fork.

Thanks, yes, but the pipeline is pretty clogged

[git]

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

​4de700d

.github/workflows/ci-conda.yml: Update ::remove-matcher

[mkoeppe]

The other failures on macOS are very minor.

[mkoeppe]

Replying to mkoeppe:

There's something wrong with libgiac, in the doctests of src/sage/calculus/calculus.py it looks like infinite recursion

This failure on Linux is the remaining big issue.

[mkoeppe]

(The log of these runs is about 250 MB uncompressed, not fun to look at.)

[mkoeppe]

There's also some cysignals-related breakage on Linux:

2022-03-17T21:25:16.4730359Z **********************************************************************
2022-03-17T21:25:16.4812929Z File "src/sage/functions/min_max.py", line 240, in sage.functions.min_max.MaxSymbolic._evalf_
2022-03-17T21:25:16.4813319Z Failed example:
2022-03-17T21:25:16.4813740Z     sig_on_count() # check sig_on/off pairings (virtual doctest)
2022-03-17T21:25:16.4814033Z Expected:
2022-03-17T21:25:16.4814224Z     0
2022-03-17T21:25:16.4814414Z Got:
2022-03-17T21:25:16.4814603Z     2947
2022-03-17T21:25:16.4935843Z **********************************************************************

[isuruf]

giac error should be fixed with ​https://github.com/conda-forge/giac-feedstock/pull/29

[git]

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

​b508d1d	Cleanup
​93fce5a	Continue on error in config step

[gh-tobiasdiez]

Most doctests are now passing, so this should be good to go now (leaving fixes to the other tests to follow-up tickets).

[mkoeppe]

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

[mkoeppe]

Replying to isuruf:

giac error should be fixed with ​https://github.com/conda-forge/giac-feedstock/pull/29

Thanks @isuruf, looking great.

[mkoeppe]

Replying to mkoeppe:

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

Other than that, it's in good shape now. Could someone review my changes please?

[gh-tobiasdiez]

Replying to mkoeppe:

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

That largely depends on the nature of the error. If the error in the config step is critical, then the build step will fail and no tests are run. Moreover, there is no harm in executing also the other steps, the workflow will still be displayed as failed due to the error in the config job. You just get a bit more information.

[mkoeppe]

Replying to gh-tobiasdiez:

Replying to mkoeppe:

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

That largely depends on the nature of the error.

No, it doesn't. On error, the generated files are not generated.

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to mkoeppe:

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

Other than that, it's in good shape now. Could someone review my changes please?

I'm fine with these changes (although they probably should have been extracted to their own tickets as they don't have to do anything with the github workflow; but lets not be overly pedantic).

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

Replying to mkoeppe:

continue-on-error makes no sense because the unconfigured source tree cannot be tested.

That largely depends on the nature of the error.

No, it doesn't. On error, the generated files are not generated.

I tried it locally and the necessary files seem to be still present when with-system-SPKG=force triggers an error. Having a quick look at the code these errors are also deferred to the very end of the configure script.

[mkoeppe]

Replying to gh-tobiasdiez:

I tried it locally and the necessary files seem to be still present when with-system-SPKG=force triggers an error. Having a quick look at the code these errors are also deferred to the very end of the configure script.

You are right.

[mkoeppe]

Nevertheless, continue-on-error makes no sense as I have explained throughout the thread, comment:141 etc.

[mkoeppe]

But it's fine for now, let's see that we can get it merged in 9.6.

[mkoeppe]

Onward to documenting it, #33426?

[mkoeppe]

Replying to gh-tobiasdiez:

they probably should have been extracted to their own tickets as they don't have to do anything with the github workflow

Yes, the fix to src/sage/features/pkg_systems.py could perhaps have been made a separate ticket and a dependency here. But it would have been difficult to test it separately because the present ticket is its only use case.

Sometimes the scope of a ticket needs to be adjusted during development. You already know that sometimes the scope turns out to be too big and it is necessary break out smaller, more manageable and more clearly defined tickets.

But sometimes the scope of a ticket also turns out to be too small and the ticket is not viable on its own. This is what happened on the present ticket. The workflow documented in the wiki ​https://wiki.sagemath.org/Conda has never actually worked. Creating a GH Actions workflow based on a semi-quasi-working variant of it, by itself was not convincing as a ticket (comment:121 - "what does it test"). With the broader scope of actually fixing this way of installing Sage and testing something that we can recommend to developers, the ticket has a viable scope: The changes bring a clear improvement to Sage.

[mkoeppe]

Some of the test suite failures that we saw are from ipython 8.x; #33170 updates the doctests

[gh-tobiasdiez]

Replying to mkoeppe:

But it's fine for now, let's see that we can get it merged in 9.6.

Thanks for the review!

[gh-tobiasdiez]

Replying to mkoeppe:

Onward to documenting it, #33426?

Yes!

[gh-tobiasdiez]

Replying to mkoeppe:

Replying to gh-tobiasdiez:

they probably should have been extracted to their own tickets as they don't have to do anything with the github workflow

Yes, the fix to src/sage/features/pkg_systems.py could perhaps have been made a separate ticket and a dependency here. But it would have been difficult to test it separately because the present ticket is its only use case.

Sometimes the scope of a ticket needs to be adjusted during development. You already know that sometimes the scope turns out to be too big and it is necessary break out smaller, more manageable and more clearly defined tickets.

But sometimes the scope of a ticket also turns out to be too small and the ticket is not viable on its own. This is what happened on the present ticket. The workflow documented in the wiki ​https://wiki.sagemath.org/Conda has never actually worked. Creating a GH Actions workflow based on a semi-quasi-working variant of it, by itself was not convincing as a ticket (comment:121 - "what does it test"). With the broader scope of actually fixing this way of installing Sage and testing something that we can recommend to developers, the ticket has a viable scope: The changes bring a clear improvement to Sage.

In general I agree that a ticket has to have a clear scope and improvement. For this ticket here, the github workflow essentially didn't change in the past 4 weeks, and at this point it was already clear that the workflow works in principle, with the caveat that a lot of docstests failed. In my opinion, it would have been better to merge the ticket already (with the few additional improvements to the workflow that we have discussed), then follow-up tickets could have easily improved different aspects of the conda environment, while the previous runs of the ci would have served as a baseline. Even thinks like the addition of the tests for macos could have been small follow-up tickets. I really think the tendency of the sage developers to create a lot of parallel, inter-dependent tickets makes reviewing harder and slows down the process. A more linear approach would increase the dev experience and velocity in my opinion.

Anyway, I'm happy that this ticket is finally ready to be merged.

[mkoeppe]

Replying to gh-tobiasdiez:

it was already clear that the workflow works in principle

The project generally uses a standard for tickets higher than that. Yes, there's a tradeoff between velocity and stability.

[isuruf]

Is there a ticket for the remaining failures after this ticket?

[gh-tobiasdiez]

Yes, they are collected in #33331.