Bug#1068046: /etc/firehol/ifupdown-firehol.sh: 71: [: -o: unexpected operator
Hello Jan, thanks for your report. This is indeed a bashism ... which is not detected by checkbashisms(1). I am on my way to apply your fix. Thanks again, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#1067293: singular: FTBFS: cfModGcd.cc:1809:37: error: cannot convert ‘fq_nmod_ctx_struct*’ to ‘const fq_nmod_mat_struct*’
Hello Lucas, thanks for the report. The issue appeared to be fixed in version 4.3.2-p16. I am on my way to bring this new version to experimental. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067068: mpfi: Please package new upstream version
Hello Hilmar, thanks for your message. The main issue with the mpfi library is that the source ball is illform: the new uptream maintainer is lost in source packaging. I will try to have a better look by the next week-end. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064635: nmu: normaliz_3.10.1+ds-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu normaliz_3.10.1+ds-5 . ANY . unstable . -m "Rebuild against libeantic3 to correct dependency" Dear Release Team, the upload of e-antic 2.0.2+ds-1 came with a shift of its SONAME from 1 to 3, and autopkgtest spots a build issue with the package normaliz: rebuilding the package against libeantic3 causes not problem (and solve the issue). Cheers, Jerome
Bug#1060832: RM: graph-tool [ppc64el] -- ROM; Does not build on ppc64el
Hi, I have just tried to build the graph-tool package on the platti porter box (ppc64el arch porter box) once with the option -mlong-double-128 and once with the option-mlong-double-80 . The two attempts failed. Accordingly I second the request made by Andreas. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1059918: sysvinit-core: /sbin/init linked against a lib in /usr/lib
Package: sysvinit-core Version: 3.06-4devuan3 Severity: normal Dear Maintainer, it appears that /sbin/init is linked against /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 . This prevents from booting without an initrd image when `/` and `/usr` are mounted on different partitions. An immediate solution is to place libpcre2 in the root partion `/`, namely in /lib/ . hth, Jerome -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 5 (daedalus) Release:5 Codename: daedalus Architecture: x86_64 Kernel: Linux 6.1.0-15-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sysvinit-core depends on: ii debconf [debconf-2.0] 1.5.82 ii initscripts3.06-4devuan3 ii libc6 2.36-9+deb12u3 ii libselinux13.4-1+b6 ii mount 2.38.1-5devuan1+b1 ii sysv-rc3.06-4devuan3 ii sysvinit-utils 3.06-4devuan3 Versions of packages sysvinit-core recommends: pn orphan-sysvinit-scripts Versions of packages sysvinit-core suggests: ii bootlogd 3.06-4devuan3 -- debconf information: sysvinit/hurd-fix-inittab:
Bug#984928: slurm fails on disconnected standalone computer/node
Hi,
I have a setup similar to the one of the original reporter.
My NodeName is localhost .
The error messages at booting time scared me, so I dug the issue.
I also related this issue to my observation that slurm fails to launch jobs
when my standalone computer is disconnected (the router provided by my ISP
is very unstable). I could reproduced the issue with a simple C program
that mimics get_addr_info function. After some trials, it appears that the issue
disappears when the hints.ai_flags do not include the AI_ADDRCONFIG flag
(see get_addr_info(3) for more information). So the current workaround
patch `retry-getaddrinfo` only fixes the issue partially.
The following patch neutralize the setup of the AI_ADDRCONFIG flag:
8><
--- a/src/common/conmgr.c
+++ b/src/common/conmgr.c
@@ -1807,7 +1807,7 @@
struct addrinfo hints = { .ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
.ai_protocol = 0,
- .ai_flags = AI_PASSIVE | AI_ADDRCONFIG };
+ .ai_flags = AI_PASSIVE /*| AI_ADDRCONFIG */ };
struct addrinfo *addrlist = NULL;
parsed_host_port_t *parsed_hp;
--- a/src/common/util-net.c
+++ b/src/common/util-net.c
@@ -261,7 +261,7 @@
else
hints.ai_family = AF_UNSPEC;
- hints.ai_flags = AI_ADDRCONFIG | AI_NUMERICSERV | AI_PASSIVE;
+ hints.ai_flags = /* AI_ADDRCONFIG | */ AI_NUMERICSERV | AI_PASSIVE;
if (hostname)
hints.ai_flags |= AI_CANONNAME;
hints.ai_socktype = SOCK_STREAM;
><8
I guess that this patch is too brutal and that it must be refined.
In particular, the flag may not be AI_ADDRCONFIG set up only on standalone
computer.
However I am not familiar enough with slurm and network stuff to step further.
Here is the simple C program that helps me to isolate better the issue:
8><
// `example-getaddrinfo-00.c' C source file
// gcc -Wall -o example-getaddrinfo-00 example-getaddrinfo-00.c
// $ ./example-getaddrinfo-00
// $ ./example-getaddrinfo-00 localhost
// $ ./example-getaddrinfo-00 debian.org
#include
#include
#include
#include
#include
#include
#include
#include
int main(int nargs, char *args[]) {
char nodename[1024]="localhost";
const char serv[6]="6817";
struct addrinfo hints;
struct addrinfo * result=NULL;
struct addrinfo * rdx=NULL;
struct sockaddr_in * ai_addr_v4=NULL;
char sa_str[INET6_ADDRSTRLEN];
char * xnodename=NULL;
int status=0;
if (1ai_next) {
ai_addr_v4=(struct sockaddr_in *)(rdx->ai_addr);
inet_ntop(AF_INET,&(ai_addr_v4->sin_addr),sa_str,sizeof(sa_str));
fprintf(stdout,">%s< >%s<\n",result->ai_canonname,sa_str);
}
freeaddrinfo(result); result=NULL;
return (status); }
><8====
hth,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#776902: tmux: leaves a socket behind in /tmp/tmux-1000/default on exit: on the contrary
Hi, I have noticed that when there is no tmux session then the command $ tmux ls gives $ no server running on /run/user/1000/tmux-1000/default So it appears that a tmux-1000/default is expected. Therefore the issue is not that ``tmux leaves a socket behind behing it'', but exactly the contrary: tmux needs to leave a socket behind behing it. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#1059711: reportbug: slurm-wlm-basic-plugins depends on libpmix-dev
Package: slurm-wlm-basic-plugins Version: 22.05.8-4+deb12u1 Severity: important Dear Maintainer, it appears that after a migration to Bookworm, slurmd failed to start because it could not load libpmix.so which is provided by libpmix-dev . hth, Jerome -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages slurm-wlm-basic-plugins depends on: ii adduser 3.134 ii libc62.36-9+deb12u3 ii libdbus-1-3 1.14.10-1~deb12u1devuan1 ii libhwloc15 2.9.0-1 ii libjson-c5 0.16-2 ii liblua5.1-0 5.1.5-9 ii libmunge20.5.15-2 ii libnuma1 2.0.16-1 ii libyaml-0-2 0.2.5-1 Versions of packages slurm-wlm-basic-plugins recommends: pn slurm-wlm-plugins slurm-wlm-basic-plugins suggests no packages. -- no debconf information
Bug#1056186: texlive-binaries: zlib library mismatch
Hello Hilmar, thanks for your prompt reply. To clarify things, the message is not only irritating but also aborting: the package tex-common cannot currently configure. Best wishes, Jerome PS: I merged my report with the first report, and I redirected the first report to texlive-binaries. On 18/11/2023 15:28, Preuße, Hilmar wrote: On 18.11.2023 14:57, Jerome Benoit wrote: Hi, Hi, the issue appeared to me within a Sid schroot environment at postinstallation time of tex-common. I traced it back to texlive-binaries by looking the logfile at the fmutils stage. The issue seems to originate from the recent migration from zlib 1.2.13 to zlib 1.3. For short, the following command-line $ luatex -ini -jobname=luatex -progname=luatex luatex.ini gives PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) aborted Already reported, but on the wrong package. I'll try, whether a simple rebuild of the package solves the issue, but I'm afraid it won't. The message "zlib library version does not match - header: 1.2.13, library: 1.3" is irritating, but I know that behavior from other packages too (e.g. proftp). I understand this warning: "expect trouble ahead". Hilmar -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1056186: texlive-binaries: zlib library mismatch
Package: texlive-binaries Version: 2023.20230311.66589-7 Severity: grave Justification: renders package unusable X-Debbugs-Cc: calcu...@rezozer.net Hi, the issue appeared to me within a Sid schroot environment at postinstallation time of tex-common. I traced it back to texlive-binaries by looking the logfile at the fmutils stage. The issue seems to originate from the recent migration from zlib 1.2.13 to zlib 1.3. For short, the following command-line $ luatex -ini -jobname=luatex -progname=luatex luatex.ini gives PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) aborted Best wishes, Jerome -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-0.deb11.6-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages texlive-binaries depends on: ii libc6 2.37-12 ii libcairo2 1.18.0-1 ii libfontconfig1 2.14.2-6 ii libfreetype62.13.2+dfsg-1 ii libgcc-s1 13.2.0-6 ii libgraphite2-3 1.3.14-1 ii libharfbuzz0b 8.0.1-1 ii libicu7272.1-4 ii libkpathsea62023.20230311.66589-7 ii libmpfr64.2.1-1 ii libpaper1 1.1.29 ii libpixman-1-0 0.42.2-1 ii libpng16-16 1.6.40-2 ii libpotrace0 1.16-2 ii libptexenc1 2023.20230311.66589-7 ii libstdc++6 13.2.0-6 ii libsynctex2 2023.20230311.66589-7 ii libteckit0 2.5.11+ds1-1+b1 ii libtexlua53-5 2023.20230311.66589-7 ii libx11-62:1.8.7-1 ii libxaw7 2:1.0.14-1 ii libxi6 2:1.8-1+b1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.17-1 ii libxt6 1:1.2.1-1.1 ii libzzip-0-130.13.72+dfsg.1-1.1 ii perl5.36.0-9 ii t1utils 1.41-4 ih tex-common 6.18 ii zlib1g 1:1.3.dfsg-2 Versions of packages texlive-binaries recommends: pn dvisvgm ii texlive-base 2023.20231007-1 Versions of packages texlive-binaries suggests: pn hintview pn texlive-binaries-sse2 Versions of packages tex-common depends on: ii ucf 3.0043+nmu1 Versions of packages tex-common suggests: ii debhelper 13.11.8 Versions of packages texlive-binaries is related to: ih tex-common6.18 ii texlive-base 2023.20231007-1 -- no debconf information
Bug#1054706: e-antic: FTBFS: ../../../libeantic/test/main.cpp:4:10: fatal error: catch2/catch.hpp: No such file or directory
Hello, as the migration to catch2 v3 appeared not simple, I finally used the catch2 material provided by the e-antic upstream team. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1054706: e-antic: FTBFS: ../../../libeantic/test/main.cpp:4:10: fatal error: catch2/catch.hpp: No such file or directory
Hi Lucas, thanks for your report. I can reproduce the issue on my box. The issue is due to the recent migration in Sid from catch2 v2 to catch2 v3. I am on my way to write a migration patch with respect to the document /usr/share/doc/catch2/docs/migrate-v2-to-v3.md.gz [ or https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md ] Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1042029: graph-tool: FTBFS: collect2: fatal error: ld terminated with signal 9 [Killed]
Hi all, I downgraded the severity to normal as this issue is before all a resource issue. I have no problem to build it on a 24 CPUs amd64 box with 64 GB of RAM (and with ~ 4/3 of 64 GB of SWAP). Please keep in mind that graph-tool is scientific tool for big-data, so the choice of the optimization option is relevant. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1052456: RM: python-igraph [s390x] -- ROM; unsatisfiable Buil-Depends-Arch: libigraph-dev: libplfit-dev
Package: ftp.debian.org Severity: normal Please remove the binary package python3-igraph on arch s390x as it fails to build due to the FTBFS on s390x bug #1003395. This issue raised because the python-igraph now builds against the libigraph-dev package after a recent refreshing (by me). Note also that I am actively working on bug #1003395. This bug in fact a ``hard'' numerical bug. Cheers, Jerome
Bug#1032936: bliss: New website for bliss and new releases
Hi William, thanks for the note. I will migrate the package to version 0.77 asap. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1035107: unblock: singular/1:4.3.1-p3+ds-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package singular. This package fixes the RC bug #1034769: the python3-brial packages is removed from the build-dependency list (and it is substituted with python3). This change is necessary to provide singular on all supported arch while it does not affect its buildings as the python3-brial material is actually not used by singular. Please find the source diff. unblock singular/1:4.3.1-p3+ds-2 Best wishes, Jerome diff -Nru singular-4.3.1-p3+ds/debian/changelog singular-4.3.1-p3+ds/debian/changelog --- singular-4.3.1-p3+ds/debian/changelog 2023-01-03 16:14:59.0 +0100 +++ singular-4.3.1-p3+ds/debian/changelog 2023-04-27 10:16:02.0 +0200 @@ -1,3 +1,9 @@ +singular (1:4.3.1-p3+ds-2) unstable; urgency=medium + + * RC fix release, discard dependency on python3-brial (Closes: #1034769). + + -- Jerome Benoit Thu, 27 Apr 2023 08:16:02 + + singular (1:4.3.1-p3+ds-1) unstable; urgency=medium * New upstream micro version. diff -Nru singular-4.3.1-p3+ds/debian/control singular-4.3.1-p3+ds/debian/control --- singular-4.3.1-p3+ds/debian/control 2023-01-03 15:38:50.0 +0100 +++ singular-4.3.1-p3+ds/debian/control 2023-04-27 10:15:55.0 +0200 @@ -10,7 +10,7 @@ libreadline-dev, libgmp-dev, libmpfr-dev, libglpk-dev, libcdd-dev, libflint-dev, libntl-dev, graphviz, 4ti2, normaliz, surf-alggeo, topcom, - python3-brial + python3 Build-Depends-Indep: doxygen, rdfind, symlinks
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hell All, I have just made singular independent from brial. Otherwise it must be keep in mind that Sage is mostly umbrella software. That means that the dependency of brian on sage material is odd. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.
Hello Again, I think that something is wrong with the package brial. Sage is an umbrella software which involves brial, so it makes no sense that brial depends on a sage package. This is my first remark. I will have a closer look on the dependency of singular on brial. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.
Hi Peter, thanks for your report. I will have a look soon. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1030959: singular-doc: install-info reports /usr/share/info/singular.info has no info dir entry
Hi Eric, thanks for your report. The info for singular comes uncompressed because singular itself may read it. Unfortunately singular can only read it uncompressed. Previously this singular.info file was somewhere in the doc. The info file has been in the proper place since version 1:4.3.0-p1+ds-1 (then in experimental). Therefore fixing this issue requires to implement a z-read machinery in singular itself. I might be easy but heavy to write. A patch is welcome. Concerning the info dir entry issue, I will have a look to the machinery that seems to generate the tex source. Thanks for pointing this issue. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'
Dear Maintainer, I second the request by Benjamin. According to the interesting discussion on a very near subject for igraph [1], VSCode and cmake appear to attribute a different purpose to the target `test`. For packaging igraph I set a workaround in the `d/rules`. However, I guess that the `test` and `check` targets must be considered to have different purposes according to some current standards. That is, they are not interchangeable. hth, Jerome [1] https://github.com/igraph/igraph/issues/2290 -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1023360: singular-doc: info file in /usr/share/doc
Hello Jakub, thanks for your report. The issue has been already fixed in the current experiemental. I am on my way to upload it to unstable. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020380: singular-modules: Files p_Procs_Field${x}.so, for x in General Indep Q Zp, are now symlinks to p_Procs_Field${x}.so.0.0.0 , however, those are missing
Hello Jan, thanks for your report. I could reproduce the issue and, more importantly, I isolated it. I am on my way to fix it. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020747: Fwd: Python 3.11 is now a supported release in unstable
Thanks for the reply. On 11/11/2022 13:49, stefa...@debian.org wrote: Hi Jerome (2022.11.11_12:23:42_+) Fixing the #1020747 may avoid FTBFS for some packages. I proposed a solution to fix it, however I cannot say if it optimal. That patch looks reasonable to me. I'd have done the [:3] inside the tuple(), but that's not exactly a problem. I will try to step forward by the end of the week-end if no one else do it before. Cheers, Jerome SR -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Hello Bill, I got a closer look. It appears that [gap-]guava auxiliary binaries do not depend on gap-dev related packages. We must discard this dependency a part of resolving the issue. However, these auxiliary binaries are C compiled executables, that is to say that they are not scripts. Therefore the comment above/below is relevant. > > > > > However only the last dir[ectory] may work on muti-architecture boxes. > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ between the two current ones: > > > can gap support this ? > > > > GAP does not have the notion of the Debian triplet, so it is difficult to write a patch > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/ > > I guess that a patch can be written to do so. This probably requires changing the C code to define a new GAPInfo.DEB_HOST_MULTIARCH field. Do you have a better idea ? I am ready to write such a C patch. Is that okay with you ? Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Hello Bill, thanks for your reply.
On 03/11/2022 11:49, Bill Allombert wrote:
On Wed, Nov 02, 2022 at 11:13:07AM +0100, Jerome BENOIT wrote:
Hello Bill, thanks for your message.
Hello Jerome,
Please keep in mind that the BTS does not forward email to the submitter so
you always need to CC them otherwise they will not see your answer!
I only found it by luck, because I see your upload.
I was trying to fix the issue when you sent the report.
I isolated the issue as you did.
Solution 1) would the solution on box with one architecture, not on box with
multi-architectures.
The package test relies DirectoriesPackagePrograms gap procedure (see
debian/tests/makecheck.tst )
In Sid environment as provided by autopkgtest(1),
DirectoriesPackagePrograms( "guava" )
gives
[ dir("/usr/share/gap/pkg/guava/bin/"),
dir("/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/") ]
which is in agreement with your comments.
Indeed, the GAP patch debian/patches/program-path adds
/usr/share/gap/pkg/guava/bin/ to this list.
However only the last dir[ectory] may work on muti-architecture boxes.
Here we would need a "/usr/share/gap/pkg/guava/bin/ between the
two current ones:
can gap support this ?
GAP does not have the notion of the Debian triplet, so it is difficult to write
a patch
to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/
I guess that a patch can be written to do so.
There is a single /usr/bin for all archs, so in particular a single
/usr/bin/gap,
so I do not see why we need to support several /usr/share/gap/pkg/guava/bin,
especially since mismatched gap-core and gap-guava-bin should work.
Along this reasonning,
/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/ has no use.
Meanwhile (before reading your report) I gave a new try by imposing gap >= 4.12
.
This is not sufficient, because it will break again when kv9 happens, for no
reason.
I agree.
Without this bug, gap would be in testing today.
This is migration in action.
My only way out is to reupload gap with Breaks: gap-guava-bin (<= 3.17+ds-2),
which will waste 5 days.
The only way out is to fix [gap-]guava .
Also this is an artificial dependency ( guava only requires >= 4.8.0) that will
make
upgrades more complex, again for no reason.
Indeed.
Please let me fix this guava issue by the week-end.
Best wishes,
Jerome
Cheers,
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Hello Bill, thanks for your message.
I was trying to fix the issue when you sent the report.
I isolated the issue as you did.
Solution 1) would the solution on box with one architecture, not on box with
multi-architectures.
The package test relies DirectoriesPackagePrograms gap procedure (see
debian/tests/makecheck.tst )
In Sid environment as provided by autopkgtest(1),
DirectoriesPackagePrograms( "guava" )
gives
[ dir("/usr/share/gap/pkg/guava/bin/"),
dir("/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/") ]
which is in agreement with your comments.
However only the last dir[ectory] may work on muti-architecture boxes.
Here we would need a "/usr/share/gap/pkg/guava/bin/ between the
two current ones:
can gap support this ?
Meanwhile (before reading your report) I gave a new try by imposing gap >= 4.12
.
Best wishes,
Jerome
On Wed, 2 Nov 2022 10:10:48 +0100 Bill Allombert wrote:
Package: gap-guava-bin
Version: 3.17+ds-2
Severity: normal
Dear Debian Science Maintainers,
gap-guava-bin includes the directory
/usr/lib/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv7
but does not depend on gap-kernel-7.
1) As far as I can see, the guava binaries are not linked against the gap-kernel
so are independent of it, so the binaries should just go to
/usr/lib/gap/pkg/guava/bin/
2) the new gap kernel 4.12 is gap-kernel-8 and will not find binaries in
x86_64-pc-linux-gnu-default64-kv7
3) if for some reason, you really need x86_64-pc-linux-gnu-default64-kvN, you
need to depend on gap-kernel-N.
Cheers,
--
Bill.
Imagine a large red swirl here.
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1020747: AM_PATH_PYTHON
control: reassign -1 autoconf-archive
control: tags -1 patch
I have just doublechecked: the bug does lie in autoconf-archive .
The faulty code was introduce in commit df89f6cdaade38f3c1c9987be0c5a57c96fc1730
https://github.com/autoconf-archive/autoconf-archive/commit/df89f6cdaade38f3c1c9987be0c5a57c96fc1730
The current code tuple(sys.version_info) gives the 5-tuple (3, 10, 7, 'final',
0) while
the former code sys.version.split()[0] would give the 3-tuple (3, 10, 7).
So, at first glance, the current code tuple(sys.version_info) should be
replaced by
tuple(sys.version_info)[:3].
A patch that applied to the current ax_python_devel serial 32 is attached.
Best wishes,
Jerome
On Fri, 30 Sep 2022 14:31:47 + Bastien =?ISO-8859-1?Q?Roucari=E8s?=
wrote:
control: reassign -1 automake
control: affects -1 autoconf-archive
Hi,
The macro AM_PATH_PYTHON dos not support 3 level python version...
The bug lie in automake not autoconf-archive
Could be workarround by a little sed script in order remove micro version on graph tool
side
Bastien
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
--- ax_python_devel.m4-s32.original 2022-10-01 17:42:46.0 +0200
+++ ax_python_devel.m4 2022-10-16 18:40:38.873380357 +0200
@@ -125,7 +125,7 @@
return tuple(map(int, s.strip().replace("rc", ".").split(".")))
def __init__(self):
import sys
-self.vpy = tuple(sys.version_info)
+self.vpy = tuple(sys.version_info)[[:3]]
def __eq__(self, s):
return self.vpy == self.vtup(s)
def __ne__(self, s):
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1020747: AM_PATH_PYTHON
Hello Bastien, thanks for your reply. On Fri, 30 Sep 2022 14:31:47 + Bastien =?ISO-8859-1?Q?Roucari=E8s?= wrote: control: reassign -1 automake control: affects -1 autoconf-archive Hi, The macro AM_PATH_PYTHON dos not support 3 level python version... The `configure.ac' of graph-tool passes a 2 level python version to AM_PATH_PYTHON. The bug lie in automake not autoconf-archive Could be workarround by a little sed script in order remove micro version on graph tool side Can you please more specific here ? Are you referred to the PYTHON_FULL_VERSION set up in `configure.ac' ? If so, it was working well before ax_python_devel serial 32 went. Second, I am not sure that removing micro version for devel stuff is a good idea. Best wishes, Jerome Bastien -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1020747: autoconf-archive: ax_python_devel serial 32 fails with current Sid python3
Package: autoconf-archive Version: 20220903-1 Severity: serious Tags: upstream Justification: causes FTBFS issues Dear Maintainer, it appears that ax_python_devel serial 32 provided by this package can cause FTBFS issues. I experienced it with the package grap-tool (#101). A closer look reveals that the ad hoc python module ax_python_devel_vpy.py fails with the current Sid Python. My understanding is that the tuple vpy contains an unexpected string. Unfortunately I am no familiar with Python to get further. Cheers, Jerome
Bug#1016296: flint: FTBFS: dh_auto_test: error: make -j8 check
ping -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1012530: 4ti2: package header files
Hi Doug, you are correct, 4ti2 is indeed a library. I am considering to add lib4ti2-dev package. Thanks, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error
Hello, the issue was fixed in the upstream version, serial 23 : https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_cc_maxopt.m4 hth, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1015964: logrotate.conf: olddir may extend tilde to HOME directory
Package: logrotate Version: 3.18.0-2+deb11u1 Severity: wishlist Tags: upstream Dear Maintainer, thanks for your work. olddir may expand tilde (~) to the HOME directory of the current user as entries do. Note that this looks as an inconsistency: entries expand ~ (tilde) while oldir's do not. Best wishes, Jerome -- Package-specific info: Contents of /etc/logrotate.d total 84 -rw-r--r-- 1 root root 120 Apr 19 2019 alternatives -rw-r--r-- 1 root root 173 Mar 14 2013 apt -rw-r--r-- 1 root root 79 Nov 7 2012 aptitude -rw-r--r-- 1 root root 378 Jan 10 2014 backupsync -rw-r--r-- 1 root root 130 Aug 29 2018 btmp -rw-r--r-- 1 root root 593 Aug 22 2015 chrony -rw-r--r-- 1 root root 181 Jun 9 2015 cups-daemon -rw-r--r-- 1 root root 319 Jan 10 2014 ddns -rw-r--r-- 1 root root 112 Apr 19 2019 dpkg -rw-r--r-- 1 root root 128 May 4 2021 exim4-base -rw-r--r-- 1 root root 108 May 4 2021 exim4-paniclog -rw-r--r-- 1 root root 716 Jul 12 2019 fetchmail -rw-r--r-- 1 root root 406 Jul 28 2014 firehol -rw-r--r-- 1 root root 119 Aug 27 2014 gapd -rw-r--r-- 1 root root 363 Aug 24 2021 hdak -rw-r--r-- 1 root root 157 Jan 16 2012 pm-utils -rw-r--r-- 1 root root 374 Feb 17 2021 rsyslog drwxr-xr-x 2 root root 4096 Jul 12 2019 scripts -rw-r--r-- 1 root root 401 Jul 2 2018 ulogd2 -rw-r--r-- 1 root root 58 Apr 17 2017 wdm -rw-r--r-- 1 root root 145 Feb 19 2018 wtmp -- System Information: Debian Release: Bullseye* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages logrotate depends on: ii anacron 2.3-30 ii cron [cron-daemon] 3.0pl1-137 ii libacl1 2.2.53-10 ii libc6 2.31-13+deb11u3 ii libpopt01.18-2 ii libselinux1 3.1-3 Versions of packages logrotate recommends: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 logrotate suggests no packages. -- no debconf information
Bug#1004669: ifupdown: ifdown does not found xargs
Package: ifupdown Version: 0.8.36 Severity: normal Dear Maintainer, if I run `ifdown wlan0` I get three times the message /usr/sbin/invoke-rc.d: 1: xargs: not found hence my report. I can fix this issue by setting a link of xargs in /bin/xargs Note that my box is a sysvinit box. hth, Jerome -- System Information: Debian Release: Bullseye* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u2 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.3 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information
Bug#1003419: ITP: primecount -- fast prime number counter C/C++ library
Package: wnpp Severity: wishlist Owner: Jerome Benoit X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: primecount Version : 7.2 Upstream Author : Kim Walisch * URL : https://github.com/kimwalisch/primecount * License : BSD-2-clause Programming Lang: C/C++ Description : fast prime number counter C/C++ library primecount is a command-line program and C/C++ library that counts the primes below an integer x <= 10**31 using highly optimized implementations of the combinatorial prime counting algorithms. primecount includes implementations of all important combinatorial prime counting algorithms known up to this date all of which have been parallelized using OpenMP. primecount contains the first ever open source implementations of the Deleglise-Rivat algorithm and Xavier Gourdon's algorithm (that works). primecount also features a novel load balancer that is shared amongst all implementations and that scales up to hundreds of CPU cores. primecount has already been used to compute several prime counting function world records. primecount will be part of sagemath. I am planning to maintain primecount in behalf of the Debian Math Team. Notice that I am actually maintaining a related package by the same author, primesieve.
Bug#802212: Patch
Dear Chad, thanks for your report and your patches. The issue will be fixed in package 2.3+ds-5. Thanks for your patience, Jerome On Sun, 27 Dec 2015 12:23:14 -0800 Chad Wallace wrote: Here's another version of that patch... with a free(dotdir) after we're done with it. -- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0 -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#828739: ssh-agent lost on nested ssh sessions
Hello, the next package 2.3+ds-4 fixes the issue. Thanks for your patience, Jerome On Mon, 13 Feb 2017 13:24:28 +0100 Harald Dunkel wrote: Hi Jerome, Any news on this problem? Apparently it is still unresolved for Stretch, even though this report was filed in time :-(. This problem is *highly* painful if you have to work a lot on remote sites. Currently I get less problems if I keep libpam-ssh uninstalled, which is surely not the idea behind this package. Would you mind to increase the severity and forward this report to upstream? Thanx very much Harri -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#784658: libpam-ssh cannot authenticate user from "Additional" block in pam.d/common-auth
Hello Ilkka, thanks for your comments.
I apologize for my late reaction.
I understand that the current suggested authenticated scheme
is rather oriented to passwords than to SSH key passphrases.
But you expect the latter. So in the coming package version 2.3+ds-4
three schemes will be available. The current one will stay as default,
the two new scheme follows your expectation. The difference between
them is that one is client oriented ('use_first_pass') and the other
is server oriented ('try_first_pass').
Cheers,
Jerome
OpenPGP_signature
Description: OpenPGP digital signature
Bug#994992: libpam-ssh: pam-ssh picks the from agent socket after login with ssh -A
Hello Stephan, thanks for your report. I guess that your issue is related to issue #995452 . I haved just merged them. Attached patch fixes the problem by omiting `session optional pam_ssh.so` from /etc/pam.d/sshd. Thanks for the patch. However note that it is not applicable because /etc/pam.d/sshd is actually distributed along the package `openssh-server` (you can check this wit apt-file(1)). For a working (but hopefully temporary) workaround you can have a look to the aforementionned bugreport. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#828739: ssh-agent lost on nested ssh sessions
On Mon, 13 Feb 2017 13:24:28 +0100 Harald Dunkel wrote: Hello Harri, sorry for my late reply. I have just got a fresh look with bugreport #995452 < https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995452 > in mind. I can indeed reproduce your issue. However I cannot see the point to nested connection. Can you give me a practical usage ? Hi Jerome, Any news on this problem? Apparently it is still unresolved for Stretch, even though this report was filed in time :-(. This problem is *highly* painful if you have to work a lot on remote sites. Currently I get less problems if I keep libpam-ssh uninstalled, which is surely not the idea behind this package. Would you mind to increase the severity and forward this report to upstream? Upstream is actually dormant. Cheers, Jerome Thanx very much Harri -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing
Hello, I have just migrated from Buster to Bullseye. The package libhdf5-mpi-dev was and is not installed on my box. However `update-alternatives --display hdf5.pc` outputs hdf5.pc - auto mode link best version is /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpi.pc link currently points to /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpi.pc link hdf5.pc is /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5.pc /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpi.pc - priority 35 /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpich.pc - priority 10 /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-serial.pc - priority 20 The disturbing thing is that /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpi.pc points to /dev/null I guess that this issue is related to this bug. HTH, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#998413: gap-float: autopkgtest regression: object must be an MPFR, not a integer
Fixed in package version 1.0.2+ds-1. -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1001658: singular: cannot upgrade to 1:4.2.1-p2+ds-3
Dear Patrice, thanks for your report. I am on my way to try to fix it. Jerome On Mon, 13 Dec 2021 20:38:06 +0100 Patrice Duroux wrote: Package: singular Version: 1:4.1.1-p2+ds-4+b3 Severity: wishlist Dear Maintainer, Here is what I am getting: $ sudo LANG=C apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libsingular4m1 : Breaks: libsingular E: Broken packages I do not know also why apt transaction is aborted while there are some other package to upgrade. Is this also a trouble in apt? Thanks, Patrice -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages singular depends on: ii singular-data 1:4.1.1-p2+ds-4 pn singular-modules pn singular-ui singular recommends no packages. singular suggests no packages. -- no debconf information -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
Hello Michael, On Fri, 01 Oct 2021 14:37:44 +0200 Michael Schindler wrote: x On the client machine with libpam-ssh installed, however, this functionality is broken: Instead of forwarding the agent from the server, it sets the environment variables SSH_AUTH_PID and SSH_AUTH_SOCK then point to the freshly started ssh-agent on the client, which has no keys charged. Thus, the login to the next client fails. Basically you say that there a competition between sshd and libpam-ssh. And in fact that this competition is actually not well managed. Actually, I think that there is no policy at all for this situation. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
On Mon, 29 Nov 2021 11:19:36 +0100 Jerome BENOIT wrote: Thanks for sharing your file. I will have a closer look soon, Cheers, Jerome ping, cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
Thanks for sharing your file. I will have a closer look soon, Cheers, Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#992003: [Debian-science-sagemath] Singular update
On my way, cheers, Jerome On Sat, 20 Nov 2021 12:34:06 + Dima Pasechnik wrote: On Sat, 20 Nov 2021, 08:08 Tobias Hansen, wrote: > Hi Jerome, > > any chance we could get an update of singular to 4.2.1.p0 in experimental? > I tried to do it myself once but the package has many patches and it was > difficult to get everything right. > 4.2.1.p2 is already there: https://trac.sagemath.org/ticket/32907 > Best, > > Tobias > > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
On Sun, 3 Oct 2021 03:25:54 +0300 Matti Kurkela wrote: Dear Kurkela, thanks for your report. I apologies for my late reply. Actually I agree with your comments. My current set up on my main computer follows your comment below. So far I can remember, I have never revisited the pam-auth-update(8) configuration file of this package since I begun to maintain it. Meanwhile, note that I put some warning in the README.Debian file. Can you share your /etc/pam.d/login and /etc/pam.d/*dm files so that I can compare with my set up ? The workaround/fix for this would be to not let pam-auth-update add pam_ssh.so into common-auth and common-session, but add the necessary lines *selectively* only to services that handle local logins like /etc/pam.d/login and /etc/pam.d/*dm, but *not* to /etc/pam.d/sshd. That should allow libpam-ssh to start the agent on initial login, but leave the SSH sessions and their agent forwarding alone. If you need the "authentication by SSH key passphrase" functionality on SSH connections, you could add only the "auth optional pam_ssh.so try_first_pass" line to /etc/pam.d/sshd. (Note that this line should not be the first authentication module, to prevent an information leak, as described in the pam_ssh(8) man page.) Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. The upstream maintainer would like to know the number of cpus from a Python shell. import multiprocessing as mp; print(mp.cpu_count()); Can you get this information ? In fact, I am curious to know it as well. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. I can reproduce the issue on my amd64 box by substituting mp.cpu_count() by 160 in the called function. We are progressing. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers wrote: Hello Paul, Is this run on all cores? Our armhf worker has 160 cores, so you may be running into limits you didn't expect. This would be a surprising bug, indeed. I will have a closer look. But I think I have ultimately to contact the upstream author. Otherwise, is there a way to limit the number of cores to use through an environment variable (or something along this way) ? Cheers, Jerom -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh
I am working on it. OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)
Hello, a closer look on the log files shows that actually the failed test (elevation) download a corrupted data file on the armhf CI box by comparison against the size of the same data file downloaded on the other CI boxes. It sound pretty much as a subtle bug form some of the dependencies. Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)
Hi, it appears that I cannot reproduce the issue on the armhf porterbox amdahl.debian.org . Cheers Jerome OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: Restriction not respected
Hello Paul, it seems that the Restriction needs-internet is not respected. Cheers, Jerome -- Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net https://www.rezozer.net/ OpenPGP_signature Description: OpenPGP digital signature
Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap
Hello Bill, thanks for the correction and sorry for my late reaction. I have just updated the gap-io package accordingly. All looks fine. Meanwhile I have noticed that /usr/lib/gap/sysinfo.gap and /usr/lib/x86_64-linux-gnu/gap/sysinfo.gap are actually the same files. Cheers, Jerome On Fri, 24 Sep 2021 13:27:28 +0200 Bill Allombert wrote: Le Sun, Apr 18, 2021 at 08:40:41PM +0200, Jerome BENOIT a écrit : Hello Jerome, I am working on updating GAP to 4.11.1, sorry for the delay. > > > I have just packaged the last version 4.7.1 of gap-io. > > > Its build machinery has changed. It now uses a Gap makefile Makefile.gappkg . > > > This makefile implicitly assumes (?=) that the gap and gac are into GAPPATH > > > as passed at configuration time. The GAPPATH is /usr/lib/gap or /usr/lib//gap : > > > the former contains gac, the latter gap. It would be nice to have > > > both > at least > > > in one of the GAPPATH. > > > > Why not set GAPPATH to /usr/bin then ? > > Because GAPPATH is also used to get access to sysinfo.gap . OK, so if I move gac to /usr/lib//gap, will it work ? Cheers, -- Bill. Imagine a large red swirl here. -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array
Hello Paul, thanks for pointing out the issue.
I will try to have a look this week-end.
Cheers,
Jerome
On 24/09/2021 22:23, Paul Gevers wrote:
Source: osmnx
Version: 1.1.1+ds-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of osmnx the autopkgtest of osmnx fails in testing
on armhf when that autopkgtest is run with the binary packages of osmnx
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
osmnx from testing1.1.1+ds-2
all others from testingfrom testing
I copied some of the output at the bottom of this report. On top of the
failure, you test seems to be sending requests to the internet, please
use the needs-internet restriction [0] to mark is as such.
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]
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
[1] https://qa.debian.org/excuses.php?package=osmnx
https://ci.debian.net/data/autopkgtest/testing/armhf/o/osmnx/15474259/log.gz
=== FAILURES
===
test_elevation
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/lib/python3.9/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/usr/lib/python3.9/multiprocessing/pool.py", line 51, in starmapstar
return list(itertools.starmap(args[0], args[1]))
File
"/tmp/autopkgtest-lxc.2hzrzn35/downtmp/build.elV/src/osmnx/elevation.py", line
49, in _query_raster
return zip(nodes.index, values)
TypeError: iteration over a 0-d array
"""
The above exception was the direct cause of the following exception:
def test_elevation():
G = ox.graph_from_address(address=address, dist=500,
dist_type="bbox", network_type="bike")
rasters = list(Path("tests/input_data").glob("elevation*.tif"))
# add node elevations from a single raster file (some nodes will
be null)
G = ox.elevation.add_node_elevations_raster(G, rasters[0], cpus=1)
# add node elevations from multiple raster files
G = ox.elevation.add_node_elevations_raster(G, rasters)
/usr/share/doc/python-osmnx-doc/examples/tests/test_osmnx.py:201:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
osmnx/elevation.py:98: in add_node_elevations_raster
results = sma.get()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = , timeout = None
def get(self, timeout=None):
self.wait(timeout)
if not self.ready():
raise TimeoutError
if self._success:
return self._value
else:
raise self._value
E TypeError: iteration over a 0-d array
/usr/lib/python3.9/multiprocessing/pool.py:771: TypeError
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature
Description: OpenPGP digital signature
Bug#993269: RFS: e-antic 0.1.8+ds-2
Hello, thanks for the update. I will apply the patch by tomorrow. Cheers, Jerome On 22/09/2021 12:46, 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? https://salsa.debian.org/science-team/e-antic Thanks! Doug -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#993322: firehol: Firehol delays system startup
Hi David, thanks for your answers. On 31/08/2021 11:02, David Jarvie wrote: On Tue, 31 Aug 2021 08:53:55 +0200 Jerome BENOIT wrote: Did the same happen with your previous firehol package ? I didn't have this issue with Firehol on my previous system. That system was quite old - Debian 8 (Jessie). It has only happened since installing Bullseye. A big step of 3. Firehol may have gain IPv6 support and some minor changes since then. But most importantly, Firehol did stick to ipatable legacy tools. Meanwhile, systemd stuff reached Debian. What I mean is that you may want to update your configuration files as regarding FireHOL. Is you configuration waiting for any iface (see WAIT_FOR_IFACE (/etc/default/ firehol)) ? Yes, it waits for my Ethernet interface: WAIT_FOR_IFACE="enp2s0" This is consistent with the log file you sent. If you do not really need to wait for the IFACE, try to empty the list. On my laptop box which is configure only for the unique Wifi IFACE, I mange firehol with a simple ifupdown script (interfaces(1)) so that I can empty the above list. Please let us know if this can fix your issue. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#993322: firehol: Firehol delays system startup
Hello David, thanks for the report. We may need more to see what is happening. Did the same happen with your previous firehol package ? Is you configuration waiting for any iface (see WAIT_FOR_IFACE (/etc/default/firehol)) ? Best wishes, Jerome On 30/08/2021 21:56, David Jarvie wrote: Package: firehol Version: 3.1.7+ds-2 Severity: normal Dear Maintainer, At each system boot, Firehol takes a full minute to initialise, and makes the boot process hang for some of that time. Looking at the system log (attached), it isn't obvious why Firehol takes just over 1 minute to complete, or why nothing seems to happen between 19:49:40 and 19:50:08, during which a console message is displayed saying that the boot process is waiting for Firehol to finish. The command 'firehol restart' takes very little time to complete once the system is up and running. This indicates that something is wrong at boot time, and that Firehol is presumably waiting for something else to complete. I would have expected Firehol to initialise quickly during boot, and not to hang the boot process. I attach the journalctl output, from Firehol start to Firehol completion: -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firehol depends on: ii firehol-common 3.1.7+ds-2 ii init-system-helpers 1.60 ii lsb-base 11.1.0 Versions of packages firehol recommends: ii fireqos 3.1.7+ds-2 Versions of packages firehol suggests: ii firehol-doc3.1.7+ds-2 pn firehol-tools pn ulogd2 -- Configuration Files: /etc/default/firehol changed: START_FIREHOL=YES WAIT_FOR_IFACE="enp2s0" FIREHOL_ESTABLISHED_ACTIVATION_ACCEPT=0 /etc/firehol/firehol.conf changed: version 6 stewjar=192.168.178.100 local="192.168.178.101 192.168.178.102 192.168.178.103" m2885fw=192.168.178.90 interface4 enp2s0 ethernet # The default policy is DROP. You can be more polite with REJECT. # Prefer to be polite on your own clients to prevent timeouts. policy drop # Protect from the internet. protection strong # The following means that this machine can REQUEST anything via enp2s0. client all accept # Specific services that this machine needs to request via enp2s0. client multicast accept client dhcp accept # Services that this machine offers to local network. server ping accept src "$local" server ssh accept src "$local" server cups accept src "$local" # Samsung M2885FW printer (needs both client and server) # The script 'scanner-enable' must be run after Firehol, to fix # iptables entries to allow SNMP to work properly. client snmp accept dst $m2885fw server snmp accept src $m2885fw server samba accept # The following enp2s0 server ports are not known by FireHOL: # tcp/45485 tcp/49074 tcp/7741 udp/32768 udp/32769 udp/517 udp/518 udp/5353 udp/7741 udp/972 # TODO: If you need any of them, you should define new services. # (see Adding Services at the web site - http://firehol.sf.net). interface usb0 usb policy accept -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#991025: merkaartor build depends on both libqt5webkit5-dev and qtwebengine5-dev but uses neither
Hello Bas, thanks for letting me know that version 0.19 is now out. I will package it by the week-end. Best wishes, Jerome On 27/08/2021 17:34, Sebastiaan Couwenberg wrote: Jérôme, Are you going to fix this issue and the related issue about not migrating to testing (#993126), e.g. while packaging the 0.19.0 release? If not, merkaartor will be removed from Debian again. Kind Regards, Bas -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#990640: e-antic: new major uptream version 1.0.x
Package: e-antic Severity: normal Hello, it appears tha the new upstream version of e-antic depends on the C library ANTIC. ANTIC is currently not supported in Debian. I have just submitted an ITP (#990638). Cheers, Jerome
Bug#990638: ITP: antic -- Algebraic Number Theory In C
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: antic Version : 0.2.4 Upstream Author : William Hart * URL : https://github.com/wbhart/antic * License : GPL Programming Lang: C Description : Algebraic Number Theory In C ANTIC is an algebraic number theory library. The e-antic library (e-antic package) depends now on the antic library. I am planning to maintain ANTIC in behalf of the Debian Science Maintainers team.
Bug#987559: ITP: plfit -- fitting power-law distributions to empirical data
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: plfit Version : 0.8.2 Upstream Author : Tamás Nepusz * URL : https://github.com/ntamas/plfit * License : GPL Programming Lang: C, Python Description : fitting power-law distributions to empirical data This program fits power-law distributions to empirical (discrete or continuous) data, according to the method of Clauset, Shalizi and Newman [SIAM Review 51, 661-703 (2009)]. This package is relevant in data analysis. It is actually part of the igraph C library as vendor software. igraph is a reputed suite of software to study networks. However plfit is not limited network study. I am planning to maintain plfit in behalf of the Debian Science Maintainers team.
Bug#987160: Fwd: Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap
Forwarded Message Subject: Re: Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap Date: Sun, 18 Apr 2021 20:40:41 +0200 From: Jerome BENOIT Reply-To: calcu...@rezozer.net Organisation: ReZoZeR To: Bill Allombert On 18/04/2021 20:05, Bill Allombert wrote: On Sun, Apr 18, 2021 at 06:21:14PM +0200, Jerome Benoit wrote: Package: gap-core Version: 4r10p0-7 Indeed. I package in a Sid chroot environemnt, and I sent the report from my Buster box. Hello Jerome, 4r10p0-7 is not the version in sid ? I have just packaged the last version 4.7.1 of gap-io. Its build machinery has changed. It now uses a Gap makefile Makefile.gappkg . This makefile implicitly assumes (?=) that the gap and gac are into GAPPATH as passed at configuration time. The GAPPATH is /usr/lib/gap or /usr/lib//gap : the former contains gac, the latter gap. It would be nice to have both at least in one of the GAPPATH. Why not set GAPPATH to /usr/bin then ? Because GAPPATH is also used to get access to sysinfo.gap . Note that the makefile is meant to be used among the Gap package. Cheers, Jerome Cheers, -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap
Package: gap-core Version: 4r10p0-7 Severity: normal Dear Maintainer, I have just packaged the last version 4.7.1 of gap-io. Its build machinery has changed. It now uses a Gap makefile Makefile.gappkg . This makefile implicitly assumes (?=) that the gap and gac are into GAPPATH as passed at configuration time. The GAPPATH is /usr/lib/gap or /usr/lib//gap : the former contains gac, the latter gap. It would be nice to have both at least in one of the GAPPATH. Cheers, Jerome -- System Information: Debian Release: Sid Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Dennis, thanks for your reply. I was rather wondering if setting Rules-Requires-Root to yes in d/rules will ask to bbuild to act as "needs-root" for autopkgtest. Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear all, > The autopkgtest probably will have to specify "needs-root" to set > unprivileged_userns_clone=1 (unless the VM image already has that set > up), but the test suite itself needn't run as root.w Will set Rules-Requires-Root to yes in d/rules solve the issue ? Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Paul Gevers, please consider to tag #982719 as bullseye-ignore given that the issue is not a package issue but it seems rather related to an chroot issue. Best regards, Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Dennis, thanks for your message. I think that the issue is actally not a firehol issue. But I cannot figure out to where the issue can be redirected. For now, I am reluctant to neutralize the tests. @Lucas: do you have any hint ? Thanks, Jeromr -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Hi Dennis, thanks for confirming. May I simply neutralize the involved test temporarily ? Cheers, Jerome
Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
Dear Lucas, thanks for your report. I can not reproduce the issue on a Sid schroot a the time of writing. Please, can you confirm the issue on your side ? Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#981839: RM: 3dldf-doc/2.0.3+ndfsg-4, RoM, dead uptream
Hello, thanks for your message. On 04/02/2021 14:57, Adam D. Barratt wrote: > On Thu, 2021-02-04 at 14:35 +0100, Jerome Benoit wrote: >> This package distributes the document for the package 3dldf >> which is no more part of Debian. This software is actually >> dead upstream. >> > > Then presumably it wants removing from unstable, rather than just > testing? Indeed, from testing and from unstable. Cheers, Jerome > > Regards, > > Adam > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#981839: RM: 3dldf-doc/2.0.3+ndfsg-4, RoM, dead uptream
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package distributes the document for the package 3dldf which is no more part of Debian. This software is actually dead upstream. Jerome Benoit -- System Information: Debian Release: Buster* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#981836: RM: igraph [mips64el] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal The ipgraph package randomly fails a test on mips64el (#970497). The failure was isolated as being a random failure in ARPACK (#981646), and the uptream maintainer of ARPACK is not willing to fix it. Their motivation is justified because it looks very much as an obscur compiler issue. Hence my request. Jerome Benoit
Bug#981646: arpack: dseupd randomly fails on mips64el arch
Package: libarpack2-dev
Version: 3.8.0-1
Severity: important
Dear Maintainer.
It appears that dseupd_ randomly fails on mips64el arch.
I attached a piece of C code that reproduces the issue.
This is a regression since this issue does not show up
on Buster.
Thanks for packaging arpack[-ng],
best wishes,
Jerome
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: mips64el (mips64)
Kernel: Linux 4.19.0-14-octeon (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libarpack2-dev:mips64el depends on:
ii libarpack23.8.0-1
ii libblas-dev [libblas.so] 3.9.0-3
ii liblapack-dev [liblapack.so] 3.9.0-3
libarpack2-dev:mips64el recommends no packages.
libarpack2-dev:mips64el suggests no packages.
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
// This piece of C code calls dseupd_ from the ARPCK library.
// On mips64el arch:
// - when it is build against ARPACK[-ng] 3.8.0 on Sid (20210202),
//it fails once for a while;
// - when it is build against ARPACK[-ng] 3.7.0 on Buster, it does not fail.
// This code was extracted by hand from an igraph library test
// which randomly fails only on mips64el arch (Debian bugreport #970497).
//
// # Compilation command-line:
// $ gcc -o bugreport-arpack-dseupd bugreport-arpack-dseupd.c -larpack -lm
// # Test command-line:
// $ while (./bugreport-arpack-dseupd) ; do : ; done | nl
//
#include
#include
#include
int dseupd_(
int *rvec, char *howmny, int *select,
double *d, double *z, int *ldz,
double *sigma, char *bmat, int *n,
char *which, int *nev, double *tol,
double *resid, int *ncv, double *v,
int *ldv, int *iparam, int *ipntr,
double *workd, double *workl,
int *lworkl, int *info);
int main() {
int rvec=1;
char *all="All";
int ldv=100;
double sigma=+0x0p+0;
char bmat[1]="I";
int n=100;
char which[2]="LA";
int nev=1;
double tol=+0x1p-53;
int ncv=20;
int iparam[11]={1,0,1,1,1,0,1,0,39,0,19};
int ipntr[14]={201,101,1,541,1,41,61,32582,2077767904,32582,481,32582,2077725096,32582};
int lworkl=560;
int ierr=0;
double v[2000/*(ldv*ncv)*/]={
+0x1.99988b72d9d21p-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,+0x1.9c542b6fbp-4,
+0x1.fd6f01b171511p-1,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,
-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,
-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f192p-7,-0x1.4953d5876f
Bug#970497: igraph: FTBFS on mips64el
On Thu, 28 Jan 2021 07:33:56 +0100 Jerome BENOIT wrote: > Hello, > > I am currently isolating the faulty code on the porter Eller. > > The issue seems to appear after the call to arpack functions, > so it does not look as an arparck issue. Finally I isolated the place where the issue emerge. It is indeed an arpack issue. In src/arpack.c in function igraph_arpack_rssolve the dsaupd_ loop works fine in the sense that the loop keeps giving the same output when the random seed is fixed. The issue emerges at the postamble of the loop, dseupd_ gives random output in the same conditions. I am on my way to write a small piece of arpack code to confirm this. If confirmed, I will submit the bug to the arpack debian maintainer. Best wishes, Jerome > > Best wishes, > Jerome > > -- > Jerome BENOIT | calculus+at-rezozer^dot*net > https://qa.debian.org/developer.php?login=calcu...@rezozer.net > AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#970497: igraph: FTBFS on mips64el
Hello, I am currently isolating the faulty code on the porter Eller. The issue seems to appear after the call to arpack functions, so it does not look as an arparck issue. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed
Hi, thanks for your quick replies. By reading your comment, I realized that I should try in a testing chroot environment. So I tried: I can compose the two demos in testing. Meanwhile, I noticed that the upstream source ball contains some .git* files. Otherwise, I think that distributing the demo material as-is is a very good idea. If you find the video too heavy, you can replace it with a shorter version of it. The Makefile files are simple and illustrative. Personally, I not a huge fan of latexmk, and write make own GNUmakefile. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed
Package: pdf-presenter-console Version: 4.5.0-2 Severity: minor Dear Maintainer. It appears that the demo material is not distributed. More importantly, the LaTeX demo cannot be composed. There is an option clash for the package color: ! LaTeX Error: Option clash for package color. I could not figure out how to fix it. Cheers, Jerome -- System Information: Debian Release: Buster* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages pdf-presenter-console depends on: ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgee-0.8-20.20.1-2 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libjavascriptcoregtk-4.0-18 2.30.4-1~deb10u1 ii libjson-glib-1.0-0 1.4.4-2 ii libmarkdown22.2.4-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpoppler-glib80.71.0-5 ii libsoup2.4-12.64.2-2 ii libwebkit2gtk-4.0-372.30.4-1~deb10u1 ii libx11-62:1.6.7-1+deb10u1 Versions of packages pdf-presenter-console recommends: ii gstreamer1.0-gtk3 1.14.4-1 pdf-presenter-console suggests no packages. -- no debconf information
Bug#896460: Please package ipywidgets 7
Hello, it appears that nbsphinx depends on ipywidgets 7 . Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#946810: python3-commonmark-py: update the source url in watch to match the currently supported repo
Hello, I agree with the first report. However, the suffix -bkrs to signify that this package refer to the deprecated version. The new update version should be brought to Debian without the -bkrs suffix. In other words, the material in experimental must be actually used in a new package named commonmark . @ Emmanuel, are you willing to support this new package ? Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#974104: merkaartor FTBFS: error: field ‘thePath’ has incomplete type ‘QPainterPath’
On Tue, 10 Nov 2020 06:10:41 +0100 Sebastiaan Couwenberg wrote: > This is likely caused by the recent update to Qt 5.15.1, and seems to be > fixed upstream: > > > https://github.com/openstreetmap/merkaartor/commit/e72553a7ea2c7ba0634cc3afcd27a9f7cfef089c > > Jerome, will you take care of this? I will soon. Best, Jerome > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#957464: libpam-ssh: ftbfs with GCC-10
Thanks for the report. I am working on it soon. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#957186: evolver: ftbfs with GCC-10
Thanks for the report. I am working on it soon. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#963338: sagemath: FTBFS: RuntimeError: Aborted
Thanks for the report. Meanwhile the Sagemath Debian team take a summer break. Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#963290: e-antic: FTBFS: error: #error FLINT 2.5.2 or 2.5.3 required
Hello Lucas, thanks for the report. I am working on it. Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#960143: sagetex: FTBFS in unstable
Hello, I have just pushed a fix at Salsa. Please can someone make a team upload as my Debian key is expired (I did not send keyring.debian.org in due time, my mistake). Thanks in adavance, Jerome On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Again, I am on my way to push a fix at Salsa. Jerome On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello, On 11/05/2020 10:30, Hilmar Preuße wrote: > Am 11.05.2020 um 00:21 teilte Hilmar Preuße mit: > > Hi, > >> - tkz-berge.sty does not exist in Debian any more. We can read at https://ctan.org/pkg/tkz-berge?lang=en This package has been taken temporarily out of circulation to give the author time to investigate some problems. So let do the same with this patch. Cheers, Jerome >> > Simply replacing tkz-berge.sty by tkz-base.sty does not solve the issue. > Leaving out debianization-examples.patch at least solves the issue. > >> - you need to declare a BD on sagetex itself, else the sagetex.sty >> is not available. >> > This is of course non-sense: the sagetex.sty is created during package > build. > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Hilmar, On 10/05/2020 14:06, Hilmar Preuße wrote: > Am 10.05.2020 um 08:46 teilte Jerome BENOIT mit: > > Hi Jerome, > >> Hello Graham, thanks for the report. >> It sounds a Depends issue. >> > I guess some style files moved to another Debian package and hence they > are missing now. I guess something like that. Do you need help by fixing the issue? Thanks, I will fix it as soon as my renewed key reach Debian. Thanks, Jerome > > Hilmar > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#960143: sagetex: FTBFS in unstable
Hello Graham, thanks for the report. It sounds a Depends issue. I will fix it as soon as my extended key reaches the Debian keyring. Best, Jerome On 10/05/2020 01:01, Graham Inggs wrote: > Source: sagetex > Version: 3.4+ds-1 > Severity: serious > Tags: ftbfs > > Hi Maintainer > > Sagetex currently FTBFS in unstable [1]. > I've copied what I hope is the relevant part of the log below. > > Regards > Graham > > > [1] > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagetex.html > > > kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 > tcrm1000 > mkdir: cannot create directory '././nonexistent': Permission denied > mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; > nonstopmode; input tcrm1000 > This is METAFONT, Version 2.7182818 (TeX Live 2020/Debian) (preloaded base=mf) > > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm1000.mf > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exbase.mf) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm.mf > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymb.mf > Ok (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exaccess.mf > Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txpseudo.mf > Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txaccent.mf > Ok [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [27] [29]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txgen.mf > Ok [100] [109] [98] [99] [108]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymbol.mf > Ok [13] [18] [21] [22] [23] [24] [25] [26] [28] [31] [32] [36] [39] [44] > [45] [46] [42] [47] [60] [61] [62] [77] [79] [87] [110] [91] [93] [94] [95] > [96] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] > [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] > [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] > [162] [163] [164] [165] [166] [167] [168] [169] [171] [172] [173] [174] > [175] [177] [176] [180] [181] [182] [183] [184] [187] [191] [214] [246]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txromod.mf > Ok [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrsuper.mf > Ok [185] [178] [179] [170] [186]) > (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrfract.mf > Ok [188] [189] [190]) ) ) ) > (some charht values had to be adjusted by as much as 0.06943pt) > Font metrics written on tcrm1000.tfm. > Output written on tcrm1000.600gf (128 characters, 23548 bytes). > Transcript written on tcrm1000.log. > mktexpk: /tmp/texfonts/pk/ljfour/jknappen/ec/tcrm1000.600pk: > successfully generated. > make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' > /usr/bin/make example.pdf TEXOPTS="-interaction batchmode" > TEXINPUTS=".:_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/:" > PYTHONPATH=_build/DEBIAN/usr/lib/python3.8/dist-packages > VPATH=_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/DEBIAN/usr/lib/python3.8/dist-packages > DOT_SAGE=/build/1st/sagetex-3.4+ds/_test/DOT_SAGE > MPLCONFIGDIR=/build/1st/sagetex-3.4+ds/_test/MPLCONFIGDIR > MAXIMA_USERDIR=/build/1st/sagetex-3.4+ds/_test/MAXIMA_USERDIR > make[2]: Entering directory '/build/1st/sagetex-3.4+ds' > pdflatex -interaction batchmode example.tex > This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) > (preloaded format=pdflatex) > restricted \write18 enabled. > entering extended mode > make[2]: *** [Makefile:21: example.pdf] Error 1 > make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' > make[1]: *** [debian/rules:59: override_dh_auto_test] Error 2 > make[1]: Leaving directory '/build/1st/sagetex-3.4+ds' > make: *** [debian/rules:28: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#958495: gap-io: please update for new GAP ABI
Dear Bill, thanks for your message.
I understand that GAP comes now with an official ABI.
Currently the package gap-io depends for building on gap and gap-dev,
while the package itseld depends only on gap.
You asked to make it depends on gap-kernel-7.
My understanding is that gap-kernel-7 is not a package.
I could build the package gap-io on a sane Sid environment (schroot)
without modification. But, the resulting gap-io package still depends
only depends on gap.
Do you mean that I must add by hand libgap7 to the list of dependencies
(as ${shlibs:Depends} does not add it) ?
Best,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
signature.asc
Description: OpenPGP digital signature
Bug#958999: igraph: the library and PC metadata report wrong version
Source: igraph
Version: 0.8.1+ds-3
Severity: normal
Tags: patch
Dear Maintainer,
it appears that the version tuple encoded in the library
and in the pkg-config metadata is wrong. This can be a
development issue. The provided patch alters the upstream
script that generates on the fly the version tuple.
This patch generates a version tuple based on the verion
of the debian package.
Cheers,
Jerome
-- System Information:
Debian Release: Buster*
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- a/tools/getversion.sh
+++ b/tools/getversion.sh
@@ -1,13 +1,4 @@
#! /bin/bash
-
-thistag=$(git describe --exact-match --tags HEAD 2>/dev/null || true)
-
-if [ -z "${thistag}" ]; then
-# taghash=$(git rev-list --tags --max-count=1)
-# tag=$(git describe --tags "$taghash")
-next_version=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && cat NEXT_VERSION )
-current=$(git rev-parse --short HEAD)
-echo "${next_version}-pre+${current}"
-else
-echo "${thistag}"
-fi
+version_upstream=$(dpkg-parsechangelog -S Version | sed -e 's/+[^+]*$//')
+echo "${version_upstream}"
+exit 0
--- a/tools/getversion.sh
+++ b/tools/getversion.sh
@@ -1,13 +1,4 @@
#! /bin/bash
-
-thistag=$(git describe --exact-match --tags HEAD 2>/dev/null || true)
-
-if [ -z "${thistag}" ]; then
-# taghash=$(git rev-list --tags --max-count=1)
-# tag=$(git describe --tags "$taghash")
-next_version=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && cat NEXT_VERSION )
-current=$(git rev-parse --short HEAD)
-echo "${next_version}-pre+${current}"
-else
-echo "${thistag}"
-fi
+version_upstream=$(dpkg-parsechangelog -S Version | sed -e 's/+[^+]*$//')
+echo "${version_upstream}"
+exit 0
Bug#951236: osmnx fails the remote autopkg test (access blocked)
Dear Matthias, thanks for your report. I have just send an email to the Nominatim system administrator to see what we can do. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#950615: liblz-dev: uncomplete examples material
Package: liblz-dev
Version: 1.11-3
Severity: normal
Dear Maintainer,
please provide along the main.c example the files carg_parser.{h,c}
which are needed..
Cheers,
Jerome
-- System Information:
Debian Release: Buster*
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages liblz-dev depends on:
ii liblz1 1.11-3
liblz-dev recommends no packages.
liblz-dev suggests no packages.
-- no debconf information
Bug#949792: ITP: merkaartor -- map editor for OpenStreetMap.org
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: merkaartor Version : 0.18.4 Upstream Author : Merkaartor Developers * URL : https://github.com/openstreetmap/merkaartor * License : GPL-2+ Programming Lang: C++ Description : map editor for OpenStreetMap.org Merkaartor is a map editor for OpenStreetMap.org, the free editable map of the whole world. Features: * download from and upload to the OpenStreetMap server * open .osm and .gpx files * create and move trackpoints, ways, and areas * add tags, delete features * reverse, split and join ways * visualize some leisure/landuse areas and road types * displaying GPS information I plan to reintroduce and maintain Merkaartor on behalf of the Debian GIS Project team. This is motivated by the recent update of Merkaartor (which occured after its remove from Sid). Jerome
Bug#949183: Package gone but there are newer version
Hello Bas, thanks for your reply. On 20/01/2020 17:38, Bas Couwenberg wrote: > On 2020-01-20 13:56, Jerome BENOIT wrote: >> why does the low frequency of release of this software justify its >> removal from Debian ? > > Because at the time it was removed it was deemed dead upstream, there were no > releases for several years. > > There was no sign that upstream was working on a release with PROJ6 support > among others. > > I'm not willing to maintain packages that are dead upstream and who block > progress in the lower parts of the stack (like PROJ & GDAL). > > If your needs are not met by JOSM and you really want the merkaartor package > back in Debian you should consider becoming the maintainer of it. I am considering it indeed. I will have a closer look before. Did you orphan it ? or remove it ? Regards, Jerome > > Kind Regards, > > Bas -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
