Bug#1071554: lintian-brush: removal of autotools-dev debhelper causes FTBFS
Package: lintian-brush Version: 0.152 Severity: important Tags: ftbfs Dear maintainer, autotools-dev debhelper has been deprecated, so lintian-brush just removes it [1], which causes packages to FTBFS [2]. It should be replaced by dh_update_autotools_config instead of simply being dropped. Regards Aurelien [1] https://salsa.debian.org/debian/tla/-/commit/6cea8b94c34768268a7a03538d11e1ecc508eb46 [2] https://bugs.debian.org/1071544
Bug#1071544: tla: FTBFS on arm64/ppc64el/riscv64: config.guess: unable to guess system type
Source: tla Version: 1.3.5+dfsg1-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, The tla packages fails to build on a few "recent" architectures due to outdated config.guess/sub: | cd debian/build && \ | CFLAGS='-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wall' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS='-Wl,-z,relro' \ | AUTOCONF_CROSS='--build aarch64-linux-gnu' AUTOCONF_CFLAGS='-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wall' \ | AUTOCONF_CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' AUTOCONF_LDFLAGS='-Wl,-z,relro' \ | ../../src/configure --prefix=/usr --with cc gcc | /<>/src/build-tools/gnu/config.guess: unable to guess system type | | This script, last modified 2006-06-06, has failed to recognize | the operating system you are using. It is advised that you | download the most up to date version of the config scripts from | | http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess | and | http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub | | If the version you run (/<>/src/build-tools/gnu/config.guess) is already up to date, please | send the following data and any information you think might be | pertinent to in order to provide the needed | information to handle your system. | | config.guess timestamp = 2006-06-06 | | uname -m = aarch64 | uname -r = 6.1.0-21-arm64 | uname -s = Linux | uname -v = #1 SMP Debian 6.1.90-1 (2024-05-03) | | /usr/bin/uname -p = unknown | /bin/uname -X = | | hostinfo = | /bin/universe = | /usr/bin/arch -k = | /bin/arch = aarch64 | /usr/bin/oslevel = | /usr/convex/getsysinfo = | | UNAME_MACHINE = aarch64 | UNAME_RELEASE = 6.1.0-21-arm64 | UNAME_SYSTEM = Linux | UNAME_VERSION = #1 SMP Debian 6.1.90-1 (2024-05-03) | make: *** [debian/rules:26: configure-stamp] Error 1 | dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 The full build logs are available here: https://buildd.debian.org/status/fetch.php?pkg=tla=arm64=1.3.5%2Bdfsg1-4=1715943782=0 https://buildd.debian.org/status/fetch.php?pkg=tla=ppc64el=1.3.5%2Bdfsg1-4=1715943032=0 https://buildd.debian.org/status/fetch.php?pkg=tla=riscv64=1.3.5%2Bdfsg1-4=1715953860=0 It appears that code for updating config.guess/sub from autotools-dev has been dropped, while it is still necessary. Regards Aurelien [1] https://salsa.debian.org/debian/tla/-/commit/6cea8b94c34768268a7a03538d11e1ecc508eb46
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:40, Luca Boccassi wrote: > On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > > > On 2024-05-20 10:22, Luca Boccassi wrote: > > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > > wrote: > > > > > > > > Hi, > > > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > > more involved checks about what PID 1 is? It could then make sure > > > > > > to only call > > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > > telinit, and a specific telinit, into a ton of different things > > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > > they are not that different. Both try to talk to their respective > > > > > pid1 daemons first using their respective communication socket. > > > > > > > > > > But then, if that doesn't work, they diverge: > > > > > - sysvinit's telinit just gives up > > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > > being in a chroot, before doing any of that. > > > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > > > glibc's > > > > > postinst (and other places) can become simpler again. > > > > > > > > via irc, jochen also pointed out: telinit could be the component which > > > > checks > > > > what PID 1 actually is and only do its thing after it confirmed that it > > > > is > > > > indeed an init system like systemd that is providing PID 1? > > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > Going from the other side, maybe libc6.postinst could use something > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > out the situation a bit better? > > > > Nope. > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported In sbuild using unshare chroot running in a VM: | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt | Failed to read $container of PID 1, ignoring: Permission denied | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy | Found container virtualization none. | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) | UML virtualization not found in /proc/cpuinfo. | Virtualization XEN not found, /proc/xen does not exist | Virtualization found, CPUID=KVMKVMKVM | Found VM virtualization kvm | kvm -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:38, Chris Hofstaedtler wrote: > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > [..] But maybe it [glibc's postinst] should be doing some > > more involved checks about what PID 1 is? It could then make sure to only > > call > > systemd telinit if systemd is pid 1. [..] > > Well, that would probably suck. Putting the knowledge when to call > telinit, and a specific telinit, into a ton of different things > makes all those things hard to get right, hard to update, the usual. On the glibc side, this part has always been a pain to handle (a bit less since upstart got removed). And the systemd decision to increase the use of dlopen() will make this step even more necessary. Therefore I wonder if it could be solved using the trigger mechanism, basically glibc saying "I got upgraded" and the packages, being systemd, sysv or any other system can then decide what to do instead of hardcoding that on the glibc side. That would also simplify the chrootless case a bit. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:22, Luca Boccassi wrote: > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > wrote: > > > > Hi, > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > more involved checks about what PID 1 is? It could then make sure to > > > > only call > > > > systemd telinit if systemd is pid 1. [..] > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > telinit, and a specific telinit, into a ton of different things > > > makes all those things hard to get right, hard to update, the usual. > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > they are not that different. Both try to talk to their respective > > > pid1 daemons first using their respective communication socket. > > > > > > But then, if that doesn't work, they diverge: > > > - sysvinit's telinit just gives up > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > being in a chroot, before doing any of that. > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > fallback to stick with sysvinit's behaviour? > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > glibc's > > > postinst (and other places) can become simpler again. > > > > via irc, jochen also pointed out: telinit could be the component which > > checks > > what PID 1 actually is and only do its thing after it confirmed that it is > > indeed an init system like systemd that is providing PID 1? > > That's all legacy stuff and I really don't want to touch it anymore. > Going from the other side, maybe libc6.postinst could use something > more reliable than ischroot()? Is systemd-detect-virt able to figure > out the situation a bit better? Nope. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071192: maildir-utils: FTBFS on riscv64: testsuite failure
Source: maildir-utils
Version: 1.12.4-1
Severity: important
Tags: ftbfs patch upstream
X-Debbugs-Cc: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64
Dear maintainer,
maildir-utils fails to build from source on riscv64 due to a testsuite
failure:
| Summary of Failures:
|
| 38/46 test-storeFAIL4.41s killed by signal 6 SIGABRT
|
| Ok: 45
| Expected Fail: 0
| Fail: 1
| Unexpected Pass:0
| Skipped:0
| Timeout:0
| rm -fr -- /tmp/dh-xdg-rundir-yjVOiMWA
| dh_auto_test: error: cd obj-riscv64-linux-gnu &&
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test
returned exit code 1
| make: *** [debian/rules:26: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=maildir-utils=riscv64=1.12.4-1=1714778367=0
After investigation, it appears the test fails due to a too small
timeout in the check for the buildd hardware. Doubling the timeout with
the following patch fixes the issue:
--- maildir-utils-1.12.4.orig/lib/tests/test-mu-store.cc
+++ maildir-utils-1.12.4/lib/tests/test-mu-store.cc
@@ -494,7 +494,7 @@ test_store_circular_symlink(void)
size_t n{};
while (store.indexer().is_running()) {
std::this_thread::sleep_for(100ms);
- g_assert_cmpuint(n++,<=,25);
+ g_assert_cmpuint(n++,<=,50);
}
// there will be a lot of dups
g_assert_false(store.empty());
Note that it might also fix the FTBFS on alpha, hppa and sparc64 as the
symptoms look similar.
Regards
Aurelien
Bug#1071172: libc6-dev omits the bits directory
Hi, On 2024-05-15 22:10, Joris van der Geer wrote: > package:libc6-dev > version: 2.36 Please provide a more accurate version than this. In the rest of this email i will therefore consider the latest glibc version, in sid, ie 2.38-11: > Libc6 omits thr ‘bits’ directory, rendering glibc inoperable The bits directory is not omitted, it is provided in /usr/include/aarch64-linux-gnu following the multiarch path convention. > after sucessfull apt-get install libc6 libc6-dev : > > When compiling gcc, the process halts at : > > In file included from ../.././libgcc/../gcc/tsystem.h:95, > from ../.././libgcc/libgcc2.c:27: > /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such > file or directory >27 | #include > | ^~ > compilation terminated. > make[2]: *** [Makefile:508: _muldi3.o] Error 1 > make[2]: Leaving directory > '/home/joris/src/gcc-14.1.0/aarch64-unknown-linux-gnu/libgcc' > make[1]: *** [Makefile:14517: all-target-libgcc] Error 2 > make[1]: Leaving directory '/home/joris/src/gcc-14.1.0' > make: *** [Makefile:1050: all] Error 2 I guess you are building gcc from source. For using the multiarch path convention, you should configure it with --enable-multiarch. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071093: libc6: [adequate] undefined-symbol
control: reassign -1 adequate control: retitle -1 false positive detected in in libthread_db.so.1 Hi, On 2024-05-14 10:14, Martin-Éric Racine wrote: > Package: libc6 > Version: 2.38-11 > Severity: important > > $ adequate --all --tags -py-file-not-bytecompiled > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pdwrite > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pglobal_lookup > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lsetregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_getpid > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lgetfpregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lsetfpregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lgetregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pdread This is perfectly normal. libthread_db.so is a special system library for thread debugging. Those symbols are provided by the debuggers using it, for instance gdb or lldb. I am therefore reassigning this to adequate as a false positive. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8
Hi, On 2024-05-14 21:51, Chris Hofstaedtler wrote: > Hi Eugene, > > could you please try again with: > util-linux 2.40.1-1 > glibc 2.38-7 or newer > > and report back, if the problem is fixed for you? > > The newer util-linux is rebuilt against the fixed glibc, so it > hopefully is now fine. It might be necessary to delete your old > utmp/lastlog files tho. Looking at it more in details, this is definitely bug#1042562 applied to util-linux. It appears that starting with version 2.40., util-linux automatically enables -D_TIME_BITS=64, so even if i386 is not an architecture that was part of the time_t transition, the problem has been triggered there. It appears that util-linux 2.40.1-1 has been rebuilt against a fixed glibc, so the problem is probably fixed. At the end it should be limited to util-linux versions 2.40-1 to 2.40-8. I don't think it is necessary to upgrade glibc to get the issue fixed. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071085: chr: FTBFS on riscv64 due to test timeout
Source: chr Version: 0.1.78-1 Severity: important Tags: ftbfs X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, chr fails to build from source on riscv64 (and a few other slow architectures) with a timeout in a test: | tests time out (After 30 seconds) | ―― | 1/1 tests TIMEOUT30.07s killed by signal 15 SIGTERM | | | Ok: 0 | Expected Fail: 0 | Fail: 0 | Unexpected Pass:0 | Skipped:0 | Timeout:1 The full build log is available there: https://buildd.debian.org/status/fetch.php?pkg=chr=riscv64=0.1.78-1=1715582047=0 After investigation, it appears the test actually passes, but needs 68 seconds instead of the default 30 seconds it got allocated. The following patch uses the --timeout-multiplier feature of meson to increase the timeout. I didn't try to use a different multiplier depending on the architecture as it has no impact on working tests. diff -Nru chr-0.1.78/debian/rules chr-0.1.78/debian/rules --- chr-0.1.78/debian/rules +++ chr-0.1.78/debian/rules @@ -22,8 +22,8 @@ dh_auto_build --builddirectory=$(build_tiny) override_dh_auto_test: - dh_auto_test --builddirectory=$(build_edit) - dh_auto_test --builddirectory=$(build_tiny) + dh_auto_test --builddirectory=$(build_edit) -- --timeout-multiplier=4 + dh_auto_test --builddirectory=$(build_tiny) -- --timeout-multiplier=4 override_dh_auto_install: dh_auto_install --builddirectory=$(build_edit) --destdir=debian/chr Note that it might also fix the same issue on hppa and sparc64. Regards Aurelien
Bug#1071076: inotify-info: baseline ABI violation, builds with -march=native
Source: inotify-info Version: 0.0.1-1 Severity: serious Dear maintainer, inotify-info builds with -march=native, which means the instruction set it uses depends on the buildd that is used. For instance the i386 package uses AVX instructions. In addition -march=native is not supported on all architectures. This is unfortunately not visible in the build log, you might want to make the build system as verbose as reasonably possible as recommended by the debian policy. Regards Aurelien
Bug#1070668: Processed: glibc: packages FTBFS caused by vector math library header on arm64
On 2024-05-07 00:29, Simon Chopin wrote: > As the one who reported the issue in the glibc upstream tracker, I'm now > of the opinion it's not a glibc bug, but rather issues with the > individual packages that are now FTBFS. As far as I know, this is either > a parser pretending to be GCC without implementing all the GCC features > (e.g. aspectc++), and/or a compiler targetting another platform while > still using the system headers (e.g. rocm-hipamd). The goal of the removal was able to progress with the migration of glibc 2.38 to testing to not block other packages for a long time. Anyway this strategy does not work for glibc 2.39 (it causes a FTBFS of glibc), so we have to solve the issues before being able to get glibc 2.39 to unstable. Among the 4 failures, cxref already got fixed. For aspectc++ and cbmc, I agree with you that the issues have to be fixed at the package level. For rocm-hipamd, the maintainer claims this is a toolchain issue... -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070981: RM: h5z-zfp/experimental -- RoQA; outdated version wrt unstable
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: h5z-...@packages.debian.org Control: affects -1 + src:h5z-zfp User: ftp.debian@packages.debian.org Usertags: remove h5z-zfp in experimental has a lower version than in unstable, which means binNMUs are not possible as they get rejected by dak. I do not see the point of keeping this lower version in experimental, I think the only reason it has not been decrufted is the s390x binary which is only in experimental. It is not buildable in sid anymore due to the new architecture-is-little-endian build dependency.
Bug#1070980: libamplsolver: FTBFS on architectures calling fedisableexcept (ppc64el, s390x, riscv64, ...)
Source: libamplsolver
Version: 0~20190702-2
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
Dear maintainer,
libamplsolver fails to build from source on a few architectures that call
fedisableexcept(), which from a quick look seems to be !x86 !arm !alpha:
| make[1]: Entering directory '/<>'
| cd ${OBJDIR=sys.`uname -m`.`uname -s`}; make
| make[2]: Entering directory '/<>/sys.riscv64.Linux'
| make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
| cc -c -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -pipe -DASL_BUILD -fPIC -DPIC -DASL_NO_FPINITMT fpinit.c
| fpinit.c: In function ‘fpinit_ASL’:
| fpinit.c:143:9: error: implicit declaration of function ‘fedisableexcept’;
did you mean ‘feraiseexcept’? [-Werror=implicit-function-declaration]
| 143 | fedisableexcept(FE_ALL_EXCEPT);
| | ^~~
| | feraiseexcept
| cc1: some warnings being treated as errors
| make[2]: *** [makefile:240: arith.h] Error 1
| make[2]: Leaving directory '/<>/sys.riscv64.Linux'
| make[1]: *** [makefile:2: amplsolver] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j4 returned exit code 2
| make: *** [debian/rules:15: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
A full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=libamplsolver=riscv64=0%7E20190702-2%2Bb2=1715411707=0
The problem has been introduced with dpkg 1.22.5, which changed the
build flags to include -Werror=implicit-function-declaration as part of
the time_t transition. fedisableexcept() is a GNU extension, so it has
to be enabled by building with -D_GNU_SOURCE. The patch belows implement
that.
Regards
Aurelien
--- libamplsolver-0~20190702.orig/fpinit.c
+++ libamplsolver-0~20190702/fpinit.c
@@ -49,6 +49,7 @@ int isatty_ASL; /* for use with "sw" und
#undef WIN32
#define WIN32
#else
+#define _GNU_SOURCE /* needed for fedisableexcept */
#include "fenv.h"
#endif
--- libamplsolver-0~20190702.orig/solvers/fpinit.c
+++ libamplsolver-0~20190702/solvers/fpinit.c
@@ -49,6 +49,7 @@ int isatty_ASL; /* for use with "sw" und
#undef WIN32
#define WIN32
#else
+#define _GNU_SOURCE /* needed for fedisableexcept */
#include "fenv.h"
#endif
Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so
control: tag -1 + patch On 2024-05-11 19:50, Aurelien Jarno wrote: > On 2024-05-11 15:46, Sebastian Ramacher wrote: > > Source: llvm-toolchain-18 > > Version: 1:18.1.5-2 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > X-Debbugs-Cc: sramac...@debian.org > > > > riscv64 is now a release architecture and llvm-toolchain-18 built > > previously. > > > > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18=riscv64=1%3A18.1.5-2=1715249422=0 > > > >debian/rules override_dh_install > > make[1]: Entering directory '/<>' > > dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake > > usr/lib/llvm-18/lib/cmake/polly > > rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake > > dh_install --fail-missing > > dh_install: warning: Please use dh_missing --list-missing/--fail-missing > > instead > > dh_install: warning: This feature will be removed in compat 12. > > dh_install: warning: Cannot find (any matches for) > > "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp) > > > > dh_install: warning: llvm-18-linker-tools missing files: > > usr/lib/llvm-18/lib/LLVMgold.so > > dh_install: error: missing files, aborting > > make[1]: *** [debian/rules:1432: override_dh_install] Error 255 > > I believe this should be fixed by the following patch. I have launched a > local build and I will confirm that when it is done. The build finished, I confirm that the patch fixes the issue. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1064003: patch for c-t-b build
Hi,
On 2024-05-05 20:57, Helmut Grohne wrote:
> Control: tags -1 + patch
>
> Hi Matthias,
>
> I'm attaching a patch for the c-t-b FTBFS. Note that due to the
> glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
> timely upload is appreciated. Due to linux-libc-dev currently providing
> the -$arch-cross packages, we have to remove the Build-Conflicts or make
> rename the Provides on linux-libc-dev. I'm ok with both approaches and
> offer dropping the conflict here.
Thanks for working on that. Note that glibc 2.38-9 switched the compiler
to gcc 13, so your patch needs a small update. Please find it attached.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru cross-toolchain-base-68/debian/changelog
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/changelog 2024-05-04
07:23:39.0 +
@@ -1,3 +1,16 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+ [ Helmut Grohne ]
+ * Non-maintainer upload.
+ * Build using linux 6.7. Closes: #1064003, #1067370.
+ * Build using glibc 2.38.
+ * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ [ Aurelien Jarno ]
+ * Build using gcc 13.
+
+ -- Helmut Grohne Sat, 04 May 2024 09:23:39 +0200
+
cross-toolchain-base (68) unstable; urgency=medium
* Build using linux 6.5.8. Closes: #1042118.
diff -Nru cross-toolchain-base-68/debian/control
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control 2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 07:23:39.0
+
@@ -9,9 +9,9 @@
Build-Depends: binutils-multiarch,
dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
binutils-source (>= 2.41-6~),
- glibc-source (>= 2.37-3~),
- gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
- linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+ glibc-source (>= 2.38),
+ gcc-13-source (>= 13), g++-13 (>= 13),
+ linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
autoconf (>= 2.69), autoconf2.69, autogen,
automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
libjansson-dev, pkg-config,
Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386],
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el],
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf],
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
- libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross,
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross,
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross,
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross,
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross,
linux-libc-dev-riscv64-cross,
+ libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross,
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
Package: linux-libc-dev-amd64-cross
diff -Nru cross-toolchain-base-68/debian/rules
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/rules 2024-05-04 07:23:39.0
+
@@ -61,11 +61,11 @@
CROSS_GNU_TYPE = $(call _gnu_type,${CROSS_ARCH})
CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
-MIN_VER_GLIBC := 2.37-3~
-MIN_VER_LINUX := 6.5.8
-MIN_VER_GCC:= 12.3.0-11~
+MIN_VER_GLIBC := 2.38
+MIN_VER_LINUX := 6.7.0
+MIN_VER_GCC:= 13
MIN_VER_BINUTILS := 2.41-6~
-VER_GCC_BASE := 12
+VER_GCC_BASE := 13
libgcc_base:= gcc-s
DEB_VER_LINUX := $(shell apt-cache policy linux-libc-dev | awk '/^ \*\*\*/
{print $$2}')
@@ -110,7 +110,7 @@
# FIXME: No conflict for the host == cross case ...
BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,)
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
# taken from gcc packaging
define unpack_tarball
Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so
On 2024-05-11 15:46, Sebastian Ramacher wrote: > Source: llvm-toolchain-18 > Version: 1:18.1.5-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > riscv64 is now a release architecture and llvm-toolchain-18 built > previously. > > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18=riscv64=1%3A18.1.5-2=1715249422=0 > >debian/rules override_dh_install > make[1]: Entering directory '/<>' > dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake > usr/lib/llvm-18/lib/cmake/polly > rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake > dh_install --fail-missing > dh_install: warning: Please use dh_missing --list-missing/--fail-missing > instead > dh_install: warning: This feature will be removed in compat 12. > dh_install: warning: Cannot find (any matches for) > "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp) > > dh_install: warning: llvm-18-linker-tools missing files: > usr/lib/llvm-18/lib/LLVMgold.so > dh_install: error: missing files, aborting > make[1]: *** [debian/rules:1432: override_dh_install] Error 255 I believe this should be fixed by the following patch. I have launched a local build and I will confirm that when it is done. diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in --- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in 2024-04-29 11:11:01.0 +0200 +++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in 2024-05-11 19:31:14.0 +0200 @@ -2,4 +2,4 @@ usr/lib/llvm-@LLVM_VERSION@/lib/libLTO.so.@LLVM_VERSION@.1 [!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMPolly.so -[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so +[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in --- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in 2024-03-06 09:19:46.0 +0100 +++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in 2024-05-11 19:33:50.0 +0200 @@ -1,3 +1,3 @@ #!/usr/bin/dh-exec -[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so +[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070850: cfengine3: missing build-depends on passwd, needed for usermod
Source: cfengine3 Version: 3.21.4-1.1 Severity: important Tags: ftbfs X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, cfengine3 fails to build from source on riscv64, here is the relevant part of the log: | checking for useradd... no | checking for usermod... no | checking for userdel... no ... | /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./../libpromises -I./../libntech/libutils -I./../libcfnet -I./../cf-check -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -I/usr/include/libxml2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/libxml2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o verify_users_pam.lo verify_users_pam.c | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./../libpromises -I./../libntech/libutils -I./../libcfnet -I./../cf-check -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -I/usr/include/libxml2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/libxml2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c verify_users_pam.c -fPIC -DPIC -o .libs/verify_users_pam.o | verify_users_pam.c: In function ‘SetAccountLockExpiration’: | verify_users_pam.c:850:50: warning: unused parameter ‘puser’ [-Wunused-parameter] | 850 | static bool SetAccountLockExpiration(const char *puser, bool lock) | | ^ | verify_users_pam.c:850:62: warning: unused parameter ‘lock’ [-Wunused-parameter] | 850 | static bool SetAccountLockExpiration(const char *puser, bool lock) | | ^ | verify_users_pam.c: In function ‘DoCreateUser’: | verify_users_pam.c:1565:38: warning: unused parameter ‘puser’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^ | verify_users_pam.c:1565:57: warning: unused parameter ‘u’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^ | verify_users_pam.c:1565:76: warning: unused parameter ‘action’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^~ | verify_users_pam.c:1566:39: warning: unused parameter ‘ctx’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | | ~^~~ | verify_users_pam.c:1566:62: warning: unused parameter ‘a’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | |~~^ | verify_users_pam.c:1566:80: warning: unused parameter ‘pp’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | | ~~~^~ | verify_users_pam.c: In function ‘DoRemoveUser’: | verify_users_pam.c:1619:62: warning: unused parameter ‘action’ [-Wunused-parameter] | 1619 | static bool DoRemoveUser (const char *puser, enum cfopaction action) | | ^~ | verify_users_pam.c: In function ‘DoModifyUser’: | verify_users_pam.c:1642:18: error: ‘USERMOD’ undeclared (first use in this function) | 1642 | strcpy
Bug#1070441: FTBFS due to /usr/include/aarch64-linux-gnu/bits/math-vector.h
control: severity 1070441 important control: block 1070668 by 1070441 control: severity 1070443 important control: block 1070668 by 1070443 control: severity 1070444 important control: block 1070668 by 1070444 control: severity 1070446 important control: block 1070668 by 1070446 Dear maintainers, glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in order to support math vector functions. This unfortunately caused the FTBFS of your packages. The change has been temporarily reverted in version 2.38-8 until a fix is found, and I have opened #1070668 on the glibc side to track the issue, with a Cc: to the arm64 porters. I am therefore downgrading the bugs to severity important. However this should not prevent working on a solution to the problem with the arm64 porters, and depending on the case either at the package level, or at the upstream glibc/gcc/llvm level. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070668: glibc: packages FTBFS caused by vector math library header on arm64
Source: glibc Version: 2.38-1 Severity: important Tags: upstream X-Debbugs-Cc: debian-...@lists.debian.org Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30909 glibc 2.38 added vector math library (libmvec) support for arm64, with ASIMD and SVE version. This includes an architecture specific header, /usr/include/aarch64-linux-gnu/bits/math-vector.h, to declare the vectorized functions. For that the ASIMD types __Float32x4_t and __Float64x2_t are also defined for GCC >= 9 or CLANG >= 8, and SVE types __SVFloat32_t, __SVFloat64_t and __SVBool_t for GCC >= 10 and CLANG >= 11. Unfortunately this causes issues to the following packages: - #1070441 cmbc: arm64 FTBFS with glibc 2.38 - #1070443 aspectc++: arm64 FTBFS with glibc 2.38 - #1070444 cxref: arm64 FTBFS with glibc 2.38 - #1070446 rocm-hipamd: arm64 FTBFS with glibc 2.38 The issue has already been reported upstream [1]. For now this file has been restored to the generic version in glibc 2.38-8, removing support for the corresponding vector functions [2]. Porters, could you please have a look at the issue, and work on fixes at the package level and at the upstream glibc/gcc/llvm level? Thanks Aurelien [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30909 [2] https://salsa.debian.org/glibc-team/glibc/-/commit/9e2889537336bdad878eef88bcfb13e457e8ea77
Bug#1055297: ruby3.1: fails to build against glibc 2.38
control: severity -1 serious Hi, On 2023-11-03 19:45, Samuel Thibault wrote: > Package: ruby3.1 > Version: 3.1.2-7 > Severity: important > Tags: patch > > Hello, > > ruby3.1 fails to build against glibc 2.38: > > dpkg-gensymbols -plibruby3.1 -Idebian/libruby3.1.symbols -Pdebian/libruby3.1 > -edebian/libruby3.1/usr/lib/x86_64-gnu/libruby-3.1.so.3.1.2 > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > file: see diff output below > dpkg-gensymbols: warning: debian/libruby3.1/DEBIAN/symbols doesn't match > completely debian/libruby3.1.symbols > --- debian/libruby3.1.symbols (libruby3.1_3.1.2-7_hurd-amd64) > +++ dpkg-gensymbols5L9SYx 2023-11-03 17:57:31.0 + > [...] > @@ -1818,5 +1818,5 @@ > ruby_xrealloc2@Base 3.1.0~preview1 > ruby_xrealloc@Base 3.1.0~preview1 > setproctitle@Base 3.1.0~preview1 > - strlcat@Base 3.1.0~preview1 > - strlcpy@Base 3.1.0~preview1 > +#MISSING: 3.1.2-7# strlcat@Base 3.1.0~preview1 > +#MISSING: 3.1.2-7# strlcpy@Base 3.1.0~preview1 > > strlcat and strlcpy were indeed added to glibc in version 2.38, so it's > not surprising that ruby3.1 doesn't define its internal versions any > more, and the attached patch can probably be applied? glibc 2.38 is now in unstable, so upgrading the severity to serious. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1059852: transition: glibc 2.38
Hi, On 2024-01-02 13:23, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: gl...@packages.debian.org > Control: affects -1 + src:glibc > > Dear release team, > > I would like to get a transition slot for glibc 2.38. It has been > available in experimental for a few months and does not have any known > issue anymore. It has been built successfully on all release > architectures and most ports architectures, and the experimental > pseudo-excuses look good overall. > > As glibc is using symbol versioning, there is no soname change. That > said a few packages are using libc internal symbols and have to be > rebuilt for this transition. Here is the corresponding ben file: > > title = "glibc"; > is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.39\)/; > is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/; > > The main symbol related changes in this version are the addition of > strlcat and strlcpy and related functions, coming from the BSD world. A > few packages have their own implementation exported in their symbols > file. With glibc 2.38 starting to provide those functions, the packages > stops providing compatibility functions and the associated symbols, > causing them to FTBFS. Many of them have been identified thanks to the > hurd-amd64 bootstrap and have been fixed. The known remaining ones are: > - #1055297 ruby3.1: fails to build against glibc 2.38 > - #1055316 heimdal: fails to build against glibc 2.38 > > Other than that a few symbols have been added to support the C2X binary > constant handling in scanf family of functions. There are unlikely to be > widely used at this point and thus that new packages start to use them, > blocking their migration to testing during the transition. > > Thanks for considering. As discussed on IRC, I just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070012: keyutils: testsuite wrongly assumes that user 0 always exists
Source: keyutils Version: 1.6.3-3 Severity: important Tags: patch upstream ftbfs X-Debbugs-Cc: debian-wb-t...@lists.debian.org Usertags: unshare Dear maintainer, keyutils fails to build from source when built inside a container: | === /<>/tests/keyctl/newring/bad-args/test.out === | ./runtest.sh: line 13: [: 4096: unary operator expected | +++ CHECK MAXLEN DESC FAILS WITH EDQUOT | FAILED | FAILED | +++ CHECK OVERLONG DESC | +++ CHECK EMPTY KEYRING NAME | +++ CHECK BAD KEY ID | make[3]: *** [Makefile:41: run] Error 1 | make[3]: Leaving directory '/<>/tests' | make[2]: *** [Makefile:253: test] Error 2 | make[2]: Leaving directory '/<>' | dh_auto_test: error: make -j4 test PATH=/<>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LD_LIBRARY_PATH=/<> SKIPROOTREQ=yes SKIPINSTALLREQ=yes returned exit code 2 | make[1]: *** [debian/rules:25: override_dh_auto_test] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:10: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 The "unary operator expected" issue is because maxsquota is undefined. Indeed it is defined by looking at /proc/key-users for user 0 (root), however this user does necessary not exists in a container. In addition as the testsuite is run as non-root (contrary to what upstream recommends), I believe the returned values are incorrect. At least on my system they are quite different between root and normal users. This simple one-liner fixes the issue, and should still work fine with the testsuite run as root: --- keyutils-1.6.3.orig/tests/toolbox.inc.sh +++ keyutils-1.6.3/tests/toolbox.inc.sh @@ -45,7 +45,7 @@ fi maxcall=$fullpage -maxsquota=`grep '^ *0': /proc/key-users | sed s@.*/@@` +maxsquota=`grep "^ *$UID": /proc/key-users | sed s@.*/@@` key_gc_delay_file="/proc/sys/kernel/keys/gc_delay" if [ -f $key_gc_delay_file ]; then Regards Aurelien
Bug#1070007: sbuild/unshare: writing to /dev/stdout denied
Package: sbuild Version: 0.85.8 Severity: normal When running sbuild in unshare chroot mode, it is not possible to write to /dev/stdout: | echo test > /dev/stdout | sh: 1: cannot create /dev/stdout: Permission denied This is the reason of the FTBFS of at least clisp and supervisor when using the unshare chroot mode of sbuild.
Bug#1070003: sbuild/unshare: bind mounting individual /dev entries causes inconsistent readdir results
Package: sbuild
Version: 0.85.7
Severity: normal
When running sbuild in unshare chroot mode, /dev is provided by creating
all the entries as regular files, and then the entries from the host
/dev are bind-mounted to the container. This causes readdir(), which
maps to the getdents64 syscall, to return the underlying files in the
/dev directory instead of the bind-mounted files. Although the names are
correct, the d_ino, d_off and d_type values are incorrect. For instance
/dev/null is reported as regular file instead of a character device.
This can be demonstrated by this simple C code:
| #include
| #include
| #include
|
| int main()
| {
| struct dirent *entry;
| DIR *dp;
|
| dp = opendir("/dev");
| if (dp == NULL) {
| perror("opendir");
| return -1;
| }
|
| while((entry = readdir(dp))) {
| printf("%s: type %d\n", entry->d_name, entry->d_type);
| }
|
| closedir(dp);
|
| return 0;
| }
This is the reason of the FTBFS of at least glibc and libwibble when
using the unshare chroot mode of sbuild.
That said, this seems to be the standard way to provide /dev entries on
a non-privileged user namespace, for instance podman has the same issue.
Docker does not have the issue, but on the other hand requires root.
There might be no way to fix the issue, in that case we should consider
this a limitation of the unshare chroot mode, document it, and add
debian specific workarounds to the affected packages.
Bug#1060772: python3-jupyterlab: Using node-corepack downloads yarnpkg from Internet
control: severity -1 serious On 2024-01-14 08:20, Yadd wrote: > Package: python3-jupyterlab > Version: 4.0.9+ds1-1 > Severity: important > X-Debbugs-Cc: y...@debian.org > > Hi, > > the patch 0003-Use-system-provided-yarn.js.patch replaces missing > yarn.js by node-corepack. Please keep in mind that > node-corepack/../yarn.js is a wrapper that downloads yarnpkg from > Internet instead of using Debian's one. As network access is forbidden by Debian Policy section 4.9, this is actually a serious bug. Changing the severity accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1036369: ruby-rest-client: network-dependent tests fail
control: severity -1 serious On 2023-05-20 10:46, Vignesh Raman wrote: > Package: ruby-rest-client > Version: 2.1.0-3 > Severity: normal > Tags: patch > X-Debbugs-Cc: vignesh.ra...@collabora.com > > Dear Maintainer, > > ruby-rest-client is failing to build because its test suite > depends on access to the internet, As network access is forbidden by Debian Policy section 4.9, this is actually a serious bug. Changing the severity accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069892: qemu: FTBFS on riscv64: error: macro "KVM_RISCV_GET_TIMER" requires 4 arguments, but only 3 given
Source: qemu
Version: 1:8.2.3+ds-1
Severity: important
Tags: upstream patch ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear maintainer,
qemu version 1:8.2.3+ds-1 fails to build from source on riscv64:
| FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o
| cc -Ilibqemu-riscv64-softmmu.fa.p -I. -I../.. -Itarget/riscv
-I../../target/riscv -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1
-I/usr/include/capstone -I/usr/include/glib-2.0
-I/usr/lib/riscv64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall
-Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef
-Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2
-Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-psabi -Wshadow=local -isystem /<>/linux-headers -isystem
linux-headers -iquote . -iquote /<> -iquote
/<>/include -iquote /<>/host/include/generic -iquote
/<>/tcg/riscv -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -g -O2
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security
-ffile-prefix-map=../../= -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE
-isystem../../linux-headers -isystemlinux-headers -DNEED_CPU_H
'-DCONFIG_TARGET="riscv64-softmmu-config-target.h"'
'-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -MF
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o.d -o
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -c
../../target/riscv/kvm/kvm-cpu.c
| ../../target/riscv/kvm/kvm-cpu.c: In function
‘kvm_riscv_get_timebase_frequency’:
| ../../target/riscv/kvm/kvm-cpu.c:691:43: error: macro "KVM_RISCV_GET_TIMER"
requires 4 arguments, but only 3 given
| 691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
| | ^
| ../../target/riscv/kvm/kvm-cpu.c:104: note: macro "KVM_RISCV_GET_TIMER"
defined here
| 104 | #define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
| |
| ../../target/riscv/kvm/kvm-cpu.c:691:5: error: ‘KVM_RISCV_GET_TIMER’
undeclared (first use in this function); did you mean ‘KVM_RISCV_SBI_EXT_TIME’?
| 691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
| | ^~~
| | KVM_RISCV_SBI_EXT_TIME
| ../../target/riscv/kvm/kvm-cpu.c:691:5: note: each undeclared identifier is
reported only once for each function it appears in
| ninja: build stopped: subcommand failed.
| make: *** [debian/rules:229: b/qemu/built] Error 1
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=qemu=riscv64=1%3A8.2.3%2Bds-1=1714044943=0
After investigation it appears to be an upstream issue, caused by a
patch backported to the 8.2 stable branch, which does not work as this
branch misses some refactoring commits:
| commit 1e4ec0958ec734ed6a194475e699c917ba950cb2
| Author: Yong-Xuan Wang
| Date: Thu Mar 14 14:15:09 2024 +0800
|
| target/riscv/kvm: fix timebase-frequency when using KVM acceleration
|
| The timebase-frequency of guest OS should be the same with host
| machine. The timebase-frequency value in DTS should be got from
| hypervisor when using KVM acceleration.
|
| Signed-off-by: Yong-Xuan Wang
| Message-ID: <20240314061510.9800-1-yongxuan.w...@sifive.com>
| Reviewed-by: Andrew Jones
| Reviewed-by: Philippe Mathieu-Daudé
| Reviewed-by: Alistair Francis
| Signed-off-by: Alistair Francis
| (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe)
| Signed-off-by: Michael Tokarev
| (Mjt: context fix due to missing other changes in this area in 8.2.x)
One way to fix that is to identify and backport the missing commits. I
know that 10f86d1b845087d14b58d65dd2a6e3411d1b6529 is one of them, but
is not enough. However the risk to break more things by backporting more
commits is important.
An alternative is to just fix the build issue with the following patch:
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index c1675158fe..f15a540f61 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -687,8 +687,9 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
{
uint64_t reg;
+CPURISCVState *env = _CPU(cs)->env;
-KVM_RISCV_GET_TIMER(cs, frequency, reg);
+KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
return reg;
}
I will let you, as the maintainer,
Bug#1041415: details
control: tag -1 + fixed-upstream On 2024-04-23 16:22, David Edmondson wrote: > tag 1041415 - upstream > thanks > > Ultimately this fails because /proc is not available in the chroot. > > The version of libc in use *emulates* fchmodat() using /proc/self/fd > rather than using the fchmodat system call. It is emulated, because support for flags != 0 is something new, and requires the fchmodat2 syscall that has been added in Linux kernel version 6.6. On the glibc side, support has been added in glibc 2.39, which is available in git [1], but unfortunately not yet in sid due to binutils/valgrind bug [2] and time_t transition [3] blocking things. Regards Aurelien [1] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.39 [2] https://bugs.debian.org/1057693 [3] https://bugs.debian.org/1059852 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069730: unblock: glibc/2.37-18
Package: release.debian.org Severity: normal Tags: security X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: unblock Hi, glibc 2.37-18 fixes an import security issue (CVE-2024-2961), and it would be nice to have it in testing asap. It is currently blocked by the proftpd-dfsg autopkgtest, which fails due to the lack of libnsl-dev in the chroot, as this dependency got removed in glibc version 2.37-15.1 as part of the time_t transition. proftpd-dfsg has already been fixed by making it an explicity build-dependency, however this fixed version can't enter testing as it is entangled in the time_t transition. The glibc doesn't break proftpd-dfsg in testing, but basically breaks its buildability and thus its autopkgtest. Do you think it would be possible to allow this glibc version to enter testing by ignoring the result of the proftpd-dfsg autopkgtest? Regards Aurelien
Bug#1068963: python-falcon: FTBFS: testsuite failure: 3084 passed, 313 skipped, 170 warnings, 35 errors
Source: python-falcon Version: 3.1.1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, python-falcon fails to build from source due to errors in the testsuite. >From my build log on amd64: | === short test summary info | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_get[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_put[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_head_405[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multipart_form[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multiple[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_invalid_content_length[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_large[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_no_body[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse_client_disconnects_early[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_stream_chunked_request[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_missing_responder[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-*-amqp] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-wamp-wamp] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_unknown[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_disconnecting_client_early[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_send_before_accept[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_recv_before_accept[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_invalid_close_code[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_error[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_http_error[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-send] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-recv] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-send] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-recv] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_passing_path_params[_uvicorn_factory] | = 3084 passed, 313 skipped, 170 warnings, 35 errors in 36.58s == A full build log on riscv64 is available here: https://buildd.debian.org/status/fetch.php?pkg=python-falcon=riscv64=3.1.1-2%2Bb2=1713048383=0 Full build logs on amd64 and arm64 are also available on reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-falcon_3.1.1-2.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-falcon_3.1.1-2.rbuild.log.gz Regards Aurelien
Bug#1068959: py-ubjson: FTBFS: testsuite failure: FAILED (failures=2)
Source: py-ubjson Version: 0.16.1-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, py-ubjson fails to build from source due to errors in the testsuite. >From my build log on amd64: | == | FAIL: test_recursion (test.TestEncodeDecodeFpExt.test_recursion) | -- | Traceback (most recent call last): | File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", line 476, in test_recursion | with self.assert_raises_regex(RuntimeError, 'recursion'): | AssertionError: RuntimeError not raised | | == | FAIL: test_recursion (test.TestEncodeDecodePlainExt.test_recursion) | -- | Traceback (most recent call last): | File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", line 476, in test_recursion | with self.assert_raises_regex(RuntimeError, 'recursion'): | AssertionError: RuntimeError not raised | | -- | Ran 116 tests in 2.212s | | FAILED (failures=2) | E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd /<>/.pybuild/cpython3_3.12_ubjson/build; python3.12 -m unittest discover -v test/ A full build log on riscv64 is available here: https://buildd.debian.org/status/fetch.php?pkg=py-ubjson=riscv64=0.16.1-3%2Bb1=1713019530=0 Full build logs on amd64 and arm64 are also available on reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/py-ubjson_0.16.1-3.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/py-ubjson_0.16.1-3.rbuild.log.gz Regards Aurelien
Bug#1068960: python-pybedtools: FTBFS: testsuite error: 14 failed, 491 passed, 2 deselected, 3 xfailed
Source: python-pybedtools
Version: 0.9.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
python-pybedtools fails to build from source due to errors in the
testsuite. From my build log on amd64:
| === short test summary info
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_file_types_are_bed
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_can_be_intersected
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_are_iterable_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_str_representation_of_gzipped_files_is_the_same_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_head_of_gzipped_files_is_the_same_as_normal
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_output -
FileNotFou...
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_is_default_when_extension_is_dot_gz
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_can_be_turned_off_even_for_dot_gz
| FAILED pybedtools/test/test_issues.py::test_issue_169 - UnicodeDecodeError:
'...
| FAILED pybedtools/test/test_issues.py::test_issue_196 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_180 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_181 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_258 - gzip.BadGzipFile:
Not...
| FAILED pybedtools/test/test_issues.py::test_issue_343 - UnicodeDecodeError:
'...
| === 14 failed, 491 passed, 2 deselected, 3 xfailed in 9.27s
| E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.11_pybedtools/build; python3.11 -m pytest
-k "not test_chromsizes"
| dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12
3.11" returned exit code 13
| make: *** [debian/rules:30: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
A full build log on riscv64 is available here:
https://buildd.debian.org/status/fetch.php?pkg=python-pybedtools=riscv64=0.9.1-1%2Bb2=1713040255=0
Full build logs on amd64 and arm64 are also available on reproducible
builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-pybedtools_0.9.1-1.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-pybedtools_0.9.1-1.rbuild.log.gz
Regards
Aurelien
Bug#1068473: closed by Debian FTP Masters (reply to Bas Couwenberg ) (Bug#1068473: fixed in icinga2 2.13.6-2+deb12u1)
Hi Sebastiaan, On 2024-04-09 16:51, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:icinga2 package: > > #1068473: icinga2: crashes on startup on ppc64el > > It has been closed by Debian FTP Masters > (reply to Bas Couwenberg ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Bas Couwenberg > ) by > replying to this email. Thanks a lot for promptly fixing this bug. The ppc64el hosts in the debian infrastructure are now using the icinga2 packages from bookworm-proposed-updates and all works fine. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1066887: ENhance Patch for local-gen
Hi,
On 2024-03-15 16:13, M. Buecher wrote:
> Adding / back to end of the path, so that a locale file is immediately
> found.
> diff --git a/debian/local/usr_sbin/locale-gen
> b/debian/local/usr_sbin/locale-gen
> index 7fa3d772..1711a4f0 100755
> --- a/debian/local/usr_sbin/locale-gen
> +++ b/debian/local/usr_sbin/locale-gen
> @@ -23,6 +23,12 @@ is_entry_ok() {
> fi
> }
>
> +if [ -z "${I18NPATH:-}" ]; then
> + if [ -d "${USER_LOCALES}" ]; then
> +I18NPATH="${USER_LOCALES%%/locales*}/"
> + fi
> +fi
> +
> echo "Generating locales (this might take a while)..."
> while read -r locale charset; do
> if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue;
> fi
> @@ -46,7 +52,7 @@ while read -r locale charset; do
> input="$USER_LOCALES/$input"
> fi
> fi
> - localedef -i "$input" -c -f "$charset" -A
> /usr/share/locale/locale.alias "$locale" || :
> + I18NPATH="${I18NPATH}" localedef -i "$input" -c -f "$charset" -A
> /usr/share/locale/locale.alias "$locale" || :
> echo " done"
> done < "$LOCALEGEN"
> echo "Generation complete."
Thanks for your bug report and for even proposing a patch which looks
good to me.
That said as I18NPATH could actually contains a list of directory, I
wonder if the behaviour would be more consistent if the user locales
directory is always prepended to I18NPATH if it exists. What do you
think?
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"
Hi, On 2024-03-22 16:42, Frank Heckenbach wrote: > - I tried to report it upstream, but that's also broken. According to > https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs > should be reported at https://www.gnu.org/software/libc/bugs.html, but this > page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html > which does not mention reporting bugs. Please see this page for reporting bug upstream: https://sourceware.org/glibc/bugs.html Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi,
On 2024-04-09 07:56, Helmut Grohne wrote:
> Hi Aurelien,
>
> On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> > Thanks for you analysis and your patch. In short your proposal is to
> > extend the initial patch from Steve to fully hide the fact that the
> > compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> >
> > This indeed works and fixes the FTBFS. However it seems that, at least
> > for some of the issues, it just hides them. For instance the wrong type
> > for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> > conformance tests. Quoting utmpx.h/conform.out:
>
> I think this needs a more nuanced look. From the comments in the
> conformance test suite, it is evident that it expects to be run without
> _FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
> exist only exist when these macros are unset. The conformance test suite
> has a comment saying that it should be testing the case where
> _FILE_OFFSET_BITS is defined, but it currently does not provide
> expectations for that case.
>
> Before we can reasonably run the conformance test suite with these
> macros set (and really, the test suite should be in control of these
> macros), we cannot reasonably use it with them set. Let us now imagine a
> future where the conformance test suite has been extended to provide
> expectations (which in lots of cases means that *64 symbols disappear
> when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:
>
> > | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have
> > ‘__suseconds64_t’ {aka ‘long long int’}
> > | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> > | | ^
> > | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with
> > type ‘suseconds_t’ {aka ‘long int’}
> > | 3 | extern suseconds_t b2_10;
> > | |^
> > | FAIL: Type of member tv_usec
>
> Indeed, this is not something that can easily be fixed and where
> upstream is still debating on what the correct solution should be. It
> also is an issue that existed for a long time. If you head over to a
> bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
> tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
> it is not one that is directly related to Debian changing the default.
> We merely increased the visibility of this problem that existed earlier
> already.
I agree that this is an existing issue. My point there was mostly that
your solution is just hiding a real issue that is found by the
testsuite, and basically the testsuite runs in a different configuration
than the one used on the system. We might just miss new issues for new
upstream versions, which is not something very comfortable for a base
library.
> Given that
> * the issue is already present in bookworm,
> * there are two mutually exclusive solutions and
> * upstream is still discussing the best solution
> I recommend deferring this aspect.
While the issue is already present in bookworm, it is not visible
because the toolchain has different defaults.
> > And we know it is the reason for the FTBFS of libflorist [2], so should
> > we just ignore that issue anyway?
>
> The libflorist issue likely is a consequence. It arises from
> gnat_to_gnu_field where GNAT verifies that the value (of type
> suseconds_t) to be assigned to a field (tv_usec) has the matching size.
> This is directly based on the POSIX expectation and will be fixed with
> the glibc issue.
>
> How about filing a separate bug with glibc that tracks this POSIX
> divergence and mark the libflorist bug as being blocked by this other
> glibc bug? It can be RC or not, but since it affects bookworm, it won't
> block testing migration.
Yes we can do that. That said I am not sure we can claim the issue
affects bookworm, as again the toolchain does not have the same defaults
and therefore libflorist does not FTBFS in bookworm.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi Helmut,
On 2024-04-08 22:19, Helmut Grohne wrote:
> Control: tags -1 + patch
>
> Hi Aurelien and Canonical folks,
>
> On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> > Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> > -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> > except i386.
> >
> > This has been partially fixed in the 2.37-15.1 NMU by adding
> > -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
>
> There are two subtleties about -U_TIME_BITS in a moment.
>
> > | +-+
> > | | Encountered regressions that don't match expected failures. |
> > | +-+
> > | FAIL: conform/ISO/stdio.h/linknamespace
>
> The detail for this failure is:
>
> | [initial] fgetpos64
> | [initial] fopen64
> | [initial] freopen64
> | [initial] fsetpos64
>| [initial] tmpfine64
>
> What linknamespace.py wants to tell us here is that it expected
> fgetpos64, but no fgetpos64 was declared. It was not declared, because
> there is no difference between fgetpos and fgetpos64 after defining
> -D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
>
> The other failures are of very similar kind, but there also is another
> kind.
>
> > | FAIL: conform/POSIX/sys/stat.h/conform
>
> The detail for this failure contains:
>
> | /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
> '__time64_t' {aka 'long long int'}
> |90 | extern __typeof__ (a2_8.st_atime) b2_8;
> | | ^~~~
> | /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with
> type '__time_t' {aka 'long int'}
> |89 | extern __time_t b2_8;
> | | ^~~~
>
> Here, it tells us that it expected the st_atime field of struct stat to
> have type __time_t (the 32 bit one), but it really has __time64_t.
>
> Looking at the invocation of linknamespace.py you can see:
>
> | python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
> --flags='-I../include
> -I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
> -I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
> -I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
> -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
> -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
> -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
> -I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
> -I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
> -I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
> -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
> -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
> /build/reproducible-path/glibc-2.37/debian/include -I..' ...
>
> In particular, what you do not see is -U_TIME_BITS inside --flags.
>
> > Ubuntu has just ignored those failures for now, but I am just afraid
> > that if we do the same, nobody will fix them.
>
> Armed with this knowledge, I think we need two changes. For one thing
> debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
> to revert any possible ABI changing effects. For another, the
> conformance tests use independent compiler flags defined in
> conform/Makefile. There, a naive patch seems to be:
>
> -conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
> +conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
> $(+sysdep-includes) $(sysincludes) -I..
>
> With these two changes, I am able to successfully build glibc on armhf
> with the conformance test suite passing.
>
> > In addition it means that upstream glibc does not build anymore by
> > default on a 32-bit Debian. Not really a Debian issue, but that is not
> > nice either and should probably be fixed.
>
> I think that latter change may be applicable upstream. Running the
> conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
> is not expected nor supported. This is partially evident from
> conform/linknamespace.py in a comment:
>
> | # * Header inclusions should be compiled several times with
> | # different options such as -O2, -D_FORTIFY_SOURCE and
> | # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
> | # from such a compilation; this is not yet implemented.
>
Bug#1068473: icinga2: crashes on startup on ppc64el
Hi, On 2024-04-06 14:17, Sebastiaan Couwenberg wrote: > On 4/6/24 1:29 PM, Aurelien Jarno wrote: > > On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > > > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > > > For Bookworm given we can not fix the compiler easily, I propose to just > > > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > > > can take care of proposing a patch and submitting it to the stable > > > > release team. > > > > > > A patch for this is very welcome. How do you propose to implement that? > > > Something like this maybe? > > > > > > --- a/debian/rules > > > +++ b/debian/rules > > > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > > > > >export CTEST_OUTPUT_ON_FAILURE=1 > > > > > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > > > + export DEB_CXXFLAGS_STRIP = -O2 > > > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > > > +endif > > > + > > >ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > > > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > > > -Wl,--as-needed > > >endif > > > > Yes, something like that works. I even tested without the > > DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so > > -O1. > > > > Also it seems that your diff applies to the Trixie/Sid version, while it > > should be applied to Bookworm instead. > > Correct, I did not actually prepare a bookworm branch as you offered to take > care of that. > > Since it's not that much work, I did that now: > > > https://salsa.debian.org/nagios-team/icinga2/-/commits/bookworm?ref_type=heads > > If you can confirm that those changes fix the issue, I can also fix the > bookworm-pu bugreport, or you can do that if you want. Thanks a lot for preparing that. I have just tested it and I confirm it fixes the problem, icinga2 is working nicely with this change. As the maintainer, I would be happy if you send the bookworm-pu bugreport, but in case you lack time or for other reasons, do not hesitate to ask it, and I will do it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068473: icinga2: crashes on startup on ppc64el
On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > For Bookworm given we can not fix the compiler easily, I propose to just > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > can take care of proposing a patch and submitting it to the stable > > release team. > > A patch for this is very welcome. How do you propose to implement that? > Something like this maybe? > > --- a/debian/rules > +++ b/debian/rules > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > export CTEST_OUTPUT_ON_FAILURE=1 > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > + export DEB_CXXFLAGS_STRIP = -O2 > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > +endif > + > ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > -Wl,--as-needed > endif Yes, something like that works. I even tested without the DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so -O1. Also it seems that your diff applies to the Trixie/Sid version, while it should be applied to Bookworm instead. > Note that we ignore test failures on ppc64el which might have caught this > issue. I don't think so. Tests are not ignored for Bookworm and haven't caught the issue. OTOH they are ignored for Trixie/Sid, while this version works fine. > Upstream doesn't care about those architectures, so we're on our own > to resolve issues on architectures other than amd64/i386/arm64. Pretty much > all packages I maintain don't have actual users on non-amd64 architectures, > so I don't consider it worth the effort to ask the porters for help, they > should spend their time on packages that are actually used. With DSA's use > of icinga2 on porterboxes it's the exception to the norm. Yes, I agree that the upstream situation is not nice. I personally try to get things fixed [1], but it went nowhere. And the issue was not really architecture specific, just that icinga2 testsuite doesn't support page sizes bigger than 4K... Regards Aurelien [1] https://github.com/Icinga/icinga2/issues/9954#issuecomment-1875209616 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
On 2024-04-05 21:59, Michael Tokarev wrote: > Control: title -1 nscd caches "wrong" name for accounts with the same uid > Control: found -1 2.37-15 > > Rehashing this 17-years old bug which biten me today quite hard. > > On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko > wrote: > > > > Today, after unsucsessful attempt to login as sashroot, I've got somewhat > > broken system -- all processes running under uid=0 were reported > > belonging to sashroot. Due to lack of knowledge of nss internals I > > inquired on -devel mailing list and it seems that multiple accounts > > sharing uid=0 might be considered a bad practice. For more details see > > http://lists.debian.org/debian-devel/2007/02/msg00323.html > > thread. > > > > If you can prove that it is 'documented feature of nss' to resolve in > > some deterministic way a uid whenever multiple ones are possible, then > > probably this bug has to be reassigned against libc6 to which > > libnss_files belongs. > > > > Since this bug might drive whole system broken, I am assigning it > > important priority, since a big proportion of sash users probably use > > sashroot account feature. > > The problem here is that nscd caches both username and uid on each > lookup, instead of caching just the lookup which has been asked, > and doing the other lookup the normal way as would be done by > getpwnam/getpwuid (and similar for getgrnam/getgrgid etc). > > For very long time we relied on multiple special accounts having > the same uid, exactly like this very sashroot case. We had this > for a few system/special accounts. Each name has its own password > and/or ssh keys (when in use), and each does start/manage its > subsystem with the right permissions. > > Now, with normal getpwuid(), it will return the first entry with > the given uid. But in case of nscd, it returns last looked up > entry with this uid instead. Eg, we have root and r_mjt, - > when I run getpwnam(root), getpwuid(0) will return the same > entry. But once I looked up getpwname(r_mjt), getpwuid(0) > will return r_mjt instead of root from now on. > > Here's another incarnation of the very same theme: > > https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/ > > I guess they use oracle rdbms, and for this one it is also very > helpful to have 2-3 accounts with the same uid, for managing > purposes. And it breaks badly with nscd too. > > Why this bug is marked 'wontfix'? Having multiple users with the same uid in not something supported, and therefore you just encountered an undefined behaviour. Please see this message which tagged the bug as wontfix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411059;msg=15 That said, please feel free to work with upstream to provide a patch. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068473: icinga2: crashes on startup on ppc64el
Source: icinga2
Version: 2.13.6-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@debian.org
Control: fixed -1 icinga2/2.14.2-1
Dear maintainer,
DSA has issues running icinga2 on ppc64el on Bookworm, it fails with a
segmentation fault just after startup:
| × icinga2.service - Icinga host/service/network monitoring system
| Loaded: loaded (/lib/systemd/system/icinga2.service; enabled; preset:
enabled)
| Active: failed (Result: exit-code) since Thu 2024-04-04 20:55:13 UTC;
3min 57s ago
|Duration: 1.209s
|Docs: https://icinga.com/docs/icinga2/latest/
| Process: 356368 ExecStartPre=/usr/lib/icinga2/prepare-dirs
/usr/lib/icinga2/icinga2 (code=exited, status=0/SUCCESS)
| Process: 356373 ExecStart=/usr/sbin/icinga2 daemon --close-stdio -e
${ICINGA2_ERROR_LOG} (code=exited, status=139)
|Main PID: 356373 (code=exited, status=139)
| Status: "Startup finished."
| CPU: 473ms
|
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 IcingaApplication.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 2 Endpoints.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 FileLogger.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 249 CheckCommands.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 ApiListener.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ScriptGlobal: Dumping variables to file
'/var/cache/icinga2/icinga2.vars'
| Apr 04 20:55:12 platti systemd[1]: Started icinga2.service - Icinga
host/service/network monitoring system.
| Apr 04 20:55:12 platti icinga2[356373]: [2024-04-04 20:55:12 +]
information/cli: Closing console log.
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Main process exited,
code=exited, status=139/n/a
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Failed with result
'exit-code'.
I have been able to obtain a backtrace:
| (gdb) bt full
| #0 0x000127d44850 in icinga::JsonRpcConnection::CheckLiveness
(this=this@entry=0x0, yc=...) at ./lib/remote/jsonrpcconnection.cpp:344
| ec = {val_ = 0, failed_ = false, cat_ = 0x0}
| #1 0x000127d44f04 in operator() (__closure=0x7fff7c002620, yc=...) at
./lib/remote/jsonrpcconnection.cpp:58
| keepAlive = {px = 0x0}
| this = 0x0
| keepAlive =
| this =
| #2 operator() (__closure=__closure@entry=0x7fff7c002620, yc=...) at
./lib/base/io-engine.hpp:106
| f = {__this = 0x0, __keepAlive = {px = 0x0}}
| #3 0x000127d521bc in
boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>::operator() (
| ca=..., this=) at
/usr/include/boost/asio/impl/spawn.hpp:355
| data =
| yield = {coro_ =
std::weak_ptr> (use count 1, weak count
5) = {get() = 0x7fff7c0c3640}, ca_ = @0x7fff7c103488,
| handler_ = {> = {},
> = {}, > = {}, > = {executor_ = {service_ =
@0x7fff94003150,
| impl_ = 0x7fff7c002040}, target_ = 0x127d70760
}, }, ec_ = 0x0}
| data =
| yield =
| #4
boost::coroutines::detail::push_coroutine_object,
void, boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>&,
boost::coroutines::basic_standard_stack_allocator
>::run (this=0x7fff7c1035c0)
| at /usr/include/boost/coroutine/detail/push_coroutine_object.hpp:302
| b = {> =
{ = { = {}, },
| _vptr.pull_coroutine_impl = 0x12884b938 +16>, flags_ = 0,
except_ = {ptr_ = {px = 0x0, pn = {pi_ = 0x0}}}, caller_ = 0x7fff7c103618,
| callee_ = 0x7fff7c1035f0}, }
| push_coro = {impl_ = 0x7fff7c103490}
| to = {do_unwind = 64, coro = 0x7fff7c103670}
| __PRETTY_FUNCTION__ =
| b =
| push_coro =
| to =
| #5
boost::coroutines::detail::trampoline_push_void,
void, boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>&,
boost::coroutines::basic_standard_stack_allocator
> >(boost::context::detail::transfer_t) (t=...) at
/usr/include/boost/coroutine/detail/trampoline_push.hpp:70
| __PRETTY_FUNCTION__ = "void
boost::coroutines::detail::trampoline_push_void(boost::context::detail::transfer_t)
[with Coro = push_coroutine_object,
void, boost::asio::detail::coro_ent"...
| data =
| param =
| coro = 0x7fff7c1035c0
| #6 0x7fffa9670f0c in make_fcontext () from
/lib/powerpc64le-linux-gnu/libboost_context.so.1.74.0
| No symbol table info available.
It is not exactly
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On 2024-04-04 22:38, Bill Allombert wrote: > On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote: > > I'm not sure what I think about that. We have a general escape hatch > > already for non-free packages in Policy 2.2.3 that says they may not fully > > comply with Policy, which may be sufficient. > > But precisely, we _do_ want non-free packages that are built on the > autobuilders > to comply with this requirement. So we do not want 2.2.3 to apply in that > specific case. It seems cleaner to say that the requirement only apply if > Autobuild: yes is declared. If we go that route, here is a proposed alternative patch: --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -338,7 +338,8 @@ For example, the build target should pass ``--disable-silent-rules`` to any configure scripts. See also :ref:`s-binaries`. -For packages in the main archive, required targets must not attempt +Except for packages in the non-free archive with the ``Autobuild`` +control field unset or set to ``no``, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On 2024-04-03 12:37, Philipp Kern wrote: > Hi, > > On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote: > > On 2024-04-02 09:21, Sean Whitton wrote: > > > Hello, > > > > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > > the main archive, which implicitly means they are authorized for > > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > > fixed). > > > > > > > > This gives constraints on the build daemons infrastructure and also > > > > brings some security concerns. Would it be possible to extend this > > > > restriction to all archives? > > > > > > We need to know if this is going to break existing packages and allow > > > some input from their maintainers. Are you able to prepare a list of > > > the affected packages? > > > > Fair enough. I can work on that, but help would be welcome as my > > resources are limited. > > I did a test rebuild of contrib, non-free and non-free-firmware packages > in sid with both stable sbuild schroot and unshare backends and could > not find a difference in build success (i.e. what failed failed in both, > what succeeded succeeded in both). Thanks Philipp. Following that result, please find a patch proposal: --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -338,9 +338,9 @@ For example, the build target should pass ``--disable-silent-rules`` to any configure scripts. See also :ref:`s-binaries`. -For packages in the main archive, required targets must not attempt -network access, except, via the loopback interface, to services on the -build host that have been started by the build. +Required targets must not attempt network access, except, via the +loopback interface, to services on the build host that have been started +by the build. Required targets must not attempt to write outside of the unpacked source package tree. There are two exceptions. Firstly, the binary Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
control: found -1 glibc/2.37-15.1 Hi, On 2024-04-01 16:23, Alejandro Colomar wrote: > Package: glibc-doc > Version: 2.38-6 > Severity: serious > Justification: Policy 7.4 > X-Debbugs-Cc: a...@kernel.org, mar...@debian.org > > Dear Maintainer, > > The Linux man-pages project has recently added the pthread_*(3) manual > pages that were provided by glibc-doc. The first upstream version of > the Linux man-pages that includes these pages is man-pages-6.06. Here's > what was added: Thanks, that sounds great that we can finally get rid out of those in the debian package. > $ git diff --stat b06cd070f..128a3ae35 >man3/pthread_cond_init.3| 264 >man3/pthread_condattr_init.3| 48 >man3/pthread_key_create.3 | 178 + >man3/pthread_mutex_init.3 | 241 ++ >man3/pthread_mutexattr_setkind_np.3 | 52 >man3/pthread_once.3 | 44 >6 files changed, 827 insertions(+) > > Debian's manpages-dev_6.7-1_all.deb has been the first package since > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to > upgrade manpages-dev due to a conflict with glibc-doc. > > $ sudo apt-get upgrade -V; > [...] > Do you want to continue? [Y/n] y > Reading changelogs... Done > (Reading database ... 404853 files and directories currently installed.) > Preparing to unpack .../manpages-dev_6.7-1_all.deb ... > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... > dpkg: error processing archive > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): >trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', > which is also in package glibc-doc 2.38-6 > Errors were encountered while processing: >/var/cache/apt/archives/manpages-dev_6.7-1_all.deb > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) I think this is actually not specific to the experimental version, those manpages are also in the unstable version. > Please, remove from glibc-doc those manual pages that conflict with > manpages-dev. Noted. However following the time_t transition, the glibc package does not build anymore on 32-bit architectures (i have just opened #1059937 to make people aware of that), so uploading a new glibc now is probably not the best idea. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Source: glibc Version: 2.37-15.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-...@lists.debian.org Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures except i386. This has been partially fixed in the 2.37-15.1 NMU by adding -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite: | +-+ | | Encountered regressions that don't match expected failures. | | +-+ | FAIL: conform/ISO/stdio.h/linknamespace | FAIL: conform/ISO11/stdio.h/linknamespace | FAIL: conform/ISO99/stdio.h/linknamespace | FAIL: conform/POSIX/aio.h/linknamespace | FAIL: conform/POSIX/dirent.h/linknamespace | FAIL: conform/POSIX/fcntl.h/conform | FAIL: conform/POSIX/fcntl.h/linknamespace | FAIL: conform/POSIX/glob.h/conform | FAIL: conform/POSIX/mqueue.h/conform | FAIL: conform/POSIX/mqueue.h/linknamespace | FAIL: conform/POSIX/stdio.h/linknamespace | FAIL: conform/POSIX/sys/mman.h/linknamespace | FAIL: conform/POSIX/sys/stat.h/conform | FAIL: conform/POSIX/unistd.h/conform | FAIL: conform/POSIX/unistd.h/linknamespace | FAIL: conform/POSIX/utime.h/conform | FAIL: conform/POSIX2008/aio.h/linknamespace | FAIL: conform/POSIX2008/dirent.h/linknamespace | FAIL: conform/POSIX2008/fcntl.h/conform | FAIL: conform/POSIX2008/fcntl.h/linknamespace | FAIL: conform/POSIX2008/glob.h/conform | FAIL: conform/POSIX2008/mqueue.h/conform | FAIL: conform/POSIX2008/mqueue.h/linknamespace | FAIL: conform/POSIX2008/signal.h/conform | FAIL: conform/POSIX2008/stdio.h/linknamespace | FAIL: conform/POSIX2008/stdlib.h/linknamespace | FAIL: conform/POSIX2008/sys/mman.h/linknamespace | FAIL: conform/POSIX2008/sys/select.h/conform | FAIL: conform/POSIX2008/sys/stat.h/conform | FAIL: conform/POSIX2008/sys/statvfs.h/linknamespace | FAIL: conform/POSIX2008/unistd.h/linknamespace | FAIL: conform/UNIX98/aio.h/linknamespace | FAIL: conform/UNIX98/dirent.h/linknamespace | FAIL: conform/UNIX98/fcntl.h/conform | FAIL: conform/UNIX98/fcntl.h/linknamespace | FAIL: conform/UNIX98/glob.h/conform | FAIL: conform/UNIX98/mqueue.h/conform | FAIL: conform/UNIX98/mqueue.h/linknamespace | FAIL: conform/UNIX98/stdio.h/linknamespace | FAIL: conform/UNIX98/stdlib.h/linknamespace | FAIL: conform/UNIX98/sys/mman.h/linknamespace | FAIL: conform/UNIX98/sys/resource.h/linknamespace | FAIL: conform/UNIX98/sys/statvfs.h/linknamespace | FAIL: conform/UNIX98/sys/time.h/conform | FAIL: conform/UNIX98/unistd.h/linknamespace | FAIL: conform/UNIX98/utmpx.h/conform | FAIL: conform/XOPEN2K/aio.h/linknamespace | FAIL: conform/XOPEN2K/dirent.h/linknamespace | FAIL: conform/XOPEN2K/fcntl.h/conform | FAIL: conform/XOPEN2K/fcntl.h/linknamespace | FAIL: conform/XOPEN2K/glob.h/conform | FAIL: conform/XOPEN2K/mqueue.h/conform | FAIL: conform/XOPEN2K/mqueue.h/linknamespace | FAIL: conform/XOPEN2K/stdio.h/linknamespace | FAIL: conform/XOPEN2K/stdlib.h/linknamespace | FAIL: conform/XOPEN2K/sys/mman.h/linknamespace | FAIL: conform/XOPEN2K/sys/resource.h/linknamespace | FAIL: conform/XOPEN2K/sys/select.h/conform | FAIL: conform/XOPEN2K/sys/statvfs.h/linknamespace | FAIL: conform/XOPEN2K/sys/time.h/conform | FAIL: conform/XOPEN2K/unistd.h/linknamespace | FAIL: conform/XOPEN2K/utmpx.h/conform | FAIL: conform/XOPEN2K8/aio.h/linknamespace | FAIL: conform/XOPEN2K8/dirent.h/linknamespace | FAIL: conform/XOPEN2K8/fcntl.h/conform | FAIL: conform/XOPEN2K8/fcntl.h/linknamespace | FAIL: conform/XOPEN2K8/ftw.h/conform | FAIL: conform/XOPEN2K8/glob.h/conform | FAIL: conform/XOPEN2K8/mqueue.h/conform | FAIL: conform/XOPEN2K8/mqueue.h/linknamespace | FAIL: conform/XOPEN2K8/signal.h/conform | FAIL: conform/XOPEN2K8/stdio.h/linknamespace | FAIL: conform/XOPEN2K8/stdlib.h/linknamespace | FAIL: conform/XOPEN2K8/sys/mman.h/linknamespace | FAIL: conform/XOPEN2K8/sys/resource.h/linknamespace | FAIL: conform/XOPEN2K8/sys/select.h/conform | FAIL: conform/XOPEN2K8/sys/stat.h/conform | FAIL: conform/XOPEN2K8/sys/statvfs.h/linknamespace | FAIL: conform/XOPEN2K8/sys/time.h/conform | FAIL: conform/XOPEN2K8/unistd.h/linknamespace | FAIL: conform/XOPEN2K8/utmpx.h/conform | FAIL: conform/XPG4/dirent.h/linknamespace | FAIL: conform/XPG4/fcntl.h/conform | FAIL: conform/XPG4/fcntl.h/linknamespace | FAIL: conform/XPG4/glob.h/conform | FAIL: conform/XPG4/stdio.h/linknamespace | FAIL: conform/XPG4/unistd.h/linknamespace | FAIL: conform/XPG42/dirent.h/linknamespace | FAIL: conform/XPG42/fcntl.h/conform | FAIL: conform/XPG42/fcntl.h/linknamespace | FAIL: conform/XPG42/glob.h/conform | FAIL: conform/XPG42/stdio.h/linknamespace | FAIL: conform/XPG42/stdlib.h/linknamespace | FAIL: conform/XPG42/sys/mman.h/linknamespace | FAIL: conform/XPG42/sys/resource.h/linknamespace | FAIL: conform/XPG42/sys/statvfs.h/linknamespace | FAIL:
Bug#1059937: fio: FTBFS on riscv64: tries to uses rdcycle, privileged since kernel 6.6
Hi, On 2024-01-22 12:59, Martin Steigerwald wrote: > Thanks for the bug report, Aurelien. > > Am Mittwoch, dem 03.01.2024 um 22:45 +0100 schrieb Aurelien Jarno: > > Since the build daemons have been upgraded to kernel 6.6, fio FTBFS > > with SIGILL in the testsuite. It is because the rdcycle instruction > > has been changed to a privileged instruction starting with this kernel > > version. > > > > A fix is available in the upstream repository [1]. Would it be > > possible to include it in the next upload? > > Sure. Instead of maintaining a patch for one version of fio and then > removing it again however I prefer to wait for the next version of fio > before the next upload. > > Feel free to ping upstream about a new release. There is now a new upstream version 3.37 that includes this fix. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On 2024-04-02 09:21, Sean Whitton wrote: > Hello, > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > Package: debian-policy > > Version: 4.6.2.1 > > Severity: normal > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > Control: affects -1 buildd.debian.org > > > > Hi, > > > > The debian policy, section 4.9, forbids network access for packages in > > the main archive, which implicitly means they are authorized for > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > fixed). > > > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > We need to know if this is going to break existing packages and allow > some input from their maintainers. Are you able to prepare a list of > the affected packages? Fair enough. I can work on that, but help would be welcome as my resources are limited. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068198: debian-installer-netboot-images: accesses the internet during build
Source: debian-installer-netboot-images Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer-netboot-images attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Bug#1068197: debian-installer: accesses the internet during build
Source: debian-installer Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free
On 2024-04-01 18:18, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote: > > On 2024-04-01 17:52, Bill Allombert wrote: > > > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > > > Package: debian-policy > > > > Version: 4.6.2.1 > > > > Severity: normal > > > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > > > Control: affects -1 buildd.debian.org > > > > > > > > Hi, > > > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > > the main archive, which implicitly means they are authorized for > > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > > fixed). > > > > > > > > This gives constraints on the build daemons infrastructure and also > > > > brings some security concerns. Would it be possible to extend this > > > > restriction to all archives? > > > > > > Does the build daemons actually build non-free ? > > > > Yes, they do, though only part of non-free, only the packages that have > > Autobuild: yes and that have been put on an allow list after review. > > Is your concern is that the package start to do network acces during build > after it has been added to the allow list ? Yes, this is the security concern. > Do you need "Autobuild: yes" to preclude network access ? Not right now, but the goal is to fully disable the network access, and we do not want to have to special case contrib or non-free, as it just makes things complicated. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free
On 2024-04-01 17:52, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > Package: debian-policy > > Version: 4.6.2.1 > > Severity: normal > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > Control: affects -1 buildd.debian.org > > > > Hi, > > > > The debian policy, section 4.9, forbids network access for packages in > > the main archive, which implicitly means they are authorized for > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > fixed). > > > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > Does the build daemons actually build non-free ? Yes, they do, though only part of non-free, only the packages that have Autobuild: yes and that have been put on an allow list after review. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Package: debian-policy Version: 4.6.2.1 Severity: normal X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, The debian policy, section 4.9, forbids network access for packages in the main archive, which implicitly means they are authorized for packages in contrib and non-free (and non-free-firmware once #1029211 is fixed). This gives constraints on the build daemons infrastructure and also brings some security concerns. Would it be possible to extend this restriction to all archives? Regards, Aurelien
Bug#1068024: revert to version that does not contain changes by bad actor
On 2024-03-29 16:25, Joey Hess wrote: > I'd suggest reverting to 5.3.1. Bearing in mind that there were security > fixes after that point for ZDI-CAN-16587 that would need to be reapplied. Note that reverted to such an old version will break packages that use new symbols introduced since then. From a quick look, this is at least: - dpkg - erofs-utils - kmod Having dpkg in that list means that such downgrade has to be planned carefully. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1067909: libc-devtools: please relax Depends on libgd3
On 2024-03-28 20:35, Martin-Éric Racine wrote: > Package: libc-devtools > Severity: normal > > libgd3 pulls an excessive amount of dependencies, including fonts. It would > thus be desirable to downgrade it to a mere Recommends. > The /usr/bin/memusagestat binary is linked against libgd3, so we can't just changes the Depends to a Recommends. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers
Hi, Thanks for your bug report. On 2024-03-26 12:53, Alessandro Vesely wrote: > Package: libc6 > Version: 2.36-9+deb12u4 > Severity: normal > Tags: ipv6 > > Dear Maintainer, > > I compiled the example program given in the inet_pton(3) man page, and obtain > the following: > > $ ./a.out i6 0:0:0::5:6:7:8 > :::5:6:7:8 > $ ./a.out i6 0:0:0::5.6.7.8 > Not in presentation format > $ ./a.out i6 0:0:0:0:0::5.6.7.8 > :::5.6.7.8 Could you please tell me what do you find curious and what do you expect instead? Thanks. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1067711: mrpt: dpkg-gencontrol: warning: can't parse dependency fonts-roboto-fontface (= )
Source: mrpt
Version: 1:2.12.0+ds-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
mrpt fails to build from source with an error in dpkg-gencontrol. From
my build log on amd64:
| make[1]: Leaving directory '/<>'
|dh_gencontrol -O--buildsystem=pybuild
| dpkg-gencontrol: warning: Depends field of package libmrpt-topography2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-topography2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-topography2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-kinematics2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-kinematics2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-kinematics2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-poses2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-poses2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-poses2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-topography2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-nav2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-nav2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-nav2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-detectors2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-detectors2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-detectors2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-ros1bridge2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-ros1bridge2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-ros1bridge2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-system2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-system2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-system2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-config2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-config2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-config2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-hwdrivers2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-hwdrivers2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-hwdrivers2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-apps2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-apps2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-apps2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-graphslam2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-graphslam2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
On 2024-03-14 04:40, Cyril Brulebois wrote: > Hi, > > Aurelien Jarno (2024-03-13): > > The date of the next point release is slowly approaching, could you > > please have a look at this? > > Sorry, lost track of that one. Feel free to upload. > Thanks, I have just done that. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1059532: abseil:riscv64: uses privileged rdcycle instruction
control: tag -1 + fixed-upstream
control: tag -1 + patch
control: forwarded -1
https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4
Hi Benjamin,
On 2023-12-27 12:45, Benjamin Barenblat wrote:
> Source: abseil
> Version: 20220623.1-1
> Severity: normal
> Tags: upstream
> Control: forwarded -1 https://github.com/abseil/abseil-cpp/pull/1550
>
> On RISC-V, Abseil's cycle counter uses the rdcycle instruction, which is
> a privileged instruction when running on Debian's Linux kernels. This
> causes some widely used Abseil functions (e.g., certain member functions
> on absl::Mutex) to crash with a SIGILL.
This has finally been fixed upstream, please pull the following patch to
fix this issue:
https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4
In addition it is not necessary anymore to run the testsuite with
--no-parallel, the problem was linked to the use of the rdcycle
instruction which jumps when the process is rescheduled on another CPU.
I have tested the following patch with the above upstream commit:
diff -Nru abseil-20230802.1/debian/rules abseil-20230802.1/debian/rules
--- abseil-20230802.1/debian/rules 2023-09-07 19:11:48.0 +0200
+++ abseil-20230802.1/debian/rules 2024-03-23 16:56:20.0 +0100
@@ -28,12 +28,6 @@
ABSL_RUN_TESTS=ON
endif
-# Debian's RISC-V builders don't have enough resources to run tests in
parallel.
-# See https://bugs.debian.org/1025221.
-ifneq ($(filter $(DEB_HOST_ARCH),riscv64),)
-ABSL_TEST_EXTRA_ARGS=--no-parallel
-endif
-
%:
dh $@
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
Bug#1067147: dcmtk: diff for NMU version 3.6.7-9.2
Hi, On 2024-03-19 11:54, Emanuele Rocca wrote: > Package: dcmtk > Version: 3.6.7-9.1 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for dcmtk (versioned as 3.6.7-9.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Emanuele > diff -Nru dcmtk-3.6.7/debian/changelog dcmtk-3.6.7/debian/changelog > --- dcmtk-3.6.7/debian/changelog 2024-02-28 02:17:02.0 +0100 > +++ dcmtk-3.6.7/debian/changelog 2024-03-19 11:08:29.0 +0100 > @@ -1,3 +1,13 @@ > +dcmtk (3.6.7-9.2) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Build without stack-clash-protection on armel. See #1060104. > + * Do not build-depend on graphviz on armhf and armel. The package is > +currently not installable on those arches due to the ongoing t64 > +transition. > + > + -- Emanuele Rocca Tue, 19 Mar 2024 11:08:29 +0100 > + > dcmtk (3.6.7-9.1) unstable; urgency=medium > >* Non-maintainer upload. > diff -Nru dcmtk-3.6.7/debian/control dcmtk-3.6.7/debian/control > --- dcmtk-3.6.7/debian/control2024-02-28 02:17:02.0 +0100 > +++ dcmtk-3.6.7/debian/control2024-03-19 11:08:29.0 +0100 > @@ -16,7 +16,7 @@ > libxml2-dev, > zlib1g-dev > Build-Depends-Indep: doxygen, > - graphviz > + graphviz [!armhf !armel] This does not look correct. Build-Depends-Indep are only used to build the arch:all packages, and currently all the arch:all autobuilder run on amd64. Therefore it looks to me that this change is not necessary to help the armel/armhf rebootstrap done as part of the time_t transition. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066444: nacl: FTBFS: ld: cannot find -lnsl: No such file or directory
control: retitle -1 nacl: FTBFS due to -Werror=implicit-function-declaration Hi, On 2024-03-13 13:03, Lucas Nussbaum wrote: > Source: nacl > Version: 20110221-13 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [ snip] > > === Tue Mar 12 20:30:43 UTC 2024 === checking -lnsl > > /usr/bin/ld: cannot find -lnsl: No such file or directory > > collect2: error: ld returned 1 exit status The build system of nacl is totally nonstandard and difficult to understand, but it appears that this error is harmless. The real issue behind this FTBFS is the -Werror=implicit-function-declaration introduced by dpkg 1.22.6. Retitling the bug accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi Cyril, On 2024-02-25 13:45, Jonathan Wiltshire wrote: > Control: tag -1 d-i > > Hi, > > On Sat, Feb 24, 2024 at 04:59:10PM +0100, Aurelien Jarno wrote: > > [ Reason ] > > The upstream stable branch got a few fixes in the last months, and this > > update pulls them into the debian package. > > > > [ Impact ] > > In case the update isn't approved, systems will be left with a few > > issues, and the differences with upstream will increase, which might > > make next fixes more difficult to review. > > I'm happy with it from SRM point of view, but as you say d-i ack needed. The date of the next point release is slowly approaching, could you please have a look at this? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi Cyril, On 2024-02-25 13:45, Jonathan Wiltshire wrote: > Control: tag -1 d-i > > Hi, > > On Sat, Feb 24, 2024 at 04:59:10PM +0100, Aurelien Jarno wrote: > > [ Reason ] > > The upstream stable branch got a few fixes in the last months, and this > > update pulls them into the debian package. > > > > [ Impact ] > > In case the update isn't approved, systems will be left with a few > > issues, and the differences with upstream will increase, which might > > make next fixes more difficult to review. > > I'm happy with it from SRM point of view, but as you say d-i ack needed. The date of the next point release is slowly approaching, could you please have a look at this? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066403: R packages failing to build with missing -ltirpc are actually an issue in r-base
control: reassign 1066403 r-base-dev control: reassign 1066452 r-base-dev control: reassign 1066455 r-base-dev control: reassign 1066456 r-base-dev control: forcemerge 1066403 1066452 1066455 1066456 control: affects 1066403 rjava control: affects 1066403 rapache control: affects 1066403 littler control: affects 1066403 rpy2 control: retitle 1066403 r-base-dev: missing dependency on libtirpc-dev Hi Dirk, There are 4 r-base packages failing to build in the latest archive rebuild: #1066403 rjava: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066452 rapache: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066455 littler: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066456 rpy2: FTBFS: ld: cannot find -ltirpc: No such file or directory Investigating, it appears that the issue is actually at the r-base level. They try to link with -ltirpc because R tell them to do so: $ R CMD config --ldflags -Wl,--export-dynamic -fopenmp -Wl,-z,relro -L/usr/lib/R/lib -lR -lpcre2-8 -llzma -lbz2 -lz -ltirpc -lrt -ldl -lm -licuuc -licui18n Therefore it seems that r-base-dev is missing a dependency on libtirpc-dev. Sorry for not having noticed that when filling #1065216. Regards Aurelien
Bug#1066422: packages using dcmtk failing to build with missing -lnsl are actually an issue in dcmtk
control: reassign 1066422 libdcmtk-dev control: reassign 1066423 libdcmtk-dev control: forcemerge 1066422 1066423 control: retitle 1066422 libdcmtk-dev: missing dependency on libnsl-dev control: affects 1066422 plastimatch control: affects 1066423 sight Hi, There are 2 packages using dcmtk failing to build in the latest archive rebuild: #1066422 plastimatch: FTBFS: ld: cannot find -lnsl: No such file or directory #1066423 sight: FTBFS: ld.gold: error: cannot find -lnsl Investigating, it appears that the issue is actually at the dcmtk package level. They try to link with -lnsl because dcmtk says so: $ grep nsl /usr/lib/x86_64-linux-gnu/cmake/dcmtk/DCMTKTargets.cmake INTERFACE_LINK_LIBRARIES "DCMTK::config;nsl;pthread;rt" dcmtk actually does not depends on libnsl-dev, but gets this dependency through the libwrap0-dev package. Therefore it seems that libdcmtk-dev is missing a dependency on libnsl-dev. In addition it might be good to add it as a build-dependency of the dcmtk package, to ensure it continues building even if libwrap0-dev drops it at some point. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066117: FTBFS: missing build-dep on libnsl-dev
Hi, On 2024-03-12 23:22, Preuße, Hilmar wrote: > On 12.03.2024 21:59, Aurelien Jarno wrote: > > Hi Aurelien, > > > Starting with glibc 2.31, support for NIS (libnsl library) has been > > moved to a separate libnsl2 package. In order to allow a smooth > > transition, a libnsl-dev has been added to the libc6-dev package. > > > > This dependency has been temporarily dropped in the 2.37-15.1 NMU, as > > part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in > > sid with: > > > I've seen the issue, but I wasn't sure if I have to do something or if I > have just have to wait until the dep change has been reverted. Let me > know if I should upload a fixed package w/ the BD added. Yes, please upload a package with the extra BD. The time_t transition takes longer than expected, and proftpd-dfsg is part of the transition. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066117: FTBFS: missing build-dep on libnsl-dev
Source: proftpd-dfsg Version: 1.3.8.b+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libnsl-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev has been added to the libc6-dev package. This dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in sid with: | /bin/bash ../libtool --mode=compile --tag=CC gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat -Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c | libtool: compile: gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat -Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c -fPIC -DPIC -o .libs/mod_wrap2_file.o | gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/src=. -fstack-protector-strong -Wformat -Werror=format-security -c trace.c | /bin/bash ../libtool --mode=link --tag=CC gcc -o mod_wrap.la -rpath /usr/lib/proftpd -Wl,-L../lib,-L../lib -Wl,-z,relro -Wl,-z,now -rdynamic -L/usr/lib/i386-linux-gnu/ -L/usr/lib/i386-linux-gnu -Wl,-z,relro -Wl,-z,now -avoid-version -export-dynamic -module -lidn2 -lsodium mod_wrap.lo `cat ../modules/mod_wrap.c | grep '$Libraries:' | sed -e 's/^.*\$Libraries: \(.*\)\\$/\1/'` | libtool: link: gcc -shared .libs/mod_wrap.o -L/usr/lib/i386-linux-gnu/ -L/usr/lib/i386-linux-gnu -lidn2 -lsodium -lwrap -lnsl -Wl,-L../lib -Wl,-L../lib -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,mod_wrap.so -o .libs/mod_wrap.so | /usr/bin/ld: cannot find -lnsl: No such file or directory | collect2: error: ld returned 1 exit status | make[3]: *** [Makefile:34: mod_wrap.la] Error 1 | make[3]: *** Waiting for unfinished jobs The full build log can be found here: https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg=i386=1.3.8.b%2Bdfsg-1%2Bb2=1710157209=0 This can be fixed by adding an explicit Build-Depends on libnsl-dev. Regards Aurelien
Bug#1065210: fricas: missing build-dep on libtirpc-dev or libtirpc-dev dependency in gcl
Hi, On 2024-03-10 11:20, Camm Maguire wrote: > Greetings! For now I am adding a libnsl-dev dependency to the gcl > package to restore the old behavior. A small fix to the fricas package > will eventually make this obsolete. You probably want to add a libtirpc-dev dependency instead, libnsl-dev is what was only ensuring that libtirpc-dev is installed. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'
Source: weston Version: 13.0.0-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, weston fails to build in unstable since the upload of neatvnc in version 8.0. From my build log on amd64: | Determining dependency 'neatvnc' with pkg-config executable '/usr/bin/pkg-config' | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --modversion neatvnc` -> 0 | stdout: | 0.8.0 | --- | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --cflags neatvnc` -> 0 | stdout: | -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/p11-kit-1 -I/usr/include/x86_64-linux-gnu | --- | env[PKG_CONFIG_ALLOW_SYSTEM_LIBS]: 1 | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --libs neatvnc` -> 0 | stdout: | -L/usr/lib/x86_64-linux-gnu -lneatvnc | --- | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --libs neatvnc` -> 0 | stdout: | -lneatvnc | --- | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0' | CMake binary for host machine is cached as not found | CMake binary for machine host machine not found. Giving up. | Run-time dependency neatvnc found: NO (tried pkgconfig and cmake) | Looking for a fallback subproject for the dependency neatvnc | Automatic wrap-based subproject downloading is disabled | Subproject neatvnc is buildable: NO (disabling) | Dependency neatvnc from subproject neatvnc found: NO (subproject failed to configure) | | ../libweston/backend-vnc/meson.build:8:1: ERROR: Problem encountered: VNC backend requires neatvnc which was not found. Or, you can use '-Dbackend-vnc=false'. | dh_auto_configure: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 -Dbackend-rdp=true -Dbackend-vnc=true -Dscreenshare=true -Dsystemd=true returned exit code 1 | make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:44: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 A full build log is also available here: https://buildd.debian.org/status/fetch.php?pkg=weston=riscv64=13.0.0-4%2Bb2=1710049432=0 Regards Aurelien
Bug#1065368: golang-1.22: unsupported obj reloc 62 (R_RISCV_CALL)/8 on riscv64
Source: golang-1.22 Version: 1.22.0-2 Severity: normal Tags: upstream patch fixed-upstream User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Control: forwarded -1 https://github.com/golang/go/commit/b5a64ba62eafe5dee13562091ca03aef6cac87b6 Dear maintainer, Thanks for packaging golang 1.22. Unfortunately this version has a small issue on riscv64 preventing other packages like hugo to be built [1]. Fortunately the issue has already been fixed upstream with a very simple patch [2]. There is a plan to backport this change to the 1.22 branch [3]. In the meantime would it be possible to include this patch in the Debian package? I have verified that it applies cleanly and fixes the problem. Thanks in advance. Regards Aurelien [1] https://buildd.debian.org/status/fetch.php?pkg=hugo=riscv64=0.123.7-1=1709330897=0 [2] https://github.com/golang/go/commit/b5a64ba62eafe5dee13562091ca03aef6cac87b6 [3] https://github.com/golang/go/issues/66060
Bug#1065366: python3-stdlib-extensions: uninstallable, depends on unavailable python3:any (>= 3.11.8-1~)
Source: python3-stdlib-extensions Version: 3.12.2-1 Severity: serious Dear maintainer, python3-distutils and python3-lib2to3 version 3.12.2-1 depend on python3:any (>= 3.11.8-1~). However python3 (provided by python3-defaults) is only at version 3.11.6-1, making python3-distutils and python3-lib2to3 uninstallable: | apt install python3-lib2to3 python3-distutils | Reading package lists... Done | Building dependency tree... Done | Reading state information... 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: | python3-distutils : Depends: python3:any (>= 3.11.8-1~) | python3-lib2to3 : Depends: python3:any (>= 3.11.8-1~) | E: Unable to correct problems, you have held broken packages. Regards Aurelien
Bug#1065330: numpy_1.26.3-2_ppc64el-buildd.changes REJECTED
Source: numpy Version: 1.26.3-2 Severity: serious On 2024-03-02 22:06, Debian FTP Masters wrote: > > > python3-numpy_1.26.3-2_ppc64el.deb: has 876 file(s) with a timestamp too far > in the past: > usr/lib/python3/dist-packages/numpy/LICENSE.txt (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/__init__.cython-30.pxd (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.pxd (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.pyi (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/__init__.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/_dtype.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_core/_dtype_ctypes.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/_internal.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_core/_multiarray_umath.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/multiarray.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/umath.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_distributor_init.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_globals.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_pyinstaller/__init__.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/hook-numpy.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/pyinstaller-smoke.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/test_pyinstaller.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_pytesttester.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_pytesttester.pyi > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/__init__.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_typing/_add_docstring.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_array_like.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_callable.pyi (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_char_codes.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_dtype_like.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_extended_precision.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_nbit.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_nested_sequence.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_scalars.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_shape.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_ufunc.pyi (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_typing/setup.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/__init__.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_utils/_convertions.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/_inspect.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/_pep440.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/__init__.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_array_object.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/array_api/_constants.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_creation_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_data_type_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_dtypes.py (Thu Jan 1 00:00:00 > 1970) > usr/lib/python3/dist-packages/numpy/array_api/_elementwise_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_indexing_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_manipulation_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_searching_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_set_functions.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_sorting_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_statistical_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_typing.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/array_api/_utility_functions.py > (Thu Jan 1 00:00:00 1970) >
Bug#1036884: 64-bit time_t: libpam0g -> libpam0t64 -> libpam0g
m0g-dev (>= 1.5.3-6)" wb nmu openvpn_2.6.9-1 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu openvpn_2.6.9-1 . s390x . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pacemaker_2.1.6-4.1 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pappl_1.3.1-2.1 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . amd64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . arm64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . i386 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . mips64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . ppc64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu pgpool2_4.3.7-2 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu rust-pleaser_0.5.4-2 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu snapper_0.10.6-1.1 . arm64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu snapper_0.10.6-1.1 . i386 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu snapper_0.10.6-1.1 . mips64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu snapper_0.10.6-1.1 . ppc64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu sssd_2.9.4-1.1 . i386 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . amd64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . arm64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . i386 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . mips64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . ppc64el . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . riscv64 . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" wb nmu wvstreams_4.6.1-17.1 . s390x . -m "Rebuild against libpam0g" . --extra-depends "libpam0g-dev (>= 1.5.3-6)" -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1065290: libhdf4: missing build-dep on libtirpc-dev
Source: libhdf4
Version: 4.2.16-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-dev
Dear maintainer,
Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev, which depends on libtirpc-dev, has been added
to the libc6-dev package.
The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1
NMU, as part of the 64-bit time_t transition. This causes libhdf4 to
FTBFS in sid with:
| dh_auto_configure --sourcedirectory=HDF4 \
| --builddirectory=debian/build-hdf4 \
| -- --prefix=/usr \
| --includedir=/usr/include/hdf \
| --libdir=/usr/lib \
| --enable-shared \
| --enable-fortran \
| --with-szlib=yes \
| F77="gfortran" CC="gcc" CXX="g++" \
| CFLAGS="-g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/" LDFLAGS="-Wl,-z,relro -Wl,-z,now -ltirpc"
| cd debian/build-hdf4 && ../../HDF4.2.16/configure
--build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc
--localstatedir=/var --disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--includedir=/usr/include/hdf --libdir=/usr/lib --enable-shared
--enable-fortran --with-szlib=yes F77=gfortran CC=gcc CXX=g\+\+ "CFLAGS=-g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/tirpc/" "LDFLAGS=-Wl,-z,relro
-Wl,-z,now -ltirpc"
| checking for a BSD-compatible install... /usr/bin/install -c
| checking whether build environment is sane... yes
| checking for a race-free mkdir -p... /usr/bin/mkdir -p
| checking for gawk... no
| checking for mawk... mawk
| checking whether make sets $(MAKE)... yes
| checking whether make supports nested variables... yes
| checking whether make supports nested variables... (cached) yes
| checking whether to enable maintainer-specific portions of Makefiles... no
| checking shell variables initial values... done
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pc-linux-gnu
| checking if basename works... yes
| checking if xargs works... yes
| checking for config x86_64-pc-linux-gnu... no
| checking for config x86_64-pc-linux-gnu... no
| checking for config pc-linux-gnu... no
| checking for config pc-linux-gnu... no
| checking for config x86_64-linux-gnu... no
| checking for config x86_64-linux-gnu... no
| checking for config x86_64-pc... no
| checking for config linux-gnu... found
| compiler 'gcc' is GNU gcc-13.2.0
| gfortran: error: unrecognized command-line option '-V'
| gfortran: fatal error: no input files
| compilation terminated.
| ../../HDF4.2.16/config/gnu-fflags: line 66: test: -ge: unary operator expected
| checking whether make sets $(MAKE)... (cached) yes
| checking for gcc... gcc
| checking whether the C compiler works... no
| configure: error: in `/<>/debian/build-hdf4':
| configure: error: C compiler cannot create executables
| See `config.log' for more details
| cd debian/build-hdf4 && tail -v -n \+0 config.log
| ==> config.log <==
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
...
| configure:4337: checking whether the C compiler works
| configure:4359: gcc -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/ -std=c99 -Wall -Wcast-qual -Wconversion -Wextra
-Wfloat-equal -Wformat=2 -Winit-self -Winvalid-pch -Wmissing-include-dirs
-Wshadow -Wundef -Wwrite-strings -pedantic -Wno-c++-compat
-Wno-error=implicit-function-declaration -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/ -Wl,-z,relro -Wl,-z,now -ltirpc conftest.c >&5
| cc1: warning: /usr/include/tirpc/: No such file or directory
[-Wmissing-include-dirs]
| cc1: warning: /usr/include/tirpc/: No such file or directory
[-Wmissing-include-dirs]
| /usr/bin/ld: cannot find -ltirpc: No such file or directory
| collect2: error: ld returned 1 exit status
| configure:4363: $? = 1
| configure:4403: result: no
| configure: failed program was:
| | /* confdefs.h */
| | #define PACKAGE_NAME "HDF"
| | #define PACKAGE_TARNAME "hdf"
| | #define PACKAGE_VERSION "4.2.16"
| | #define PACKAGE_STRING "HDF 4.2.16"
| | #define
Bug#1065289: mysql-8.0: missing build-dep on libtirpc-dev
Source: mysql-8.0 Version: 8.0.36-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes mysql-8.0 to FTBFS in sid with: | -- MECAB_INCLUDE_DIR = /usr/include | -- MECAB_LIBRARY = /usr/lib/x86_64-linux-gnu/libmecab.so | -- Found PkgConfig: /bin/pkg-config (found version "1.8.1") | -- Checking for module 'libtirpc' | -- Package 'libtirpc', required by 'virtual:world', not found | CMake Warning at cmake/rpc.cmake:40 (MESSAGE): | Cannot find RPC development libraries. You need to install the required | packages: | | Debian/Ubuntu: apt install libtirpc-dev | RedHat/Fedora/Oracle Linux: yum install libtirpc-devel | SuSE: zypper install glibc-devel | | Call Stack (most recent call first): | cmake/rpc.cmake:96 (WARN_MISSING_SYSTEM_TIRPC) | plugin/group_replication/libmysqlgcs/cmake/configure.cmake:34 (MYSQL_CHECK_RPC) | plugin/group_replication/libmysqlgcs/CMakeLists.txt:31 (INCLUDE) | | | CMake Error at cmake/rpc.cmake:97 (MESSAGE): | Could not find rpc/rpc.h in /usr/include or /usr/include/tirpc | Call Stack (most recent call first): | plugin/group_replication/libmysqlgcs/cmake/configure.cmake:34 (MYSQL_CHECK_RPC) | plugin/group_replication/libmysqlgcs/CMakeLists.txt:31 (INCLUDE) | | | -- Configuring incomplete, errors occurred! | make[1]: *** [debian/rules:80: configure-stamp] Error 1 | make[1]: Leaving directory '/home/aurel32/work/glibc/libnsl/packages/mysql-8.0-8.0.36' | make: *** [debian/rules:230: build-arch] Error 2 | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 This can be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065283: lsof: recent libc6-dev change causes the RPC support to be dropped
Package: lsof Version: 4.95.0-1 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes the RPC support in lsof to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly so that this feature does not depend on the packages installed on the system. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065282: dsniff: missing build-dep on libtirpc-dev
Source: dsniff
Version: 2.4b1+debian-31
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-dev
Dear maintainer,
Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev, which depends on libtirpc-dev, has been added
to the libc6-dev package.
The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1
NMU, as part of the 64-bit time_t transition. This causes dsniff to
FTBFS in sid with:
|dh_auto_configure
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking
| checking for gcc... gcc
| checking whether the C compiler works... no
| configure: error: in `/<>':
| configure: error: C compiler cannot create executables
| See `config.log' for more details
| tail -v -n \+0 config.log
| ==> config.log <==
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
...
| configure:3051: checking whether the C compiler works
| configure:3073: gcc -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -I/usr/include/tirpc/ -Wdate-time
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -ltirpc conftest.c >&5
| /usr/bin/ld: cannot find -ltirpc: No such file or directory
| collect2: error: ld returned 1 exit status
| configure:3077: $? = 1
| configure:3117: result: no
| configure: failed program was:
| | /* confdefs.h */
| | #define PACKAGE_NAME ""
| | #define PACKAGE_TARNAME ""
| | #define PACKAGE_VERSION ""
| | #define PACKAGE_STRING ""
| | #define PACKAGE_BUGREPORT ""
| | #define PACKAGE_URL ""
| | /* end confdefs.h. */
| |
| | int
| | main (void)
| | {
| |
| | ;
| | return 0;
| | }
| configure:3122: error: in `/<>':
| configure:3124: error: C compiler cannot create executables
| See `config.log' for more details
This can be fixed by adding an explicit Build-Depends on libtirpc-dev.
The glibc change will likely be reverted in the short term, but given
its a change we want to do for Trixie, this will only lower the severity
of the bug.
Regards
Aurelien
Bug#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped
Hi Hilmar, On 2024-03-02 00:19, Preuße, Hilmar wrote: > On 01.03.2024 23:33, Aurelien Jarno wrote: > > Hi Aurelien, > > > This can be fixed by adding an explicit Build-Depends on > > libtirpc-dev. The glibc change will likely be reverted in the short > > term, but given its a change we want to do for Trixie, this will only > > lower the severity of the bug. > > > I do not fully understand, what needs to be done from my side: add a BD on > libtirpc-dev and (maybe) remove it later on? If you say the change will be > reverted later, I'd guess one can rather wait for that point in time and > then request an binNMU (or wait until anybody triggers a mass binNMU). What > do I miss? Sorry if i was not very clear, all of those bug filling was done in emergency and was not really planned. Asymptote needs libtirpc-dev to build with the proper features, so you need to add it as a build-depends, to avoid side effects of dependency changes in other packages. You do not need to remove it at any point. In the long term, we will definitely drop the libtirpc-dev dependency in libc6-dev. The plan is to do it for Trixie if possible, but we don't know when this is going to happen, this release cycle is really chaotic. We might also not even revert the temporary change if all packages are fixed before the time_t transition is finished. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1065216: r-base: recent libc6-dev change causes the xdr feature to be dropped
Source: r-base Version: 4.3.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes the xdr feature of r-base to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the xdr feature support explicitly so that it does not depend on the packages installed on the system. Regards Aurelien
Bug#1065215: xinetd: recent libc6-dev change causes the RPC support to be dropped
Source: xinetd Version: 1:2.3.15.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1i NMU, as part of the 64-bit time_t transition. This causes the RPC support of xinetd to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly using --with-rpc=no, so that this feature does not depend on the packages installed on the system. Regards Aurelien
Bug#1065213: dovecot: recent libc6-dev change causes the rquota feature to be dropped
Source: dovecot Version: 1:2.3.21+dfsg1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes the rquota feature of dovecot to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the rquota feature explicitly so that it does not depend on the packages installed on the system. Regards Aurelien
Bug#1065214: iproute2: recent libc6-dev change causes the RPC support to be dropped
Package: iproute2 Version: 6.7.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes the RPC support in iproute2 (from misc/ss.c) to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly using --without-rpc so that this feature does not depend on the packages installed on the system. Regards Aurelien
Bug#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped
Source: asymptote Version: 2.86+ds1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes XDR and V3D support in asymptote to be dropped, something which is not recommended by upstream. This can be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065208: gcl: recent libc6-dev change causes XDR support to be dropped
On 2024-03-01 22:10, Aurelien Jarno wrote: > Source: gcl > Version: 2.6.14-6 > Severity: serious > User: debian-gl...@lists.debian.org > Usertags: libtirpc-dev > > Dear maintainer, > > Starting with glibc 2.31, support for NIS (libnsl library) has been > moved to a separate libnsl2 package. In order to allow a smooth > transition, a libnsl-dev, which depends on libtirpc-dev, has been added > to the libc6-dev package. > > The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 > NMU, as part of the 64-bit time_t transition. This causes gcl to disable > the XDR support. Not fully sure what are the consequences, but it seems > at least axiom requires XDR support. > > Therefore please either: > - Add libnsl-dev as build dependency Sorry that was a thinko. I meant libtirpc-dev. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065207: gcl27: recent libc6-dev change causes XDR support to be dropped
On 2024-03-01 22:10, Aurelien Jarno wrote: > Source: gcl27 > Version: 2.7.0-20 > Severity: serious > User: debian-gl...@lists.debian.org > Usertags: libtirpc-dev > > Dear maintainer, > > Starting with glibc 2.31, support for NIS (libnsl library) has been > moved to a separate libnsl2 package. In order to allow a smooth > transition, a libnsl-dev, which depends on libtirpc-dev, has been added > to the libc6-dev package. > > The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 > NMU, as part of the 64-bit time_t transition. This causes gcl27 to > disable the XDR support. Not fully sure what are the consequences. > > Therefore please either: > - Add libnsl-dev as build dependency Sorry that was a thinko. I meant libtirpc-dev. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065210: fricas: missing build-dep on libtirpc-dev or libtirpc-dev dependency in gcl
Source: fricas Version: 1.3.10-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes fricas to FTBFS in sid with: | End of Pass 1. | End of Pass 2. | OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 | Finished compiling /<>/src/lisp/primitives.o. | #p"/<>/src/lisp/primitives.o" | NIL | NIL | | >echo '(compiler::link nil "prelisp" ' \ | ' (format nil "(progn (let ((SI::*load-path*' \ | ' (cons ~S SI::*load-path*))' \ | ' (si::*load-types* ~S))' \ |' (compiler::emit-fn t))' \ | ' (when (fboundp (quote si::sgc-on))' \ | ' (si::sgc-on nil))' \ | ' (setq compiler::*default-system-p* nil))' \ | ' (setq compiler::*default-large-memory-model-p* t))"' \ | ' si::*system-directory* (quote (list ".lsp")))' \ |' "/<>/src/lib/bsdsignal.o /<>/src/lib/cfuns-c.o /<>/src/lib/sockio-c.o ")' \ | | gcl | GCL (GNU Common Lisp) 2.6.14 Fri Jan 13 10:47:56 AM EST 2023 ANSIgit: Version_2_6_15pre5 | Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) | Binary License: GPL due to GPL'ed components: (XGCL UNEXEC) | Modifications of this banner must retain notice of a compatible license | Dedicated to the memory of W. Schelter | | Use (help) to get some basic information on how to use GCL. | Temporary directory for compiler files: | /tmp/ | | >/usr/bin/ld: cannot find -ltirpc: No such file or directory | collect2: error: ld returned 1 exit status | | Correctable error: | Fast links are on: do (si::use-fast-links nil) for debugging | Signalled by COMPILER::LINK. | If continued: Continues anyway. | SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc -Wl,-z,relro -no-pie -Wl,-T,../unixport/gcl.script -o /<>/src/lisp/raw_prelisp user-init.o -L/usr/lib/gcl-2.6.14/unixport/ -Wl,-Map /<>/src/lisp/raw_prelisp_map /<>/src/lib/bsdsignal.o /<>/src/lib/cfuns-c.o /<>/src/lib/sockio-c.o -lansi_gcl -lX11 -lm -ldl -lgmp -ltirpc -lreadline -lc -lgclp") returned a non-zero value 1 0. | | Broken at COMPILER::LINK. Type :H for Help. | 1 (continue) Continues anyway. | 2 Return to top level. | >>make[3]: *** [Makefile:250: do_it.gcl] Error 255 | make[3]: Leaving directory '/<>/src/lisp' | make[2]: *** [Makefile:231: all-lisp] Error 2 | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:251: all-src] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:43: build-stamp] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 One way to fix that would be to add an explicit Build-Depends on libtirpc-dev. That said I could not find any reference to tirpc in the fricas package, so I wonder if the right change is actually to add a libtirpc-dev dependency to the gcl binary package. You probably know that better than me, so please use the best option and feel free to reassign the bug to the right package. Regards Aurelien
Bug#1065208: gcl: recent libc6-dev change causes XDR support to be dropped
Source: gcl Version: 2.6.14-6 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes gcl to disable the XDR support. Not fully sure what are the consequences, but it seems at least axiom requires XDR support. Therefore please either: - Add libnsl-dev as build dependency - Disable XDR support explicitly with --disable-xdr so that this feature does not depend on the packages installed on the system. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065207: gcl27: recent libc6-dev change causes XDR support to be dropped
Source: gcl27 Version: 2.7.0-20 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes gcl27 to disable the XDR support. Not fully sure what are the consequences. Therefore please either: - Add libnsl-dev as build dependency - Disable XDR support explicitly with --disable-xdr so that this feature does not depend on the packages installed on the system. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065188: [Pkg-samba-maint] Bug#1065188: samba: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
control: notfound -1 samba/2:12.3.5-4 control: found -1 samba/2:4.19.5+dfsg-2 On 2024-03-01 20:26, Michael Tokarev wrote: > 01.03.2024 19:05, Aurelien Jarno : > > Source: samba > > Version: 2:12.3.5-4 > > Is it really 12.3.5-4? :) Oops, sorry about that. I probably mixed packages when reporting the bug :( -ETOOMANYBUGS. Fixing that with this mail. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065190: ogdi-dfsg: missing build-dep on libtirpc-dev
Source: ogdi-dfsg Version: 4.1.1+ds-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes ogdi-dfsg to FTBFS in sid with: | checking for string.h... yes | checking for inttypes.h... yes | checking for stdint.h... yes | checking for strings.h... yes | checking for sys/stat.h... yes | checking for sys/types.h... yes | checking for unistd.h... yes | checking for rpc/rpc.h... no | checking for libtirpc... no | configure: error: Package requirements (libtirpc) were not met: | | Package 'libtirpc', required by 'virtual:world', not found | | Consider adjusting the PKG_CONFIG_PATH environment variable if you | installed software in a non-standard prefix. | | Alternatively, you may set the environment variables RPC_CFLAGS | and RPC_LIBS to avoid the need to call pkg-config. | See the pkg-config man page for more details. | tail -v -n \+0 config.log This can be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065189: libguestfs: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: libguestfs Version: 1:1.52.0-2.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes libguestfs to FTBFS in sid with: | checking for CFLocaleCopyPreferredLanguages... no | checking for GNU gettext in libc... yes | checking whether to use NLS... yes | checking where the gettext function comes from... libc | checking if the user specified a default backend... direct | checking for dlopen in -ldl... yes | checking for dlfcn.h... (cached) yes | checking for libtirpc... no | checking for rpc/xdr.h... no | configure: error: XDR header files are required | cd debian/build-1 && tail -v -n \+0 config.log This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. I also noticed that libguestfs, uses rpcgen, provided by the rpcsvc-proto during the build process. It is currently a dependency of the libc6-dev package for the same reason as libnsl-dev, and will be removed at some point. Therefore please also add an explicit Build-Depends on rpcsvc-proto. Regards Aurelien
Bug#1065188: samba: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: samba Version: 2:12.3.5-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes samba to FTBFS in sid with: | [4938/6301] Compiling ctdb/utils/smnotify/smnotify.c | 13:58:50 runner ['x86_64-linux-gnu-gcc', '-D_SAMBA_BUILD_=4', '-DHAVE_CONFIG_H=1', '-g', '-O2', '-ffile-prefix-map=/<>=.', '-fstack-protector-strong', '-fstack-clash-protection', '-Wformat', '-Werror=format-security', '-fcf-protection', '-ffile-prefix-map=../../=', '-MMD', '-D_GNU_SOURCE=1', '-D_XOPEN_SOURCE_EXTENDED=1', '-DHAVE_CONFIG_H=1', '-fPIE', '-fPIC', '-D__STDC_WANT_LIB_EXT1__=1', '-D_REENTRANT', '-DCTDB_HELPER_BINDIR="/usr/libexec/ctdb"', '-DLOGDIR="/var/log/ctdb"', '-DCTDB_DATADIR="/usr/share/ctdb"', '-DCTDB_ETCDIR="/etc/ctdb"', '-DCTDB_VARDIR="/var/lib/ctdb"', '-DCTDB_RUNDIR="/run/ctdb"', '-fstack-protector-strong', '-fstack-clash-protection', '-DSTATIC_smnotify_MODULES=NULL', '-DSTATIC_smnotify_MODULES_PROTO=extern void __smnotify_dummy_module_proto(void)', '-Ictdb', '-I../../ctdb', '-Ictdb/utils', '-I../../ctdb/utils', '-Ictdb/utils/smnotify', '-I../../ctdb/utils/smnotify', '-Iinclude/public', '-I../../include/public', '-Isource4', '-I../../source4', '-Ilib', '-I../../lib', '-Isource4/lib', '-I../../source4/lib', '-Isource4/include', '-I../../source4/include', '-Iinclude', '-I../../include', '-Ilib/replace', '-I../../lib/replace', '-Ictdb/include', '-I../../ctdb/include', '-I.', '-I../..', '../../ctdb/utils/smnotify/smnotify.c', '-c', '-o/<>/bin/default/ctdb/utils/smnotify/smnotify.c.54.o', '-Wdate-time', '-D_FORTIFY_SOURCE=2'] | [4939/6301] Linking bin/default/ctdb/ctdb_takeover_helper.inst | 13:58:50 runner ['x86_64-linux-gnu-gcc', '-Wl,--as-needed', 'ctdb/protocol/protocol_header.c.7.o', 'ctdb/protocol/protocol_packet.c.7.o', 'ctdb/protocol/protocol_types.c.7.o', 'ctdb/protocol/protocol_call.c.7.o', 'ctdb/protocol/protocol_message.c.7.o', 'ctdb/protocol/protocol_control.c.7.o', 'ctdb/protocol/protocol_keepalive.c.7.o', 'ctdb/protocol/protocol_tunnel.c.7.o', 'ctdb/protocol/protocol_client.c.7.o', 'ctdb/protocol/protocol_debug.c.7.o', 'ctdb/protocol/protocol_sock.c.7.o', 'ctdb/server/ipalloc_deterministic.c.11.o', 'ctdb/server/ipalloc_nondeterministic.c.11.o', 'ctdb/server/ipalloc_lcp2.c.11.o', 'ctdb/server/ipalloc_common.c.11.o', 'ctdb/server/ipalloc.c.11.o', 'ctdb/protocol/protocol_basic.c.6.o', 'ctdb/server/ctdb_takeover_helper.c.47.o', 'ctdb/common/cmdline.c.4.o', 'ctdb/common/comm.c.4.o', 'ctdb/common/conf.c.4.o', 'ctdb/common/db_hash.c.4.o', 'ctdb/common/event_script.c.4.o', 'ctdb/common/hash_count.c.4.o', 'ctdb/common/line.c.4.o', 'ctdb/common/logging.c.4.o', 'ctdb/common/path.c.4.o', 'ctdb/common/pidfile.c.4.o', 'ctdb/common/pkt_read.c.4.o', 'ctdb/common/pkt_write.c.4.o', 'ctdb/common/rb_tree.c.4.o', 'ctdb/common/reqid.c.4.o', 'ctdb/common/run_event.c.4.o', 'ctdb/common/run_proc.c.4.o', 'ctdb/common/sock_client.c.4.o', 'ctdb/common/srvid.c.4.o', 'ctdb/common/tmon.c.4.o', 'ctdb/common/tunable.c.4.o', 'lib/async_req/async_sock.c.1.o', 'ctdb/protocol/protocol_util.c.8.o', 'ctdb/client/client_connect.c.9.o', 'ctdb/client/client_call.c.9.o', 'ctdb/client/client_message.c.9.o', 'ctdb/client/client_control.c.9.o', 'ctdb/client/client_message_sync.c.9.o', 'ctdb/client/client_control_sync.c.9.o', 'ctdb/client/client_db.c.9.o', 'ctdb/client/client_util.c.9.o', 'ctdb/client/client_tunnel.c.9.o', '-o/<>/bin/default/ctdb/ctdb_takeover_helper.inst', '-Wl,-rpath,/usr/lib/x86_64-linux-gnu/samba', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/<>/bin/default/libcli/util', '-L/<>/bin/default/lib/tdb_wrap', '-L/<>/bin/default/lib/util', '-L/<>/bin/default/lib/replace', '-L/usr/local/lib', '-L/usr/local/lib', '-lreplace-samba4', '-lsocket-blocking-samba4', '-lsys-rw-samba4', '-lsamba-util', '-liov-buf-samba4', '-ltdb-wrap-samba4', '-ltevent-util', '-lutil-setid-samba4', '-ltime-basic-samba4', '-lgenrand-samba4', '-lsamba-debug-samba4', '-lsamba-errors', '-licuuc', '-licui18n', '-licudata', '-lsystemd', '-lgnutls', '-lpopt', '-lbsd', '-ltevent', '-ltalloc', '-ltdb', '-ltalloc', '-Wl,-z,relro', '-Wl,-z,now', '-pie', '-Wl,-z,relro,-z,now', '-Wl,-no-undefined', '-Wl,--export-dynamic'] | In file included from ../../ctdb/utils/smnotify/smnotify.c:27: | ctdb/utils/smnotify/smnotify.h:9:10: fatal error: rpc/rpc.h: No such file or directory | 9 | #include | | ^~~ | compilation terminated. This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change
Bug#1065187: open-vm-tools: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: open-vm-tools Version: 2:12.3.5-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes open-vm-tools to FTBFS in sid with: | checking for gtkmm-3.0 >= 3.0.0 (via pkg-config)... yes | checking for sigc++-2.0 >= 2.5.1 (via pkg-config)... yes | checking for crypt in -lcrypt... yes | checking for dlopen... yes | checking for ecvt... yes | checking for fcvt... yes | checking for mkdtemp... yes | checking for pthread_mutex_init in -lpthread... yes | checking for g++... yes | checking for libtirpc (via pkg-config)... no | configure: tirpc is needed: yes | configure: error: cannot find libtirpc but it is required. | cd open-vm-tools && tail -v -n \+0 config.log This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. I also noticed that open-vm-tools, uses rpcgen, provided by the rpcsvc-proto during the build process. It is currently a depends of the libc6-dev package for the same reason as libnsl-dev, and will be removed at some point. Therefore please also add an explicit Build-Depends on rpcsvc-proto. Regards Aurelien
Bug#1065186: caml-crush: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: caml-crush Version: 1.0.12-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes caml-crush to FTBFS in sid with: | checking for gawk... no | checking for mawk... mawk | checking for camlidl... yes | checking for spatch... yes | Detected coccinelle version 1.1.1 | configure: Using default C based client and RPC | checking for getnetname in -ltirpc... no | configure: Using the glibc RPC implementation | checking for rpc/rpc.h... no | configure: error: Could not find C RPC headers. | cd build-SERVER && tail -v -n \+0 config.log This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. I also noticed that caml-crush, uses rpcgen, provided by the rpcsvc-proto during the build process. It is currently a dependency of the libc6-dev package for the same reason as libnsl-dev, and will be removed at some point. Therefore please also add an explicit Build-Depends on rpcsvc-proto. Regards Aurelien
Bug#1065185: zfs-fuse: missing build-dep on libtirpc-dev
Source: zfs-fuse Version: 0.7.0-26 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes zfs-fuse to FTBFS in sid with: | gcc -o lib/libnvpair/build-user/nvpair.o -c -pipe -Wall -std=c99 -Wno-switch -Wno-unused -Wno-missing-braces -Wno-parentheses -Wno-uninitialized -fno-strict-aliasing -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DTEXT_DOMAIN=\"zfs-fuse\" -ggdb -DNDEBUG -O2 -DLINUX_AIO -Ilib/libnvpair/include -Ilib/libsolcompat/include -I/usr/include/tirpc lib/libnvpair/nvpair.c | lib/libnvpair/nvpair.c:33:10: fatal error: rpc/types.h: No such file or directory |33 | #include | | ^ | compilation terminated. | scons: *** [lib/libnvpair/build-user/nvpair.o] Error 1 | scons: building terminated because of errors. | make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:38: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065184: xwayland: missing build-dep on libtirpc-dev
Package: xwayland Version: 2:23.2.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes xwayland to FTBFS in sid with: | Configuring version-config.h using configuration | Configuring xkb-config.h using configuration | Configuring xwayland-config.h using configuration | Run-time dependency glproto found: YES 1.4.17 | Run-time dependency gl found: YES 1.2 | Dependency glproto found: YES 1.4.17 (cached) | Dependency gl found: YES 1.2 (cached) | Run-time dependency libtirpc found: NO (tried pkgconfig and cmake) | Has header "rpc/rpc.h" : NO | | ../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, but neither libtirpc or libc RPC support were found | | A full log can be found at /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt | cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065183: python-fsquota: missing build-dep on libtirpc-dev
Source: python-fsquota
Version: 0.1.0+dfsg1-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-dev
Dear maintainer,
Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev, which depends on libtirpc-dev, has been added
to the libc6-dev package.
The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1
NMU, as part of the 64-bit time_t transition. This causes python-fsquota
to FTBFS in sid with:
|dh_auto_configure -O--buildsystem=pybuild
| pybuild --configure -i python{version} -p 3.11
| I: pybuild base:305: python3.11 setup.py config
| Using hints/linux.h for myconfig.h
| WARNING: Header file /usr/include/rpc/rpc.h not present on this system.
| Likely compilation will fail. Recommend to either install package
| "libtirpc-dev", or disable RPC (network file system) support by
| adding the following switch to myconfig.h:
| #define NO_RPC
|
| running config
|dh_auto_build -O--buildsystem=pybuild
| pybuild --build -i python{version} -p 3.11
| I: pybuild base:305: /usr/bin/python3 setup.py build
| Using hints/linux.h for myconfig.h
| WARNING: Header file /usr/include/rpc/rpc.h not present on this system.
| Likely compilation will fail. Recommend to either install package
| "libtirpc-dev", or disable RPC (network file system) support by
| adding the following switch to myconfig.h:
| #define NO_RPC
|
| running build
| running build_ext
| building 'FsQuota' extension
| creating build
| creating build/temp.linux-x86_64-cpython-311
| creating build/temp.linux-x86_64-cpython-311/src
| x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I. -I/usr/include/python3.11 -c
src/FsQuota.c -o build/temp.linux-x86_64-cpython-311/src/FsQuota.o
| In file included from src/FsQuota.c:18:
| ./myconfig.h:18:10: fatal error: rpc/rpc.h: No such file or directory
|18 | #include
| | ^~~
| compilation terminated.
| error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
| E: pybuild pybuild:391: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
| dh_auto_build: error: pybuild --build -i python{version} -p 3.11 returned
exit code 13
| make: *** [debian/rules:9: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
This could be fixed by adding an explicit Build-Depends on libtirpc-dev.
The glibc change will likely be reverted in the short term, but given
its a change we want to do for Trixie, this will only lower the severity
of the bug.
Regards
Aurelien
Bug#1065179: argus: missing build-dep on libtirpc-dev
Source: argus Version: 2:3.0.8.2-2.2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes argus to FTBFS in sid with: | checking for inet_aton... yes | checking for setlinebuf... yes | checking for strerror... yes | checking for strtof... yes | checking for floorf... no | checking for remainderf... no | checking for timegm... yes | checking for rpc_call in -ltirpc... no | configure: error: no tirpc library, exiting...! | tail -v -n \+0 config.log | ==> config.log <== This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065182: libquota-perl: missing build-dep on libtirpc-dev
Source: libquota-perl Version: 1.8.2+dfsg-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes libquota-perl to FTBFS in sid with: | x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -DVERSION=\"1.8.2\" -DXS_VERSION=\"1.8.2\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.38/CORE" linuxapi.c | In file included from linuxapi.c:13: | myconfig.h:18:10: fatal error: rpc/rpc.h: No such file or directory |18 | #include | | ^~~ | compilation terminated. | make[1]: *** [Makefile:345: linuxapi.o] Error 1 | make[1]: *** Waiting for unfinished jobs | mv Quota.xsc Quota.c | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:9: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
Bug#1065181: liblxi: missing build-dep on libtirpc-dev
Source: liblxi Version: 1.20-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-dev Dear maintainer, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev, which depends on libtirpc-dev, has been added to the libc6-dev package. The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes liblxi to FTBFS in sid with: | Found pkg-config: /usr/bin/pkg-config (1.8.1) | Run-time dependency avahi-client found: YES 0.8 | Run-time dependency libxml-2.0 found: YES 2.9.14 | Run-time dependency threads found: YES | Has header "avahi-client/client.h" : YES | Did not find CMake 'cmake' | Found CMake: NO | Run-time dependency libtirpc found: NO (tried pkgconfig) | | ../src/meson.build:30:14: ERROR: Dependency "libtirpc" not found, tried pkgconfig | | A full log can be found at /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt | cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien
