set up FreeBSD testing on GitHub actions

[dimpase]

Is there an existing issue for this?

• I have searched the existing issues for a bug report that matches the one I want to file, without success.

Problem Description

currently Sage is not really tested on FreeBSD, and the support is lagging behind.
It's however possible to set up FreeBSD (and other BSDs) testing on GitHub Actions:
https://github.com/cross-platform-actions/action#readme

Proposed Solution

use https://github.com/cross-platform-actions/action#readme

Alternatives Considered

n/a

Additional Information

@thierry-FreeBSD

[mkoeppe]

Within that VM, you can just run tox -e local-root-freebsd-standard or tox -e local-root-freebsd-minimal

[thierry-FreeBSD]

The problems encountered with Sage in the FreeBSD ports / packages are caused by different versions of the dependencies: many ports of FreeBSD follow upstream releases, and it breaks Sage.

I have read https://github.com/cross-platform-actions/action#readme but I don't understand how it handles this problem of dependencies.

[dimpase]

In principle, the idea would be to build and test Sage from source, just like we do on Linux. Dependencies are installed based on the info in build/pkgs/*/distros/freebsd.txt , checked for compatibilty by ./configure, and these ones which are not OK are not used, but built instead.

[dimpase]

And tox -e local-root-freebsd-standard etc will try to do all the above for you.

[dimpase]

I see that indeed some Python packages in FreeBSD are ahead of Sage, e.g. scipy. Anyhow it would be good to set it up, if only just to see where we are and what fails.

[mkoeppe]

That doesn't matter because we do not use system Python packages.

[thierry-FreeBSD]

That doesn't matter for you, as upstream, but packagers (be it FreeBSD or most Linux distributions) won't package an application with so many bundled dependencies: we use the dependencies provided by the system packages.

[mkoeppe]

Yes, I said it in the context of this Issue because it is about setting up testing that our upstream project builds on this platform.

[thierry-FreeBSD]

WIP on my fork, see https://github.com/thierry-FreeBSD/sage/actions/runs/4357449549/jobs/7616771378#step:3:528 .

Remarks:

• it is not sufficient to install tox with its dependencies: tomli must also be installed;
• it does not work with local-root-freebsd-standard because actually the user is not root and cannot install packages => I switched to local-sudo-freebsd-standard;
• packages names have mistakes for pari_galdata, tox and pkg-config (in distros/freebsd.txt): I fixed them for pari_galdata and tox, but it is still failing for pkg-config!

[mkoeppe]

• it is not sufficient to install tox with its dependencies: tomli must also be installed

Packaging bug on freebsd?

[thierry-FreeBSD]

Packaging bug on freebsd?

I'm not sure. You mean that tomli should be a dependency of tox?

[mkoeppe]

https://github.com/tox-dev/tox/blob/main/pyproject.toml#L60

[thierry-FreeBSD]

To be fixed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270014

[thierry-FreeBSD]

Well, the error about pkg-config is solved, and the build goes on.

Then it tries to install a list of 266 packages, and aborts quickly without explicit message:

Number of packages to be installed: 266

The process will require 3 GiB more space.
548 MiB to be downloaded.

Proceed with this action? [y/N]: local-sudo-freebsd-standard: exit 1 (5.34 seconds) /Users/runner/work/sage/sage> bash -c 'case "" in 1|y*|Y*);; *) export PATH="build/bin:$PATH" && eval $(sage-print-system-package-command auto --sudo --yes --no-install-recommends --spkg install $(sage-package list --has-file=spkg-configure.m4 :standard:) _bootstrap      ) || [ "$IGNORE_MISSING_SYSTEM_PACKAGES" = yes ] && echo "(ignoring errors)" ;; esac' pid=909
  local-sudo-freebsd-standard: FAIL code 1 (8.19=setup[2.79]+cmd[0.02,0.03,5.34] seconds)
  evaluation failed :( (9.10 seconds)

Is it possible to make it more verbose?

[mkoeppe]

I think in build/bin/sage-print-system-package-command, you'll need to handle the YES flag

[thierry-FreeBSD]

Well, it took some time, but finally it succeeded!
I had no success with the previous version of cross-platform-actions, but here we are:
See https://github.com/thierry-FreeBSD/sage/actions/runs/4874888903

I you want, I could push my file .github/workflows/ci-bsd.yml .

[mkoeppe]

You probably meant to post this link: https://github.com/thierry-FreeBSD/sage/actions/runs/4874888897/jobs/8696385000

[dimpase]

it failed due to the runner hang, it seems

[thierry-FreeBSD]

You probably meant to post this link: https://github.com/thierry-FreeBSD/sage/actions/runs/4874888897/jobs/8696385000

Yes, sorry!

[thierry-FreeBSD]

it failed due to the runner hang, it seems

Building the documentation (Build documentation (PDF) #4) hang, but the build (Build & Test #23) seems OK:
https://github.com/thierry-FreeBSD/sage/actions/runs/4874888903/jobs/8696420057

[dimpase]

Yeah, looks good. So, can we get the branch which does the job in a PR?

[mkoeppe]

Building the documentation (Build documentation (PDF) #4) hang, but the build (Build & Test #23) seems OK

But neither of these two have anything to do with FreeBSD

[dimpase]

Indeed, it's confusing, sorry. The only relevant CI here is .github/workflows/ci-bsd.yml

Perhaps put there a manual trigger ?

[thierry-FreeBSD]

In this case, I guess that for the parameter on: I should replace [push] by workflow_dispatch: or [workflow_dispatch] ?

[dimpase]

For your experimental FreeBSD branch, I'd have disabled all the CI, expect this one. I think you can just remove

ci-conda.yml                                  doc-build-pdf.yml
ci-cygwin-standard.yml                        doc-build.yml
ci-linux.yml                                  
ci-macos.yml                                  
ci-wsl.yml   

in .github/workflows/.