10.9.beta5 startup failure

78 views
Skip to first unread message

Trevor Karn

unread,
Feb 2, 2026, 4:32:58 PM (2 days ago) Feb 2
to sage-devel
Hi all,

I just "successfully" built 10.9.beta5 but am having an issue upon startup. I'll try to troubleshoot, but just wanted folks to be aware of it.

Please see the following: 

[sagelib-10.9.beta5] installing. Log file: /home/tkkarn/sage/sage/logs/pkgs/sagelib-10.9.beta5.log
  [sagelib-10.9.beta5] successfully installed (real 6m11.876s user 6m8.748s sys 0m2.932s).
make[2]: Leaving directory '/home/tkkarn/sage/sage/build/make'
Sage build/upgrade complete!
real 6m12.432s user 6m9.248s sys 0m2.987s
make[1]: Leaving directory '/home/tkkarn/sage/sage'
tkkarn@math:~/sage/sage$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 10.9.beta5, Release Date: 2026-02-01              │
│ Using Python 3.12.5. Type "help()" for help.                       │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable.     ┃
┃ Warning: sage.all is not available; this is a limited REPL.        ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Error in sys.excepthook:
Traceback (most recent call last):
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/IPython/core/application.py", line 284, in excepthook
    return self.crash_handler(etype, evalue, tb)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/IPython/core/crashhandler.py", line 163, in __call__
    if rptdir is None or not Path.is_dir(rptdir):
                             ^^^^^^^^^^^^^^^^^^^
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/pathlib.py", line 875, in is_dir
    return S_ISDIR(self.stat().st_mode)
                   ^^^^^^^^^
AttributeError: 'str' object has no attribute 'stat'

Original exception was:
Traceback (most recent call last):
  File "/home/tkkarn/sage/sage/src/bin/sage-ipython", line 16, in <module>
    app.initialize()
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/traitlets/config/application.py", line 118, in inner
    return method(app, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/IPython/terminal/ipapp.py", line 278, in initialize
    self.init_shell()
  File "/home/tkkarn/sage/sage/src/sage/repl/interpreter.py", line 832, in init_shell
    self.shell = self.shell_class.instance(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/traitlets/config/configurable.py", line 583, in instance
    inst = cls(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/IPython/terminal/interactiveshell.py", line 853, in __init__
    super(TerminalInteractiveShell, self).__init__(*args, **kwargs)
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/site-packages/IPython/core/interactiveshell.py", line 641, in __init__
    self.init_display_formatter()
  File "/home/tkkarn/sage/sage/src/sage/repl/interpreter.py", line 297, in init_display_formatter
    from sage.repl.rich_output.backend_ipython import BackendIPythonCommandline
  File "/home/tkkarn/sage/sage/src/sage/repl/rich_output/__init__.py", line 2, in <module>
    from .display_manager import get_display_manager
  File "/home/tkkarn/sage/sage/src/sage/repl/rich_output/display_manager.py", line 39, in <module>
    from sage.repl.rich_output.output_basic import (
  File "/home/tkkarn/sage/sage/src/sage/repl/rich_output/output_basic.py", line 44, in <module>
    from sage.structure.sage_object import SageObject
  File "/home/tkkarn/sage/sage/src/sage/structure/__init__.py", line 2, in <module>
    import sage.structure.element
  File "sage/structure/element.pyx", line 1, in init sage.structure.element
  File "sage/structure/sage_object.pyx", line 5, in init sage.structure.sage_object
  File "sage/misc/persist.pyx", line 41, in init sage.misc.persist
  File "/home/tkkarn/sage/sage/local/var/lib/sage/venv-python3.12.5/lib/python3.12/bz2.py", line 17, in <module>
    from _bz2 import BZ2Compressor, BZ2Decompressor
ModuleNotFoundError: No module named '_bz2'

Dima Pasechnik

unread,
Feb 2, 2026, 7:59:18 PM (2 days ago) Feb 2
to sage-...@googlegroups.com
Have you built Python from source? That's very flaky, and should not
be done, IMHO.
> --
> 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 visit https://groups.google.com/d/msgid/sage-devel/940b57ac-aa1b-4c62-870b-8a0a9474ed10n%40googlegroups.com.

Eric Gourgoulhon

unread,
Feb 3, 2026, 8:28:01 AM (20 hours ago) Feb 3
to sage-devel
Le mardi 3 février 2026 à 01:59:18 UTC+1, dim...@gmail.com a écrit :
Have you built Python from source? That's very flaky, and should not
be done, IMHO.

Unfortunately, since Sage 10.9.beta4, it has to be done on Ubuntu 24.04 because the system python (3.12.3) is considered too old by Sage: from config.log, we have:

real_configure:157002: result: python3:                        no suitable system package; standard, SPKG version 3.12.5 will be installed

Is there any strong reason to prefer Python 3.12.5 over 3.12.3 in Sage >= 10.9.beta4 ?
(for Sage 10.9.beta3, the Ubuntu system python was considered OK). 


Eric. 

Dima Pasechnik

unread,
Feb 3, 2026, 9:54:49 AM (19 hours ago) Feb 3
to sage-...@googlegroups.com
I cannot think of any reason for this, other than some system package not installed.

I can say more if you post the top level config.log

Dima

>
>Eric.
>

Eric Gourgoulhon

unread,
Feb 3, 2026, 12:18:17 PM (16 hours ago) Feb 3
to sage-devel
Le mardi 3 février 2026 à 15:54:49 UTC+1, dim...@gmail.com a écrit :

>
>Is there any strong reason to prefer Python 3.12.5 over 3.12.3 in Sage >=
>10.9.beta4 ?
>(for Sage 10.9.beta3, the Ubuntu system python was considered OK).

I cannot think of any reason for this, other than some system package not installed.

I can say more if you post the top level config.log

Here it is (namely the config.log of Sage 10.9.beta5 on my Ubuntu 24.04 computer). Thanks.  

Eric. 
config.log

Michael Orlitzky

unread,
Feb 3, 2026, 1:51:04 PM (15 hours ago) Feb 3
to sage-...@googlegroups.com
One of the ./configure checks for python is expecting the old format
for the license identifier in pyproject.toml, but all of the ones used
in sage have been updated.

We probably shouldn't check this so soon because the sage distro
installs a newer setuptools anyway (is setuptools to blame?). Then
again, we probably probably should have python as a prereq instead of
the hundreds of lines of m4 macros currently used validate it.

Ref:

0. https://github.com/sagemath/sage/commit/df46f6e4
1. https://packaging.python.org/en/latest/specifications/pyproject-toml/#license

Dima Pasechnik

unread,
Feb 3, 2026, 3:07:23 PM (13 hours ago) Feb 3
to sage-...@googlegroups.com
On Tue, Feb 3, 2026 at 12:51 PM Michael Orlitzky <mic...@orlitzky.com> wrote:
>
> One of the ./configure checks for python is expecting the old format
> for the license identifier in pyproject.toml, but all of the ones used
> in sage have been updated.
>
> We probably shouldn't check this so soon because the sage distro
> installs a newer setuptools anyway (is setuptools to blame?).

This is something that happens during the check of the system python,
3.12.3, with its setuptools.
Do this mean that it fails its *own* checks?
Or does it does check Sage's pyproject.toml, but this check is too old
for our current pyproject.toml?

I don't get what's going on here. Is 3.12.3 too old now for us?


> Then
> again, we probably probably should have python as a prereq instead of
> the hundreds of lines of m4 macros currently used validate it.

https://github.com/sagemath/sage/pull/41120
is moving python to prereqs (more precisely, even to bootstrap's prereqs)

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 visit https://groups.google.com/d/msgid/sage-devel/aYJDktyjnOIGde62%40mertle.

Dima Pasechnik

unread,
Feb 3, 2026, 3:18:20 PM (13 hours ago) Feb 3
to sage-...@googlegroups.com
On Tue, Feb 3, 2026 at 1:59 PM Dima Pasechnik <dim...@gmail.com> wrote:
>
> On Tue, Feb 3, 2026 at 12:51 PM Michael Orlitzky <mic...@orlitzky.com> wrote:
> >
> > One of the ./configure checks for python is expecting the old format
> > for the license identifier in pyproject.toml, but all of the ones used
> > in sage have been updated.
> >
> > We probably shouldn't check this so soon because the sage distro
> > installs a newer setuptools anyway (is setuptools to blame?).
>
> This is something that happens during the check of the system python,
> 3.12.3, with its setuptools.
> Do this mean that it fails its *own* checks?
> Or does it does check Sage's pyproject.toml, but this check is too old
> for our current pyproject.toml?
>
> I don't get what's going on here. Is 3.12.3 too old now for us?

it actually is almost 2 years old, and that's an Ubuntu fault for
keeping it that old.
On the other hand, Python 3.13 on Ununtu 24.04 should be at least
3.13.7, which is much newer,
and hopefully working.
Switch to 3.13?

Michael Orlitzky

unread,
Feb 3, 2026, 3:37:29 PM (13 hours ago) Feb 3
to sage-...@googlegroups.com
On 2026-02-03 13:59:15, Dima Pasechnik wrote:
> I don't get what's going on here. Is 3.12.3 too old now for us?

I think it's setuptools and not python. Old setuptools doesn't
understand the new license field format.

In the sage distro, we'll build a newer setuptools anyway, but this
./configure check is implicitly testing that the system version of
setuptools can be used to build a C extension.
Reply all
Reply to author
Forward
0 new messages