Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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=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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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 libmpc3 1.2.1-1
> pn

Bug#1002587: python3-sage: Depends on unavailable package

[Tobias Hansen]

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  

Bug#998190: sagemath: package new upstream version

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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 

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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?

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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.

[Tobias Hansen]

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.

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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)

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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  

Bug#879905: glee: source for GLee.c and GLee.h is missing

[Tobias Hansen]

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

[Tobias Hansen]

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++6   8.1.0-9
> ii  libsymmetrica2   2.0+ds-5
&g

Bug#896218: python-brial: brial fails to import

[Tobias Hansen]

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

[Tobias Hansen]

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=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

[Tobias Hansen]

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

[Tobias Hansen]

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)

[Tobias Hansen]

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

[Tobias Hansen]

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=armhf=8.0-5=1504503431=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)

[Tobias Hansen]

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/src/sage/sagemath/sagemath'
   debian/rules override_dh_auto_build-indep
make[1]: Ent

Bug#846268: cython: Upstream resolution

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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}

[Tobias Hansen]

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}

[Tobias Hansen]

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}

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

On 11/21/2016 01:03 PM, Sebastian P. Luque wrote:
> On Sun, 20 Nov 2016 19:57:53 -0600,
> Sebastian P. Luque <splu...@gmail.com> wrote:
> 
>> On Sun, 20 Nov 2016 21:01:08 +0000,
>> Tobias Hansen <than...@debian.org> 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

[Tobias Hansen]

On 11/21/2016 01:57 AM, Sebastian P. Luque wrote:
> On Sun, 20 Nov 2016 21:01:08 +,
> Tobias Hansen <than...@debian.org> 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

[Tobias Hansen]

On 11/20/2016 08:29 PM, Sebastian P. Luque wrote:
> On Sun, 20 Nov 2016 19:17:49 +,
> Tobias Hansen <than...@debian.org> 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

[Tobias Hansen]

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'

[Tobias Hansen]

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

[Tobias Hansen]

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 <bagn...@cs.unipr.it>
>> 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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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 <than...@debian.org>
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 <than...@debian.org>  Wed, 10 Aug 2016 14:20:41 +0100
 

Bug#829742: dpkg-maintscript-helper fails to convert directory to symlink on upgrade

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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

[Tobias Hansen]

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
thomas.g.gir...@free.fr 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/SNIP/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

[Tobias Hansen]

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=?=
   mariodeb...@gmail.com 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

[Tobias Hansen]

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=?=
mariodeb...@gmail.com 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

[Tobias Hansen]

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#771132: morse-simulator is not usable with the current version of blender

[Tobias Hansen]

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
arnaud.degro...@laas.fr wrote:
 On 01/Dec - 22:56, Pablo Oliveira wrote:
  
  Hi Séverin,
  
  Séverin Lemaignan severin.lemaig...@epfl.ch 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 than...@debian.org  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 pierrick.k...@gmail.com
+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 pierrick.k...@gmail.com
+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]
+ 
+ bpymorse.deselect_all()
+ # Append the objects to the scene, and (auto)select them
+-bpymorse.link_append(directory=filepath + '/Object/', link=False,
+- autoselect=True, files=objlist

Bug#765129: tcos: diff for NMU version 0.89.93+nmu1

[Tobias Hansen]

On Tue, 02 Dec 2014 21:29:29 +0100
=?UTF-8?B?TWFyaW8gSXpxdWllcmRvIFJvZHLDrWd1ZXo=?=
 mariodeb...@gmail.com 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#765291: aseprite: FTBFS on i386,kfreebsd-i386: 1 FAILED TEST

[Tobias Hansen]

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

[Tobias Hansen]

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
philipp.ma...@linbit.com 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

[Tobias Hansen]

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

[Tobias Hansen]

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#745901: fglrx-driver: fglrx update crashes totem, gdm, gnome-session and anything that uses clutter

[Tobias Hansen]

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

[Tobias Hansen]

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#743328: genus2reduction: obsoleted by libpari 2.7

[Tobias Hansen]

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#710635: pynac: FTBFS: ld: cannot find -lz

[Tobias Hansen]

Hi Julien,

pynac 0.3.1 was released now.

Cheers,
Tobias


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org