Bug#1074952: fflas-ffpack: ftbfs with GCC-14

[Torrance, Douglas]

Control: block -1 by 1075001

On Wed 03 Jul 2024 12:26:26 PM GMT, Matthias Klose  wrote:

Package: src:fflas-ffpack
Version: 2.5.0-3
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14

[This bug is targeted to the upcoming trixie release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2024/07/01/fflas-ffpack_2.5.0-3_unstable_gccexp.log


Here are the relevant lines from the build log:

configure:19320: checking for GIVARO usability
configure:19333: g++ -o conftest  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.cpp  -lgivaro -lgmpxx -lgmp  >&5
In file included from /usr/include/givaro/givinteger.h:24,
from conftest.cpp:40:
/usr/include/givaro/random-integer.h: In member function 'Givaro::RandomIntegerIterator<_Unsigned, 
_Exact_Size>& Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>::operator=(const 
Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>&)':
/usr/include/givaro/random-integer.h:94:54: error: no match for 'operator=' (operand types are 
'Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>::Integer_Domain' {aka 
'Givaro::ZRing'} and 'const Givaro::RandomIntegerIterator<_Unsigned, 
_Exact_Size>::Integer_Domain' {aka 'const Givaro::ZRing'})
  94 | const_cast(_ring)=R._ring;
 |  ^


This is givaro bug #1075001, which was just fixed in the recently uploaded 
givaro 4.2.0-5.


signature.asc
Description: PGP signature

Bug#1069427: macaulay2: FTBFS on armhf: make[4]: *** [Makefile:50: check-ForeignFunctions] Error 1

[Torrance, Douglas]

Control: tags -1 unreproducible
Control: severity -1 important

On Sat 20 Apr 2024 08:57:46 AM -04, Lucas Nussbaum  wrote:

--no-preload --stop --silent -e
"needsPackage(\"ForeignFunctions\",LoadDocumentation=>true,DebuggingMode=>true)"
-e "debug Core; argumentMode = defaultMode - SetUlimit" -e
"check(ForeignFunctions,UserMode=>false,Verbose=>true); exit 0"

 -- capturing check(0, "ForeignFunctions")-- SIGSEGV
-* stack trace, pid: 2593432
 0# stack_trace(std::ostream&, bool) at ./M2/Macaulay2/d/main.cpp:119
 1# segv_handler at ./M2/Macaulay2/d/main.cpp:235
 2# 0xF64686C0 in /lib/arm-linux-gnueabihf/libc.so.6
-- end stack trace *-
make[4]: *** [Makefile:50: check-ForeignFunctions] Error 1


I haven't been able to reproduce this build error after several attempts on 
armhf machines, so
I'm dropping the severity of this bug to "important".



signature.asc
Description: PGP signature

Bug#1067629: FTBFS: Build killed with signal TERM after 150 minutes of inactivity

[Torrance, Douglas]

Control: reassign -1 gprbuild
Control: found -1 2024.1.20231009-4
Control: affects -1 src:phcpack

On Mon, 25 Mar 2024 00:49:45 +0500 Andrey Rakhmatullin  wrote:

Source: phcpack
Version: 2.4.90+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=phcpack=armhf=2.4.90%2Bdfsg-1=1711030010=0

   debian/rules execute_after_dh_auto_clean
make[1]: Entering directory '/<>'
gprclean src/Ada/Main/main.gpr || true
E: Build killed with signal TERM after 150 minutes of inactivity


This seems to be a bug with gprclean, as we're hanging at the initial dh_clean
step when building phcpack.  I was able to reproduce this on an armhf
porterbox.  Sending an interrupt while it's hanging with gdb gives the
following.  Perhaps it's related to the t64 transition?

   Starting program: /usr/bin/gprclean -v src/Ada/Main/main.gpr
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
   GPRCLEAN Pro 18.0w (19940713) (arm-linux-gnueabihf)
   Copyright (C) 2006-2016, AdaCore
   
   Parsing Project File "src/Ada/Main/main.gpr".
   
150 lines: No errors

   TMPDIR = "/tmp/GPR.22180"
   /usr/bin/gprconfig --batch -o /tmp/GPR.22180/GNAT-TEMP-01.TMP 
--target=armhf-linux --fallback-targets --config=c --config=ada 
--config=c++
   [Detaching after fork from child process 22185]
   Checking configuration /tmp/GPR.22180/GNAT-TEMP-01.TMP
   Setting the default project search directories
  Adding directory "/usr/armhf-linux/share/gpr"
  Adding directory "/usr/armhf-linux/lib/gnat"
  Adding directory "/usr/share/gpr"
  Adding directory "/usr/lib/gnat"
   /usr/bin/gprconfig --batch -o /tmp/GPR.22180/GNAT-TEMP-02.TMP 
--target=armhf-linux --fallback-targets --config=c --config=ada 
--config=c++
   [Detaching after fork from child process 22203]
   Checking configuration /tmp/GPR.22180/GNAT-TEMP-02.TMP
   Setting the default project search directories
  Adding directory "/usr/armhf-linux/share/gpr"
  Adding directory "/usr/armhf-linux/lib/gnat"
  Adding directory "/usr/share/gpr"
  Adding directory "/usr/lib/gnat"
150 lines: No errors
   
   Parsing of Project File "src/Ada/Main/main.gpr" is finished.
   
   Cleaning project "main"
   
   
   No file has been deleted

   ^C
   Program received signal SIGINT, Interrupt.
   0xb5f7948a in __pthread_cond_timedwait64 ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   (gdb) bt
   #0  0xb5f7948a in __pthread_cond_timedwait64 ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   #1  0xb5f79636 in pthread_cond_timedwait ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   #2  0xb63258c6 in system.task_primitives.operations.monotonic.timed_sleep ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #3  0xb6325c7a in system.task_primitives.operations.timed_sleep ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #4  0xb632b820 in system.tasking.stages.finalize_global_tasks ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #5  0x00553930 in ?? ()
   #6  0xb5f3b7da in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
   #7  0xb5f3b87e in __libc_start_main () from 
/lib/arm-linux-gnueabihf/libc.so.6
   #8  0x005539ac in ?? ()
   Backtrace stopped: previous frame identical to this frame (corrupt stack?)


signature.asc
Description: PGP signature

Bug#1067953: transition: flint

[Torrance, Douglas]

Package: release.debian.org
Control: affects -1 + src:flint
X-Debbugs-Cc: fl...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: normal

Dear Release Team,

I would like to request a transition slot for flint.  The recent upstream
release 3.1.0 introduced the new soversion flint 19.  A new binary package,
libflint19, was introduced in the source package flint 3.1.2-1~exp1, which
cleared the NEW queue on March 28 and is now in experimental.

flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in
the libflint18t64 binary package.  However, flint 3.0.1-3.1 had been
previously uploaded for the t64 transition, shipping libflint.so.18 in
the same binary package.  This is RC bug #1067226 and has resulted in
several other RC bugs in reverse dependencies.

An auto-flint tracker already exists for the t64 transition, but it doesn't
take the new libflint19 package into account.  (Although perhaps this will
update automatically at some point?)

binNMU's should be sufficient for each of flint's reverse dependencies:

* e-antic
* gyoto
* macaulay2
* msolve
* normaliz
* polymake
* singular

Ben file:

title = "flint";
is_affected = (.build-depends ~ /\blibflint-dev\b/) | (.depends ~ 
/\blibflint(?:18|18t64|19)\b/);
is_good = .depends ~ /\blibflint19\b/;
is_bad = .depends ~ /\blibflint18(?:t64)?\b/;

Thank you!


signature.asc
Description: PGP signature

Bug#1067787: Additional Information

[Torrance, Douglas]

On Tue 26 Mar 2024 03:53:47 PM -04, Vladimir Petko 
 wrote:

  Would it be possible to consider a merge request[1] that addresses this issue?

[1] https://salsa.debian.org/math-team/linbox/-/merge_requests/1


Absolutely!  I've merged it and will upload a new version of linbox soon.

Thanks for working on this!


signature.asc
Description: PGP signature

Bug#1067226: flint: libflint needs soversion bump to 19

[Torrance, Douglas]

On Wed, 20 Mar 2024 14:16:07 + "Torrance, Douglas"  
wrote:

The binary package libflint18t64 ships libflint.so.19, so it should be
renamed to libflint19 and there should be a transition.


I've just uploaded a new flint package to experimental that ships a
libflint19 binary package.  Once it clears the NEW queue, we can request
a transition slot.


signature.asc
Description: PGP signature

Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

[Torrance, Douglas]

Control: forcemerge 1067226 -1

On Mon, 25 Mar 2024 10:42:24 -0300 David Bremner  wrote:


Control: reassign -1 flint

Lucas Nussbaum  writes:

> Source: polymake
> Version: 4.11-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

I'm fairly sure this is actually a bug in flint.


Indeed!  It's #1067226 -- merging.


signature.asc
Description: PGP signature

Bug#1067226: flint: libflint needs soversion bump to 19

[Torrance, Douglas]

Control: block 1067262 by -1
Control: block 1067274 by -1
Control: block 1067286 by -1
Control: block 1067293 by -1
Control: block 1067300 by -1
Control: block 1067360 by -1

On Wed 20 Mar 2024 10:13:20 AM -04, Doug Torrance  
wrote:

The binary package libflint18t64 ships libflint.so.19, so it should be
renamed to libflint19 and there should be a transition.


FTBFS bugs were recently filed against several packages (e-antic, normaliz,
msolve, singular, pynormaliz, and macaulay2) that depend on flint.  I'm
pretty sure that this is the underlying issue behind all of them.


signature.asc
Description: PGP signature

Bug#1067226: flint: libflint needs soversion bump to 19

[Torrance, Douglas]

Source: flint
X-Debbugs-Cc: dtorra...@piedmont.edu
Version: 3.1.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The binary package libflint18t64 ships libflint.so.19, so it should be
renamed to libflint19 and there should be a transition.  This is causing
a number of issues:

* Several Lintian warnings and errors:
 - mismatched-override
 - package-name-doesnt-match-sonames
 - shared-library-not-shipped
 - ships-undeclared-shared-library

* The normaliz autopkgtests are failing, e.g., [1]:
 /usr/bin/normaliz: error while loading shared libraries: libflint.so.18: 
cannot open shared object file: No such file or directory

* The macaulay2 builds are failing, e.g. [2]:
 checking whether the package normaliz is installed... /usr/bin/normaliz
 normaliz: error while loading shared libraries: libflint.so.18: cannot open 
shared object file: No such file or directory

[1] https://ci.debian.net/packages/n/normaliz/testing/amd64/44097859/
[2] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=all=1.23%2Bds-1=1710934109=0



signature.asc
Description: PGP signature

Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences

[Torrance, Douglas]

Control: tags -1 - moreinfo + confirmed

On Mon 18 Mar 2024 05:54:25 AM GMT, Julian Gilbey  wrote:

On Mon, Mar 18, 2024 at 05:48:14AM +, Julian Gilbey wrote:

I was building or testing a package using sbuild or autopkgtest using
lxc, I don't remember which.  One of the dependencies was dot2tex, so
it was being installed on a clean chroot (or equivalent).  The
warnings appeared during the dpkg installation of the package
(probably during the configure step).

But either way, all of these are, indeed, syntax errors and need to be
corrected.  (It turns out, just looking at the first example on line
1236, that they cannot all be fixed by turning them into raw strings:
this string has both '\p', which should be '\\p' (with a literal
backslash), and '\n', which presumably is intended as a new line
character.


Oh, and just to add on to this: I believe that this will become a
SyntaxError in Python 3.13 or Python 3.14.


Ok, thanks for clarifying!

I was able to reproduce the warnings in Python 3.12:

$ python3.12
Python 3.12.2 (main, Mar  3 2024, 09:11:00) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import dot2tex

/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:900: SyntaxWarning: invalid 
escape sequence '\i'
 variables['<>'] = "\input{gvcols.tex}"
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1236: SyntaxWarning: invalid 
escape sequence '\p'
...

They were silent using Python 3.11, which is suppose is why I hadn't seen them
before.

Doug


signature.asc
Description: PGP signature

Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences

[Torrance, Douglas]

Control: tags -1 moreinfo

On Fri, 08 Mar 2024 09:54:07 + Julian Gilbey  wrote:

Package: dot2tex
Version: 2.11.3-4
Severity: normal

While installing this version on a testing system, lots of warning
messages were given; the relevant strings should be marked as raw.

/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:900: SyntaxWarning: invalid 
escape sequence '\i'
  variables['<>'] = "\input{gvcols.tex}"
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1236: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psellipse[%s](%sbp,%sbp)(%sbp,%sbp)\n" % (stylestr, smart_float(x), 
smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1256: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \pspolygon[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1262: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psline%s\n" % "".join(pp)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1272: SyntaxWarning: invalid 
escape sequence '\p'
  return "  \psbezier{%s}%s\n" % (arrowstyle, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1299: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1306: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{fillcolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1313: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1322: SyntaxWarning: invalid 
escape sequence '\p'
  return "  \psset{%s}\n" % psstyle
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1393: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psbezier[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1395: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psline[%s]%s%s\n" % (stylestr, pp[0], pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1589: SyntaxWarning: invalid 
escape sequence '\p'
  dashed='\pgfsetdash{{3pt}{3pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1590: SyntaxWarning: invalid 
escape sequence '\p'
  dotted='\pgfsetdash{{\pgflinewidth}{2pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1591: SyntaxWarning: invalid 
escape sequence '\p'
  bold='\pgfsetlinewidth{1.2pt}')
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1639: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{newcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1641: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1649: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{strokecol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1651: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetstrokecolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1661: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{fillcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1663: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetfillcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1707: SyntaxWarning: invalid 
escape sequence '\%'
  s += "  \%s%s (%sbp,%sbp) ellipse (%sbp and %sbp);\n" % (cmd, stylestr, 
smart_float(x), smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1723: SyntaxWarning: invalid 
escape sequence '\%'
  s = "  \%s%s %s -- cycle;\n" % (cmd, stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1730: SyntaxWarning: invalid 
escape sequence '\d'
  return "  \draw%s %s;\n" % (stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1753: SyntaxWarning: invalid 
escape sequence '\d'
  s = "  \draw (%sbp,%sbp) node%s {%s};\n" % (smart_float(x), smart_float(y), 
lblstyle, text)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1765: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \draw%s %s .. %s;\n" % (stylestr, " .. ".join(pstrs), pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1857: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \draw [%s] %s to[%s]%s %s;\n" % (stylestr, src,
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1860: SyntaxWarning: invalid 
escape sequence '\d'


Thanks for the report!

I'm not able to reproduce these warnings.  What did you run to get them?


signature.asc
Description: PGP signature

Bug#1065139: morph's abandoned packages (list)

[Torrance, Douglas]

Control: retitle 1065139 ITA: dot2tex -- Graphviz to LaTeX converter
Control: owner 1065139 !
Control: retitle 1065220 ITA: mpmath -- library for arbitrary-precision 
floating-point arithmetic
Control: owner 1065220 !

I'll work on the following:

On Thu 14 Mar 2024 06:20:11 AM GMT, Julian Gilbey  wrote:

#1065139 O: dot2tex -- Graphviz to LaTeX converter
#1065220 O: mpmath -- library for arbitrary-precision floating-point 
arithmetic


Doug


signature.asc
Description: PGP signature

Bug#1065019: ITP: r-cran-fadist -- GNU R package for distributions sometimes useful in hydrology

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: r-cran-fadist
 Version : 2.4
 Upstream Contact: Thomas Petzoldt 
* URL : https://cran.r-project.org/web/packages/FAdist/
* License : GPL
 Programming Lang: R
 Description : GNU R package for distributions sometimes useful in hydrology

This package contains several probability distributions that are
sometimes useful in hydrology, including the three-parameter gamma
distribution, the generalized Pareto distribution, the generalized
extreme value distribution, the Gumbel distribution, the kappa
distribution, the four-parameter kappa distribution, the log-Pearson
type III distribution, the log-logistic distribution, the
three-parameter log-logistic distribution, the three-parameter
lognormal distribution, and the three-parameter Weibull distribution.

I plan to maintain this package as a member of the Debian R Team.


signature.asc
Description: PGP signature

Bug#1064023: cddlib: FTBFS on armhf: ! Text line contains an invalid character.

[Torrance, Douglas]

On Thu 15 Feb 2024 03:51:43 PM -05, Sebastian Ramacher  
wrote:

Source: cddlib
Version: 094m-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=cddlib=armhf=094m-1%2Bb1=1704482099=0

[13] [14]) [15] [16]
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def

Package amsfonts Warning: Obsolete command \Bbb; \mathbb should be used instead
 on input line 1139.

(./cddlibman.bbl
Overfull \hbox (2.6514pt too wide) in paragraph at lines 4--9
[]\OT1/cmr/m/n/10.95 N. Amenta.  Di-rec-tory of com-pu-ta-tional ge-om-e-try.  
http://www.geom.uiuc.edu/software/cglist/. 
[17])

(./cddlibman.aux)
Underfull \hbox (badness 2302) in paragraph at lines 68--73
[]\OT1/cmr/m/n/10.95 J. Er-ick-son.  Com-pu-ta-tional ge-om-e-try pages, list o
f soft-ware li-braries and codes.
[18]) [19] (./cddlibman.aux
! Text line contains an invalid character.
l.1 ^^@
   ^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@...

? 
! Emergency stop.
l.1 

Output written on cddlibman.dvi (19 pages, 73740 bytes).

Transcript written on cddlibman.log.
 (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)make[2]: *** 
[Makefile:526: cddlibman.dvi] Error 1
make[2]: *** Waiting for unfinished jobs

Cheers


I think this may have just been a flaky TeX thing.  After giving back, the next 
build was successful:

https://buildd.debian.org/status/fetch.php?pkg=cddlib=armhf=094m-1%2Bb1=1708344490=0

Closing


signature.asc
Description: PGP signature

Bug#1063302: libsingular4-dev: libsingular renders sagemath unusable

[Torrance, Douglas]

Control: reassign -1 sagemath 9.5-6
Control: severity 1052051 grave
Control: merge -1 1052051

On Tue 06 Feb 2024 12:18:06 AM -03, Alexandre Lymberopoulos  
wrote:

Package: libsingular4-dev
Version: 1:4.3.2-p10+ds-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

It seems that this version of the package (or other on the libsingular4 family) 
renders sagemath completelu unusable. In other systems, with the an older 
version of libsingular4* (4.3.1, if my memory isn't cheating me), sage runs 
perfectly.

Below is an output of sagemath running from the prompt:

~$ sage
┌┐
│ SageMath version 9.5, Release Date: 2022-01-30 │
│ Using Python 3.11.7. Type "help()" for help.   │
└┘
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3.11/pathlib.py", line 1251, in is_dir
return S_ISDIR(self.stat().st_mode)
   ^

AttributeError: 'str' object has no attribute 'stat'
Original exception was:
Traceback (most recent call last):
  File "/usr/bin/sage-ipython", line 15, in 
app.initialize()
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
110, in inner
return method(app, *args, **kwargs)
   
  File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 278, in 
initialize
self.init_shell()
  File "/usr/lib/python3/dist-packages/sage/repl/interpreter.py", line 789, in 
init_shell
self.shell.extension_manager.load_extension(SAGE_EXTENSION)
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 76, in 
load_extension
return self._load_extension(module_str)
   
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 93, in 
_load_extension
if self._call_load_ipython_extension(mod):
   ^^
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 145, 
in _call_load_ipython_extension
mod.load_ipython_extension(self.shell)
  File "/usr/lib/python3/dist-packages/sage/repl/__init__.py", line 5, in 
load_ipython_extension
sage.repl.ipython_extension.load_ipython_extension(*args)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
617, in wrapper
result = func(*args, **kwargs)
 ^
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
630, in load_ipython_extension
SageCustomizations(shell=ip)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
434, in __init__
import sage.all # until sage's import hell is fixed
^^^
  File "/usr/lib/python3/dist-packages/sage/all.py", line 169, in 
from sage.rings.all  import *
  File "/usr/lib/python3/dist-packages/sage/rings/all.py", line 87, in 
from .qqbar import (AlgebraicRealField, AA,
  File "/usr/lib/python3/dist-packages/sage/rings/qqbar.py", line 2810, in 

QQxy = QQ['x', 'y']
   ~~^^
  File "sage/structure/parent.pyx", line 1276, in 
sage.structure.parent.Parent.__getitem__ (build/cythonized/sage/structure/parent.c:11543)
  File "/usr/lib/python3/dist-packages/sage/categories/rings.py", line 1177, in 
__getitem__
return PolynomialRing(self, elts)
   ^^
  File 
"/usr/lib/python3/dist-packages/sage/rings/polynomial/polynomial_ring_constructor.py",
 line 647, in PolynomialRing
return _multi_variate(base_ring, names, **kwds)
   
  File 
"/usr/lib/python3/dist-packages/sage/rings/polynomial/polynomial_ring_constructor.py",
 line 775, in _multi_variate
from sage.rings.polynomial.multi_polynomial_libsingular import 
MPolynomialRing_libsingular
ImportError: libsingular-Singular-4.3.1.so: cannot open shared object file: No 
such file or directory

It seems that sage calls previous version (4.3.1) of libsingular. I reported 
this bug before to sagemath package, but got no answer. I'let this filed here 
and report again on sage.

I may provide any further information needed to fix this.

Best, Alexandre

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsingular4-dev depends on:
ii  libflint-dev 3.0.1-2
ii  libgmp-dev   2:6.3.0+dfsg-2
ii  libmpfr-dev  4.2.1-1
ii  libntl-dev   11.5.1-1+b2
ii  libsingular4-dev-common  1:4.3.2-p10+ds-1
ii  libsingular4m3n0 

Bug#1062816: ITP: latte -- R interface to 'LattE' and '4ti2'

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: r-cran-latte
 Version : 0.2.1
 Upstream Contact: David Kahle 
* URL : https://dkahle.github.io/latte/
* License : GPL
 Programming Lang: R
 Description : R interface to 'LattE' and '4ti2'

Back-end connections to 'LattE' ()
for counting lattice points and integration inside convex polytopes and
'4ti2' () for algebraic, geometric, and combinatorial
problems on linear spaces and front-end tools facilitating their use in the
'R' ecosystem.

I plan on maintaining this package under the umbrella of the Debian R Team.


signature.asc
Description: PGP signature

Bug#1061313: macaulay2 ftbfs with Python 3.12 as the default

[Torrance, Douglas]

Control: tags -1 confirmed

On Mon 22 Jan 2024 09:22:49 AM -05, Matthias Klose  wrote:

Package: src:macaulay2
Version: 1.22+ds-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

with python3-defaults from experimental:

[...]
gcc -std=gnu11 -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security
 -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/macaulay2-1.22+ds-5build1
 -g3 -O2 -Wno-unused -pipe -Wall -Wno-shadow -Wcast-qual 
-Wno-sign-conversion -Wno-sign-compare -Wno-parentheses
 -Wno-sign-compare  -Wuninitialized -Wframe-address -Wstrict-aliasing 
-Wfatal-errors -Wimplicit-function-declaration -Wno-unused-label
 -Wreturn-type -Wunused-function -Wfatal-errors -I. -I. -I./../e 
-I./../system -I./../../include -I./../c -I/<>/M2/include
 -I/<>/M2/include -I/<>/M2/usr-host/include 
-I/<>/M2/include -I/<>/M2/include
 -I/<>/M2/usr-host/include -I/<>/M2/include 
-I/<>/M2/include -I/<>/M2/usr-host/include
 -Wdate-time -D_FORTIFY_SOURCE=3 -isystem /usr/include/libxml2 
-I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular
 -DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time 
-D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib -I/usr/include/cdd
 -I/usr/include/eigen3  -I/usr/include/python3.12 -I/usr/include 
-DBOOST_STACKTRACE_LINK -isystem /usr/include/libxml2
 -I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular 
-DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time

 -D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib
-I/usr/include/cdd -I/usr/include/eigen3  -I/usr/include/python3.12
-I/usr/include -DBOOST_STACKTRACE_LINK -isystem /usr/include/libxml2 
-I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular
 -DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time 
-D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib -I/usr/include/cdd
 -I/usr/include/eigen3  -I/usr/include/python3.12 -I/usr/include 
-DBOOST_STACKTRACE_LINK -DNDEBUG -Wno-unknown-pragmas  -c

 -Wno-unused-value -Wno-unused-but-set-variable
-Wno-maybe-uninitialized util-tmp.c -o util.o
util.d: In function ‘util_getSequenceOfPairsOfSmallIntegers_1’:
util.d:52:12: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
   52 |  is x:Sequence  do getSequenceOfPairsOfSmallIntegers(x)
  |^~
In file included from ./../../include/M2/gc-include.h:44,
 from util-exports.h:6,
 from util-tmp.c:1:
util.d:52:29: note: object of size 4 allocated by ‘GC_malloc_atomic’
   52 |  is x:Sequence  do getSequenceOfPairsOfSmallIntegers(x)
  | ^~~~
util.d: In function ‘util_getSequenceOfSmallIntegers_1’:
util.d:102:19: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
  102 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |   ^~
util.d:102:36: note: object of size 4 allocated by ‘GC_malloc_atomic’
  102 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |^~~~
util.d: In function ‘util_getNullOrSequenceOfSmallIntegers’:
util.d:110:19: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
  110 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |   ^~
util.d:110:36: note: object of size 4 allocated by ‘GC_malloc_atomic’
  110 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |^~~~
util.d: In function ‘util_getSequenceOfStrings’:
util.d:120:12: warning: array subscript ‘struct
M2_ArrayString_struct[0]’ is partly outside array bounds of ‘unsigned 
char[8]’ [-Warray-bounds=]

  120 |  new array(string) len length(s) do (
  |^~
util.d:120:32: note: object of size 8 allocated by ‘GC_malloc’
  120 |  new array(string) len length(s) do (
  |^
util.d: In function ‘util_getSequenceOfRingElements’:
util.d:151:12: warning: array subscript ‘struct
engine_RawRingElementArray_struct[0]’ is partly outside array bounds
of ‘unsigned char[8]’ [-Warray-bounds=]
  151 |  is a:RawRingElementCell do RawRingElementArray(a.p)
  |^~
util.d:151:44: note: object of size 8 allocated by ‘GC_malloc’
  151 |  is a:RawRingElementCell do RawRingElementArray(a.p)
  |^
util.d: In function ‘util_getSequenceOfMatrices’:
util.d:170:13: warning: array subscript ‘struct
engine_RawMatrixArray_struct[0]’ is partly outside array bounds of 
‘unsigned char[8]’ [-Warray-bounds=]

  170 |  is 

Bug#1059066: transition: nauty

[Torrance, Douglas]

On Mon 15 Jan 2024 10:20:44 PM +01, Sebastian Ramacher  
wrote:

Control: tags -1 confirmed

On 2023-12-19 23:02:13 +, Torrance, Douglas wrote:

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: normal

Hello!

I am requesting a transition slot for nauty.


Please go ahead.


Thank you!

New versions of nauty, normaliz, and libgraph-nauty-perl have now been uploaded
to unstable.

In my original bug report, I mistakenly said that pynauty would need a new
source upload, but it already listed libnauty-dev instead of libnauty2-dev
in its Build-Depends, so a binNMU will be sufficient for it.

Doug


signature.asc
Description: PGP signature

Bug#1057405: Processed: Fix version number

[Torrance, Douglas]

Control: fixed -1 2.8.8+ds-2~exp1

On Wed 20 Dec 2023 12:33:04 AM GMT, "Debian Bug Tracking System" 
 wrote:

Processing control commands:


fixed -1 2.88+ds-2~exp1

Bug #1057405 {Done: Bo YU } [src:nauty] pynormaliz
ftbfs with Python 3.12
Bug #1057412 {Done: Bo YU } [src:nauty]
pynormaliz: FTBFS in testing and unstable
The source 'nauty' and version '2.88+ds-2~exp1' do not appear to match
any binary packages


Indeed they don't!  Let's try that again..


Marked as fixed in versions nauty/2.88+ds-2~exp1.
Marked as fixed in versions nauty/2.88+ds-2~exp1.




signature.asc
Description: PGP signature

Bug#1057405: Fix version number

[Torrance, Douglas]

Control: fixed -1 2.88+ds-2~exp1

nauty's reversed dependencies are still marked as AUTORM because of this
bug, possibly because it is marked as fixed in a pynormaliz version which 
islower than the nauty version?

I'm updating the "fixed" version to 2.8.8+ds-2~exp1, which just entered
experimental and has the version number hardcoded into the library name
to trigger transitions at new releases.  This should prevent this problem from
happening in the future.

Doug


signature.asc
Description: PGP signature

Bug#1059066: transition: nauty

[Torrance, Douglas]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: normal

Hello!

I am requesting a transition slot for nauty.

The version number is now included in the library name to force a
transition at each new release and avoid bugs like #1057405.  (A program
linked against a newer version of libnauty than the one it was compiled
against will exit.)  The development package has also been renamed from
libnauty2-dev -> libnauty2-dev.

The new package (nauty 2.8.8+ds-2~exp1) just cleared the NEW queue and
its auto transition page at [1] looks correct.

All three reverse dependencies (pynauty, libgraph-nauty-perl, and
normaliz) will need source uploads to switch libnauty2-dev to
libnauty-dev in their Build-Depends.  But future transitions should be
much smoother!

Thanks,
Doug

Ben file:

title = "nauty";
is_affected = .depends ~ "libnauty2" | .depends ~ "libnauty2-dev" | .depends ~ 
"libnauty-2.8.8" | .depends ~ "libnauty-dev";
is_good = .depends ~ "libnauty-2.8.8" | .depends ~ "libnauty-dev";
is_bad = .depends ~ "libnauty2" | .depends ~ "libnauty2-dev";

[1] https://release.debian.org/transitions/html/auto-nauty.html


signature.asc
Description: PGP signature

Bug#1057405: pynormaliz ftbfs with Python 3.12

[Torrance, Douglas]

Control: reassign -1 src:nauty  2.8.8+ds-1

On Sun 10 Dec 2023 12:08:31 AM +08, Bo YU  wrote:

[[PGP Signed Part:Undecided]]
On Mon, Dec 04, 2023 at 02:22:43PM +0100, Matthias Klose wrote:

Package: src:pynormaliz
Version: 2.18+ds-1
Severity: serious
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

pynormaliz ftbfs with Python 3.12:


[...]
dh execute_after_dh_auto_build --buildsystem=pybuild
make[1]: Leaving directory '/<>'
  dh_auto_test -a -O--buildsystem=pybuild
I: pybuild base:310: cd
/<>/.pybuild/cpython3_3.12/build;
PYTHONPATH=/<>/.pybuild/cpython3_3.12/build python3.12 
tests/runtests.py

Error: nauty.c version mismatch
E: pybuild pybuild:395: test: plugin distutils failed with: exit
code=1: cd /<>/.pybuild/cpython3_3.12/build; 
PYTHONPATH={build_dir} {interpreter} tests/runtests.py

I: pybuild base:310: cd
/<>/.pybuild/cpython3_3.11/build;
PYTHONPATH=/<>/.pybuild/cpython3_3.11/build python3.11 
tests/runtests.py

Error: nauty.c version mismatch
E: pybuild pybuild:395: test: plugin distutils failed with: exit
code=1: cd /<>/.pybuild/cpython3_3.11/build; 
PYTHONPATH={build_dir} {interpreter} tests/runtests.py

dh_auto_test: error: pybuild --test -i python{version} -p "3.12
3.11" returned exit code 13
make: *** [debian/rules:9: binary-arch] Error 25



I have spent some time looking at this and I'm more inclined to think
about that this issue has nothing to do with python3.12.

The error from (lib)nauty, unfortunately I did not find the root cause.
The error prototype is defined:
https://salsa.debian.org/science-team/nauty/-/blame/master/nauty.c?page=2#L1175

pynormaliz use libnormaliz that defined some header files in
/usr/include/libnormaliz/ which has relative with nauty.

In fact even on python3.12 the pynormaliz package can be built with
nauty 2.8.6+ds-2. Now the failed version is on nauty 2.8.8+ds-1. So if
you look at the update for nauty and then have a better understand:
https://tracker.debian.org/pkg/nauty

So I suspected the root cause is that upgrading of nauty. If someone
help me to understand the specially call chain or debug method I'm
appreciate it.


I think this is really a nauty bug, and so it's showing up in normaliz and 
consequently pynormaliz.  Here it is in normaliz, for example:

$ cat cube_3.in 
amb_space 3

constraints 6 symbolic
x[1] >= 0;
x[2] >= 0;
x[3] >= 0;
x[1] <= 1;
x[2] <= 1;
x[3] <= 1;
EuclideanAutomorphisms
$ normaliz cube_3.in 
Error: nauty.c version mismatch


I think the underlying problem is that nauty forces all of its reverse 
dependencies to be built against the latest version with the nauty_check() 
function.  But currently, we're not bumping the SONAME version when this 
happens to trigger a transition.  Maybe we should do that.

Doug


signature.asc
Description: PGP signature

Bug#1043417: libwraster6: libwraster ABI breakage

[Torrance, Douglas]

Hi Andreas,

On Thu 10 Aug 2023 06:14:44 PM +02, Andreas Metzler  wrote:

already communicated upstream, lets add a blocker bug. The new release
bumped the symbol version of all symbols from LIBWRASTER6 to
LIBWRASTER7, i.e. we have got total ABI breakage, none of the previously
exported symbols are exported anymore.
-
ametzler@argenau:~$ wmweather+ ; echo $?
wmweather+: /lib/x86_64-linux-gnu/libwraster.so.6: version
`LIBWRASTER6' not found (required by wmweather+)
1
-

Upstream had introduced a script for automatic symbol versioning,
however given a libtool version string current:revision:age it
constructs the symbol versioning from $current instead of the soname.
libwraster went from 6:0:0 to 7:0:1 (no soname change).


I've applied the patch that you submitted upstream [1] to the package.  I
think this should fix the issue.  See the latest draft in Salsa [2].

Does this look okay?

Doug

[1] https://groups.google.com/g/wmaker-dev/c/TO106V4iiOo/m/D5oUWxBCDgAJ
[2] https://salsa.debian.org/wmaker-team/wmaker


signature.asc
Description: PGP signature

Bug#1012500: ITP: latte-int -- Lattice point Enumeration

[Torrance, Douglas]

Hi David,

On Sat 29 Jul 2023 08:48:21 AM -03, David Bremner  wrote:

Are you still working on this? For what it's worth I started some
packages for my own use at

 https://salsa.debian.org/bremner/latte


Thanks for the reminder!  The package is essentially done, but it had slipped
off my radar.  I just uploaded it to the NEW queue.

Doug


signature.asc
Description: PGP signature

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Torrance, Douglas]

Control: severity -1 important

On Thu 13 Jul 2023 12:21:48 PM -04, Doug Torrance  
wrote:

[[PGP Signed Part:Undecided]]
Control: forwarded -1 https://github.com/algebraic-solving/msolve/issues/66

On Mon 10 Jul 2023 03:33:43 PM +03, Adrian Bunk  wrote:

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity


[[End of PGP Signed Part]]


The latest upload (0.5.0-2) of msolve skips the tests on 32-bit architectures
so that it will still build.  The issue has been reported upstream and hopefully
will be fixed in a future release.

Since the program still works for some inputs on these architectures, I'm
dropping the severity of the bug to "important".


signature.asc
Description: PGP signature

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Torrance, Douglas]

Control: forwarded -1 https://github.com/algebraic-solving/msolve/issues/66

On Mon 10 Jul 2023 03:33:43 PM +03, Adrian Bunk  wrote:

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity




signature.asc
Description: PGP signature

Bug#1034656: ITP: geneagrapher-core -- request and build graphs of records from the Math Genealogy Project

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: geneagrapher-core
 Version : 0.1.0
 Upstream Author : David Alber 
* URL : https://github.com/davidalber/geneagrapher-core
* License : MIT
 Programming Lang: Python
 Description : request and build graphs of records from the Math Genealogy 
Project

Geneagrapher is a tool for extracting information from the
Mathematics Genealogy Project to form a math family tree, where
connections are between advisors and their students.

This package contains the core data-grabbing and manipulation
functions needed to build a math family tree. The functionality here
is low level and intended to support the development of other
tools. If you just want to build a geneagraph, take a look at
Geneagrapher. If you want to get mathematician records and use them in
code, then this project may be useful to you.

Note that this is a dependency of geneagrapher, which is already in Debian,
as of the latest release.  I intend to maintain this package under the
umbrella of the Debian Python Team.


signature.asc
Description: PGP signature

Bug#1034638: wmaker: comments in appearance.menu not allowed

[Torrance, Douglas]

Control: forwarded -1 https://github.com/window-maker/wmaker/issues/28

On Thu 20 Apr 2023 11:31:51 AM -04, Helge Kreutzmann  
wrote:

[[PGP Signed Part:Undecided]]
Package: wmaker
Version: 0.95.9-3+b2
Severity: minor

Yesterday I got the following error messaage:
2023-04-19T20:00:02.520024+02:00 twentytwo
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:885)):
warnung: Syntaxfehler in file /usr/share/WindowMaker/appearance.menu,
Zeile 1: Zeichenkette, Binärdaten, Array oder Dictionary
erwartet. Zeichenketten ggf. mit " einklammern.
2023-04-19T20:00:02.521878+02:00 twentytwo 
/usr/libexec/WindowMaker/wmaker[2864]: (getPropList(proplist.c:888)): warnung: 
Kommentare sind in Domänendaten von WindowMaker nicht erlaubt.

In english:
Warning: Syntaxerror in  file /usr/share/WindowMaker/appearance.menu line 1: String, 
binary data, array or dictionary expected. Escape strings possibly by "
Warning: Comments are not allowed within domain names from window maker.


# head /usr/share/WindowMaker/appearance.menu
#include "wmmacros"

Appearance MENU
  "Background" OPEN_MENU background.menu


Thanks for the reported!  Forwarding upstream.


signature.asc
Description: PGP signature

Bug#1034619: ITP: msolve -- computer algebra algorithms for solving polynomial systems

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: msolve
 Version : 0.4.9
 Upstream Author : Jérémy Berthomieu ,
   Christian Eder 
   Mohab Safey El Din 
* URL : https://msolve.lip6.fr/
* License : GPL
 Programming Lang: C
 Description : computer algebra algorithms for solving polynomial systems

msolve is an open source C library implementing computer algebra
algorithms for solving polynomial systems (with rational coefficients
or coefficients in a prime field).

Currently, with msolve, you can basically solve multivariate
polynomial systems. This encompasses:

* the computation of Groebner bases
* real root isolation of the solutions to polynomial systems
* the computation of the dimension and the degree of the solution set
 and many other things you can do using msolve.

I plan to maintain this package under the umbrella of the Debian Math Team.


signature.asc
Description: PGP signature

Bug#1031504: ITP: pynormaliz -- Python bindings for LibNormaliz

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: pynormaliz
 Version : 2.18
 Upstream Author : Sebastian Gutsche 
* URL : https://github.com/Normaliz/PyNormaliz
* License : GPL-2+
 Programming Lang: Python
 Description : Python bindings for LibNormaliz

Normaliz is an open source tool for computations in affine monoids,
vector configurations, lattice polytopes, and rational
cones. Normaliz also computes algebraic polyhedra, i.e., polyhedra
defined over real algebraic extensions of Q.

PyNormaliz provides an interface to Normaliz via libNormaliz. It
offers the complete functionality of Normaliz, and can be used
interactively from Python.

I plan to maintain this package under the umbrella of the Debian
Python Team.


signature.asc
Description: PGP signature

Bug#1026000: ITP: git-delete-merged-branches -- command-line tool to delete merged git branches

[Torrance, Douglas]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Doug Torrance 
X-Debbugs-Cc: dtorra...@piedmont.edu
Severity: wishlist

* Package name: git-delete-merged-branches
 Version : 7.2.2
 Upstream Author : Sebastian Pipping 
* URL : https://github.com/hartwork/git-delete-merged-branches
* License : GPL
 Programming Lang: Python
 Description : command-line tool to delete merged git branches

A convenient command-line tool helping you keep repositories clean.

Features:
* Supports deletion of both local and remote branches
* Detects multiple forms of de-facto merges (rebase merges, squash merges
  (needs --effort=3), single or range cherry-picks… leveraging git cherry)
* Supports workflows with multiple release branches, e.g. only delete
  branches that have been merged to all of master, dev and staging
* Quick interactive configuration
* Provider agnostic: Works with GitHub, GitLab, Gitea and any other Git
hosting
* Takes safety seriously

I plan to maintain this package under the umbrella of the Debian Python Team.

Note that this tool is distinct from the git-delete-merged-branches utility in
the git-extras package.


signature.asc
Description: PGP signature

Bug#617296: debian packages of RStudio

[Torrance, Douglas]

On Mon 05 Dec 2022 11:24:22 AM -05, Andreas Tille  wrote:

Hi Neal,

Am Mon, Dec 05, 2022 at 07:55:36AM -0800 schrieb Neal Fultz:

I saw you left a ticket on the github repo for estimatr that I used to work
on about debian support.

I had started working on packaging RStudio for debian, but nobody ever
wrote back to my post:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617296#204


Great you worked on packaging RStudio.  It would be really welcome, if
you would move the package development to Debian R pkg team at

   https://salsa.debian.org/r-pkg-team/
 

It is something I'd like to eventually get into the main debian
repositories, was curious if you have any advice, it's the most confusing
build system I've had to deal with. I should have more time for open source
Q1 next year.


I have moved the rstudio repository on Salsa to R-pkg-team[1] and merged
those parts of your packaging from mentors into this.  I've droped the
unused example boilerplates and did some other polishing of your work.

Please create a login at salsa.debian.org and I'll add you to the
r-pkg-team to enable you contributing to this package.  Please note:
We do not work with mentors.debian.net for sponsoring inside the team.
You can ping us over the mailing list

debia...@lists.debian.org

for any packaging question.

I personally would love to see rstudio packaged and I think the most
promising way is to move the discussion about this to this list.

Kind regards
Andreas.

[1] https://salsa.debian.org/r-pkg-team/rstudio


I played around a little bit with packaging RStudio about a year ago.  If it's
any help, here's a link to my work:
https://salsa.debian.org/dtorrance/rstudio

Doug


signature.asc
Description: PGP signature

Bug#1021690: RM: r-cran-m2r [mipsel] -- ROM; macaulay2 (in Depends) is not available in mipsel

[Torrance, Douglas]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: dtorra...@piedmont.edu

Hello!

I am an uploader for r-cran-m2r, which is team-mainted by the Debian R Team.
It hasn't transitioned to testing because it originally built on mipsel but
has macaulay2, which is not available in mipsel, in its Depends.

Am I correct that after removing the existing r-cran-m2r package in mipsel,
it should be able to transition to testing?

My latest upload has added macaulay2 to Build-Depends, so it should no longer
build on any architectures where macaulay2 is unavailable.

Thank you!
Doug


signature.asc
Description: PGP signature

Bug#1015537: macaulay2: ftbfs with LTO (link time optimization) enabled

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2604

On Tue, 19 Jul 2022 16:56:31 + Matthias Klose  wrote:

This package currently fails to build (at least on the amd64
architecture) with link time optimizations enabled.  For a background
for LTO please see

https://wiki.debian.org/ToolChain/LTO

The goal is to enable this optimization by default in an upcoming
Debian release in dpkg-buildflags for 64bit architectures.  The goal
is to get this package to build with link time optimizations, or to
explicitly disable link time optimizations for this package build.

To reproduce the build failure, enable the lto optimization in
testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS
in the debian/rules file, or if this macro is unset, just set it:

export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

Please try to fix the build with lto enabled, fixing the packaging or
forwarding the issue upstream. If the issue cannot be fixed,
explicitly disallow building the package with lto by adding to your
rules file:

export DEB_BUILD_MAINT_OPTIONS = optimize=-lto

or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS.

The full build log can be found at:
http://qa-logs.debian.net/2022/06/09/dpkglto/macaulay2_1.20+ds-4_unstable_dpkglto.log
The last lines of the build log are at the end of this report.

[...]
testing: schorder2.m2
testing: schreyer.m2
testing: schubert.m2
testing: schur.m2
testing: selectInSubring.m2
testing: singular.m2
testing: size.m2
testing: skew.m2
testing: skewmonideal.m2
testing: skewmult.m2
testing: smith.m2
testing: socket.m2
testing: sort.m2
testing: sortcol.m2
testing: sottile.m2
testing: strings.m2
testing: submatrix.m2
testing: subring.m2
testing: subsets.m2
testing: subst.m2
testing: subst2.m2
testing: subst3.m2
testing: subst4.m2
testing: subst5.m2
testing: subst6.m2
testing: subst7.m2
testing: substitute-1.2.m2
testing: sums.m2
testing: symbols.m2
testing: symmetricAlgebra.m2
testing: symmetricPowers.m2
testing: syz-schreyer-order.m2
testing: syz1.m2
testing: syz2.m2
testing: tensor.m2
testing: tensor_monoid.m2
testing: tensor_ring.m2
testing: terms.m2
testing: testdet.m2
testing: testgb.m2
testing: testing.m2
testing: testmat.m2
testing: testpromote.m2
testing: testskew.m2
testing: testsubring.m2
testing: threads.m2
testing: timing-quotient.m2
  -- occasionally caused build failures, see:
  -- https://github.com/Macaulay2/M2/issues/1804
  -- https://github.com/Macaulay2/M2/pull/1811
  -- https://github.com/Macaulay2/M2/pull/1957
  assert BinaryOperation {symbol <, tim#0, standardSecond}
timing-quotient.m2:224:1:(3):[5]: error: assertion failed:
.569765<.381781 is false


I was never able to reliably duplicate this particular error, and I think it's 
likely unrelated to LTO (see [1,2]).

However, PPA builds of Macaulay2 are now consistently failing in Ubuntu 22.10, 
which enables LTO and uses GCC 12 (the GCC version in the above log was 11), 
e.g., [3].  I've opening a corresponding issue upstream [4].

Doug

[1] https://github.com/Macaulay2/M2/issues/1804
[2] https://github.com/Macaulay2/M2/issues/2533
[3] 
https://launchpadlibrarian.net/622254125/buildlog_ubuntu-kinetic-amd64.macaulay2_1.20.0.1+git202209061708-0ppa202209021435~ubuntu22.10.1_BUILDING.txt.gz
[4] https://github.com/Macaulay2/M2/issues/2604


signature.asc
Description: PGP signature

Bug#1016261: givaro: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Torrance, Douglas]

On Fri, 29 Jul 2022 18:33:25 +0200 Lucas Nussbaum  wrote:

Source: givaro
Version: 4.2.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> Parsing file /<>/tests/test-recint_convert.C...
> Preprocessing /<>/tests/test-recint_exp.C...
> Parsing file /<>/tests/test-recint_exp.C...
> Preprocessing /<>/tests/test-recint_extra.C...
> Parsing file /<>/tests/test-recint_extra.C...
> Preprocessing /<>/tests/test-recint_rand.C...
> Parsing file /<>/tests/test-recint_rand.C...
> Preprocessing /<>/tests/test-regression.C...
> Parsing file /<>/tests/test-regression.C...
> Preprocessing /<>/tests/test-ringarith.C...
> Parsing file /<>/tests/test-ringarith.C...
> Preprocessing /<>/tests/test-rint_arith.C...
> Parsing file /<>/tests/test-rint_arith.C...
> Preprocessing /<>/tests/test-rmint_arith.C...
> Parsing file /<>/g
> E: Build killed with signal TERM after 150 minutes of inactivity


The full build log is available from:
http://qa-logs.debian.net/2022/07/28/givaro_4.2.0-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220728;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220728=lu...@debian.org=1=1=1=1#results

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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.



I think this is really a regression in Doxygen (version 1.9.4 was just uploaded
recently).  I've reported it at https://github.com/doxygen/doxygen/issues/9491.

An hacky fix is to remove the symlinks that are generated by the configure
script before building the documentation.  I'll upload a new package shortly.

Doug


signature.asc
Description: PGP signature

Bug#1015042: qepcad: FTBFS: ./source/saclib/GCSI.c:31: undefined reference to `GCM'

[Torrance, Douglas]

Control: reassign -1 src:saclib 2.2.8-4
Control: affects -1 src:qepcad

On Sat, 16 Jul 2022 15:23:42 +0200 Lucas Nussbaum  wrote:

Source: qepcad
Version: 1.74+ds-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220716 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /usr/bin/ld: /tmp/ccNUx4kV.o: in function `GCSI':
> ./source/saclib/GCSI.c:31: undefined reference to `GCM'
> /usr/bin/ld: ./source/saclib/GCSI.c:35: undefined reference to `CLOCK'
> /usr/bin/ld: ./source/saclib/GCSI.c:38: undefined reference to `GCGLOBALS'
> /usr/bin/ld: ./source/saclib/GCSI.c:42: undefined reference to `PTRRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:40: undefined reference to `PTRFIRST'
> /usr/bin/ld: ./source/saclib/GCSI.c:41: undefined reference to `ISLIST'
> /usr/bin/ld: ./source/saclib/GCSI.c:41: undefined reference to `ISGCA'
> /usr/bin/ld: ./source/saclib/GCSI.c:41: undefined reference to `ISNIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:41: undefined reference to `MARK'
> /usr/bin/ld: ./source/saclib/GCSI.c:42: undefined reference to `PTRRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:46: undefined reference to `GCGLOBALS'
> /usr/bin/ld: ./source/saclib/GCSI.c:48: undefined reference to `RED'
> /usr/bin/ld: ./source/saclib/GCSI.c:49: undefined reference to `SRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:57: undefined reference to `BACSTACK'
> /usr/bin/ld: ./source/saclib/GCSI.c:69: undefined reference to `AVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:69: undefined reference to `RED'
> /usr/bin/ld: ./source/saclib/GCSI.c:70: undefined reference to `RED'
> /usr/bin/ld: ./source/saclib/GCSI.c:71: undefined reference to `SRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:65: undefined reference to `MARK'
> /usr/bin/ld: ./source/saclib/GCSI.c:65: undefined reference to `ISLIST'
> /usr/bin/ld: ./source/saclib/GCSI.c:65: undefined reference to `ISGCA'
> /usr/bin/ld: ./source/saclib/GCSI.c:65: undefined reference to `ISNIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:72: undefined reference to `GCAAVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:73: undefined reference to `GCASPACEBp'
> /usr/bin/ld: ./source/saclib/GCSI.c:79: undefined reference to `NU'
> /usr/bin/ld: ./source/saclib/GCSI.c:77: undefined reference to `AVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:81: undefined reference to `AVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:81: undefined reference to `SRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:82: undefined reference to `SFIRST'
> /usr/bin/ld: ./source/saclib/GCSI.c:83: undefined reference to `AVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:80: undefined reference to `RED'
> /usr/bin/ld: ./source/saclib/GCSI.c:87: undefined reference to `SRED'
> /usr/bin/ld: ./source/saclib/GCSI.c:89: undefined reference to `GCAAVAIL'
> /usr/bin/ld: ./source/saclib/GCSI.c:91: undefined reference to `BETApp'
> /usr/bin/ld: ./source/saclib/GCSI.c:91: undefined reference to `BETAp'
> /usr/bin/ld: ./source/saclib/GCSI.c:91: undefined reference to `BETAp'
> /usr/bin/ld: ./source/saclib/GCSI.c:92: undefined reference to `GCASPACEBp'
> /usr/bin/ld: ./source/saclib/GCSI.c:93: undefined reference to `GCAFREE'
> /usr/bin/ld: ./source/saclib/GCSI.c:91: undefined reference to `BETAp'
> /usr/bin/ld: ./source/saclib/GCSI.c:101: undefined reference to `CLOCK'
> /usr/bin/ld: ./source/saclib/GCSI.c:102: undefined reference to `TAU'
> /usr/bin/ld: ./source/saclib/GCSI.c:103: undefined reference to `GCC'
> /usr/bin/ld: ./source/saclib/GCSI.c:104: undefined reference to `GCCC'
> /usr/bin/ld: ./source/saclib/GCSI.c:105: undefined reference to `GCAC'


This is actually a saclib bug.  A typo in a recent upload made it so that the
static library is an archive containing a single object file instead of all of
them.

Doug


signature.asc
Description: PGP signature

Bug#1013619: phcpack: FTBFS: mv: cannot stat 'debian/phcpack/usr/share/octave': No such file or directory

[Torrance, Douglas]

On Fri 24 Jun 2022 07:28:00 AM EDT, Lucas Nussbaum  wrote:

Source: phcpack
Version: 2.4.86+dfsg-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220624 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[1]: Entering directory '/<>'
+-+
| building PHClab |
+-+
cp --update --reflink=auto src/Octave/COPYING.txt COPYING
mkdir --parents inst
cp --update --reflink=auto src/Octave/*.m debian/PKG_ADD inst
dh_auto_install --buildsystem=octave
octave --no-gui --no-history --silent --no-init-file --no-window-system 
/usr/share/dh-octave/install-pkg.m 
/<>/phcpack-2.4.86\+dfsg/debian/tmp/usr/share/octave/packages 
/<>/phcpack-2.4.86\+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu/octave/packages
warning: creating installation directory 
/<>/debian/tmp/usr/share/octave/packages
warning: called from
install at line 36 column 5
pkg at line 603 column 9
/usr/share/dh-octave/install-pkg.m at line 38 column 1

mkdir -p debian/tmp/usr/share
mv debian/phcpack/usr/share/octave debian/tmp/usr/share
mv: cannot stat 'debian/phcpack/usr/share/octave': No such file or directory
make[1]: *** [debian/rules:81: execute_after_dh_auto_install-indep] Error 1



The full build log is available from:
http://qa-logs.debian.net/2022/06/24/phcpack_2.4.86+dfsg-1_unstable.log


Thanks for the report!  There was some recent improvements to dh_octave that
made some of the hacks I'd been using to build PHCpack's Octave interface
unnecessary.  I've done a little work already to get this fixed, and will
upload a new package soon once I've finished.

Doug


signature.asc
Description: PGP signature

Bug#1012530: 4ti2: package header files

[Torrance, Douglas]

Source: 4ti2
Version: 1.6.9+ds-4
Severity: wishlist
X-Debbugs-Cc: dtorra...@debian.org

Dear Maintainer,

4ti2 exists as a shared library.  Currently, the library files themselves
are shipped for the 4ti2 binaries' use, in /usr/lib//4ti2.
However, the header files for use with these libraries are not packaged.

Would it be possible to ship these header files with the package, or possibly
in a new lib4ti2-dev binary package?  Then they could be used to build other
packages that depend on the 4ti2 library, e.g., LattE.

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#1012500: ITP: latte-int -- Lattice point Enumeration

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@debian.org

* Package name: latte-int
 Version : 1.7.6
 Upstream Author : The LattE Team 
* URL : https://www.math.ucdavis.edu/~latte/software.php
* License : GPL
 Programming Lang: C++
 Description : Lattice point Enumeration

LattE (Lattice point Enumeration) is a computer software dedicated to
the problems of counting lattice points and integration inside convex
polytopes. LattE contains the first ever implementation of Barvinok's
algorithm. The LattE macchiato version (by M. Köppe) incorporated
fundamental improvements and speed ups.

Now the latest version, LattE integrale, has the ability to directly
compute integrals of polynomial functions over polytopes and in
particular to do exact volume computations. Version 1.6 adds the
capability of computing the highest coefficients of weighted Ehrhart
quasipolynomials.

I plan to maintain this package under the umbrella of the Debian Math Team.


signature.asc
Description: PGP signature

Bug#1011364: phcpack: FTBFS with gnat-11

[Torrance, Douglas]

On Fri 20 May 2022 05:37:23 PM EDT, Sebastian Ramacher  
wrote:

Source: phcpack
Version: 2.4.85+dfsg-5
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org


 debian/rules clean
/usr/share/ada/debian_packaging-11.mk:31: *** Please include 
/usr/share/dpkg/default.mk (or the more specific buildflags.mk and 
buildopts.mk) before /usr/share/ada/debian_packaging-11.mk.  Stop.
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2


Thanks for the report!

The fix for this particular bug is very simple (see [1]).  However, the
build then fails later on:

   gnatbind -n -static use_c2phc -o use_c2phc_binder.adb

   raised STORAGE_ERROR : stack overflow or erroneous memory access
   make[3]: *** [makefile_unix:4102: phcpy2c3.so] Error 1

I'll investigate further and hopefully upload a new package soon that fixes
both issues.

Doug

[1] https://salsa.debian.org/math-team/phcpack/-/commit/b38a6ba


signature.asc
Description: PGP signature

Bug#1010453: closed by Debian FTP Masters (reply to Doug Torrance ) (Bug#1010453: fixed in macaulay2 1.19.1+ds-9)

[Torrance, Douglas]

On Mon 02 May 2022 12:11:48 AM EDT, Paul Gevers  wrote:

Hi,

On 02-05-2022 02:39, Debian Bug Tracking System wrote:

  macaulay2 (1.19.1+ds-9) unstable; urgency=medium
  .
* debian/tests/control
  - Mark package-tests as flaky since it regularly times out on armhf
(Closes: #1010453).


Hmmm. May I recommend something else?

Marking autopkgtests that regularly time out is a solution that has a 
relative high price on the infrastructure. These tests are still run 
(until they time out), while they don't influencing migration of any 
package if the package contain more than one autopkgtest. Marking tests 
flaky is nearly only useful if a human is regularly going to look at the 
results and does something with it. To be honest, I'm not expecting that 
here (but let me know if I'm making a wrong assumption here).


Instead, I recommend to not run the test at all on armhf if we're going 
to ignore the result there (successful runs also take long), but use it 
normally on all other architectures. There's the "Architecture" field 
available in debian/tests/control that can be used to achieve that in a 
correct way. It understands the regular syntax so "!armhf" should suffice.


That seems like a good solution -- thanks for the suggestion!

I'll switch to this on the next upload (likely after Macaulay2 1.20 is released
in a few weeks).

Doug


signature.asc
Description: PGP signature

Bug#1010096: macaulay2: FTBFS on ppc64el

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2119

On Sun 24 Apr 2022 06:26:35 AM EDT, Sebastian Ramacher  
wrote:

macaulay2 FTBFS on ppc64el:

 ulimit -c unlimited; ulimit -t 700; ulimit -m 85; ulimit -s 8192; ulimit -n 512;  cd /tmp/M2-2532003-0/31-rundir/; GC_MAXIMUM_HEAP_SIZE=400M 
"/<>/M2/usr-dist/powerpc64le-Linux-Debian-buildd-unstable/bin/M2-binary" -q --int --no-randomize --no-readline --silent --stop --print-width 
77 -e 'needsPackage("AssociativeAlgebras",Reload=>true,FileName=>"/<>/M2/Macaulay2/packages/AssociativeAlgebras.m2")' 
<"/tmp/M2-2532003-0/30.m2" >>"/tmp/M2-2532003-0/30.tmp" 2>&1
/tmp/M2-2532003-0/30.tmp:0:1: (output file) error: Macaulay2 killed by signal 9
/tmp/M2-2532003-0/30.m2:0:1: (input file)
M2: *** Error 9
 -- 6.50792 seconds elapsed
 -- running   check(26, "AssociativeAlgebras")   -- 
6.69457 seconds elapsed
 -- running   check(27, "AssociativeAlgebras")   -- 
7.99133 seconds elapsed
 -- running   check(28, "AssociativeAlgebras")   -- 
6.99254 seconds elapsed
 -- capturing check(29, "AssociativeAlgebras")   -- 
8.69268 seconds elapsed
 -- skipping  check(30, "AssociativeAlgebras")   -- 
0.000117095 seconds elapsed
 -- running   check(31, "AssociativeAlgebras")   -- 
7.8834 seconds elapsed
 -- running   check(32, "AssociativeAlgebras")   -- 
8.43175 seconds elapsed
 -- running   check(33, "AssociativeAlgebras")   -- 
6.76101 seconds elapsed
AssociativeAlgebras/tests.m2:729:1-752:1: error:
 -- -- -*- M2-comint -*- hash: 1928805808
 -- Killed
 -- 
../m2/debugging.m2:23:6:(1):[9]: error: test(s) #25 of package AssociativeAlgebras failed.

../m2/testing.m2:135:9:(1):[8]: --back trace--
../m2/methods.m2:154:80:(1):[7]: --back trace--
../m2/option.m2:17:8:(1):[6]: --back trace--
../m2/testing.m2:108:33:(1):[5]: --back trace--
../m2/methods.m2:154:80:(1):[4]: --back trace--
../m2/option.m2:17:8:(1):[3]: --back trace--
currentString:1:82:(3):[2]: --back trace--
Macaulay2/Core/startup.m2.in:561:33:(0):[1]: --back trace--
Macaulay2/Core/startup.m2.in:661:6:(0): --back trace--
make[4]: *** [Makefile:41: check-AssociativeAlgebras] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=ppc64el=1.19.1%2Bds-6%2Bb2=1650754325=0


Thanks for the report!

The tests for the AssociativeAlgebras package have a history of being flaky.
I'll set it to skip this test (and #31, which failed on another build [1]) on
ppc64el in the next upload.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=ppc64el=1.19.1%2Bds-6%2Bb2=1650804921=0


signature.asc
Description: PGP signature

Bug#1009838: macaulay2: wrong dependency on base-files from linktree

[Torrance, Douglas]

On Mon, 18 Apr 2022 13:45:28 -0700 Steve Langasek 
 wrote:

The macaulay2-common package has a versioned dependency on base-files that
is generated by dh_linktree.  This is because
debian/macaulay2-common.linktrees generates links to
usr/share/common-licenses/ that are then resolved to a dependency.

- You do not have to depend on base-files, this package is essential.
- The only time you need to depend on an essential package is if you have a
  versioned dependency.  However, in this case the versioned dependency is
  itself wrong; dh_linktree is generating a >= versioned dependency against
  the version of base-files that is currently installed at build time, but
  that version is arbitrary and is not an indication of the minimum version
  required (GPL-2 and GPL-3 are not new).
- You should not in general need to make symlinks to the license files.  All
  packages have their license information available in the standard location
  of /usr/share/doc/$package/copyright, as this package does.

We noticed this in Ubuntu because an upload of base-files triggered a run of
macaulay2's autopkgtests, which take a long time to run and are irrelevant
to a base-files update.

Please drop these links, and with them the gratuitous versioned dependency.


Thanks for the report!

I'd added the symlinks because the Macaulay2 documentation includes these
license files, and this seemed like a slightly easier solution to shipping
redundant copies of the GPL than patching the documentation itself.  I didn't
think about the repercussions of using dh_linktrees to do this!

I'll upload a new version soon with a fix.

Doug



signature.asc
Description: PGP signature

Bug#493784: libgc: please provide a build with --enable-large-config

[Torrance, Douglas]

On Mon, 04 Aug 2008 23:26:10 +0200 Bernd Zeimetz  wrote:

for some use cases ([1] for example) it would be useful to have a
version of libgc available, which was built with --enable-large-config.
I didn't dig into libgc to find out what the best way would be to
achive this, but I'm sure there is one ;)


I would also like to see this.  libgc is used by Macaulay2, a software
platform for algebraic geometry and commutative algebra research, and
the memory limitations of the current Debian libgc package aren't
sufficient for some problems [3].

[3] https://github.com/Macaulay2/M2/issues/2445


signature.asc
Description: PGP signature

Bug#1008041: wmforecast: invalid Uploaders field: missing comma between Doug Torrance and Andreas Metzler

[Torrance, Douglas]

On Mon 21 Mar 2022 06:28:52 AM EDT, Paul Wise  wrote:

wmforecast 1.8-1 introduced an invalid Uploaders field, that is missing
a comma between Doug Torrance and Andreas Metzler.

   $ apt-cache showsrc wmforecast | grep -E '^$|^Version|^Uploaders'
   Version: 1.7-1.1
   Uploaders: Doug Torrance , Andreas Metzler 

   
   Version: 1.8-1

   Uploaders: Doug Torrance  Andreas Metzler 


According to Debian policy 5.6.3 the Uploaders field must separate
individual uploaders using commas:

   List of the names and email addresses of co-maintainers of the
   package, if any.
   ...
   The format of each entry is the same as that of the Maintainer
   field, and multiple entries must be comma separated.

   https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders

This is causing the DDPO and BLS cron jobs to send error mails,
please fix it as soon as possible.


Oops, sorry about introducing this bug with my last upload!  I'll upload
a new version with a comma here shortly.

Doug


signature.asc
Description: PGP signature

Bug#1000336: Upgrading tbb

[Torrance, Douglas]

On Sun 13 Mar 2022 04:50:32 PM EDT, M. Zhou  wrote:

Recently I'm not able to test the build of libtbb-dev's reverse dependencies
as my build machine was out of access. That blocks my submission of the
transition bug and hence I'm stalled at this point.
According to some archlinux developers, this transition breaks a lot of
reverse dependencies since some of the core APIs have been changed.
Please expect a relatively negative rebuild result.

Help is welcome.


I've built both mathicgb and macaulay2 in unstable against TBB 2021 from
experimental and they're both ready to go for the transition.

Doug


signature.asc
Description: PGP signature

Bug#1005379: Subject: ITP: elpa-macaulay2 -- Software system for algebraic geometry research (Emacs package)

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@debian.org

* Package name: elpa-macaulay2
 Version : 1.19.1
 Upstream Author : Dan Grayson 
* URL : http://github.com/Macaulay2/M2-emacs
* License : GPL-3+
 Programming Lang: Emacs Lisp
 Description : Software system for algebraic geometry research (Emacs 
package)

Macaulay 2 is a software system for algebraic geometry research, written by
Daniel R. Grayson and Michael E. Stillman.  Based on Groebner bases, it
provides algorithms for computing homological invariants of rings and
modules.

This package contains the modes for running Macaulay2 within Emacs and
editing Macaulay2 code.

The binary package elpa-macaulay2 already exists in the archive and is built
currently by the macaulay2 source package.  However, the code was split off into
its own repository a while ago, and I believe it would simplify things if it
had its own source package as well.

I intend to continue maintaining this package under the umbrella of the Debian
Math Team.


signature.asc
Description: PGP signature

Bug#1004462: ITP: node-should-sinon -- Sinon.js assertions for should.js

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: node-should-sinon
 Version : 0.0.6
 Upstream Author : Denis Bardadym 
* URL : https://github.com/shouldjs/sinon
* License : Expat
 Programming Lang: JavaScript
 Description : Sinon.js assertions for should.js

should is an expressive, readable, framework-agnostic assertion
library. The main goals of this library are to be expressive and to
be helpful. It keeps your test code clean, and your error messages
helpful.

This module adds additional assertions for sinon.js, which provides
standalone test spies, stubs and mocks.

Node.js is an event-based server-side JavaScript engine.

I plan to maintain this package as a member of the Debian JavaScript Team.


signature.asc
Description: PGP signature

Bug#1004400: ITP: node-less-plugin-clean-css -- clean-css plugin for less.js

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: node-less-plugin-clean-css
 Version : 1.5.1
 Upstream Author : Luke Page 
* URL : https://github.com/less/less-plugin-clean-css
* License : Apache-2.0
 Programming Lang: JavaScript
 Description : clean-css plugin for less.js

Compresses the css output from less (a backwards-compatible language
extension for CSS) using clean-css.  Specify the plugin with the
--clean-css command line option to lessc.

Node.js is an event-based server-side JavaScript engine.

The presence of this plugin in Debian will fix #977974.

I plan on maintaining this package as a member of the Debian JavaScript Team.


signature.asc
Description: PGP signature

Bug#1004220: ITP: libstatistics-r-io-perl -- Perl interface to serialized R data

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@debian.org

* Package name: libstatistics-r-io-perl
 Version : 1.0002
 Upstream Author : Davor Cubranic 
* URL : https://github.com/cubranic/Statistics-R-IO
* License : GPL
 Programming Lang: Perl
 Description : Perl interface to serialized R data

Statistics::R::IO  is a pure-Perl implementation for reading native data
files produced by the R statistical computing environment.

It provides routines for reading files in the two primary file
formats used in R for serializing native objects: RDS and RData.

I plan to maintain this package under the umbrella of the Debian Perl Team.


signature.asc
Description: PGP signature

Bug#1003709: ITP: libclass-tiny-antlers-perl -- Moose-like sugar for Class::Tiny

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: libclass-tiny-antlers-perl
 Version : 0.024
 Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Class-Tiny-Antlers
* License : GPL/Artistic
 Programming Lang: Perl
 Description : Moose-like sugar for Class::Tiny

Class::Tiny::Antlers provides Moose-like has, extends, with, before, after
and around keywords for Class::Tiny. (The with keyword requires Role::Tiny;
method modifiers require Class::Method::Modifiers.)

Class::Tiny doesn't support all Moose's attribute options; has should throw
you an error if you try to do something it doesn't support (like triggers).

Class::Tiny::Antlers does however hack in support for is => 'ro' and
Moo-style is => 'rwp', clearers and predicates.


From version 0.24, Class::Tiny::Antlers also adds support for `isa` and

`coerce` using Type::Tiny. (I mean, this is a TOBYINK module, so what do you
expect?!) Technically MooseX::Types, MouseX::Types, Specio, and Type::Nano
should work, but these are less tested.

I intend to maintain this package under the umbrella of the Debian Perl Team.


signature.asc
Description: PGP signature

Bug#1001878: liblinbox-dev should depend on libfplll-dev

[Torrance, Douglas]

Control: reopen -1
Control: found 1.7.0-1
Control: notfixed 1.7.0-1~exp1

On Sat 18 Dec 2021 09:38:16 AM EST, Doug Torrance  
wrote:
> On Sat 18 Dec 2021 02:59:31 AM EST, Tobias Hansen  wrote:
>> while building sagemath I noticed that linbox includes fplll.h in 
>> algorithms/lattice.h and algorithms/short-vector.h. Hence I think 
>> liblinbox-dev should depend on libfplll-dev.
>
> Yes, I noticed the same thing while packaging 1.7.0, and this fix has been in
> place since it was first uploaded to experimental.  See [1,2].

Oops, I misread the bug report!  It should be added to *Depends* and not just
*Build-Depends*.  I'll upload a new version shortly.

(I probably should drink coffee *before* reading bug reports...)

Doug

Bug#1001606: ITP: r-cran-m2r -- Macaulay2 interface for R

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@debian.org

* Package name: r-cran-m2r
 Version : 1.0.2
 Upstream Author : David Kahle 
* URL : https://github.com/coneill-math/m2r
* License : GPL
 Programming Lang: R
 Description : Macaulay2 interface for R

m2r was created at the American Mathematical Society's 2016 Mathematics
Research Community gathering on algebraic statistics. It connects R to a
persistent local or remote Macaulay2 session and leverages mpoly's existing
infrastructure to provide wrappers for commonly used algebraic algorithms in
a way that naturally fits into the R ecosystem, alleviating the need to
learn Macaulay2.  It is our hope that m2r will provide a flexible framework
for computations in the algebraic statistics community and beyond.

I intend to maintain this package under the umbrella of the Debian R Team.


signature.asc
Description: PGP signature

Bug#1001023: ITP: r-cran-r.rsp -- dynamic generation of scientific reports

[Torrance, Douglas]

Package: wnpp
Owner: Doug Torrance 
Severity: wishlist

* Package name: r-cran-r.rsp
  Version : 0.44.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/R.rsp
* License : LGPL-2.1
  Programming Lang: R
  Description : dynamic generation of scientific reports

The RSP markup language makes any text-based document come alive. RSP
provides a powerful markup for controlling the content and output of
LaTeX, HTML, Markdown, AsciiDoc, Sweave and knitr documents (and
more), e.g. 'Today's date is <%=Sys.Date()%>'. Contrary to many other
literate programming languages, with RSP it is straightforward to loop
over mixtures of code and text sections, e.g. in month-by-month
summaries. RSP has also several preprocessing directives for
incorporating static and dynamic contents of external files (local or
online) among other things. Functions rstring() and rcat() make it
easy to process RSP strings, rsource() sources an RSP file as it was
an R script, while rfile() compiles it (even online) into its final
output format, e.g. rfile('report.tex.rsp') generates 'report.pdf' and
rfile('report.md.rsp') generates 'report.html'. RSP is ideal for self-
contained scientific reports and R package vignettes. It's easy to use
- if you know how to write an R script, you'll be up and running
within minutes.

I plan to maintain this package under the umbrella of the Debian R Team.

Bug#1000772: macaulay2: autopkgtest regression on i386: out of memory

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2319
Control: tags -1 pending

On Sun 28 Nov 2021 02:57:24 PM EST, Paul Gevers  wrote:

Source: macaulay2
Version: 1.19+ds-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of macaulay2 the autopkgtest of macaulay2 fails
in testing when that autopkgtest is run with the binary packages of 
macaulay2 from unstable. It passes when run with only packages from

testing. In tabular form:

   passfail
macaulay2  from testing1.19+ds-3
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing
[1]. Can you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the
log file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from

macaulay2/1.19+ds-3. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=macaulay2

https://ci.debian.net/data/autopkgtest/testing/i386/m/macaulay2/17068663/log.gz

K3Surfaces
**
 -- capturing check(0, "K3Surfaces")-- 15.155 seconds elapsed
 -- capturing check(1, "K3Surfaces")-- 3.51379 seconds elapsed
 -- capturing check(2, "K3Surfaces")-- 14.3303 seconds elapsed
 -- capturing check(3, "K3Surfaces")-- 27.3209 seconds elapsed
 -- capturing check(4, "K3Surfaces")-- 1.92744 seconds elapsed
 -- capturing check(5, "K3Surfaces")-- 9.5648 seconds elapsed
 -- skipping  check(6, "K3Surfaces")-- 0.00011649 seconds
   elapsed
 -- skipping  check(7, "K3Surfaces")-- 0.7854 seconds
   elapsed
 -- capturing check(8, "K3Surfaces") 
 *** out of memory trying to allocate 131108 bytes, exiting ***


 cd /tmp/M2-2812-0/171-rundir/; GC_MAXIMUM_HEAP_SIZE=400M
 "/usr/bin/M2-binary" -q --int --no-randomize --no-readline --silent 
--stop --print-width 77 <"/tmp/M2-2812-0/170.m2" >>"/tmp/M2-2812-0/170.tmp"

/tmp/M2-2812-0/170.tmp:0:1: (output file) error: Macaulay2 exited with
status code 1
/tmp/M2-2812-0/170.m2:0:1: (input file)
M2: *** Error 1


Thanks for the report!  I've reported this upstream and have pushed a
band-aid fix to git skipping this test.  It should be fixed on the next
upload.

Doug


signature.asc
Description: PGP signature

Bug#1000348: macaulay2: FTBFS on mips64el: assert(timer((m, n) -> apply(m, i -> M(offset,n,1)), (10000,294)) < 1.5) -- timing test

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2206
Control: tags -1 pending

On Sun 21 Nov 2021 05:36:05 PM EST, Sebastian Ramacher  
wrote:

Source: macaulay2
Version: 1.19+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| testing: methods.m2
|
| oo50 : FunctionClosure
|
| ii51 : assert(timer(M, (offset,296,1)) < 0.1) -- recursion test
|
| ii52 : -- WISHLIST: M(0,301,1)
|assert(timer((m, n) -> apply(m, i -> M(offset,n,1)), (1,294)) < 
1.5) -- timing test
| Command terminated by signal 9
| 89.71user 0.16system 1:23.64elapsed 107%CPU (0avgtext+0avgdata 
125120maxresident)k
| 0inputs+0outputs (0major+6166minor)pagefaults 0swaps
| methods.errors:0: error output left here for the errors above:
| make[5]: *** [../Makefile.test:68: methods.out] Error 137

See
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=mips64el=1.19%2Bds-1=1637251853=0


Thanks for the report!  I've reported this issue upstream and pushed a commit
to git with a band-aid fix (skipping the failing test):
https://salsa.debian.org/math-team/macaulay2/-/commit/d295fa2


signature.asc
Description: PGP signature

Bug#1000350: macaulay2: FTBFS on s390x: i49 : saturate(sing2, sub(irrelTot, ring sing2)) -- SIGSEGV

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2318
Control: tags -1 pending

On Sun 21 Nov 2021 05:37:27 PM EST, Sebastian Ramacher  
wrote:

Source: macaulay2
Version: 1.19+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

|  -- making example results for "multiplicity"
-- 0.516413 seconds elapsed
|  -- storing example results in 
../../../usr-dist/common/share/doc/Macaulay2/ReesAlgebra/example-output/_multiplicity.out
| ../../m2/debugging.m2:23:6:(1):[9]: error: installPackage: 1 error(s) 
occurred running examples for package ReesAlgebra:
|
| ___Plane__Curve__Singularities.errors
| *
|
| i48 : time sing2 = ideal singularLocus strictTransform2;
|  -- used 0.777859 seconds
|
|  ZZ
| o48 : Ideal of -[p ..p , w ..w , x..y]
|32003  0   2   0   1
|
| i49 : saturate(sing2, sub(irrelTot, ring sing2))
| -- SIGSEGV
| -* stack trace, pid: 3693279
| Segmentation fault (core dumped)
|
| ../../m2/installPackage.m2:726:18:(1):[8]: --back trace--
| ../../m2/methods.m2:154:80:(1):[7]: --back trace--
| ../../m2/option.m2:17:8:(1):[6]: --back trace--
| ../../m2/installPackage.m2:604:5:(1):[5]: --back trace--
| ../../m2/methods.m2:154:80:(1):[4]: --back trace--
| ../../m2/option.m2:17:8:(1):[3]: --back trace--
| currentString:1:1:(3):[2]: --back trace--
| Macaulay2/Core/startup.m2.in:561:33:(0):[1]: --back trace--
| Macaulay2/Core/startup.m2.in:661:6:(0): --back trace--
| make[3]: *** [Makefile:94: 
/<>/M2/usr-dist/s390x-Linux-Debian-buildd-unstable/lib/s390x-linux-gnu/Macaulay2/ReesAlgebra/.installed]
 Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=s390x=1.19%2Bds-1=1637349812=0


Thanks for the report!  I reported this issue upstream and pushed a band-aid
fix (using a cached version of the documentation example in question) to
git a few days ago:
https://salsa.debian.org/math-team/macaulay2/-/commit/81366d4


signature.asc
Description: PGP signature

Bug#992003: [Debian-science-sagemath] Singular update

[Torrance, Douglas]

On Sat 20 Nov 2021 02:50:55 AM EST, Tobias Hansen  wrote:

any chance we could get an update of singular to 4.2.1.p0 in experimental? I 
tried to do it myself once but the package has many patches and it was 
difficult to get everything right.


I'm also interested in getting singular 4.2.x in Debian, as Macaulay2 requires
it as well.  (Fortunately, it still works with 4.1.x with a patch, but upstream
claims it's buggy.)

Doug


signature.asc
Description: PGP signature

Bug#950008: Sv: Bug#950008: gfan: assertion fails on riscv64

[Torrance, Douglas]

On Tue, 9 Nov 2021 01:13:25 + "Torrance, Douglas"  
wrote:

On Tue, 28 Jan 2020 13:28:02 + Anders Nedergaard Jensen  
wrote:
> Thanks for the bug report.
> Line 30 of application.cpp looks suspicious:
>   while(p[l]!=0 && p[l]!='/');
> Does it help to change it to
>   while(l!=0 && p[l]!='/');
> ?
> If not, I think I need to know what the char* argv[0] points to when main is  
called.

I included a slight modification of this patch (with "l >= 0" instead of
"l != 0") in the latest gfan upload (0.6.2-5).  Fingers crossed that it
fixes things on riscv64!


This patch (attached) appears to have worked!  The most recent build of
Macaulay2 on riscv64 [1], while failing for other reasons, got past the gfan
detection stage:

   checking whether the package gfan is installed... yes

I'll wait to see if it works for the next riscv64 build of Sage before
closing this bug.

Doug

[1] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=riscv64=1.19%2Bds-1=1637315650=0
Description: Properly terminate while loop when finding application name.
Author: Anders Nedergaard Jensen 
Origin: https://bugs.debian.org/950008#17
Bug-Debian: https://bugs.debian.org/950008
Last-Update: 2021-11-08

--- a/src/application.cpp
+++ b/src/application.cpp
@@ -26,7 +26,7 @@
 {
   l--;
 }
-  while(p[l]!=0 && p[l]!='/');
+  while(l >= 0 && p[l]!='/');
 
   return p+l+1;
 }


signature.asc
Description: PGP signature

Bug#950008: Sv: Bug#950008: gfan: assertion fails on riscv64

[Torrance, Douglas]

On Tue, 28 Jan 2020 13:28:02 + Anders Nedergaard Jensen  
wrote:

Thanks for the bug report.
Line 30 of application.cpp looks suspicious:
  while(p[l]!=0 && p[l]!='/');
Does it help to change it to
  while(l!=0 && p[l]!='/');
?
If not, I think I need to know what the char* argv[0] points to when main is  
called.


I included a slight modification of this patch (with "l >= 0" instead of
"l != 0") in the latest gfan upload (0.6.2-5).  Fingers crossed that it
fixes things on riscv64!

Doug



signature.asc
Description: PGP signature

Bug#997249: mpsolve: FTBFS: ./conftest.c:34: undefined reference to `yywrap'

[Torrance, Douglas]

Control: tags -1 confirmed

On Sat, 23 Oct 2021 21:18:43 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.


I believe this became an issue when autoconf was bumped from 2.69 to 2.71
in unstable a few months ago.

Fortunately, it has been reported [1] and fixed [2] upstream.  I'll adapt
the patch to quilt and upload a new version shortly.

[1] https://github.com/robol/MPSolve/issues/27
[2] https://github.com/robol/MPSolve/commit/3a89087


signature.asc
Description: PGP signature

Bug#998244: lists.debian.org: request for debian-math mailing list

[Torrance, Douglas]

Package: lists.debian.org
Severity: wishlist
X-Debbugs-Cc: dtorra...@piedmont.edu

Hello!

I would like to request a new mailing list to discuss the use and packaging
of mathematics software in Debian.

Name: debian-math

Rationale: There is a wide variety of mathematics software in Debian,
including an entire section of the archive [1].  Currently, however, there
is no mailing list to discuss mathematics software specifically.  Existing
lists are either too general (e.g., debian-science [2]) or too specific
(e.g., debian-science-sagemath [3]).  Such a list could serve as a way
for users and developers of mathematics software in Debian to communicate
with one another, and in particular members of the new proposed Debian
Math Team [4].

Short description: Using Debian for mathematics and related research

Long description: Discussion of issues relating to the use of Debian for
mathematics research, including useful packages, particular problems faced by
mathematician using Debian, how to make Debian more useful to mathematicians,
etc.

Category: Developers

Subscription Policy:  open

Post Policy:  open

Web Archive:  yes

Thank you!

[1] https://packages.debian.org/stable/math/
[2] https://lists.debian.org/debian-science/
[3] 
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
[4] https://lists.debian.org/debian-science/2021/10/msg00034.html


signature.asc
Description: PGP signature

Bug#973192: python-gear: FTBFS: make[1]: pyversions: No such file or directory

[Torrance, Douglas]

Control: tags -1 patch

On Tue, 27 Oct 2020 18:21:49 +0100 Lucas Nussbaum  wrote:


During a rebuild of all packages in sid, your package failed to build
on amd64.



[ snip ]



> ==
> FAIL: gear.tests.test_functional.TestFunctional.test_job(ssl)
> gear.tests.test_functional.TestFunctional.test_job(ssl)
> --
> testtools.testresult.real._StringException: pythonlogging:'': {{{
> Disconnected from 127.0.0.1 port 35395
> Disconnected from 127.0.0.1 port 35395
> Exception while connecting to 
> Traceback (most recent call last):
>   File "/<>/gear/__init__.py", line 756, in _connectLoop
> conn.reconnect()
>   File "/<>/gear/__init__.py", line 232, in reconnect
> self.connect()
>   File "/<>/gear/__init__.py", line 189, in connect
> s = ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_TLSv1,
>   File "/usr/lib/python3.9/ssl.py", line 1402, in wrap_socket
> context.load_cert_chain(certfile, keyfile)
> ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:4021)


This has been fixed upstream; see [1].  I've adapted the patch to quilt and
have prepared an NMU.  See the attached debdiff.
diff -Nru python-gear-0.5.8/debian/changelog python-gear-0.5.8/debian/changelog
--- python-gear-0.5.8/debian/changelog	2019-07-16 08:32:22.0 -0400
+++ python-gear-0.5.8/debian/changelog	2021-10-27 15:36:23.0 -0400
@@ -1,3 +1,11 @@
+python-gear (0.5.8-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/bump-crypto-requirement.patch
+-  New patch; use a stronger key during tests (Closes: #973192)
+
+ -- Doug Torrance   Wed, 27 Oct 2021 15:36:23 -0400
+
 python-gear (0.5.8-5) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-gear-0.5.8/debian/patches/bump-crypto-requirement.patch python-gear-0.5.8/debian/patches/bump-crypto-requirement.patch
--- python-gear-0.5.8/debian/patches/bump-crypto-requirement.patch	1969-12-31 19:00:00.0 -0500
+++ python-gear-0.5.8/debian/patches/bump-crypto-requirement.patch	2021-10-27 15:33:07.0 -0400
@@ -0,0 +1,29 @@
+Description: Bump crypto requirement to accomodate security standards
+ This patch ensures that the ssl engine does not complains about:
+ - ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2951)
+ - ssl.SSLError: [SSL: CA_MD_TOO_WEAK] ca md too weak (_ssl.c:2951)
+Author: Fabien Boucher 
+Origin: https://opendev.org/opendev/gear/commit/79e1c30
+Bug-Debian: https://bugs.debian.org/973192
+Last-Update: 2021-10-27
+
+--- a/gear/tests/test_functional.py
 b/gear/tests/test_functional.py
+@@ -75,7 +75,7 @@
+ 
+ def create_cert(self, cn, issuer=None, signing_key=None):
+ key = crypto.PKey()
+-key.generate_key(crypto.TYPE_RSA, 1024)
++key.generate_key(crypto.TYPE_RSA, 2048)
+ 
+ cert = crypto.X509()
+ subject = cert.get_subject()
+@@ -94,7 +94,7 @@
+ else:
+ cert.set_issuer(subject)
+ if signing_key:
+-cert.sign(signing_key, 'sha1')
++cert.sign(signing_key, 'sha256')
+ else:
+ cert.sign(key, 'sha1')
+ 
diff -Nru python-gear-0.5.8/debian/patches/series python-gear-0.5.8/debian/patches/series
--- python-gear-0.5.8/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ python-gear-0.5.8/debian/patches/series	2021-10-27 15:33:07.0 -0400
@@ -0,0 +1 @@
+bump-crypto-requirement.patch


[1] https://opendev.org/opendev/gear/commit/79e1c30


signature.asc
Description: PGP signature

Bug#996561: qepcad fails autopkgtests on !amd64, !i386

[Torrance, Douglas]

Control: tags -1 pending

On Fri 15 Oct 2021 01:52:37 PM EDT, Doug Torrance  
wrote:

On Fri 15 Oct 2021 10:29:40 AM EDT, Nilesh Patra  wrote:

qepcad fails its autopkgtests on every non-x86 arch as seen here.
Can you fix this?


I confirmed that QEPCAD isn't functioning for me locally on an armhf system
(Raspberry Pi).  I'll see if I can track down the issue.


I believe the issue was that QEPCAD was reading input using a `char`, and
occasionally checking to see if this was EOF, which is negative (-1).  But on
the failing architectures, `char` defaults to unsigned, so it was getting
255 instead of -1, and we ended up with infinite loops.

I'll upload a new version of the package containing a patch, which I confirmed
works on armhf, shortly.

Doug


signature.asc
Description: PGP signature

Bug#996561: qepcad fails autopkgtests on !amd64, !i386

[Torrance, Douglas]

Control: tags -1 confirmed

On Fri 15 Oct 2021 10:29:40 AM EDT, Nilesh Patra  wrote:

qepcad fails its autopkgtests on every non-x86 arch as seen here.
Can you fix this?


I confirmed that QEPCAD isn't functioning for me locally on an armhf system
(Raspberry Pi).  I'll see if I can track down the issue.

Doug


signature.asc
Description: PGP signature

Bug#996213: ITP: r-cran-r.devices -- unified handling of graphics devices in R

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: r-cran-r.devices
 Version : 2.17.0
 Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/R.devices
* License : LGPL
 Programming Lang: R
 Description : unified handling of graphics devices in R

Functions for creating plots and image files in a unified way regardless
of output format (EPS, PDF, PNG, SVG, TIFF, WMF, etc.). Default device
options as well as scales and aspect ratios are controlled in a uniform
way across all device types. Switching output format requires minimal
changes in code. This package is ideal for large-scale batch processing,
because it will never leave open graphics devices or incomplete image
files behind, even on errors or user interrupts.

I intend to maintain this package under the umbrella of the Debian R packaging
team.


signature.asc
Description: PGP signature

Bug#984353: surf-alggeo: ftbfs with GCC-11

[Torrance, Douglas]

Control: tags -1 patch

On Wed, 03 Mar 2021 16:17:45 + Matthias Klose  wrote:
> ../../../yaccsrc/Script.cc: In static member function ‘static void 
> Script::clearScreen()’:
> ../../../yaccsrc/Script.cc:910:23: error: reference to ‘byte’ is ambiguous
>   910 | *intensity = (byte)(-print_background_data);
>   |   ^~~~
> In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
>  from /usr/include/c++/11/bits/char_traits.h:39,

This is due to the introduction of std::byte in C++17, which is default in GCC 
11.  One band-aid fix would be to explicitly drop back to C++14 -- see the 
attached patch.

In the long term, it would probably be good to drop all the various instances 
of "using namespace std".

DougFrom 1c7279785ea154905b33cdcafe79087efff39f44 Mon Sep 17 00:00:00 2001
From: Doug Torrance 
Date: Mon, 11 Oct 2021 16:09:53 -0400
Subject: [PATCH] Compile with C++14 standard to avoid byte v. std::byte
 issues.

---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 3018e1a..e9aa70a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,7 @@
 include /usr/share/dpkg/pkg-info.mk
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+export DEB_CPPFLAGS_MAINT_APPEND = -std=gnu++14
 
 DEB_VIRT_SURFALGGEO_LISTOF_VARIANT = nox ##gtk
 
-- 
2.30.2

Bug#996088: RFS: r-cran-mpoly

[Torrance, Douglas]

Hi Andreas,

On Mon 11 Oct 2021 12:54:13 AM EDT, Andreas Tille  wrote:

Am Mon, Oct 11, 2021 at 12:59:56AM + schrieb Torrance, Douglas:

I've just finished packaging r-cran-mpoly, which implements multivariate
polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
I'm unable to upload it.  Would anyone be able to review/sponsor?


Looking at the repository layout I realise that it has debian/master
instead of master.  That's fine in principle but its a sign that you
did not used

prepare_missing_cran_package

I keep on recommending to use this to save a lot of time.


I actually did use prepare_missing_cran, but made some additional tweaks
afterwards.  Using debian/master as the packaging branch was one of these,
to avoid clashing with upstream's master branch locally.  It's a great tool,
and made the work very simple!

Thanks for the upload!
Doug


signature.asc
Description: PGP signature

Bug#996088: RFS: r-cran-mpoly

[Torrance, Douglas]

Control: tags -1 pending

I've just finished packaging r-cran-mpoly, which implements multivariate
polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
I'm unable to upload it.  Would anyone be able to review/sponsor?

https://salsa.debian.org/r-pkg-team/r-cran-mpoly

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#996088: ITP: r-cran-mpoly -- symbolic computing with multivariate polynomials in R

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu,

* Package name: r-cran-mpoly
 Version : 1.1.1
 Upstream Author : David Kahle 
* URL : https://github.com/dkahle/mpoly
* License : GPL
 Programming Lang: R
 Description : symbolic computing with multivariate polynomials in R

mpoly is a simple collection of tools to help deal with multivariate
polynomials symbolically and functionally in R.  Features include term
ordering, creating vectors of polynomials, extracting pieces of polynomials,
arithmetic, derivatives, evaluation, homogenization and dehomogenization, and
many special polynomials.

I intend to maintain this package under the umbrella of the Debian R team.


signature.asc
Description: PGP signature

Bug#995446: lintian: don't emit hyphen-in-upstream-part-of-debian-changelog-version for R packages

[Torrance, Douglas]

On Fri 01 Oct 2021 08:51:28 AM EDT, Felix Lechner  
wrote:

Hi Douglas,

On Fri, Oct 1, 2021 at 4:51 AM Torrance, Douglas  wrote:


Would it be possible to avoid emitting this warning for R packages?


Yes! We have a new facility for the purpose of granting summary
exemptions to package groups. It is called a screen. [1]


Great!


As for your broader issue, I would actually prefer if version strings
were totally unrestricted, but am in the minority. [2] I will revisit
the details and then install a screen for you, unless we can get rid
of the tag altogether.


most R source packages can be identified easily because they generally start
with "r-".


We do not like to group based on installable names or source names.
Those are a last resort because they enshrine namespaces that do not
exist otherwise. On average, they also do not work well for language
families where names vary (although it may for R). Can you think of
another way to identify R packages?


Possibly having dh-r and/or r-base-dev in Build-Depends?  I'm still relatively
new to R packaging, though, so I'm Cc'ing the Debian R list for further input.

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#995446: lintian: don't emit hyphen-in-upstream-part-of-debian-changelog-version for R packages

[Torrance, Douglas]

Package: lintian
Version: 2.106.1
X-Debbugs-Cc: dtorra...@piedmont.edu

In R, unlike Debian, hyphens (-) and dots (.) are sorted equally for comparing
version numbers, and it is standard practice upstream for hyphens to be used
between the minor and patch numbers, e.g., x.y-z.

The existence of the pedantic Lintian warning
hyphen-in-upstream-part-of-debian-changelog-version could imply that these
hyphens should be changed to dots, e.g., by using a uversionmangle option
in d/watch.  However, doing this can cause dependency issues in R packages.
See, for example, [1,2,3].

Would it be possible to avoid emitting this warning for R packages?  Note that
most R source packages can be identified easily because they generally start
with "r-".

[1] https://lists.debian.org/debian-r/2018/06/msg00069.html
[2] https://lists.debian.org/debian-r/2021/09/msg00135.html
[3] https://bugs.debian.org/953225


signature.asc
Description: PGP signature

Bug#994218: RFS: r-cran-partitions (NEW)

[Torrance, Douglas]

On Thu 30 Sep 2021 10:47:16 AM EDT, Nilesh Patra  
wrote:

I happened to notice that you added a uversionmangle rule to convert "1.10-2" to 
"1.10.2"
this is not good, we are not supposed to convert hyphenations into "." for R 
packages,
as this goes counter-productive, for managing dependencies etc.
There has been a consensus on this already in the team.


Oops!  I didn't realize this and just made the change based Lintian's
hyphen-in-upstream-part-of-debian-changelog-version warning and reading that,
in R, '-' and '.' are equivalent for sorting version numbers.  It's even
mentioned in the old Debian R policy [1] as an option: "Alternatively, the
hyphen in the CRAN version can be translated into a dot yielding `a.b.c-d'."


We are supposed to take versions as-is with hyphenations, and let debhelper do 
its job.
If you agree, please ask for a reject, fix the version and I'll re-upload.


Sounds good to me!  I've fixed the version for r-cran-partitions in git:
https://salsa.debian.org/r-pkg-team/r-cran-partitions

How do I ask for a reject?  Just send an email to the FTP masters, or is there
some official way through the BTS or something?  I haven't been able to find any
documentation on how to do this for packages still in the NEW queue...


I also noticed that similar thing has been done in r-cran-sets and 
r-cran-orthopolynom. But I guess
its a bit too late unfortunately to change them :/
So probably you need to add an epoch at some point in time for these.


When would an epoch be necessary?  It seems like the dot/hyphen issues I'm
seeing searching through the list archives (e.g., [2]) are in the opposite
direction, i.e., upstream uses a dot in a versioned dependency when our
package uses a hyphen.

I guess my question is, would it be ok to just wait for, e.g., sets 1.1-1 to
be released to switch r-cran-sets to use a hyphen?

Thanks for noticing this!
Doug

[1] https://lists.debian.org/debian-devel/2003/12/msg02332.html
[2] https://lists.debian.org/debian-r/2018/06/msg00069.html


signature.asc
Description: PGP signature

Bug#994218: RFS: r-cran-partitions (NEW)

[Torrance, Douglas]

On Wed 29 Sep 2021 03:45:23 AM EDT, Nilesh Patra  
wrote:

Hi Doug,

On 9/29/21 1:44 AM, Torrance, Douglas wrote:

Control: tags -1 pending

I've just finished packaging r-cran-partitions (ITP #994218), which would be
headed for the NEW queue and so needs a binary upload.


Uploaded with minor copyright change. Thanks!


Thank you!


I'm also interested in this package (well, partitions are interesting always) 
will you
allow me to add myself to uploaders along with you?


Please do!

Doug


signature.asc
Description: PGP signature

Bug#994218: RFS: r-cran-partitions (NEW)

[Torrance, Douglas]

Control: tags -1 pending

I've just finished packaging r-cran-partitions (ITP #994218), which would be
headed for the NEW queue and so needs a binary upload.  Since I'm only a DM,
would anyone be able to review/sponsor?

https://salsa.debian.org/r-pkg-team/r-cran-partitions

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Torrance, Douglas]

I'll go ahead and close this bug.


Oops, I put the -done address in Cc instead of To.  Trying again...


signature.asc
Description: PGP signature

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Torrance, Douglas]

On Sat 25 Sep 2021 03:32:13 PM EDT, Paul Gevers  wrote:

Hi Torrance,

On 25-09-2021 04:56, Torrance, Douglas wrote:

There's a problem though -- this macaulay2 autopkgtest regression is now
preventing ntl from migrating to testing! [1]  This seems like a chicken
and
egg situation -- we need it to migrate for the tests to pass, but we need
the tests to pass for it to migrate...


I must confess that transitions aren't perfectly handled by the
migration software (britney) of the release team yet. britney tries to
figure which packages should come from unstable and adds them as pinned
packages, but hasn't any special notion of transitions.


Is there a good solution for this?


Not yet.


One very hacky idea would be to upload
a new macaulay2 package with a very basic autopkgtest that's guaranteed to
pass for the time being until everything migrates.  Is there a better
solution?


Yes:
* macaulay2 could (temporarily) add *versioned* test dependencies on
libsingular4m1 and libflint-2.8.0 (then autopkgtest will do the right
thing).
* macaulay2 could add *versioned* dependencies on libsingular4m1 and
libflint-2.8.0
* I could manually trigger the test with the combination.

Let's pick the last option for now and see if it works.


That worked!  The autopkgtests were all successful, and ntl has migrated to
testing [1] (along with the flint and factory binNMU's).

I'll go ahead and close this bug.  Thanks for all of your help!

Doug

[1] https://tracker.debian.org/news/1261285/ntl-1151-1-migrated-to-testing/


signature.asc
Description: PGP signature

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Torrance, Douglas]

On Fri 24 Sep 2021 05:15:25 PM EDT, Torrance, Douglas  
wrote:

On Fri 24 Sep 2021 04:40:29 PM EDT, Paul Gevers  wrote:

Hi Torrance,

On 24-09-2021 22:30, Torrance, Douglas wrote:

I had noticed this as well.  My guess is that it has something to do with
the transition of ntl.  libntl43 is in testing, and libntl44 recently
appeared
in unstable.  The unstable autopkgtests, using only libntl44, run without
issue, e.g., [1], but the testing autopkgtests, which use both, have these
segfaults.  We even see both soname versions appearing in the stacktrace:


But as the transition isn't finished yet, we'd keep both versions of
libntl in testing. So, what's loading the old one?


Possibly flint and/or singular?  Both are dependencies of Macaulay2 which
also link against libntl, and both have also already gone through binNMU's
for libntl44 in unstable.


I'm pretty certain this is the issue.  macaulay2 depends on both
libsingular4m1 and libflint-2.8.0, which in turn depend on libntl43 (in
testing) and libntl44 (in sid after recent binNMU's).  Once libntl44 and these
two binNMU's migrate, then I think the tests should work again like they do
in sid.

There's a problem though -- this macaulay2 autopkgtest regression is now
preventing ntl from migrating to testing! [1]  This seems like a chicken and
egg situation -- we need it to migrate for the tests to pass, but we need
the tests to pass for it to migrate...

Is there a good solution for this?  One very hacky idea would be to upload
a new macaulay2 package with a very basic autopkgtest that's guaranteed to
pass for the time being until everything migrates.  Is there a better solution?
Cc'ing the Debian Science list for suggestions.

Thanks!
Doug

[1] https://qa.debian.org/excuses.php?package=ntl


signature.asc
Description: PGP signature

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Torrance, Douglas]

On Fri 24 Sep 2021 04:40:29 PM EDT, Paul Gevers  wrote:

Hi Torrance,

On 24-09-2021 22:30, Torrance, Douglas wrote:

I had noticed this as well.  My guess is that it has something to do with
the transition of ntl.  libntl43 is in testing, and libntl44 recently
appeared
in unstable.  The unstable autopkgtests, using only libntl44, run without
issue, e.g., [1], but the testing autopkgtests, which use both, have these
segfaults.  We even see both soname versions appearing in the stacktrace:


But as the transition isn't finished yet, we'd keep both versions of
libntl in testing. So, what's loading the old one?


Possibly flint and/or singular?  Both are dependencies of Macaulay2 which
also link against libntl, and both have also already gone through binNMU's
for libntl44 in unstable.


 3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 5# 0x7F02080D25B3 in /lib/x86_64-linux-gnu/libntl.so.43


I'm hopeful that once ntl 11.5.1-1 migrates to testing (which is
imminent, as
today is day 5 of 5), this issue will be resolved.


Please don't miss my "flaky" note. That's an RC bug in it's own right.


I'm afraid I don't follow.  Is this note referring to the previous, unrelated
autopkgtest failures?  Those particular tests have been reported upstream
and are now being skipped.

Doug


signature.asc
Description: PGP signature

Bug#995020: macaulay2: autopkgtest regression and flaky test: SIGSEGV

[Torrance, Douglas]

On Fri 24 Sep 2021 04:10:40 PM EDT, Paul Gevers  wrote:

Source: macaulay2
Version: 1.18+ds-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression flaky

Dear maintainer(s),

With a recent upload of macaulay2 the autopkgtest of macaulay2 fails in
testing when that autopkgtest is run with the binary packages of
macaulay2 from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
macaulay2  from testing1.18+ds-4
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. I noticed that
in the past the autopktest regularly fails. As the error is different
from the failing log for the old version, I suspect a genuine regression
now, but please check that the fixed test isn't flaky.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=macaulay2

https://ci.debian.net/data/autopkgtest/testing/amd64/m/macaulay2/15490748/log.gz

 --
/usr/share/doc/Macaulay2/Core/tests/factor.m2:0:1-108:1: error:
 --   -- factoring over fraction fields
 --   F=frac(QQ[a]);
 --
 -- i44 : R=F[x,y];
 --
 -- i45 : assert(#factor(x^2-a^-2*y^2)==3);
 --
 -- i46 :
 --
 -- -- SIGSEGV
 -- -* stack trace, pid: 3577
 --  0# 0x561FFF048737 in /usr/bin/M2-binary
 --  1# 0x561FFF0489EA in /usr/bin/M2-binary
 --  2# 0x7F2AE3C76EF0 in /lib/x86_64-linux-gnu/libc.so.6
 --  3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 --  4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 --  5# 0x7F2AE34ED5B3 in /lib/x86_64-linux-gnu/libntl.so.43
 -- -- end stack trace *-
 --
/usr/share/doc/Macaulay2/Core/tests/factory.m2:0:1-25:1: error:
 --
 -- o14 : R
 --
 -- i15 : assert( gcd(p,q) == d )
 --
 -- i16 : -- test deferred, trying to get it to work
 --   -- factor p   -- not 
implemented yet
 --
 --
 -- -- SIGSEGV
 -- -* stack trace, pid: 3615
 --  0# 0x5612348DA737 in /usr/bin/M2-binary
 --  1# 0x5612348DA9EA in /usr/bin/M2-binary
 --  2# 0x7FBEA4D64EF0 in /lib/x86_64-linux-gnu/libc.so.6
 --  3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 --  4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 --  5# 0x7FBEA45DB5B3 in /lib/x86_64-linux-gnu/libntl.so.43
 -- -- end stack trace *-
 --
/usr/share/doc/Macaulay2/Core/tests/flattenRing.m2:0:1-256:1: error:
 --
 -- i164 : assert( source p === ring J )
 --
 -- i165 : assert( target q === ring I )
 --
 -- i166 : assert( source q === ring I )
 --
 -- i167 :
 --
 -- -- SIGSEGV
 -- -* stack trace, pid: 3768
 --  0# 0x55599045B737 in /usr/bin/M2-binary
 --  1# 0x55599045B9EA in /usr/bin/M2-binary
 --  2# 0x7FDC96DC7EF0 in /lib/x86_64-linux-gnu/libc.so.6
 --  3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 --  4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 --  5# 0x7FDC9663E5B3 in /lib/x86_64-linux-gnu/libntl.so.43
 -- -- end stack trace *-
 --
/usr/share/doc/Macaulay2/Core/tests/frac.m2:0:1-132:1: error:
 --
 -- o83 : FractionField
 --
 -- i84 : try (1_F/x)^2
 --
 -- i85 : assert( getNonUnit F === x )
 --
 -- i86 :
 --   end
 -- -- SIGSEGV
 -- -* stack trace, pid: 3806
 --  0# 0x56275E6BE737 in /usr/bin/M2-binary
 --  1# 0x56275E6BE9EA in /usr/bin/M2-binary
 --  2# 0x7FC1E5D7BEF0 in /lib/x86_64-linux-gnu/libc.so.6
 --  3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 --  4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 --  5# 0x7FC1E55F25B3 in /lib/x86_64-linux-gnu/libntl.so.43
 -- -- end stack trace *-
 --
/usr/share/doc/Macaulay2/Core/tests/galois.m2:0:1-39:1: error:
 -- o26 = k
 --
 -- o26 : GaloisField
 --
 -- i27 :
 --   assert( length degree id_(k^1) == 0 )
 --
 -- i28 :
 --   end
 -- -- SIGSEGV
 -- -* stack trace, pid: 3882
 --  0# 0x558928975737 in /usr/bin/M2-binary
 --  1# 0x5589289759EA in /usr/bin/M2-binary
 --  2# 0x7F7A7EF02EF0 in /lib/x86_64-linux-gnu/libc.so.6
 --  3# NTL::UniqueArray >::~UniqueArray() in
/lib/x86_64-linux-gnu/libntl.so.44
 --  4# __cxa_finalize in /lib/x86_64-linux-gnu/libc.so.6
 --  5# 0x7F7A7E7795B3 in /lib/x86_64-linux-gnu/libntl.so.43
 -- -- end stack trace *-
 --
/usr/share/doc/Macaulay2/Core/tests/galois1.m2:0:1-66:1: error:
 -- i33 : --assert( p (c*x) == (-t-2)^e * q*r ) -- this behavior has
changed (15 June 2014):
 --   assert( p (c*x) == t*q*r)
 --
 -- i34 :
 --   -- # Local Variables:
 --   -- # compile-command: "make -k -C
$M2BUILDDIR/Macaulay2/packages/Macaulay2Doc/test 

Bug#993269: RFS: e-antic 0.1.8+ds-2

[Torrance, Douglas]

On Wed 22 Sep 2021 08:50:51 AM EDT, Nilesh Patra  wrote:
> On Wed, 22 Sept 2021 at 16:49, Torrance, Douglas 
> wrote:
>
>> Control: tags -1 pending
>>
>> e-antic and its reverse dependencies (macaulay2, normaliz, polymake,
>> pynac, and
>> singular) are currently scheduled for autoremoval on 2021-10-12 due to RC
>> bug
>> #993269.  Peter Green tracked down a fix and submitted a patch, which I've
>> pushed to Salsa, along with a couple other minor things.
>>
>> Would anyone be able to review/sponsor, or alternatively, grant me DM
>> upload
>> permissions for e-antic?
>>
>
> $ dcut ssh-upload dm --uid dtorra...@piedmont.edu --allow e-antic
>
> Uploading commands file to ssh.upload.debian.org (incoming: /srv/
> upload.debian.org/UploadQueue/)
> Picking DM Doug Torrance  with fingerprint
> 803CE41F4DC252ECB5E5F1B9D12B2BE26D3FF663
> SCP is deprecated. Please consider upgrading to SFTP.
> Uploading nilesh-1632314835.dak-commands to ssh-upload
>
> Enjoy!

Thanks, Nilesh!

However, since Jerome also responded, I'll hold off on uploading for now.

Bug#993269: RFS: e-antic 0.1.8+ds-2

[Torrance, Douglas]

Control: tags -1 pending

e-antic and its reverse dependencies (macaulay2, normaliz, polymake, pynac, and
singular) are currently scheduled for autoremoval on 2021-10-12 due to RC bug
#993269.  Peter Green tracked down a fix and submitted a patch, which I've
pushed to Salsa, along with a couple other minor things.

Would anyone be able to review/sponsor, or alternatively, grant me DM upload
permissions for e-antic?

https://salsa.debian.org/science-team/e-antic

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#994765: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

[Torrance, Douglas]

Package: libxml2
Version: 2.9.12+dfsg-3
Severity: normal
Control: affects -1 src:macaulay2
X-Debbugs-Cc: dtorra...@piedmont.edu

Beginning with the upload of 2.9.12 to sid, the build of the Macaulay2 package
began failing when validating its html documentation.  For example, from [1,2]:

/usr/bin/make -C M2 validate-html
make[2]: Entering directory 
'/<>/macaulay2-1.18.0.1+git202109031258/M2'
-- validating all html and xhtml files in 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2
validating: BGG/html/_direct__Image__Complex.html
*** invalid HTML: 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2/BGG/html/_direct__Image__Complex.html
error: line 338: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

...

validating: AlgebraicSplines/html/index.html
*** invalid HTML: 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2/AlgebraicSplines/html/index.html
error: line 338: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

9328 HTML files checked; 9328 invalid
make[2]: *** [GNUmakefile:302: validate-html] Error 1

A bit more information is given by running xmllint on one of the affected files:

$  xmllint --noout --loaddtd /usr/share/doc/Macaulay2/Macaulay2Doc/html/_ideal.html 
file:///usr/share/xml/w3c-sgml-lib/schema/dtd/WD-XHTMLplusMathMLplusSVG-20020809/xhtml-math-svg.dtd:338: parser error : xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

  %xhtml-qname-extra.decl;
  ^
Entity: line 2: 
  "http://www.w3.org/Math/DTD/mathml2/mathml2-qname-1.mod;

  ^
The problem appears to be that the latest release of libxml2 is more strict
when parsing DTD files, xhtml-math-svg.dtd in this particular case.

See also [3], which involves a similar error related to the file
xhtml1-strict.dtd.

[1] 
https://launchpadlibrarian.net/556859860/buildlog_ubuntu-impish-amd64.macaulay2_1.18.0.1+git202109031258-0ppa202109031444~ubuntu21.10.1_BUILDING.txt.gz
[2] https://github.com/Macaulay2/M2/issues/2225
[3] https://bugs.debian.org/993638


signature.asc
Description: PGP signature

Bug#993638: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

[Torrance, Douglas]

Control: affects -1 - src:macaulay2

On Mon 20 Sep 2021 11:41:39 AM EDT, Vincent Lefevre  wrote:

On 2021-09-20 15:00:00 +, Torrance, Douglas wrote:

On Mon 20 Sep 2021 08:17:11 AM EDT, Vincent Lefevre  wrote:
> The error message is different. I'd say that this is a different issue.

Fair enough.  I think it's related -- the latest release is more strict about
DTD files --


Yes, but there seem to be many changes, thus potentially several kinds
of regressions for different reasons. It is better to report one bug
per kind of regression.


That makes sense -- I'll open a new bug.


but involving a different DTD file, xhtml-math-svg.dtd from the
w3c-sgml-lib package. Here's the output of xmllint, which gives a
bit more info:

$  xmllint --noout --loaddtd
/usr/share/doc/Macaulay2/Macaulay2Doc/html/_ideal.html 
file:///usr/share/xml/w3c-sgml-lib/schema/dtd/WD-XHTMLplusMathMLplusSVG-20020809/xhtml-math-svg.dtd:338:
parser error : xmlParseEntityDecl: entity xhtml-qname-extra.mod not
terminated
   %xhtml-qname-extra.decl;
   ^
Entity: line 2:
"http://www.w3.org/Math/DTD/mathml2/mathml2-qname-1.mod;
   ^
Perhaps this should be filed against w3c-sgml-lib?


I don't know about this one. It could be a bug either in libxml2
(e.g. an unexpected regression in a corner case due to some fix
of a more general case) or in the DTD from w3c-sgml-lib. Some
investigation would be needed.


I guess I'll start by filing it against libxml2 like this bug, and it can always
be re-assigned later if necessary.


signature.asc
Description: PGP signature

Bug#993638: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

[Torrance, Douglas]

On Mon 20 Sep 2021 08:17:11 AM EDT, Vincent Lefevre  wrote:

On 2021-09-20 11:58:00 +, Torrance, Douglas wrote:

Control: affects -1 src:macaulay2

I believe this bug is also affecting the build of the Macaulay2 package.  From
[1,2]:

/usr/bin/make -C M2 validate-html
make[2]: Entering directory 
'/<>/macaulay2-1.18.0.1+git202109031258/M2'
-- validating all html and xhtml files in 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2
validating: BGG/html/_direct__Image__Complex.html
*** invalid HTML: 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2/BGG/html/_direct__Image__Complex.html
error: line 338: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated


The error message is different. I'd say that this is a different issue.


Fair enough.  I think it's related -- the latest release is more strict about
DTD files -- but involving a different DTD file, xhtml-math-svg.dtd from the
w3c-sgml-lib package.  Here's the output of xmllint, which gives a bit more
info:

$  xmllint --noout --loaddtd /usr/share/doc/Macaulay2/Macaulay2Doc/html/_ideal.html 
file:///usr/share/xml/w3c-sgml-lib/schema/dtd/WD-XHTMLplusMathMLplusSVG-20020809/xhtml-math-svg.dtd:338: parser error : xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

   %xhtml-qname-extra.decl;
   ^
Entity: line 2: 
   "http://www.w3.org/Math/DTD/mathml2/mathml2-qname-1.mod;

   ^
Perhaps this should be filed against w3c-sgml-lib?


signature.asc
Description: PGP signature

Bug#993638: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

[Torrance, Douglas]

Control: affects -1 src:macaulay2

I believe this bug is also affecting the build of the Macaulay2 package.  From
[1,2]:

/usr/bin/make -C M2 validate-html
make[2]: Entering directory 
'/<>/macaulay2-1.18.0.1+git202109031258/M2'
-- validating all html and xhtml files in 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2
validating: BGG/html/_direct__Image__Complex.html
*** invalid HTML: 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2/BGG/html/_direct__Image__Complex.html
error: line 338: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

...

validating: AlgebraicSplines/html/index.html
*** invalid HTML: 
/<>/macaulay2-1.18.0.1+git202109031258/M2/usr-dist/common/share/doc/Macaulay2/AlgebraicSplines/html/index.html
error: line 338: xmlParseEntityDecl: entity xhtml-qname-extra.mod not terminated

9328 HTML files checked; 9328 invalid
make[2]: *** [GNUmakefile:302: validate-html] Error 1

[1] 
https://launchpadlibrarian.net/556859860/buildlog_ubuntu-impish-amd64.macaulay2_1.18.0.1+git202109031258-0ppa202109031444~ubuntu21.10.1_BUILDING.txt.gz
[2] https://github.com/Macaulay2/M2/issues/2225


signature.asc
Description: PGP signature

Bug#993923: macaulay2: FTBFS on s390x: error: installPackage: 1 error(s) occurred running examples for package SparseResultants

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2162
Control: tags -1 pending

On Wed 08 Sep 2021 04:42:51 AM EDT, Sebastian Ramacher  
wrote:

| ../../m2/debugging.m2:20:6:(1):[9]: error: installPackage: 1 error(s) 
occurred running examples for package SparseResultants:
|
| _char_lp__Sparse__Resultant_rp.errors
| *
| -- -*- M2-comint -*- hash: 829653806
|
| i1 : R = denseResultant(2,2,1,CoefficientRing=>ZZ/331);
| Killed


Thanks for the report!  This has been reported upstream and there's a
(band-aid) fix in git for the next upload.


signature.asc
Description: PGP signature

Bug#992432: RFS: frobby (NEW binary package)

[Torrance, Douglas]

On Wed 18 Aug 2021 03:35:19 PM EDT, Doug Torrance  
wrote:
> Due to [1], frobby needs a soname version bump and hence a NEW binary package
> (libfrobby0 -> libfrobby1).  As a DM, I'm not able to upload packages to the
> NEW queue.  Would anyone be able to review/sponsor?
>
> https://salsa.debian.org/science-team/frobby
>
> Thanks!
> Doug
>
> [1] https://bugs.debian.org/992432

FYI, I just uploaded a band-aid fix to sid to take care of this RC bug for the
time being so we don't have to wait for the NEW queue, but I'm still looking
for a sponsor for the long-term fix, which I've pushed to git.

Thanks!
Doug

Bug#992432: RFS: frobby (NEW binary package)

[Torrance, Douglas]

Control: tags -1 pending

Due to [1], frobby needs a soname version bump and hence a NEW binary package
(libfrobby0 -> libfrobby1).  As a DM, I'm not able to upload packages to the
NEW queue.  Would anyone be able to review/sponsor?

https://salsa.debian.org/science-team/frobby

Thanks!
Doug

[1] https://bugs.debian.org/992432

Bug#992432: frobby: undefined symbol: _ZN9constants7versionE

[Torrance, Douglas]

Message-ID: <162929730510.557678.4828600179998098531.reportbug@mixtuppa>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailer: reportbug 7.10.3ubuntu1
Package: frobby
Version: 0.9.5-1
Severity: important
X-Debbugs-Cc: dtorra...@piedmont.edu

/usr/bin/M2-binary: symbol lookup error: /usr/bin/M2-binary: undefined symbol: 
_ZN9constants7versionE

>From a CI test run of Macaulay2 after the upload of frobby 0.9.5-1 [1]:

This is due to the upstream change from constants::version to frobby_version
[2].  Due to the change in interface, frobby should get a soname version bump.


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/m/macaulay2/14665382/log.gz
[2] https://github.com/Macaulay2/frobby/pull/5
Date: Wed, 18 Aug 2021 10:38:51 -0400

Bug#991791: RFS: pynauty

[Torrance, Douglas]

On Mon 02 Aug 2021 06:40:14 AM EDT, Andrius Merkys  wrote:

Hi,

On Mon, 2 Aug 2021, 13:35 Torrance, Douglas,  wrote:


I've recently packaged pynauty [1], which provides a Python interface to
nauty
[2] for computing automorphism groups of graphs.

I'm a DM, but this package would be NEW, so I need a sponsor.  Would
anyone be
willing to review?
https://salsa.debian.org/python-team/packages/pynauty

Thanks!
Doug

[1] https://github.com/pdobsan/pynauty
[2] https://pallini.di.uniroma1.it/



I'm interested in this package. Therefore I'll happily review and upload it
for you. Just allow me a couple of days to do so.


Wonderful, thank you!

Doug


signature.asc
Description: PGP signature

Bug#991791: RFS: pynauty

[Torrance, Douglas]

I've recently packaged pynauty [1], which provides a Python interface to nauty
[2] for computing automorphism groups of graphs.

I'm a DM, but this package would be NEW, so I need a sponsor.  Would anyone be
willing to review?
https://salsa.debian.org/python-team/packages/pynauty

Thanks!
Doug

[1] https://github.com/pdobsan/pynauty
[2] https://pallini.di.uniroma1.it/


signature.asc
Description: PGP signature

Bug#991750: nauty: segfaults during sagemath testsuite

[Torrance, Douglas]

Control: forwarded -1 na...@anu.edu.au

FYI, the segfault below was just reported in Debian.

On Sat, 31 Jul 2021 21:11:10 +0200 (CEST) Ahzo  wrote:
> Package: nauty
> Version: 2.7r1+ds-2
> Severity: important
> Control: affects -1 sagemath
> 
> Hi,
> 
> during the sagemath testsuite, a nauty crash occurs. Nonetheless, the 
> sagemath test passes:
> sage -t --long --random-seed=0 src/sage/graphs/digraph_generators.py
>     [150 tests, 6.44 s]
> 
> The crash can be easily reproduced:
> $ nauty-gentourng -d0 -D1 -c 2
> >A nauty-gentourng -cd1D0 n=2
> Segmentation fault (core dumped)
> 
> Anyway, nauty should not crash like this, particularly since the input seems 
> valid.
> 
> Regards,
> Ahzo

Bug#990950: Question about packaging a Lisp image

[Torrance, Douglas]

On Wed 14 Jul 2021 01:10:36 PM EDT, Sébastien Villemot  
wrote:

[Sorry, resending with proper quoting; my email client somehow messed things up]

Hi Douglas,

Le dimanche 11 juillet 2021 à 17:08 +, Torrance, Douglas a écrit :


I would like to package bergman [1], a Common Lisp program for computations in
noncommutative algebra.



Upstream's build script creates an executable by generating an image with
SAVEINITMEM.  However, in order for some of the features of bergman to work
properly, the source files must be present, and in the same location as they
were during build time, at runtime.  So generating the image while building the
binary package won't work, as then at runtime we'd be looking for some
non-existent directory from the buildd machines.  (Not to mention the
reproducibility issues from having these paths hardcoded in the image!)



One solution that I've come up with is to just have the Debian package install
the necessary source files, and then have the postinst script run the upstream
build script and generate the image right there on the user's system as part of
the installation process.



I'm very new to Common Lisp, so I'm not sure if this is the best strategy.  Is
there another method that would be recommended instead?


First, note that Common Lisp is a standard, which has different
implementations. In Debian, we have 5 of them, the most important ones
being SBCL, ECL and CLISP.¹

My understanding is that Bergman uses CLISP as its reference
implementation. This is a rather slow Common Lisp implementation, but
it is well-supported in Debian. SBCL is a much faster implementation,
but I don’t know if Bergman works with it (at the very least you would
have to modify the build system).

Applications programmed in Common Lisp typically ship the lisp image in
the binary package. See for example xindy², which also uses CLISP. See
also pgloader³, that uses SBCL (and relies on buildapp⁴ for creating
the executable from the lisp image).

So the ideal solution would still be to patch Bergman in a way that
allows it to work with sources under a standard location (typically
/usr/share/common-lisp/source/bergman/).

If that’s not possible, then you could do as you suggest: only ship the
sources in the binary package (under the location mentioned above), and
build the lisp image in the postinst script.

Note that most Common Lisp library packages only ship sources as well
(under /usr/share/common-lisp/source/), but they don’t provide any lisp
image. These libraries are supposed to be loaded from implementations,
typically via ASDF, into the running lisp image.

I hope this clarifies a bit. Don’t hesitate to ask for further advice,
since the Common Lisp way of doings things can be disturbing at first
sight. In particular, I suggest that you go through the introductory
wiki page linked below.

Best,

¹ For more details on Common Lisp and Debian, see 
https://wiki.debian.org/CommonLisp
² https://tracker.debian.org/pkg/xindy
³ https://tracker.debian.org/pkg/pgloader
⁴ https://tracker.debian.org/pkg/buildapp


Thank you so much for all of this information!  I'll do some more work and see 
if it's possible to patch things and ship the lisp image in the package, but 
it's good to hear that the postinst option would work as well.

Thanks again!
Doug


signature.asc
Description: PGP signature

Bug#990950: Question about packaging a Lisp image

[Torrance, Douglas]

Hello!

I would like to package bergman [1], a Common Lisp program for computations in
noncommutative algebra.

Upstream's build script creates an executable by generating an image with
SAVEINITMEM.  However, in order for some of the features of bergman to work
properly, the source files must be present, and in the same location as they
were during build time, at runtime.  So generating the image while building the
binary package won't work, as then at runtime we'd be looking for some
non-existent directory from the buildd machines.  (Not to mention the
reproducibility issues from having these paths hardcoded in the image!)

One solution that I've come up with is to just have the Debian package install
the necessary source files, and then have the postinst script run the upstream
build script and generate the image right there on the user's system as part of
the installation process.

I'm very new to Common Lisp, so I'm not sure if this is the best strategy.  Is
there another method that would be recommended instead?

Thanks!
Doug

[1] https://bugs.debian.org/990950


signature.asc
Description: PGP signature

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

On Thu 08 Jul 2021 12:24:47 AM EDT, Torrance, Douglas  
wrote:

On Wed 07 Jul 2021 08:37:08 AM EDT, Doug Torrance  
wrote:

On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra  wrote:

./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.


Good catch!  I've sent upstream a note asking for clarification on the license
of the files in this directory.


Upstream confirmed that this particular feature would cause limitations for
commercial use due to the license.  It's just one feature, though, and I think
that PHCpack would still be a valuable addition to Debian without it.  (For
example, the PHCpack package in Macaulay2 doesn't use it.)

I'll spend some time working on stripping this feature out to create a
DFSG-compliant version of PHCpack and ping the list when it's ready for another
look.


I've repacked the PHCpack package so that it doesn't use the non-free QD
library.  I believe it's ready for another review:
https://salsa.debian.org/science-team/phcpack

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

On Wed 07 Jul 2021 08:37:08 AM EDT, Doug Torrance  
wrote:

On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra  wrote:

./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.


Good catch!  I've sent upstream a note asking for clarification on the license
of the files in this directory.


Upstream confirmed that this particular feature would cause limitations for
commercial use due to the license.  It's just one feature, though, and I think
that PHCpack would still be a valuable addition to Debian without it.  (For
example, the PHCpack package in Macaulay2 doesn't use it.)

I'll spend some time working on stripping this feature out to create a
DFSG-compliant version of PHCpack and ping the list when it's ready for another
look.

Thanks again!
Doug


signature.asc
Description: PGP signature

Bug#950008: gfan: assertion fails on riscv64

[Torrance, Douglas]

On Tue, 28 Jan 2020 10:29:07 +0100 Tobias Hansen  wrote:
> many of sagemath's doctests in the interface to gfan fail on riscv64 with the 
> following error:
> 
> gfan_*: src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed.
> 
> It looks like the pointer arithmetic in the function tail() in 
> application.cpp does not work like this on riscv64. Unfortunately there are 
> no porterboxes for riscv64 yet, so I can't come up with a minimal example 
> triggering the bug.

This is also causing macaulay2 to FTBFS in riscv64 [1]:

checking whether the package gfan is installed... gfan: 
src/application.cpp:42: char* tail(char*): Assertion `*p==*m' failed.
yes, but < 0.6, will build

...

make -C gfan fetch
make[3]: Entering directory '/<>/M2/libraries/gfan'
error: for the third-party library or program source "gfan"
   the source code is not present in the file 
"/<>/M2/BUILD/tarfiles/gfan0.6.2.tar.gz"
   so either download a "fat" tar file of the Macaulay2 source code
   or rerun the Macaulay2 "configure" command with the added option 
"--enable-download"
   to enable automatic downloading of the source code over the internet
make[3]: *** [../Makefile.library:235: 
/<>/M2/BUILD/tarfiles/gfan0.6.2.tar.gz] Error 1

[1] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=riscv64=1.18%2Bds-1%7Eexp1=1625665959=0

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra  wrote:

Hi Doug,

On Wed, 7 Jul 2021 at 03:42, Torrance, Douglas 
wrote:



On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance 
wrote:
> I've finished packaging PHCpack, which is written in Ada and solves
polynomial systems using homotopy continuation, for Debian.  It also
includes Python and Octave interfaces.
>
> Would anyone be willing to review/sponsor?  Note that I currently have
it set for upload to unstable since it's destined for the NEW queue and I
don't think that would interfere with the freeze, but perhaps it would make
sense to upload to experimental instead?
>
> https://salsa.debian.org/science-team/phcpack

FYI, I'm still looking for a sponsor for PHCpack.  Upstream recently
released a new version (2.4.85), and I've updated the packaging in Salsa
accordingly.



./src/Ada/Math_Lib/QD/READ_ME states this:

The main reference for the QD-2.3.9 library is
Y. Hida, X.S. Li, and D.H. Bailey:
"Algorithms for quad-double precision floating point arithmetic."
In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001),
11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001.
Shortened version of Technical Report LBNL-46996,
software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz.

Note that the "BSD-LBNL-License" is GPL compatible, although
"If you wish to use the software for commercial purposes
please contact the Technology Transfer Department at t...@lbl.gov or
call 510-286-6457."

I admit, I'm not very sure if I understand the terms there correctly, but
should it be mentioned in d/copyright?
I also see similar stuff in a lot of READ_ME files,
./src/Ada/Root_Counts/MixedVol/READ_ME for instance.

Do they need to be mentioned in d/copyright? If not, IMO adding a
"Comment:" and the reasoning for not adding these in copyright would be
good.


Good catch!  I've sent upstream a note asking for clarification on the license
of the files in this directory.


I've also opened a merge request in the Debian Science Blend repo to add
it to the mathematics task:
https://salsa.debian.org/blends-team/science/-/merge_requests/7

I'm also still looking for sponsors for a few other packages:

* macaulay2 (new upstream version 1.18, for experimental)
  https://salsa.debian.org/science-team/macaulay2



Unfortunately, I've got no resources to build it :-(
I hope someone else uploads this. If not, just ping me after your keys are
added to the DM keyring, and I'll grant you DM access for this


I see that you've uploaded this after all -- thank you!


* macaulay2-jupyter-kernel (NEW)
  https://salsa.debian.org/science-team/macaulay2-jupyter-kernel



Uploaded!


Thank you!


* qepcad (NEW)
  https://salsa.debian.org/science-team/qepcad



./plot2d/ADJ2D_plot is a binary file, and I'm sure FTP masters will not
like it. Please repack this and compile the same during the build.


It was already being re-compiled during build ("make -C plot2d" in d/rules), but
I went ahead and also repacked the tarball without it.


Good news: my DM application was recently approved, so once the keyring is
updated, I won't need to ask for sponsorship for non-NEW packages.  :)



I'm very happy about this. Whilst I could not advocate you due to us
working on not many packages together, I was definitely cheering on the
sidelines all this while.
I hope you apply for being a DD someday, and by that time I've sponsored
enough packages for you.


Thanks again!
Doug


signature.asc
Description: PGP signature

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance  
wrote:

I've finished packaging PHCpack, which is written in Ada and solves polynomial 
systems using homotopy continuation, for Debian.  It also includes Python and 
Octave interfaces.

Would anyone be willing to review/sponsor?  Note that I currently have it set 
for upload to unstable since it's destined for the NEW queue and I don't think 
that would interfere with the freeze, but perhaps it would make sense to upload 
to experimental instead?

https://salsa.debian.org/science-team/phcpack


FYI, I'm still looking for a sponsor for PHCpack.  Upstream recently released a 
new version (2.4.85), and I've updated the packaging in Salsa accordingly.

I've also opened a merge request in the Debian Science Blend repo to add it to 
the mathematics task:
https://salsa.debian.org/blends-team/science/-/merge_requests/7

I'm also still looking for sponsors for a few other packages:

* macaulay2 (new upstream version 1.18, for experimental)
 https://salsa.debian.org/science-team/macaulay2

* macaulay2-jupyter-kernel (NEW)
 https://salsa.debian.org/science-team/macaulay2-jupyter-kernel

* qepcad (NEW)
 https://salsa.debian.org/science-team/qepcad

Good news: my DM application was recently approved, so once the keyring is 
updated, I won't need to ask for sponsorship for non-NEW packages.  :)

Thanks!
Doug


signature.asc
Description: PGP signature