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
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.
[...] progressing towards a way that sage is properly integrated and that "dnf install sagemath" just works
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.
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.
You said you did "dnf update". That's what it does, it changes system packages.
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?
It looks like currently sage is not properly fixing the foundations of its prerequisites.
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.
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)?
--
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.
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.
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.
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.
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.
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,
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)?
--
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.
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…
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?
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?[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.
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 ...
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.
As long as fedora doesn't allow two different version of flint to be installed at the same time
I think build-from-source using these kinds of system resources should actually *not* be a recommended install method:
https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda-developlinks to a different section, namely "Using conda to provide all dependencies for the Sage library (experimental)"
Read that
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.
# 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
Have you tried the existing instructions that I pointed you to?
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
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.
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?
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.
Things like not having to issue "sage -b" after making a little edit will be nice to have eventually,
--
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.
--
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.
Can you try in a couple of hours and report back?