Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
On 5/8/23 21:22, Paul Gevers wrote: Hi Tobias, On Sat, 6 May 2023 10:24:41 + Tobias Hansen wrote: Note that we could also just remove python3-sage and the autopkgtest. I assume you mean python3-brial here. Yes indeed. Nothing in Debian depends on it Not true (and it's too late in the freeze to do that [1]): paul@mulciber ~ $ reverse-depends python3-brial Reverse-Recommends == * science-mathematics-dev * singular-data I see. I checked with dak [1] and those were not shown, maybe because they are recommends and not depends. Anyway, I'm fine with the proposed NMU. Best, Tobias [1] https://wiki.debian.org/ftpmaster_Removals
Bug#896460: Please package ipywidgets 7
5 years on, can we please start being more pragmatic about it and just ship the provided js files? Aren't other big packages like Firefox or Chromium also doing that? Or are they rebuilding all their js files from source? The Debian Javascript policy uses soft words like should and could for this: https://wiki.debian.org/Javascript/Policy This little package is basically holding sagemath and others hostage. It is the reason we have sagemath 9.5 in bookworm instead of 9.7 or 9.8. See #1010735. Best, Tobias On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: Source: ipywidgets Severity: wishlist Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 doctests to fail. Best, Tobias [1] https://trac.sagemath.org/ticket/23177
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
On 5/2/23 14:20, plugwash wrote: I've prepared a NMU, and intend to open a pre-approval request with the release team. If you have any objections to the NMU please tell me ASAP (I do not intend to upload it until I receive a response from the release team, if you would preffer to make the upload yourself that is fine too). Hi, thanks for taking care of the NMU. Note that we could also just remove python3-sage and the autopkgtest. Nothing in Debian depends on it and the upstream maintainer of brial pointed out that it is not needed anymore: https://alioth-lists.debian.net/pipermail/debian-science-sagemath/2023-May/001809.html Best, Tobias
Bug#1031036: sagemath: sage starts from command line but not from desktop menu
Dear Jorge, thanks for the bug report. I googled the error that you got and it seems a lot of xfce users had similar problems over the years (unrelated to sagemath). Maybe xfce trips over the space in the command? What happens if you change the line Exec=sage --notebook=jupyter to Exec=sage in /usr/share/applications/sagemath.desktop ? Best, Tobias
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On 2/6/23 23:23, Adrian Bunk wrote: > I can make a 0-day NMU if you don't want to upload giac. > > That's not a nice thing to do, but given the freeze deadline it's pretty > urgent. > > cu > Adrian That would be great, thanks! It's team maintained, I don't think anyone will be upset about it. Best, Tobias
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
Control: block -1 by 1030687 I applied the patches and confirmed that the package builds now. I can upload it once giac is fixed.
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
Hi Rogo, awesome, that helps a lot! Thanks for figuring all this out. I had already started determining which patches need to be applied, but wasn't finished yet. Could you please file a bug against giac to get the uchar issue fixed? Best, Tobias
Bug#1020576: Clarify why sagemath package is broken
Control: retitle -1 "FTBFS with setuptools >= 64" Control: block 1028345 by -1 Control: block 1013399 by -1 Control: block 1022254 by -1 Control: block 1022278 by -1 Control: block 1028433 by -1 Control: block 1025874 by -1 Just to clarify that the issue is simply that I can't build sagemath due to the setuptools issue described above. Everything else is just a symptom of not being able to rebuild the package. Best, Tobias
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On 12/23/22 12:56, Nilesh Patra wrote: > On Sat, 10 Dec 2022 18:07:53 +0530 Nilesh Patra wrote: >> On Mon, 28 Nov 2022 21:05:07 +0000 Tobias Hansen wrote: >>> On 11/27/22 19:24, Nilesh Patra wrote: >>>> On Sun, Nov 27, 2022 at 05:35:17PM +, Tobias Hansen wrote: >>>>> On 11/27/22 06:37, Nilesh Patra wrote: >>>>>> Tobias, since this is done, would you consider to check sagemath now and >>>>>> get the ball rolling? :-) >>>>> Hi, >>>>> >>>>> I actually tried building with the new pari and gap versions a while ago >>>>> (using sagemath 9.5 with upstream patches for the new pari and gap >>>>> versions, I pushed them to the git repo today) and got stuck with a lot >>>>> of errors like this (might be unrelated to pari and gap): >>>> I am having a hard time building/reproducing this because sage tends to >>>> need a lot of compute power that I currently do not have, and it takes >>>> forever to porter box too. >>>> But looking at the error, my hunch is that this is a setuptools related >>>> monkeypatch issue (there are similar RC bugs filed for many packages). So >>>> re-ordering cython import >>>> in sage/misc/cython.py file after setuptools along with ensuring distutils >>>> is imported after setuptools will (very) likely help. >>>> >>>> Here is a related link that I found for the same >>>> >>>> >>>> https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t >>>> >>> Thanks. The attached patch removed the error, but now there are these >>> warnings when cython is used in doctests: >>> >>> UserWarning: Distutils was imported before Setuptools, but importing >>> Setuptools also replaces the `distutils` module in `sys.modules`. >> >> >> Apologies for late response. I suppose the line above is the crux? >> setuptools monkey-patches distutils so it should be imported _before_ >> distutils. >> Somewhere in the doctests, it is other way round and hence the error. >> >> Did you get a chance to build sage yet? > Sorry to pester you, but since softfreeze is near - did you happen to have > any update about this yet? Can I be of help in any way? > > Let me know. > Last time I tried to build sage, I reported here what happened. I tried to figure out why upstream is not having this problem. My best guess is the mismatch in setuptools versions. Upstream is still at 63.4.3 while Debian updated to 65.5.0. Upstream has a (maybe unrelated?) problem with higher setuptools versions described here: https://trac.sagemath.org/ticket/34442 Unfortunately I don't have much time to work on this. If someone can come up with a patch, that would be highly appreciated. Best wishes, Tobias
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On 11/27/22 19:24, Nilesh Patra wrote: > On Sun, Nov 27, 2022 at 05:35:17PM +0000, Tobias Hansen wrote: >> On 11/27/22 06:37, Nilesh Patra wrote: >>> Tobias, since this is done, would you consider to check sagemath now and >>> get the ball rolling? :-) >> Hi, >> >> I actually tried building with the new pari and gap versions a while ago >> (using sagemath 9.5 with upstream patches for the new pari and gap versions, >> I pushed them to the git repo today) and got stuck with a lot of errors like >> this (might be unrelated to pari and gap): > I am having a hard time building/reproducing this because sage tends to need > a lot of compute power that I currently do not have, and it takes forever to > porter box too. > But looking at the error, my hunch is that this is a setuptools related > monkeypatch issue (there are similar RC bugs filed for many packages). So > re-ordering cython import > in sage/misc/cython.py file after setuptools along with ensuring distutils is > imported after setuptools will (very) likely help. > > Here is a related link that I found for the same > > > https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t > Thanks. The attached patch removed the error, but now there are these warnings when cython is used in doctests: UserWarning: Distutils was imported before Setuptools, but importing Setuptools also replaces the `distutils` module in `sys.modules`. This may lead to undesirable behaviors or errors. To avoid these issues, avoid using distutils directly, ensure that setuptools is installed in the traditional way (e.g. not an editable install), and/or make sure that setuptools is always imported before distutils. UserWarning: Setuptools is replacing distutils. and DeprecationWarning: msvccompiler is deprecated and slated to be removed in the future. Please discontinue use or file an issue with pypa/distutils describing your use case. Best, Tobias Description: Import setuptools before cython To fix the error distutils.errors.DistutilsSetupError: each element of 'ext_modules' option must be an Extension instance or 2-tuple Author: Tobias Hansen --- a/sage/src/sage/misc/cython.py +++ b/sage/src/sage/misc/cython.py @@ -285,9 +285,6 @@ includes = [os.getcwd()] + standard_includes # Now do the actual build, directly calling Cython and distutils -from Cython.Build import cythonize -from Cython.Compiler.Errors import CompileError -import Cython.Compiler.Options try: # Import setuptools before importing distutils, so that setuptools @@ -301,6 +298,10 @@ from distutils.dist import Distribution from distutils.core import Extension +from Cython.Build import cythonize +from Cython.Compiler.Errors import CompileError +import Cython.Compiler.Options + from distutils.log import set_verbosity set_verbosity(verbose)
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
On 11/27/22 06:37, Nilesh Patra wrote:
> Tobias, since this is done, would you consider to check sagemath now and get
> the ball rolling? :-)
Hi,
I actually tried building with the new pari and gap versions a while ago (using
sagemath 9.5 with upstream patches for the new pari and gap versions, I pushed
them to the git repo today) and got stuck with a lot of errors like this (might
be unrelated to pari and gap):
Exception raised:
Traceback (most recent call last):
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/misc/cython.py",
line 399, in cython
dist.run_command("build")
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1217, in
run_command
super().run_command(command)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
987, in run_command
cmd_obj.run()
File
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", line
132, in run
self.run_command(cmd_name)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line
319, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1217, in
run_command
super().run_command(command)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
986, in run_command
cmd_obj.ensure_finalized()
File "/usr/lib/python3.10/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "/usr/lib/python3/dist-packages/setuptools/command/build_ext.py",
line 179, in finalize_options
self.check_extensions_list(self.extensions)
File "/usr/lib/python3.10/distutils/command/build_ext.py", line 362, in
check_extensions_list
raise DistutilsSetupError(
distutils.errors.DistutilsSetupError: each element of 'ext_modules' option
must be an Extension instance or 2-tuple
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/doctest/forker.py",
line 694, in _run
self.compile_and_execute(example, compiler, test.globs)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/doctest/forker.py",
line 1088, in compile_and_execute
exec(compiled, globs)
File "", line 1, in
cython('''
File "sage/misc/lazy_import.pyx", line 391, in
sage.misc.lazy_import.LazyImport.__call__
(build/cythonized/sage/misc/lazy_import.c:4321)
return self.get_object()(*args, **kwds)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/misc/cython.py",
line 661, in cython_compile
return cython_import_all(tmpfile, get_globals(), **kwds)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/misc/cython.py",
line 551, in cython_import_all
m = cython_import(filename, **kwds)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/misc/cython.py",
line 526, in cython_import
name, build_dir = cython(filename, **kwds)
File
"/<>/debian/tmp/usr/lib/python3.10/dist-packages/sage/misc/cython.py",
line 405, in cython
raise RuntimeError(msg.strip())
RuntimeError: each element of 'ext_modules' option must be an Extension
instance or 2-tuple
Best,
Tobias
Bug#1020456: cypari2 FTBFS with PARI 2.15.0
Thanks! I will apply the patch once the pari version with the other fixes is uploaded. Best wishes, Tobias On 10/26/22 10:55, Bill Allombert wrote: > Also I consider the error message change > - PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC > (1 elts) > + PariError: call_python: incorrect type in qfbcomp (t_VEC) > to be a bug in PARI/GP that I will fix too. > > For the others, I join a patch. > > Cheers,
Bug#1020436: giac failed tests with new pari
Hi Ileana, are you aware of the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020436 Bill posted a suggestion how to fix this test there yesterday. Best wishes, Tobias On 10/19/22 14:44, Ileana Dumitrescu wrote: > Hi Julien, > > I applied pari.patch to fix the compile issues with new upstream version of > giac 1.9.0.21 and using new pari version 2.15.0. giac compiles without error > now, but I am seeing several errors from the test outputs, mostly > segmentation faults involving pari functions (see giac_test_failures.txt). I > think this is an issue with the pari library and not with pari.cc in giac. If > you can reproduce this and agree then I can write a bug for pari or any > action you think is best. But right now it is not ready for release. > > Ileana Dumitrescu > > GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
Bug#1020436: giac FTBFS with PARI 2.15.0
I tried rebuilding with this patch from sagemath: |diff --git a/src/pari.cc b/src/pari.cc index 76ce8e1..50d08ab 100644 --- a/src/pari.cc +++ b/src/pari.cc @@ -40,6 +40,13 @@ using namespace std; #ifdef HAVE_LIBPARI +// Anyarg disappeared from PARI 2.15.0 +#ifdef __cplusplus +# define ANYARG ... +#else +# define ANYARG +#endif + #ifdef HAVE_PTHREAD_H #include #endif| But I get one test failure: FAIL: chk_fhan4 === // Using locale /usr/share/locale/ // C.UTF-8 // /usr/share/locale/ // giac // UTF-8 // Maximum number of parallel threads 8 // Unable to find keyword file doc/en/keywords Added 0 synonyms // Warning: a, declared as global variable(s). If symbolic variables are required, declare them as local and run purge // Success // Success // Success // Success // Success // Success // Success // Success // End defining T == restarted === // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 // Time 0.02 // Time 0 // Time 0 // Time 0 // Time 0 0 0 0 0 0 0 0 0 0 // Time 0.03 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 0 0 0 0 // Time 0.04 // Time 0 // Time 0 // Time 0 // Time 0 0 // Time 0.06 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0.01 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0 // Time 0.01 *** the thread stack overflows ! current stack size: 1024000 (0.977 Mbytes) [hint] set 'threadsizemax' to a nonzero value in your GPRC *** matdet: Warning: increasing stack size to 2048000. *** at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,- *** ^-- *** matdet: the thread stack overflows ! current stack size: 1024000 (0.977 Mbytes) [hint] set 'threadsizemax' to a nonzero value in your GPRC Error in PARI subsystem Segmentation fault 49c49,108 < --- > "Done", > "Done", > "Done", > 0, > 0, > 50, > "Done", > "Done", > "Done", > "Done", > 0, > 0, > 30, > "Done", > "Done", > "Done", > "Done", > "Done", > "Done", > 0, > 0, > 0, > 40, > "Done", > "Done", > 0, > 50, > "Done", > "Done", > 0, > [[0,-2,1,3],[0,0,0,1],[1,1,0,0],[-3,4,1,0]], > "Done", > "Done", > "Done", > "Done", > "Done", > [[0,1,0,0],[1,0,0,0],[0,0,1,0],[0,0,0,1]], > [[0,0,0,1],[0,-2,1,3],[1,1,0,0],[-3,4,1,0]], > proc(i,j,a) > local TT; > TT:=identity(4); > TT[i,j]:=a; > TT; > > end;, > [[0,0,0,1],[0,-2,1,3],[1,1,0,1/2],[-3,4,1,0]], > [[0,0,0,1],[0,-2,1,3],[1,1,0,1/2],[-3,4,1,3/2]], > "Done", > "Done", > "Done", > "Done", > "Done", > [[1,0,0,0],[0,0,0,1],[0,0,1,0],[0,1,0,0]], > [[0,0,0,1],[-3,4,1,3/2],[1,1,0,1/2],[0,-2,1,3]], > [[0,0,1,0],[1,0,0,0],[0,0,0,1],[0,1,0,0]], > [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]], > [[0,0,0,1],[-3,4,1,3/2],[1,1,0,1/2],[-2,-4,1,2]], > [[1,0,0,0],[-3/2,1,0,0],[-1/2,0,1,0],[0,0,2,1]], > [[0,0,0,1],[1,0,0,0],[0,0,1,0],[0,1,0,0]], > [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]] FAIL chk_fhan4 (exit status: 1) Testsuite summary for giac 1.9.0 # TOTAL: 30 # PASS: 29 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 On 10/1/22 20:46, Bill Allombert wrote: > On Wed, Sep 21, 2022 at 09:01:51PM +0300, Adrian Bunk wrote: >> Source: giac >> Version: 1.9.0.19+dfsg2-1 >> Severity: serious >> Tags: ftbfs >> >> https://buildd.debian.org/status/logs.php?pkg=giac&ver=1.9.0.19%2Bdfsg2-1%2Bb1 >> >> ... >> pari.cc: At global scope: >> pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ >> instead) >> 752 | typedef GEN (*PFGEN)(ANYARG); >> | ^ >> pari.cc:752:24: error: ‘ANYARG’ was not declared in this scope > This is my comment on this bug: > > PARI used to define ANYARG as > #ifdef __cplusplus > # define ANYARG ... > #else > # define ANYARG > #endif > > This definition was removed because newer gcc/clang do not like to call > function without prototype and it was not particularly > useful. > > So you can replace this by > > typedef GEN (*PFGEN)(); > > if you like, but recent gcc 12 will issue warning. > In PARI we changed EVAL_f to cast the pointer to the right prototype > before calling it. > > Sorry for the trouble. > > Cheers,
Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0
Control: block -1 by 1020436 1020456 Before sagemath can be fixed, cypari2 and giac have to be built against pari 2.15. On 10/13/22 19:08, Paul Gevers wrote: > Control: severity -1 serious > > Hi, > > On Fri, 23 Sep 2022 15:55:41 +0200 Bill Allombert wrote: >> Please update sagemath so that it can work with both PARI 2.15.0 (in >> unstable) >> and GAP 4.12.0 (in experimental). >> >> I am not saying it is easy :) > > The autopkgtest of sagemath is failing with the new pari, blocking its > migration. > > Paul
Bug#1013890: gmp-ecm breaks sagemath autopkgtest: lots of issues
Hi, not all tests are expected to pass in sagemath's test suite. The issue is always described at the end: Success: 62 tests failed, up to 100 failures are tolerated Error: critical test failures (e.g. timeout, segfault, etc.) And in the overview above that, it indicates a segfault: sage/src/sage/libs/libecm.pyx # Killed due to abort sagemath probably just needs to be rebuilt against the new gmp-ecm. gmp-ecm should have done a library transition. Best, Tobias On 6/26/22 21:21, Paul Gevers wrote: > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of gmp-ecm to testing > [1]. Due to the nature of this issue, I filed this bug report against both > packages. Can you please investigate the situation and reassign the bug to > the right package? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul
Bug#934258: Current status?
Hi, there is a Debian package fonts-fork-awesome. Isn't that what you need? (ITP bug is 910256) Best, Tobias On Tue, 26 Apr 2022 17:20:02 +0200 Roland Mas wrote: > > - fortawesome-fontawesome-free (see my other mail: no source available, > and I don't know what to do; split the part of jupyterlab that depend on > it into a separate package in contrib? try to make do with a previous > version?) > >
Bug#1010735: Update to sagemath 9.6 requires jupyter-sphinx requires ipywidgets >= 7
Source: sagemath Version: 9.5-4 Severity: normal Control: block -1 by 950598 Control: block -1 by 896460 The need for ipywidgets >= 7 is getting even bigger in sagemath 9.6. Sagemath now depends on jupyter-sphinx, see https://trac.sagemath.org/ticket/33507 jupyter-sphinx is broken in Debian because it depends on ipywidgets >= 7 (#950598). I'm not sure if we are stuck with sagemath 9.5 until we have ipywidgets >=7 or if it is an option to revert even more upstream commits in sagemath to keep this going.
Bug#1010109: RM: higan -- ROM; superseded by ares
Package: ftp.debian.org Severity: normal Please remove higan from unstable. It is superseded by ares, which I packaged to replace higan. higan still exists as a slightly different version of the same program, but ares is more user friendly and more actively maintained. Thanks, Tobias
Bug#1010105: ITP: python-lrcalc -- Python interface to lrcalc
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Tobias Hansen Severity: wishlist * Package name: python-lrcalc Version : 2.1 Upstream Author : Anders S. Buch * URL : http://www.math.rutgers.edu/~asbuch/lrcalc/ * License : GPL-3+ Programming Lang: Python Description : Python interface to lrcalc This is a Cython interface to the C library lrcalc. It is a dependency of sagemath >= 9.6. I am planning to maintain it within the Debian Math Team.
Bug#1009756: RM: sagemath [armhf mips64el] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal Hi, please remove the python3-sage package on armhf and mips64el from unstable. They are no longer allowed in source as their builds were constantly failing for a long time (#920147, #1004872). Best wishes, Tobias
Bug#1009731: libglu1-mesa-dev: pkg-config file glu.pc depends on opengl.pc
Package: libglu1-mesa-dev Version: 9.0.2-1 Severity: serious Control: block 1008372 by -1 Hi, recently sludge started to FTBFS with the following error, see #1008372: Package 'opengl', required by 'glu', not found I believe this is because glu.pc now depends on opengl.pc which means that libglu1-mesa-dev should depend on libopengl-dev which contains opengl.pc. I checked that sludge build successfully when installing libopengl-dev. Best wishes, Tobias
Bug#1009241: sagemath: autokgtest regression on armhf
Hi, this is not a regression, as the armhf and mips64el tests never passed, see #1004872 and #920147. There was a bug in the package that caused the tests not to be run when building with python 3.10, so the armhf and mips64el package builds succeeded. The packages for these architectures should be removed from testing. I fixed this in sagemath 9.5-3. Best, Tobias On 4/9/22 16:56, Sebastian Ramacher wrote: > Source: sagemath > Version: 9.5-2 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > sagemath's autopkgtests fail on armhf:
Bug#1005691: myst-parser: Fauling autopkgtest on i386 and armhf prevents testing migration
Source: myst-parser
Version: 0.16.1-1
Severity: normal
Hi,
myst-parser is not migrating to testing because of a failing autopkgtest on
i386 and armhf, see below.
This is also blocking testing migration of other packages such as primecountpy
and sagemath.
Best wishes,
Tobias
=== FAILURES ===
__ test_sphinx_directives[35-highlight (`sphinx.directives.code.Highlight`):] __
line = 35, title = 'highlight (`sphinx.directives.code.Highlight`):'
input = '```{highlight} something\n```\n'
expected = '\n\n'
@pytest.mark.parametrize(
"line,title,input,expected",
read_fixture_file(FIXTURE_PATH.joinpath("sphinx_directives.md")),
ids=[
f"{i[0]}-{i[1]}"
for i in read_fixture_file(FIXTURE_PATH / "sphinx_directives.md")
],
)
def test_sphinx_directives(line, title, input, expected):
# TODO fix skipped directives
# TODO test domain directives
if title.startswith("SKIP"):
pytest.skip(title)
elif title.startswith("SPHINX3") and sphinx.version_info[0] < 3:
pytest.skip(title)
elif title.startswith("SPHINX4") and sphinx.version_info[0] < 4:
pytest.skip(title)
document = to_docutils(input, in_sphinx_env=True)
_actual, _expected = [
"\n".join([ll.rstrip() for ll in text.splitlines()])
for text in (document.pformat(), expected)
]
try:
> assert _actual == _expected
E assert '' == ''
E Skipping 84 identical leading characters in diff, use -v to show
E - hreshold="9223372036854775807">
E + hreshold="2147483647">
tests/test_renderers/test_fixtures.py:121: AssertionError
- Captured stdout call -
=== short test summary info
FAILED
tests/test_renderers/test_fixtures.py::test_sphinx_directives[35-highlight
(`sphinx.directives.code.Highlight`):]
Bug#1005337: pynac can be removed from Debian
Source: pynac Version: 0.7.29-2 Severity: normal Hi Julien, pynac was merged into sagemath 9.5, see https://trac.sagemath.org/ticket/32386 Since pynac has no other use than the one in sage (according to that ticket) I suggest that you request removal of pynac from Debian unstable. Best wishes, Tobias
Bug#1004872: sagemath FTBFS on armhf
Package: sagemath Version: 9.0-1 Severity: normal Control: tags -1 + ftbfs We are getting test timeouts on armhf since sagemath 9.0-1. The exact spots where it happens have changed over time, one that stayed the whole time is in src/sage/modular/modform/constructor.py. From there one can see that one can trigger the issue for example with sage -c "print(ModularForms(Gamma1(4),11).basis())" I tried to debug this on an armhf porterbox, but didn't manage to get a meaningful backtrace. The backtraces from the build logs also don't tell me much. Here is an example: Stack backtrace --- No symbol table info available. #1 0xf76fc274 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 No symbol table info available. #2 0xf6bac1a6 in ?? () from /usr/lib/python3/dist-packages/cysignals/signals.cpython-39-arm-linux-gnueabihf.so No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) Increasing SAGE_TIMEOUT also didn't help. Any help is appreciated. Best, Tobias
Bug#1004708: ITP: primecountpy -- Python interface to primecount
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Tobias Hansen Severity: wishlist * Package name: primecountpy Version : 0.1.0 Upstream Author : Dima Pasechnik * URL : https://github.com/dimpase/primecountpy * License : GPL Programming Lang: Python Description : Python interface to primecount This is a Cython interface to the C++ library primecount. It is a dependency of sagemath >= 9.5. I am planning to maintain it within the Debian Math Team.
Bug#1003317: [Debian-science-sagemath] [RFP]: primecount -- count the primes below an integer
Hi Jerome, any news on this? If you prefer I could also take care of it. Best, Tobias On 1/8/22 20:10, Jerome BENOIT wrote: > Hello, > > I think it the best idea. > I cannot do that this week-end. > > I think I can have a look on it the next week-end or the week-end after. > > If it is ok, I can put an ITP. > > Best wishes, > Jerome > > On 08/01/2022 12:14, Tobias Hansen wrote: >> Hi, >> >> we need to package primecount and primecountpy for sagemath 9.5. Jerome, I >> saw that you are already maintaining primesieve by the same upstream. Are >> you interested in packaging these two or should I take care of it? >> >> Best wishes, >> Tobias >> >> On Sat, 08 Jan 2022 06:35:05 + Preetham Gujjula >> wrote: >>> Package: wnpp >>> Severity: wishlist >>> >>> * Package name : primecount >>> Version : 7.2 >>> Upstream Author : Kim Walisch >>> * URL : https://github.com/kimwalisch/primecount >>> * License : BSD-2-Clause >>> Programming Lang: C/C++ >>> Description : count the primes below an integer >>> >>> primecount is a command-line program and C/C++ library that counts the >>> primes >>> below an integer <= 10^31 using highly optimized implementations of the >>> combinatorial prime counting algorithms. >>> >>> It is related to and created by the same developer as primesieve, which is >>> already packaged into Debian. >>> >>> >>> >> >> ___ >> Debian-science-sagemath mailing list >> debian-science-sagem...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >> > > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
Bug#1003848: ITP: ares -- Accurate multi-system emulator
Package: wnpp Owner: Tobias Hansen Severity: wishlist * Package name: ares Version : 126 Upstream Author : Near et al * URL : https://ares-emulator.github.io/ * License : ISC Programming Lang: C++ Description : Accurate multi-system emulator ares is an emulator for systems from Nintendo, Sega, Sony, NEC, SNK, Microsoft, Coleco, Bandai and Benesse. It is a descendent of higan and bsnes and focuses on accuracy and preservation. The SNES emulation is especially complete and polished. Near created various variants of his emulator under different names (bsnes, higan, byuu and ares). Since ares seems to be the most actively developed variant and more user friendly than the latest higan versions, I am planning to package ares and to remove the existing higan package from Debian.
Bug#1001541: run-time shared lib not placed in package with proper name
On 12/11/21 22:22, Jochen Sprickerhof wrote: > Package: ecl > Version: 21.2.1+ds-1 > Severity: critical > X-Debbugs-Cc: jspri...@debian.org > > Hi, > > according to policy: > > "The run-time shared library must be placed in a package whose name > changes whenever the SONAME of the shared library changes." > > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > This breaks unrelated software, for example sagemath: > > $ sage -c "solve(x, x)" > Traceback (most recent call last): > File "/usr/share/sagemath/bin/sage-eval", line 10, in > eval(compile(s,'','exec')) > File "", line 1, in > File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1044, > in solve > return _solve_expression(f, x, explicit_solutions, multiplicities, > to_poly_solve, solution_dict, algorithm, domain) > File "/usr/lib/python3/dist-packages/sage/symbolic/relation.py", line 1283, > in _solve_expression > m = ex._maxima_() > File "sage/symbolic/expression.pyx", line 1015, in > sage.symbolic.expression.Expression._maxima_ > (build/cythonized/sage/symbolic/expression.cpp:7931) > File "sage/structure/sage_object.pyx", line 680, in > sage.structure.sage_object.SageObject._interface_ > (build/cythonized/sage/structure/sage_object.c:5480) > File "sage/misc/lazy_import.pyx", line 329, in > sage.misc.lazy_import.LazyImport.__getattr__ > (build/cythonized/sage/misc/lazy_import.c:3870) > File "sage/misc/lazy_import.pyx", line 191, in > sage.misc.lazy_import.LazyImport.get_object > (build/cythonized/sage/misc/lazy_import.c:2435) > File "sage/misc/lazy_import.pyx", line 228, in > sage.misc.lazy_import.LazyImport._get_object > (build/cythonized/sage/misc/lazy_import.c:2842) > File "sage/misc/lazy_import.pyx", line 224, in > sage.misc.lazy_import.LazyImport._get_object > (build/cythonized/sage/misc/lazy_import.c:2704) > File "/usr/lib/python3/dist-packages/sage/interfaces/maxima_lib.py", line > 92, in > from sage.libs.ecl import EclObject, ecl_eval > ImportError: libecl.so.20.4: cannot open shared object file: No such file or > directory > > Hi, from debian/README.Debian: "The libecl.so file is changing too quickly and is integrated with the ecl binary to such extend that, after consultation with upstream, I will not create a libecl package. If ecl will reach a stable release (1.0 or so) and some guarantees with respect to API stability can be make I will reconsider this decision." This is still true 13 years later. ecl is using its version (which is based on the year) as SONAME... And sagemath is not unrelated software: maxima-sage and sagemath are the only packages in Debian with Depends: ecl. We are always making sure that maxima-sage and sagemath are rebuilt with every new ecl version, however sagemath 9.2 in Debian was already so broken that it didn't matter (look at the number of bugs fixed by sagemath 9.4-1). Creating a library package for ecl would just mean that it would have to go through NEW for every new version with no real benefit. Do you insist that I do that? Best wishes, Tobias
Bug#1003317: [RFP]: primecount -- count the primes below an integer
Hi, we need to package primecount and primecountpy for sagemath 9.5. Jerome, I saw that you are already maintaining primesieve by the same upstream. Are you interested in packaging these two or should I take care of it? Best wishes, Tobias On Sat, 08 Jan 2022 06:35:05 + Preetham Gujjula wrote: > Package: wnpp > Severity: wishlist > > * Package name: primecount > Version : 7.2 > Upstream Author : Kim Walisch > * URL : https://github.com/kimwalisch/primecount > * License : BSD-2-Clause > Programming Lang: C/C++ > Description : count the primes below an integer > > primecount is a command-line program and C/C++ library that counts the primes > below an integer <= 10^31 using highly optimized implementations of the > combinatorial prime counting algorithms. > > It is related to and created by the same developer as primesieve, which is > already packaged into Debian. > > >
Bug#1002587: python3-sage: Depends on unavailable package
Version: 9.4-1 Hi, memory-allocator passed NEW now. Best, Tobias On 12/24/21 10:33 PM, Alexandre Lymberopoulos wrote: > Hi, Tobias. > > Thanks for the prompt elucidation. > > Best, Alexandre > > On December 24, 2021 6:17:16 PM GMT-03:00, Tobias Hansen > wrote: > > Hi, > > memory-allocator is in NEW (https://ftp-master.debian.org/new.html > <https://ftp-master.debian.org/new.html>) since two weeks and waiting to be > approved for inclusion in Debian. I uploaded sagemath 9.4 after > memory-allocator but it passed NEW faster. > > Best, > Tobias > > On 12/24/21 9:45 PM, Alexandre Lymberopoulos wrote: > > Package: python3-sage > Version: 9.4-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I was trying for a few weeks to upgrade some packages and it couldn't > do that due to sage dependencies. Now it has a new version available > (9.4-1), which depends on python3-sage (9.4-1) that depends itself on > python3-memory-allocator that shows up as unavailable here. > > Any advice? > > Thanks in advance and best regards, > Alexandre > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages python3-sage depends on: > ii bc 1.07.1-3+b1 > ii binutils 2.37-7 > ii bzip2 1.0.8-5 > ii ca-certificates 20210119 > pn cliquer > ii cmake 3.22.1-1+b1 > ii curl 7.79.1-2 > ii cython3 0.29.24-1+b1 > ii ecl 21.2.1+ds-1 > ii eclib-tools 20210625-1+b2 > ii fflas-ffpack 2.5.0-1 > ii flintqs 1:1.0-3+b1 > ii gap-atlasrep 2.1.0-3 > ii gap-dev 4.11.1-1 > ii gap-online-help 4.11.1-1 > ii gap-primgrp 3.4.0-1 > ii gap-smallgrp 1.4.1-2 > ii gap-table-of-marks 1.2.9-1 > ii gap-transgrp 2.0.6-2 > ii gfan 0.6.2-6 > pn gfortran > ii glpk-utils 5.0-1 > ii gmp-ecm 7.0.4+ds-6 > ii jmol 14.32.3+dfsg1-1 > ii lcalc 2.0.4-2 > ii libatlas3-base [libblas.so.3] 3.10.3-11 > ii libatomic-ops-dev 7.6.12-1 > ii libblas3 [libblas.so.3] 3.10.0-2 > pn libboost-dev > pn libbraiding-dev > ii libbraiding0 1.0-1+b1 > pn libbrial-dev > pn libbrial-groebner-dev > ii libbrial-groebner3 1.2.10-1+b2 > ii libbrial3 1.2.10-1+b2 > pn libbz2-dev > ii libc6 2.33-1 > pn libcdd-dev > ii libcdd-tools 094l-2 > pn libcliquer-dev > ii libcliquer1 1.21-3 > pn libcurl4-openssl-dev > pn libec-dev > ii libec8 20210625-1+b2 > pn libecm-dev > ii libecm1 7.0.4+ds-6 > ii libffi-dev 3.4.2-3 > ii libflint-2.8.4 2.8.4-2 > pn libflint-arb-dev > ii libflint-arb2 1:2.21.1-2 > pn libflint-dev > pn libfplll-dev > ii libfreetype6-dev 2.11.0+dfsg-1 > ii libgap-dev 4.11.1-1 > ii libgap7 4.11.1-1 > ii libgc-dev 1:8.0.6-1.1 > ii libgcc-s1 11.2.0-13 > pn libgd-dev > ii libgd3 2.3.0-2 > pn libgf2x-dev > pn libgiac-dev > hi libgiac0 1.7.0.39+dfsg2-1 > ii libgivaro-dev 4.2.0-1 > ii libgivaro9 4.2.0-1 > pn libglpk-dev > ii libglpk40 5.0-1 > ii libgmp-dev 2:6.2.1+dfsg-3 > ii libgmp10 2:6.2.1+dfsg-3 > ii libgmpxx4ldbl 2:6.2.1+dfsg-3 > pn libgsl-dev > pn libgsl27 > pn libhomfly-dev > ii libhomfly0 1.02r6-1 > pn libiml-dev > ii libiml0 1.0.5-1 > ii libjs-mathjax 2.7.9+dfsg-1 > ii libjs-three 111+dfsg1-2 > pn liblfunction-dev > ii liblfunction1 2.0.4-2 > pn liblinbox-dev > pn liblrcalc-dev > ii liblrcalc1 1.2-2+b1 > ii liblzma-dev 5.2.5-2 > ii libm4ri-0.0.20200125 20200125-1+b1 > ii libm4rie-0.0.20200125 20200125-1+b2 > pn libm4rie-dev > pn libmpc-dev > ii libmpc
Bug#1002587: python3-sage: Depends on unavailable package
Hi, memory-allocator is in NEW (https://ftp-master.debian.org/new.html) since two weeks and waiting to be approved for inclusion in Debian. I uploaded sagemath 9.4 after memory-allocator but it passed NEW faster. Best, Tobias On 12/24/21 9:45 PM, Alexandre Lymberopoulos wrote: > Package: python3-sage > Version: 9.4-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I was trying for a few weeks to upgrade some packages and it couldn't > do that due to sage dependencies. Now it has a new version available > (9.4-1), which depends on python3-sage (9.4-1) that depends itself on > python3-memory-allocator that shows up as unavailable here. > > Any advice? > > Thanks in advance and best regards, > Alexandre > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages python3-sage depends on: > ii bc1.07.1-3+b1 > ii binutils 2.37-7 > ii bzip2 1.0.8-5 > ii ca-certificates 20210119 > pn cliquer > ii cmake 3.22.1-1+b1 > ii curl 7.79.1-2 > ii cython3 0.29.24-1+b1 > ii ecl 21.2.1+ds-1 > ii eclib-tools 20210625-1+b2 > ii fflas-ffpack 2.5.0-1 > ii flintqs 1:1.0-3+b1 > ii gap-atlasrep 2.1.0-3 > ii gap-dev 4.11.1-1 > ii gap-online-help 4.11.1-1 > ii gap-primgrp 3.4.0-1 > ii gap-smallgrp 1.4.1-2 > ii gap-table-of-marks1.2.9-1 > ii gap-transgrp 2.0.6-2 > ii gfan 0.6.2-6 > pn gfortran > ii glpk-utils5.0-1 > ii gmp-ecm 7.0.4+ds-6 > ii jmol 14.32.3+dfsg1-1 > ii lcalc 2.0.4-2 > ii libatlas3-base [libblas.so.3] 3.10.3-11 > ii libatomic-ops-dev 7.6.12-1 > ii libblas3 [libblas.so.3] 3.10.0-2 > pn libboost-dev > pn libbraiding-dev > ii libbraiding0 1.0-1+b1 > pn libbrial-dev > pn libbrial-groebner-dev > ii libbrial-groebner31.2.10-1+b2 > ii libbrial3 1.2.10-1+b2 > pn libbz2-dev > ii libc6 2.33-1 > pn libcdd-dev > ii libcdd-tools 094l-2 > pn libcliquer-dev > ii libcliquer1 1.21-3 > pn libcurl4-openssl-dev > pn libec-dev > ii libec820210625-1+b2 > pn libecm-dev > ii libecm1 7.0.4+ds-6 > ii libffi-dev3.4.2-3 > ii libflint-2.8.42.8.4-2 > pn libflint-arb-dev > ii libflint-arb2 1:2.21.1-2 > pn libflint-dev > pn libfplll-dev > ii libfreetype6-dev 2.11.0+dfsg-1 > ii libgap-dev4.11.1-1 > ii libgap7 4.11.1-1 > ii libgc-dev 1:8.0.6-1.1 > ii libgcc-s1 11.2.0-13 > pn libgd-dev > ii libgd32.3.0-2 > pn libgf2x-dev > pn libgiac-de
Bug#1001878: liblinbox-dev should depend on libfplll-dev
Source: linbox Version: 1.7.0-1 Severity: normal Hi, while building sagemath I noticed that linbox includes fplll.h in algorithms/lattice.h and algorithms/short-vector.h. Hence I think liblinbox-dev should depend on libfplll-dev. Best, Tobias
Bug#1001806: libsingular reports wrong location of singular.info
Package: singular Version: 1:4.2.1-p2+ds-5 Severity: normal Hi Jerome, I noticed some sagemath doctests are failing because sagemath cannot find singular.info. It uses the libsingular function feGetResource() to determine the location of the file. You can see in resources/feResource.cc that it is expected to be at /usr/bin/share/singular/singular.info, however it is installed to /usr/share/doc/singular/singular.info. Could you please update feResource() to give the right location? It should be enough to set SINGULAR_INFO_FILE, SINGULAR_IDX_FILE etc in debian/rules. Best, Tobias
Bug#998244: lists.debian.org: request for debian-math mailing list
Hi Cord, I am also in favor of the creation of this list. I think we could then close down debian-science-sagem...@alioth-lists.debian.net and move these discussions to debian-math. Best, Tobias On Sat, 13 Nov 2021 16:45:48 +0530 "Nilesh Patra" wrote: > Dear list masters, > > Since a few people already responded on this bug, and other folks > already showed interest in joining the team[1], would you please consider to > process this mailing list request now? > > [1]: https://lists.debian.org/debian-science/2021/10/msg00034.html > > Thanks a lot for your work, > Nilesh > >
Bug#1001589: libgsl25: Can't be upgraded to 2.7+dfsg-2
On 12/13/21 4:30 PM, Dirk Eddelbuettel wrote: > Hi Alexandre, > > On 13 December 2021 at 09:08, Alexandre Lymberopoulos wrote: > | Hi there, Dirk! > | > | I see that, libgslblasc0 is upgradable to version 2.7.1+dfsg-3 here, but > | the upgrade available version of libgsl25 (2.6+dfsg-2 -> 2.7+dfsg-2) > | requires libgslbalsc0 2.7.1+dfsg-2, which is unavailable. > | > | Digging around here, I noticed that the only package that still depends > | on libgsl25 after a supposed upgrade is sagemath. Is there a way to let > | them know this and try tu upgrade their dependency to libgsl27? Or is it > | better to bugreport them? > > That is is a bit of grey zone to me too. Sometimes the ftpmasters help nudge > this, or even do a 'binary build' (unchanged package rebuilt under new > dependencies). > I am CCing Sebastian who has been very helpful for the GSL update / informal > transition. He may be able to suggest a next step. > > Otherwise you could start with a simple email to the maintainer. > > Cheers, Dirk sagemath maintainer here. The sagemath 9.2 package is broken at the moment and does not build and I wouldn't expect it to work very well either. I am working on a big update but that may still need some days until it's finished. In the meantime I wouldn't mind if sagemath 9.2 breaks further. Best, Tobias
Bug#1001521: sphinx: dh_sphinxdoc is too strict about how searchindex.js is loaded
Source: sphinx Version: 4.3.1-1 Severity: normal Hi, sagemath uses a custom sphinx build where some of the search.html files load searchindex.js like this: This causes dh_sphinxdoc to throw an error: dh_sphinxdoc: error: */search.html does not load searchindex.js This was already discussed in #866166 where we went around this by patching sagemath, but the question why this strict check in dh_sphinxdoc is necessary was never answered. It was eventually fixed in sagemath but at some point the issue returned. Could you please make the regex in dh_sphinxdoc less strict to accept the line used by sagemath? Or at least provide an option to dh_sphinxdoc to allow us to ignore this check? At the moment we are not running dh_sphinxdoc at all, which causes a ton of lintian warnings. Best wishes, Tobias
Bug#1001492: lcalc: Please build against pari to enable -e flag
Source: lcalc Version: 2.0.4-1 Severity: normal Hi Julien, I realized that there are some failing sagemath tests where lcalc claims that -e is an invalid option. After some digging I found that this flag only exists when lcalc is built against pari: https://gitlab.com/sagemath/lcalc/-/commit/ef417c25898686967d64e35a15be021b5f178afa While the lcalc package Build-Depends on libpari-dev, maybe building against pari needs to be explicitly enabled? Please provide the -e flag. Best, Tobias
Bug#1001150: ITP: memory-allocator -- memory allocation extension class for cython
Package: wnpp Owner: Tobias Hansen Severity: wishlist * Package name: memory-allocator Version : 0.1.2 Upstream Author : The Sage Development Team * URL : https://github.com/sagemath/memory_allocator * License : GPL-3+ Programming Lang: Python Description : memory allocation extension class for cython An extension class to allocate memory easily with cython. This is a dependency of sagemath.
Bug#1001102: matplotlib: fix bug which causes sagemath doc build to fail
Source: matplotlib Version: 3.5.0-2 Severity: normal Tags: patch fixed-upstream Control: forwarded -1 https://github.com/matplotlib/matplotlib/issues/21683 Hi, I am in the process of updateting sagemath and have problems building the documentation because of this bug. Please apply this upstream patch for the next upload, it should also be fixed in matplotlib 3.5.1. Best, Tobias Bug: https://github.com/matplotlib/matplotlib/issues/21683 Source: https://github.com/matplotlib/matplotlib/pull/21686 >From 34636bfe2b9fa9dfa0eb6db6dc662c9b57fe79d6 Mon Sep 17 00:00:00 2001 From: Jody Klymak Date: Sat, 20 Nov 2021 08:28:56 +0100 Subject: [PATCH 1/2] FIX: don't double transpose xy for add-lines colorbar --- lib/matplotlib/colorbar.py | 2 -- 1 file changed, 2 deletions(-) --- a/lib/matplotlib/colorbar.py +++ b/lib/matplotlib/colorbar.py @@ -783,8 +783,6 @@ xy[[2, 3], 1] += fac # back to axes units... xy = self.ax.transAxes.inverted().transform(inches.transform(xy)) -if self.orientation == 'horizontal': -xy = xy.T col.set_clip_path(mpath.Path(xy, closed=True), self.ax.transAxes) self.ax.add_collection(col)
Bug#992003: Singular update
Hi Jerome, any chance we could get an update of singular to 4.2.1.p0 in experimental? I tried to do it myself once but the package has many patches and it was difficult to get everything right. Best, Tobias
Bug#998190: sagemath: package new upstream version
Source: sagemath Version: 9.2-2 Severity: serious Control: block -1 by 992003 Control: block 986527 by -1 Control: block 993149 by -1 I started updating sagemath to version 9.4, which is the first version that supports pari 2.13 (which is already in Debian and causes a large part of the failing doctests). I got stuck for now because we need an update of singular (see #992003). I am filing this bug to make the situation more transparent. I am marking it as serious because the current sagemath package FTBFS. Since sagemath has not been updated for a while, fixing it requires preparing a compatible combination of its dependencies. It makes most sense to do this for the current sagemath version (rather than heavily patching an old sagemath version to work with newer versions of dependencies). Best, Tobias
Bug#986527: Patches for flaky build and cython unavailability
I started updating sagemath to version 9.4, which is the first version that supports pari 2.13 (which is already in Debian and causes a large part of the failing doctests). I got stuck for now because we need an update of singular (see #992003). Best, Tobias On 8/27/21 7:37 PM, Paul Gevers wrote: > Hi, > > Just for the record, I did a rebuild of the package for two transitions > that are ongoing, and it failed on all architectures. > > Paul >
Bug#992979: sagemath: Blank black page for 3D plots using three.js viewer
Hi, yes, this is probably because sagemath 9.2 uses threejs 117 while in Debian we are using / trying to use the Debian package three.js which is at version 111. Replacing js stuff with Debian packages is always fiddly... Best, Tobias On 8/25/21 9:56 PM, Balbir Thomas wrote: > Package: sagemath > Version: 9.2-2 > Severity: normal > > Dear Maintainer, > > Creating any 3D graphics using the default three.js viewer > opens a blank black page in the web browser. The same plot > with an argument "viewer=tachyon" or "viewer=jmol" results > in a correct plot. > > It was suggested in IRC that this may be a wayland issue > but I did check I am not running wayland using > > loginctl show-session $XDG_SESSION_ID -p Type > > and this shows the session type is tty. I am using the FVWM > desktop. > > -- System Information: > Debian Release: 11.0 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/6 CPU threads) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sagemath depends on: > ii curl 7.74.0-1.3+b1 > ii cysignals-tools 1.10.2+ds-6 > ii cython3 0.29.21-3+b1 > ii ecl 20.4.24+ds-2 > ii eclib-tools 20190909-3+b1 > ii fflas-ffpack 2.4.3-2 > ii flintqs 1:1.0-3+b1 > ii gap-atlasrep 2.1.0-3 > ii gap-dev 4.11.0-4 > ii gap-online-help 4.11.0-4 > ii gap-primgrp 3.4.0-1 > ii gap-smallgrp 1.4.1-2 > ii gap-table-of-marks1.2.9-1 > ii gap-transgrp 2.0.6-2 > ii gfan 0.6.2-4 > ii glpk-utils5.0-1 > ii gmp-ecm 7.0.4+ds-5 > ii ipython3 7.20.0-1 > ii iso-codes 4.6.0-1 > ii jmol > 14.6.4+2016.11.05+dfsg1-4 > ii lcalc 1.23+dfsg-11+b1 > ii less 551-2 > ii libatlas3-base [libblas.so.3] 3.10.3-10 > ii libblas3 [libblas.so.3] 3.9.0-3 > ii libbraiding0 1.0-1+b1 > ii libbrial-groebner31.2.10-1+b1 > ii libbrial3 1.2.10-1+b1 > ii libc6 2.31-13 > ii libcdd-tools 094l-2 > ii libcliquer1 1.21-2 > ii libec520190909-3+b1 > ii libecm1 7.0.4+ds-5 > ii libflint-2.6.32.6.3-3 > ii libflint-arb2 1:2.19.0-1 > ii libgap7 4.11.0-4 > ii libgcc-s1 10.2.1-6 > ii libgd32.3.0-2 > ii libgiac0 1.6.0.41+dfsg1-1 > ii libgivaro94.1.1-2 > ii libglpk40 5.0-1 > ii libgmp10 2:6.2.1+dfsg-1 > ii libgmpxx4ldbl 2:6.2.1+dfsg-1 > ii libgomp1 10.2.1-6 > ii libgsl25 2.6+dfsg-2 > ii libhomfly01.02r6-1 > ii libiml0 1.0.4-1+b2 > ii libjs-mathjax 2.7.9+dfsg-1 > ii libjs-three 111+dfsg1-2 > ii liblfunction0 1.23+dfsg-11+b1 > ii liblrcalc11.2-2+b1 > ii libm4ri-0.0.20200125 20200125-1+b1 > ii libm4rie-0.0.20200125 20200125-1+b2 > ii libmpc3 1.2.0-1 > ii libmpfi0 1.5.3+ds-5 > ii libmpfr6 4.1.0-3 > ii libntl43 11.4.3-1
Bug#992003: package singular 4.2.0p3 in experimental?
Source: singular Version: 1:4.1.2-p1+ds-2 Severity: wishlist Hi Jerome, I started packaging sagemath 9.4 and they are using singular 4.2.0p3 at the moment. It seems tricky to get it to work with anything else than this version. It would be great if we had it in experimental. Best wishes, Tobias
Bug#986527: Patches for flaky build and cython unavailability
Thanks a lot for the patches Ahzo. Especially fixing the file handle leak
should help a lot.
I guess it's too late for bullseye now, but I can at least upload a fixed
package to experimental. I'll also try to fix many of the failing tests by
including sage's (large) patch to support pari 2.13 which was finished in June
[1]. I have to see if I can backport that to sage 9.2 or if I update to sage
9.4 right away.
Best,
Tobias
[1] https://trac.sagemath.org/ticket/30801
On 7/31/21 8:47 PM, Ahzo wrote:
> Control: tags -1 patch
>
> Hi,
>
> the main problem making the sagemath testsuite flaky is that it randomly
> aborts due to 'Too many open files'.
> Thus only a small part of the test suite gets actually run, when the build is
> heavily parallelized.
> This can be seen by reporting not only the number of failed, but also that of
> run tests, which shows significant fluctuations.
>
> The problem occurs, because every finished, but not yet logged worker, holds
> an open fd (a pipe used to read the output of the child actually doing the
> tests).
> Thus when following a long running worker, i.e. logging its messages, while
> it is still running, so many finished tests can accumulate, that the open
> files limit (ulimit -n) is reached.
>
> However, there should be no open pipe per finished worker, as the test suite
> calls 'os.close(self.rmessages)' before waiting for logging the messages.
> So this seems to be caused by something that python does behind the scenes.
> Removing the single line 'finished.append(w)' in src/sage/doctest/forker.py
> prevents the open fd increase, though at the cost of hardly logging any test
> output.
>
> This problem can be avoided by simply logging every finished test, but no
> running one.
>
> With only the 0001-Report-the-number-of-total-tests-run.patch, the result is
> something like:
> Success: 5 of 71435 tests failed, up to 200 failures are tolerated
>
> Adding the dt-Do-not-follow-a-running-worker.patch, the result becomes:
> Success: 194 of 361139 tests failed, up to 200 failures are tolerated
>
> These 194 failures are pretty close to the threshold of 200, so it is not
> particularly surprising, that this can fail in some environments.
> Slightly passing this threshold triggered the build failure in this bug and
> also the one in bug #983931.
>
> Increasing the threshold to 300 should make that rather unlikely, though.
> And considering that there are more than 360 thousand tests, less then 300
> failures means more than 99.9 % of the tests succeeded.
>
> The "cython: not found" issue is trivial to fix and important, because
> otherwise 'sage --cython' does not work and there is no '--cython3' option
> (unlike e.g. the '--ipython3' option).
>
> After adding the 0002-Tolerate-up-to-300-failing-tests.patch and the
> u2-Adapt-to-python2-removal.patch the test result is:
> Success: 189 of 361139 tests failed, up to 300 failures are tolerated
>
> It would also be a good idea to include a backport of commit 5cf493ca51
> ("Avoid libgmp's new lazy allocation") in the next sagemath upload, as that
> fixes a severe memory leak (see bug #964848).
>
> As to the crashes, I can't reproduce any crash when testing
> interfaces/singular.py:
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
> [404 tests, 3.87 s]
>
> This crash also does not always happen for the reproducible builds either,
> e.g. the following log shows it first crashing and then passing this test:
> https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/sagemath_9.2-2.rbuild.log.gz
> [...]
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
> Killed due to segmentation fault
> [...]
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
> [404 tests, 21.06 s]
> [...]
>
> However, a number of other crashes happen during every test run, but only one
> of them causes a test failure:
> sage -t --long --random-seed=0 src/sage/interfaces/tests.py
> **
> File "src/sage/interfaces/tests.py", line 34, in sage.interfaces.tests
> Failed example:
> subprocess.call("echo syntax error | ecl", **kwds) in (0, 255)
> Expected:
> True
> Got:
> False
> **
>
> Similar crashes sometimes also occur when testing interfaces/lisp.py, but
> without causing the test to fail.
> This is a problem in ecl, which crashes when both stdout and stderr are full,
> see bug #710953.
>
> Then there is a crash in nauty-gentourng triggered by
> src/sage/graphs/digraph_generators.py.
> For details see bug #991750.
>
> There are also two SIGABRT crashes in mwrank triggered by
> src/sage/interfaces/mwrank.py.
> These seem to be intentional due to invalid input.
>
> Finally, there are some python crashes (5 SIGQUIT, 1 SIGABRT, 1 SIGSEGV) that
> are all caused intentionally by the test suite.
>
> So none of these crashes are probl
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Hi,
On 5/18/21 8:25 PM, Jochen Sprickerhof wrote:
>
> I think there are a number of problems:
> - Tests not being executed due to the open file limit ("Killing test" in
> the log). If you want to use the tests as an indicator if the build works,
> you should make sure the all tests are executed, otherwise 200 tolerated
> failures is arbitrary.
I have been struggling with this for quite a while and I don't know how to fix
it. It comes and goes and does not seem to affect vanilla upstream builds. This
has impacted progress on the package since one cannot properly work on it when
the test suite crashes. I tried asking upstream for help here and provided more
details:
https://groups.google.com/g/sage-packaging/c/1G_3JiIcbvY
> - I found a number of segfaults in the tests, like:
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py # Killed
> due to segmentation fault
> - Looking at the amd64 log of the buildd:
> Error: 202 tests failed, up to 200 failures are tolerated
> Yes: 202 tests failed, up to 400 failures are tolerated for rerun
> Success: 192 tests failed, up to 200 failures are tolerated
> does that mean we ran the test twice and it passed the second time cause
> there where 10 failures less? Can we be sure that this always succeeds? 192
> is really close to 200.
> - I still see cython: not found in the logs, so there are definitely tests
> broken due to that. Maybe it makes sense to define tests which are allowed
> to break and other which should succeed?
I agree, segfaults and the cython issue should be fixed. The number of failed
tests always grows with time when dependencies change and sagemath is not
adapted accordingly.
Best,
Tobias
Bug#974886: pari: rnfinit hangs (regression)
On 12/9/20 4:56 PM, Bill Allombert wrote: On Wed, Dec 09, 2020 at 04:21:39PM +, Tobias Hansen wrote: On 12/9/20 4:15 PM, Bill Allombert wrote: On Mon, Nov 16, 2020 at 11:16:58AM +0100, Bill Allombert wrote: On Mon, Nov 16, 2020 at 12:19:07AM +, Tobias Hansen wrote: Package: pari-gp Version: 2.13.0-2 Severity: normal Hi, with pari 2.13.0-2 the following code (which is a sagemath test and worked with pari 2.11.4) hangs indefinitely in gp when calling rnfinit. Hello Tobias, this is not a regression in PARI. Note that %2 has changed between PARI 2.11.4 and PARI 2.13.0, so the list of primes is not the right one. The test should be changed to use a factor bound instead of a list of primes. L = rnfinit(K, [pol, 10^6]); finishes quickly. Hello Tobias, Would you mind acknowledging my answer so that we can move forward ? Cheers, Dear Bill, sorry that I forgot to answer. I think you are right, it should be changed in sagemath. Then, should we reassign this bug to sagemath or close it ? Cheers, Close it. The code is already patched out of the sagemath Debian package. Best, Tobias
Bug#974886: pari: rnfinit hangs (regression)
On 12/9/20 4:15 PM, Bill Allombert wrote: On Mon, Nov 16, 2020 at 11:16:58AM +0100, Bill Allombert wrote: On Mon, Nov 16, 2020 at 12:19:07AM +, Tobias Hansen wrote: Package: pari-gp Version: 2.13.0-2 Severity: normal Hi, with pari 2.13.0-2 the following code (which is a sagemath test and worked with pari 2.11.4) hangs indefinitely in gp when calling rnfinit. Hello Tobias, this is not a regression in PARI. Note that %2 has changed between PARI 2.11.4 and PARI 2.13.0, so the list of primes is not the right one. The test should be changed to use a factor bound instead of a list of primes. L = rnfinit(K, [pol, 10^6]); finishes quickly. Hello Tobias, Would you mind acknowledging my answer so that we can move forward ? Cheers, Dear Bill, sorry that I forgot to answer. I think you are right, it should be changed in sagemath. Best, Tobias
Bug#974991: sagemath: segfault on startup
Hi, thanks for the report. I am waiting for upstream to complete their support for pari 2.13 [1]. I could already include their incomplete patch with ~150 failing doctests, or might as well wait for the patch to be completed. Best, Tobias [1] https://trac.sagemath.org/ticket/30801 On 11/20/20 3:15 PM, Sylvain LÉVÊQUE wrote: Hello From trial and error, my workaround is to downgrade python3-cypari2. I have no idea whether it is appropriate or if it is going to trigger something else, but at least I don't have a startup crash anymore. Here are the steps: - add "deb https://snapshot.debian.org/archive/debian/20200628T024451Z unstable main" to /etc/apt/sources.list - sudo apt -o Acquire::Check-Valid-Until=false update - sudo apt install python3-cypari2=2.1.1-2+b2 It seems it is a recurring situation, 906796 happened two years ago. -- Sylvain
Bug#974886: pari: rnfinit hangs (regression)
Package: pari-gp Version: 2.13.0-2 Severity: normal Hi, with pari 2.13.0-2 the following code (which is a sagemath test and worked with pari 2.11.4) hangs indefinitely in gp when calling rnfinit. ? default(parisizemax, 6400) *** Warning: new maximum stack size = 6400 (61.035 Mbytes). ? addprimes([31438243, 238576291, 18775387483, 24217212463267, 1427657500359111961, 135564809928627323997297867381959]) %1 = [31438243, 238576291, 18775387483, 24217212463267, 1427657500359111961, 135564809928627323997297867381959] ? K = bnfinit(y^4-52*y^2+26,1); pol = rnfkummer(bnrinit(K,3,1),Mat(5)) *** rnfkummer: Warning: increasing stack size to 1600. *** rnfkummer: Warning: increasing stack size to 3200. %2 = x^5 + Mod(110204030699148446242240727411928*y^3 + 78307112557844012237261751372042*y^2 - 5674967313235540791169353111603168*y - 4032432401431710468830825285246862, y^4 - 52*y^2 + 26)*x^3 + Mod(3584385289728983153736626109782883812630266327074*y^3 + 2546938261266850926623105095261199201469991786986*y^2 - 184578270215768626033547266289676107590835240929344*y - 131154834263516880788254706677043629282657949113896, y^4 - 52*y^2 + 26)*x^2 + Mod(-15945740003655332675782861358818654840188899544932019410080320228*y^3 - 11330482645350308816127897029643884908098414170467295139095028642*y^2 + 821127437281616776660676358742832568035279253518770614693405673368*y + 583464309314436137234694332457180466091106061530271825134872723487, y^4 - 52*y^2 + 26)*x + Mod(-2525952539668323241105877810188736226631914278044174736728608642554334711529032666/5*y^3 - 1794853133635045389913501675559728057300960191252635296432148581791471098749677474/5*y^2 + 130074172482266569775137436374287366020035438450870128721868069952858489111087504396/5*y + 92426137236702454005536614663867953386157003978148965339540012644512376720064080964/5, y^4 - 52*y^2 + 26) ? L = rnfinit(K, pol); polredabs(polredbest(L.polabs)) Best, Tobias
Bug#970558: openblas: segfault in zgemm_oncopy_EMAG8180 during sagemath test on arm64
Control: tags -1 + fixed-upstream patch
The bug was fixed upstream in the linked issue. Can we apply the attached
upstream patch?
Best,
Tobias
On Fri, 18 Sep 2020 18:09:01 +0200 Tobias Hansen wrote:
> Package: libopenblas0
> Version: 0.3.10+ds-3
> Severity: normal
>
> Hi,
>
> a sagemath test segfaulted in libopenblas.so.0 / zgemm_oncopy_EMAG8180 when
> building on arm-ubc-01.debian.org,
> see
> https://buildd.debian.org/status/fetch.php?pkg=sagemath&arch=arm64&ver=9.2%7Ebeta12-1&stamp=159992&raw=0
>
> openblas was called by numpy and the issue looks similar to #966175 where the
> segfault occurred in dgemm_oncopy_HASWELL.
>
> Extract from the stack backtrace:
>
> #5 0xab2fe3b0 in zgemm_oncopy_EMAG8180 () from
> /usr/lib/aarch64-linux-gnu/libopenblas.so.0
> #6 0xaaac8430 in zgetrf_single () from
> /usr/lib/aarch64-linux-gnu/libopenblas.so.0
> #7 0xaa064f3c in zgesv_ () from
> /usr/lib/aarch64-linux-gnu/liblapack.so.3
> #8 0xaa00f330 in ?? () from
> /usr/lib/python3/dist-packages/numpy/linalg/_umath_linalg.cpython-38-aarch64-linux-gnu.so
>
> Best,
> Tobias
>
>
>
>From 7f26be4802042d7c54bd1645c54adc3e2ff72d50 Mon Sep 17 00:00:00 2001
From: Martin Kroeker
Date: Sun, 1 Nov 2020 00:00:43 +0100
Subject: [PATCH] Reunify BUFFERSIZE across arm64 platforms to avoid segfaults
in DYNAMIC_ARCH
---
common_arm64.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/common_arm64.h b/common_arm64.h
index 314946282..9cdded305 100644
--- a/common_arm64.h
+++ b/common_arm64.h
@@ -142,14 +142,8 @@ static inline int blas_quickdivide(blasint x, blasint y){
#define HUGE_PAGESIZE ( 4 << 20)
#ifndef BUFFERSIZE
-#if defined(CORTEXA57)
-#define BUFFER_SIZE (20 << 20)
-#elif defined(TSV110) || defined(EMAG8180)
#define BUFFER_SIZE (32 << 20)
#else
-#define BUFFER_SIZE (16 << 20)
-#endif
-#else
#define BUFFER_SIZE (32 << BUFFERSIZE)
#endif
Bug#972916: sagemath ftbfs with python3.9
Control: tags -1 + pending It should be fixed in git, but before another upload cypari2 needs to be updated. Best, Tobias On 10/27/20 5:17 PM, Graham Inggs wrote: > Control: reopen -1 > > Hi > > The new upload of sagemath/9.2-1 still FTBFS [1] with Python 3.9 as > default. I've copied what I hope is the relevant part of the log > below. > > Regards > Graham > > > [1] > https://people.debian.org/~ginggs/python3.9-default/sagemath_9.2-1+build1_amd64-2020-10-27T15:56:32Z.build > > > make[2]: Entering directory '/<>' > mkdir -p debian/tmp > mv sage/local debian/tmp/usr > mv debian/tmp/usr/lib/python3.8 debian/tmp/usr/lib/python3 > mv: cannot stat 'debian/tmp/usr/lib/python3.8': No such file or directory > make[2]: *** [debian/rules:83: override_dh_auto_install] Error 1 > make[2]: Leaving directory '/<>' > make[1]: *** [debian/rules:40: install] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:40: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 >
Bug#970558: openblas: segfault in zgemm_oncopy_EMAG8180 during sagemath test on arm64
Package: libopenblas0 Version: 0.3.10+ds-3 Severity: normal Hi, a sagemath test segfaulted in libopenblas.so.0 / zgemm_oncopy_EMAG8180 when building on arm-ubc-01.debian.org, see https://buildd.debian.org/status/fetch.php?pkg=sagemath&arch=arm64&ver=9.2%7Ebeta12-1&stamp=159992&raw=0 openblas was called by numpy and the issue looks similar to #966175 where the segfault occurred in dgemm_oncopy_HASWELL. Extract from the stack backtrace: #5 0xab2fe3b0 in zgemm_oncopy_EMAG8180 () from /usr/lib/aarch64-linux-gnu/libopenblas.so.0 #6 0xaaac8430 in zgetrf_single () from /usr/lib/aarch64-linux-gnu/libopenblas.so.0 #7 0xaa064f3c in zgesv_ () from /usr/lib/aarch64-linux-gnu/liblapack.so.3 #8 0xaa00f330 in ?? () from /usr/lib/python3/dist-packages/numpy/linalg/_umath_linalg.cpython-38-aarch64-linux-gnu.so Best, Tobias
Bug#963290: e-antic: FTBFS: error: #error FLINT 2.5.2 or 2.5.3 required
Hi, since flint 2.6.3 is now in unstable, can this be fixed with a rebuild? Best, Tobias On Wed, 29 Jul 2020 09:36:31 +0200 Jerome BENOIT wrote: > Hello Lucas, thanks for the report. I am working on it. Jerome > -- > Jerome BENOIT | calculus+at-rezozer^dot*net > https://qa.debian.org/developer.php?login=calcu...@rezozer.net > AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B >
Bug#963338: sagemath: FTBFS: RuntimeError: Aborted
Control: tags 963338 + help Just yesterday I just did a test build of vanilla sage (not the Debian package) 9.2.beta6 with the python 3.8 patch from [1] and Debian's python 3.8 to see if the file handle leak that happens during parallel builds of the Debian package also happens there. It didn't. I don't know how to debug this. Best, Tobias [1] https://trac.sagemath.org/ticket/27754 On 8/1/20 10:43 AM, Jerome BENOIT wrote: > Thanks for the report. Meanwhile the Sagemath Debian team take a summer > break. Cheers, Jerome
Bug#886642: please default to a larger /boot for guided partitioning
Control: severity -1 important Please someone do this, having these small default sizes for /boot is really annoying and has been the only reason I had to reinstall Debian on several systems over the years. Let me explain. I usually use guided partitioning to set up encrypted LVM. Doing this, it is not that simple to change the size of /boot. I think it is equivalent to doing the whole partitioning manually. Also, having an encrypted LVM starting right after /boot, it is very complicated to change the size of /boot later. So it is important to have a sensible default for the size of /boot. I have one system where /boot is 162M which was apparently the default a few years ago. Even after changing the initrd encryption to xz, every single kernel upgrade fails, because dkms does a backup of the initrd, so one needs at least 3-4 times the space of the initrd to be available to do an update. After the failed update I always have to delete the dkms backup and run apt install -f. I just did a fresh install of Debian 10 (amd64) and guess what, the size of /boot is 256M, with the size of the default initrd.img 64.2M. System.map and vmlinuz add another 8.7M. Free space on /boot: 147M. This will probably make kernel updates fail in 2 years if the encryption is not changed to xz. (Of course always making sure that only a single kernel image is installed before the update.) 512M is already a low value for the size of /boot today. Best, Tobias On Mon, 8 Jan 2018 11:50:05 + Jonathan Dowland wrote: > Package: debian-installer > Version: 20171204 > Severity: wishlist > > Hi there! Filing this after a discussion on IRC. For various guided > partitioning profiles (at least "use entire disk and use LVM") the created > /boot is 256M in size[1]. > > I'd like to suggest a larger default, at least 512M[2]. Note: this would only > change the default for guided partitioning and would not prevent someone from > manually specifying a smaller size. > > Rationale: > > with current kernel and default initramfs/generator settings, you need roughly > 33.2M for a vmlinuz/initramfs/system.map triplet on amd64. So there's enough > room for 7 at a time, but you also need at least 10M for grub, and that may > very a lot depending on the specifics of the host. > > I think the default should leave enough room for a user to install more rescue > options, since it can be very hard/impossible to grow /boot later on if they > decide they want it. GRML currently requires ~280M for the small version (600M > for the fully featured version). grml-rescueboot is a very nice integration > package to add grml ISOs to the GRUB menu and it would be nice if it would be > usable on a default installation without having the foresight to manually set > the /boot size larger. (There's also grub-imageboot as a more generic > solution, > the user may wish to put e.g. BIOS/firmware update ISOs in /boot for use with > this, etc.) > > > This seems like a nice bug for a beginner to patch, and I am a beginner for > d-i (but anyone else who wants to try please don't let me stop you) > > > [1] perhaps things are more complex than that and it depends on the size of > the > disk; it has appeared 256G for me with VM tests (=8G drive) and real > drives > (=512G) > > [2] Exactly how large, I'm sure, many might have an opinion on; let the > discussion > commence! > > -- System Information: > Debian Release: 9.1 > APT prefers stable > APT policy: (990, 'stable'), (600, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.68-x86_64-linode89 (SMP w/2 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland > ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net > ⠈⠳⣄ Please do not CC me, I am subscribed to the list. > >
Bug#955751: gap-atlasrep: package is broken
Source: gap-atlasrep Version: 2.1.0-1 Severity: grave Hi Bill, during a test build of sage I noticed that the newly updated gap-atlasrep package seems to be seriously broken. Trying the first commands from the atlasrep tutorial yields this: $ gap ┌───┐ GAP 4.10.2 of 19-Jun-2019 │ GAP │ https://www.gap-system.org └───┘ Architecture: x86_64-pc-linux-gnu-default64-kv3 Configuration: gmp 6.2.0, readline Loading the library and packages ... Error, AppendList: must be a small list (not a boolean or fail) in Append( res, arg[i] ); at /usr/share/gap/lib/list.gi:2011 called from Concatenation( "core|", Filename( DirectoriesPackageLibrary( "atlasrep", "" ), "atlasprm.json" ) ) at /usr/share/gap/pkg/AtlasRep/gap/userpref.g:154 called from record.default( ) at /usr/share/gap/lib/userpref.g:274 called from ( ) called from read-eval loop at /usr/share/gap/pkg/AtlasRep/gap/userpref.g:208 you can replace via 'return ;' brk> LoadPackage( "AtlasRep", false ); true brk> DisplayAtlasInfo(); Syntax warning: Unbound global variable in *errin*:2 DisplayAtlasInfo(); ^ Error, Variable: 'DisplayAtlasInfo' must have a value in called from Concatenation( "core|", Filename( DirectoriesPackageLibrary( "atlasrep", "" ), "atlasprm.json" ) ) at /usr/share/gap/pkg/AtlasRep/gap/userpref.g:154 called from record.default( ) at /usr/share/gap/lib/userpref.g:274 called from ( ) called from read-eval loop at *errin*:2 brk> g:= AtlasGroup( "M24" ); Syntax warning: Unbound global variable in *errin*:3 g:= AtlasGroup( "M24" ); ^^ Syntax warning: Unbound global variable in *errin*:3 g:= AtlasGroup( "M24" ); ^ Error, Variable: 'AtlasGroup' must have a value in called from Concatenation( "core|", Filename( DirectoriesPackageLibrary( "atlasrep", "" ), "atlasprm.json" ) ) at /usr/share/gap/pkg/AtlasRep/gap/userpref.g:154 called from record.default( ) at /usr/share/gap/lib/userpref.g:274 called from ( ) called from read-eval loop at *errin*:3 Downgrading gap-atlasrep to 1.5.1-2 fixes the problem. Best, Tobias
Bug#953633: pari: backport patch for #2164, #2208
On 3/26/20 10:56 PM, Bill Allombert wrote: > On Wed, Mar 25, 2020 at 08:32:59PM +0100, Tobias Hansen wrote: >>> If I release 2.11.4-pre1 on April 3, would that be OK ? >>> >>> Cheers, >> Sure, but that means that the fix would only be in Debian with the >> release of 2.11.4 in about three weeks right? Then I should still >> disable the test in order not to have a broken sagemath all this time. > Well I suppose I can upload 2.11.4-pre1 to Debian on the same day. > > Cheers, Ok, then I'll wait for that. Thank you. Best, Tobias
Bug#953633: pari: backport patch for #2164, #2208
On 3/25/20 8:28 PM, Bill Allombert wrote: > On Wed, Mar 25, 2020 at 03:02:48PM +0100, Tobias Hansen wrote: >> On 3/25/20 1:08 PM, Bill Allombert wrote: >>> On Wed, Mar 25, 2020 at 12:47:17PM +0100, Tobias Hansen wrote: >>>> Hi Bill, >>>> >>>> is pari 2.11.4-pre1 going to be released soon? Otherwise, could you >>>> please consider backporting the patch for the Debian package? sagemath >>>> was removed from testing today because I'm waiting for this bug to be >>>> fixed before I do an upload fixing RC bugs. >>> I plan to release 2.11.4 in May, and 2.11.4-pre1 two weeks before. >>> If this is too late for you I can do something, but to be honest, >>> Sagemath is making this bug RC completly artificially. >>> Why not disable the test until that ? >>> >>> Cheers, >>> >> Of course I can disable the test that is timing out and ignore the >> other failures, but that leaves some functionality in pari and >> sagemath broken. Normally it's better to just fix bugs. If you confirm >> that you prefer to wait for pari 2.11.4 with this I will go ahead and >> disable the test. > We need to check that the fix for this bug do not create regressions, > and this takes time. > Indeed this bug occured while fixing another. > > If I release 2.11.4-pre1 on April 3, would that be OK ? > > Cheers, Sure, but that means that the fix would only be in Debian with the release of 2.11.4 in about three weeks right? Then I should still disable the test in order not to have a broken sagemath all this time. Best, Tobias
Bug#953633: pari: backport patch for #2164, #2208
On 3/25/20 1:08 PM, Bill Allombert wrote: > On Wed, Mar 25, 2020 at 12:47:17PM +0100, Tobias Hansen wrote: >> Hi Bill, >> >> is pari 2.11.4-pre1 going to be released soon? Otherwise, could you >> please consider backporting the patch for the Debian package? sagemath >> was removed from testing today because I'm waiting for this bug to be >> fixed before I do an upload fixing RC bugs. > > I plan to release 2.11.4 in May, and 2.11.4-pre1 two weeks before. > If this is too late for you I can do something, but to be honest, > Sagemath is making this bug RC completly artificially. > Why not disable the test until that ? > > Cheers, > Of course I can disable the test that is timing out and ignore the other failures, but that leaves some functionality in pari and sagemath broken. Normally it's better to just fix bugs. If you confirm that you prefer to wait for pari 2.11.4 with this I will go ahead and disable the test. Best, Tobias
Bug#953633: pari: backport patch for #2164, #2208
On 3/11/20 11:27 PM, Tobias Hansen wrote: > On 3/11/20 8:22 PM, Bill Allombert wrote: >> On Wed, Mar 11, 2020 at 02:15:31PM +0000, Tobias Hansen wrote: >>> Source: pari >>> Version: 2.11.3-1 >>> Severity: normal >>> Tags: patch >>> >>> Hi Bill, >>> >>> please consider backporting the patch for the pari bugs #2164 and >>> #2208. It seems to be a serious bug and it breaks several things in >>> sagemath that worked with 2.11.2. >> Hi Tobias, >> >> Sorry for this regression, I forgot to backport the fix for #2164. >> >> Unfortunately, it seems nobody from Sagemath checked PARI 2.11.3-pre1 during >> the >> two-weeks test period. >> >> Would you be willing to test PARI 2.11.4-pre1 when it is published? >> >> Cheers, > > Hi, > > > sure, I can run a test build once 2.11.4-pre1 is out. > > > Best, > > Tobias > Hi Bill, is pari 2.11.4-pre1 going to be released soon? Otherwise, could you please consider backporting the patch for the Debian package? sagemath was removed from testing today because I'm waiting for this bug to be fixed before I do an upload fixing RC bugs. Best, Tobias
Bug#952309: cysignals: FTBFS: help2man: can't get `--help' info from /<>/debian/adhoc/wrappers/cysignals-CSI
The reason for this is that src/scripts/cysignals-CSI calls python which is not installed. The script has to be ported to python3. Best, Tobias On 2/23/20 2:37 PM, Lucas Nussbaum wrote: > Source: cysignals > Version: 1.10.2+ds-3 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200222 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): >> fakeroot debian/rules binary >> dh binary --with python3 --with sphinxdoc --buildsystem=pybuild >>dh_testroot -O--buildsystem=pybuild >>debian/rules override_dh_prep-indep >> make[1]: Entering directory '/<>' >> help2man --manual="CySIgnals Cython package" --source="CySIgnals (Debian >> 1.10.2+ds-3)" --version-string="cysignals-CSI - 1.10.2+ds-3" >> --locale=C.UTF-8 --no-info -s 1 \ >> -n "debugger information extractor for Python processes" \ >> -o cysignals-CSI.1 \ >> /<>/debian/adhoc/wrappers/cysignals-CSI >> help2man: can't get `--help' info from >> /<>/debian/adhoc/wrappers/cysignals-CSI >> Try `--no-discard-stderr' if option outputs to stderr >> make[1]: *** [debian/rules:43: override_dh_prep-indep] Error 255 > > The full build log is available from: >http://qa-logs.debian.net/2020/02/22/cysignals_1.10.2+ds-3_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. >
Bug#950147: sagemath ftbfs with python 3.8
Control: block -1 by 953633 We have a patch for this but I'm waiting for a fix of a bug in pari that causes test failures and a test timeout. Best, Tobias On Wed, 29 Jan 2020 17:46:47 +0100 Tobias Hansen wrote: > It does if applied first. But ok, the ipython 7 patch needed some small > changes. I applied it in the branch python3.8 on salsa. > > Best, > Tobias > > On 1/29/20 5:35 PM, Matthias Klose wrote: > > On 1/29/20 5:20 PM, Tobias Hansen wrote: > >> Hi, > >> > >> Arch Linux has a patch for that: > >> https://git.archlinux.org/svntogit/community.git/tree/trunk/sagemath-python-3.8.patch?h=packages/sagemath > >> > >> We plan to apply it when the default Python switches to 3.8. If we apply > >> it now, the doctests will fail with Python 3.7. I haven't yet tried > >> building with Python 3.8 though. > > yes, I'm aware of that patch. It doesn't apply cleanly. Could you help > > updating it? > > > > > >> Best, > >> Tobias > >> > >> On 1/29/20 3:07 PM, Matthias Klose wrote: > >>> Package: src:sagemath > >>> Version: 9.0-1 > >>> Severity: important > >>> Tags: sid bullseye > >>> User: debian-pyt...@lists.debian.org > >>> Usertags: python3.8 > >>> > >>> sagemath ftbfs with python 3.8. Not sure if you already can check that in > >>> Debian, however in Ubuntu, there seem to be a lot of failing tests, plus > >>> the > >>> tests failing because of too many open files (googling about that, I > >>> found some > >>> hints, but just for MacOSX). > >>> > >>> Build logs at > >>> https://launchpad.net/ubuntu/+source/sagemath/9.0-1build1 > >>> > >>> Any help would be appreciated. > >>> > > >
Bug#953633: pari: backport patch for #2164, #2208
On 3/11/20 8:22 PM, Bill Allombert wrote: > On Wed, Mar 11, 2020 at 02:15:31PM +0000, Tobias Hansen wrote: >> Source: pari >> Version: 2.11.3-1 >> Severity: normal >> Tags: patch >> >> Hi Bill, >> >> please consider backporting the patch for the pari bugs #2164 and >> #2208. It seems to be a serious bug and it breaks several things in >> sagemath that worked with 2.11.2. > Hi Tobias, > > Sorry for this regression, I forgot to backport the fix for #2164. > > Unfortunately, it seems nobody from Sagemath checked PARI 2.11.3-pre1 during > the > two-weeks test period. > > Would you be willing to test PARI 2.11.4-pre1 when it is published? > > Cheers, Hi, sure, I can run a test build once 2.11.4-pre1 is out. Best, Tobias
Bug#953633: pari: backport patch for #2164, #2208
Source: pari Version: 2.11.3-1 Severity: normal Tags: patch Hi Bill, please consider backporting the patch for the pari bugs #2164 and #2208. It seems to be a serious bug and it breaks several things in sagemath that worked with 2.11.2. The patch is at https://pari.math.u-bordeaux.fr/cgi-bin/gitweb.cgi?p=pari.git;a=commitdiff;h=c7a1d35f382e96ddf14694be27a0ca5746880700 Best, Tobias
Bug#943451: Is that bug really pplpy's problem?
Hi, yes, it also looks more like doxygen bug to me. I didn't reassign yet because if doxygen upstream does not want to fix it, a workaround in ppl (not pplpy) might be needed. Best, Tobias On 2/23/20 8:46 PM, Julien Puydt wrote: > Hi, > > it looks more like a doxygen 1.8.16 bug than a pplpy issue, isn't it? > > If that is so, then it should be marked as affecting pplpy, but > assigned to doxygen. > > Thanks, > > JP >
Bug#951275: gap: Install libgap following library conventions
On 2/13/20 5:49 PM, Bill Allombert wrote: > On Thu, Feb 13, 2020 at 05:28:10PM +0100, Tobias Hansen wrote: >> Source: gap >> Version: 4r10p2-2 >> Severity: normal >> >> Hi Bill, >> >> please keep in mind to create a library package for libgap and install it to >> /usr/lib/triplet. >> >> We still need to keep extra hacks in sagemath to find libgap and >> library transitions for libgap can also not be handled properly >> without a library package. > Hello Tobias, > > Thanks for the reminder! > However, for that I need the GAP team to provide a stable ABI across point > release. This is not the case with GAP 4.10. That's ok, I just wanted to create the bug as a reminder. > Also once it is done, I will not be able to apply any patches that > change the library ABI. That's fine with me, all the sagemath related patches are merged upstream as far as I know. Best, Tobias
Bug#951275: gap: Install libgap following library conventions
Source: gap Version: 4r10p2-2 Severity: normal Hi Bill, please keep in mind to create a library package for libgap and install it to /usr/lib/triplet. We still need to keep extra hacks in sagemath to find libgap and library transitions for libgap can also not be handled properly without a library package. Best, Tobias On 12/16/18 10:24 PM, Bill Allombert wrote: > On Sun, Dec 16, 2018 at 08:25:17PM +0100, Tobias Hansen wrote: >> + * Install libgap to /usr/lib/triplet. > > Do you need this now ? When the interface to libgap has stabilized, then > probably we will split libgap from gap-dev and move it to > /usr/lib/triplet, but as long as it is an experimental feature it is > best to keep it in a subdirectory. >
Bug#945522: has to be fixed in brial
Hi Matthias, you reassigned the two bugs #945522 and #949029 to brial, however I don't see any connection to brial. Neither beancount nor python-bleach depends on brial, which is a math library for dealing with polynomials over boolean rings by the way. Did you confuse brial with something else? Best, Tobias On Sat, 8 Feb 2020 11:00:29 +0100 Matthias Klose wrote: > Control: reassign -1 src:brial > > this has to be fixed in brial. Changing the standard library just for the > distro isn't going to work. Yes, it's unfortunate that such a change was > released, but IMO it's too late to fix there. > > >
Bug#950467: sagemath: Install, run & crash w/ "---> 15 app.initialize()"
Hi, looks like an instance of #907119 which was fixed in gsl 2.5+dfsg-5, however you have gsl 2.5+dfsg-4 installed. Please update your packages to the versions in unstable. Best, Tobias On 2/2/20 9:13 AM, Kingsley G. Morse Jr. wrote: > ImportError: /usr/lib/i386-linux-gnu/libgsl.so.23: undefined symbol: > cblas_ctrmv > ii libgsl23 2.5+dfsg-4
Bug#920147: Sage FTBFS on mipsel + mips64el
Thanks, that got lost in the other bug. It is correct bash test syntax (see 'man test') where -a between two logical expressions means 'and'. mips64 is the GNU name for the architecture, mips64el is an invention of Debian. Best, Tobias On 2/2/20 4:22 AM, John Scott wrote: > On the off-chance they're relevant and Jmol is a red herring, I'm re-sending > my misplaced comments [1] about relevant parts of /usr/bin/sage here: > >> By the way, looking at the header of that file I see >> # workaround #892622; unfortunately we can't simply run setarch -R when >> running Singular >> # because src/sage/libs/singular/singular.pyx loads libsingular.so into the >> current process >> if [ "$(arch)" = "mips64" -a -z "$SAGE_DEB_MIPS64_WORKAROUND" ]; then >> SAGE_DEB_MIPS64_WORKAROUND=1 exec setarch mips64 -R "$0" "$@" >> fi >> >> I don't understand the test inside the brackets. Why do you use -a [in >> addition to the -z] when there is no mention of a file? And if you're >> checking equality, shouldn't that be a double equals sign (==)? >> >> Furthermore, the code refers to mips64, but #892622 refers to mips64el. Is >> it possible these issues are the cause of Sage failing to build from source >> there (#920147)? > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948731#12
Bug#950450: libm4rie-0.0.20200125: Depends on libm4ri-0.0.20200115
Package: libm4rie-0.0.20200125 Version: 20200125-1 Severity: serious Hi, seems that something went wrong with the binary upload of libm4rie on amd64. On this architecture libm4rie-0.0.20200125 depends on libm4ri-0.0.20200115 which makes it uninstallable. This might be fixable with a source-only-upload. Best, Tobias
Bug#950147: sagemath ftbfs with python 3.8
It does if applied first. But ok, the ipython 7 patch needed some small changes. I applied it in the branch python3.8 on salsa. Best, Tobias On 1/29/20 5:35 PM, Matthias Klose wrote: > On 1/29/20 5:20 PM, Tobias Hansen wrote: >> Hi, >> >> Arch Linux has a patch for that: >> https://git.archlinux.org/svntogit/community.git/tree/trunk/sagemath-python-3.8.patch?h=packages/sagemath >> >> We plan to apply it when the default Python switches to 3.8. If we apply it >> now, the doctests will fail with Python 3.7. I haven't yet tried building >> with Python 3.8 though. > yes, I'm aware of that patch. It doesn't apply cleanly. Could you help > updating it? > > >> Best, >> Tobias >> >> On 1/29/20 3:07 PM, Matthias Klose wrote: >>> Package: src:sagemath >>> Version: 9.0-1 >>> Severity: important >>> Tags: sid bullseye >>> User: debian-pyt...@lists.debian.org >>> Usertags: python3.8 >>> >>> sagemath ftbfs with python 3.8. Not sure if you already can check that in >>> Debian, however in Ubuntu, there seem to be a lot of failing tests, plus the >>> tests failing because of too many open files (googling about that, I found >>> some >>> hints, but just for MacOSX). >>> >>> Build logs at >>> https://launchpad.net/ubuntu/+source/sagemath/9.0-1build1 >>> >>> Any help would be appreciated. >>>
Bug#950147: sagemath ftbfs with python 3.8
Hi, Arch Linux has a patch for that: https://git.archlinux.org/svntogit/community.git/tree/trunk/sagemath-python-3.8.patch?h=packages/sagemath We plan to apply it when the default Python switches to 3.8. If we apply it now, the doctests will fail with Python 3.7. I haven't yet tried building with Python 3.8 though. Best, Tobias On 1/29/20 3:07 PM, Matthias Klose wrote: > Package: src:sagemath > Version: 9.0-1 > Severity: important > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: python3.8 > > sagemath ftbfs with python 3.8. Not sure if you already can check that in > Debian, however in Ubuntu, there seem to be a lot of failing tests, plus the > tests failing because of too many open files (googling about that, I found > some > hints, but just for MacOSX). > > Build logs at > https://launchpad.net/ubuntu/+source/sagemath/9.0-1build1 > > Any help would be appreciated. >
Bug#950008: gfan: assertion fails on riscv64
Source: gfan Version: 0.6.2-2 Severity: normal Hi, many of sagemath's doctests in the interface to gfan fail on riscv64 with the following error: gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed. It looks like the pointer arithmetic in the function tail() in application.cpp does not work like this on riscv64. Unfortunately there are no porterboxes for riscv64 yet, so I can't come up with a minimal example triggering the bug. Best, Tobias
Bug#949446: python3-ipython: Prevents sage fro starting, fails to import _baseclass_reprs
Control: reassign -1 src:sagemath 8.9-3 Hi, please wait for sagemath 9.0 with the bug reports. We know that sagemath 8.9 is broken at the moment for various reasons. For one it has to be patched to work with ipython 7 and there are several ongoing library transitions that break sagemath 8.9. Best, Tobias On 1/21/20 12:11 AM, Amaury Pouly wrote: > Package: python3-ipython > Version: 7.11.1-1 > Severity: important > > Dear Maintainer, > > Sagemath is not usable on my system because of an import error. I am not sure > if the issue > lies with sage or with ipython. Here is the backtrace: > > Traceback (most recent call last): > File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main > "__main__", mod_spec) > File "/usr/lib/python3.7/runpy.py", line 85, in _run_code > exec(code, run_globals) > File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/__main__.py", > line 3, in > IPKernelApp.launch_instance(kernel_class=SageKernel) > File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line > 663, in launch_instance > app.initialize(argv) > File "", line 2, in initialize > File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line > 87, in catch_config_error > return method(app, *args, **kwargs) > File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 542, in > initialize > self.init_kernel() > File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 447, in > init_kernel > user_ns=self.user_ns, > File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", > line 412, in instance > inst = cls(*args, **kwargs) > File "/usr/lib/python3/dist-packages/sage/repl/ipython_kernel/kernel.py", > line 51, in __init__ > super(SageKernel, self).__init__(**kwds) > File "/usr/lib/python3/dist-packages/ipykernel/ipkernel.py", line 68, in > __init__ > kernel = self, > File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", > line 412, in instance > inst = cls(*args, **kwargs) > File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", > line 683, in __init__ > self.init_display_formatter() > File "/usr/lib/python3/dist-packages/sage/repl/interpreter.py", line 231, > in init_display_formatter > backend.get_display_manager().switch_backend(backend, shell=self) > File > "/usr/lib/python3/dist-packages/sage/repl/rich_output/display_manager.py", > line 322, in switch_backend > self._backend.install(**kwds) > File > "/usr/lib/python3/dist-packages/sage/repl/rich_output/backend_ipython.py", > line 59, in install > from sage.repl.display.formatter import SageDisplayFormatter > File "/usr/lib/python3/dist-packages/sage/repl/display/formatter.py", line > 66, in > from sage.repl.display.pretty_print import SagePrettyPrinter > File "/usr/lib/python3/dist-packages/sage/repl/display/pretty_print.py", > line 29, in > from sage.repl.display.fancy_repr import * > File "/usr/lib/python3/dist-packages/sage/repl/display/fancy_repr.py", line > 17, in > from IPython.lib.pretty import ( > ImportError: cannot import name '_baseclass_reprs' from 'IPython.lib.pretty' > (/usr/lib/python3/dist-packages/IPython/lib/pretty.py) > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.2-amdmp2 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages python3-ipython depends on: > ii python3 3.7.5-3 > ii python3-backcall0.1.0-2 > ii python3-decorator 4.3.0-1.1 > ii python3-jedi0.15.2-1 > ii python3-pexpect 4.6.0-1 > ii python3-pickleshare 0.7.5-1 > ii python3-pkg-resources 44.0.0-1 > ii python3-prompt-toolkit 2.0.10-2 > ii python3-pygments2.3.1+dfsg-1 > ii python3-traitlets 4.3.3-2 > > python3-ipython recommends no packages. > > python3-ipython suggests no packages. > > -- no debconf information >
Bug#948731: Shouldn't work upstream either
Hi, I think the point is that upsteam $0-version.sh is always available since the script sage always comes with sage-version.sh in the same folder. We just have to source sage-env before the problematic functions. Best, Tobias On 1/18/20 1:31 PM, Julien Puydt wrote: > Hi, > > I tried to have a look at this bug : I don't even understand how it is > supposed to work upstream, so I reported it there: > https://trac.sagemath.org/ticket/29036 > > JP >
Bug#949023: Correction: cpython 3.8
Hi, yes, we are building sagemath only for the default python. For transitioning to python 3.8, upstream is still working on [1] doing it in a python 2 compatible way I think. Since we don't have to support python 2 anymore we can just use the patch from Arch Linux [2]. However the patch changes 200+ results of doctests so once we apply it these tests fail with python 3.7. Can we get away with only building for the default python also in the future? That would mean that brials autopkgtests can only use the default python, maybe that's ok? Best, Tobias [1] https://trac.sagemath.org/ticket/27754 [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/sagemath-python-3.8.patch?h=packages/sagemath On 1/16/20 5:41 PM, Julien Puydt wrote: > Hi, > > I realise I mention cython in my last message, but the file name says > it's actually about cpython : probably we build something only for the > default Python 3 and not for all available versions. > > I'll ask on the Debian Python Module Team mailing list for insight on > the matter in a few days if we're stuck. > > JP >
Bug#949137: [Python-modules-team] Bug#949137: Please package ipython 7.11.1
Control: block 949287 by 949137 Thanks, I already used it for my tests with sagemath 9.0. The need for ipython 7.11.1 was now also reported as sagemath bug #949287. Thanks for that. Best, Tobias On 1/17/20 3:58 PM, Emmanuel Arias wrote: > Source: ipython > Version: 7.11.0-2 > > Hi Tobias, > > I've just push to salsa the new upstream release. I will need sponsorship. > > Cheers, > Arias Emmanuel > @eamanu > http://eamanu.com > > El vie., 17 de ene. de 2020 a la(s) 07:51, Tobias Hansen > (than...@debian.org) escribió: >> >> Source: ipython >> Version: 7.11.0-2 >> Severity: wishlist >> >> Hi, >> >> ipython 7.11.1 brought back some compatibility functions that are needed for >> sagemath 9.0: >> >> https://github.com/ipython/ipython/commit/9a8d1a345f48b7aa85e6a6da5841b65ee1f8de63#diff-230d8a7c9440fa2ab8c6a3ebe9a9f279 >> >> Could you please update the package? >> >> Best, >> Tobias >> >> ___ >> Python-modules-team mailing list >> python-modules-t...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
Bug#949137: Please package ipython 7.11.1
Source: ipython Version: 7.11.0-2 Severity: wishlist Hi, ipython 7.11.1 brought back some compatibility functions that are needed for sagemath 9.0: https://github.com/ipython/ipython/commit/9a8d1a345f48b7aa85e6a6da5841b65ee1f8de63#diff-230d8a7c9440fa2ab8c6a3ebe9a9f279 Could you please update the package? Best, Tobias
Bug#944648: sagemath FTBFS on i386
Control: forwarded 944648 https://trac.sagemath.org/ticket/28795 On 11/28/19 2:09 AM, peter green wrote: >> All three failures give the error message >> >> OverflowError: Python int too large to convert to C long >> >> from >> >> File "sage/rings/polynomial/polynomial_integer_dense_flint.pyx", line 284, >> in >> sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint.__init__ >> >> (build/cythonized/sage/rings/polynomial/polynomial_integer_dense_flint.cpp:6548) >> fmpz_poly_set_coeff_si(self.__poly, i, a) >> >> Help on finding a fix would be appreciated. > On line 282 of that file (assuming the version at > https://github.com/sagemath/sage/blob/master/src/sage/rings/polynomial/polynomial_integer_dense_flint.pyx > is the same as the one in the Debian package). > > "if type(a) is int:" > > If that conditional is true then the code takes a fast path, which assumes > that the value of "a" fits in a C long. > > In python 2 "int" was a type limited to the size of a c long, so the check > was appropriate. However in python 3 "int" is an arbitrary precision type, so > we need to check if it will fit in the range of a C long. > > There are several other conditionals on types being "int" in the file that > presumably need fixing in the same way. I also spotted a "isinstance(x0, > long):" which i'm pretty sure will fail in python 3 as there is no type long > in python 3. > > I have attached a completely untested patch. > Thanks, that helped a lot. Knowing this I was able to find the upstream ticket were this was fixed only 3 days ago: https://trac.sagemath.org/ticket/28795 I'll apply that upstream patch soon. Sagemath 9.0 will be the first release with Python 3 as default so I hope it will have less problems than 8.9. Best, Tobias
Bug#827848: snapd: Purging snapd doesn't properly delete snapd from the system
Version: 2.37.4-1+b1 Now trying to purge snapd leads directly to an error: $ sudo apt purge snapd Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: snapd* 0 upgraded, 0 newly installed, 1 to remove and 7 not upgraded. After this operation, 61.0 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 394506 files and directories currently installed.) Removing snapd (2.37.4-1+b1) ... Processing triggers for mime-support (3.62) ... Processing triggers for gnome-menus (3.31.4-3) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for desktop-file-utils (0.23-4) ... (Reading database ... 394456 files and directories currently installed.) Purging configuration files for snapd (2.37.4-1+b1) ... Stopping snap-core-8039.mount Stopping unit snap-core-8039.mount Waiting until unit snap-core-8039.mount is stopped [attempt 1] snap-core-8039.mount is stopped. Removing snap core and revision 8039 Removing snap-core-8039.mount Final directory cleanup Discarding preserved snap namespaces Removing extra snap-confine apparmor rules Removing snapd cache rm: cannot remove '/var/cache/snapd/aux': Is a directory dpkg: error processing package snapd (--purge): installed snapd package post-removal script subprocess returned error exit status 1 Errors were encountered while processing: snapd E: Sub-process /usr/bin/dpkg returned an error code (1)
Bug#945401: RM: sagenb -- RoM; deprecated and not ported to Python 3
Package: ftp.debian.org Severity: normal Control: block 938427 by -1 Control: block 941693 by -1 Control: block -1 by 945397 Hi, I'm requesting removal of sagenb on behalf of the Debian Science Team. There is no Python 3 version and sagemath now uses Jupyter notebook instead (also see #941693). The remaining sagemath binaries that still depend on python-sagenb should be removed in #945397. Best, Tobias
Bug#945397: RM: sagemath [armhf i386] -- RoM; FTBFS; old packages obstruct py2removal
Package: ftp.debian.org Severity: normal Hi, since sagemath was switched over from Python 2 to Python 3 with version 8.9 it has not yet been successfully built on armhf and i386. On these architectures the sagemath 8.8 packages are still in unstable and depend on a large number of Python 2 packages. These cruft dependencies are showing up as reverse dependencies of many Python 2 packages that should be removed. Thus it would be helpful to remove sagemath from armhf and i386. Thanks, Tobias
Bug#944891: Please update three.js to version 105 to fix 3D plotting in sagemath
Source: three.js
Version: 80+dfsg2-2
Severity: important
Hi Jose,
thanks for reporting, I hereby filed it as a bug.
Best,
Tobias
On 11/13/19 8:57 AM, jose wrote:
> Please consider upgrading three.js to a more recent version. When trying to
> use plot3d I get only axes drawn (or even a black image), either in testing
> or unstable (not tried stable).
>
> Failing code is:
>
> x, y = var('x y')
>
> plot3d(x*x+y*y, (-3,3), (-3,3))
>
> But this works
> plot3d(x*x+y*y, (-3,3), (-3,3), viewer='tachyon')
>
> In debug console I can see:
>
> THREE.WebGLRenderer 80 three.min.js:12:4970
> THREE.WebGLRenderer: ANGLE_instanced_arrays extension not supported.
> three.min.js:11:3290
> THREE.MeshPhongMaterial: 'flatShading' is not a property of this material.
> three.min.js:4:12201
>
> PS: Sorry for not reporting as bug, never filed one and learning curve seems
> steep.
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
Bug#920147: sagemath FTBFS on mipsel and mips64el
It seems like the build failures are related to timeouts of jmol. These timeouts started roughly at the time when the default Java version was changed in java-common from 10 to 11 in October 2018. There are also other reports of jmol being broken depending on the jre version, see https://ask.sagemath.org/question/47837/jmol-stuck-at-initializing-3d-display/ While jmol was already replaced by threejs as the default 3d viewer in interactive mode, it is still used in the command line mode and hence when running the tests. Maybe we should try to remove jmol completely, or fix it on mipsel and mips64el. Best, Tobias
Bug#944648: sagemath FTBFS on i386
Source: sagemath Version: 8.9-2 Severity: serious Since the switch to Python 3 in 8.9~beta9-1, sagemath fails to build from source on i386. The reason are segmentation faults in the following three tests: sage -t --long src/sage/schemes/elliptic_curves/isogeny_small_degree.py # Killed due to segmentation fault sage -t --long src/sage/schemes/elliptic_curves/ell_number_field.py # Killed due to abort sage -t --long src/sage/schemes/elliptic_curves/ell_field.py # Killed due to segmentation fault All three failures give the error message OverflowError: Python int too large to convert to C long from File "sage/rings/polynomial/polynomial_integer_dense_flint.pyx", line 284, in sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint.__init__ (build/cythonized/sage/rings/polynomial/polynomial_integer_dense_flint.cpp:6548) fmpz_poly_set_coeff_si(self.__poly, i, a) Help on finding a fix would be appreciated. Best, Tobias
Bug#944544: sagemath: prompt_toolkit 2.x support
Hi, it looks like prompt_toolkit was only added to sagemath because ipython depends on it. So it could well be that the sagemath Debian package does not need a direct dependency on it. Unfortunately sagemath does not say anywhere what are its direct dependencies so the Debian package has some unnecessary dependencies. Best, Tobias On 11/11/19 5:04 PM, Gordon Ball wrote: > Source: sagemath > Severity: normal > > sagemath depends on python3-prompt-toolkit, for which a transition has > been opened to upgrade to the 1.x series to 2.x (see #944227). > > The dependency in d/control for sagemath is unversioned, but looking at > https://git.sagemath.org/sage.git/tree/build/pkgs/prompt_toolkit/package-version.txt > it looks like it supports 1.x; unclear whether there is 2.x support, or > the dependency is transitive with the version of ipython etc used. > > (sagemath also has a residual dependency on python-prompt-toolkit, but > it looks like it's only some no-longer-built architectures) >
Bug#941557: Processed: Re: gri: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
Control: affects 941557 - src:maxima-sage Thanks for providing the solution for the problem! Best, Tobias On 10/29/19 2:24 PM, Norbert Preining wrote: > reassign 941557 src:gri > tags 941557 + patch > retitle 941557 texi file need @documentencoding > thanks > > With texinfo 6.7 finally the default encoding is UTF-8, thus gri.texi > fails to compile since it is in ISO-8859-1. If files in other encodings > are to be translated @documentencoding needs to be used - this has been > the case since ... version 6.0 or so (?). > > Please add > @documentencoding ISO-8859-1 > after the > \input texinfo > so that it reads > \input texinfo > @documentencoding ISO-8859-1 > to fix it. > > Thanks > > Norbert > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 >
Bug#941557: gri: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
Control: reassign 941557 src:texinfo 6.7.0.dfsg.2-5 Control: affects 941557 + src:gri src:maxima-sage Control: retitle 941557 texinfo: Malformed UTF-8 character in ParserNonXS.pm This is probably a bug in texinfo, since both the program giving the error (makeinfo) and the file it is complaining about (ParserNonXS.pm) are part of texinfo. The same error also causes maxima-sage to FTBFS at the moment. maxima-sage builds without changes when using texinfo from stable which is 6.5.0.dfsg.1-4, so this is a regression. Best, Tobias On Tue, 1 Oct 2019 15:49:30 -0700 Steve Langasek wrote: > Source: gri > Version: 2.12.26-1 > Severity: serious > Justification: FTBFS > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu eoan > > Hi Peter, > > The gri package appears to fail to build from source in unstable: > > [...] > cd tst_suite ; make > make[2]: Entering directory '/tmp/gri-2.12.26/doc/tst_suite' > perl ./../gri2html tst_IO.gri tst_IO.html > perl ./../gri2html tst_control.gri tst_control.html > perl ./../gri2html tst_rpn.gri tst_rpn.html > perl ./../gri2html tst_var_syn.gri tst_var_syn.html > make[2]: Leaving directory '/tmp/gri-2.12.26/doc/tst_suite' > makeinfo -I. gri.texi > utf8 "\xF3" does not map to Unicode at > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796, line 19280. > Malformed UTF-8 character: \xf3\x70\x65\x7a (unexpected non-continuation byte > 0x70, immediately after start byte 0xf3; need 4 bytes, got 1) in pattern > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > Malformed UTF-8 character (fatal) at > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364. > make[1]: *** [Makefile:975: html] Error 25 > make[1]: Leaving directory '/tmp/gri-2.12.26/doc' > make: *** [debian/rules:83: build-indep] Error 2 > dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > debuild: fatal error at line 1182: > dpkg-buildpackage -us -uc -ui -b failed > [...] > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org
Bug#942432: sagemath FTBFS on ppc64el
Hi Thierry,
thanks for the bug report. The relevant part of the log is this:
Success: 40 tests failed, up to 65 failures are tolerated
Error: critical test failures (e.g. timeout, segfault, etc.)
There is a segfault in
sage -t --long src/sage/calculus/riemann.pyx # Killed due to segmentation fault
Help on this would be appreciated. This is the output of the test:
sage -t --long src/sage/calculus/riemann.pyx
Killed due to segmentation fault
**
Tests run before process (pid=5419) failed:
sage: f(t) = e^(I*t) ## line 136 ##
sage: fprime(t) = I*e^(I*t) ## line 137 ##
sage: m = Riemann_Map([f], [fprime], 0) # long time (4 sec) ## line 138 ##
sage: m.plot_colored() + m.plot_spiderweb() # long time ## line 139 ##
Graphics object consisting of 22 graphics primitives
sage: m = Riemann_Map([f], [fprime], 0, exterior=True) # long time (4 sec) ##
line 144 ##
sage: m.plot_colored() # long time ## line 146 ##
Graphics object consisting of 1 graphics primitive
sage: f(t) = e^(I*t) ## line 151 ##
sage: fprime(t) = I*e^(I*t) ## line 152 ##
sage: hf(t) = 0.5*e^(-I*t) ## line 153 ##
sage: hfprime(t) = 0.5*-I*e^(-I*t) ## line 154 ##
sage: m = Riemann_Map([f, hf], [fprime, hfprime], 0.5 + 0.5*I) ## line 155 ##
sage: m.plot_spiderweb(withcolor = True) # long time ## line 158 ##
Graphics object consisting of 3 graphics primitives
sage: ps = polygon_spline([(-1, -1), (1, -1), (1, 1), (-1, 1)]) ## line 163 ##
sage: f = lambda t: ps.value(real(t)) ## line 164 ##
sage: fprime = lambda t: ps.derivative(real(t)) ## line 165 ##
sage: m = Riemann_Map([f], [fprime], 0.25, ncorners=4) ## line 166 ##
sage: m.plot_colored() + m.plot_spiderweb() # long time ## line 167 ##
Graphics object consisting of 22 graphics primitives
sage: x = 0.75 # long time ## line 172 ##
sage: print("error = {}".format(m.inverse_riemann_map(m.riemann_map(x)) - x))
# long time ## line 173 ##
error = (-0.00029174226355732635+0.001608746176755322j)
sage: f(t) = e^(I*t) ## line 178 ##
sage: fp(t) = I*e^(I*t) ## line 179 ##
sage: ef1(t) = .2*e^(-I*t) +.4+.4*I ## line 180 ##
sage: ef1p(t) = -I*.2*e^(-I*t) ## line 181 ##
sage: ef2(t) = .2*e^(-I*t) -.4+.4*I ## line 182 ##
sage: ef2p(t) = -I*.2*e^(-I*t) ## line 183 ##
sage: pts =
[(-.5,-.15-20/1000),(-.6,-.27-10/1000),(-.45,-.45),(0,-.65+10/1000),(.45,-.45),(.6,-.27-10/1000),(.5,-.15-10/1000),(0,-.43+10/1000)]
## line 184 ##
sage: pts.reverse() ## line 185 ##
sage: cs = complex_cubic_spline(pts) ## line 186 ##
sage: mf = lambda x:cs.value(x) ## line 187 ##
sage: mfprime = lambda x: cs.derivative(x) ## line 188 ##
sage: m = Riemann_Map([f,ef1,ef2,mf],[fp,ef1p,ef2p,mfprime],0,N = 400) # long
time ## line 189 ##
/usr/lib/python3/dist-packages/cysignals/signals.cpython-37m-powerpc64le-linux-gnu.so(+0xb84c)[0x7fff8d8bb84c]
/usr/lib/python3/dist-packages/cysignals/signals.cpython-37m-powerpc64le-linux-gnu.so(+0x13788)[0x7fff8d8c3788]
/usr/lib/python3/dist-packages/cysignals/signals.cpython-37m-powerpc64le-linux-gnu.so(+0x13ae8)[0x7fff8d8c3ae8]
linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x7fff8f3e04d8]
/usr/lib/powerpc64le-linux-gnu/libopenblas.so.0(zgemm_oncopy_POWER8+0x1dc)[0x7fff4af150ec]
/usr/lib/powerpc64le-linux-gnu/liblapack.so.3(zgesv_+0x29c)[0x7fff417b239c]
/usr/lib/python3/dist-packages/numpy/linalg/_umath_linalg.cpython-37m-powerpc64le-linux-gnu.so(+0xee18)[0x7fff4173ee18]
/usr/lib/python3/dist-packages/numpy/core/_multiarray_umath.cpython-37m-powerpc64le-linux-gnu.so(+0x24ec24)[0x7fff421fec24]
/usr/lib/python3/dist-packages/numpy/core/_multiarray_umath.cpython-37m-powerpc64le-linux-gnu.so(+0x24f374)[0x7fff421ff374]
/usr/bin/python3(_PyObject_FastCallKeywords+0x730)[0x10210790]
/usr/bin/python3[0x1012cbe4]
/usr/bin/python3(_PyEval_EvalFrameDefault+0x1a04)[0x10132544]
/usr/bin/python3(PyEval_EvalFrameEx+0x34)[0x10130484]
/<>/debian/build/usr/lib/python3/dist-packages/sage/calculus/riemann.cpython-37m-powerpc64le-linux-gnu.so(+0xb888)[0x7fff3e95b888]
/<>/debian/build/usr/lib/python3/dist-packages/sage/calculus/riemann.cpython-37m-powerpc64le-linux-gnu.so(+0xedcc)[0x7fff3e95edcc]
/<>/debian/build/usr/lib/python3/dist-packages/sage/calculus/riemann.cpython-37m-powerpc64le-linux-gnu.so(+0x6a6e4)[0x7fff3e9ba6e4]
/<>/debian/build/usr/lib/python3/dist-packages/sage/calculus/riemann.cpython-37m-powerpc64le-linux-gnu.so(+0x3e358)[0x7fff3e98e358]
/<>/debian/build/usr/lib/python3/dist-packages/sage/calculus/riemann.cpython-37m-powerpc64le-linux-gnu.so(+0x405b4)[0x7fff3e9905b4]
/usr/bin/python3[0x101a10c0]
/<>/debian/build/usr/lib/python3/dist-packages/sage/misc/lazy_import.cpython-37m-powerpc64le-linux-gnu.so(+0x16fd4)[0x7fff8df26fd4]
/usr/bin/python3(_PyObject_FastCallKeywords+0x730)[0x10210790]
/usr/bin/python3[0x1012cbe4]
/usr/bin/python3(_PyEval_EvalFrameDefault+0x1a04)[0x10132544]
/usr/bin/python3(_PyEval_EvalCodeWithName+0x2ec)[0x1012dc8c]
/usr/bin/python3(PyEv
Bug#941693: sagenb: No Python3 version of python-sagenb
Hi, thanks for the bug report. sagenb was not and as far as I know will not be ported to Python 3. It was replaced by the Jupyter notebook. "sage -notebook" leads me to a website informing about this and providing links to the Jupyter as well as the old notebook. Running notebook() in sage indeed leads to the error you described. This will hopefully be fixed eventually. Please install sagemath-jupyter if you haven't done this already. The package sagenb should be removed from Debian. Best, Tobias On 10/3/19 10:42 PM, Rann Bar-On wrote: > Source: sagenb > Version: 1.1..2+ds1-1 > Severity: important > > Dear Maintainer, > > Since Debian's sage is now Python 3 based, we need a python3-sagenb for the > notebook to work. > > Right now, since there is no such package, sage -notebook or notebook() in > Sage itself fails with 'No module named 'sagenb'. > > Thank you! > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (800, 'testing'), (750, 'unstable'), (500, 'unstable-debug'), > (500, 'testing-debug'), (500, 'stable-updates'), (500, 'proposed-updates'), > (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#939097: conway-polynomials needs to be pickled with Python 2 as long as sagemath uses Python 2
I'm almost ready to upload sagemath 8.8. If you agree I could also just revert commit f5187d87 of sagemath-database-conway-polynomialsand upload. Best, Tobias On 9/1/19 11:45 AM, Tobias Hansen wrote: > Package: src:sagemath-database-conway-polynomials > Version: 0.5-6 > Severity: important > > Hi Julien, > > I'm currently updating sagemath to version 8.8 and since version 0.5-5 > sagemath-database-conway-polynomials is pickled with Python 3 and is not > compatible with Python 2 sagemath. Could you please revert to pickling with > Python 2 until we update sagemath to Python 3? I want to start experimenting > with Python 3 for sagemath soon but first I want to upload another working > sagemath with Python 2. > > Best, > Tobias >
Bug#939097: conway-polynomials needs to be pickled with Python 2 as long as sagemath uses Python 2
Package: src:sagemath-database-conway-polynomials Version: 0.5-6 Severity: important Hi Julien, I'm currently updating sagemath to version 8.8 and since version 0.5-5 sagemath-database-conway-polynomials is pickled with Python 3 and is not compatible with Python 2 sagemath. Could you please revert to pickling with Python 2 until we update sagemath to Python 3? I want to start experimenting with Python 3 for sagemath soon but first I want to upload another working sagemath with Python 2. Best, Tobias
Bug#929848: How is the packaging of pplpy going?
On 7/19/19 2:19 AM, Julien Puydt wrote: > Hi, > > Le 18/07/2019 à 21:55, Tobias Hansen a écrit : >> On 7/18/19 3:17 PM, Julien Puydt wrote: >>> Hi, >>> >>> Le 18/07/2019 à 20:12, Tobias Hansen a écrit : >>>> I pushed it now to https://salsa.debian.org/science-team/pplpy/ >>>> >>>> Feel free to work on / upload it. >>> Excellent! >>> >>> I worked on it a little. >>> >>> But I don't understand the lines in d/rules where you put "export >>> whatever=whatever" as dependencies... does it work? >>> >>> Cheers, >>> >>> JP >> Great, thanks! That export thing is to prevent sphinx accessing the >> internet, from >> >> https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation >> > I didn't know it was possible to do exports like this, but indeed: > https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html#Target_002dspecific > > I worked on the package some more ; I think it's ready : it builds and > autopkgtest is happy... > > You might still want to have a look first. > > JP Thanks a lot! It looks good, you can add yourself to uploaders and upload if you want. There's the lintian warning about the Python 2 package, but we could just see if ftp-masters object to that. Best, Tobias
Bug#929848: How is the packaging of pplpy going?
On 7/18/19 3:17 PM, Julien Puydt wrote: > Hi, > > Le 18/07/2019 à 20:12, Tobias Hansen a écrit : >> I pushed it now to https://salsa.debian.org/science-team/pplpy/ >> >> Feel free to work on / upload it. > Excellent! > > I worked on it a little. > > But I don't understand the lines in d/rules where you put "export > whatever=whatever" as dependencies... does it work? > > Cheers, > > JP Great, thanks! That export thing is to prevent sphinx accessing the internet, from https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation Best, Tobias
Bug#929848: How is the packaging of pplpy going?
Hi Julien, I pushed it now to https://salsa.debian.org/science-team/pplpy/ Feel free to work on / upload it. Thanks! Tobias On 7/18/19 10:27 AM, Julien Puydt wrote: > Hi, > > how is the packaging of pplpy going? > > I wanted to lend a hand, but didn't find 'pplpy' on salsa. > > Cheers, > > JP
Bug#931223: sagemath: sage test fails to test sagetex example_doctest.sage generated from sagetex example.tex
Hi,
yes, to run doctests one needs to set SAGE_SRC and SAGE_PKGS. From sagemath's
README.Debian:
One can run the tests using the installed sage packages. First, get the source
code for this package (`apt-get source sagemath`), and make sure the Debian
patches are applied. Then, from the 'sage' directory in the sources:
*$ export -n SAGE_LOCAL SAGE_ROOT
*$ SAGE_SRC=$(pwd)/src SAGE_PKGS=$(pwd)/build/pkgs sage -t -p --long
--logfile=ptestlong.log --all
Hopefully we can refactor and simplify the package one day and then also
doctesting should hopefully work out of the box.
What you are trying is slightly different but it boils down to patching sage to
do doctests without having SAGE_PKGS around.
Best,
Tobias
On 6/28/19 4:25 PM, Jerome Benoit wrote:
> Source: sagemath
> Version: 8.6-6
> Severity: normal
>
> Dear Maintainer,
>
> for the sake of curiosity, I have just tried to doctest the sage script
> generated
> by SageTeX for the example.tex : the test reveals an issue with sage-runtests
> .
> The issue can be reproduce as follows (when sagetex-doc is installed):
>
> cd
> cp -p /usr/share/doc/sagetex/examples/example.tex .
> pdflatex example.tex
> sage -t example_doctest.sage
>
> The last command gives:
>
> Traceback (most recent call last):
> File "/usr/share/sagemath/bin/sage-runtests", line 162, in
> DC = DocTestController(options, args)
> File "/usr/lib/python2.7/dist-packages/sage/doctest/control.py", line
> 357, in __init__
> for pkg in list_packages('optional', local=True).values():
> File "/usr/lib/python2.7/dist-packages/sage/misc/package.py", line 228,
> in list_packages
> for p in os.listdir(SAGE_PKGS):
> OSError: [Errno 2] No such file or directory: '/usr/share/sagemath/build/pkgs'
>
> As it does not look as a sagetex issue but rather as a sagemath issue, I
> submitted this issue
> as sagemath bug.
>
> Thanks,
> Jerome
>
>
>
> -- System Information:
> Debian Release: Stretch*
> APT prefers stable
> APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
