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#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#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#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#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#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#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#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#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#955082: marked as pending in pexpect
Control: tag -1 pending Hello, Bug #955082 in pexpect reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/modules/pexpect/-/commit/4fd5b97f7a2b62562840681df4607f92a7204b9d Merge branch 'slyon/sphinx-logging-api' into 'master' Apply upstream logging API patch (Closes: #955082) See merge request python-team/modules/pexpect!2 (this message was generated automatically) -- Greetings https://bugs.debian.org/955082
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#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#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#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#949029: 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#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#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#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#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#923203: pulseaudio: fails to start without manual configuration
On 6/21/19 10:54 PM, Adam Borowski wrote: > Control: severity -1 grave > Control: tags -1 +patch > > (patch is > https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/5) > > On Fri, Jun 21, 2019 at 11:37:48AM +0200, Tobias Hansen wrote: >> I just updated by system from stretch to buster and after that there was no >> sound in GNOME because pulseaudio was not started. >> It can be easily worked around by setting "autospawn = yes" in >> ~/.config/pulse/client.conf but it's quite an annoying regression. >> >> Can this still be fixed for buster? Can we make it an RC bug? > It should have been tagged a long time ago, but I believe that's a good > idea. The bug is severe -- makes the package effectively useless for a good > part of users (those on any inits other than systemd), has a pending fix, > and the fix has went through maintainer's review with no comments since 3 > weeks ago. > > I just did some extra tests, just in case -- upgrades work for me; and > obviously the functionality itself. > > > Meow! But I am using systemd and saw this regression anyway. Let me test that patch. Best, Tobias
Bug#920147: sagemath FTBFS on mipsel and mips64el
On 1/22/19 8:59 AM, peter green wrote: > sagemath versions from 8.4-2 through to 8.6-2 have failed to build on mipsel > and mips64el. snip > This will need to be dealt with one way or the other (either by fixing the > build failures or by requesting removal of the old binaries) before sagemath > can migrate to testing. > Are you sure? I thought old binaries only prevent migration when they are in testing. sagemath is not in testing at the moment. Now migration is of course blocked by this RC bug. Best, Tobias
Bug#917428: [Debian-science-sagemath] Python 2 matplotlib package required for sagemath
On 12/30/18 2:59 AM, Sandro Tosi wrote: >> You are right, I didn't notice the new matplotlib2 package and sagemath >> failed to build due to the missing matplotlibrc in python-matplotlib-data. > this should be fixed, does sagemath build fine now? > It fixes the errors from matplotlib, thanks! Now I'm just working on gap related errors that might be fixed by installing the right combination of gap packages. Best, Tobias
Bug#917428: [Debian-science-sagemath] Python 2 matplotlib package required for sagemath
You are right, I didn't notice the new matplotlib2 package and sagemath failed to build due to the missing matplotlibrc in python-matplotlib-data. Best, Tobias On December 28, 2018 5:14:23 AM GMT+01:00, Sandro Tosi wrote: >there is a python-matplotlib binary package at 2.2.3 so i'm not sure >what is the problem you're having - check again? > >On Thu, Dec 27, 2018 at 12:08 PM Tobias Hansen >wrote: >> >> Hi Sandro, >> >> I was just about to finish an update to the sagemath package when you >uploaded matplotlib 3.0.2 to unstable. We need the Python 2 package for >sagemath (see #917428). Would you be ok with me uploading matplotlib >2.2.3 as a separate source package that provides python-matplotlib? Or >would you even want to maintain it? >> >> Best, >> >> Tobias >> >> > > >-- >Sandro "morph" Tosi >My website: http://sandrotosi.me/ >Me at Debian: http://wiki.debian.org/SandroTosi >G+: https://plus.google.com/u/0/+SandroTosi > >___ >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#917428: Python 2 matplotlib package required for sagemath
Hi Sandro, I was just about to finish an update to the sagemath package when you uploaded matplotlib 3.0.2 to unstable. We need the Python 2 package for sagemath (see #917428). Would you be ok with me uploading matplotlib 2.2.3 as a separate source package that provides python-matplotlib? Or would you even want to maintain it? Best, Tobias
Bug#917428: sagemath depends on python 2 version of matplotlib (which was removed from unstable)
Package: src:sagemath Version: 8.4-2 Severity: serious Tags: sid buster Control: block 912980 by -1 Control: block 912593 by -1 Control: block 890231 by -1 matplotlib 3.0 was recently uploaded to Debian unstable. This version requires Python 3 and hence the package python-matplotlib was removed. Sagemath still uses Python 2 and I don't think there is any chance to change that before the buster freeze. Hence I think the only way forward is to upload matplotlib 2.2.3 as a separate source package to provide the Python 2 package python-matplotlib. All other RC bugs of sagemath are fixed in git, this is the bug preventing an upload. Best, Tobias
Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
Package: grub-efi-amd64 Version: 2.02~beta3-5+deb9u1 Severity: critical After updating grub2 in Debian stable to 2.02~beta3-5+deb9u1 the UEFI boot option was removed on my Dell Latitude 5480. After rebooting I was greeted with "No bootable devices found". In the setup utility (reached by pressing F2) the UEFI boot sequence was empty. I could fix the problem by adding a new boot option, selecting the file EFI/debian/grubx64.efi. I could reproduce this by downgrading the installed grub2 packages (grub2-common, grub-common, grub-efi-amd64, grub-efi-amd64-bin) to 2.02~beta3-5, making sure the boot option is there, and updating the packages to 2.02~beta3-5+deb9u1 again. After the update the boot option is gone. Just rebooting with either of the versions does not remove the boot option. There is no indication during the update that something went wrong: Setting up grub-efi-amd64 (2.02~beta3-5+deb9u1) ... Installing for x86_64-efi platform. Installation finished. No error reported. Generating grub configuration file ... Found background image: .background_cache.png Found linux image: /boot/vmlinuz-4.9.0-8-amd64 Found initrd image: /boot/initrd.img-4.9.0-8-amd64 Found linux image: /boot/vmlinuz-4.9.0-7-amd64 Found initrd image: /boot/initrd.img-4.9.0-7-amd64 Adding boot menu entry for EFI firmware configuration done Best, Tobias
Bug#912593: sagemath has unfulfillable build-dependencies
Control: tags -1 + pending This bug is easy enough to fix, however it doesn't make sense to upload a new version at the moment due to #912980. debian/control is in .gitignore because it is generated in debian/rules from debian/control.in, mostly to avoid writing the control fields for all the documentation packages in different languages. Best, Tobias On 11/02/2018 09:59 AM, Graham Inggs wrote: > Control: tags -1 + ftbfs > > Hi Maintainers > > This causes reproducible builds of sagemath [1] to FTBFS (depwait) currently. > BTW, it seems really odd to me to have /control in /debian/.gitignore [2]. > > Regards > Graham > > [1] https://tests.reproducible-builds.org/debian/history/amd64/sagemath.html > [2] > https://salsa.debian.org/science-team/sagemath/blob/master/debian/.gitignore >
Bug#912980: sagemath is incompatible with GAP 4.9
Package: src:sagemath Version: 8.4-2 Severity: serious Tags: sid buster Control: forwarded -1 https://trac.sagemath.org/ticket/22626 Control: block -1 by 912862 gap 4.9.3 was recently uploaded to Debian unstable. sagemath is not yet compatible to this version, see upstream bug.
Bug#911084: sagemath crashes as cantor backend
Control: reassign -1 cantor-backend-sage Please provide more information. How can the bug be triggered? I'm not familiar with cantor. If someone can demonstrate that the segfault is really in sage, the bug can be reassigned to sagemath. Best, Tobias On 10/15/2018 03:34 PM, Kinky Nekoboi wrote: > Package: sagemath > Version: 8.3-3 > Severity: serious > Justification: unkown > > as above > cantor-sage-backend crashes with Segmentation fault. > > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sagemath depends on: > ii cysignals-tools 1.6.7+ds-4 > ii cython 0.28.4-1 > ii ecl 16.1.2-4+b1 > ii eclib-tools 20171002-1+b3 > ii f2c 20160102-1 > ii fflas-ffpack 2.3.2-3 > ii flintqs 1:1.0-3 > ii gap-core 4r8p8-3 > ii gfan 0.6.2-2 > ii gmp-ecm 7.0.4+ds-3 > ii ipython 5.5.0-1 > ii iso-codes4.1-1 > ii jmol 14.6.4+2016.11.05+dfsg1-3.1 > ii lcalc1.23+dfsg-7 > ii less 487-0.1+b1 > ii libatlas3-base [liblapack.so.3] 3.10.3-7+b1 > ii libblas3 [libblas.so.3] 3.8.0-1+b1 > ii libbrial-groebner3 1.2.0-2 > ii libbrial31.2.0-2 > ii libc62.27-6 > ii libcdd-tools 094h-1+b1 > ii libcliquer1 1.21-2 > ii libec3 20171002-1+b3 > ii libecm1 7.0.4+ds-3 > ii libflint-2.5.2 2.5.2-18 > ii libflint-arb21:2.14.0-4 > ii libgap-sage-4 > 4.8.8+3+20160327g69a66f0+dsx-1 > ii libgcc1 1:8.2.0-7 > ii libgd3 2.2.5-4 > ii libgivaro9 4.0.4-2 > ii libglpk404.65-2 > ii libgmp10 2:6.1.2+dfsg-3 > ii libgmpxx4ldbl2:6.1.2+dfsg-3 > ii libgsl23 2.5+dfsg-5 > ii libgslcblas0 2.5+dfsg-5 > ii libiml0 1.0.4-1+b2 > ii libjs-mathjax2.7.4+dfsg-1 > ii libjs-three 80+dfsg2-2 > ii liblapack3 [liblapack.so.3] 3.8.0-1+b1 > ii liblfunction01.23+dfsg-7 > ii liblinbox-1.5.2-01.5.2-2 > ii liblinboxsage-1.5.2-01.5.2-2 > ii liblrcalc1 1.2-2+b1 > ii libm4ri-0.0.20140914 20140914-2+b1 > ii libm4rie-0.0.2015090820150908-2 > ii libmpc3 1.1.0-1 > ii libmpfi0 1.5.3+ds-2 > ii libmpfr6 4.0.1-1 > ii libntl35 10.5.0-2 > ii libopenblas-base [liblapack.so.3]0.3.3+ds-1 > ii libpari-gmp-tls6 2.11.0-1 > ii libplanarity03.0.0.5-3 > ii libpng16-16 1.6.34-2 > ii libppl14 1:1.2-3 > ii libpynac18 0.7.22-3 > ii libratpoints-2.1.3 1:2.1.3-1+b2 > ii libreadline7 7.0-5 > ii librw0 0.8+ds-1 > ii libsingular4 1:4.1.1-p2+ds-2 > ii libstdc++6 8.2.0-7 > ii libsymmetrica2 2.0+ds-5 > ii libzn-poly-0.9 0.9-3+b2 > ii maxima-sage 5.41.0+ds-2 > ii maxima-sage-doc 5.41.0+ds-2 > ii maxima-sage-share5.41.0+ds-2 > ii nauty2.6r10+ds-1 > ii octave
Bug#905191: libecm1-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
It looks like it's just a typo in the maintscript. The path is /usr/share/doc/libecm1-dev-common but the mainscript file is: symlink_to_dir /usr/share/doc/libecm1-dev /usr/share/doc/libecm1-common-dev 7.0.4+ds-2~ Best, Tobias On Fri, 5 Oct 2018 09:49:34 +0400 Jerome BENOIT wrote: > Hi Andreas, > > I thought that I fixed this issue. > > The difficulty here is that I am blind here: > how can I reproduce the issue on my own ? > > Thanks, > 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#910808: sagemath: Sage crashes on startup, seems to be compiled against wrong libsingular version
It's good to keep this in mind for the future, but what do you think needs to be done now? The packages are already in testing and work together without problems. By the way, in this case testing users were not affected. The only reverse dependencies of singular are pynac and sagemath. pynac and singular migrated to testing together and sagemath was not in testing. Best, Tobias On 10/12/2018 10:07 PM, Adrian Bunk wrote: > Control: reopen -1 > Control: reassign -1 libsingular4 1:4.1.1-p2+ds-2 > Control: retitle -1 libsingular4 must change packagename when sonames change > Control: affects -1 sagemath > > On Thu, Oct 11, 2018 at 05:55:06PM +0200, Tobias Hansen wrote: >> It's not a bug in sagemath. The problem is that the singular library package >> was not renamed even though the library name changed. >> However this is only a problem for people who somehow do partial updates. > People who use testing are also victims of this kind of bugs. > > If the soname of included libraries changes with every minor release, > then the package name of the package also has to change. > > Reopening and reassigning to libsingular4. > >> Best, >> Tobias > cu > Adrian >
Bug#910808: sagemath: Sage crashes on startup, seems to be compiled against wrong libsingular version
It's not a bug in sagemath. The problem is that the singular library package was not renamed even though the library name changed. However this is only a problem for people who somehow do partial updates. Best, Tobias On 10/11/2018 05:44 PM, Rann Bar-On wrote: > That does the trick. Should it be a dependency, then? >
Bug#910808: sagemath: Sage crashes on startup, seems to be compiled against wrong libsingular version
Hi, please update libpynac18 to 0.7.22-3. Best, Tobias On 10/11/2018 05:19 PM, Rann Bar-On wrote: > Package: sagemath > Version: 8.3-3 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > The relevant output from the crash report: > > ImportError: libsingular-factory-4.1.0.so: cannot open shared object file: No > such file or directory > > I believe, given the dependencies of sagemath 8.3, that it should be compiled > against libsingular 4.1.1, not 4.1.0 > > Thanks! > > > -- System Information: > Debian Release: buster/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 4.18.0-1-amd64 (SMP w/4 CPU cores) > 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 > > Versions of packages sagemath depends on: > ii cysignals-tools 1.6.7+ds-4 > ii cython 0.28.4-1 > ii ecl 16.1.2-4+b1 > ii eclib-tools 20171002-1+b3 > ii f2c 20160102-1 > ii fflas-ffpack 2.3.2-3 > ii flintqs 1:1.0-3 > ii gap-core 4r8p8-3 > ii gfan 0.6.2-2 > ii gmp-ecm 7.0.4+ds-3 > ii ipython 5.5.0-1 > ii iso-codes4.1-1 > ii jmol 14.6.4+2016.11.05+dfsg1-3.1 > ii lcalc1.23+dfsg-7 > ii less 487-0.1+b1 > ii libatlas3-base [liblapack.so.3] 3.10.3-7+b1 > ii libblas3 [libblas.so.3] 3.8.0-1+b1 > ii libbrial-groebner3 1.2.0-2 > ii libbrial31.2.0-2 > ii libc62.27-6 > ii libcdd-tools 094h-1+b1 > ii libcliquer1 1.21-2 > ii libec3 20171002-1+b3 > ii libecm1 7.0.4+ds-3 > ii libflint-2.5.2 2.5.2-18 > ii libflint-arb21:2.14.0-4 > ii libgap-sage-4 > 4.8.8+3+20160327g69a66f0+dsx-1 > ii libgcc1 1:8.2.0-7 > ii libgd3 2.2.5-4 > ii libgivaro9 4.0.4-2 > ii libglpk404.65-2 > ii libgmp10 2:6.1.2+dfsg-3 > ii libgmpxx4ldbl2:6.1.2+dfsg-3 > ii libgsl23 2.5+dfsg-5 > ii libgslcblas0 2.5+dfsg-5 > ii libiml0 1.0.4-1+b2 > ii libjs-mathjax2.7.4+dfsg-1 > ii libjs-three 80+dfsg2-2 > ii liblapack3 [liblapack.so.3] 3.8.0-1+b1 > ii liblfunction01.23+dfsg-7 > ii liblinbox-1.5.2-01.5.2-2 > ii liblinboxsage-1.5.2-01.5.2-2 > ii liblrcalc1 1.2-2+b1 > ii libm4ri-0.0.20140914 20140914-2+b1 > ii libm4rie-0.0.2015090820150908-2 > ii libmpc3 1.1.0-1 > ii libmpfi0 1.5.3+ds-2 > ii libmpfr6 4.0.1-1 > ii libntl35 10.5.0-2 > ii libpari-gmp-tls6 2.11.0-1 > ii libplanarity03.0.0.5-3 > ii libpng16-16 1.6.34-2 > ii libppl14 1:1.2-3 > ii libpynac18 0.7.22-2 > ii libratpoints-2.1.3 1:2.1.3-1+b2 > ii libreadline7 7.0-5 > ii librw0 0.8+ds-1 > ii libsingular4 1:4.1.1-p2+ds-2 > ii libstdc++6 8.2.0-7 > ii libsymmetrica2 2.0+ds-5 > ii li
Bug#879905: glee: source for GLee.c and GLee.h is missing
On Mon, 6 Nov 2017 02:08:44 +0100 Steve Cotton wrote: > On Fri, Oct 27, 2017 at 07:55:52AM +0200, Steve Cotton wrote: > > On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: > > > These files are clearly not source code. But luckily it should > > > be possible to regenerate them from the git repo I mentioned: > > > > > > > [..] https://github.com/kallisti5/glee > > > > It seems that repo is also not the complete source, the build > > steps in CMakeLists.txt download specs for the GL extensions from > > http://www.opengl.org/registry/ > > It doesn't manage to download the specifications any more, which is > probably because the website has changed since 2011. OTOH, anything > that works with Debian's 2009 version of GLee can only be using > extensions that existed in 2009. > > AFAICS, what GLeeGen creates is a mix of: > > 1. An easy wrapper for checking if an extension is supported > 2. The DFSG-free files which are now packaged in khronos-api > 3. The specifications under Khronos' speccopyright (not DFSG-free) > > The speccopyright means that we can't make a DFSG version of GLee, but > it also seems that it might be easier to just fix the rdeps to not use > GLee at all. The wrapper for checking if extensions are supported > could be ported to use the khronos-api, if it's needed at all. > > Looking at the packages that use GLee: > > Fife: only a few extensions, all of them now in khronos-api. Would > need the wrapper function. > > FS-UAE: build-depends on glee-dev, but the changelog includes "use > GLEW instead of GLee", none of the binaries depend on libglee, and the > two #includes in the source are commented out. Bug #880944 logged. > > Out Of Order: transitive dependency via Sludge > > Pink Pony: build-depends on glee-dev, but doesn't #include GLee.h > anywhere. Builds and runs fine without it (bug #880941 logged for > dropping the dependency). > > Sludge: if a compile-time check finds OpenGL ES 2.0, the code assumes > that all of the extensions that it wants are already present, and > doesn't use GLee's wrapper. > > Unknown Horizons: transitive dependency via Fife > > Steve > > I ported sludge to use glew instead of glee, and it was the last rdep. glee can be removed now. Best, Tobias
Bug#902872: sagemath: sage fails to start with 'undefined symbol acb_calc_integrate error
Hi, please upgrade your packages and try again. Your version of libfint-arb2 should be 1:2.12.0-3. Best, Tobias Hansen On 07/02/2018 06:26 PM, Rann Bar-On wrote: > Package: sagemath > Version: 8.2-5 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > see sage crash log below. > > -- System Information: > Debian Release: buster/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 4.16.0-2-amd64 (SMP w/4 CPU cores) > 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) > > Versions of packages sagemath depends on: > ii cysignals-tools 1.6.7+ds-1 > ii cython 0.28.2-4 > ii ecl 16.1.2-4+b1 > ii eclib-tools 20171002-1+b2 > ii f2c 20160102-1 > ii fflas-ffpack 2.3.2-2 > ii flintqs 1:1.0-1+b1 > ii gap-core 4r8p8-3 > ii gfan 0.5+dfsg-6 > ii gmp-ecm 7.0.4+ds-2 > ii ipython 5.5.0-1 > ii iso-codes3.79-1 > ii jmol 14.6.4+2016.11.05+dfsg1-3.1 > ii lcalc1.23+dfsg-6+b1 > ii less 487-0.1+b1 > ii libatlas3-base [liblapack.so.3] 3.10.3-7 > ii libblas3 [libblas.so.3] 3.8.0-1 > ii libbrial-groebner3 1.2.0-2 > ii libbrial31.2.0-2 > ii libc62.27-3 > ii libcdd-tools 094h-1+b1 > ii libcliquer1 1.21-2 > ii libec3 20171002-1+b2 > ii libecm1 7.0.4+ds-2 > ii libflint-2.5.2 2.5.2-18 > ii libflint-arb22.11.1-2+b1 > ii libgap-sage-4 > 4.8.8+3+20160327g69a66f0+dsx-1 > ii libgcc1 1:8.1.0-9 > ii libgd3 2.2.5-4 > ii libgivaro9 4.0.4-2 > ii libglpk404.65-2 > ii libgmp10 2:6.1.2+dfsg-3 > ii libgmpxx4ldbl2:6.1.2+dfsg-3 > ii libgsl23 2.5+dfsg-4 > ii libgslcblas0 2.5+dfsg-4 > ii libiml0 1.0.4-1+b2 > ii libjs-mathjax2.7.4+dfsg-1 > ii libjs-three 80+dfsg2-2 > ii liblapack3 [liblapack.so.3] 3.8.0-1 > ii liblfunction01.23+dfsg-6+b1 > ii liblinbox-1.5.2-01.5.2-1 > ii liblinboxsage-1.5.2-01.5.2-1 > ii liblrcalc1 1.2-2+b1 > ii libm4ri-0.0.20140914 20140914-2+b1 > ii libm4rie-0.0.2015090820150908-1 > ii libmpc3 1.1.0-1 > ii libmpfi0 1.5.3+ds-2 > ii libmpfr6 4.0.1-1 > ii libntl35 10.5.0-2 > ii libpari-gmp-tls5 2.9.5-1 > ii libplanarity03.0.0.5-1+b1 > ii libpng16-16 1.6.34-1 > ii libppl14 1:1.2-3 > ii libpynac17 0.7.19-2 > ii libratpoints-2.1.3 1:2.1.3-1+b2 > ii libreadline7 7.0-5 > ii librw0 0.8+ds-1 > ii libsingular4 1:4.1.0-p3+ds-2+b3 > ii libstdc+
Bug#896218: python-brial: brial fails to import
Control: severity -1 normal
Hi Helmut,
thanks for the bug report. We are aware that brial has a circular dependency
with sagemath. src:sagemath build-depends on src:brial and python-brial should
depend on sagemath. We didn't add this dependency in order not to manifest the
circular dependency in the package relationships. We brought this up with
upstream once (can't find it now) but they didn't care. For that reason I don't
know if there is anything to be done at the moment.
Best,
Tobias
On 04/20/2018 10:00 PM, Helmut Grohne wrote:
> Package: python-brial
> Version: 1.2.0-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
>
> After installing python-brial importing the module brial
> into a python interpreter fails with the following error:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/dist-packages/brial/__init__.py", line 31, in
>
> from .PyPolyBoRi import *
> File "/usr/lib/python2.7/dist-packages/brial/PyPolyBoRi.py", line 66, in
>
> from sage import all
> ImportError: No module named sage
>
> The vast majority of import failures is attributed to missing dependencies.
> Often times that manifests as an ImportError or ModuleNotFoundError.
> Typically, dependencies should be inserted by dh-python via ${python:Depends}
> or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
> install_requires in setup.py. Sometimes a missing dependency of a dependency
> is the cause, in such cases this bug should be reassigned.
>
> Helmut
>
Bug#888912: sagemath test failures with mpfr 4.0.0 and several architectures
Control: block -1 by 888459 888911 Not a surprise as long as some dependencies are built against libmpfr4. On 01/31/2018 06:01 AM, Matthias Klose wrote: > Package: src:sagemath > Version: 8.2-1 > Severity: serious > Tags: sid buster > > see https://buildd.debian.org/status/package.php?p=sagemath&suite=unstable > > test failures on every architecture. >
Bug#888606: [Debian-science-sagemath] Fwd: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target
Hi, yes, I think you can update cysignals in unstable. I applied upstream patches for new mpfr and matplotlib versions to sagemath and built it with both versions of cysignals yesterday and got the same problems: sage -t --long src/sage/rings/number_field/number_field.py # Bad exit: 1 sage -t --long src/sage/rings/polynomial/plural.pyx # Killed due to segmentation fault sage -t --long src/sage/structure/factorization_integer.py # Killed due to kill signal sage -t --long src/sage/structure/sage_object.pyx # Killed due to abort I have had the failure with number_field.py on my computer for a while, but it doesn't happen on buildds. The others are new, but I don't even know if the libmpfr6 transition is finished... Best, Tobias On 01/28/2018 06:11 AM, Jerome BENOIT wrote: > Hello, > > this issue was fixed in 1.6.6+ds-2 which is current in experimental: > can we migrate cysingals 1.6.6+ds-2 to unstable ? > > Thanks, > Jerome > > > Forwarded Message > Subject: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build > target > Resent-Date: Sat, 27 Jan 2018 17:51:02 + > Resent-From: Niels Thykier > Resent-To: debian-bugs-d...@lists.debian.org > Resent-CC: Jerome Benoit > Date: Sat, 27 Jan 2018 18:44:34 +0100 > From: Niels Thykier > Reply-To: Niels Thykier , 888...@bugs.debian.org > To: Debian Bug Tracking System > > Source: cysignals > Version: 1.6.5+ds-2 > Severity: serious > Tags: patch > > Hi, > > The cysignals package FTBFS with debhelper/11.1 as it has an empty > build target. This is caused by debhelper had a bug in its handling > of "explicitly defined rules targets" that has now been fixed. > > Previously, this happened to work because dpkg-buildpackage would > invoke "debian/rules build" (which would be a no-op) followed by > "fakeroot debian/rules binary". During the binary target, dh's > suboptimal handling would run the build commands. > > > The solution is trivial but less pretty; explicitly define "build" > with the same content as the "%:" target (or rename the "build" folder > and drop the ".PHONY" target). I have attached a patch for this. > > > More details can be found in: > * #886901 comment #35 > * #887688 comment #37 > * #880840 > > Apologies for the inconvenience. > > Thanks, > ~Niels > > > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
Bug#888560: mpfi dependencies inconsistency
On 01/27/2018 01:41 PM, Jerome BENOIT wrote:
> Hello Vincent, thanks for your bugreport.
>
>
>
> On 27/01/18 06:31, Vincent Lefevre wrote:
>> Package: src:mpfi
>> Version: 1.5.3+ds-1
>> Severity: serious
>> Justification: Policy 7.2
>>
>> The current libmpfi-dev version is 1.5.3+ds-1+b1, which has:
>>
>> Depends: libmpfi0 (= 1.5.3+ds-1+b1), libmpfi-dev-common (= 1.5.3+ds-1),
>> libmpfr-dev, libgmp-dev
>>
>> but libmpfi-dev-common 1.5.3+ds-1 has:
>>
>> Recommends: libmpfi-dev (= 1.5.3+ds-1)
>>
>> This is inconsistent.
> This true.
>
> Do you have any idea from where comes the +b1 ?
>
> Thanks,
> Jerome
Hi,
the +b1 was appended to the binary version for the rebuild against libmpfr6.
This is a matter of using (=${binary:Version}) vs. (=${source:Version}) in
debian/control.
Best,
Tobias
Bug#872259: sagemath: FTBFS with Sphinx 1.6: TypeError: frompickle() takes exactly 3 arguments (4 given)
Control: tags -1 +pending Fixed in git, but we need for a libgap-sage update before the next upload.
Bug#873791: python2.7: fpectl extension removal broke the ABI for C extensions
Control: affects -1 + python-scipy python-fpylll Cython autogenerated code uses the fpectl macros, so removing fpectl breaks the ABI of probably all Cython modules, see [1] for a more detailed explanation. The last sagemath build [2] shows that at least also scipy and fpylll are affected, with errors such as ImportError: /usr/lib/python2.7/dist-packages/scipy/linalg/_solve_toeplitz.arm-linux-gnueabihf.so: undefined symbol: PyFPE_jbuf ImportError: /usr/lib/python2.7/dist-packages/fpylll/fplll/integer_matrix.arm-linux-gnueabihf.so: undefined symbol: PyFPE_jbuf ImportError: /usr/lib/python2.7/lib-dynload/_tkinter.so: undefined symbol: PyFPE_jbuf, please install the python-tk package Best, Tobias [1] https://github.com/numpy/numpy/issues/8415#issuecomment-269103493 [2] https://buildd.debian.org/status/fetch.php?pkg=sagemath&arch=armhf&ver=8.0-5&stamp=1504503431&raw=1
Bug#870688: Sage 8.0 status (was Re: [Debian-science-sagemath] Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)
On 07/28/2017 03:06 PM, Jerome BENOIT wrote: > > On 28/07/17 17:53, Tobias Hansen wrote: >> On 07/28/2017 02:38 PM, Jerome BENOIT wrote: >>> On 28/07/17 17:28, Tobias Hansen wrote: >>>> On 07/28/2017 02:24 PM, Jerome BENOIT wrote: >>>>> On 24/07/17 19:28, Jeroen Demeyer wrote: >>>>>> On 2017-07-24 17:17, Jerome BENOIT wrote: >>>>>>> I think that the trouble comes from cysignals. >>>>>> Do you have logs or anything that you want me to have a look at? >>>>> At the time of writing, the cysignals package is in the tube (unstable): >>>>> the doctest issue was fixed, it was merely a packaging mistake. >>>>> >>>>> Enjoy, >>>>> Jerome >>>> Hi, >>>> >>>> won't that break sagemath 7.6? At least it declares that it does. ;P >>> Oops, I was no aware of that. >>> Sorry for the mistake, Jerome >> Nevermind. We should all get used to uploading stuff for the next Sage >> version to experimental by default (unless we know unstable is ok). >> >> Now we can either live with the fact that sagemath will be uninstallable >> in unstable until we upload 8.0 or we need to check if sagemath 7.6 >> works with the newer cysignals and then remove the "Breaks" from >> cysignals. I'd say let's first wait and see how our sage 8.0 package >> progresses. cypari2 is still in NEW. >> >> At least now we will see if the "Breaks" really prevents cysignals from >> migrating to testing. (So please don't remove it unless we know that >> sage 7.6 works with this cysignals version.) > Ok, I guess you meant that we let it as it. > > Meanwhile, I tried to reproduce the fpylll issue on my box: > 1] with cysignals 1.3.2+ds-1 (stable/testing), it could be built ; > 2] with cysinagls 1.6.4+ds- and 1.6.5+ds-s, it cannot be built. > > In short, the issue remains but we know now it unlikely caused by cysignals. > > I may work on it later. Any hint is welcome, meanwhile. > > Cheers, > Jerome Hi, good work on finding the fpylll issue! Now the main holdup for sage 8.0 is still cypari2 being stuck in NEW. I wrote on June 21 to ftpmas...@debian.org and August 2 directly to the ftpmaster who helped us get sagemath through NEW in time for stretch. Let's see if it helps. I'm also not totally sure if the sagemath packages can be built at the moment. When I build in a schroot with sage deps installed with DEB_BUILD_OPTIONS=parallel=5 fakeroot debian/rules binary after the build is almost completed, including running the tests, it later tries again to run the test suite and fails (I attached the end of the console output). I wanted to try if this also happens with sbuild once the fpylll problem is fixed. However I will be on vacation the next three weeks. The accidental upload of cysignals 1.6.5 to unstable is now a RC bug (#870688). Not sure if we should fix it by downgrading cysignals, patching sage 7.6 or just let the bug sit until we upload sage 8.0. At least the "Breaks: sagemath (<< 8.0~)" does indeed prevent cysignals from migrating to testing, which is good. Best, Tobias $DEB_BUILD_OPTIONS=parallel=5 fakeroot debian/rules binary ... I: dh_python2 fs:322: renaming matroid.so to matroid.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming set_system.so to set_system.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming union_matroid.so to union_matroid.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming unpickling.so to unpickling.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming probability_distribution.so to probability_distribution.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming channels.so to channels.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming algebra_elements.so to algebra_elements.x86_64-linux-gnu.so I: dh_python2 fs:322: renaming paths.so to paths.x86_64-linux-gnu.so dh_numpy --package sagemath # stop lintian complaining at us make[2]: Leaving directory '/home/thansen/src/sage/sagemath/sagemath' dh_python2 -Nsagemath dh_lintian dh_perl dh_link dh_strip_nondeterminism debian/rules override_dh_compress make[2]: Entering directory '/home/thansen/src/sage/sagemath/sagemath' dh_compress -X.pdf -X.pickle -X.doctree make[2]: Leaving directory '/home/thansen/src/sage/sagemath/sagemath' dh_fixperms dh_missing make[1]: Leaving directory '/home/thansen/src/sage/sagemath/sagemath' dh_testdir dh_update_autotools_config dh_autoreconf dh_auto_configure debian/rules override_dh_auto_build-arch make[1]: Entering directory '/home/thansen/src/sage/sagemath/sagemath' dh override_dh_auto_build-arch --with=python2,sphinxdoc make[1]: Leaving directory '/home/thansen/
Bug#846268: cython: Upstream resolution
Hi Yaroslav, looks like upstream included the fix in cython 0.25.2, so if you don't wait too long this bug can still be fixed by just uploading the new version. Best, Tobias On Fri, 2 Dec 2016 08:14:24 -0500 Antonio Russo wrote: > tags -1 + patch > > Upstream has posted a patch for this issue. See the github thread: > > https://github.com/cython/cython/issues/1538#issuecomment-263995994 > >
Bug#848131: [Debian-science-sagemath] libmpich.so.12: cannot open shared object file: No such file or directory
And also #831442, which has a workaround that can be applied to tachyon.
Best,
Tobias
On 12/15/2016 05:03 PM, Tobias Hansen wrote:
> Hi,
>
> yes, this looks like #842881.
>
> Note by the way that libtachyon-mpich-0 already depends on libmpich12 on
> hurd-i386, m68k, mips, mipsel, ppc64 and sh4.
>
> Best,
> Tobias
>
> On 12/15/2016 04:56 PM, Jerome BENOIT wrote:
>> Hello,
>>
>> I can reproduce the issue in schroot Sid environment on an amd64 box.
>> The Depends fields for the libraries is
>>
>> ${shlibs:Depends}, ${misc:Depends}
>>
>> and it works fine except for mpich. Before to add it by hand, I want
>> to understand why dpkg-shlibdep does not make properly its job.
>>
>> $ dpkg-shlibdeps
>> debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0
>>
>> gives something interesting:
>>
>> dpkg-shlibdeps: warning: /usr/lib/libmpich.so.12 has an unexpected SONAME
>> (libmpi.so.20)
>> dpkg-shlibdeps: error: no dependency information found for
>> /usr/lib/libmpich.so.12 (used by
>> debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0)
>>
>> And, more interestingly,
>>
>> ls -l /usr/lib/libmpich.so.12
>>
>> gives
>>
>> /usr/lib/libmpich.so.12 -> libmpi.so
>>
>> libmpi.so coming from libopenmpi-dev while
>>
>>
>> Installing only libmpich-dev on a fresh schroot gives similar output:
>> it looks as a mpich building error.
>>
>>
>>
>> Thanks,
>> Jerome
>>
>>
>> ___
>> Debian-science-sagemath mailing list
>> debian-science-sagem...@lists.alioth.debian.org
>> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
>>
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
>
Bug#848131: [Debian-science-sagemath] libmpich.so.12: cannot open shared object file: No such file or directory
Hi,
yes, this looks like #842881.
Note by the way that libtachyon-mpich-0 already depends on libmpich12 on
hurd-i386, m68k, mips, mipsel, ppc64 and sh4.
Best,
Tobias
On 12/15/2016 04:56 PM, Jerome BENOIT wrote:
> Hello,
>
> I can reproduce the issue in schroot Sid environment on an amd64 box.
> The Depends fields for the libraries is
>
> ${shlibs:Depends}, ${misc:Depends}
>
> and it works fine except for mpich. Before to add it by hand, I want
> to understand why dpkg-shlibdep does not make properly its job.
>
> $ dpkg-shlibdeps
> debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0
>
> gives something interesting:
>
> dpkg-shlibdeps: warning: /usr/lib/libmpich.so.12 has an unexpected SONAME
> (libmpi.so.20)
> dpkg-shlibdeps: error: no dependency information found for
> /usr/lib/libmpich.so.12 (used by
> debian/libtachyon-mpich-0/usr/lib/x86_64-linux-gnu/libtachyon-mpich-openmp.so.0)
>
> And, more interestingly,
>
> ls -l /usr/lib/libmpich.so.12
>
> gives
>
> /usr/lib/libmpich.so.12 -> libmpi.so
>
> libmpi.so coming from libopenmpi-dev while
>
>
> Installing only libmpich-dev on a fresh schroot gives similar output:
> it looks as a mpich building error.
>
>
>
> Thanks,
> Jerome
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
>
Bug#840458: [Debian-science-sagemath] linbox: FTBFS on i386: illegal instruction in test-{cra, charpoly}
On 11/29/2016 06:01 PM, Tobias Hansen wrote: > On 11/29/2016 03:53 PM, Doug Torrance wrote: >> Control: reassign -1 src:givaro >> >> On 11/29/2016 09:58 AM, Tobias Hansen wrote: >>> I think I figured out at least the test failures with "Illegal >>> instruction" on i386. The problem is that givaro is built using cpu >>> extensions that are not allowed. >>> >>> Jerome figured out in [1] that the problem happens when givaro code is >>> called. And sure enough: >>> >>> objdump -S /usr/lib/i386-linux-gnu/libgivaro.so.9.0.0 | grep >>> '\b\(ymm\|zmm\|vfm\)' >>> 15411:c4 e3 79 6b 8b a4 29 vfmaddsd >>> %xmm2,-0x1d65c(%ebx),%xmm0,%xmm1 >>> 154d1:c4 e3 69 6b 8b ac 29 vfmaddsd >>> %xmm0,-0x1d654(%ebx),%xmm2,%xmm1 >>> >>> And in the i386 build logs for givaro there are these flags: >>> -mmmx -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mavx >>> -mfma4 -mfpmath=sse >>> >>> Do you have time in the next days to disable these flags? Otherwise I >>> can do it. (I'm not sure if some of these flags (mmx, sse ?) are allowed >>> on i386 and didn't find that info. Ximin, do you know this?) >> >> Sure, I can take a look. I think it should be a simple --disable-simd >> in d/rules (we did the same in fflas-ffpack). >> >> Doug > > Thanks! I tried building it but now there seems to be an issue similar > to [1]: > > FAIL: test-ringarith > > > 997167681959697!=997167682008849 failed (at line 123) > x y failed ! > MEDmax failed ! > FAIL test-ringarith (exit status: 255) > > And it even fails when setting the flag -ffp-contract=off . > Note that now the failure seems to be related to ModularExtended > instead of ModularExtended (MEDmax instead of MEFmax in the error > message). > > Best, > Tobias > > [1] https://github.com/linbox-team/givaro/issues/25 Ok, a workaround is to set -ffloat-store (like the Fedora package). I pushed this change to the git repo. Can I upload this? Best, Tobias
Bug#840458: linbox: FTBFS on i386: illegal instruction in test-{cra,charpoly}
On 11/29/2016 03:53 PM, Doug Torrance wrote: > Control: reassign -1 src:givaro > > On 11/29/2016 09:58 AM, Tobias Hansen wrote: >> I think I figured out at least the test failures with "Illegal >> instruction" on i386. The problem is that givaro is built using cpu >> extensions that are not allowed. >> >> Jerome figured out in [1] that the problem happens when givaro code is >> called. And sure enough: >> >> objdump -S /usr/lib/i386-linux-gnu/libgivaro.so.9.0.0 | grep >> '\b\(ymm\|zmm\|vfm\)' >> 15411:c4 e3 79 6b 8b a4 29 vfmaddsd >> %xmm2,-0x1d65c(%ebx),%xmm0,%xmm1 >> 154d1:c4 e3 69 6b 8b ac 29 vfmaddsd >> %xmm0,-0x1d654(%ebx),%xmm2,%xmm1 >> >> And in the i386 build logs for givaro there are these flags: >> -mmmx -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mavx >> -mfma4 -mfpmath=sse >> >> Do you have time in the next days to disable these flags? Otherwise I >> can do it. (I'm not sure if some of these flags (mmx, sse ?) are allowed >> on i386 and didn't find that info. Ximin, do you know this?) > > Sure, I can take a look. I think it should be a simple --disable-simd > in d/rules (we did the same in fflas-ffpack). > > Doug Thanks! I tried building it but now there seems to be an issue similar to [1]: FAIL: test-ringarith 997167681959697!=997167682008849 failed (at line 123) x y failed ! MEDmax failed ! FAIL test-ringarith (exit status: 255) And it even fails when setting the flag -ffp-contract=off . Note that now the failure seems to be related to ModularExtended instead of ModularExtended (MEDmax instead of MEFmax in the error message). Best, Tobias [1] https://github.com/linbox-team/givaro/issues/25
Bug#840458: linbox: FTBFS on i386: illegal instruction in test-{cra,charpoly}
Hi Doug, I think I figured out at least the test failures with "Illegal instruction" on i386. The problem is that givaro is built using cpu extensions that are not allowed. Jerome figured out in [1] that the problem happens when givaro code is called. And sure enough: objdump -S /usr/lib/i386-linux-gnu/libgivaro.so.9.0.0 | grep '\b\(ymm\|zmm\|vfm\)' 15411: c4 e3 79 6b 8b a4 29vfmaddsd %xmm2,-0x1d65c(%ebx),%xmm0,%xmm1 154d1: c4 e3 69 6b 8b ac 29vfmaddsd %xmm0,-0x1d654(%ebx),%xmm2,%xmm1 And in the i386 build logs for givaro there are these flags: -mmmx -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mavx -mfma4 -mfpmath=sse Do you have time in the next days to disable these flags? Otherwise I can do it. (I'm not sure if some of these flags (mmx, sse ?) are allowed on i386 and didn't find that info. Ximin, do you know this?) Best, Tobias [1] https://github.com/linbox-team/linbox/issues/44 On Tue, 11 Oct 2016 14:02:24 -0400 "Aaron M. Ucko" wrote: > Source: linbox > Version: 1.4.2-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > The i386 build of linbox failed: > > ../build-aux/test-driver: line 107: 16085 Illegal instruction "$@" > > $log_file 2>&1 > FAIL: test-cra > [...] > ../build-aux/test-driver: line 107: 16135 Illegal instruction "$@" > > $log_file 2>&1 > FAIL: test-charpoly > > Could you please take a look? > > Thanks! > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu > >
Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done
On Thu, 3 Nov 2016 20:25:23 +0100 Julian Taylor wrote: > On 03.11.2016 20:17, Sandro Tosi wrote: > >> Looks like your last upload fixed the build on most architectures. However > >> the > >> package still failed to build on arm64. > >> > >> https://buildd.debian.org/status/package.php?p=pyzmq > > > > Hey Julian, do you have time to look at the failures in the > > https://buildd.debian.org/status/package.php?p=pyzmq ? it looks like > > upstream released 16.0.0 so it might worth a shot packaging it to see > > if that solves them. thanks!! > > > > I have packaged it though the tests are also unreliable on x86, still > needs to be looked at. > Could it be that zeromq3 4.2.0 (which is now in unstable) helps? It would be nice if this could be fixed before the soft freeze on January 5. We are trying to get sagemath (currently not uploaded yet) to migrate to testing before that date and it could become a problem to have different versions of pyzmq (and zeromq3) in unstable and testing. Best, Tobias
Bug#845696: cython: FTBFS on all 32 bit architectures
Control: tags -1 + patch
Here is a patch that contains the two upstream commits that fix the
issue. I tested it on i386. Yaroslav, do you mind if I upload the fix or
do you want?
Best,
Tobias
>From afeb193f97a5f7b85f7128f252b6071127e4031a Mon Sep 17 00:00:00 2001
From: Stefan Behnel
Date: Sun, 27 Nov 2016 12:03:06 +0100
Subject: [PATCH] Try to fix #1530: left-shift operations by more than 31 bits
wrap around on 32bit systems
---
Cython/Utility/Optimize.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Cython/Utility/Optimize.c b/Cython/Utility/Optimize.c
index 9de085b..4fed9d9 100644
--- a/Cython/Utility/Optimize.c
+++ b/Cython/Utility/Optimize.c
@@ -596,7 +596,7 @@ static PyObject* __Pyx_PyInt_{{op}}{{order}}(PyObject *op1, PyObject *op2, CYTHO
}
return PyInt_FromLong(x);
{{elif op == 'Lshift'}}
-if (likely(a == (a << b) >> b)) {
+if (likely(b < sizeof(long)*8 && a == (a << b) >> b) || !a) {
return PyInt_FromLong(a {{c_op}} b);
}
{{else}}
@@ -685,12 +685,12 @@ static PyObject* __Pyx_PyInt_{{op}}{{order}}(PyObject *op1, PyObject *op2, CYTHO
x = a {{c_op}} b;
{{if op == 'Lshift'}}
#ifdef HAVE_LONG_LONG
-if (unlikely(a != x >> b)) {
+if (unlikely(!(b < sizeof(long)*8 && a == x >> b)) && a) {
ll{{ival}} = {{ival}};
goto long_long;
}
#else
-if (likely(a == x >> b)) /* execute return statement below */
+if (likely(b < sizeof(long)*8 && a == x >> b) || !a) /* execute return statement below */
#endif
{{endif}}
{{endif}}
>From ea1939d4e88c598dd9685ca5372d6da73e0b44b0 Mon Sep 17 00:00:00 2001
From: Robert Bradshaw
Date: Mon, 21 Nov 2016 22:35:40 -0800
Subject: [PATCH] Fix some trailing Ls in doctsts.
---
tests/run/pyintop.pyx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/run/pyintop.pyx b/tests/run/pyintop.pyx
index b9fba34..8ca77ae 100644
--- a/tests/run/pyintop.pyx
+++ b/tests/run/pyintop.pyx
@@ -159,16 +159,16 @@ def lshift_int(obj):
>>> bigints(lshift_int(-32))
(-256, -68719476736, -295147905179352825856, -340282366920938463463374607431768211456)
->>> (2**28) << 3
+>>> bigint((2**28) << 3)
2147483648
>>> bigints(lshift_int(2**28))
(2147483648, 576460752303423488, 2475880078570760549798248448, 2854495385411919762116571938898990272765493248)
->>> (-2**28) << 3
+>>> bigint((-2**28) << 3)
-2147483648
>>> bigints(lshift_int(-2**28))
(-2147483648, -576460752303423488, -2475880078570760549798248448, -2854495385411919762116571938898990272765493248)
->>> (2**30) << 3
+>>> bigint((2**30) << 3)
8589934592
>>> bigints(lshift_int(2**30))
(8589934592, 2305843009213693952, 9903520314283042199192993792, 11417981541647679048466287755595961091061972992)
Bug#845696: FTBFS on all 32 bit architectures
Source: cython Severity: serious Version: 0.25.2~b0-1 Control: forwarded -1 https://github.com/cython/cython/issues/1530 Dear maintainer, the package fails to build on 32 bit architectures. There is already an upstream bug report and a partial fix. Best, Tobias
Bug#843898: Something to try
On 11/21/2016 01:03 PM, Sebastian P. Luque wrote: > On Sun, 20 Nov 2016 19:57:53 -0600, > Sebastian P. Luque wrote: > >> On Sun, 20 Nov 2016 21:01:08 +0000, >> Tobias Hansen wrote: > >> [...] > >>>> $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ total 12K >>>> drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 . drwx-- 20 sluque >>>> sluque 4.0K Oct 30 16:18 .. drwxr-xr-x 2 sluque sluque 4.0K Oct 30 >>>> 16:16 configparser > >>> What happens if you rename that for a moment? Does it fix the >>> problem? > >> No; same result. > > I just tried a different approach, and it's revealing: > > $ python -s > Python 2.7.12+ (default, Sep 1 2016, 20:27:38) > [GCC 6.2.0 20160927] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> from backports.shutil_get_terminal_size import get_terminal_size > > Why on Earth did moving ~/.local/lib/python2.7/site-packages/backports > not have the same effect is beyond me. > So I guess we can close the bug. The problem is that different backport packages can conflict with each other. The only thing we could think about is if python-backports-shutil-get-terminal-size could be changed to be more robust against that. Looks like a task for upstream. Best, Tobias
Bug#843898: Something to try
On 11/21/2016 01:57 AM, Sebastian P. Luque wrote: > On Sun, 20 Nov 2016 21:01:08 +, > Tobias Hansen wrote: > > [...] > >>> $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ total 12K >>> drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 . drwx-- 20 sluque >>> sluque 4.0K Oct 30 16:18 .. drwxr-xr-x 2 sluque sluque 4.0K Oct 30 >>> 16:16 configparser > >> What happens if you rename that for a moment? Does it fix the problem? > > No; same result. > What do you get if you run this: python -c "import sys; print sys.path" What exactly did you try? Could you try renaming the whole folder ~/.local/lib/python2.7/site-packages ?
Bug#843898: Something to try
On 11/20/2016 08:29 PM, Sebastian P. Luque wrote: > On Sun, 20 Nov 2016 19:17:49 +, > Tobias Hansen wrote: > >> If you google this you see that tons of people have similar issues: >> https://github.com/ipython/ipython/issues/9656 >> https://github.com/ipython/ipython/issues/9815 >> https://github.com/chrippa/backports.shutil_get_terminal_size/issues/9 > >> The most common "solution" there is reinstalling something with >> pip. My suspicion is that the people who see this on Debian also used >> pip and there is something interfering. Did you guys use pip (or >> something else to install Python modules not from Debian) and have a >> backports module or backports.shutil_get_terminal_size itself >> installed there? > > I do use pip within virtual environments, but these shouldn't interfere. > > First, as per Julien's request, here's my output: > > $ python > Python 2.7.12+ (default, Sep 1 2016, 20:27:38) > [GCC 6.2.0 20160927] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> from backports.shutil_get_terminal_size import get_terminal_size > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named shutil_get_terminal_size > > When using pip within virtual environments, packages/modules get > installed in ~/.local/lib/python2.7 in my case. There I see one > potentially interfering backports module, which shows these contents: > > $ ls -alh ~/.local/lib/python2.7/site-packages/backports/ > total 12K > drwxr-xr-x 3 sluque sluque 4.0K Oct 30 16:16 . > drwx-- 20 sluque sluque 4.0K Oct 30 16:18 .. > drwxr-xr-x 2 sluque sluque 4.0K Oct 30 16:16 configparser > > What happens if you rename that for a moment? Does it fix the problem?
Bug#843898: Something to try
If you google this you see that tons of people have similar issues: https://github.com/ipython/ipython/issues/9656 https://github.com/ipython/ipython/issues/9815 https://github.com/chrippa/backports.shutil_get_terminal_size/issues/9 The most common "solution" there is reinstalling something with pip. My suspicion is that the people who see this on Debian also used pip and there is something interfering. Did you guys use pip (or something else to install Python modules not from Debian) and have a backports module or backports.shutil_get_terminal_size itself installed there? Best, Tobias On Wed, 16 Nov 2016 07:42:16 +0100 Julien Puydt wrote: > Hi, > > can all of you seeing the problem try to reproduce the following > session, please, and send what you get: > > jpuydt@nox:~$ python > Python 2.7.12+ (default, Nov 4 2016, 17:04:30) > [GCC 6.2.0 20161027] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from backports.shutil_get_terminal_size import get_terminal_size > >>> > > (as you see, there's no problem here...) > > Thanks, > > Snark on #debian-python > >
Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'
Control: tags -1 + patch This was fixed upstream. Here is the patch: https://github.com/cython/cython/commit/6dd263aa3d2d6d80f2d7b96a640a27538fdaa0b2.patch Best, Tobias On Wed, 10 Aug 2016 14:20:36 +0200 Andreas Tille wrote: > On Wed, Aug 10, 2016 at 02:12:20PM +0200, Jakub Wilk wrote: > > * Andreas Tille , 2016-08-10, 09:54: > > >I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function > > >call should be fine - so probably the problem is somewhere else - but > > >where? > > > > https://github.com/cython/cython/issues/551 > > Thanks a lot for tracking this down > > Andreas. > > -- > http://fam-tille.de > >
Bug#811825: FaCT++ Debian package removal
Hello Roberto, I have some good news. But let me first explain the situation. What happened here is a social problem that sometimes occurs in Debian. The package has a single person as a maintainer. He didn't respond to the bugs, and nobody else felt responsible to work on the issue. On top of that, it is normally expected not to upload a package without the maintainers consent, so a non-responding maintainer can slow things down quite a lot. The reason I asked for a patch is that a soname bump requires a library transitions and for the next Debian release these were only allowed until November 5. The good news is, we moved the package to team maintenance, packaged version 1.2 and got a transition granted despite the freeze. So the problem should be resolved. With a team maintained package RC bugs will hopefully be fixed more quickly in the future. Here is the bug tracking the ppl 1.2 transition: https://bugs.debian.org/844100 Best, Tobias On 11/14/2016 02:05 PM, Roberto Bagnara wrote: > > Hello Tobias. > > Sorry for the delay in answering your message: I was traveling. > > On 11/11/2016 02:08 AM, Tobias Hansen wrote: >> I noticed today that ppl was removed from Debian testing due to two RC >> bugs. The problem is that ppl 1.2 has a new soname (14), that means it >> requires a library transition. We are now already past the library >> transition freeze for Debian stretch. Are you shure that the ABI of ppl >> changed with version 1.2, i.e. that this soname bump is required? > > No, I am not sure it is required: we bump it at any new release > just as a caution. > >> It would now probably be best to patch version 1.1 of ppl to have at >> least this version in the next Debian release. The previous mails from >> this bug report suggest that the patch that was discussed was not enough >> to fix the build with gcc 6. Could you provide a new patch for this? > > I am sorry, but I do not follow: why not switch to PPL 1.2, which > was released around 9 months ago and that is the current stable version? > More generally, we have no time to follow the evolution of Debian. > We have offered (multiple times) all the possible cooperation upstream, > but we got the impression the Debian people is not interested: > they do not use our mailing list and they seem totally uninterested to > explain the issues in non-Debian terms. I now repeat the offer to you: > if you are willing to explain what the problem is without assuming > we know anything about Debian, you are more than welcome, and the > problem will be solved very quickly. > Kind regards, > >Roberto > >> On Sat, 6 Aug 2016 14:34:14 +0200 Roberto Bagnara >> wrote: >>> The new version upstream (PPL 1.2, released in February 2016) solves >>> all problems wrt GCC 6. If upgrading to the latest upstream release >>> is not wanted (why?), then patches have been provided in this very issue. >>> Kind regards, >>> >>>Roberto >>> >> > >
Bug#806865: transition: ppl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi Release Team, I noticed yesterday that ppl has two RC bugs and was removed from testing. I would like to take over the package and fix it, but one of the RC bugs (#811825) is best fixed by updating to the new upstream version, which requires a small library transition. Since the debian-devel-announce@l.d.o mail from November 5 said the transition freeze is only for "transitions that involve a large number of packages", I'd thought I'd ask if we can still do this transition. I already created a package of ppl 1.2 that fixes both RC bugs. ppl has two reverse dependencies, which were of course both removed from testing because of ppl: apron cloog-ppl I checked that they both build without changes against the updated ppl package. If it's too late for the transition, we'll have to see if we can fix #811825 by applying a patch that does not require a transition. Thanks, Tobias Ben file: title = "ppl"; is_affected = .depends ~ "libppl13v5" | .depends ~ "libppl14"; is_good = .depends ~ "libppl14"; is_bad = .depends ~ "libppl13v5";
Bug#811825: FaCT++ Debian package removal
Hi Roberto, I noticed today that ppl was removed from Debian testing due to two RC bugs. The problem is that ppl 1.2 has a new soname (14), that means it requires a library transition. We are now already past the library transition freeze for Debian stretch. Are you shure that the ABI of ppl changed with version 1.2, i.e. that this soname bump is required? It would now probably be best to patch version 1.1 of ppl to have at least this version in the next Debian release. The previous mails from this bug report suggest that the patch that was discussed was not enough to fix the build with gcc 6. Could you provide a new patch for this? Best, Tobias On Sat, 6 Aug 2016 14:34:14 +0200 Roberto Bagnara wrote: > The new version upstream (PPL 1.2, released in February 2016) solves > all problems wrt GCC 6. If upgrading to the latest upstream release > is not wanted (why?), then patches have been provided in this very issue. > Kind regards, > >Roberto >
Bug#840454: Lowering the severity to important
Control: severity -1 important I'm lowering the severity to important to allow testing migration. fflas-ffpack 1.6.0 in testing is broken since it build-depends on givaro 3.7.2, which is not in testing anymore. For now it is best to have a working package for the architectures that work (and no package for the other architectures).
Bug#773205: libatomic-ops-dev: FTBFS on mips64el
Hi Ian, the response on the upstream bug report looks like it could take a while with the new release. With regard to the upcoming freeze, could you please apply the patches so that the package can migrate to testing? Best, Tobias On Tue, 1 Nov 2016 11:23:19 +1100 Ian Wienand wrote: > I'm sorry about this. I must have misread the history of that branch > > My preference is to be in sync with upstream, so I have asked if we > can get this in a 7.4.5 release [1] > > If no response, or not possible, I'll add these back in > > Thanks, > > -i > > [1] https://github.com/ivmai/libatomic_ops/issues/20 > > On Fri, Oct 28, 2016 at 8:31 PM, James Cowgill wrote: > > Control: found -1 7.4.4-1 > > Control: severity -1 serious > > > > Hi, > > > > In 7.4.4-1 the patches adding mips64el support were removed from the > > package. While they've applied upstream in the 'master' branch not all > > of them were applied to the 'release-7_4' branch and libatomic-ops FTBFS > > on mips64el again. > > > > These have been applied to 7.4.4-1 (which is good): > > 0002-Remove-inclusion-of-acquire_release_volatile.h-on-mi.patch > > 0003-Minor-fix-of-code-alignment-in-mips-AO_compare_and_s.patch > > > > Please reapply these patches from 7.4.2-3: > > 0001-Use-LLD-and-SCD-instructions-on-mips64.patch > > 0004-Support-n32-ABI-for-mips64.patch > > > > Thanks, > > James > > > >
Bug#833860: marked as pending
tag 833860 pending thanks Hello, Bug #833860 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=python-modules/packages/pexpect.git;a=commitdiff;h=61cb26c --- commit 61cb26ca92c352d1d2f3230d446147b7c7c3e47c Author: Tobias Hansen Date: Fri Aug 12 13:38:56 2016 + Set http_proxy='127.0.0.1:9' for sphinx-build to prevent internet access. diff --git a/debian/changelog b/debian/changelog index a07972c..a77f626 100644 --- a/debian/changelog +++ b/debian/changelog @@ -11,6 +11,9 @@ pexpect (4.2.0-1) UNRELEASED; urgency=medium * Bump Standards-Version to 3.9.8. * Bump dh compat to 9. * Install without *.install files. + * Set http_proxy='127.0.0.1:9' for sphinx-build to prevent +internet access (Closes: #833860) + -- Tobias Hansen Wed, 10 Aug 2016 14:20:41 +0100
Bug#829742: dpkg-maintscript-helper fails to convert directory to symlink on upgrade
Hi Jerome, ok, if you think it does not need to be fixed, you can close the bug. I should mention that a workaround to get the package configured is to just delete the folder /usr/share/doc/libmpfi-dev. Best, Tobias On 07/05/2016 07:42 PM, Jerome BENOIT wrote: > Hi Tobias, thanks for the report. > > > > On 05/07/16 18:46, Tobias Hansen wrote: >> Source: mpfi >> Version: 1.5.1+ds-4 >> Severity: grave >> Justification: prevents package upgrade > >> Hi Jerome, > >> When upgrading from version 1.5.1+ds-2, I get the following error: > >> Preparing to unpack .../libmpfi-dev_1.5.1+ds-4_amd64.deb ... >> dpkg-query: no packages found matching libmpfi-dev:amd64 >> dpkg-query: package 'libmpfi-dev' is not installed >> Use dpkg --info (= dpkg-deb --info) to examine archive files, >> and dpkg --contents (= dpkg-deb --contents) to list their contents. >> dpkg-maintscript-helper: error: directory '/usr/share/doc/libmpfi-dev' >> contains files not owned by package libmpfi-dev:amd64, cannot switch to >> symlink >> dpkg: error processing archive >> /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb (--unpack): >> subprocess new pre-installation script returned error exit status 1 >> Errors were encountered while processing: >> /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb >> E: Sub-process /usr/bin/dpkg returned an error code (1) > >> The directory contains the following files > >> ls /usr/share/doc/libmpfi-dev >> changelog.Debian.gz changelog.gz copyright > > Indeed the migration part of the story had been messed up for a while: > a couple of fixes has been done to fix it. Tests via piuparts and the absence > of any piuparts bugreport let me think that is now working with the current > distributed versions: 1.5.1-1, 1.5.1-3, and 1.5.1+ds-4 . > Your former version, according to the report is 1.5.1+ds-2, a buggy one > that was for a short while in testing or unstable: my guess is that we > can consider it as over. Otherwise, I am not sure if it is relevant > to fix this very migration as it is quite unlikely while I am not sure > how to reproduce it. > > Thanks, > Jerome > > > >> Best, >> Tobias > > >
Bug#829742: dpkg-maintscript-helper fails to convert directory to symlink on upgrade
Source: mpfi Version: 1.5.1+ds-4 Severity: grave Justification: prevents package upgrade Hi Jerome, When upgrading from version 1.5.1+ds-2, I get the following error: Preparing to unpack .../libmpfi-dev_1.5.1+ds-4_amd64.deb ... dpkg-query: no packages found matching libmpfi-dev:amd64 dpkg-query: package 'libmpfi-dev' is not installed Use dpkg --info (= dpkg-deb --info) to examine archive files, and dpkg --contents (= dpkg-deb --contents) to list their contents. dpkg-maintscript-helper: error: directory '/usr/share/doc/libmpfi-dev' contains files not owned by package libmpfi-dev:amd64, cannot switch to symlink dpkg: error processing archive /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) The directory contains the following files ls /usr/share/doc/libmpfi-dev changelog.Debian.gz changelog.gz copyright Best, Tobias
Bug#784135: Lowering severity
Control: severity -1 important I'm lowering the severity for now because i suspect this happens only with some older graphics cards. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Bug#784135: out-of-order: starting out-of-order produces black window and high system load
Hi, it works for me. Which graphics card and driver are you using? Best, Tobias Hansen Am 03.05.2015 um 14:26 schrieb Nils Dagsson Moskopp: > Package: out-of-order > Version: 1.0-2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I started out-of-order and it produces a black window and high system load. > I killed it using killall and xkill. I did expect to see some kind of game. > > Here is the output of “out-of-order -d1” right up until the program hangs: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776483: package is in NEW
Control: tags -1 +pending A fix for this is currently in the NEW queue. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767423: #767423
Dear Eric, I noticed that there was this reply to your bug report, directed at you but apparently not sent to you (only to the bug). So, would it be possible to share this file? Best, Tobias On Sat, 13 Dec 2014 20:14:07 +0100 Thomas Girard wrote: > tag 767423 + moreinfo > thanks > > > Hello, > > the stacktrace you provide shows two messages that could explain the error: > > > (tracker-extract:18870): libmediaart-CRITICAL **: media_art_process_buffer: > > assertion 'artist != NULL || title != NULL' failed > > > > (tracker-extract:18870): Tracker-WARNING **: Could not process media art for > > 'file:///home//test.flac', No error given > > Is it possible that you share this flac file? > > Thanks, > Regards, > > Thomas > > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765129: tcos: diff for NMU version 0.89.93+nmu1
Am 21.12.2014 um 17:09 schrieb Mario Izquierdo Rodríguez: > >> >> Hi, >> >> I just realized that there are already different versions in testing and >> unstable. That means we have to upload a targeted fix for the bug for >> the package version that is in testing (0.89.93) to >> testing-proposed-updates. >> >> Is the start-stop-daemon bug relevant for that version? Also, we can >> really just fix RC bugs this late in the freeze (freeze policy was >> tightened on Dec 5), so if the second bug is also RC you have to open a >> bug for it and close it in the changelog. If the second bug is not in >> version 0.89.93 or not RC, I'll just upload Jonathans debdiff to t-p-u >> ok? >> >> Best, >> Tobias >> > > > The transition to libxmlrpc-core-c3-dev breaks some binaries and 0.89.93 > + debian/control diff don't fix the real problem. > > I think it's better to remove from testing, and 0.89.97 will be too > dificult to upload to testing-proposed-updates because of freeze. > > What's your opinion? > > Thanks for your help > So you mean 0.89.93 in testing has a third RC bug right now? It could also be possible to upload a 0.89.93+tpu1 with fixes for 3 RC bugs to testing-proposed-updates. If you want to know for sure, file the RC bugs, prepare the patches and get them pre-approved by the release team on the debian-release list. Or just explain them the problem without preparing everything and ask them what they think. Best, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765129: tcos: diff for NMU version 0.89.93+nmu1
Am 21.12.2014 um 16:31 schrieb Mario Izquierdo Rodríguez: > El 21/12/14 a las 16:17, Tobias Hansen escribió: >> Am 21.12.2014 um 16:05 schrieb Mario Izquierdo Rodríguez: >>> El 19/12/14 a las 22:03, Tobias Hansen escribió: >>>> On Tue, 02 Dec 2014 21:29:29 +0100 >>>> =?UTF-8?B?TWFyaW8gSXpxdWllcmRvIFJvZHLDrWd1ZXo=?= >>>> wrote: >>>>> El 24/11/14 a las 15:28, Jonathan Wiltshire escribió: >>>>>> On Mon, Nov 24, 2014 at 12:05:21AM +0100, Mario Izquierdo RodrÃguez >>>>>> wrote: >>>>>>> El 23/11/14 a las 19:40, Jonathan Wiltshire escribió: >>>>>>>> Control: tags 765129 + pending >>>>>>>> >>>>>>>> Dear maintainer, >>>>>>>> >>>>>>>> I've prepared an NMU for tcos (versioned as 0.89.93+nmu1) and >>>>>>>> uploaded it to DELAYED/2. Please feel free to tell me if I >>>>>>>> should delay it longer. >>>>>>>> >>>>>>>> Regards. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, thanks for NMU, I'm not a DD and I have a new package but no >>>>>>> sponsor for >>>>>>> upload. >>>>>> >>>>>> How about preparing a maintainer upload and I'll sponsor it for you? >>>>>> >>>>> >>>>> Hi Jonathan. >>>>> >>>>> I had prepared new TCOS package: >>>>> >>>>> http://mariodebian.com/debian-packages/tcos_0.89.97.dsc >>>>> >>>>> Only sources (not binary) >>>>> >>>>> Can you upload it? >>>>> >>>>> Thanks in advance. >>>>> >>>> >>>> Hi Mario, >>>> >>>> the freeze policy allows only targeted fixes for rc bugs. The >>>> changes in >>>> 0.89.97 are too extensive. I could upload Jonathans NMU patch, unless >>>> there's another small and important fix you want to include. Is the >>>> patch you mentioned on Nov 24 important? >>>> >>>> Best, >>>> Tobias >>>> >>> >>> >>> >>> Hi I attach the minimal patch needed to fix this bug and another one >>> that fix start-stop-daemon start >>> >>> You can split to use only debian/control diff but the diff of >>> debian/tcos-standalone.init is needed to fix start-stop-daemon >>> >>> Thanks in advance >>> >>> >> >> Hi, >> >> could you please prepare a maintainer upload (create a .dsc) where these >> patches are applied? Please mention both changes in the changelog. Then >> I upload it. >> >> Best, >> Tobias >> > > Here is it: > > http://mariodebian.com/debian-packages/tcos_0.89.96+1.dsc > > Diff from 0.89.96 (current Debian unstable version) attached. > > > > Thanks > Hi, I just realized that there are already different versions in testing and unstable. That means we have to upload a targeted fix for the bug for the package version that is in testing (0.89.93) to testing-proposed-updates. Is the start-stop-daemon bug relevant for that version? Also, we can really just fix RC bugs this late in the freeze (freeze policy was tightened on Dec 5), so if the second bug is also RC you have to open a bug for it and close it in the changelog. If the second bug is not in version 0.89.93 or not RC, I'll just upload Jonathans debdiff to t-p-u ok? Best, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765129: tcos: diff for NMU version 0.89.93+nmu1
Am 21.12.2014 um 16:05 schrieb Mario Izquierdo Rodríguez: > El 19/12/14 a las 22:03, Tobias Hansen escribió: >> On Tue, 02 Dec 2014 21:29:29 +0100 >> =?UTF-8?B?TWFyaW8gSXpxdWllcmRvIFJvZHLDrWd1ZXo=?= >>wrote: >>> El 24/11/14 a las 15:28, Jonathan Wiltshire escribió: >>>> On Mon, Nov 24, 2014 at 12:05:21AM +0100, Mario Izquierdo RodrÃguez >>>> wrote: >>>>> El 23/11/14 a las 19:40, Jonathan Wiltshire escribió: >>>>>> Control: tags 765129 + pending >>>>>> >>>>>> Dear maintainer, >>>>>> >>>>>> I've prepared an NMU for tcos (versioned as 0.89.93+nmu1) and >>>>>> uploaded it to DELAYED/2. Please feel free to tell me if I >>>>>> should delay it longer. >>>>>> >>>>>> Regards. >>>>>> >>>>> >>>>> >>>>> Hi, thanks for NMU, I'm not a DD and I have a new package but no >>>>> sponsor for >>>>> upload. >>>> >>>> How about preparing a maintainer upload and I'll sponsor it for you? >>>> >>> >>> Hi Jonathan. >>> >>> I had prepared new TCOS package: >>> >>> http://mariodebian.com/debian-packages/tcos_0.89.97.dsc >>> >>> Only sources (not binary) >>> >>> Can you upload it? >>> >>> Thanks in advance. >>> >> >> Hi Mario, >> >> the freeze policy allows only targeted fixes for rc bugs. The changes in >> 0.89.97 are too extensive. I could upload Jonathans NMU patch, unless >> there's another small and important fix you want to include. Is the >> patch you mentioned on Nov 24 important? >> >> Best, >> Tobias >> > > > > Hi I attach the minimal patch needed to fix this bug and another one > that fix start-stop-daemon start > > You can split to use only debian/control diff but the diff of > debian/tcos-standalone.init is needed to fix start-stop-daemon > > Thanks in advance > > Hi, could you please prepare a maintainer upload (create a .dsc) where these patches are applied? Please mention both changes in the changelog. Then I upload it. Best, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765129: tcos: diff for NMU version 0.89.93+nmu1
On Tue, 02 Dec 2014 21:29:29 +0100 =?UTF-8?B?TWFyaW8gSXpxdWllcmRvIFJvZHLDrWd1ZXo=?= wrote: > El 24/11/14 a las 15:28, Jonathan Wiltshire escribió: > > On Mon, Nov 24, 2014 at 12:05:21AM +0100, Mario Izquierdo RodrÃguez wrote: > >> El 23/11/14 a las 19:40, Jonathan Wiltshire escribió: > >>> Control: tags 765129 + pending > >>> > >>> Dear maintainer, > >>> > >>> I've prepared an NMU for tcos (versioned as 0.89.93+nmu1) and > >>> uploaded it to DELAYED/2. Please feel free to tell me if I > >>> should delay it longer. > >>> > >>> Regards. > >>> > >> > >> > >> Hi, thanks for NMU, I'm not a DD and I have a new package but no sponsor > >> for > >> upload. > > > > How about preparing a maintainer upload and I'll sponsor it for you? > > > > Hi Jonathan. > > I had prepared new TCOS package: > > http://mariodebian.com/debian-packages/tcos_0.89.97.dsc > > Only sources (not binary) > > Can you upload it? > > Thanks in advance. > Hi Mario, the freeze policy allows only targeted fixes for rc bugs. The changes in 0.89.97 are too extensive. I could upload Jonathans NMU patch, unless there's another small and important fix you want to include. Is the patch you mentioned on Nov 24 important? Best, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771132: morse-simulator is not usable with the current version of blender
Control: tags -1 + patch
Hi,
I applied the two mentioned commits to the Debian package and created
the attached debdiff. I confirmed that with the patches the bug is fixed
by running the sample simulation.
Best,
Tobias
On Wed, 3 Dec 2014 17:59:36 +0100 Arnaud Degroote
wrote:
> On 01/Dec - 22:56, Pablo Oliveira wrote:
> >
> > Hi Séverin,
> >
> > Séverin Lemaignan wrote:
> > > For sanity check, can you post the output of `morse --version`?
> >
> > Sure:
> >
> > morse 1.2.1
> >
> > > Thanks for your report. MORSE 1.2.1 is indeed expected to support Blender
> > > 2.72.
> >
> > From my tests, MORSE 1.2.1 does not work out of the box with Blender 2.72. I
> > relaxed the version check at morse:48 and ran into another problem.
> > Apparently,
> > Blender 2.72 has substituded the link_append method by two separate link
> > and append
> > methods
> > (http://blender.stackexchange.com/questions/17876/import-object-without-bpy-ops-wm-link-append).
> > To make morse work on my system I had to patch line 63 of
> > /usr/lib/python3/dist-packages/morse/builder/bpymorse.py with "link_append
> > = bpy.ops.wm.link"
>
> Can you give a try yo Morse 1.2.2 available at
>
> ftp://ftp.openrobots.org/pub/openrobots/morse/morse-1.2.2.tar.bz2
>
> and confirm that it works properly on sid.
>
> Best regards,
>
> --
> Arnaud Degroote
> ISAE DMIA
>
>
diff -Nru morse-simulator-1.2.1/debian/changelog
morse-simulator-1.2.1/debian/changelog
--- morse-simulator-1.2.1/debian/changelog 2014-07-14 15:09:04.0
+0200
+++ morse-simulator-1.2.1/debian/changelog 2014-12-19 21:20:44.0
+0100
@@ -1,3 +1,10 @@
+morse-simulator (1.2.1-1.1) unstable; urgency=medium
+
+ * Team upload.
+ * Allow running with Blender 2.72. (Closes: #771132)
+
+ -- Tobias Hansen Fri, 19 Dec 2014 21:18:35 +0100
+
morse-simulator (1.2.1-1) unstable; urgency=medium
* New upstream release
diff -Nru morse-simulator-1.2.1/debian/patches/bump-max-blender-version.patch
morse-simulator-1.2.1/debian/patches/bump-max-blender-version.patch
--- morse-simulator-1.2.1/debian/patches/bump-max-blender-version.patch
1970-01-01 01:00:00.0 +0100
+++ morse-simulator-1.2.1/debian/patches/bump-max-blender-version.patch
2014-12-19 21:18:01.0 +0100
@@ -0,0 +1,24 @@
+From 35c9b53d03b5df6c1c66e0d3265235092774c225 Mon Sep 17 00:00:00 2001
+From: Pierrick Koch
+Date: Wed, 24 Sep 2014 14:07:53 +0200
+Subject: [PATCH] [bin] bump blender max version
+
+tested with:
+http://download.blender.org/release/Blender2.72/blender-2.72-RC1-linux-glibc211-x86_64.tar.bz2
+---
+ bin/morse.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/morse.in b/bin/morse.in
+index 022ece5..b28e01b 100755
+--- a/bin/morse.in
b/bin/morse.in
+@@ -44,7 +44,7 @@ except ImportError as exn:
+ #Blender version must be egal or bigger than...
+ MIN_BLENDER_VERSION = "2.62"
+ #Blender version must be smaller than...
+-STRICT_MAX_BLENDER_VERSION = "2.72"
++STRICT_MAX_BLENDER_VERSION = "2.73"
+
+ #Unix-style path to the MORSE default scene and templates, within the prefix
+ DEFAULT_SCENE_PATH = "share/morse/data/morse_default.blend"
diff -Nru morse-simulator-1.2.1/debian/patches/drop-link_append.patch
morse-simulator-1.2.1/debian/patches/drop-link_append.patch
--- morse-simulator-1.2.1/debian/patches/drop-link_append.patch 1970-01-01
01:00:00.0 +0100
+++ morse-simulator-1.2.1/debian/patches/drop-link_append.patch 2014-12-19
21:18:25.0 +0100
@@ -0,0 +1,64 @@
+From db937ea839121cd44762342c6833d4e8610a1911 Mon Sep 17 00:00:00 2001
+From: Pierrick Koch
+Date: Mon, 15 Sep 2014 10:11:38 +0200
+Subject: [PATCH] [builder] link_append dropped in 2.71.6
+
+---
+ src/morse/builder/abstractcomponent.py | 12
+ src/morse/builder/bpymorse.py | 8 +++-
+ 2 files changed, 15 insertions(+), 5 deletions(-)
+
+--- a/src/morse/builder/abstractcomponent.py
b/src/morse/builder/abstractcomponent.py
+@@ -633,19 +633,23 @@
+ "or default path, typically
$PREFIX/share/morse/data)."% (component, looked_dirs))
+ raise FileNotFoundError("%s '%s' not
found"%(self.__class__.__name__, component))
+
+-if not objects: # link_append all objects from blend file
++if not objects: # append all objects from blend file
+ objects = bpymorse.get_objects_in_blend(filepath)
+
+ if prefix: # filter (used by PassiveObject)
+ objects = [obj for obj in objects if obj.startswith(prefix)]
+
+-# Format the objects list for link_append
++# Format the objects list to append
+ objlist = [{'name':obj} for obj in objects]
+
+
Bug#765291: aseprite: FTBFS on i386,kfreebsd-i386: 1 FAILED TEST
Control: tags -1 + pending Thanks. I told upstream about the bug in the resizing algorithm and will upload either a fix or disable the test soon. Best, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613484: /usr/bin/ecl is not installed
Control: tags -1 + patch Hi, the problem is a faulty postrm script that removes /usr/bin/ecl on upgrade after the new files are unpacked, see [1]. A workaround is to remove ecl and then install it again. The attached patch fixes the postrm script but since the old postrm script is run on upgrade everybody upgrading to a new version which includes this patch would still end up without /usr/bin/ecl. After a second update everything would be fine. I'm not sure if one should go further into complicated maintainer script constructions to solve this issue. [1] https://wiki.debian.org/MaintainerScripts#Upgrading Best, Tobias On Mon, 17 Feb 2014 12:41:40 +0100 "Ph. Marek" wrote: > Package: ecl > Version: 13.5.1+dfsg2-4 > Followup-For: Bug #613484 > > This is still an issue: > > > $ apt-get install --reinstall ecl ... > $ ls -la /usr/bin/ecl > ls: cannot access /usr/bin/ecl: No such file or directory --- a/debian/postrm +++ b/debian/postrm @@ -17,7 +17,7 @@ # for details, see /usr/share/doc/packaging-manual/ case "$1" in - purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) + purge|remove|failed-upgrade|abort-install|abort-upgrade|disappear) rm /usr/bin/ecl 2> /dev/null || true rm /usr/lib/ecl/*.o 2> /dev/null || true ;;
Bug#745901: cogl fglrx incompatibility bug
Hi, this bug was now reported as #722161 against cogl #745901 against fglrx-driver #744152 against gdm3 I posted a workaround to #745901 [1]. The bugs should be merged and linked to the affected packages with "affects" but I'm not sure if the bug is in cogl or fglrx. It should probably be fixed in cogl. Best, Tobias [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745901#41 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745901: fglrx-driver: fglrx update crashes totem, gdm, gnome-session and anything that uses clutter
Comment 4 from [1] has a workaround that lets you use GNOME and fglrx together. I had to switch to lightdm since gdm3 doesn't work and use this ~/.xsession: export COGL_DRIVER=gl export COGL_OVERRIDE_GL_VERSION=1.4 export COGL_RENDERER=GLX export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2 gnome-session Note that this will link everything run under the session with the GL library. See [1] for further explanation. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1054435#c4 Cheers, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745901: fglrx-driver: fglrx update crashes totem, gdm, gnome-session and anything that uses clutter
Here are links to the gnome and (unofficial) amd bugs that seem relevant: https://bugzilla.gnome.org/show_bug.cgi?id=712340 http://ati.cchtml.com/show_bug.cgi?id=949 It seems related to GNOME enabling EGL/Wayland support. The first version of clutter-1.0 with EGL support enabled that migrated to testing was 1.18.0-2. It came to testing in the beginning of April. That was around the time I first got a black screen instead of gdm3. As a workaround I switched to the free radeonsi driver. I checked today that the current set of packages in testing still has this problem. Cheers, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745901: fglrx-driver: fglrx update crashes totem, gdm, gnome-session and anything that uses clutter
found 745901 1:14.3~beta1.0-1 thanks I have the same problem with the fglrx version in testing with a Radeon HD 7750 (Southern Islands). Cheers, Tobias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743328: genus2reduction: obsoleted by libpari 2.7
Hi Bill, I already did. Cheers, Tobias On 04/15/2014 11:02 AM, Bill Allombert wrote: > Woould anybody object if I asked for the removal of this package ? > As far as I can see it is not maintained, buggy, and quite useless now > that gp includes the functionnality (without the bugs). > > Cheers, -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733362: gstreamer0.10: FTBFS: grammar.tab.c:1819:7: error: too few arguments to function 'priv_gst_parse_yylex'
tag 733362 + patch fixed-upstream forwarded 733362 https://bugzilla.gnome.org/show_bug.cgi?id=706462 thanks Should be fixed by the upstream patch in https://bugzilla.gnome.org/show_bug.cgi?id=706462 See also https://bugzilla.gnome.org/show_bug.cgi?id=705401 which has the same compile error as reported here and is marked as duplicate of 706462. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
