-
-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tox / GH Actions: Add ubuntu variants using ppa:ubuntu-toolchain-r #32966
Comments
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. New commits:
|
Commit: |
Author: Matthias Koeppe |
This comment has been minimized.
This comment has been minimized.
comment:8
Do we really need to add tests for each possible combination of system packages? This would also mean that we voucher to support these systems (otherwise, what's the point of these tests?). I think maintaining the "standard" system config is already enough overhead. How much people on ubuntu add custom package repos? Maybe it would be worthwhile to have a general discussion about which systems sage wants to support (how old, which system configs, when to drop support etc) and then based on this outcome add tests. (Please excuse my ignorance if there have been already such a discussion.) Also this ticket seems to be the exact opposite of #32532 and as far as I followed the discussion on the dev list no final conclusion has been reached there yet. |
comment:9
The standard ones on these museum-grade systems are too old to be supported. IMHO we must be much more aggressive in dropping old systems than we currently are... |
comment:10
Replying to @tobiasdiez:
No, this ticket (and all of tox.ini) does not come with a promise that we support a particular system configuration. It only makes it easy to test it. |
comment:12
Replying to @mkoeppe:
But why do you want to test something (and spend resources on implementing and maintaining such tests) if there is no intention to support this particular config? |
comment:13
Once we can easily test if something works, a decision can be made whether to support it. |
comment:14
Also, this infrastructure is now used by several upstream projects for portability testing; most recent add: pypa/setuptools#2923 |
comment:15
Replying to @mkoeppe:
I think you have proven very successfully that the existing infrastructure can easily be extended to incorporate new system configs. Thus, the important question is if we want to support a certain config, and not if its technically possible to test it. I don't have enough experience with the linux environment to judge if custom gcc installations are common enough on recent systems. However, a common theme in the discussion about removing the gcc package was that's a pain in the * * to maintain different configs. So I think there should be good reasons to add another config to the already pretty long list of variations. |
comment:16
Let me rephrase for clarity: Once we can easily test if something works on a platform, a decision can be made whether to support SageMath on this platform. |
comment:17
As we saw recently a few times, such obsolete systems, where one needs such non-standard toolchains to get anywhere, are well-supported by conda. Direct support of such configurations is not buying us much. |
comment:18
Replying to @tobiasdiez:
No, it sounds like you have misunderstood the discussion. We want people to be able to use GCC (and other toolchain components) from their distribution -- to reduce our maintenance burden for our project regarding the gcc spkg. |
comment:19
I think a long-term idea of what systems to support and in which way would be preferably. For example, numpy has a clear strategy where they recommend people to install it via conda and are relatively restrictive on which compilers they support for from-source installations. Not saying that sage should go the same path, but I think narrowing down the range of supported distribution channels would open up more resources for actual features and bug fixes. Anyway, should we transfer this discussion to the dev mailing list? |
comment:20
I have made a plan for platform support in Sage 9.6, 9.7 in #32074 because major changes are coming from upstream. |
comment:21
The present ticket does not need more discussion. It's an improvement because it expands the platforms that we can easily test. Being able to test is better than not being able to test. |
comment:22
|
comment:23
|
comment:24
although |
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
|
comment:57
Just noticed that now
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:60
Replying to @sagetrac-git:
you forgot this one, and without it one gets an error early on. |
comment:61
Replying to @dimpase:
oops, sorry, I messed up my branches. It's good here. Still testing. |
comment:62
Please add wiping up |
comment:63
I've pushed this change to the branch of #32789 |
comment:64
OK, lgtm |
comment:65
Thanks! |
comment:66
needs a rebase |
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:
|
Changed branch from u/mkoeppe/tox___gh_actions__add_ubuntu_variants_using_ppa_ubuntu_toolchain_r to |
(from #30876)
see https://askubuntu.com/a/1149383/309919
To test:
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=trusty:
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=xenial
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=bionic
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=jammy
NB: Your Docker should have enough RAM allowed (I'd advice 8GB). In Docker Desktop this setting is in Preferences->Resources -> Advanced.
Depends on #33187
Depends on #33103
CC: @dimpase @tobiasdiez
Component: porting
Author: Matthias Koeppe
Branch/Commit:
d42bc03
Reviewer: Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/32966
The text was updated successfully, but these errors were encountered: