Bug#881216: sagemath: Not using standard LaTeX fonts with plots using text()

[Ximin Luo]

Hi Jaimos, you can force use of the latex fonts by passing typeset="latex" as a 
parameter to any one of the three functions plot(), text() or show() that 
you're using.

The documentation for sage.plot.graphics.show() says:

- ``typeset`` -- (default: ``"default"``) string. The type of
  font rendering that should be used for the text. The possible
  values are

  - ``"default"`` -- Uses matplotlib's internal text rendering
engine called Mathtext ( see
https://matplotlib.org/users/mathtext.html ). If you have
modified the default matplotlib settings, for instance via
a matplotlibrc file, then this option will not change any of
those settings.
  - ``"latex"`` -- LaTeX is used for rendering the fonts. This
requires LaTeX, dvipng and Ghostscript to be installed.
  - ``"type1"`` -- Type 1 fonts are used by matplotlib in the text
in the figure.  This requires LaTeX, dvipng and Ghostscript to
be installed.

implying that the "default" setting is based on whatever matplotlib does. 
Looking at sage's own patches for their matplotlib package, I see nothing 
relevant that suggests they are forcing latex specifically. Neither do I see 
anything relevant in Debian's matplotlib package forcing non-latex:

- https://git.sagemath.org/sage.git/tree/build/pkgs/matplotlib
- https://sources.debian.org/src/matplotlib/2.1.1-2/debian/patches/

We are doing nothing specific in the Debian sagemath package either.

Feel free to investigate further; I am unlikely to do that but would be happy 
to leave this bug open for documentation purposes. Arguably it could be 
reassigned to the python-matplotlib package but I am unsure if it is really 
their issue, or our issue.

X

Jaimos Skriletz wrote:
> Package: sagemath
> Version: 7.4-9
> Severity: minor
> 
> Dear Maintainer,
> 
> In upgrading to stretch from jessie I am trying to switch to using the
> Debian package for sagemath from using the packages from upstream.
> In switching I noticed the following issue:
> 
> I use sagemath, via the notebook(), to mostly draw images and label
> them. For example to label a function I would use something like:
> 
> P = plot( sqrt(4-x), (x,0,4) )
> P += text( r"$y=\sqrt{4-x}$", (3.2,1.5), fontsize=16, color="black" )
> P.show(figsize=[3,3])
> 
> The upstream version of sagemath (either the version pre-compiled for
> Debian 8 or a version I compiled on stretch use the standard LaTeX
> math fonts for formulas, while the Debian package does not.
> Images attached.
> 
> I am not sure if this is an issue with how sagemath was built or a
> configuration option, but I have not been able to figure out how
> to get the Debian package to use the standard LaTeX fonts that
> I am use to.
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#892622: singular: on mips64el, crashes 50% of the time when ASLR is enabled (the default)

[Ximin Luo]

Package: singular
Version: 1:4.1.0-p3+ds-2+b2
Severity: important
Control: affects -1 sagemath

Dear Maintainer,

Singular on mips64el crashes 50% of the time when ASLR is enabled (the default).
If one disables it (by using `setarch $(arch) -R`) then the segfaults go away.

This affects sagemath, but I will add the workaround to it for now.

In order to get a backtrace it is necessary to run `gdb -ex "set 
disable-randomization off" Singular`
as well as install libsingular4-dbgsym singular-modules-dbgsym 
singular-ui-dbgsym.
Then the backtrace looks like this:

(gdb) bt
#0  0x00fff5901e84 in omTakeOutBinPage (bin=, bin=, page=0xfff4be8000) at om_Alloc.c:83
#1  omFreeToPageFault (page=0xfff4be8000, addr=) at 
om_Alloc.c:182
#2  0x00fff5d6d340 in iiConvName (libname=libname@entry=0xfff4be9420 
"standard.lib") at iplib.cc:1352
#3  0x00fff5d6ea5c in iiLibCmd (newlib=0xfff4be9420 "standard.lib", 
autoexport=autoexport@entry=1, tellerror=tellerror@entry=1, 
force=force@entry=1) at iplib.cc:852
#4  0x00fff5d9fd10 in siInit (name=) at misc_ip.cc:1372
#5  0x00aaaf7b7910 in main (argc=, argv=0xb4e1d8) at 
tesths.cc:77

X

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages singular depends on:
ii  singular-data 1:4.1.0-p3+ds-2
ii  singular-modules  1:4.1.0-p3+ds-2+b2
ii  singular-ui   1:4.1.0-p3+ds-2+b2

singular recommends no packages.

singular suggests no packages.

-- no debconf information

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Accepted sagemath 8.1-4 (source) into unstable

[Ximin Luo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 13 Feb 2018 11:28:20 +0100
Source: sagemath
Binary: sagemath sagemath-common sagemath-jupyter sagemath-doc-ca 
sagemath-doc-de sagemath-doc-en sagemath-doc-es sagemath-doc-fr sagemath-doc-hu 
sagemath-doc-it sagemath-doc-ja sagemath-doc-pt sagemath-doc-ru sagemath-doc-tr
Architecture: source
Version: 8.1-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 sagemath   - Open Source Mathematical Software
 sagemath-common - Open Source Mathematical Software - architecture-independent 
file
 sagemath-doc-ca - Open Source Mathematical Software - documentation (Catalan; 
Valen
 sagemath-doc-de - Open Source Mathematical Software - documentation (German)
 sagemath-doc-en - Open Source Mathematical Software - documentation (English)
 sagemath-doc-es - Open Source Mathematical Software - documentation (Spanish; 
Casti
 sagemath-doc-fr - Open Source Mathematical Software - documentation (French)
 sagemath-doc-hu - Open Source Mathematical Software - documentation (Hungarian)
 sagemath-doc-it - Open Source Mathematical Software - documentation (Italian)
 sagemath-doc-ja - Open Source Mathematical Software - documentation (Japanese)
 sagemath-doc-pt - Open Source Mathematical Software - documentation 
(Portuguese)
 sagemath-doc-ru - Open Source Mathematical Software - documentation (Russian)
 sagemath-doc-tr - Open Source Mathematical Software - documentation (Turkish)
 sagemath-jupyter - Open Source Mathematical Software - Jupyter kernel
Changes:
 sagemath (8.1-4) unstable; urgency=medium
 .
   * Bump gf2x build-dependency to pull in fixes for illegal instruction
 on older amd64 and i386 machines.
   * Increase the allowed test failures from 50 up to 62. This is mostly to
 handle certain arches that have 11 extra failures; most arches should
 stay below 50.
 - Generally we have to do this increasing when the versions of the
   Build-Deps in Debian grow newer and further apart from what upstream
   expects; and can reset the number back down to 50 or less when a new
   upstream version is released.
Checksums-Sha1:
 a14a26196a40bcbbd574ea6d2f26cc6721b8c151 6853 sagemath_8.1-4.dsc
 f35220017806285bfaaebdc8e8ad3a7fd0bd4549 87260 sagemath_8.1-4.debian.tar.xz
 b93ce93d98a66646d43d85f9305b204c2de5538d 28293 sagemath_8.1-4_source.buildinfo
Checksums-Sha256:
 31ed952bee4a9e1b17c874453fbbba5c530b84c6e716532e2d0a1298157f5589 6853 
sagemath_8.1-4.dsc
 2df175877694a3c742ca1e0e32dd26121f0e74e1bd55a8fa8eb8298f32813fad 87260 
sagemath_8.1-4.debian.tar.xz
 7c1e853cb614980b027372ec8884e8c8bd1c7979854f5b9ac390c2d101324aaa 28293 
sagemath_8.1-4_source.buildinfo
Files:
 05ec37001244199d4e68ce945947ca0a 6853 math optional sagemath_8.1-4.dsc
 af97062e3b3972496be1bfb2b24211dc 87260 math optional 
sagemath_8.1-4.debian.tar.xz
 b7609369e3ab6b94cb4743fa500c4c79 28293 math optional 
sagemath_8.1-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEENmdIajJtsnZtJVVGhg3vO49lC3kFAlqCvfMVHGluZmluaXR5
MEBkZWJpYW4ub3JnAAoJEIYN7zuPZQt5pR4QAKozqPduXNfhQhAXS7AwuQj13rUf
Jd4vGQPt3uWe4ZCC+5jhkJZjT5xtPH01PCOy8M84X6n4BxqyA63/4uzQ6wlrNeq1
6AqscAAlUISPNrKzJkyZ6gAXU/gJuItz7n38neJUutkqLXVYfZ++yKIUZsbccREn
r3yQVY8nUc8gdo1C9dBz3S1PaEETXR1UyT4WeSPd+jN5mcp15dwuffTPraeUHwvv
V4hB4Ec6lKIJZ1atyFO3qXeUwjtfrFWM7NMhHFNVynks9T+uYX3JvgTTWPttUNC5
7baRwCs8cbfnovJ+fq97eSroYUBceqNTdjUiPSs5G0oUZmnzC9/xyzsvfOSAVuF5
nfuLJZmBpvP+GjHvyaoBikfusTsaq1DZ/jCA6+vleQ0GykF5RsAayRGTPTj6frpe
PJ6dVR5zv/d8Z3GSz+8kOG5260Zr7tkYcj7OJ9oWPc7HtzGnc/AlOtKx2tgZ2XXQ
usijXKSnJp92qERnoUSIS6SM42qOfmi7cKnEYGaNv0PxEOqHDj6d27uap7U46FNE
JEEmtUPiXOyYbgLJE/NCYWgeWqnlJY6MKqt9woDqwiSuTBREw6adJ+okkjf6crlV
HgEbAbdremKGB0dHhm2UUN/xkDyoE6PZU34+7SeIx7cbDnOUPBqHQU/I0nB8cG0G
pVh0+GYuOx493ctp
=+g8J
-END PGP SIGNATURE-


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#890231: sagemath should use gdb, not gdb-python2, to be removed for buster

[Ximin Luo]

Ah, understood regarding gdb-python3.

sagemath uses cysignals-CSI from the cysignals-tools package to print out a 
more detailed backtrace containing native, cython and python code, when tests 
fail. 

cysignals-CSI starts gdb and writes the contents of cysignals-CSI-helper.py [1] 
into gdb. That script does things like "from Cython.Debugger import libpython, 
libcython". If gdb (instead of gdb-python2) is used then this fails with an 
error like:

Traceback (most recent call last):
  File "", line 26, in 
ModuleNotFoundError: No module named 'Cython'
Error while executing Python code.

because currently we only install cython for python2 when building sagemath. 
So, gdb's libpython3 can't find the Cython module.

After replacing gdb with gdb-python2 I get a nice Cython backtrace instead.

X

[1] The Debian package installs this file into 
/usr/lib/python3/dist-packages/cysignals_gdb/cysignals-CSI-helper.py but that 
is a Debian-specific innovation by the package maintainer that is slightly 
misleading; the file is just meant to be read into gdb rather than imported in 
a python program.

Matthias Klose:
> On 12.02.2018 15:41, Ximin Luo wrote:
>> Understood, but the entirety of sagemath is python2 at the moment and 
>> doesn't support python3 (upstream is working on it).
>>
>> What's the timeframe for removal of gdb-python2 and will there be a 
>> gdb-python3 alternative?
> 
> gdb is built using python3.  So maybe there is a misunderstanding, but how 
> does
> sagemath use python for debugging? Does it add it's own pretty printers so 
> that
> it needs python2? How is the gdb usage related to Python2?
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Accepted gf2x 1.2-4 (source) into unstable

[Ximin Luo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 12 Feb 2018 18:26:47 +0100
Source: gf2x
Binary: libgf2x1 libgf2x-dev
Architecture: source
Version: 1.2-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 libgf2x-dev - Routines for fast arithmetic in GF(2)[x] (development files)
 libgf2x1   - Routines for fast arithmetic in GF(2)[x]
Closes: 890254
Changes:
 gf2x (1.2-4) unstable; urgency=medium
 .
   * Team upload.
   * Actually disable HW-specific code also on i386. (Closes: #890254)
Checksums-Sha1:
 358990355ddb56845fbd4ac1011ee81f6262eb89 1994 gf2x_1.2-4.dsc
 177b85d451c395d7b6253639e19ae49f628db6b5 2884 gf2x_1.2-4.debian.tar.xz
 5e0c05609608b45e4617878dc5af4400ba1a93a1 5378 gf2x_1.2-4_source.buildinfo
Checksums-Sha256:
 457d365e70bb761d3deaceec080ef0c0c0f3edb2e16ac4e9728c0d0d65c96e0c 1994 
gf2x_1.2-4.dsc
 cfa4e3ef3de47eb59861f88e0d1f266638d508782e973de3ef7efd0daa53180a 2884 
gf2x_1.2-4.debian.tar.xz
 f3faa3f045f0a3334471cb4a3de114cf0e2484761332e16097953cfadbe66bec 5378 
gf2x_1.2-4_source.buildinfo
Files:
 559fdb5f3bf2e26cd4938d8480117247 1994 math optional gf2x_1.2-4.dsc
 153ed98364e0f8d260df27648cf806dd 2884 math optional gf2x_1.2-4.debian.tar.xz
 dc165518a2aef947c03e39d10e65129e 5378 math optional gf2x_1.2-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEENmdIajJtsnZtJVVGhg3vO49lC3kFAlqBzmEVHGluZmluaXR5
MEBkZWJpYW4ub3JnAAoJEIYN7zuPZQt5QO8P/2u+qGiMI7BCnSz67az7K6XtcLeG
HlTMIXJ3s13C/M1Ch9204s791UEPHRVqSiRC46jlDCPTHo6JfJn22sxhlqP3xoUT
mkmXqXYmbrYtiXyJRWPXRkxHpnpXp76zxAhwZ6sjUD0PI1vIhaLKdbMmJL6BmMML
ZXl6BsTkRYdbBl8j5F7Ouh7uKZoOL+oHsbjaJEJNMokWU/hgTYeGSWYdkQMrjc7f
Uj1KU0exjKBUVT/3wPDZoqmkOKbPw0+4azDEDYLZ3xBu3Zn1WVEM5YIGNiTgR+nJ
qO1QcNRuRzuTimaWiZxtGAVIdqdpZqTGfhJUnNMf5Epie0n42CaSsTV8BsjTO8jn
kiqsR7brbsR5j1vtNIheav0IMkdsLnoXIiiVgvl29Y7aeNgrB3b2fLlNtav+aS0+
yRxdMjop/hWAYbfRBowla34Ib6IMXFYplBSlV6ipO0cvFKZZQtLdvSOWaoQttA7b
zk4bDtAn1dKhv+nU0f+xaqbLz//teTaBioyKqsRxdQM+XVuWt5hrOCPsNOPTdk13
p43Nz2LRqdGRKzOF4yOL7oYyTFqxOWDTarEoOKHEpcYOca7mxn+NGLFMhcfE2aIF
BQbO7XIb0CLxc/wceQRxw6MaMMIY3hdbIT7djZRNcn6IdZU1HOMTUsRqkN01gYUO
TwZVQFV7NC8TFQ4p
=HHwL
-END PGP SIGNATURE-


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Accepted gf2x 1.2-3 (source) into unstable

[Ximin Luo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 12 Feb 2018 14:39:24 +0100
Source: gf2x
Binary: libgf2x1 libgf2x-dev
Architecture: source
Version: 1.2-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 
<debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 libgf2x-dev - Routines for fast arithmetic in GF(2)[x] (development files)
 libgf2x1   - Routines for fast arithmetic in GF(2)[x]
Changes:
 gf2x (1.2-3) unstable; urgency=medium
 .
   * Team upload.
   * Actually disable HW-specific code.
Checksums-Sha1:
 2d86d8c9b4431f8cad4e6f71c3c93d93e37cb7fd 1994 gf2x_1.2-3.dsc
 a5515784abb8bd5c93acf54a0f9e298e9924cb50 2812 gf2x_1.2-3.debian.tar.xz
 137f099499224f1e031b2df45d67bcf0b66fb64d 5378 gf2x_1.2-3_source.buildinfo
Checksums-Sha256:
 263eb544f833418c952eb5455a6dada06eed6af440da195e05275aa78c136163 1994 
gf2x_1.2-3.dsc
 0afb2bb727db50d06dc413a068d378ded428221afc422f687efb65f4811b8b3e 2812 
gf2x_1.2-3.debian.tar.xz
 7fc447ce63dc76a1a744c4d18ff7469247b07aec1a4b2bc6c2da2a356c863cf7 5378 
gf2x_1.2-3_source.buildinfo
Files:
 d083b9cade015a4ade7ca86bc67bdf47 1994 math optional gf2x_1.2-3.dsc
 fe1f36bcb856a2a5fc27efeb3f481a33 2812 math optional gf2x_1.2-3.debian.tar.xz
 e567e86b9ab4378bd5c088d83bc48027 5378 math optional gf2x_1.2-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEENmdIajJtsnZtJVVGhg3vO49lC3kFAlqBmSQVHGluZmluaXR5
MEBkZWJpYW4ub3JnAAoJEIYN7zuPZQt5ktAP/2XD8Rb0CvivVShNmPIY2mlZdQd7
79Yx/InpxiVFmtgxCSfEyjzSndvS4BI76cSBV4WnBknTMQF8Svs3VYH/jlHzIvRx
b1L9BQhtKOqQqr0oM5/dPIU5RPPeO1UoxNmHQHLouGjm2jWrjui8yKx9Ml0sBZV0
631zH27gtriPXAIUfHsyR+DgvRcqKxPb1gu+dt6t7AECYGEwnZpKq0ZjjDga5cxk
lBNEYm1hEiaerzey4UPdJCAOmJwqnM6i1Qkga6cGO/J97Okm9TrOZFIi+94DfN4s
J9AFGEsUUxYmyZA0irbstAhBDWjJ3pHvhxJdCDl+SHPvJ8ZWObohA+ZNpOcOrbfG
g+VNoR11xwbSGl32iAdzF4Lha4e0y488bWknIzxFeNDM2wJyvOt4P9eZFXNNdXfF
gdX2qsUxskz91aI7J7GuY/0EfqtCm9Isrv3Ygl5ZCPGjxgB66ly8US/CEjXElURo
DcI1/mGdqiPfYHK+r3gluCqo8KiS8+eq0YrsQYTARsL3ZAeAMEw2kyqNwiX3OMYJ
x7QjONl9Cm8L+EgPHTQ6y4aQ/nTH4/31o5tvnMnuI87cMhQG739DcmyAlSk9ipeE
pUUq7TMvzaLCGqkWBZE0z77wJ8D9Ln3cQFHxgYc5S99YYnbdPgQRFZMXdSWwapW3
I5BxZFPuOPvkU5Iy
=ysIZ
-END PGP SIGNATURE-


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#890231: sagemath should use gdb, not gdb-python2, to be removed for buster

[Ximin Luo]

Understood, but the entirety of sagemath is python2 at the moment and doesn't 
support python3 (upstream is working on it).

What's the timeframe for removal of gdb-python2 and will there be a gdb-python3 
alternative?

X

Matthias Klose:
> Package: src:sagemath
> Version: 8.2-3
> Severity: important
> Tags: sid buster
> 
> sagemath should use gdb, not gdb-python2, to be removed for buster.  Please
> don't introduce new python2 (build) dependencies.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#890254: control

[Ximin Luo]

Control: fixed -1 1.2-3

Already fixed there, version in stretch still affected.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> Ximin Luo:
>> Julien Puydt:
>>> Le 19/10/2017 à 22:24, Ximin Luo a écrit :
>>>
>>>> I fixed things in git by removing MAKEFLAGS and rewriting d/rules to do 
>>>> the previous stuff in a cleaner way. I've rebuilt all of the reverse 
>>>> dependencies () and they all succeeded including tests. So I think we're 
>>>> good to go ahead with the transition, whenever Julien is ready.
>>>
>>> Can you remind me what you want to transition exactly? I think most of
>>> my packages related to debian-science are up to date in git ; they
>>> should just need sponsorship to experimental...
>>>
>>
>> We'd like to transition NTL to version 10.5.0, it's been sitting at 9.9.1 
>> for too long. It shouldn't need any source uploads (except NTL itself), we 
>> just need to request a transition slot to do binary-only rebuilds from the 
>> release team:
>>
>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>>
>> I can sponsor your upload once you feel 10.5.0 is ready, just let me know. 
>> (Perhaps now would be a good time to make it multi-arch compatible? Not sure 
>> how hard it is, upstream does not seem to do it explicitly.)
>>
> 
> I've uploaded this to experimental, it's sitting in NEW.
> 

Transition is being tracked here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886319

For some reason singular and sagemath rebuilds have been scheduled before 
flint's rebuilds completed, so they are failing due to pulling in both libnt27 
(via the old flint) and libntl35 (via the rebuilt flint). I've noted this on 
the bug report. Hopefully the release team will fix this by themselves.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> Le 19/10/2017 à 22:24, Ximin Luo a écrit :
>>
>>> I fixed things in git by removing MAKEFLAGS and rewriting d/rules to do the 
>>> previous stuff in a cleaner way. I've rebuilt all of the reverse 
>>> dependencies () and they all succeeded including tests. So I think we're 
>>> good to go ahead with the transition, whenever Julien is ready.
>>
>> Can you remind me what you want to transition exactly? I think most of
>> my packages related to debian-science are up to date in git ; they
>> should just need sponsorship to experimental...
>>
> 
> We'd like to transition NTL to version 10.5.0, it's been sitting at 9.9.1 for 
> too long. It shouldn't need any source uploads (except NTL itself), we just 
> need to request a transition slot to do binary-only rebuilds from the release 
> team:
> 
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 
> I can sponsor your upload once you feel 10.5.0 is ready, just let me know. 
> (Perhaps now would be a good time to make it multi-arch compatible? Not sure 
> how hard it is, upstream does not seem to do it explicitly.)
> 

I've uploaded this to experimental, it's sitting in NEW.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs

[Ximin Luo]

Control: notfixed -1 8.0-5
Control: reopen -1
Control: severity -1 minor

You're right. I knew that we split the docbuild away (I did that, even) but I 
thought that the tests passing indicated that the bug was fixed.

However I tried a full build on another ppc64el machine just now, and it seems 
that the problem is indeed specific to building the docs.

[dochtml] ImportError: /usr/lib/powerpc64le-linux-gnu/libgomp.so.1: cannot 
allocate memory in static TLS block

but the tests run OK, as they do on the buildds. In that case, I'll reopen the 
bug, but set the severity to minor.

X

Tobias Hansen:
> Just for the record, this was fixed by building the documentation only in the 
> indep build. Building the documentation on these architectures will probably 
> still fail, but I agree that the bug can be closed.
> 
> Best, Tobias
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881218: sagemath: notebook() Worksheet Process Users not working

[Ximin Luo]

On Wed, 8 Nov 2017 14:35:11 -0700 Jaimos Skriletz  
wrote:
> Package: sagemath
> Version: 7.4-9
> Severity: normal
> 
> Dear Maintainer,
> 
> In upgrading to stretch from jessie I am trying to switch to using the
> Debian package for sagemath from using the packages from upstream.
> In switching I noticed the following issue:
> 
> I was using sagemath with a single Worksheet Process User, so
> worksheets were run on my system as a user with limited privileges. I
> have this configured to use with ssh keys and it works as expected
> using the package from upstream.
> 
> When I set a Worksheet Process User with the Debian package, either
> with notebook(server_pool=["sagenb@localhost"]) or configuring it
> using the web UI under server settings, I am not able to use the
> worksheets. In this case no matter what I ask sagemath to do I get the
> error that the _interact_ function is not defined.
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "_sage_input_3.py", line 8, in 
> _interact_.SAGE_CELL_ID=29
> NameError: name '_interact_' is not defined
> 

Hi Jaimos, it sounds like this problem:

https://stackoverflow.com/questions/40732874/sage-notebook-server-error-when-not-logged-in-to-host
https://unix.stackexchange.com/questions/338747/errors-in-process-running-in-screen-session-while-not-logged-in

However I'm not sure why "it works as expected using the package from upstream" 
for you - but perhaps you can figure this out from the details in the above 
links.

Let us know if we need to change something on the Debian side. If I don't hear 
anything, I'll assume everything's fine and close this bug report in a few 
weeks.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881236: flint-arb: tests fail on amd64 and i386

[Ximin Luo]

Control: reassign -1 src:flint
Control: retitle -1 flint: omits __volatile__ in assembly division, causing 
faulty optimisations
Control: affects -1 src:flint-arb

The bug is in flint not flint-arb, see:

https://gmplib.org/list-archives/gmp-bugs/2017-October/004231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
https://github.com/fredrik-johansson/arb/issues/194

We patched flint on amd64 in Debian as a minimal fix, but the proper fix is 
being discussed with GMP upstream, where flint copied its code from.

I will extend the patch to i386 later today, and close this bug with a new 
flint upload.

X

On Thu, 9 Nov 2017 08:19:27 +0100 Matthias Klose  wrote:
> Package: src:flint-arb
> Version: 2.11.1-1
> Severity: serious
> Tags: sid buster
> 
> The x86* builds fail with:
> 
> make[3]: Leaving directory '/<>/dlog'
> make[3]: Entering directory '/<>/arb_fmpz_poly'
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include test/t-evaluate_acb.c
> -o ../build/arb_fmpz_poly/test/t-evaluate_acb -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-evaluate_acb.d -MT
> "../build/arb_fmpz_poly/test/t-evaluate_acb" -MT
> "../build/arb_fmpz_poly/test/t-evaluate_acb.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include
> test/t-gauss_period_minpoly.c -o
> ../build/arb_fmpz_poly/test/t-gauss_period_minpoly -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF 
> ../build/arb_fmpz_poly/test/t-gauss_period_minpoly.d
> -MT "../build/arb_fmpz_poly/test/t-gauss_period_minpoly" -MT
> "../build/arb_fmpz_poly/test/t-gauss_period_minpoly.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include 
> test/t-complex_roots.c
> -o ../build/arb_fmpz_poly/test/t-complex_roots -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-complex_roots.d -MT
> "../build/arb_fmpz_poly/test/t-complex_roots" -MT
> "../build/arb_fmpz_poly/test/t-complex_roots.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include test/t-evaluate_arb.c
> -o ../build/arb_fmpz_poly/test/t-evaluate_arb -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-evaluate_arb.d -MT
> "../build/arb_fmpz_poly/test/t-evaluate_arb" -MT
> "../build/arb_fmpz_poly/test/t-evaluate_arb.d"
> evaluate_acbgauss_period_minpoly../Makefile.subdirs:84: recipe for
> target '../build/arb_fmpz_poly/test/t-gauss_period_minpoly_RUN' failed
> make[3]: *** [../build/arb_fmpz_poly/test/t-gauss_period_minpoly_RUN] Floating
> point exception
> make[3]: *** Waiting for unfinished jobs
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880241: sagenb-export: FTBFS: Test failures

[Ximin Luo]

Control: reassign -1 src:testpath
Control: retitle -1 testpath does not install .egg-info or .dist-info, making 
it invisible to pip
Control: affects -1 sagenb-export

The sagenb-export FTBFS is caused by the python "testpath" module not 
installing a .egg-info file (or .dist-info directory) which makes it invisible 
to pip. It then tries downloading testpath from the internet, causing the below 
error.

Upstream testpath uses their own custom tool "flit" to generate a .dist-info 
directory - which you can see the contents of by running `pip install testpath` 
then looking in ~/.local/lib/python2.7/site-packages/testpath-0.3.1.dist-info/.

An alternative to packaging flit and then modifying testpath to use flit, would 
be to simply add 
~/.local/lib/python2.7/site-packages/testpath-0.3.1.dist-info/METADATA to our 
Debian packaging and install it in 
/usr/lib/pythonX.Y/dist-packages/testpath-0.3.1.egg-info, etc

X

On Mon, 30 Oct 2017 20:32:00 +0100 Lucas Nussbaum  wrote:
> Source: sagenb-export
> Version: 3.2-3
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20171030 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > r = adapter.send(request, **kwargs)
> >   File 
> > "/<>/.tox/python3/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/adapter.py",
> >  line 47, in send
> > resp = super(CacheControlAdapter, self).send(request, **kw)
> >   File 
> > "/<>/.tox/python3/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/adapters.py",
> >  line 423, in send
> > timeout=timeout
> >   File 
> > "/<>/.tox/python3/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/connectionpool.py",
> >  line 643, in urlopen
> > _stacktrace=sys.exc_info()[2])
> >   File 
> > "/<>/.tox/python3/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
> >  line 315, in increment
> > total -= 1
> > TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'
> > 
> > python3 installed: 
> > bleach==2.0.0,decorator==4.1.2,entrypoints==0.2.3.post1,html5lib==0.9,ipykernel==4.6.1,ipython==5.5.0,ipython-genutils==0.2.0,Jinja2==2.9.6,jsonschema==2.5.1,jupyter-client==5.1.0,jupyter-core==4.3.0,MarkupSafe==1.0,mistune==0.8,nbconvert==5.3.1,nbformat==4.4.0,notebook==4.2.3,pandocfilters==1.4.2,pexpect==4.2.1,pickleshare==0.7.4,pkg-resources==0.0.0,pluggy==0.4.0,prompt-toolkit==1.0.14,py==1.4.34,Pygments==2.2.0,python-dateutil==2.6.1,pyzmq==16.0.2,simplegeneric==0.8.1,six==1.11.0,terminado==0.6,tornado==4.5.1,tox==2.5.0,traitlets==4.3.2,virtualenv==15.1.0,wcwidth==0.1.7,webencodings==0.5
> > ___ summary 
> > 
> > ERROR:   python: InvocationError: /<>/.tox/python/bin/pip 
> > install /<>/.tox/dist/sagenb_export-3.2.zip (see 
> > /<>/.tox/python/log/python-1.log)
> > ERROR:   python3: InvocationError: /<>/.tox/python3/bin/pip 
> > install /<>/.tox/dist/sagenb_export-3.2.zip (see 
> > /<>/.tox/python3/log/python3-1.log)
> > debian/rules:30: recipe for target 'override_dh_auto_test' failed
> 
> The full build log is available from:
>http://aws-logs.debian.net/2017/10/30/sagenb-export_3.2-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.
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> Le 19/10/2017 à 22:24, Ximin Luo a écrit :
> 
>> I fixed things in git by removing MAKEFLAGS and rewriting d/rules to do the 
>> previous stuff in a cleaner way. I've rebuilt all of the reverse 
>> dependencies () and they all succeeded including tests. So I think we're 
>> good to go ahead with the transition, whenever Julien is ready.
> 
> Can you remind me what you want to transition exactly? I think most of
> my packages related to debian-science are up to date in git ; they
> should just need sponsorship to experimental...
> 

We'd like to transition NTL to version 10.5.0, it's been sitting at 9.9.1 for 
too long. It shouldn't need any source uploads (except NTL itself), we just 
need to request a transition slot to do binary-only rebuilds from the release 
team:

https://wiki.debian.org/Teams/ReleaseTeam/Transitions

I can sponsor your upload once you feel 10.5.0 is ready, just let me know. 
(Perhaps now would be a good time to make it multi-arch compatible? Not sure 
how hard it is, upstream does not seem to do it explicitly.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> [..]
> 
> I fixed things in git by removing MAKEFLAGS and rewriting d/rules to do the 
> previous stuff in a cleaner way. I've rebuilt all of the reverse dependencies 
> () and they all succeeded including tests. So I think we're good to go ahead 
> with the transition, whenever Julien is ready.
> 

To be clear, the issue and fix are to the NTL Debian packaging, FLINT does not 
need any fixes, and NTL upstream does not need any fixes (AFAICT). The 
reverse-dependencies I rebuilt are:

eclib flint giac linbox singular pynac

(I did not rebuild sagemath yet.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> 
> 
> Le 01/09/2017 à 00:03, Ximin Luo a écrit :
>> Thanks for that. I forced the rebuild to continue by skipping the flint 
>> tests with DEB_BUILD_OPTIONS=nocheck sbuild --profiles=nocheck , and am 
>> pleased to report that singular and pynac built (including tests) 
>> successfully.
> 
> That is good news, but since FLINT saw problems, they may be hidden.
> 
>> If the flint maintainer doesn't fix this "soon" then perhaps we can just 
>> disable that one test for the short-term to allow this transition to go 
>> forward.
> 
> I'm not sure it is a good idea to push things forward: Bill (main
> developer) said those tests only pass data to NTL, let it do the
> calculation and get the result back. If those conversions are
> problematic, the root can be:
> - NTL changed something and it wasn't intentional, so NTL will need a fix ;
> - NTL changed something and it was intentional, so FLINT will need a fix.
> 
> In either case, there is a good chance that this change will break
> things also higher up the stack : FLINT is just an early warning sign,
> and ignoring it is wrong.
> 
> I suggest to wait for a diagnosis before planning anything.
> 

Your cautiousness was well-placed, I think I nailed down the cause and fixed 
it. It was actually very serious.

I did not drill down into the *exact* underlying cause but saw enough to be 
fairly certain it was due to MAKEFLAGS plus incompletely-declared dependencies 
in d/rules. Those interested can read "recursive Make considered harmful" for a 
description of the generic problem. 

In summary, when you incompletely-duplicate dependency declarations from child 
Makefiles, the top-level make process (here, the one running debian/rules) does 
not have enough dependency information to always correctly determine the order 
in which targets should be rebuilt. Sometimes this gets overlooked because 
compilation "looks like" it worked but actually things were miscompiled (I 
admit I don't know the exact details of how the binary stuff works on this 
level). These errors are much more likely when running builds in parallel, 
because here make will aggressively parallelise non-dependent targets, so if 
two targets actually do depend on each other in the child Makefiles but you 
didn't declare this in the top-level Makefile, you get screwed.

Several observations pointed to this as being the culprit, e.g. rebuilding NTL 
using `dpkg-buildpackage -J1` or `debian/rules build && fakeroot debian/rules 
binary` directly (with no DEB_BUILD_OPTIONS=parallel=X in the env) would make 
the FLINT test failures go away.

I fixed things in git by removing MAKEFLAGS and rewriting d/rules to do the 
previous stuff in a cleaner way. I've rebuilt all of the reverse dependencies 
() and they all succeeded including tests. So I think we're good to go ahead 
with the transition, whenever Julien is ready.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#875611: sagenb: ruby-compass obsolete and now broken

[Ximin Luo]

Control: tags -1 + pending

On Tue, 12 Sep 2017 18:04:56 +0200 Jonas Smedegaard  wrote:
> [..]> 
> Attached is a patch to make Sagenb use sassc with separately maintained
> stylesheets.  It needs to wait until the stylesheets have been approved,
> though: Is in NEW queue now:
> https://ftp-master.debian.org/new/sass-stylesheets-compass_0.12.10-1.html
> 
> Please consider doing above fix, and accept my apology for rushing things.
> [..]

Thanks for the patch! I've applied it in git. Please ping me when 
sass-stylesheets-compass passes NEW and I'll upload sagenb again.

X

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#875465: sagemath: FTBFS on arm64: partitions doctests fail

[Ximin Luo]

Control: severity -1 important

The previous build success was an accident, I raised the ignore-test-failures 
threshold too high. These combinat tests that you mention, also failed in the 
"successful build". Further, that build did not get a chance to migrate to 
Debian testing, so it can effectively be disregarded for Debian release 
purposes.

Upstream are spending a minor amount of effort on fixing these issues but until 
this is complete, I think it's best to avoid shipping arm64 sagemath on Debian. 
Downgrading the severity for now.

(FWIW ppc64el seems to be fine and has the same number of test failures as 
amd64.)

X

On Mon, 11 Sep 2017 11:08:41 -0400 "Aaron M. Ucko"  wrote:
> Source: sagemath
> Version: 8.0-7
> Severity: serious
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> 
> The latest arm64 build of sagemath encountered errors in two
> sage.combinat.partitions.* doctests, as detailed at
> https://buildd.debian.org/status/fetch.php?pkg=sagemath=arm64=8.0-7=1505101830=0
> 
>   2 items had failures:
> 10 of  26 in sage.combinat.partitions.number_of_partitions
>  1 of   3 in sage.combinat.partitions.run_tests
>   [35 tests, 11 failures, 8.05 s]
> 
> 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
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> Hi,
> 
>> [..]
> 
> I could reproduce the matter, asked upstream if it was known, and since
> it wasn't:
> https://github.com/wbhart/flint2/issues/372
> 

Thanks for that. I forced the rebuild to continue by skipping the flint tests 
with DEB_BUILD_OPTIONS=nocheck sbuild --profiles=nocheck , and am pleased 
to report that singular and pynac built (including tests) successfully.

If the flint maintainer doesn't fix this "soon" then perhaps we can just 
disable that one test for the short-term to allow this transition to go forward.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> [..]
>> 
>> I still pushed this work-in-progress, as it should be good enought for
>> some tests already.
>>
> 
> I will have a go at testing it tomorrow/soon. Thanks!
> 

eclib, giac, linbox succeeded but flint fails:

[..]
make[3]: Entering directory '/<>'
g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -I/<> -c 
interfaces/NTL-interface.cpp -o build/interfaces/NTL-interface.o
g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -I/<> 
interfaces/test/t-NTL-interface.cpp build/interfaces/NTL-interface.o -o 
build/interfaces/test/t-NTL-interface -L/<> -L/usr/local/lib 
-L/usr/local/lib -L/usr/local/lib -lflint -lmpfr -lgmp -lm -lntl -lpthread 
make[3]: Leaving directory '/<>'
ZZ_to_fmpzPASS
ZZX_to_fmpz_polyPASS
ZZ_pX_to_fmpz_mod_polyPASS
ZZ_pE_to_fqPASS
ZZ_pEX_to_fq_polyPASS
zz_pX_to_fmpz_mod_polyFAIL:
f_poly1 = 61 40559  2065 31588 35949 5581 18565 23027 17733 40355 21583 29748 
34876 9541 13193 37235 25453 21973 26716 1397 32001 6909 21509 13786 20347 3693 
31431 1471 14890 19641 12608 1894 24849 8969 15639 30973 20096 8110 30791 35078 
29416 16789 35010 10460 34287 20737 768 35601 22276 17792 3619 10427 1950 5016 
21067 39969 274 29530 39547 13397 8480 1868 19224
f_poly2 = 61 40559  -19790727 -303309173 -345202259 -53532299 -178238240 
-221104641 -170248949 -387500890 -207234907 -285627289 -334901346 -91572681 
-126652564 -357530909 -244383081 -210965945 -256508959 -13342514 -307283542 
-66307056 -206504919 -132330231 -195352356 -35404314 -301808647 -14072502 
-142955585 -188579709 -121015448 -18127979 -238583748 -86097788 -150133779 
-297388174 -192959626 -77824611 -295644319 -336847976 -282464019 -161164677 
-336158541 -100413624 -329223675 -199083394 -7299852 -341836210 -213885890 
-170816716 -34714885 -100089185 -18655190 -48097958 -202287225 -383810407 
-2554943 -283558998 -379754929 -128599192 -81393433 -17884651 -184564785
zz_pE_to_fqFAIL:
p = 31
mod = x^2+19*x+12
f1 = 20*a+16 - 2
zzpe:[-418 -538]
f2 = -538*a-418 - 2
zz_pEX_to_fq_polyAborted
Makefile:211: recipe for target 'check' failed
make[2]: *** [check] Error 134
[..]

I did not yet try singular or pynac because they depend on flint.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> Hi,
>>
>> Le 29/08/2017 à 14:25, Tobias Hansen a écrit :
>>> Now is a good time for the NTL transition. Julien, could you update the
>>> package to 10.3.0? Then we can test-build the reverse dependencies and
>>> ask for a transition.
>>
>> Indeed there was a soname version bump from 27 to 35, so a transition is
>> in order.
>>
>> There also was a change of license, so I changed d/copyright -- I would
>> be glad if someone could check the result.
>>
>> Finally, lintian complains about hardening-no-fortify-functions and
>> hardening-no-bindnow, which means there's more digging to do for me.
>>
> 
> I'd ignore both:
> 
> 1. hardening-no-fortify-functions happens naturally when the library does not 
> use any libc functions that change under -D_FORTIFY_SOURCE=2 and this is 
> probably a false positive
> 
> 2. hardening-no-bindnow is just due to dpkg-buildflags not defaulting that to 
> on. If you really want to fix it you can
> 
> export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
> 
> but IMO this is better fixed in dpkg-buildflags itself as a matter of Debian 
> policy.
> 
>> I still pushed this work-in-progress, as it should be good enought for
>> some tests already.
>>
> 
> I will have a go at testing it tomorrow/soon. Thanks!
> 

BTW, please don't forget about the other bug involving gf2x, #872711

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> Hi,
> 
> Le 29/08/2017 à 14:25, Tobias Hansen a écrit :
>> Now is a good time for the NTL transition. Julien, could you update the
>> package to 10.3.0? Then we can test-build the reverse dependencies and
>> ask for a transition.
> 
> Indeed there was a soname version bump from 27 to 35, so a transition is
> in order.
> 
> There also was a change of license, so I changed d/copyright -- I would
> be glad if someone could check the result.
> 
> Finally, lintian complains about hardening-no-fortify-functions and
> hardening-no-bindnow, which means there's more digging to do for me.
> 

I'd ignore both:

1. hardening-no-fortify-functions happens naturally when the library does not 
use any libc functions that change under -D_FORTIFY_SOURCE=2 and this is 
probably a false positive

2. hardening-no-bindnow is just due to dpkg-buildflags not defaulting that to 
on. If you really want to fix it you can

export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow

but IMO this is better fixed in dpkg-buildflags itself as a matter of Debian 
policy.

> I still pushed this work-in-progress, as it should be good enought for
> some tests already.
> 

I will have a go at testing it tomorrow/soon. Thanks!

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#872259: sagemath: FTBFS with Sphinx 1.6: TypeError: frompickle() takes exactly 3 arguments (4 given)

[Ximin Luo]

Control: tags -1 + upstream
Control: forwarded -1 https://trac.sagemath.org/ticket/23023

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#872711: ntl: Please link against gf2x

[Ximin Luo]

Source: ntl
Version: 9.9.1-3
Severity: wishlist

Dear Maintainer,

NTL has the ability to link against the gf2x library, but the current version
in Debian does not seem to do so:
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgmp10, libstdc++6 (>= 5.2)

Sage uses NTL with gf2x, as follows:
https://git.sagemath.org/sage.git/tree/build/pkgs/ntl/spkg-install#n112
NTL_GF2X_LIB=on

For some reason Debian switches this off:
https://anonscm.debian.org/cgit/debian-science/packages/libntl.git/tree/debian/rules#n28
NTL_GF2X_LIB=off

This was done back in 2011:
https://anonscm.debian.org/cgit/debian-science/packages/libntl.git/commit/debian/rules?id=bac15db8073856e14e20eaecdc5423eaf404cdc8
but I don't see a particular reason for it, so it would be good if it were 
fixed.

X

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870688: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

Ximin Luo:
> -#869778
> 
> Ximin Luo:
>> [..]
>>
>> Hi, I see that libgsl23 was uploaded but who is taking care of the library 
>> transition? It seems that this process was not followed:
>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>>
>> The transition tracker detected the library change:
>> https://release.debian.org/transitions/html/auto-gsl.html
>>
>> However there is no corresponding Transition Tracking bug report:
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org
>>
>> Currently this prevents me from doing test builds of sagemath, because some 
>> of its build dependencies are not installable [..]
>>
> 
> As a temporary workaround:
> 
> $ aptitude search '~Dlibgsl2$ ~R^sagemath$ ~rnative' --disable-columns
> p  python-cvxopt - Python package for convex optimization 
>  
> p  xcas - Computer Algebra System - console and graphical calculator
> 
> Since this list is quite small, I've done my own binNMUs of these packages 
> (using sbuild --binNMU etc) and uploaded them to deb-sci-sage. This makes 
> `debian/rules release-deb-sci-sage` work again, I'll run it properly in the 
> morning and report the results.
> 

8.0-0~sage1 built and uploaded! 
https://debian-science.alioth.debian.org/apt/sid-sage/

--
sage -t --long src/sage/geometry/polyhedron/backend_cdd.py  # 1 doctest failed
sage -t --long src/sage/interfaces/giac.py  # 7 doctests failed
sage -t --long src/sage/interfaces/gap.py  # 1 doctest failed
sage -t --long src/sage/libs/gap/all_documented_functions.py  # 1 doctest failed
sage -t --long src/sage/libs/gap/assigned_names.py  # 1 doctest failed
sage -t --long src/sage/libs/ppl.pyx  # Timed out after testing finished
sage -t --long src/sage/misc/compat.py  # 1 doctest failed
sage -t --long src/sage/misc/fast_methods.pyx  # 1 doctest failed
sage -t --long src/sage/misc/weak_dict.pyx  # 1 doctest failed
sage -t --long src/sage/numerical/backends/glpk_backend.pyx  # 1 doctest failed
sage -t --long src/sage/numerical/optimize.py  # 5 doctests failed
sage -t --long src/sage/parallel/use_fork.py  # 1 doctest failed
sage -t --long src/sage/plot/arrow.py  # 1 doctest failed
sage -t --long src/sage/plot/plot.py  # 1 doctest failed
sage -t --long src/sage/probability/probability_distribution.pyx  # 1 doctest 
failed
sage -t --long src/sage/repl/interpreter.py  # 1 doctest failed
sage -t --long src/sage/repl/rich_output/backend_ipython.py  # 1 doctest failed
sage -t --long src/sage/rings/number_field/number_field.py  # 1 doctest failed
sage -t --long src/sage/rings/number_field/unit_group.py  # 1 doctest failed
sage -t --long src/sage/rings/polynomial/polynomial_quotient_ring.py  # 8 
doctests failed
sage -t --long src/sage/tests/cython.pyx  # 1 doctest failed
sage -t --long src/sage/tests/cmdline.py  # 6 doctests failed
--

Requires binNMU-rebuilt cvxopt, giac (against libgsl23), plus new source 
uploads of fplll, fpylll, givaro, and a cypari2 that is going through NEW.

As soon as cypari2 passes NEW I think it is OK to upload all of those other 
packages to unstable, then we can fix the failing tests later.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870688: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

-#869778

Ximin Luo:
> [..]
> 
> Hi, I see that libgsl23 was uploaded but who is taking care of the library 
> transition? It seems that this process was not followed:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 
> The transition tracker detected the library change:
> https://release.debian.org/transitions/html/auto-gsl.html
> 
> However there is no corresponding Transition Tracking bug report:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org
> 
> Currently this prevents me from doing test builds of sagemath, because some 
> of its build dependencies are not installable [..]
> 

As a temporary workaround:

$ aptitude search '~Dlibgsl2$ ~R^sagemath$ ~rnative' --disable-columns
p  python-cvxopt - Python package for convex optimization   
   
p  xcas - Computer Algebra System - console and graphical calculator

Since this list is quite small, I've done my own binNMUs of these packages 
(using sbuild --binNMU etc) and uploaded them to deb-sci-sage. This makes 
`debian/rules release-deb-sci-sage` work again, I'll run it properly in the 
morning and report the results.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870688: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

Control: block 870688 by 869778
Control: affects 869778 + sagemath

Ximin Luo:
> Tobias Hansen:
>> [..]
>>
>> 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.
>>
>> [..]
> 
> Hi, I'm at DebConf over the next week and will very likely be able to find 
> some time to deal with this.
> 

Hi, I see that libgsl23 was uploaded but who is taking care of the library 
transition? It seems that this process was not followed:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

The transition tracker detected the library change:
https://release.debian.org/transitions/html/auto-gsl.html

However there is no corresponding Transition Tracking bug report:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org

Currently this prevents me from doing test builds of sagemath, because some of 
its build dependencies are not installable:

[..]
cd .. && sbuild \
  --extra-repository='deb http://httpredir.debian.org/debian experimental main' 
\
  --chroot-setup-commands='apt-get install -y apt-transport-https' \
  --extra-repository='deb https://debian-science.alioth.debian.org/apt 
sid-sage/' \
  
--extra-repository-key=/home/infinity0/var/lib/sage/sagemath/debian/deb-sci-sage.asc
 \
  --build-dep-resolver=aspcud \
  --build-failed-commands '%SBUILD_SHELL' \
   \
  "sagemath_8.0-0~sage1.dsc"
[..]
(I)Distcheck: Solving...
output-version: 1.2
native-architecture: amd64
report:
 -
  package: sbuild-build-depends-sagemath-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: libgslcblas0
  version: 2.4+dfsg-5
  architecture: amd64
  unsat-conflict: libgsl2:amd64
 pkg2:
  package: libgsl2
  version: 2.4+dfsg-2
  architecture: amd64
 depchain1:
  -
   depchain:
-
 package: sbuild-build-depends-sagemath-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libgsl-dev:amd64
-
 package: libgsl-dev
 version: 2.4+dfsg-5
 architecture: amd64
 depends: libgslcblas0:amd64 (= 2.4+dfsg-5)
 depchain2:
  -
   depchain:
-
 package: sbuild-build-depends-sagemath-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: python-cvxopt:amd64
-
 package: python-cvxopt
 version: 1.1.9+dfsg-1+b1
 architecture: amd64
 depends: libgsl2:amd64
[..]

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870698: [Debian-science-sagemath] Possible fix for fplll/fpylll issue with default strategy path

[Ximin Luo]

Ximin Luo:
> Ximin Luo:
>> Julien Puydt:
>>> Hi,
>>>
>>> I just pushed to fplll's Debian git repository a tentative 5.1.0-3 which
>>> would fix the recently reported issue with fpylll : I rewrote the patch
>>> for the default strategies path changes.
>>>
>>> I'm a bit at loss on how to check if that really fixes anything : I
>>> tried to build fpylll (success), but then trying to "import fpylll" in
>>> python gave:
>>> RuntimeError: You must get the file local/bin/sage-maxima.lisp
>>>
>>> so I can't really test seriously...
>>>
>>
>> I can reproduce this, it works if you uninstall sage (but of course we have 
>> to fix it properly).
>>
>> The underlying issue is caused by the fact that Sage sets things like 
>> SAGE_LOCAL outside of python itself, so that one gets e.g.:
>>
>> $ python -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
>> print(SAGE_SCRIPTS_DIR)'
>> $SAGE_LOCAL/bin
>> $ sage -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
>> print(SAGE_SCRIPTS_DIR)'
>> /usr/share/sagemath/bin
>>
>> I would guess that this also affects upstream Sage, but perhaps the issue is 
>> hidden somehow (Debian uses a different "sage-env" shell script).
>>
> 
> So for example this works, with sage installed:
> 
> $ SAGE_LOCAL=/usr SAGE_SCRIPTS_DIR=/usr/share/sagemath/bin python -c "import 
> fpylll"
> # no errors, exit code 0
> 
> Now the question is, does Sage always expect that itself should be run via 
> the "sage" program, with particular envvars set? 
> 
> If yes, then fpylll should run the "sage" version of itself after detecting 
> the presence of these envvars - a simple "try: import sage; except 
> ImportError" is not enough.
> 

I've pushed a slightly simpler fix to our git and opened a PR here: 
https://github.com/fplll/fpylll/pull/97

Also have built+uploaded fplll/fpylll to deb-sci-sage. Please upload them to 
sid & close this bug report when you are ready!

> If no (i.e. "import sage" etc should work in a plain python program), then 
> sage should put its own "sage-env" shell script logic, into the "sage.env" 
> python module instead, so that it gets run properly when things like "from 
> sage.env import *" are done by third-party libs/programs. (And we in Debian 
> would patch this logic for Debian paths.)
> 
> In both cases, this should be documented somewhere upstream in the Sage 
> source code / documentation.
> 
> François & Jeroen (and any other Sage devs here), what do you think? Shall I 
> file an upstream trac ticket about this?
> 
> (In any case, I think the fplll/fpylll bug is fixed, and we can upload + 
> close #870698).
> 
X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870698: [Debian-science-sagemath] Possible fix for fplll/fpylll issue with default strategy path

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> Hi,
>>
>> I just pushed to fplll's Debian git repository a tentative 5.1.0-3 which
>> would fix the recently reported issue with fpylll : I rewrote the patch
>> for the default strategies path changes.
>>
>> I'm a bit at loss on how to check if that really fixes anything : I
>> tried to build fpylll (success), but then trying to "import fpylll" in
>> python gave:
>> RuntimeError: You must get the file local/bin/sage-maxima.lisp
>>
>> so I can't really test seriously...
>>
> 
> I can reproduce this, it works if you uninstall sage (but of course we have 
> to fix it properly).
> 
> The underlying issue is caused by the fact that Sage sets things like 
> SAGE_LOCAL outside of python itself, so that one gets e.g.:
> 
> $ python -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
> print(SAGE_SCRIPTS_DIR)'
> $SAGE_LOCAL/bin
> $ sage -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
> print(SAGE_SCRIPTS_DIR)'
> /usr/share/sagemath/bin
> 
> I would guess that this also affects upstream Sage, but perhaps the issue is 
> hidden somehow (Debian uses a different "sage-env" shell script).
> 

So for example this works, with sage installed:

$ SAGE_LOCAL=/usr SAGE_SCRIPTS_DIR=/usr/share/sagemath/bin python -c "import 
fpylll"
# no errors, exit code 0

Now the question is, does Sage always expect that itself should be run via the 
"sage" program, with particular envvars set? 

If yes, then fpylll should run the "sage" version of itself after detecting the 
presence of these envvars - a simple "try: import sage; except ImportError" is 
not enough.

If no (i.e. "import sage" etc should work in a plain python program), then sage 
should put its own "sage-env" shell script logic, into the "sage.env" python 
module instead, so that it gets run properly when things like "from sage.env 
import *" are done by third-party libs/programs. (And we in Debian would patch 
this logic for Debian paths.)

In both cases, this should be documented somewhere upstream in the Sage source 
code / documentation.

François & Jeroen (and any other Sage devs here), what do you think? Shall I 
file an upstream trac ticket about this?

(In any case, I think the fplll/fpylll bug is fixed, and we can upload + close 
#870698).

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870698: [Debian-science-sagemath] Possible fix for fplll/fpylll issue with default strategy path

[Ximin Luo]

Julien Puydt:
> Hi,
> 
> I just pushed to fplll's Debian git repository a tentative 5.1.0-3 which
> would fix the recently reported issue with fpylll : I rewrote the patch
> for the default strategies path changes.
> 
> I'm a bit at loss on how to check if that really fixes anything : I
> tried to build fpylll (success), but then trying to "import fpylll" in
> python gave:
> RuntimeError: You must get the file local/bin/sage-maxima.lisp
> 
> so I can't really test seriously...
> 

I can reproduce this, it works if you uninstall sage (but of course we have to 
fix it properly).

The underlying issue is caused by the fact that Sage sets things like 
SAGE_LOCAL outside of python itself, so that one gets e.g.:

$ python -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
print(SAGE_SCRIPTS_DIR)'
$SAGE_LOCAL/bin
$ sage -c 'from sage.env import DOT_SAGE, SAGE_SCRIPTS_DIR; 
print(SAGE_SCRIPTS_DIR)'
/usr/share/sagemath/bin

I would guess that this also affects upstream Sage, but perhaps the issue is 
hidden somehow (Debian uses a different "sage-env" shell script).

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870688: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

Tobias Hansen:
> [..]> 
> 
> 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.
> 
> [..]

Hi, I'm at DebConf over the next week and will very likely be able to find some 
time to deal with this.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: [Debian-science-sagemath] patch proposal

[Ximin Luo]

whoops, I forgot to CC Frédéric, the Debian BTS does not do this automatically. 
:( see my message below:

Ximin Luo:
> On Tue, 11 Jul 2017 13:24:02 +0200 Frédéric Bonnard 
> <fre...@linux.vnet.ibm.com> wrote:
>> Tags: patch
>> User: debian-powe...@lists.debian.org
>> Usertags: ppc64el 
>>
>> --
>>
>> Hi,
>> it just seems that there's too many space taken by different libraries
>> in the static TLS space. I contacted some people from the toolchain,
>> especially Alan Modra which seems to confirm that :
>> "If sagemath is dlopen'ing libraries, one of which is libgomp or has a
>> dependency on libgomp, and the sagemath executable itself does not load
>> libgomp at startup, then that would explain the error you're seeing."
>> Python binary has no direct dependency on libgomp :
>> $ lddtree /usr/bin/python2.7
>> python2.7 => /usr/bin/python2.7 (interpreter => /lib64/ld64.so.2)
>> libpthread.so.0 => /lib/powerpc64le-linux-gnu/libpthread.so.0
>> ld64.so.2 => /lib64/ld64.so.2
>> libdl.so.2 => /lib/powerpc64le-linux-gnu/libdl.so.2
>> libutil.so.1 => /lib/powerpc64le-linux-gnu/libutil.so.1
>> libz.so.1 => /lib/powerpc64le-linux-gnu/libz.so.1
>> libm.so.6 => /lib/powerpc64le-linux-gnu/libm.so.6
>> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
>>
>> And also :
>> sagemath-7.6/sage# LD_DEBUG=files
>> PYTHONPATH=/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages
>> /build/sagemath-wDWVd1/sagemath-7.6/sage/src/bin/sage --docbuild
>> --no-pdf-links all html
>> ...
>> [..]
>> 
>> ...
>> So the failure occurs while importing the python module 
>> matrix_modn_dense_float.so.
>> So I propose to preload libgomp which looks good to Alan.
>>
>> As Ximin explained, this workaround should not be applied on
>> documentation build only, as the import should trigger the error on the
>> CLI as well, thus I inserted LD_PRELOAD export in sage-env, for ppc64el
>> only. So here is a debdiff for you to review.
>> I hope that will help,
>>
>> [..]
> 
> Hi, thanks very much for the investigation and explanation! I am not sure 
> this patch is the best approach however. Also I don't yet completely 
> understand what is wrong, I'm still guessing some things based on your 
> explanation:
> 
> Firstly your patch is for ppc64el but the same error occurs also on arm64 and 
> possibly other platforms - we'll only know for sure, after we get the right 
> Build-Dependencies into Debian on those other platforms.
> 
> I don't think it's a long-term sustainable approach to hardcode 
> architecture-specific exceptions. What *aspect* of ppc64el requires this 
> patch? Am I understanding correctly that dlopen(), for some reason, loads 
> stuff into thread-local-storage (TLS) instead of a shared area between all 
> threads? And that this space is running out on ppc64el (and arm64)? Why 
> doesn't it happen on amd64 / x86_64? This sounds like a bug in dlopen() or 
> the threading library, or something else?
> 
> Even if not, shouldn't it be possible to predict that the space will run out 
> on any platform in a generic way, in order to raise the limit or to do this 
> LD_PRELOAD workaround, in a cross-platform way?
> 
> (For example, on rustc recently we had a nasty issue on ppc64el but the 
> underlying reason was due to interaction between PAGESIZE and newer Linux 
> kernel stack behaviour, and the workaround I wrote was conditioned on 
> PAGESIZE rather than ppc64el specifically.)
> 
> Finally, ideally we would push the patch upstream, though testing it out in 
> Debian first would be good - I think we have easier access to some platforms 
> than upstream does. However I'd expect that the chances of Sage accepting a 
> ppc64el-specific patch are very slim. And this one has a DEB_* variable in.
> 
> X
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: patch proposal

[Ximin Luo]

On Tue, 11 Jul 2017 13:24:02 +0200 Frédéric Bonnard  
wrote:
> Tags: patch
> User: debian-powe...@lists.debian.org
> Usertags: ppc64el 
> 
> --
> 
> Hi,
> it just seems that there's too many space taken by different libraries
> in the static TLS space. I contacted some people from the toolchain,
> especially Alan Modra which seems to confirm that :
> "If sagemath is dlopen'ing libraries, one of which is libgomp or has a
> dependency on libgomp, and the sagemath executable itself does not load
> libgomp at startup, then that would explain the error you're seeing."
> Python binary has no direct dependency on libgomp :
> $ lddtree /usr/bin/python2.7
> python2.7 => /usr/bin/python2.7 (interpreter => /lib64/ld64.so.2)
> libpthread.so.0 => /lib/powerpc64le-linux-gnu/libpthread.so.0
> ld64.so.2 => /lib64/ld64.so.2
> libdl.so.2 => /lib/powerpc64le-linux-gnu/libdl.so.2
> libutil.so.1 => /lib/powerpc64le-linux-gnu/libutil.so.1
> libz.so.1 => /lib/powerpc64le-linux-gnu/libz.so.1
> libm.so.6 => /lib/powerpc64le-linux-gnu/libm.so.6
> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
> 
> And also :
> sagemath-7.6/sage# LD_DEBUG=files
> PYTHONPATH=/build/sagemath-wDWVd1/sagemath-7.6/debian/build/usr/lib/python2.7/dist-packages
> /build/sagemath-wDWVd1/sagemath-7.6/sage/src/bin/sage --docbuild
> --no-pdf-links all html
> ...
> [..]
> 
> ...
> So the failure occurs while importing the python module 
> matrix_modn_dense_float.so.
> So I propose to preload libgomp which looks good to Alan.
> 
> As Ximin explained, this workaround should not be applied on
> documentation build only, as the import should trigger the error on the
> CLI as well, thus I inserted LD_PRELOAD export in sage-env, for ppc64el
> only. So here is a debdiff for you to review.
> I hope that will help,
> 
> [..]

Hi, thanks very much for the investigation and explanation! I am not sure this 
patch is the best approach however. Also I don't yet completely understand what 
is wrong, I'm still guessing some things based on your explanation:

Firstly your patch is for ppc64el but the same error occurs also on arm64 and 
possibly other platforms - we'll only know for sure, after we get the right 
Build-Dependencies into Debian on those other platforms.

I don't think it's a long-term sustainable approach to hardcode 
architecture-specific exceptions. What *aspect* of ppc64el requires this patch? 
Am I understanding correctly that dlopen(), for some reason, loads stuff into 
thread-local-storage (TLS) instead of a shared area between all threads? And 
that this space is running out on ppc64el (and arm64)? Why doesn't it happen on 
amd64 / x86_64? This sounds like a bug in dlopen() or the threading library, or 
something else?

Even if not, shouldn't it be possible to predict that the space will run out on 
any platform in a generic way, in order to raise the limit or to do this 
LD_PRELOAD workaround, in a cross-platform way?

(For example, on rustc recently we had a nasty issue on ppc64el but the 
underlying reason was due to interaction between PAGESIZE and newer Linux 
kernel stack behaviour, and the workaround I wrote was conditioned on PAGESIZE 
rather than ppc64el specifically.)

Finally, ideally we would push the patch upstream, though testing it out in 
Debian first would be good - I think we have easier access to some platforms 
than upstream does. However I'd expect that the chances of Sage accepting a 
ppc64el-specific patch are very slim. And this one has a DEB_* variable in.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

[Ximin Luo]

Edmund Grimley Evans:
>> http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?p=8963#p8963
>>
>> Do you have any suggestions on how to move forward? The easiest option is 
>> just to give the test two possible things to diff against, but this buries 
>> the issue and does not really solve it.
> 
> That looks worrying. It might be a real bug.
> 
> If I've understood correctly, you get different behaviour with and
> without the patch on amd64. But the patch consists of a load of
> independent changes. So, if we can't think of anything else, there's
> the option here of doing a bisection search to find out which hunk of
> the patch causes the difference. (Though it could be more complicated
> I suppose: like whether an odd or even number of hunks are applied...)
> 

Not amd64 but arm64 - the Debian name for aarch64 / armv8. But yes to the other 
parts of what you said. Alright, thanks for the tips, I'll try the bisect when 
I get some time.

Actually there was a paper posted to Hacker News yesterday: 
https://www.st.cs.uni-saarland.de/publications/files/zeller-esec-1999.pdf whose 
algorithm would be perfect for this sort of thing, unfortunately I don't think 
it was released as a piece of executable software :(

> Is -1 cast to a pointer being used as a special value somewhere? That
> value would not survive being packed and unpacked.
> 
>> Another thing now: your robopatch results in the following patch:
>>
>> https://anonscm.debian.org/cgit/debian-science/packages/giac.git/tree/debian/patches/fix-48-bit-addr.patch?id=075cd498f2590ed067e73da827a5cb07b4d1aa5b
>>
>> As you can see, it makes some changes to src/cocoa.cc that are not guarded 
>> by #ifdef SMARTPTR64 conditions. Judging by your perl expression, I guess 
>> this should also be unpatched?
> 
> I think that code in cocoa.cc is wrong either way: (1<<31) is an
> overflow already, whatever you cast it to afterwards. It should
> probably be (1LL<31), and then there's no need to convert it to
> longlong or ulonglong, i.e.: gen p(int((1LL<<31)-1))
> 

I see right, according to the C/C++ standards you shouldn't perform operations 
that require more than 16 bits on these. But I think the existing results that 
we're getting probably wouldn't be affected since they are running on machines 
where ints do have >= 32 bits so it wouldn't be overflowing in practice in 
these cases.

>> Similarly, src/ifactor.cc and the third hunk of src/vecteur.cc should 
>> probably be reverted just for "neatness" purposes, but I don't think this 
>> would have affected any of the results described.
> 
> src/ifactor.cc looks like a false positive: the << is not a shift. So
> revert that.
> 
> Third hunk of vecteur.cc should make no difference either way.
> 
> So I'd recommend trying to discover which part of that patch changes
> the test result on amd64, and maybe it will then be possible to
> understand why...
> 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

[Ximin Luo]

On Thu, 29 Jun 2017 20:40:26 +0100 Edmund Grimley Evans 
 wrote:
> This robopatch seems to fix the problem on arm64 with 48-bit addresses:
> 
> perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ &&
> !/gen\(longlong/;' src/*.cc
> 
> The idea is to change the type whenever there seems to be a cast
> followed by a shift. The last condition is to avoid a couple of
> harmful false positives.
> 
> [..]

Hey Edmund, thanks for all your help with this!

I've tested your robopatch and it works. However, now I'm experiencing this 
issue:

http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?p=8963#p8963

Do you have any suggestions on how to move forward? The easiest option is just 
to give the test two possible things to diff against, but this buries the issue 
and does not really solve it.

Another thing now: your robopatch results in the following patch:

https://anonscm.debian.org/cgit/debian-science/packages/giac.git/tree/debian/patches/fix-48-bit-addr.patch?id=075cd498f2590ed067e73da827a5cb07b4d1aa5b

As you can see, it makes some changes to src/cocoa.cc that are not guarded by 
#ifdef SMARTPTR64 conditions. Judging by your perl expression, I guess this 
should also be unpatched? I tried this, things still work, unfortunately 
chk_fhan16 still fails. But from what I understand of your explanation, it 
would be best to leave this part out of the patch. Is that right?

Similarly, src/ifactor.cc and the third hunk of src/vecteur.cc should probably 
be reverted just for "neatness" purposes, but I don't think this would have 
affected any of the results described.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868347: sagemath-common: /usr/share/sagemath/bin/sage-native-execute: firefox:elinks:w3m: not found

[Ximin Luo]

Control: severity -1 normal
Control: tags -1 moreinfo

Rogério Brito  wrote:
> Package: sagemath-common
> Version: 7.6-2
> Severity: important
> File: /usr/share/sagemath/bin/sage-native-execute
> 
> 
> Hi,
> 
> It seems that sage-native-execute doesn't respect the way that the BROWSER
> variable is set according to the sensible-browser way of working with
> colon-delimited values.
> 
> This breaks the notebook() function of the interpreter of sage.
> 
> [..]

Hi, the contents of that file is merely "$@" so I guess the bug is elsewhere.

Where are you setting BROWSER and why are you expecting that sage should honour 
it? Can you paste a stack trace?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#866166: sagemath: FTBFS with Sphinx 1.5: AttributeError: 'BuildEnvironment' object has no attribute 'citations'

[Ximin Luo]

Control: tags -1 + pending upstream
Control: forwarded -1 https://trac.sagemath.org/ticket/23364

Ximin Luo:
> [..]
> 
> Could you also explain why exactly dh_sphinxdoc checks for these - what 
> functionality is broken because these paths don't exist? I don't see that 
> anyone noticed anything on the Sage upstream ticket 
> https://trac.sagemath.org/ticket/22252 which is already merged, but then 
> again I know that not everybody reads the documentation and checks it for 
> flaws...
> 
> OTOH Sage uses a very custom sphinx build so it's possible that dh_sphinxdoc 
> itself is not doing the right thing for Sage's docs - I remember filing a 
> patch for dh_sphinxdoc for another thing that it was searching for, which for 
> Sage was at a different location than usual. (see #841141)
> 

Thanks for the patch over on IRC! I've applied it in Debian git and forwarded 
it upstream.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#866166: sagemath: FTBFS with Sphinx 1.5: AttributeError: 'BuildEnvironment' object has no attribute 'citations'

[Ximin Luo]

Dmitry Shachnev:
> Hi Ximin!
> 
> On Tue, Jul 04, 2017 at 07:35:00AM +0000, Ximin Luo wrote:
>> I fixed our other issue in git and now I'm seeing these sphinxdoc errors:
>>
>> [..]
>> make[1]: Entering directory '/home/infinity0/var/lib/sage/sagemath'
>> dh_sphinxdoc -XMathJax.js -Xtranslations.js -Xsearchtools.js
>> dh_sphinxdoc: ignoring unknown JavaScript code: 
>> debian/sagemath-doc-ca/usr/share/doc/sagemath/html/ca/intro/_static/thebe-sage.js
>> [..]
>> dh_sphinxdoc: 
>> debian/sagemath-doc-en/usr/share/doc/sagemath/html/en/reference/_sources/lie_algebras.rst.txt
>>  is missing
>> debian/rules:199: recipe for target 'override_dh_sphinxdoc' failed
>> make[1]: *** [override_dh_sphinxdoc] Error 2
>>
>> Dmitry, if we need to further patch Sphinx or Sage, I'd be happy to do that.
>> But what exactly is needed? I'm not sure if I totally understood the ticket
>> you linked:
>>
>> https://github.com/sphinx-doc/sphinx/pull/2454
>>
>> Do we just need to put the equivalent of this:
>>
>> https://github.com/mitya57/matplotlib/commit/53e6bc46d2f010f9a80e0c73dceb6166705f608f
>>
>> into Sage's layout templates?
> 
> No, the problem is not in the templates, the problem is with installation
> layout.
> 
> dh_sphinxdoc (and searchtools.js) expect to to find the source files with the
> following scheme: .../_sources/ + original filename (i.e. lie_algebras.rst) +
> sourcelink_suffix if it is different from the original extension (i.e. .txt).
> 
> Here it fails to find these files. Most probably they are installed without
> the sourcelink_suffix, i.e. .../_sources/lie_algebras.rst instead of
> .../_sources/lie_algebras.rst.txt.
> 

It looks like the .txt suffixes are there, but the problem rather is that we 
have multiple files with the same name installed into different nested 
directories:

$ find debian/tmp/usr/share/doc/ -name lie_algebras.rst*
debian/tmp/usr/share/doc/sagemath/html/en/reference/algebras/_sources/lie_algebras.rst.txt
debian/tmp/usr/share/doc/sagemath/html/en/reference/categories/_sources/sage/categories/lie_algebras.rst.txt
debian/tmp/usr/share/doc/sagemath/html/en/reference/categories/_sources/sage/categories/examples/lie_algebras.rst.txt

The file contents are all different:

$ cat 
debian/tmp/usr/share/doc/sagemath/html/en/reference/algebras/_sources/lie_algebras.rst.txt
 
Lie Algebras


.. toctree::
   :maxdepth: 2

   sage/algebras/lie_algebras/abelian
   sage/algebras/lie_algebras/affine_lie_algebra
   sage/algebras/lie_algebras/classical_lie_algebra
   sage/algebras/lie_algebras/examples
   sage/algebras/lie_algebras/heisenberg
   sage/algebras/lie_algebras/lie_algebra
   sage/algebras/lie_algebras/lie_algebra_element
   sage/algebras/lie_algebras/poincare_birkhoff_witt
   sage/algebras/lie_algebras/structure_coefficients
   sage/algebras/lie_algebras/virasoro

$ cat 
debian/tmp/usr/share/doc/sagemath/html/en/reference/categories/_sources/sage/categories/lie_algebras.rst.txt
.. nodoctest

.. _sage.categories.lie_algebras:

Lie Algebras


.. This file has been autogenerated.


.. automodule:: sage.categories.lie_algebras
   :members:
   :undoc-members:
   :show-inheritance:
   

$ cat 
debian/tmp/usr/share/doc/sagemath/html/en/reference/categories/_sources/sage/categories/examples/lie_algebras.rst.txt
.. nodoctest

.. _sage.categories.examples.lie_algebras:

Examples of a Lie algebra
=

.. This file has been autogenerated.


.. automodule:: sage.categories.examples.lie_algebras
   :members:
   :undoc-members:
   :show-inheritance:

> It looks like it installs using custom code in docbuild/ext/multidocs.py, not
> by enabling the standard Sphinx’ html_copy_source configuration option.
> 
> Unfortunately I cannot test sagemath build locally because it exceeds my RAM,
> but I can suggest two ways to potentially fix it:
> 
> * Add sourcelink_suffix support to multidocs.py (the “# Setup source symbolic
>   links” block). It can be obtained from app.config.html_sourcelink_suffix.
> 
> * Or set html_sourcelink_suffix to '.rst' in conf.py. This way it should be
>   the same as original extensions, so dh_sphinxdoc will not try to append it.
> 

So I guess your second option won't work but perhaps the first option might 
work, we just need to fiddle with the paths?

Could you also explain why exactly dh_sphinxdoc checks for these - what 
functionality is broken because these paths don't exist? I don't see that 
anyone noticed anything on the Sage upstream ticket 
https://trac.sagemath.org/ticket/22252 which is already merged, but then again 
I know that not everybody reads the documentation and checks it for flaws...

OTOH Sage uses a very custom sphinx build so it's possible that dh_sphinxdoc 
itself is not doing the right th

Bug#866166: sagemath: FTBFS with Sphinx 1.5: AttributeError: 'BuildEnvironment' object has no attribute 'citations'

[Ximin Luo]

Tobias Hansen wrote:
> On 06/28/2017 04:03 PM, Dmitry Shachnev wrote:
> > Hi Tobias, and thanks for the quick response!
> >
> > On Wed, Jun 28, 2017 at 02:44:23PM +0100, Tobias Hansen wrote:
> >> Hi Dmitry,
> >>
> >> would it be an option to upload sphinx 1.5 to unstable together with
> >> sagemath 8.0 (which works fine with sphinx 1.5) or do you want to do it
> >> before? We plan to upload sagemath 8.0 to unstable when it's released
> >> (they are at beta12 now).
> > That depends on how long do you estimate the final release to take.
> >
> > From what I found [1] the sage-8.0 milestone still has 341 active issues,
> > which does not sound very optimistic.
> >
> > I can wait for 2 or 3 weeks, but I do not want to wait longer. After all
> > upstream already released Sphinx 1.6 so we are two major releases behind.
> >
> >> Otherwise it's a matter of backporting commits from sagemath 8.0 to 7.6.
> > I think this is not enough, unless the second part of my bugreport is also
> > addressed upstream.
> >
> > [1]: https://trac.sagemath.org/milestone/sage-8.0
> >
> > --
> > Dmitry Shachnev
> 
> 
> Ok, we should fix this then. The sage 8.0 package build actually stops
> before dh_sphinxdoc currently (at override_dh_auto_install), so I don't
> know yet if we have the same problem there.
> 

I fixed our other issue in git and now I'm seeing these sphinxdoc errors:

[..]
make[1]: Entering directory '/home/infinity0/var/lib/sage/sagemath'
dh_sphinxdoc -XMathJax.js -Xtranslations.js -Xsearchtools.js
dh_sphinxdoc: ignoring unknown JavaScript code: 
debian/sagemath-doc-ca/usr/share/doc/sagemath/html/ca/intro/_static/thebe-sage.js
[..]
dh_sphinxdoc: 
debian/sagemath-doc-en/usr/share/doc/sagemath/html/en/reference/_sources/lie_algebras.rst.txt
 is missing
debian/rules:199: recipe for target 'override_dh_sphinxdoc' failed
make[1]: *** [override_dh_sphinxdoc] Error 2

Dmitry, if we need to further patch Sphinx or Sage, I'd be happy to do that. 
But what exactly is needed? I'm not sure if I totally understood the ticket you 
linked:

https://github.com/sphinx-doc/sphinx/pull/2454

Do we just need to put the equivalent of this:

https://github.com/mitya57/matplotlib/commit/53e6bc46d2f010f9a80e0c73dceb6166705f608f

into Sage's layout templates?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#866508: sagemath: sage fail at starting with: ImportError: No module named 'sage'

[Ximin Luo]

Package: sagemath
Followup-For: Bug #866508
Control: tags -1 + moreinfo unreproducible
Control: severity -1 important

Sorry, I can't reproduce this, even from a clean sid schroot. What does it say
when you run each of the following:

$ dpkg -S /usr/lib/python2.7/dist-packages/sage/__init__.py
$ dpkg -L sagemath | xargs -rn1 test -e; echo $?
$ dpkg -L sagemath-common | xargs -rn1 test -e; echo $?
$ python -c 'import numpy'; echo $?

Expected outputs are:

sagemath-common: /usr/lib/python2.7/dist-packages/sage/__init__.py
0
0
0

X

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sagemath depends on:
ii  cysignals-tools  1.3.2+ds-1
ii  cython   0.25.2-1+sage1
ii  ecl  16.1.2-2
ii  eclib-tools  20170330-1
ii  f2c  20100827-3
ii  fflas-ffpack 2.2.2-4
ii  flintqs  1:1.0-1+b1
ii  gap-core 4r8p6-2
ii  gfan 0.5+dfsg-6
ii  gmp-ecm  7.0.4+ds-1
ii  ipython  5.1.0-3
ii  iso-codes3.75-1
ii  jmol 14.6.4+2016.11.05+dfsg1-3
ii  lcalc1.23+dfsg-6+b1
ii  less 481-2.1
ii  libatlas3-base [liblapack.so.3]  3.10.3-1+b1
ii  libblas3 [libblas.so.3]  3.7.0-2
ii  libbrial-groebner0   0.8.7-1
ii  libbrial00.8.7-1
ii  libc62.24-12
ii  libcdd-tools 094h-1+b1
ii  libcliquer1  1.21-1+b2
ii  libec3   20170330-1
ii  libecm1  7.0.4+ds-1
ii  libflint-2.5.2   2.5.2-15
ii  libflint-arb12.8.1-3
ii  libgap-sage-44.8.6+3+20160327g69a66f0+dsx-2
ii  libgcc1  1:7.1.0-7
ii  libgd3   2.2.4-2
ii  libgivaro9   4.0.2-5
ii  libglpk404.62-1
ii  libgmp10 2:6.1.2+dfsg-1
ii  libgmpxx4ldbl2:6.1.2+dfsg-1
ii  libgsl2  2.3+dfsg-1
ii  libiml0  1.0.4-1+b2
ii  libjs-mathjax2.7.0-2
ii  libjs-three  80+dfsg2-1
ii  liblapack3 [liblapack.so.3]  3.7.0-2
ii  liblfunction01.23+dfsg-6+b1
ii  liblinbox-1.4.2-01.4.2-3
ii  liblinboxsage-1.4.2-01.4.2-3
ii  liblrcalc1   1.2-2+b1
ii  libm4ri-0.0.20140914 20140914-2+b1
ii  libm4rie-0.0.2015090820150908-1
ii  libmpc3  1.0.3-1+b2
ii  libmpfi0 1.5.1+ds-4
ii  libmpfr4 3.1.5-1
ii  libntl27 9.9.1-3
ii  libopenblas-base [liblapack.so.3]0.2.19-3
ii  libpari-gmp-tls5 2.9.1-1
ii  libplanarity03.0.0.5-1+b1
ii  libpng16-16  1.6.29-3
ii  libppl14 1:1.2-1
ii  libpynac10   0.7.5-2
ii  libratpoints-2.1.3   1:2.1.3-1+b2
ii  libreadline7 7.0-3
ii  librw0   0.8+ds-1
ii  libsingular4 1:4.1.0-p3+ds-2
ii  libsingular4-dev 1:4.1.0-p3+ds-2
ii  libstdc++6   7.1.0-7
ii  libsymmetrica2   2.0+ds-4
ii  libzn-poly-0.9   0.9-3+b2
ii  maxima-sage  5.39.0+ds-3
ii  maxima-sage-doc  5.39.0+ds-3
ii  maxima-sage-share5.39.0+ds-3
ii  nauty 

Bug#864831: ntl: New upstream version available

[Ximin Luo]

Source: ntl
Version: 9.9.1-3
Severity: wishlist

Dear Maintainer,

There's a new upstream version available, 10.3.0.

http://shoup.net/ntl/doc/tour-changes.html

X

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#863919: Acknowledgement (sympow segfaults with basic input)

[Ximin Luo]

Control: severity -1 minor
Control: retitle -1 segfaults when MALLOC_PERTURB_ is set

Hi Jerome, it happens on stretch/sid. This is what I have installed:

Versions of packages sympow depends on:
ii  dpkg 1.18.24
ii  libc62.24-10
ii  pari-gp  2.9.1-1
ii  sympow-data  1.023-8

However, I just did some more tests and have tracked this down to me setting 
MALLOC_PERTURB_ in my .xsession. The error goes away if I unset it:

$ env -u MALLOC_PERTURB_ sympow -curve "[0,-1,1,-10,-20]" -analrank
[..]
Done with small primes 1049
Analytic Rank is 0 : L-value 2.53842e-01

$ sympow -curve "[0,-1,1,-10,-20]" -analrank
[..]
Done with small primes 1049
Segmentation fault
139

MALLOC_PERTURB_ is a glibc envvar that causes malloc() and free() to set memory 
- see "man mallopt" - which I was testing locally to see if it might be a good 
security defense against attacks like HeartBleed and Cloudbleed.

Since it's not a default envvar that most users would set, I'll downgrade the 
severity of this bug. However I haven't experienced any problems with other 
programs, so I would guess that sympow is using malloc/free in a weird way, 
which may be worth revisiting if you have time.

X

Jerome BENOIT:
> Hello Ximin, thanks for your report.
> 
> Do you meant that the issue happens on Stretch ?
> I ask because I thought it happens on experimental and because the CI test 
> does not currently fail.
> 
> Thanks,
> Jerome 
> 
> On 02/06/17 14:34, Ximin Luo wrote:
>> BTW the stretch release date is soon:
> 
>> https://lists.debian.org/debian-devel-announce/2017/05/msg2.html
> 
>> The deadline for fixing this is June 9th and you'll need to file an unblock 
>> request, asking them to reduce the default migration time of 10 days.
> 
>> I'm not sure if this bug warrants raising the severity to grave, but please 
>> do that if appropriate.
> 
>> X
> 
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#863919: Acknowledgement (sympow segfaults with basic input)

[Ximin Luo]

BTW the stretch release date is soon:

https://lists.debian.org/debian-devel-announce/2017/05/msg2.html

The deadline for fixing this is June 9th and you'll need to file an unblock 
request, asking them to reduce the default migration time of 10 days.

I'm not sure if this bug warrants raising the severity to grave, but please do 
that if appropriate.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#863919: sympow segfaults with basic input

[Ximin Luo]

Package: sympow
Version: 1.023-8
Severity: important

Dear Maintainer,

sympow now segfaults with basic input, possibly due to libc upgrades - I didn't
see these before when we were testing with Sage 7.4. The failure is definitely
independent of Sage:

$ gdb -q sympow
Reading symbols from sympow...Reading symbols from 
/usr/lib/debug/.build-id/4a/af4652689eadb85484e33a562f7ff64ecc20d9.debug...done.
done.
(gdb) run -curve "[0,-1,1,-10,-20]" -analrank
Starting program: /usr/bin/sympow -curve "[0,-1,1,-10,-20]" -analrank
sympow 1.023 RELEASE (Debian 1.023-8)  (c) Mark Watkins --- see README and 
COPYING for details
Minimal model of curve  is [0,-1,1,-10,-20]
At 11: Inertia Group is  C1 MULTIPLICATIVE REDUCTION
Conductor is 11
sp 1: Conductor at 11 is 1+0, root number is -1
sp 1: Euler factor at 11 is 1-1*x
1st sym power conductor is 11, global root number is 1
NT 1d0: 7
Maximal number of terms is 7
0.0E+00
Done with small primes 1049

Program received signal SIGSEGV, Segmentation fault.
0x77ab6344 in free () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x77ab6344 in free () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x5558905a in free_data () at util.c:28
#2  0x6650 in prep_analrank (UB=35184372088832, sl=) 
at analrank.c:21
#3  0x5d66 in main (argc=, argv=) at 
main.c:258


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sympow depends on:
ii  dpkg 1.18.24
ii  libc62.24-10
ii  pari-gp  2.9.1-1
ii  sympow-data  1.023-8

sympow recommends no packages.

sympow suggests no packages.

-- no debconf information

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861684: r-cran-randomfields: FTBFS against r-base 3.4.0-1

[Ximin Luo]

Control: reassign -1 r-base
Control: forcemerge 861333 -1

Hey Andreas, I was told that this is a r-base issue, not an issue with 
r-cran-randomfields, and it is already being discussed in 861333.

Ximin

Andreas Tille:
> tags 861684 sid
> thanks
> 
> I'm tagging this sid since it is not relevant for testing.  It would be
> great if r-base maintainer would respect freeze policy to avoid this
> kind of problems. 
> 
> Kind regards
> 
>  Andreas.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861684: r-cran-randomfields: FTBFS against r-base 3.4.0-1

[Ximin Luo]

Package: r-cran-randomfields
Version: 3.1.36-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

This package FTBFS against r-base 3.4.0-1 which was uploaded to unstable
recently.

[..]
make[1]: Leaving directory '/<>/src'
make[1]: Entering directory '/<>/src'
make[1]: Leaving directory '/<>/src'
installing to 
/<>/debian/r-cran-randomfields/usr/lib/R/site-library/RandomFields/libs
** R
** data
** inst
** preparing package for lazy loading
Error: package or namespace load failed for 'RandomFieldsUtils' in 
dyn.load(file, DLLpath = DLLpath, ...):
 allocation failure in R_setPrimitiveArgTypes
Error : package 'RandomFieldsUtils' could not be loaded
ERROR: lazy loading failed for package 'RandomFields'
* removing 
'/<>/debian/r-cran-randomfields/usr/lib/R/site-library/RandomFields'
dh_auto_install: R CMD INSTALL -l 
/<>/debian/r-cran-randomfields/usr/lib/R/site-library --clean . 
--built-timestamp='Sun, 08 Jan 2017 17:05:46 +0100' returned exit code 1
debian/rules:4: recipe for target 'binary' failed
make: *** [binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

Build finished at 2017-05-02T17:28:29Z

Ximin


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (300, 'unstable'), (200, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

[Ximin Luo]

On Mon, 13 Feb 2017 16:12:14 -0500 "Aaron M. Ucko"  wrote:
> [..]
> 
>   xvfb-run ../../src/icas "algo.tex"
>   ./algo.tex:4: Warning: Command not found: \textheight
>   /usr/share/hevea/hyperref.hva:65: Warning: Ignoring option: 'pdftex'
>   /usr/share/hevea/hyperref.hva:65: Warning: Ignoring option: 'colorlinks'
>   ./algo.tex:33: Warning: Application of '\~' on 'p' failed
>   Exclude comment 'comment'
>   // Using locale /usr/share/locale/
>   // C
>   // /usr/share/locale/
>   // giac
>   // UTF-8
>   // Maximum number of parallel threads 3
>   // Unable to find keyword file doc/en/keywords
>   Help file doc/en/aide_cas not found
>   Added 0 synonyms
>   Giac pdflatex and HTML5 output
>   Partly inspired from pgiac by Jean-Michel Sarlat
>   Segmentation fault
>   Makefile:648: recipe for target 'algo.pdf' failed
>   make[4]: *** [algo.pdf] Error 139
>   make[4]: *** Waiting for unfinished jobs
> 
> [..]

I was unable to get to the bottom of this, however here are my findings so far:

Upstream attempts to optimise on space, defining SMARTPTR64 when it is possible 
to store pointers in less than 64 bits. From src/gen.h:

/* Warning: the size of a gen depend on the architecture and of 
compile-time flags
   Define -DSMARTPTR64 on 64 bit CPU if the pointers allocated by new are 
48 bits
   this will make sizeof(gen)==8 instead of 16
[..]

This *appears* to be force-disabled on ppc64el. From src/first.h:

#ifndef __x86_64__
#ifdef SMARTPTR64
#undef SMARTPTR64
#endif // SMARTPTR64
[..]

Further evidence that it is force-disabled:

(sid_ppc64el-dchroot)infinity0@plummer:~/giac$ uname -a
Linux plummer 3.16.0-4-powerpc64le #1 SMP Debian 3.16.39-1 (2016-12-30) 
ppc64le GNU/Linux

(sid_ppc64el-dchroot)infinity0@plummer:~/giac$ cat test.cc
#include "src/giac/giac.h"
#include 
int main() { printf("%d\n", SMARTPTR64); }

(sid_ppc64el-dchroot)infinity0@plummer:~/giac$ g++ test.cc
test.cc: In function 'int main()':
test.cc:3:29: error: 'SMARTPTR64' was not declared in this scope
 int main() { printf("%d\n", SMARTPTR64); }
 ^~
(sid_ppc64el-dchroot)infinity0@plummer:~/giac$ g++ -DSMARTPTR64 test.cc
test.cc: In function 'int main()':
test.cc:3:29: error: 'SMARTPTR64' was not declared in this scope
 int main() { printf("%d\n", SMARTPTR64); }
 ^~
(sid_ppc64el-dchroot)infinity0@plummer:~/giac$ g++ -DSMARTPTR64=1 test.cc
test.cc: In function 'int main()':
test.cc:3:29: error: 'SMARTPTR64' was not declared in this scope
 int main() { printf("%d\n", SMARTPTR64); }
 ^~

By editing src/icas one can run the failing build command in gdb:

(sid_ppc64el-dchroot)infinity0@plummer:~/giac/doc/fr$ diff -ru 
../../src/icas{.orig,}
--- ../../src/icas.orig 2017-02-15 16:48:15.962658720 +
+++ ../../src/icas  2017-02-15 16:48:29.294839196 +
@@ -114,7 +114,7 @@
 $ECHO "icas:icas:$LINENO: newargv[0]: $progdir/$program" 1>&2
 func_lt_dump_args ${1+"$@"} 1>&2
   fi
-  exec "$progdir/$program" ${1+"$@"}
+  exec gdb -q -d ../../src "$progdir/$program" ${1+"$@"}
 
   $ECHO "$0: cannot exec $program $*" 1>&2
   exit 1

(sid_ppc64el-dchroot)infinity0@plummer:~/giac/doc/fr$ xvfb-run 
../../src/icas
Reading symbols from /home/infinity0/giac/src/.libs/icas...done.
(gdb) run algo.tex
Starting program: /home/infinity0/giac/src/.libs/icas algo.tex
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/powerpc64le-linux-gnu/libthread_db.so.1".
// Using locale /usr/share/locale/
// C
// /usr/share/locale/
// giac
// UTF-8
// Maximum number of parallel threads 16
// Unable to find keyword file doc/en/keywords
Help file doc/en/aide_cas not found
Added 0 synonyms
Giac pdflatex and HTML5 output
Partly inspired from pgiac by Jean-Michel Sarlat
[New Thread 0x3fffb4f7eaa0 (LWP 17730)]

Thread 2 "icas" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffb4f7eaa0 (LWP 17730)]
giac::gen::in_eval (this=0x5e38b0b8, level=, evaled=..., 
contextptr=0x3fff59f8) at gen.cc:2105
2105evaled=(*Sommet.ptr())(evaled,contextptr);
(gdb) bt
#0  giac::gen::in_eval (this=0x5e38b0b8, level=, evaled=..., 
contextptr=0x3fff59f8) at gen.cc:2105
#1  0x3fffb7d3b3e8 in giac::eval_VECT (g=..., evaled=..., 
subtype=, level=, contextptr=0x3fff59f8) at 
gen.cc:1755
#2  0x3fffb7d391cc in giac::in_eval_vect (g=..., evaled=..., level=25, 
contextptr=0x3fff59f8) at gen.cc:2025
#3  0x3fffb7d3aa34 in giac::gen::in_eval (this=0x5e38b4f0, level=25, 
evaled=..., contextptr=0x3fff59f8) at gen.cc:2046
#4  0x3fffb7d3adb8 in giac::gen::in_eval 

Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs

[Ximin Luo]

Aaron M. Ucko:
> Ximin Luo <infini...@debian.org> writes:
> 
>> The error occurs right when the docbuild starts, before it actually
>> attempts to build anything, so my guess is that it would also occur
>> when starting the normal Sage CLI. So I don't think we should skip the
>> docbuild and release the build products as-is.
> 
> Thanks for clarifying.  You might want to consider conditionalizing the
> docbuild anyway to save build time and disk space, since crashing at
> startup would presumably also break the test suite.
> 

This is certainly a possibility and would be an improvement, but is harder than 
it might first appear, because the test suite contains some tests that depend 
on the existence of the built documentation. We'd have to figure out how to 
also disable those as well.

But yes, we'll try to do this in the future when we have time.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849152: sagemath: FTBFS on i386: many tests fail

[Ximin Luo]

On Thu, 22 Dec 2016 18:59:24 -0500 "Aaron M. Ucko"  wrote:
> Source: sagemath
> Version: 7.4-3
> Severity: important
> Justification: fails to build from source
> 
> The i386 build of sagemath failed with many test suite errors
> (including some outright crashes), as detailed at
> 
> https://buildd.debian.org/status/fetch.php?pkg=sagemath=i386=7.4-3=1482425583
> 
> Could you please take a look?
> 

This is an issue with python-brial, with the groebner_basis() function, see this

https://lists.alioth.debian.org/pipermail/debian-science-sagemath/Week-of-Mon-20161219/000687.html

and the subsequent messages.

I've temporarily allowed the build to pass, ignoring the test failures, to be 
able to pass the Debian stable release deadline for "new packages in testing". 
We'll try to fix it properly in the new year.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs

[Ximin Luo]

Hi, this does not look like a simple out-of-memory, but a bug involving 
libgomp. A quick Google search of the error message shows that there was some 
issue involving libgomp, dlopen and GCC years ago, but it's unclear if this is 
issue here is related.

The error occurs right when the docbuild starts, before it actually attempts to 
build anything, so my guess is that it would also occur when starting the 
normal Sage CLI. So I don't think we should skip the docbuild and release the 
build products as-is.

Given everything else that we need to do, it's unlikely that we'll have time to 
fix this in a timely manner, unless we get more volunteers on the team. Patches 
welcome.

X

As reference for other readers, the build logs are here:

https://buildd.debian.org/status/fetch.php?pkg=sagemath=arm64=7.4-4=1482515204=1
https://buildd.debian.org/status/fetch.php?pkg=sagemath=ppc64el=7.4-4=1482513811=1

On Thu, 22 Dec 2016 18:50:03 -0500 "Aaron M. Ucko"  wrote:
> Source: sagemath
> Version: 7.4-3
> Severity: important
> Justification: fails to build from source
> 
> The automatic builds of sagemath for arm64 and ppc64el both ran out of
> memory when trying to build documentation:
> 
>   [dochtml] ImportError: /usr/lib/«ARCH»/libgomp.so.1: cannot allocate memory 
> in static TLS block
>   Makefile:1059: recipe for target 'doc-html' failed
>   make[4]: *** [doc-html] Error 1
> 
> Could you please take a look?  Since this documentation presumably
> winds up in an architecture-independent binary package, perhaps you
> can arrange for binary-only builds to skip building it.
> 
> 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
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848246: [Debian-science-sagemath] Fwd: sagemath_7.4-1_amd64.changes is NEW

[Ximin Luo]

Control: retitle -1 Document SYMPOW_CACHEDIR better and automatically try to 
create it

Jerome BENOIT:
> Hello SymPow enthusiasts,
> 
> On 17/12/16 15:46, Jerome BENOIT wrote:
>>> It would be good if sympow could automatically create SYMPOW_CACHEDIR
 if it doesn't exist. Otherwise, I would have to add this logic to
 Sage, which seems a bit unclean.
>> I not so sure that it is a good idea to create SYMPOW_CACHEDIR on the fly.
>> Not that if SYMPOW_CACHEDIR does not exist, an appropraite message is 
>> printed.
> 
>>>
> I am on my way to add a mechanism to create SYMPOW_CACHEDIR on the fly
> (that may avoid to add a dirty trick on Sage).
> 

Hey, thanks for this. To explain in some more detail: at the moment I have to 
patch Sage like this:

sage/src/sage/lfunctions/sympow.py:
-cmd = 'sympow %s'%args
+cmd = 'env HOME="%s" sympow %s' % (DOT_SAGE, args)

Setting HOME is ugly, it would be nicer to do this instead:

-cmd = 'sympow %s'%args
+cmd = 'env SYMPOW_CACHEDIR="%s" sympow %s' % (os.path.join(DOT_SAGE, 
"sympow"), args)

However I can't, because sympow does not automatically create SYMPOW_CACHEDIR. 
I would have to do this instead:

-cmd = 'sympow %s'%args
+cmd = 'mkdir "{0}" && env SYMPOW_CACHEDIR="{0}" sympow 
{1}'.format(os.path.join(DOT_SAGE, "sympow"), args)

Note, it's not necessary to create all the parent directories like what `mkdir 
-p` does. That is, if `dirname $SYMPOW_CACHEDIR` does not exist, I think it's 
fine that sympow fails - because there is no way to know what permissions (etc) 
to create parent directories with, it is a sysadmin and local policy issue, and 
it means there is a bug somewhere else.

However if `dirname $SYMPOW_CACHEDIR` does exist, then sympow should try to 
create SYMPOW_CACHEDIR inside it - it "controls" this directory, so it knows 
what permissions to use.

So actually, I think there is no bug in sympow regarding non-existent HOME. It 
is OK to fail, if HOME does not exist and SYMPOW_CACHEDIR is not set. It is 
better that during tests, SYMPOW_CACHEDIR is set explicitly in a Makefile, or 
by the parent process (Sage) which already has a "directory for testing" 
(DOT_SAGE).

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848131: Acknowledgement (libmpich.so.12: cannot open shared object file: No such file or directory)

[Ximin Luo]

Control: reassign -1 libtachyon-mpich-0
Control: affects -1 tachyon-bin-nox
Control: affects -1 tachyon-bin-ogl

Note that the problem occurs only when you install libtachyon-mpich-0. (For 
some reason, that is what sbuild chose to satisfy sage's "tachyon" dependency. 
Probably I should remove my workaround of adding "libmpich12" to Sage's 
depends.)

It should be fixed by adding Depends: libmpich12 to libtachyon-mpich-0. I'm not 
sure exactly why this isn't happening already - but for example, if it is 
dynamically loaded using dlopen(1) rather than normal dynamic *linking* then I 
guess dpkg-shlibdeps won't pick it up, so you need to add it explicitly in 
debian/control.

X

Debian Bug Tracking System:
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Science Maintainers 
> 
> 
> If you wish to submit further information on this problem, please
> send it to 848...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848131: libmpich.so.12: cannot open shared object file: No such file or directory

[Ximin Luo]

Package: tachyon-bin-nox
Version: 0.99~b6+dsx-6
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

This package is missing either a direct or indirect dependency libmpich12:

(unstable-amd64-sbuild)infinity0:/build/sagemath-fBCYuv/sagemath-7.4$ 
tachyon-nox
tachyon-nox: error while loading shared libraries: libmpich.so.12: cannot open 
shared object file: No such file or directory

$ apt-file search libmpich.so.12
libmpich12: /usr/lib/x86_64-linux-gnu/libmpich.so.12

After I install the package, it works.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (300, 'unstable'), (200, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#847172: sagenb-export: FTBFS: UnicodeEncodeError: 'ascii' codec can't encode characters in position 41-42: ordinal not in range(128)

[Ximin Luo]

Control: clone -1 -2 -3
Control: reassign -2 src:nbformat
Control: retitle -2 Doesn't support non-UTF-8 filepaths
Control: severity -2 normal
Control: tags -2 + upstream
Control: forwarded -2 https://github.com/jupyter/nbformat/issues/76
Control: retitle -3 Fails when LC_CTYPE is not explicitly UTF-8
Control: severity -3 normal
Control: tags -3 + upstream
Control: forwarded -3 https://github.com/vbraun/ExportSageNB/issues/6

Instead of patching 2 Debian packages to fix this issue properly, and risking 
the upstreams picking different solutions and having to re-patch those 2 again, 
I will wait for the upstreams to pick the solutions I proposed.

In the meantime, I will work around this FTBFS by overriding LC_CTYPE specially 
for the tests.

X

Ximin Luo:
> I think I narrowed it down, could you try the build again with 
> LC_CTYPE="C.UTF-8" and see how it works?
> 
> X
> 
> Chris Lamb:
>> Ximin Luo wrote:
>>
>>> I can't reproduce this, even when setting the locale to various non-UTF
>>> values
>>
>> Not sure why you were trying this specifically; I don't do anything special
>> by default — or I would mention it! — and build under en_GB.UTF-8 etc. (See
>> the top of the full build log).
>>
>> If it "helps", I can still reproduce this on the today's sid.
>>

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#847172: sagenb-export: FTBFS: UnicodeEncodeError: 'ascii' codec can't encode characters in position 41-42: ordinal not in range(128)

[Ximin Luo]

I think I narrowed it down, could you try the build again with 
LC_CTYPE="C.UTF-8" and see how it works?

X

Chris Lamb:
> Ximin Luo wrote:
> 
>> I can't reproduce this, even when setting the locale to various non-UTF
>> values
> 
> Not sure why you were trying this specifically; I don't do anything special
> by default — or I would mention it! — and build under en_GB.UTF-8 etc. (See
> the top of the full build log).
> 
> If it "helps", I can still reproduce this on the today's sid.
> 
> 
> Regards,
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#847172: sagenb-export: FTBFS: UnicodeEncodeError: 'ascii' codec can't encode characters in position 41-42: ordinal not in range(128)

[Ximin Luo]

Hi Chris, I can't reproduce this, even when setting the locale to various 
non-UTF values. How are you building this?

X

Chris Lamb:
> Source: sagenb-export
> Version: 2.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> sagenb-export fails to build from source in unstable/amd64:
> 
>   […]
> 
>   py27 runtests: PYTHONHASHSEED='256193135'
>   py27 runtests: commands[0] | python2.7 -m unittest discover
>   ...E..
>   ==
>   ERROR: test_aleksandra_slapik_44 (test.test_sagenb_writer.ReadSageNB)
>   --
>   Traceback (most recent call last):
> File "«BUILDDIR»/test/test_sagenb_writer.py", line 39, in 
> test_aleksandra_slapik_44
>   ipynb.write(self.tmp_filename(u'WDI projekt - R\xf3\u017cankowski, 
> Kie\u0142pi\u0144ski, Kozok.ipynb'))
> File "«BUILDDIR»/sagenb_export/ipynb_writer.py", line 58, in write
>   write(ipynb, filename)
> File "/usr/lib/python2.7/dist-packages/nbformat/__init__.py", line 163, 
> in write
>   with io.open(fp, 'w', encoding='utf-8') as f:
>   UnicodeEncodeError: 'ascii' codec can't encode characters in position 
> 41-42: ordinal not in range(128)
>   
>   --
>   Ran 6 tests in 0.028s
>   
>   FAILED (errors=1)
>   ERROR: InvocationError: '«BUILDDIR»/.tox/py27/bin/python2.7 -m unittest 
> discover'
>   py35 create: «BUILDDIR»/.tox/py35
>   py35 inst: «BUILDDIR»/.tox/dist/sagenb_export-2.0.zip
>   py35 installed: 
> decorator==4.0.6,devscripts==2.16.11,entrypoints==0.2.2.post2,ipykernel==4.5.0,ipython==5.1.0,ipython-genutils==0.1.0,Jinja2==2.8,jsonschema==2.5.1,jupyter-client==4.4.0,jupyter-core==4.2.0,MarkupSafe==0.23,mistune==0.7.3,nbconvert==4.2.0,nbformat==4.1.0,notebook==4.2.3,pexpect==4.2.0,pickleshare==0.7.4,pkg-resources==0.0.0,pluggy==0.4.0,prompt-toolkit==1.0.9,ptyprocess==0.5.1,py==1.4.31,Pygments==2.1.3,pyzmq==15.4.0,sagenb-export==2.0,simplegeneric==0.8.1,six==1.10.0,terminado==0.6,tornado==4.4.2,tox==2.5.0,traitlets==4.3.1,virtualenv==15.1.0,wcwidth==0.1.7
>   py35 runtests: PYTHONHASHSEED='256193135'
>   py35 runtests: commands[0] | python3.5 -m unittest discover
>   E.
>   ==
>   ERROR: test_aleksandra_slapik_44 (test.test_sagenb_writer.ReadSageNB)
>   --
>   Traceback (most recent call last):
> File "«BUILDDIR»/test/test_sagenb_writer.py", line 39, in 
> test_aleksandra_slapik_44
>   ipynb.write(self.tmp_filename(u'WDI projekt - R\xf3\u017cankowski, 
> Kie\u0142pi\u0144ski, Kozok.ipynb'))
> File "«BUILDDIR»/sagenb_export/ipynb_writer.py", line 58, in write
>   write(ipynb, filename)
> File "/usr/lib/python3/dist-packages/nbformat/__init__.py", line 163, in 
> write
>   with io.open(fp, 'w', encoding='utf-8') as f:
>   UnicodeEncodeError: 'ascii' codec can't encode characters in position 
> 43-44: ordinal not in range(128)
>   
>   --
>   Ran 6 tests in 0.020s
>   
>   FAILED (errors=1)
>   ERROR: InvocationError: '«BUILDDIR»/.tox/py35/bin/python3.5 -m unittest 
> discover'
>   ___ summary 
> 
>   ERROR:   py27: commands failed
>   ERROR:   py35: commands failed
>   debian/rules:23: recipe for target 'override_dh_auto_test' failed
>   make[1]: *** [override_dh_auto_test] Error 1
>   make[1]: Leaving directory '«BUILDDIR»'
>   debian/rules:9: recipe for target 'build' failed
>   make: *** [build] Error 2
>   dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
>   […]
> 
> The full build log is attached.
> 
> 
> Regards,
> 
> 
> 
> ___
> Reproducible-bugs mailing list
> reproducible-b...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/reproducible-bugs
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: sagenb-export_2.0-1_amd64.changes REJECTED

[Ximin Luo]

Thorsten Alteholz:
> 
> Hi,
> 
> in case the license is GPL-3, your License block should not contain 
> "or (at your option) any later version.". This doesn't seem to match.
> 
>   Thorsten
> 

Whoops, my bad. I've fixed this and uploaded again.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840621: python-sympy: please apply 01_undeffun_sage.patch from sagemath

[Ximin Luo]

Package: python-sympy
Version: 1.0-2
Severity: normal
Tags: upstream patch

Dear Maintainer,

Please apply 01_undeffun_sage.patch in the next upload. I have already done
this in git in the pu/undeffun_sage branch [1], so you can just merge from this
branch before your next upload.

This patch is needed for SageMath to work correctly with SymPy, and it should
not affect other users of SymPy.

Thanks,
Ximin

[1] 
https://anonscm.debian.org/git/debian-science/packages/sympy.git/commit/?h=pu/undeffun_sage=9401420fe864795345db827137f5e2b018645c54

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-sympy depends on:
ii  python-mpmath  0.19-3
pn  python:any 

Versions of packages python-sympy recommends:
ii  dvipng  1.14-2+b2
ii  ipython 5.1.0-1
pn  isympy  
ii  python [python-ctypes]  2.7.11-2
pn  python-gmpy 
ii  python-imaging  3.3.1-1
ii  python-numpy1:1.11.1~rc1-1+sage1
pn  python-pyglet   
pn  python-sympy-doc
pn  texlive-fonts-extra 

python-sympy suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python2.7/dist-packages/sympy/core/function.py 
(from python-sympy package)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840481: [Debian-science-sagemath] Bug#840481: singular-ui: segfault when piping to stdin

[Ximin Luo]

Control: tags -1 upstream
Control: forwarded -1 https://www.singular.uni-kl.de:8005/trac/ticket/775

Ximin Luo:
> Package: singular-ui
> Version: 4.0.3-p3+ds-1
> Severity: important
> 
> Dear Maintainer,
> 
> Some extra Sagemath test cases are failing since we upgraded to Singular 4;
> minimal test case:
> 
> $ echo '12345*54321;' | Singular
> [ fails spectacularly ]
> 
> but it works if you run `Singular` and type it in manually. Presumably the 
> pipe
> version also worked with Singular 3 before.
> 

Workaround is to call `Singular -b` instead of `Singular`; I will prepare a 
patch for Sage shortly.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840481: singular-ui: segfault when piping to stdin

[Ximin Luo]

Package: singular-ui
Version: 4.0.3-p3+ds-1
Severity: important

Dear Maintainer,

Some extra Sagemath test cases are failing since we upgraded to Singular 4;
minimal test case:

$ echo '12345*54321;' | Singular
[ fails spectacularly ]

but it works if you run `Singular` and type it in manually. Presumably the pipe
version also worked with Singular 3 before.

X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages singular-ui depends on:
ii  libc6   2.24-3
ii  libflint-2.5.2  2.5.2-9
ii  libgcc1 1:6.1.1-11
ii  libgmp102:6.1.1+dfsg-1
ii  libmpfr43.1.5-1
ii  libntl279.9.1-3
ii  libreadline77.0-1
ii  libsingular44.0.3-p3+ds-1
ii  libstdc++6  6.1.1-11
ii  libtinfo5   6.0+20160917-1
ii  singular-data   4.0.3-p3+ds-1

Versions of packages singular-ui recommends:
ii  singular-modules  4.0.3-p3+ds-1

Versions of packages singular-ui suggests:
pn  singular-doc  

-- no debconf information

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#833846: fflas-ffpack: don't generate optimised code based on the build machine

[Ximin Luo]

Control: severity -1 serious

I was recommended by multiple people to bump the severity of this bug. Also to 
clarify that i386 should have no optimisation flags, and not "-msse -msse2". My 
earlier comment was based on a misunderstanding of what "i386 doesn't have mmx" 
meant; sse and sse2 build on top of mmx.

X

Ximin Luo:
> Package: fflas-ffpack
> Version: 2.2.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> fflas-ffpack on amd64 was built with "-msse4.1 -mfma -mavx2" as can be seen
> from the output of `pkg-config --cflags fflas-ffpack`. This unfortunately 
> makes
> it crash on amd64 machines that don't support these instructions, and we are
> running into this issue whilst testing SageMath.
> 
> Please disable any build options that set optimisations based on autodetection
> of the CPU features of the build machine.
> 
> It should be OK to hard-code "-mmmx -msse -msse2" for amd64 and "-msse -msse2"
> for i386, according to wRAR on #debian-devel. This is somewhat based on
> information from [1]. There might be other optimisations you can make, but I
> haven't yet done the detailed research for that.
> 
> X
> 
> [1] https://lists.debian.org/debian-devel-announce/2016/05/msg1.html
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages fflas-ffpack depends on:
> ii  fflas-ffpack-common  2.2.1-1
> 
> fflas-ffpack recommends no packages.
> 
> Versions of packages fflas-ffpack suggests:
> pn  fflas-ffpack-dev-doc   
> pn  fflas-ffpack-user-doc  
> 
> -- no debconf information
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#833846: fflas-ffpack: don't generate optimised code based on the build machine

[Ximin Luo]

Package: fflas-ffpack
Version: 2.2.1-1
Severity: important

Dear Maintainer,

fflas-ffpack on amd64 was built with "-msse4.1 -mfma -mavx2" as can be seen
from the output of `pkg-config --cflags fflas-ffpack`. This unfortunately makes
it crash on amd64 machines that don't support these instructions, and we are
running into this issue whilst testing SageMath.

Please disable any build options that set optimisations based on autodetection
of the CPU features of the build machine.

It should be OK to hard-code "-mmmx -msse -msse2" for amd64 and "-msse -msse2"
for i386, according to wRAR on #debian-devel. This is somewhat based on
information from [1]. There might be other optimisations you can make, but I
haven't yet done the detailed research for that.

X

[1] https://lists.debian.org/debian-devel-announce/2016/05/msg1.html

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fflas-ffpack depends on:
ii  fflas-ffpack-common  2.2.1-1

fflas-ffpack recommends no packages.

Versions of packages fflas-ffpack suggests:
pn  fflas-ffpack-dev-doc   
pn  fflas-ffpack-user-doc  

-- no debconf information

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#830206: libmpfi-dev: undefined symbol: mpfi_is_strictly_neg_default

[Ximin Luo]

Package: libmpfi-dev
Version: 1.5.1+ds-4
Severity: normal

Dear Maintainer,

When trying to compile Sage 7.1 as described in 

https://wiki.debian.org/DebianScience/Sage
https://anonscm.debian.org/cgit/debian-science/packages/sagemath.git/

Sage compiles successfully but the resulting binary crashes when I try to run
it, with an error related to cython dynamic library loading:

cd ../.. && sage-logger './sage --docbuild --no-pdf-links all html ' 
logs/dochtml.log
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
mod_name, _Error)
  File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
__import__(mod_name)  # Do not catch exceptions initializing package
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage_setup/docbuild/__init__.py",
 line 22, in 
import sage.all
  File "/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/all.py", 
line 79, in 
from sage.rings.all  import *
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/all.py", 
line 50, in 
from finite_rings.all import *
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/finite_rings/all.py",
 line 21, in 
from finite_field_constructor import FiniteField
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/finite_rings/finite_field_constructor.py",
 line 176, in 
import sage.rings.polynomial.polynomial_element as polynomial_element
  File "sage/rings/polynomial/polynomial_element.pyx", line 53, in init 
sage.rings.polynomial.polynomial_element 
(/home/anonymous/tmp/sage/sagemath/sage/src/build/cythonized/sage/rings/polynomial/polynomial_element.c:78933)
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_ring.py",
 line 148, in 
import sage.rings.polynomial.polynomial_element_generic as 
polynomial_element_generic
  File 
"/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_element_generic.py",
 line 1057, in 
from sage.rings.polynomial.polynomial_rational_flint import 
Polynomial_rational_flint
  File "sage/rings/polynomial/polynomial_integer_dense_flint.pxd", line 7, in 
init sage.rings.polynomial.polynomial_rational_flint 
(/home/anonymous/tmp/sage/sagemath/sage/src/build/cythonized/sage/rings/polynomial/polynomial_rational_flint.cpp:21576)
  File "sage/rings/real_mpfi.pxd", line 11, in init 
sage.rings.polynomial.polynomial_integer_dense_flint 
(/home/anonymous/tmp/sage/sagemath/sage/src/build/cythonized/sage/rings/polynomial/polynomial_integer_dense_flint.cpp:19473)
ImportError: 
/home/anonymous/.sage/local/lib/python2.7/site-packages/sage/rings/real_mpfi.so:
 undefined symbol: mpfi_is_strictly_neg_default

This function is present in the source code, but not in the compiled .so for
some reason. I will investigate further in the meantime, but any tips on this
would be appreciated.

Thanks!

X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmpfi-dev depends on:
ii  dpkg1.18.9
ii  libgmp-dev  2:6.1.1+dfsg-1
ii  libmpfi-dev-common  1.5.1+ds-4
ii  libmpfi01.5.1+ds-4
ii  libmpfr-dev 3.1.4-2

libmpfi-dev recommends no packages.

libmpfi-dev suggests no packages.

-- no debconf information

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers