System upgrades breaking sage frequently

[Nils Bruin]

I've noticed that after a modest upgrade (just "dnf update"), with some regularity sage breaks. In the most recent edition, "libflint.so" couldn't be found.

I guess there is some prerequisite that sage was relying on to be provided by the operating system was changed? Is sage relying on the system python nowadays?

The only way I have found to clean this up is by doing a "make distclean", which makes for quite a heavy rebuild process! Is there a more modest approach?

It's nice that we're integrating better with OS-supplied prerequisites, but it mixes very badly with building from source on an actual system one works on:

I can see the nightmare scenario where you've run a small system update (as one should do to keep up-to-date with vulnerabilities) in the evening (or perhaps your computer did it for you!) and the next morning you arrive in front of the class with a demo where you now discover that sage is broken and requires an hour's worth of build time to get up to snuff again.

Is there a better/safer way of having both an up-to-date system and a reliable sage install?

[Is the problem perhaps that fedora bumps the default "python" to a newer version for which sage doesn't have its libraries built/accessible? In that case: fedora doesn't delete older versions. I can still run python3.9 or python3.8. So in that case perhaps sage should be a little more careful about what python interpreter it chooses and be a bit more explicit about it (or at least have an option for that)?. I don't know if "python" is the problem]

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 1:42:58 PM UTC-7 Nils Bruin wrote:

I've noticed that after a modest upgrade (just "dnf update"), with some regularity sage breaks. In the most recent edition, "libflint.so" couldn't be found.

I guess there is some prerequisite that sage was relying on to be provided by the operating system was changed?

When system packages no longer need a specific old version of a shared library, then the system package manager may remove that version.

It does not know about user-built programs that link to system libraries. That's not Sage-specific.

Perhaps there is a way to stop dnf or other package managers from removing unused library packages?

That would be worth investigating.

Is sage relying on the system python nowadays?

Yes.

[Matthias Koeppe]

https://www.reddit.com/r/Fedora/comments/3pqrv9/dnf_remove_package_keep_dependencies/

[Dima Pasechnik]

On Wed, Jul 20, 2022 at 9:43 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
> I've noticed that after a modest upgrade (just "dnf update"), with some regularity sage breaks. In the most recent edition, "libflint.so" couldn't be found.
>
> I guess there is some prerequisite that sage was relying on to be provided by the operating system was changed? Is sage relying on the system python nowadays?

by default, Sage will be using the system python3, sure.
And gmp, flint, ntl, mpfr, arb, pari, ecl, singular, R, glpk, etc etc etc

On a recent Fedora on a newish desktop building, docs included, from
scratch, with all the usable system packages, takes less than an hour.

>
> The only way I have found to clean this up is by doing a "make distclean", which makes for quite a heavy rebuild process! Is there a more modest approach?


>
> It's nice that we're integrating better with OS-supplied prerequisites, but it mixes very badly with building from source on an actual system one works on:
>
> I can see the nightmare scenario where you've run a small system update (as one should do to keep up-to-date with vulnerabilities) in the evening (or perhaps your computer did it for you!) and the next morning you arrive in front of the class with a demo where you now discover that sage is broken and requires an hour's worth of build time to get up to snuff again.
>
> Is there a better/safer way of having both an up-to-date system and a reliable sage install?

As Matthias wrote, it's not Sage specific, and if the ABI of the
system package changes, then yes, the relevant part has to be rebuilt.

>
> [Is the problem perhaps that fedora bumps the default "python" to a newer version for which sage doesn't have its libraries built/accessible? In that case: fedora doesn't delete older versions. I can still run python3.9 or python3.8. So in that case perhaps sage should be a little more careful about what python interpreter it chooses and be a bit more explicit about it (or at least have an option for that)?. I don't know if "python" is the problem]


>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d46378df-8652-45d4-96f9-ced715d8ec6cn%40googlegroups.com.

[Nils Bruin]

On Wednesday, 20 July 2022 at 14:01:25 UTC-7 dim...@gmail.com wrote:

by default, Sage will be using the system python3, sure.
And gmp, flint, ntl, mpfr, arb, pari, ecl, singular, R, glpk, etc etc etc

so .. the rebuild of sage indeed worked; with "make -j8" it timed it at 8 minutes (after distclean), with hurricane-force fan action on my laptop. In a classroom situation, 8 minutes is an eternity (never mind that one would not even *start* recompiling during a class)

Mind you: I did not change/reinstall any system packages. It looks like sage simply "lost" the connection to some of them (libflint in particular, apparently. That's the error sage exited on). So it's not that dependencies were inadvertently removed.

 

As Matthias wrote, it's not Sage specific, and if the ABI of the
system package changes, then yes, the relevant part has to be rebuilt.

I don't think that's what's happened, though. The "libflint.so" I have is way older than the update that broke sage. So there's something else that broke sage. I don't even know where to start tracing down what went wrong (and the traces of that have probably been erased by the rebuild anyway). I just need a way of installing sage that gives me something reliable. If that means something statically linked or otherwise localized, so be it. It's nice that development is progressing towards a way that sage is properly integrated and that "dnf install sagemath" just works, but I don't think we're there yet (or at least not for a sagemath that's sort-of usable).

In the mean time, we do need a way of reliably running sage. We can't really first scuttle "sage the distribution" and then build "sage the properly integrated app". As long as the properly integrated app isn't quite working yet, we need to maintain "sage the distribution".

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 2:59:26 PM UTC-7 Nils Bruin wrote:

[...] progressing towards a way that sage is properly integrated and that "dnf install sagemath" just works

That actually works but has nothing to do with the Sage distribution. 

Fedora has an up to date distribution package of SageMath in Fedora 36 thanks to the Fedora package maintainer. https://repology.org/project/sagemath/versions

 

[Nils Bruin]

I'm pretty sure that if a package has been "dnf install"-ed, then it's considered desired, and not just there as a prerequisite. So preventing libraries from being removed should be as simple as including the requisite package in the recommended "dnf install ..." as written at:

https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation

(it's probably good if that gets updated with "dnf" instead of "yum" -- that change happened around 2015!)

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 2:59:26 PM UTC-7 Nils Bruin wrote:

On Wednesday, 20 July 2022 at 14:01:25 UTC-7 dim...@gmail.com wrote:

by default, Sage will be using the system python3, sure.
And gmp, flint, ntl, mpfr, arb, pari, ecl, singular, R, glpk, etc etc etc

so .. the rebuild of sage indeed worked; with "make -j8" it timed it at 8 minutes (after distclean), with hurricane-force fan action on my laptop. In a classroom situation, 8 minutes is an eternity (never mind that one would not even *start* recompiling during a class)

Mind you: I did not change/reinstall any system packages.

You said you did "dnf update". That's what it does, it changes system packages.

 

[Dima Pasechnik]

On Wed, Jul 20, 2022 at 10:59 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
> On Wednesday, 20 July 2022 at 14:01:25 UTC-7 dim...@gmail.com wrote:
>>
>>
>> by default, Sage will be using the system python3, sure.
>> And gmp, flint, ntl, mpfr, arb, pari, ecl, singular, R, glpk, etc etc etc
>>
> so .. the rebuild of sage indeed worked; with "make -j8" it timed it at 8 minutes (after distclean), with hurricane-force fan action on my laptop. In a classroom situation, 8 minutes is an eternity (never mind that one would not even *start* recompiling during a class)
>
> Mind you: I did not change/reinstall any system packages. It looks like sage simply "lost" the connection to some of them (libflint in particular, apparently. That's the error sage exited on). So it's not that dependencies were inadvertently removed.
>
>>
>> As Matthias wrote, it's not Sage specific, and if the ABI of the
>> system package changes, then yes, the relevant part has to be rebuilt.
>
>
> I don't think that's what's happened, though. The "libflint.so" I have is way older than the update that broke sage. So there's something else that broke sage. I don't even know where to start tracing down >what went wrong (and the traces of that have probably been erased by the rebuild anyway). I just need a way of installing sage that gives me something reliable.

It seems that the correct way to use "system" packages in an
upgradeable way is to make sure that Sage is such a package itself.
Here "system" means either your OS, or Conda.
And Conda comes with a quite fresh version of Sage, so it looks as if
it might be what you want.

> If that means something statically linked or otherwise localized,
so be it. It's nice that development is progressing towards a way that
sage is properly integrated and that "dnf install sagemath" just
works, but I don't think we're there yet (or at least not for a
sagemath that's sort-of usable).
>
> In the mean time, we do need a way of reliably running sage. We can't really first scuttle "sage the distribution" and then build "sage the properly integrated app". As long as the properly integrated app isn't quite working yet, we need to maintain "sage the distribution".

Conda provides a good enough "sage the properly integrated app", IMHO.

Dima

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bf3e6d04-2d98-4c15-a685-703ad0e58c52n%40googlegroups.com.

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 3:05:44 PM UTC-7 Nils Bruin wrote:

I'm pretty sure that if a package has been "dnf install"-ed, then it's considered desired, and not just there as a prerequisite.

Yes, but you likely did "dnf install libflint-devel". The shared library package, in some version, is merely a dependency.

https://fedora.pkgs.org/36/fedora-updates-aarch64/flint-devel-2.9.0-1.fc36.aarch64.rpm.html

Current is the package "libflint.so.17". On an update of your system, dnf replaced the previous package,  likely libflint.so.16.

 

[Nils Bruin]

On Wednesday, 20 July 2022 at 15:06:09 UTC-7 Matthias Koeppe wrote:

You said you did "dnf update". That's what it does, it changes system packages.

 

It's also what people are encouraged to run quite regularly in order for vulnerabilities to be fixed on a reasonable time scale.

A source install of sagemath should be sort-of usable across that. In the present setup it seems it needs a big disclaimer that sage needs to be rebuilt after any system update? That's a little impractical. Isn't there at least something that can systematically check which dependencies are still in place and which are not, and then just rebuild what's necessary? Then at least, most of the time, the rebuild isn't hugely onerous.

It looks like currently sage is not properly fixing the foundations of its prerequisites.

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 3:20:25 PM UTC-7 Nils Bruin wrote:

 Isn't there at least something that can systematically check which dependencies are still in place and which are not, and then just rebuild what's necessary?

Yes, I think we can do that. I have opened https://trac.sagemath.org/ticket/34203 for this.

[Matthias Koeppe]

On Wednesday, July 20, 2022 at 3:20:25 PM UTC-7 Nils Bruin wrote:

It looks like currently sage is not properly fixing the foundations of its prerequisites.

If you want integration with your system package manager, use the sagemath package from that repository.

[Matthias Koeppe]

An implementation of this (for macOS) is now on the ticket

 

[Nils Bruin]

In that case, shouldn't sagemath be linking to libflint.so instead of libflint.so.16 then? That's the thing that seems to be available between the different versions. Are they not ABI compatible? (or at least in one direction)?

[Nils Bruin]

It seems that the correct way to use "system" packages in an
upgradeable way is to make sure that Sage is such a package itself.
Here "system" means either your OS, or Conda.
And Conda comes with a quite fresh version of Sage, so it looks as if
it might be what you want.

I'm pretty sure "OS-packaged" is not suitable for development (modification of, for instance, sagelib code; checking in/out tickets). Is Conda?

[Antonio Rojas]

El jueves, 21 de julio de 2022 a las 7:32:59 UTC+2, Nils Bruin escribió:

In that case, shouldn't sagemath be linking to libflint.so instead of libflint.so.16 then? That's the thing that seems to be available between the different versions. Are they not ABI compatible? (or at least in one direction)?

They are not, that's exactly the point of library soversions. The soversion, if correctly used, is bumped when a release contains some ABI incompatible change that requires a rebuild of consumers. So you can't just link to the .so symlink, that would just defeat the point. 

[Dima Pasechnik]

you can install Conda packages (including Python packages - which makes buildiing very quick) used by Sage, and build sagelib from source using them.

But needless to say, you'd still need a rebuild after package updates, although you can just avoid updating Conda environment, I gather.

This seems to be orthogonal to having stable Sage, though.

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a8e37b2a-c48a-4fcd-955f-7f8e7f4d5500n%40googlegroups.com.

[Matthias Koeppe]

This is documented in https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda-develop

[Nils Bruin]

On Wednesday, 20 July 2022 at 23:33:09 UTC-7 Antonio Rojas wrote:

They are not, that's exactly the point of library soversions. The soversion, if correctly used, is bumped when a release contains some ABI incompatible change that requires a rebuild of consumers. So you can't just link to the .so symlink, that would just defeat the point. 

Ah boy, that explains why packaging binary software for linux distributions is such a complicated task. For binary distributions,  even FC36 isn't a stable target! Is that a Fedora-specific disease or do other distribution just push ABI-incompatible changes within a release as well? A binary distribution really does need to include all libraries.

It sounds like Conda is the next "distribution within a distribution" that can isolate sagemath from the shifting ABI foundations the OS offers (in cases where using a distribution-offered sagemath isn't tracking close enough).

It also sounds like sagemath has now matured to the point where development requires to have two installs: one "production" version, possibly the OS-packaged one [that might as well be binary] and one built-from-source one that should either be properly sandboxed in an environment where the prerequisites are ensured to be stable or where one accepts that arbitrary rebuilds (including a distclean build) may be necessary. It's unfortunate that the plain "pull from git and build from source" days of sage are over ... and that it's basically unreliable for *any* software out there.

 

[Matthias Koeppe]

On Thursday, July 21, 2022 at 11:14:13 AM UTC-7 Nils Bruin wrote:

On Wednesday, 20 July 2022 at 23:33:09 UTC-7 Antonio Rojas wrote:

They are not, that's exactly the point of library soversions. The soversion, if correctly used, is bumped when a release contains some ABI incompatible change that requires a rebuild of consumers. So you can't just link to the .so symlink, that would just defeat the point. 

Ah boy, that explains why packaging binary software for linux distributions is such a complicated task. For binary distributions,  even FC36 isn't a stable target! Is that a Fedora-specific disease or do other distribution just push ABI-incompatible changes within a release as well? A binary distribution really does need to include all libraries.

You really just need to stop your distribution from automatically uninstalling the old shared library packages when you do upgrades. Both the old version (needed for your from-source installation of Sage) and the new version (needed as dependencies of upgraded system packages) can coexist in your system.

development requires to have two installs: one "production" version, possibly the OS-packaged one [that might as well be binary] and one built-from-source one that should either be properly sandboxed in an environment where the prerequisites are ensured to be stable or where one accepts that arbitrary rebuilds (including a distclean build) may be necessary.

Definitely. Basically, don't bring a random development build to the classroom.

 

[Nils Bruin]

On Thursday, 21 July 2022 at 11:31:35 UTC-7 Matthias Koeppe wrote:

You really just need to stop your distribution from automatically uninstalling the old shared library packages when you do upgrades. Both the old version (needed for your from-source installation of Sage) and the new version (needed as dependencies of upgraded system packages) can coexist in your system.

Right .. but that would require telling the system which libraries need to be preserved ... I guess one could collect the dependencies by a liberal ldd application, but then one would need to query the package manager which packages provide the requisite library files and then somehow register those packages *are* dependencies ... I guess that could be done by building a placeholder package (rpm or deb) that declares all the specific dependencies. And to "declare" these, one could install that package. Upon a reconfigure+rebuild, one could uninstall the old placeholder, recompute the new dependencies, and install a new placeholder ...

Conda looks like it has potential too, provided the " pip install --no-build-isolation -v -v --editable src" can somehow be overlaid with the git-managed repository and have git-trac configuration with it? Then that could make for a reasonable development environment. It's presently unclear to me (but that's probably just inexperience) whether a "production" conda build could co-exist with a "development" conda build: is "conda activate" something local or does it change the global state of conda (e.g., is it possible to have different conda environments activated in different concurrent processes)?

[Matthias Koeppe]

I have opened https://trac.sagemath.org/ticket/34207 with the goal of adding documentation on best practices. Help welcome

[Matthias Koeppe]

On Thursday, July 21, 2022 at 11:52:42 AM UTC-7 Nils Bruin wrote:

somehow register those packages *are* dependencies ... I guess that could be done by building a placeholder package (rpm or deb) that declares all the specific dependencies. And to "declare" these, one could install that package. Upon a reconfigure+rebuild, one could uninstall the old placeholder, recompute the new dependencies, and install a new placeholder ...

Basically you are entering downstream territory. You maintain a private version of the Fedora sagemath package based on your current branch.

[Matthias Koeppe]

On Thursday, July 21, 2022 at 11:52:42 AM UTC-7 Nils Bruin wrote:

Conda looks like it has potential too,

I'd say that's an understatement

 

It's presently unclear to me [...] whether a "production" conda build could co-exist with a "development" conda build: is "conda activate" something local or does it change the global state of conda (e.g., is it possible to have different conda environments activated in different concurrent processes)?

Yes, "conda activate" only sets environment variables.

 

[Tomoaki Sato]

I have no idea what really happens in Fedora 36,

but I have had no problems with Sagemath 9.5 (installed from the source) on Fedora 35 for several months.

Of course, I have made "dnf update" a lot of times meanwhile.

(I have installed Fedora 35 on VMware workstation.)

Now, I use Fedora remix for WSL. This corresponds to Fedora 36, and I have installed Sagemath (9.6)

with "dnf install sagemath."

　

Tomoaki Sato (CXN0...@nifty.ne.jp)

---

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b8ce6c6e-7054-4558-98b7-bf373bd14857n%40googlegroups.com.

[Emmanuel Charpentier]

FWIW, the very same mishap just happened to me on Debian.testing.

What I fail to understand is why Sake was linked to a specific version of libflint.so, rather than to the generic version…

​

Le mercredi 20 juillet 2022 à 22:42:58 UTC+2, Nils Bruin a écrit :

I've noticed that after a modest upgrade (just "dnf update"), with some regularity sage breaks. In the most recent edition, "libflint.so" couldn't be found.

I guess there is some prerequisite that sage was relying on to be provided by the operating system was changed? Is sage relying on the system python nowadays?

The only way I have found to clean this up is by doing a "make distclean", which makes for quite a heavy rebuild process! Is there a more modest approach?

It's nice that we're integrating better with OS-supplied prerequisites, but it mixes very badly with building from source on an actual system one works on:

I can see the nightmare scenario where you've run a small system update (as one should do to keep up-to-date with vulnerabilities) in the evening (or perhaps your computer did it for you!) and the next morning you arrive in front of the class with a demo where you now discover that sage is broken and requires an hour's worth of build time to get up to snuff again.

Is there a better/safer way of having both an up-to-date system and a reliable sage install?

[Dima Pasechnik]

On Sat, 23 Jul 2022, 20:31 Emmanuel Charpentier, <emanuel.c...@gmail.com> wrote:

FWIW, the very same mishap just happened to me on Debian.testing.

What I fail to understand is why Sake was linked to a specific version of libflint.so, rather than to the generic version…

Because the specific versions are not compatible with each other, and this is the very reason to do the version bump dance.

​

Le mercredi 20 juillet 2022 à 22:42:58 UTC+2, Nils Bruin a écrit :

I've noticed that after a modest upgrade (just "dnf update"), with some regularity sage breaks. In the most recent edition, "libflint.so" couldn't be found.

I guess there is some prerequisite that sage was relying on to be provided by the operating system was changed? Is sage relying on the system python nowadays?

The only way I have found to clean this up is by doing a "make distclean", which makes for quite a heavy rebuild process! Is there a more modest approach?

It's nice that we're integrating better with OS-supplied prerequisites, but it mixes very badly with building from source on an actual system one works on:

I can see the nightmare scenario where you've run a small system update (as one should do to keep up-to-date with vulnerabilities) in the evening (or perhaps your computer did it for you!) and the next morning you arrive in front of the class with a demo where you now discover that sage is broken and requires an hour's worth of build time to get up to snuff again.

Is there a better/safer way of having both an up-to-date system and a reliable sage install?

[Is the problem perhaps that fedora bumps the default "python" to a newer version for which sage doesn't have its libraries built/accessible? In that case: fedora doesn't delete older versions. I can still run python3.9 or python3.8. So in that case perhaps sage should be a little more careful about what python interpreter it chooses and be a bit more explicit about it (or at least have an option for that)?. I don't know if "python" is the problem]

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5b10fce5-a79e-4c55-af96-ee26f0f1039bn%40googlegroups.com.

[Matthias Koeppe]

"make list-broken-packages" now works both on macOS and Linux - https://trac.sagemath.org/ticket/34203 (needs review)

[Nils Bruin]

On Thursday, 21 July 2022 at 11:52:42 UTC-7 Nils Bruin wrote:

On Thursday, 21 July 2022 at 11:31:35 UTC-7 Matthias Koeppe wrote:

You really just need to stop your distribution from automatically uninstalling the old shared library packages when you do upgrades. Both the old version (needed for your from-source installation of Sage) and the new version (needed as dependencies of upgraded system packages) can coexist in your system.

Right .. but that would require telling the system which libraries need to be preserved ... I guess one could collect the dependencies by a liberal ldd application, but then one would need to query the package manager which packages provide the requisite library files and then somehow register those packages *are* dependencies ... I guess that could be done by building a placeholder package (rpm or deb) that declares all the specific dependencies. And to "declare" these, one could install that package. Upon a reconfigure+rebuild, one could uninstall the old placeholder, recompute the new dependencies, and install a new placeholder ...

Ouch ... and it looks like this wouldn't even work: if I try

dnf whatprovides /usr/lib64/libflint.so.17

I get:

flint-2.9.0-1.fc36.x86_64

and similarly

dnf whatprovides /usr.lib64/libflint.so.16

flint-2.8.4-2.fc36.x86_64

Hence, if a compiled-from-source sagemath were to declare its dependencies to the package manager it would have to do so by depending on a *specific version* of flint, and hence "updating" flint should lead to a dependency conflict. As long as fedora doesn't allow two different version of flint to be installed at the same time (and the fact that flint-2.9 "upgrades" flint-2.8 suggests that it won't), we'd need a version lock: just keeping an unmanaged so-file hang around in space that's supposed to be managed by a package manager would lead to a rather messy system state.

So, based on that, I think build-from-source using these kinds of system resources should actually *not* be a recommended install method: build-from-source should have its less stable prerequisites satisfied by some separate environment -- possibly/likely conda. Resources/libraries such as libflint are clearly *only* managed and provided by the OS in a way that is appropriate for other OS-managed/packaged software. Turns out there's still a niche for sage-the-distribution; possibly replaced by sage-in-conda-the-distribution. Can we get sage-on-conda modified so that it works nicely with git-trac, so that a sage-conda container can be used for development? I would be very interested in a guide to that.

 

[Matthias Koeppe]

On Monday, July 25, 2022 at 12:44:20 PM UTC-7 Nils Bruin wrote:

Can we get sage-on-conda modified so that it works nicely with git-trac, so that a sage-conda container can be used for development? I would be very interested in a guide to that.

Have you tried the existing instructions that I pointed you to?

[Matthias Koeppe]

On Monday, July 25, 2022 at 12:44:20 PM UTC-7 Nils Bruin wrote:

As long as fedora doesn't allow two different version of flint to be installed at the same time

It does allow two different versions of the shared library package to be installed. 

Please see https://trac.sagemath.org/ticket/34207

 

[Matthias Koeppe]

On Monday, July 25, 2022 at 12:44:20 PM UTC-7 Nils Bruin wrote:

 I think build-from-source using these kinds of system resources should actually *not* be a recommended install method:

The installation guide (https://doc.sagemath.org/html/en/installation/index.html) only recommends it to people who want to do SageMath development. Take a look

 

 

[Nils Bruin]

OK, that at least helps a bit. But how do you query the package management system to report those specific packages as "owner" of the so file, i.e., how do you find the packages that need to be pinned? I thought "dnf whatprovides" would do that, but it reports the generic libflint package. In fact, I've not been able to find the version-specific rpm's at all (if I do "dnf search flint" these things do not show up). I was expecting that flint would have one of those version-specific packages as a dependency and that they simply changed the dependency to bump the version, but it looks like that's not how they do it: as far as I can tell,  /usr/lib64/libflint.so.17 is really owned by flint-2.9.0-1.fc36.x86_64 and nothing else.

[Nils Bruin]

Well, I looked at the instructions and found:

"Installing all of SageMath from conda (not for development)"

and not a corresponding section "Installing SageMath in/from conda for development". That's the part that isn't addressed in the guide pointed to. I'd expect sage to be pulled from a sagemath repository to be suitable for git-trac workflows, not from conda.

[Matthias Koeppe]

https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda-develop

links to a different section, namely "Using conda to provide all dependencies for the Sage library (experimental)"
Read that

[Nils Bruin]

On Monday, 25 July 2022 at 18:55:54 UTC-7 Matthias Koeppe wrote:

https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda-develop

links to a different section, namely "Using conda to provide all dependencies for the Sage library (experimental)"
Read that

Ah, OK. so: pull sagemath source as usual, activate conda, then build in some conda-specific way. It still requires conda, which dnf provides ... but I guess if I pull it from there we'll have the same version problems if fedora decides to upgrade conda? Or would "created" environments persist from one conda version to the next?

[Matthias Koeppe]

On Monday, July 25, 2022 at 6:39:35 PM UTC-7 Nils Bruin wrote:

I've not been able to find the version-specific rpm's at all (if I do "dnf search flint" these things do not show up). [...] as far as I can tell,  /usr/lib64/libflint.so.17 is really owned by flint-2.9.0-1.fc36.x86_64 and nothing else.

You are right. I have to retract my claim regarding Fedora. I'll update https://trac.sagemath.org/ticket/34207 accordingly

# dnf install 'libflint.so.16()(64bit)' 'libflint.so.17()(64bit)'

Last metadata expiration check: 0:04:24 ago on Tue Jul 26 02:02:49 2022.
Error: 

 Problem: cannot install both flint-2.9.0-1.fc36.x86_64 and flint-2.8.4-2.fc36.x86_64

  - conflicting requests

 

[Matthias Koeppe]

I don't have experience with the Fedora-packaged conda package manager. I'm not sure if that is widely used.

At the top of https://doc.sagemath.org/html/en/installation/conda.html#install-from-conda-forge we have instructions how to install conda as a user.

conda environments persist -- and normally have nothing to do with the system package manager's packages. All installed packages are coming from conda channels (our instructions have you use the conda-forge channel).

The trick with conda is that you can have many environments -- typically one per "project". When you update one, the others are not changed, so they will continue to work.

You can still break things by making unattended updates within an environment, of course.

[Nils Bruin]

On Monday, 25 July 2022 at 12:53:08 UTC-7 Matthias Koeppe wrote:

Have you tried the existing instructions that I pointed you to?

I have now. I'm stuck on running configure.

 * the ./configure command suggested doesn't work in my bash. I'm getting:

 bash: unexpected EOF while looking for matching `)'

Instead I split it up a bit:

$ for pkg in $(./sage -package list :standard:     \
                               --has-file spkg-configure.m4      \
                               --has-file distros/conda.txt); do                     echo --with-system-$pkg=force; done > with

$ ./configure --with-python=$CONDA_PREFIX/bin/python --prefix=$CONDA_PREFIX  `cat with`

That seemed to succeed in running configure, but resulted in an error:

configure: error:

    Given --with-system-eclib=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-eclib)
    Given --with-system-primesieve=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-primesieve)
    Given --with-system-primecount=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-primecount)

[Dima Pasechnik]

this says that conda is behind Sage in regard of versions of eclib
and primesieve/count

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f432a44d-fa4b-4ae9-855c-91219258f2bcn%40googlegroups.com.

[John Cremona]

On Tue, 26 Jul 2022 at 08:13, Dima Pasechnik <dim...@gmail.com> wrote:
>
> On Tue, Jul 26, 2022 at 8:24 AM Nils Bruin <nbr...@sfu.ca> wrote:
> >
> > On Monday, 25 July 2022 at 12:53:08 UTC-7 Matthias Koeppe wrote:
> >>
> >> Have you tried the existing instructions that I pointed you to?
> >
> >
> > I have now. I'm stuck on running configure.
> >
> > * the ./configure command suggested doesn't work in my bash. I'm getting:
> > bash: unexpected EOF while looking for matching `)'
> >
> > Instead I split it up a bit:
> > $ for pkg in $(./sage -package list :standard: \
> > --has-file spkg-configure.m4 \
> > --has-file distros/conda.txt); do echo --with-system-$pkg=force; done > with
> > $ ./configure --with-python=$CONDA_PREFIX/bin/python --prefix=$CONDA_PREFIX `cat with`
> > That seemed to succeed in running configure, but resulted in an error:
> > configure: error:
> >
> > Given --with-system-eclib=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-eclib)
> > Given --with-system-primesieve=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-primesieve)
> > Given --with-system-primecount=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-primecount)
>
> this says that conda is behind Sage in regard of versions of eclib

For what it's worth, Nils, Sage's eclib was recently updated: not
major but a bugfix. See https://trac.sagemath.org/ticket/34029.

John

> and primesieve/count
>
> >
> > --
> > You received this message because you are subscribed to the Google Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f432a44d-fa4b-4ae9-855c-91219258f2bcn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3bUXCivTEz7tmJSXnVf9auBQtg_bDPfOYmiKUX4EPaHA%40mail.gmail.com.

[Samuel Lelievre]

2022-07-26 07:13:30 UTC, Dima Pasechnik:

this says that conda is behind Sage in regard of versions of eclib
and primesieve/count

- eclib upgrade in Conda now done:

  https://github.com/conda-forge/eclib-feedstock/pull/36

- primesieve and primecount seem up to date

[William Stein]

For CoCalc, where we have a bunch of different specific versions of
Sage pre-installed that all stay stable over *years*, we run a 1-2
pages long "./configure ..." command before I even do "make". At the
top it starts with

--with-system-python3=no \
--with-system-r=no \
--with-system-primecount=no \
--with-system-primesieve=no \
--with-system-qhull=no \
--with-system-cmake=no \
...
… so,that's why R, Python interpreter, and other stuff is independent. …

We should definitely check if there is more I could make independent.
I mean, technically it's not independent, because some underlying libs
are shared, but there are certainly less surprises and the dependency
graph is not a wide blinking christmas tree. What we are not doing is
sharing Sage across linux editions. i.e. 20.04 will have a couple of
Sage installs and with 22.04 there will be a new 9.6 one. But that's
not the issue in the thread.

Could there be a single option to the Sage build system such as:
"--without-system" that disables all system libraries, and hence
behaves exactly like Sage used to? Is there already such an option
that I don't know about?

William

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6aea8da4-bd04-4eda-914a-c04a6fcbb4e6n%40googlegroups.com.



--
William (http://wstein.org)

[Marc Culler]

I think that --without-system would be a very nice thing to have.

The macOS SageMath binary is completely self-contained.  Every shared library used by every component of the SageMath app is contained within the Sage.framework embedded in the app, except for runtime libraries provided by Apple on all systems.  All LC_LOAD_DYLIB load commands for libraries other than the runtime libraries begin with @rpath and all LC_RPATH load command begins with @loader_path or @executable_path.  This allows specifying libraries with a relative path.  For example, here are the LC_LOAD_DYLIB and LC_RPATH load commands for libecl.dylib as installed in the SageMath app:

    LC_LOAD_DYLIB: @rpath/libgmp.10.dylib
    LC_LOAD_DYLIB: @rpath/libgc.1.dylib
    LC_LOAD_DYLIB: /usr/lib/libffi.dylib
    LC_LOAD_DYLIB: /usr/lib/libSystem.B.dylib
    LC_RPATH: @loader_path

Apple will not notarize an application or framework bundle which has an rpath that points outside of the bundle, so this design is required in order to produce a signed and notarized SageMath application bundle.  And in order for the app to run on every system there must not be any dependency on any external library unless it is guaranteed that the library exists on every system.

Currently I have to work pretty hard to make sure that Sage does not try to "borrow" any libraries installed on my build system which might not be installed on a user's system.  Basically I have to make sure that /usr/local and /opt are completely empty on the build systems.  (There is currently a special exception for the homebrew gfortan libraries on arm64 systems.  These have to be used for the build and are then copied into the app after modifying their LC_LOAD_DYLIB and LC_RPATH load commands.)

It would be nice to have a guarantee that the Sage build will stay inside its sandbox.  That might even make it possible to build the macOS binary on a CI runner.

- Marc

[Matthias Koeppe]

On Tuesday, July 26, 2022 at 6:47:47 AM UTC-7 wst...@gmail.com wrote:

For CoCalc, [...] we run a 1-2

pages long "./configure ..." command before I even do "make". At the
top it starts with

--with-system-python3=no \
--with-system-r=no \
--with-system-primecount=no \
--with-system-primesieve=no \
--with-system-qhull=no \
--with-system-cmake=no \

[...]

Could there be a single option to the Sage build system such as:
"--without-system" that disables all system libraries

That's https://trac.sagemath.org/ticket/33345

 

[Nils Bruin]

Yup, rerunning "mamba env update -n sage-build -f src/environment.yml" installed eclib and now "./configure ..." produces one less error:

configure: error:

    Given --with-system-primesieve=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-primesieve)
    Given --with-system-primecount=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-primecount)

The documentation section about this is  marked "experimental", and I think this shows it's indeed not ready for prime time yet.

It sounds like https://trac.sagemath.org/ticket/33345 would also solve the problem of depending on prone-to-change system libraries. Is that perhaps the route to go for development nowadays? Then there's no conda/mamba to worry about at all.

[Matthias Koeppe]

On Tuesday, July 26, 2022 at 2:08:32 PM UTC-7 Nils Bruin wrote:

configure: error:

    Given --with-system-primesieve=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-primesieve)
    Given --with-system-primecount=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-primecount)

The documentation section about this is  marked "experimental", and I think this shows it's indeed not ready for prime time yet.

Whether the method described in section https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental works always depends on the conda package maintainers providing packages that are up to date with respect to our requirements. It's not directly under control of our project. 

 

[Nils Bruin]

On Tuesday, 26 July 2022 at 15:58:18 UTC-7 Matthias Koeppe wrote:

Whether the method described in section https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental works always depends on the conda package maintainers providing packages that are up to date with respect to our requirements. It's not directly under control of our project. 

Hm ... so I guess "configure"  with these "--with-system-*=true/false/force" can then determine per-prerequisite whether to try to get it from the system or build it by itself? And that the advantage of conda is that it can distribute binaries, that are then hopefully built with approrpriate flags for your particular system? And that the hope is that conda-provided prereqs are a better match than what the OS may provide and/or are more stable (mainly because one can afford to not update a conda env regularly).

Is it possible for prerequisites that conda fails at, such as primesieve and primecount, to flick the "with-system" switches the other way, so that sage builds that by itself? Is there a way to tell the system to get from conda what it can and otherwise build it by itself? It seems like that's what configure does normally (and with a WAY shorter configure command!), so would it be able to do that within conda? It would seem that after:

$ conda env update --file environment.yml -n sage-build

(which is I think one of the commands where using mamba instead saves gobs of time!!!) conda has already exerted its best efforts to satisfy the prereqs, so anything that now fails should be built by sage itself ...

[Matthias Koeppe]

On Tuesday, July 26, 2022 at 5:12:47 PM UTC-7 Nils Bruin wrote:

On Tuesday, 26 July 2022 at 15:58:18 UTC-7 Matthias Koeppe wrote:

Whether the method described in section https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental works always depends on the conda package maintainers providing packages that are up to date with respect to our requirements. It's not directly under control of our project. 

Hm ... so I guess "configure"  with these "--with-system-*=true/false/force" can then determine per-prerequisite whether to try to get it from the system or build it by itself?

 

And that the advantage of conda is that it can distribute binaries, that are then hopefully built with approrpriate flags for your particular system?

The binaries are not any more tailored to your system than the binaries from the Fedora distribution are.

 

And that the hope is that conda-provided prereqs are a better match than what the OS may provide and/or are more stable (mainly because one can afford to not update a conda env regularly).

... and you can use conda on machines where you are not root.

 

Is it possible for prerequisites that conda fails at, such as primesieve and primecount, to flick the "with-system" switches the other way, so that sage builds that by itself? Is there a way to tell the system to get from conda what it can and otherwise build it by itself? It seems like that's what configure does normally (and with a WAY shorter configure command!), so would it be able to do that within conda? 

Sort of. This is another way to build Sage with conda. It is described in the 2nd of the 3 sections on the same page, https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-system-packages-for-the-sage-distribution, "Using conda to provide system packages for the Sage distribution". This works in the same way that it does on top of Fedora, or on top of any other package distribution. You can control what packages are taken from the system and what packages are built by the Sage distribution. And it has the same restrictions as what the Sage distribution does on top of Fedora etc.: Only packages for which we have "spkg-configure.m4" scripts can be taken from the system -- and no Python packages can be taken from the system.

[Nils Bruin]

On Tuesday, 26 July 2022 at 17:27:11 UTC-7 Matthias Koeppe wrote:

Sort of. This is another way to build Sage with conda. It is described in the 2nd of the 3 sections on the same page, https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-system-packages-for-the-sage-distribution, "Using conda to provide system packages for the Sage distribution". This works in the same way that it does on top of Fedora, or on top of any other package distribution. You can control what packages are taken from the system and what packages are built by the Sage distribution. And it has the same restrictions as what the Sage distribution does on top of Fedora etc.: Only packages for which we have "spkg-configure.m4" scripts can be taken from the system -- and no Python packages can be taken from the system.

Ah, so that sounds like it's a lot closer to how most people have the build-environment organized. Things like not having to issue "sage -b" after making a little edit will be nice to have eventually, but it looks like that stuff is still too much in flux to be reliable at the moment.

 

[Matthias Koeppe]

On Tuesday, July 26, 2022 at 5:34:07 PM UTC-7 Nils Bruin wrote:

Things like not having to issue "sage -b" after making a little edit will be nice to have eventually,

This feature (editable installs) is actually orthogonal to the decision on the conda install method.

You can activate it using "configure --enable-editable", and it is slated to become default in one of next betas (see https://trac.sagemath.org/ticket/32406).

 

[Samuel Lelièvre]

2022-07-27 00:27 UTC, Matthias Koeppe:

>
> Only packages for which we have "spkg-configure.m4" scripts
> can be taken from the system

More and more packages have such scripts. Many thanks to
people who authored and reviewed the corresponding tickets:

https://trac.sagemath.org/query?order=id&desc=1&status=closed&max=200&summary=~spkg-configure&summary=~spkg_configure&col=id&col=summary&col=author&col=reviewer&col=milestone

Remaining open tickets in that direction:

https://trac.sagemath.org/query?order=id&desc=1&status=!closed&summary=~spkg-configure&summary=~spkg_configure

[Isuru Fernando]

Hi Nils,

Can you give me the commands that you did to get the primesive/conda error? I'd like to fix that.

Isuru

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAEcArF3TxCfYPbRWvrxNyyMqg61GA7s4qz%2BEhXQoB_ziKgg6iw%40mail.gmail.com.

[Nils Bruin]

Hi Isuru,

I followed https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda-develop

except that for my bash,  the long compound "configure" invocation didn't work (is that even correct bash symtax? my shell is pretty vanilla, so I'd be surprised if my shell rejects syntax that others accept. I suspect the nested "$(...$(...)...)" made it fail ) so I broke it up as referenced in https://groups.google.com/g/sage-devel/c/Iz8ZsmQM3Pg/m/dgiXcfOhAQAJ :

$ for pkg in $(./sage -package list :standard:     \
                               --has-file spkg-configure.m4      \
                               --has-file distros/conda.txt); do  echo --with-system-$pkg=force; done > with

$ ./configure --with-python=$CONDA_PREFIX/bin/python --prefix=$CONDA_PREFIX  `cat with`

That then produced the two errors.

[Isuru Fernando]

Hi Nils,

We need to rebuild primecount for the latest primesieve version. That's why an older primesieve version was used.

I've opened a PR at https://github.com/conda-forge/primecount-feedstock/pull/7

Can you try in a couple of hours and report back?

Isuru

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ceecb0f0-e4cb-4cbd-a730-163b2db53b39n%40googlegroups.com.

[Nils Bruin]

On Wednesday, 3 August 2022 at 23:41:02 UTC-7 isu...@gmail.com wrote:

Can you try in a couple of hours and report back?

Yes, this time it looks like the instructions led to a successful build! Nice.