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#1060318: Could be related to LLVM rather than PoCL: works with LLVM-15
I managed to get the test pass on PoCL v3, v4 and v5 using the same LLVM 15 (on a basis of silx development branch ... on a debian stable base) I suspect the regression is in the version of LLVM more than in PoCL or silx. I will investigate further. Cheers, -- Jérôme Kieffer
Bug#1060318: This is a regression: it used to pass with PoCL3.1
Platform Name Portable Computing Language Platform Vendor The pocl project Platform VersionOpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 15.0.6, SLEEF, DISTRO, POCL_DEBUG Platform ProfileFULL_PROFILE
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#1063047: Unable to run R CMD Rserve
Package: r-cran-rserve Version: 1.8-13-1 Severity: important Hello, Running the command "R CMD Rserve" doesn't work because of missing symlinks in the package. The error message shown is: /usr/lib/R/bin/Rcmd: 64: exec: Rserve: not found This problem was previously reported as #744759, but has been reintroduced (I think) when the package was migrated to debhelper. Migrating the DEB_DH_LINK_ARGS variable to a proper target should be sufficient to resolve this. Thanks! -- Jérôme
Bug#1062108: revelation segfault
Package: revelation Version: 0.5.5-1 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, When revelation run there is some "random" segfault. Maybe a dependency. If you know a way to improve verbosity. I will try to make advance tests with strace in a near future. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages revelation depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii gir1.2-gtk-3.0 3.24.40-2 ii python3 3.11.6-1 ii python3-cracklib 2.9.6-5.1+b1 ii python3-dbus 1.3.2-5+b1 ii python3-defusedxml 0.7.1-2 ii python3-gi 3.46.0-3 ii python3-pwquality1.4.5-3 ii python3-pycryptodome 3.11.0+dfsg1-4 revelation recommends no packages. revelation suggests no packages. -- no debconf information
Bug#939583: rsstail: Please consider updating to version 2.1
Package: rsstail Version: 1.8-1+b1 Followup-For: Bug #939583 X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, Please upgrade to 2.1 as it add capabilities. (-T options). As remember : https://github.com/folkertvanheusden/rsstail/ -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages rsstail depends on: ii libc6 2.37-13 ii libmrss0 0.19.2-7 rsstail recommends no packages. rsstail suggests no packages. -- no debconf information
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#1060295: boost1.83: not have sufficient long double support issue on ppc64le
Source: boost1.83 Severity: important X-Debbugs-Cc: calcu...@rezozer.net Dear Maintainer, it appears that the current graph-tool package (version 2.59+ds-1) fails to build on ppc64le arch because a `static assertion (fails)`. The message from the compiler is: /usr/include/boost/math/tools/promotion.hpp:267:27: error: static assertion failed: \ Sorry, but this platform does not have sufficient long double support for the special \ functions to be reliably implemented. Best, Jerome System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-27-powerpc64le (SMP w/4 CPU threads) 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
Bug#1056471: python-fabio: debdiff with patch from upstream recommendation
This looks good to be. Thanks for your contribution. Cheers, -- Jérôme Kieffer
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#1056471: Patch for 3.12
Hi, I am the upstream author of FabIO and indeed, there is a regression in the tests when run for the first time. This is linked to an un-flushed file. This can simply be corrected with this simple patch https://github.com/silx-kit/fabio/pull/550/files It is probably simpler to debian to just apply this patch to the source when packaging instead of making a new release... Cheers, -- Jérôme Kieffer tel +33 476 882 445
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#1053849: base-files: Allow .d for issue and issue.net
Package: base-files Version: 13 Severity: wishlist X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, Is there is a way to use the conf.d mecanism for files in base-files. In my case it's for issue and issue.net. For explanation i will imagine the directory issue.d . Maybe it's need an option to concatenate or erase default file. And maybe the same way to load 10- 20- etc. Why asking ? - to separate my own legal issue and the default one - no more dpkg question on update/upgrade. Please let me know if a more relevant place for that new feature exist. thx for your work -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages base-files depends on: ii gawk [awk] 1:5.2.1-2 ii mawk [awk] 1.3.4.20230808-1 base-files recommends no packages. base-files suggests no packages. -- no debconf information
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#1041443: issue at meson-python
Hi, Apparently this bug comes from the tool used to build the source package: "meson-python" ... it does not set properly timestamps in the source archive. https://github.com/mesonbuild/meson-python/issues/450 Cheers, Jerome
Bug#1039722: [Debian-pan-maintainers] Bug#1039722: pyfai is failing autopkg tests with python 3.11.4
Hi Matthias, I am the upstream developper of pyFAI. This version is >1 year old and I don't have the resources to backport bug-fixes. I develop on a daily basis on debian 12 and python 3.11 and the latest version is OK there. https://pypi.org/project/pyfai/#history How much work would it represent to package the the version from 2023 ? Cheers, Jerome On Wed, 28 Jun 2023 18:41:46 +0200 Matthias Klose wrote: > Package: src:pyfai > Version: 0.21.3+dfsg1-4 > Severity: serious > Tags: sid trixie > > pyfai is failing it's autopkg tests on amd64 with python 3.11.4: > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyfai/34908607/log.gz > > 442s == > 442s FAIL: test_count_csr > (pyFAI.test.test_histogram.TestHistogram2d.test_count_csr) > 442s Test that the pixel count and the total intensity is conserved > 442s -- > 442s Traceback (most recent call last): > 442s File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line > 340, in test_count_csr > 442s self.assertTrue(delta == 0, msg="check all pixels were counted") > 442s AssertionError: False is not true : check all pixels were counted > 442s > 442s == > 442s FAIL: test_numpy_vs_cython_vs_csr_2d > (pyFAI.test.test_histogram.TestHistogram2d.test_numpy_vs_cython_vs_csr_2d) > 442s Compare numpy histogram with cython simple implementation > 442s -- > 442s Traceback (most recent call last): > 442s File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line > 375, in test_numpy_vs_cython_vs_csr_2d > 442s self.assertTrue(delta_max <= self.err_max_cnt, "pixel count > difference > numpy/csr : max delta=%s" % delta_max) > 442s AssertionError: False is not true : pixel count difference numpy/csr : > max > delta=8.0 > 442s > 442s -- > 442s Ran 376 tests in 272.476s > 442s > 442s FAILED (failures=2, skipped=9) > 442s 92 > 442s 61 > 442s 33 > 442s autopkgtest [15:28:03]: test command1: ---] > 443s command1 FAIL non-zero exit status 1 > 443s autopkgtest [15:28:04]: test command1: - - - - - - - - - - results - - > - - > - - - - - - > 443s autopkgtest [15:28:04]: summary > 443s command1 FAIL non-zero exit status 1 > > -- > Debian-pan-maintainers mailing list > debian-pan-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers -- Jérôme Kieffer tel +33 476 882 445
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#1033843: xsettings-kde: Plasma doesn't depend on xsettings-kde, which do not depend on xsettingsd
Package: xsettings-kde Version: 0.9-2+b2 Severity: normal X-Debbugs-Cc: an.in...@free.fr Dear Maintainer, The plasma desktop doesn't depend on xsettings-kde. And xsettings-kde doesn't depend on the xsettingsd package. Since 5.27, xsettingsd is required for the GTK applications to get the KDE HiDPI scaling configuration. So when upgrading from Bullseye to Bookworm on a system with a HiDPI screen all the GTK application can be off by default. Making the Plasma desktop depend on xsettings-kde, and xsettings-kde depend on xsettingsd, would fix this problem and give a better "out of the box" experience. If not depend, at least recommend would help. Thanks -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:us Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xsettings-kde depends on: ii libc6 2.36-8 ii libx11-6 2:1.8.4-2 xsettings-kde recommends no packages. xsettings-kde suggests no packages. -- no debconf information
Bug#1004130: debian logo displayed partly off screen
I have another laptop that works perfectly with the same external screen. Also Bookworm, both up to date, same configurations for Plymouth, initramfs and grub. I checked the initramfs content and couldn't detect a difference related to the display. The laptop with the issue is a Thinkpad X1 gen6, with a 2560x1440 display. The laptop that works fine is a Dell Latitude 7490, 1920x1080 screen. A difference in behavior is that the Latitude shows the same thing on both screens: I can see the LUKS entry field and my input on the external screen too. On the X1 however, the external screen has a fixed image with no input field. The laptop screen is truncated so I can't see the input field, but I assume it's present (I can enter the LUKS password just fine). So it seems Plymouth displays different things on both screens. On Bullseye it didn't behave this way: both screen showed the same thing on the X1 too, with no truncation on the laptop screen. Suggestions on how to troubleshoot this welcomed ;)
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#1004130: debian logo displayed partly off screen
Actually, my laptop screen resolution configuration should not be relevant: it's a KDE Plasma level setting, not available in an early boot environment (root and home are even on an encrypted volume, not yet mounted). I tried looking into /boot and the initramfs and can't find any sign that the KDE screen setting is somewhat persisted there (but could have missed it). Still: 1) Laptop only: the Plymouth display is fine; 2) External screen connected: the external screen is OK, the Plymouth display on the laptop is truncated. The grub screen resolution configuration doesn't seem to have an effect on this. Thanks.
Bug#1004130: debian logo displayed partly off screen
Hi, I have this issue since upgrading from Bullseye to Bookworm. It was working fine with Bullseye, but now with Bookworm my laptop Plymouth login screen only show up the top left part of the theme image, with the LUKS password entry field not visible (but functional). In my case, it's related to multi-screens support. My laptop has a native 2560x1440 screen, and is connected to an external display also 2560x1440. When I use the laptop alone (no second screen), I use its native resolution. Then on boot Plymouth works fine. When the laptop is connected to the external screen, in order to deal with the different sizes and dpi (problematic on X11, which I use with KDE), I set the laptop screen to 1920x1080. Good enough, and there less pixel density difference. In this case, on boot with Plymouth: 1) The external screen show a proper theme image, with no input field; 2) The laptop screen only show the top-left part of the theme as described. So it seems that the 1920x1080 resolution is applied already when Plymouth starts, and Plymouth is not aware of it and display a 2560x1440 native content, which doesn't fit. So the issue for me looks to be a mismanagement of the screen resolution change. Either this should be done after Plymouth is done, or Plymouth should be aware of it and use the actual resolution and not the native one. For other people having this issue (Marc and Paul): do you also happen to change the screen resolution on the screen where Plymouth has a partial display? Thanks -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:us Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plymouth depends on: ii init-system-helpers 1.65.2 ii initramfs-tools 0.142 ii libc6 2.36-8 ii libdrm2 2.4.114-1 ii libplymouth5 22.02.122-3 ii lsb-base 11.6 ii systemd 252.6-1 ii sysvinit-utils [lsb-base] 3.06-2 ii udev 252.6-1 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 12.0.5 ii plymouth-themes 22.02.122-3 -- Configuration Files: /etc/plymouth/plymouthd.conf changed [not included, just setting the "Breeze" theme] -- no debconf information
Bug#1013594: insubstantial: FTBFS: Caused by: : java.lang.VerifyError: Expecting a stackmap frame at branch target 33
Control: user debian-rele...@lists.debian.org Control: usertag -1 + bsp-2023-02-ca-montreal Hello, I've worked on this today: I can confirm the FTBFS issue occurs consistently, but I wasn't able to find a solution. Upstream isn't much help here: 7.3 is the latest release and was tagged in 2014 (9 years ago) and the project is now archived/read-only on GitHub. If we removed this from Debian, notable packages affected would be include triplea and scilab. Thanks, -- Jérôme
Bug#1018811: [Debian-pan-maintainers] Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)
On Sun, 22 Jan 2023 16:56:46 +0100 Andreas Tille wrote: > Thanks for commenting on this. Would you be able to push the needed changes > to Salsa (and preferably upload)? Hi Andreas, I know a bit about debian packaging and also about the gitlab-CI, but I never used the later for the former. I just re-acetivated my salsa account and forked the project. Now what should I do ? * I guess replace the content of the master branch with the newest release * should I update the content of any other branch ? * then perform a merge-request on the scient-team Maybe (probably) there is a documentation existing, but as usual a quick googling did not provide the adequate answer. Cheers, Jerome
Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)
Hi Andreas,
Thanks for taking care of the packaging of pyFAI. I had a look at what
the logs and apparently you are packaging the version 0.21.3 ... while
I released the verison 2023.1 last week:
https://pypi.org/project/pyfai/
I just checked on the i386-debian sid chroot I have and none of the 3 test you
found were failing (they are skipped)... but there is another one failing:
==
FAIL: test (pyFAI.test.test_error_model.TestErrorModel.test)
--
Traceback (most recent call last):
File
"/tmp/pyFAI/build/lib/python3/dist-packages/pyFAI/test/test_error_model.py",
line 121, in test
self.assertGreaterEqual(cormap(ref.__getattribute__(array),
res.__getattribute__(array)), epsilon, f"array {array} matches for {k} vs
numpy")
AssertionError: 0 not greater than or equal to 0.002 : array
sum_normalization matches for ('poisson', 'opencl', 'integrate') vs numpy
I double checked and this failure is relative to the PoCL
implemantation used on my i386-chroot. If OpenCL is disabled for the
tests in debian, this test should pass OK.
Cheers,
Jerome
On Fri, 20 Jan 2023 22:20:57 +0100
Andreas Tille wrote:
> Hi Jerome,
>
> I've applied the suggested patch to relax the tests on 32 bit architectures.
> Unfortunately there are new test suite errors as you can see in Salsa CI[1]:
>
>
> ==
> FAIL: test_count_csr
> (pyFAI.test.test_histogram.TestHistogram2d.test_count_csr)
> Test that the pixel count and the total intensity is conserved
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
> line 339, in test_count_csr
> self.assertTrue(delta == 0, msg="check all pixels were counted")
> AssertionError: False is not true : check all pixels were counted
> ==
> FAIL: test_numpy_vs_cython_vs_csr_2d
> (pyFAI.test.test_histogram.TestHistogram2d.test_numpy_vs_cython_vs_csr_2d)
> Compare numpy histogram with cython simple implementation
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
> line 373, in test_numpy_vs_cython_vs_csr_2d
> self.assertTrue(delta_max <= self.err_max_cnt, "pixel count difference
> numpy/csr : max delta=%s" % delta_max)
> AssertionError: False is not true : pixel count difference numpy/csr : max
> delta=8.0
> ==
> FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR.test_2d_nosplit)
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_csr.py",
> line 195, in test_2d_nosplit
> self.assertLess(error.mean(), 1e-3, "img are almost the same")
> AssertionError: 244.15215998872887 not less than 0.001 : img are almost the
> same
> ==
>
> Any idea how to fix these?
>
> Kind regards
>Andreas.
>
>
> [1] https://salsa.debian.org/science-team/pyfai/-/jobs/3826387
>
> --
> http://fam-tille.de
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#1022440: [Debian-pan-maintainers] Bug#1022440: python-fabio: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Dear Lucas,
I suspect the issue is once again the "numpy.distutils" which enforces
"setuptools<60"...
I have started to port FabIO to the meson-python builder, in a similar
way to what is done for scipy-1.9 (still not packaged for debian).
It is now close to production ready and can release a version as soon
the packaging tools are available in debian.
Best regards,
Jérôme Kieffer
On Sun, 23 Oct 2022 15:37:18 +0200
Lucas Nussbaum wrote:
> Source: python-fabio
> Version: 0.14.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > fakeroot debian/rules clean
> > dh clean --buildsystem=pybuild
> >dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:240: python3.10 setup.py clean
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
> > Distutils was imported before Setuptools, but importing Setuptools also
> > replaces the `distutils` module in `sys.modules`. This may lead to
> > undesirable behaviors or errors. To avoid these issues, avoid using
> > distutils directly, ensure that setuptools is installed in the traditional
> > way (e.g. not an editable install), and/or make sure that setuptools is
> > always imported before distutils.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
> > Setuptools is replacing distutils.
> > warnings.warn("Setuptools is replacing distutils.")
> > INFO: Disabling color, you really want to install colorlog.
> > INFO:pythran:Disabling color, you really want to install colorlog.
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Use setuptools.setup
> > Traceback (most recent call last):
> > File "/<>/setup.py", line 1118, in
> > setup_package()
> > File "/<>/setup.py", line 1114, in setup_package
> > setup(**setup_kwargs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 87, in
> > setup
> > return distutils.core.setup(**attrs)
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line
> > 172, in setup
> > ok = dist.parse_command_line()
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
> > 474, in parse_command_line
> > args = self._parse_command_opts(parser, args)
> > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1107, in
> > _parse_command_opts
> > nargs = _Distribution._parse_command_opts(self, parser, args)
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
> > 540, in _parse_command_opts
> > raise DistutilsClassError(
> > distutils.errors.DistutilsClassError: command class > '__main__.CleanCommand'> must subclass Command
> > E: pybuild pybuild:379: clean: plugin distutils failed with: exit code=1:
> > python3.10 setup.py clean
> > dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned
> > exit code 13
> > make: *** [debian/rules:7: clean] Error 25
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/10/23/python-fabio_0.14.0+dfsg-1_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221023;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221023=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
> --
> Debian-pan-maintainers mailing list
> debian-pan-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers
--
Jérôme Kieffer
tel +33 476 882 445
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#1021605: persepolis: Systemd dependencies
Package: persepolis Version: 3.0.1-1.1 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, It's look like the package need systemd … (throught recommends) Can you please fix it ? A default installation should not rely on a specific software that can break all others software. thx -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages persepolis depends on: ii aria2 1.36.0-1 ii libnotify-bin 0.8.1-1 ii libqt5svg55.15.4-2 ii python3 3.10.6-1 ii python3-pyqt5 5.15.7+dfsg-1 ii python3-requests 2.27.1+dfsg-1 Versions of packages persepolis recommends: pn pulseaudio ii python3-psutil 5.9.2-1 ii python3-setproctitle 1.3.1-1 ii sound-theme-freedesktop 0.8-2 persepolis suggests no packages.
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#1020639: (no subject)
merge 1020639 1021076 severity 1020639 grave Raising severity has PDF Arranger is now unusable
Bug#1020073: [Debian-pan-maintainers] Bug#1020073: pyfai: FTBFS: distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w
Hi Lucas,
All my packages (and probably many more) are marked for removal because of this
bug.
I believe this bugs comes from a specificity of Debian which does not
install python3-pip together with python3. If python3-pip is now needed by
pybuild it should be a build dependency.
Cheers,
Jerome
On Sun, 18 Sep 2022 08:31:39 +0200
Lucas Nussbaum wrote:
> Source: pyfai
> Version: 0.21.3+dfsg1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > fakeroot debian/rules clean
> > dh clean --buildsystem=pybuild
> >dh_auto_clean -O--buildsystem=pybuild
> > install -d
> > /<>/pyfai-0.21.3\+dfsg1/debian/.debhelper/generated/_source/home
> > pybuild --clean -i python{version} -p 3.10
> > I: pybuild base:240: python3.10 setup.py clean
> > /<>/setup.py:43: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
> > Distutils was imported before Setuptools, but importing Setuptools also
> > replaces the `distutils` module in `sys.modules`. This may lead to
> > undesirable behaviors or errors. To avoid these issues, avoid using
> > distutils directly, ensure that setuptools is installed in the traditional
> > way (e.g. not an editable install), and/or make sure that setuptools is
> > always imported before distutils.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
> > Setuptools is replacing distutils.
> > warnings.warn("Setuptools is replacing distutils.")
> > INFO: Disabling color, you really want to install colorlog.
> > INFO:pythran:Disabling color, you really want to install colorlog.
> > INFO:pyFAI.setup:Use setuptools with cython
> > INFO:pyFAI.setup:Use setuptools.setup
> > /usr/lib/python3/dist-packages/setuptools/installer.py:27:
> > SetuptoolsDeprecationWarning: setuptools.installer is deprecated.
> > Requirements should be satisfied by a PEP 517 installer.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/setuptools/installer.py:34: UserWarning:
> > Unbuilt egg for pyFAI [unknown version] (/<>)
> > pkg_resources.get_distribution('wheel')
> > WARNING: The wheel package is not available.
> > /usr/lib/python3/dist-packages/setuptools/installer.py:60: UserWarning:
> > Unbuilt egg for pyFAI [unknown version] (/<>)
> > environment = pkg_resources.Environment()
> > /usr/bin/python3.10: No module named pip
> > Traceback (most recent call last):
> > File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82,
> > in fetch_build_egg
> > subprocess.check_call(cmd)
> > File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
> > raise CalledProcessError(retcode, cmd)
> > subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m',
> > 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w',
> > '/tmp/tmpymrbi1ta', '--quiet', 'setuptools<60.0.0']' returned non-zero exit
> > status 1.
> >
> > The above exception was the direct cause of the following exception:
> >
> > Traceback (most recent call last):
> > File "/<>/setup.py", line 1137, in
> > setup_package()
> > File "/<>/setup.py", line 1133, in setup_package
> > setup(**setup_kwargs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 86, in
> > setup
> > _install_setup_requires(attrs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 80, in
> > _install_setup_requires
> > dist.fetch_build_eggs(dist.setup_requires)
> > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 875, in
> > fetch_build_eggs
> > resolved_dists = pkg_resources.working_set.resolve(
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 789, in resolve
> > dist = best[req.key] = env.best_match(
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 1075, in best_match
> > return self.obtain(req, installer)
> > File "/usr/lib/python
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#1020639: (no subject)
severity 1020639 important Lowering serverity because pdfarranger as NOT YET been removed from testing
Bug#1018820: [Debian-pan-maintainers] Bug#1018820: fabio-viewer: crash during file opening
Dear Martin, Thanks for reporting the bug. I have opened another at github: https://github.com/silx-kit/fabio/issues/491 It should be fairly easy to fix. Best regards, Jerome On Wed, 31 Aug 2022 11:57:45 +0200 Martin Lutz via Debian-pan-maintainers wrote: > Package: fabio-viewer > Version: 0.14.0+dfsg-1 > Severity: normal > > Dear Maintainer, > > when opening a file with the script fabio_viewer a crash occurs. (Tried on cbf > and Bruker sfrm images). The progress bar expects an integer value but the > routine returns a float value. > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/fabio/app/viewer.py", line 192, in > open_data_series > self.progressBar.setValue(float(iid + 1) / (total) * 100.) > TypeError: setValue(self, int): argument 1 has unexpected type 'float' > Aborted > > Reading the files interactively in python and display with matplotlib works as > expected. > > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages fabio-viewer depends on: > ii python33.10.6-1 > ii python3-fabio 0.14.0+dfsg-1+b1 > ii python3-numpy 1:1.21.5-1+b1 > > fabio-viewer recommends no packages. > > fabio-viewer suggests no packages. > > -- no debconf information > > -- > Debian-pan-maintainers mailing list > debian-pan-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers
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#1018811: [Debian-pan-maintainers] Bug#1018811: pyfai: autopkgtest regression on armel and i386
Hi Graham, Thanks for making me aware ... this is probably related to this PR which was just accepted upstream: https://github.com/silx-kit/pyFAI/pull/1729 Apparently, Michael Hudson-Doyle is from Ubuntu and the bugs addressed are exactly those... Unfortunately, there is no release planed in the foreseeable future ... Cheers, Jerome (upstream author of pyFAI) On Wed, 31 Aug 2022 08:35:02 +0200 Graham Inggs wrote: > Source: pyfai > Version: 0.21.3+dfsg1-1 > Severity: important > User: debian...@lists.debian.org > Usertags: regression > > Hi Maintainer > > The autopkgtests of pyfai have regressed on armel and i386 [1][2], > where they passed previously (see results of e.g. 0.20.0+dfsg1-3). I > have copied what I hope is the relevant part of the log below. > > These test failures are known upstream, as can be seen in the > following code snippets. > > pyFAI/test/test_histogram.py: > @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor") > def test_count_csr(self): > > pyFAI/test/test_histogram.py: > @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor") > def test_numpy_vs_cython_vs_csr_2d(self): > > pyFAI/test/test_csr.py: > @unittest.skipIf(UtilsTest.low_mem, "test unreliable on 32bits processor") > def test_2d_nosplit(self): > > This was noticed in Ubuntu, when the upload of glibc 2.36 caused the > same tests to start failing on armhf. > > Regards > Graham > > > [1] https://ci.debian.net/packages/p/pyfai/unstable/armel/ > [2] https://ci.debian.net/packages/p/pyfai/unstable/i386/ > > > == > FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d) > Test that the pixel count and the total intensity is conserved > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 339, in test_count_csr > self.assertTrue(delta == 0, msg="check all pixels were counted") > AssertionError: False is not true : check all pixels were counted > > == > FAIL: test_numpy_vs_cython_vs_csr_2d > (pyFAI.test.test_histogram.TestHistogram2d) > Compare numpy histogram with cython simple implementation > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 373, in test_numpy_vs_cython_vs_csr_2d > self.assertTrue(delta_max <= self.err_max_cnt, "pixel count > difference numpy/csr : max delta=%s" % delta_max) > AssertionError: False is not true : pixel count difference numpy/csr : > max delta=8.0 > > == > FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR) > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/pyFAI/test/test_csr.py", line > 195, in test_2d_nosplit > self.assertLess(error.mean(), 1e-3, "img are almost the same") > AssertionError: 244.15215998872887 not less than 0.001 : img are almost the > same > > -- > Ran 376 tests in 285.382s > > FAILED (failures=3, skipped=10) > > -- > Debian-pan-maintainers mailing list > debian-pan-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers -- Jérôme Kieffer tel +33 476 882 445
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#1011752: [Debian-pan-maintainers] Bug#1011752: freesas: please make the build reproducible
Hi Chris, This patch looks good to me. Thanks for the fix -- Jérôme Kieffer upstream author of FreeSAS
Bug#1011081: Please upload 0.2.2 to bullseye-backports
Package: onionbalance Version: 0.2.0-5 Release 0.2.2 of onionbalance provides support for multiple onion sites, as such it would be very useful to have in bullseye. I've checked that its dependencies are available in either bullseye or bullseye-backports (tor). Thanks.
Bug#1010989: ITP: nippy-clojure
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : nippy-clojure Version : 3.1.1 Upstream author : Peter Taoussanis URL : https://github.com/ptaoussanis/nippy License : EPL-1.0 Programming Lang : Clojure Description : High-performance serialization library for Clojure the fastest serialization library for Clojure Clojure's rich data types are awesome. And its reader allows you to take your data just about anywhere. But the reader can be painfully slow when you've got a lot of data to crunch (like when you're serializing to a database). Nippy is an attempt to provide a reliable, high-performance drop-in alternative to the reader. Used by the Carmine Redis client, the Faraday DynamoDB client, PigPen, Onyx and others. Thanks, -- Jerome
Bug#1010987: ITP: encore-clojure
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : encore-clojure Version : 3.22.0 Upstream author : Peter Taoussanis URL : https://github.com/ptaoussanis/encore License : EPL-1.0 Programming Lang : Clojure Description : Core utils library for Clojure/Script Extended core library for Clojure/Script that emphasizes: * Cross platform API compatibility * Flexibility * Performance * Backwards compatibility Thanks, -- Jerome
Bug#1010986: ITP: encore-clojure
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : truss-clojure Version : 1.6.0 Upstream author : Peter Taoussanis URL : https://github.com/ptaoussanis/encore License : EPL-1.0 Programming Lang : Clojure Description : Core utils library for Clojure/Script Extended core library for Clojure/Script that emphasizes: * Cross platform API compatibility * Flexibility * Performance * Backwards compatibility Thanks, -- Jerome
Bug#1010979: ITP: truss-clojure
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : truss-clojure Version : 1.6.0 Upstream author : Peter Taoussanis URL : https://github.com/ptaoussanis/truss License : EPL-1.0 Programming Lang : Clojure Description : Assertions API for Clojure/Script Truss is a micro library for Clojure/Script that provides fast, flexible runtime condition assertions with great error messages. It can be used to get many of the most important benefits of static/gradual typing without the usual rigidity or onboarding costs. Thanks, -- Jerome
Bug#1010939: ITP: libmurphy-clojure
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : libmurphy-clojure Version : 0.5.2 Upstream author : Rob Browning URL : https://gitlab.com/clj-murphy/murphy License : LGPL-2.1+ or EPL-1.0 Programming Lang : Clojure Description : Clojure library for better handling of bad situations Murphy is a library that provides several facilities to improve error handling in Clojure code. Thanks, -- Jerome
Bug#1008465: [Debian-pan-maintainers] Bug#1008465: python-fabio: FTBFS: Could not import extension nbsphinx (exception: No module named 'ipython_genutils')
Hi Lucas,
Thanks for the report. This looks like a bug I recently fixed in pyFAI ... I'll
have a look tomorrow. Probably just a missing dependency like in
https://github.com/silx-kit/pyFAI/commit/7bcb6dd7419b48580d97cd91a28d05f86b301f1c
Cheers,
Jerome
On Sat, 26 Mar 2022 22:57:37 +0100
Lucas Nussbaum wrote:
> Source: python-fabio
> Version: 0.13.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_build
> > I: pybuild base:237: /usr/bin/python3.10 setup.py build
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > I: pybuild base:237: /usr/bin/python3 setup.py build
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > dh_auto_build -- -s custom --build-args="PYTHONPATH={build_dir} xvfb-run -a
> > --server-args=\"-screen 0 1024x768x24\" {interpreter} setup.py build_man"
> > I: pybuild base:237:
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build xvfb-run -a
> > --server-args="-screen 0 1024x768x24" python3.10 setup.py build_man
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > I: pybuild base:237:
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build xvfb-run -a
> > --server-args="-screen 0 1024x768x24" python3.9 setup.py build_man
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > dh_auto_build -- -s custom --build-args="cd doc && PYTHONPATH={build_dir}
> > http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source
> > build/html"
> > I: pybuild base:237: cd doc &&
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> >
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom failed with: exit code=2: cd
> > doc && PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > I: pybuild base:237: cd doc &&
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build
> > http_proxy='127.0.0.1:9' python3.9 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> >
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom fa
Bug#1008119: [Debian-pan-maintainers] Bug#1008119: src:pyfai: fails to migrate to testing for too long: autopkgtest regression
Dear Paul, I am the upstream author of pyFAI and the release 0.21.1 is a bugfix for the regressions spotted by the debian CI on a couple of 32-bit computer architectures (thanks to debian for that). Thus I don't understand why the migration from unstable to testing is blocked, especially that the tests passes on all architectures now. Best regards, Jerome Nota, a version 0.21.2 was released with some documentation improvements. On Tue, 22 Mar 2022 20:34:35 +0100 Paul Gevers wrote: > Source: pyfai > Version: 0.20.0+dfsg1-4.1 > Severity: serious > Control: close -1 0.21.1+dfsg1-1 > Tags: sid bookworm > User: release.debian@packages.debian.org > Usertags: out-of-sync > Control: block -1 by 1004509 > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 60 days as having a Release Critical bug in > testing [1]. Your package src:pyfai has been trying to migrate for 61 > days [2]. Hence, I am filing this bug. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and bookworm, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > > Paul > > [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html > [2] https://qa.debian.org/excuses.php?package=pyfai > -- Jérôme Kieffer tel +33 476 882 445
Bug#1006637: greenbone-security-assistant: No more sysvinit service file
Package: greenbone-security-assistant Version: 21.4.3-1 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, I just see the sysvinit script have been remove. So service can not start on systemd less system. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages greenbone-security-assistant depends on: ii greenbone-security-assistant-common 21.4.3-1 ii gvmd 21.4.4-1 ii libc62.33-7 ii libgcrypt20 1.9.4-5 ii libglib2.0-0 2.70.4-1 ii libgnutls30 3.7.3-4+b1 ii libgvm21 21.4.3-1 ii libmicrohttpd12 0.9.75-3 ii libxml2 2.9.12+dfsg-6 ii lsb-base 11.1.0 greenbone-security-assistant recommends no packages. greenbone-security-assistant suggests no packages. -- no debconf information
Bug#1005995: espeakup: not systemd support
Package: espeakup Version: 1:0.90-6 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Restarting Speakup/espeak connector: espeakup failed! invoke-rc.d: initscript espeakup, action "restart" failed. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages espeakup depends on: ii libasound2 1.2.6.1-1 ii libc6 2.33-5 ii libespeak-ng1 1.50+dfsg-10 ii lsb-base 11.1.0 espeakup recommends no packages. espeakup suggests no packages. -- no debconf information
Bug#1003567: Please make a separate package for mistune 2.x
Le 2022-02-04 à 11 h 24, Nilesh Patra a écrit : On 2/4/22 9:33 PM, Julian Gilbey wrote: _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. This is true, though there are only 7 reverse dependencies currently in testing. Yeah, in total the reverse-deps are 8 and there is one different reverse-build-dep (pasted at end of this mail) But the problem is if these fall through the cracks, and close to the release we notice some package is not looking nice. Also, if you suppose that the upstreams are very slow, and we get to the new debian release with these things still embedded, it'd be a real mess to upload fixes to stable, right... I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. That would be a reasonable approach, but how long will it take for the dust to settle? With this major change, and no guidance from upstream on how to migrate, and at least a number of upstream authors happy to rely on setup.py having "mistune <1.0.0" in the install_requires field, it might be several months or longer before things are fixed upstream. I think we could do this transition even a month or two before the soft freeze starts, which is roughly an year from now (considering general trend timings of starting in feb in release year). Situation might improve by then, I suppose. If it does not, we could still go ahead with the older python3-mistune in the archive, I do not see a huge problem there, except for maybe a few mistune uploads to stable if desired. And what do we do when some packages have converted and some haven't? In such a case, we atleast will have a few examples to see how to go about doing the API changes the right way. We could patch out at our end and send the changes upstream for review provided we are stuck in an unfortunate situation. FWIW, there's a recent patch and PR for the lektor upstream which add mistune 2.x support, so for this particular project I don't think a separate package is necessary. -- Jerome
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#1004509: [Debian-pan-maintainers] Bug#1004509: pyfai: autopkgtest regression on armhf: images have different dimensions
Dear Paul, Dear Fred. Those 3-broken tests are exactly the same as the one reported by Fred Picca on i386 with Python3.10. I tried to reproduce them manually on a Zen computer with an i386 debian system installed on it, without success. I will try to reproduce the bug on an ARM system: I own a Tinkerboard to perform this test. What puzzles me is that it shows of only with Py3.10 The 2GB limit per process can be hit with even moderate size problems in pyFAI and I wonder if it makes sense to package pyFAI for 32-bits systems. That said, I could easily release a 0.21.1 with those 3 tests disables on 32-bits systems. Cheers, Jerome developer of pyFAI On Sat, 29 Jan 2022 19:21:38 +0100 Paul Gevers wrote: > Source: pyfai > Version: 0.21.0+dfsg1-1 > X-Debbugs-CC: debian...@lists.debian.org > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > With a recent upload of pyfai the autopkgtest of pyfai fails in testing > when that autopkgtest is run with the binary packages of pyfai from > unstable. It passes when run with only packages from testing. In tabular > form: > > passfail > pyfai from testing0.21.0+dfsg1-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=pyfai > > https://ci.debian.net/data/autopkgtest/testing/armhf/p/pyfai/18797397/log.gz > > == > FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d) > Test that the pixel count and the total intensity is conserved > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 337, in test_count_csr > self.assertTrue(delta == 0, msg="check all pixels were counted") > AssertionError: False is not true : check all pixels were counted > > == > FAIL: test_numpy_vs_cython_vs_csr_2d > (pyFAI.test.test_histogram.TestHistogram2d) > Compare numpy histogram with cython simple implementation > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 370, in test_numpy_vs_cython_vs_csr_2d > self.assertTrue(delta_max <= self.err_max_cnt, "pixel count > difference numpy/csr : max delta=%s" % delta_max) > AssertionError: False is not true : pixel count difference numpy/csr : > max delta=8.0 > > == > FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR) > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_csr.py", line > 193, in test_2d_nosplit > self.assertLess(error.mean(), 1e-3, "img are almost the same") > AssertionError: 244.15215998872887 not less than 0.001 : img are almost > the same > > -- > Ran 375 tests in 138.562s > > FAILED (failures=3, skipped=9) > 60 > 44 > 23 > autopkgtest [08:17:51]: test command1 >
Bug#1004571: ITP: python-pytest-click
Package: wnpp Severity: wishlist Owner: Jerome Charaoui Package name : python-pytest-click Version : 1.0.2 Upstream author : Dmitry Dygalo URL : https://github.com/Stranger6667/pytest-click License : MIT Programming Lang : Python Description : Click plugin for py.test Click is a Python package for creating beautiful command line interfaces in a composable way with as little code as necessary. pytest-click provides fixtures for easy integration with the py.test framework. Thanks, -- Jerome OpenPGP_signature Description: OpenPGP digital signature
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#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving
This is fixed in pdfarranger 1.8.2 by https://github.com/pdfarranger/pdfarranger/commit/de8acb310e23cacd8409bd895f9cfbd64af9bf23
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#996575: qtconnectivity5-examples: Unknown module(s) in QT: nfc
Package: qtconnectivity5-examples Version: 5.15.2-2 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, After a copy of the content of /usr/lib/x86_64-linux-gnu/qt5/examples/nfc in my home and open the .pro 4 error (one by subproject) are display : :-1: erreur : Project ERROR: Unknown module(s) in QT: nfc Maybe i miss something but should examples run without issue ? Also exemple are not show in qtcreator. thx for your work. J. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages qtconnectivity5-examples depends on: ii dpkg 1.20.9 ii libc6 2.32-4 ii libqt5bluetooth5 5.15.2-2 ii libqt5core5a 5.15.2+dfsg-12 ii libqt5gui55.15.2+dfsg-12 ii libqt5nfc55.15.2-2 ii libqt5qml55.15.2+dfsg-8 ii libqt5quick5 5.15.2+dfsg-8 ii libqt5widgets55.15.2+dfsg-12 ii libstdc++611.2.0-9 qtconnectivity5-examples recommends no packages. qtconnectivity5-examples suggests no packages.
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#679905: RFP: cctbx -- Computational Crystallography Toolbox
Hi Recently (last summer), Fred Picca told me he advanced quite a bit on this package and finally got something working. Using non standart packaging system is really a pain ... Cheers, Jérôme On Wed, 6 Oct 2021 14:28:06 +0200 Baptiste Carvello wrote: > Hi, > > thanks for caring about Debian packaging efforts! This one is an old > one, it must have been 2012 or 2013, and salsa was called alioth :-) > > What I remember was a rather inflexible packaging system, that forced us > to duplicate existing code. And an effort that, well, slowly lost steam. > Then I lost track of it due to real life commitments (my first child was > born 2014). > > I also gratefully remember that Luc Bourhis was very helpful from the > upstream side. I wouldn't want to bother him again, though, until we > have something concrete to put on the table. > > Best regards, > Baptiste > > Le 06/10/2021 à 10:13, Andreas Tille a écrit : > > Hi, > > > > I've got a hint about cctbx and realised that there is an RFP (degraded > > from ITP) as well as a salsa repository[1]. I took the freedom to > > inject the latest upstream source and updated *parts* of the packaging > > to recent standards. I have no idea whether this might give some new > > inspiration for those who want to catch up with this package, which is > > interesting for several teams (in CC). So I simply make some noise for > > anybody who might want to continue from here. > > > > Kind regards > > > > Andreas. > > > > [1] https://salsa.debian.org/science-team/cctbx > > > >
