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#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#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#1070872: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1070872 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/cddca4c12be51d67d8f383b2ccf21b6335b61898 debian/patches/any/submitted-static-*.diff: add proposed patches to fix various missing math function in libm.a. Closes: #1070872. (this message was generated automatically) -- Greetings https://bugs.debian.org/1070872
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#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#1069191: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1069191 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/994a994014c13b43ffc4768a8969cc44045d7a67 debian/patches/git-updates.diff: update from upstream stable branch: * debian/patches/git-updates.diff: update from upstream stable branch: - Fix fix out-of-bound writes when writing escape sequence in iconv ISO-2022-CN-EXT module (CVE-2024-2961). Closes: #1069191. (this message was generated automatically) -- Greetings https://bugs.debian.org/1069191
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#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#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#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#1068737: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1068737 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/e4d86ee27cbefa6fa55f965c15b629170d60f302 debian/debhelper.in/locales.config: revert to the version that has been working for 20+ years. Closes: #1068737. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068737
Bug#1068251: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1068251 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/2aeb43031cb6bbcd1978c5329ffee010155c044f debian/rules.d/build.mk: present glibc with a compiler that does not default to -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64, as upstream doesn't support this configuration. This has the consequence of hiding real issues found by the testsuite, but there is a consensus that this is the way to go for now. Thanks to Helmut Grohne for the hint and starting the discussion. Closes: #1068251. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068251
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1065180: argus-clients: missing build-dep on libtirpc-dev
Source: argus-clients Version: 1:3.0.8.2-6.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-clients to FTBFS in sid with: | checking for strtof... (cached) yes | checking for srandomdev... no | checking for tzset... yes | checking for .threads... yes | checking for sched_get_priority_min... yes | checking for local tcp_wrappers library... not found | checking for system tcp_wrappers library... yes | checking for rpc_call in -ltirpc... no | configure: error: no tirpc library, exiting...! | 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. 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#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
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#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#1065165: autofs: recent libc6-dev change causes NIS support to be dropped
Source: autofs Version: 5.1.9-1 Severity: serious 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 autofs to be built without NIS support, which in practice means that the following modules are missing from the autofs package: /usr/lib/x86_64-linux-gnu/autofs/lookup_nisplus.so /usr/lib/x86_64-linux-gnu/autofs/lookup_yp.so /usr/lib/x86_64-linux-gnu/autofs/lookup_nis.so -> lookup_yp.so Please either: - Add libnsl-dev as build dependency - Disable NIS 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#1065162: yp-tools: FTBFS: missing build-dep on libnsl-dev
Source: yp-tools Version: 4.2.3-3 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 yp-tools to FTBFS in sid with: | gcc -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/include/tirpc -DLOCALEDIR=\"/usr/share/locale\" -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -D_REENTRANT=1 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o host2ypbind3_binding.o host2ypbind3_binding.c | yp_all_host.c:30:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |30 | #include | | ^ | compilation terminated. | make[3]: *** [Makefile:443: yp_all_host.o] Error 1 | make[3]: *** Waiting for unfinished jobs | make[3]: Leaving directory '/<>/lib' | make[2]: *** [Makefile:447: all-recursive] Error 1 | make[2]: Leaving directory '/<>' | make[1]: *** [Makefile:379: all] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:19: build] Error 25 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065163: ypserv: FTBFS: missing build-dep on libnsl-dev
Source: ypserv Version: 4.2-1.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 ypserv to FTBFS in sid with: | gcc -DHAVE_CONFIG_H -D_REENTRANT=1 -DCONFDIR=\"/etc\" -DYPMAPDIR=\"/var/yp\" -DUSE_SD_NOTIFY=1 -I. -I.. -I.. -I.. -I. -Wdate-time -D_FORTIFY_SOURCE=2 -fpie -I/usr/include/tirpc -Werror -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wno-error=format-truncation= -Wno-error=format-overflow= -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -c -o securenets.o securenets.c | In file included from ypproc_match_2.c:22: | yp.h:10:10: fatal error: rpcsvc/yp_prot.h: No such file or directory |10 | #include | | ^~ | compilation terminated. | gmake[3]: *** [Makefile:615: ypproc_match_2.o] Error 1 | gmake[3]: *** Waiting for unfinished jobs | gmake[3]: Leaving directory '/<>/lib' | gmake[2]: *** [Makefile:395: all-recursive] Error 1 | gmake[2]: Leaving directory '/<>' | make[1]: *** [Makefile:336: all] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:28: build] Error 25 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065161: udptunnel: FTBFS: missing build-dep on libnsl-dev
Source: udptunnel
Version: 1.1-10
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 udptunnel to FTBFS in
sid with:
| gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"udptunnel\" -DVERSION=\"1.1\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
-DHAVE_FCNTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_SHORT=2
-DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRTOL=1 -I. -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wall -c -o host2ip.o host2ip.c
| host2ip.c:7:10: fatal error: rpcsvc/ypclnt.h: No such file or directory
| 7 | #include/* YP */
| | ^
| compilation terminated.
| make[1]: *** [Makefile:379: host2ip.o] Error 1
| make[1]: *** Waiting for unfinished jobs
| udptunnel.c: In function ‘await_incoming_connections’:
| udptunnel.c:430:55: warning: pointer targets in passing argument 3 of
‘accept’ differ in signedness [-Wpointer-sign]
| 430 | (struct sockaddr *) _addr, )) < 0)
{
| | ^~~~
| | |
| | int *
| In file included from udptunnel.c:14:
| /usr/include/x86_64-linux-gnu/sys/socket.h:307:42: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
| 307 |socklen_t *__restrict __addr_len);
| |~~^~
| udptunnel.c: In function ‘udp_to_tcp’:
| udptunnel.c:485:26: warning: pointer targets in passing argument 6 of
‘recvfrom’ differ in signedness [-Wpointer-sign]
| 485 | )) <= 0) {
| | ^~~~
| | |
| | int *
| In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:343:
| /usr/include/x86_64-linux-gnu/bits/socket2.h:62:56: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
|62 | __SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len)
| | ~~^~
| udptunnel.c: In function ‘tcp_to_udp’:
| udptunnel.c:564:36: warning: pointer targets in passing argument 5 of
‘getsockopt’ differ in signedness [-Wpointer-sign]
| 564 | (void *), ) < 0) {
| |^~~~
| ||
| |int *
| /usr/include/x86_64-linux-gnu/sys/socket.h:257:46: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
| 257 |socklen_t *__restrict __optlen) __THROW;
| |~~^~~~
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j3 returned exit code 2
| make: *** [debian/rules:6: 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 libnsl-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#1065160: slapi-nis: FTBFS: missing build-dep on libnsl-dev
Source: slapi-nis Version: 0.60.0-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 slapi-nis to FTBFS in sid with: | /bin/bash ../libtool --tag=CC --mode=link gcc -I/usr/include/nss -I/usr/include/nspr -I/usr/include/tirpc -DDEFS_NIS_MAIN -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -module -avoid-version -export-symbols-regex '.*_plugin_init' -Wl,-z,relro -o nisserver-plugin-defs nisserver_plugin_defs-defs-nis.o -lsss_nss_idmap | libtool: link: gcc -I/usr/include/nss -I/usr/include/nspr -I/usr/include/tirpc -DPORTMAP_MAIN -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wl,-z -Wl,relro -o portmap portmap-portmap.o -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -ltirpc -lwrap -lnsl -lsss_nss_idmap | /usr/bin/ld: cannot find -lnsl: No such file or directory | collect2: error: ld returned 1 exit status | make[3]: *** [Makefile:717: portmap] Error 1 | make[3]: *** Waiting for unfinished jobs | libtool: link: gcc -I/usr/include/nss -I/usr/include/nspr -I/usr/include/tirpc -DDEFS_NIS_MAIN -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wl,-z -Wl,relro -o nisserver-plugin-defs nisserver_plugin_defs-defs-nis.o -lsss_nss_idmap | make[3]: Leaving directory '/<>/src' | make[2]: *** [Makefile:547: all] Error 2 | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:481: all-recursive] Error 1 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:8: build] Error 25 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065159: aplus-fsf: FTBFS: missing build-dep on libnsl-dev
Source: aplus-fsf Version: 4.22.1-12 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 aplus-fsf to FTBFS in sid with: | libtool: compile: gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"aplus-fsf\" -DVERSION=\"4.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DRETSIGTYPE=void -DHAVE_STRFTIME=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_VPRINTF=1 -DHAVE_GETCWD=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETWD=1 -DHAVE_MKTIME=1 -DHAVE_PUTENV=1 -DHAVE_REGCOMP=1 -DHAVE_SELECT=1 -DHAVE_SIGACTION=1 -DHAVE_SOCKET=1 -DHAVE_STRCSPN=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOD=1 -DHAVE_STRTOL=1 -DHAVE_STRTOUL=1 -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MATH_H=1 -DHAVE_FLOAT_H=1 -DHAVE_NEW=1 -DHAVE_IOSTREAM=1 -DHAVE_IOMANIP=1 -DHAVE_FSTREAM=1 -DHAVE_SSTREAM=1 -DHAVE_IOSFWD=1 -DHAVE_FPCLASSIFY=1 -DHAVE_FINITE=1 -DHAVE_ISINF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_SOCKLEN_T=1 -I. -I.. -g -pipe -std=gnu++98 -O2 -MT getmuser.lo -MD -MP -MF .deps/getmuser.Tpo -c getmuser.c -fPIC -DPIC -o .libs/getmuser.o | cc1: warning: command-line option â<80><98>-std=gnu++98â<80><99> is valid for C++/ObjC++ but not for C | getmuser.c:10:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |10 | #include | | ^ | compilation terminated. | make[3]: *** [Makefile:872: getmuser.lo] Error 1 | make[3]: *** Waiting for unfinished jobs This could be fixed by adding an explicit Build-Depends on libnsl-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#1065158: postfix: FTBFS: missing build-dep on libnsl-dev
Source: postfix Version: 3.8.5-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 postfix to FTBFS in sid with: | gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE=2 -DHAS_LDAP -DUSE_LDAP_SASL -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" -DDEF_MANPAGE_DIR=\"/usr/share/man\" -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fno-common -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -I. -DLINUX6 -c dict_nis.c | dict_nis.c:42:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |42 | #include | | ^ | compilation terminated. | make: *** [Makefile:220: dict_nis.o] Error 1 | make: *** Waiting for unfinished jobs | make: Leaving directory '/<>/src/util' | make[2]: *** [Makefile:114: update] Error 1 | make[2]: Leaving directory '/<>' | dh_auto_build: error: make -j3 "INSTALL=install --strip-program=true" returned exit code 2 | make[1]: *** [debian/rules:90: override_dh_auto_build] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:63: binary] Error 2 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065129: python3.11: recent libc6-dev change causes NIS support to be dropped
Source: python3.11 Version: 3.11.13-1 Severity: serious 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 python3.11 to be built without NIS support, which in practice means that this python module is missing from libpython3.11-stdlib: /usr/lib/python3.11/lib-dynload/nis.cpython-311-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS 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#1065130: python3.10: recent libc6-dev change causes NIS support to be dropped
Source: python3.10 Version: 3.10.13-1 Severity: serious 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 python3.10 to be built without NIS support, which in practice means that this python module is missing from libpython3.10-stdlib: /usr/lib/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS 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#1065128: python3.12: recent libc6-dev change causes NIS support to be dropped
Source: python3.12 Version: 3.12.13-1 Severity: serious 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 python3.12 to be built without NIS support, which in practice means that this python module is missing from libpython3.12-stdlib: /usr/lib/python3.12/lib-dynload/nis.cpython-312-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS 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#1065127: pike8.0: recent libc6-dev change causes Yp module to be empty
Source: pike8.0 Version: 8.0.1738-1.2 Severity: serious 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 the Yp module in pike8.0 to be empty (default behaviour when libnsl is not found). Please either: - Add libnsl-dev as build dependency - Disable NIS support explicitly so that the content of Yp.pmods 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#1065110: ypbind-mt: FTBFS: missing build-dep on libnsl-dev
Source: ypbind-mt Version: 2.7.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: 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 ypbind-mt to FTBFS in sid with: | checking for sys/types.h... yes | checking for unistd.h... yes | checking for wchar.h... yes | checking for minix/config.h... no | checking whether it is safe to define __EXTENSIONS__... yes | checking whether _XOPEN_SOURCE should be defined... no | checking for pthread_create in -lpthread... yes | checking for pkg-config... /usr/bin/pkg-config | checking pkg-config is at least version 0.9.0... yes | checking for libsystemd >= 209... yes | checking for libnsl... no | configure: error: Package requirements (libnsl) were not met: | | Package 'libnsl', 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 NSL_CFLAGS | and NSL_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 could be fixed by adding an explicit Build-Depends on libnsl-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#1065109: perdition: FTBFS: missing build-dep on libnsl-dev
Source: perdition Version: 2.2-3.2 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 perdition to FTBFS in sid with: | make[5]: Entering directory '/<>/perdition/db/nis' | /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../ -I../../../perdition -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o perditiondb_nis.lo perditiondb_nis.c | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../ -I../../../perdition -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c perditiondb_nis.c -fPIC -DPIC -o .libs/perditiondb_nis.o | In file included from perditiondb_nis.c:32: | perditiondb_nis.h:32:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |32 | #include | | ^ | compilation terminated. | make[5]: *** [Makefile:499: perditiondb_nis.lo] Error 1 | make[5]: Leaving directory '/<>/perdition/db/nis' | make[4]: *** [Makefile:431: all-recursive] Error 1 | make[4]: Leaving directory '/<>/perdition/db' | make[3]: *** [Makefile:797: all-recursive] Error 1 | make[3]: Leaving directory '/<>/perdition' | make[2]: *** [Makefile:471: all-recursive] Error 1 | make[2]: Leaving directory '/<>' | make[1]: *** [Makefile:399: all] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:25: build-stamp] Error 2 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065108: java3d: FTBFS: missing build-dep on libnsl-dev
Source: java3d Version: 1.5.2+dfsg-17 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 java3d to FTBFS in sid with: | [exec] In file included from /usr/include/GL/gl.h:2050, | [exec] from /<>/j3d-core/src/native/ogl/gldefs.h:68: | [exec] /usr/include/GL/glext.h:35: note: this is the location of the previous definition | [exec]35 | #define GL_GLEXT_VERSION 20220530 | [exec] | | [exec] ld: cannot find -lnsl: No such file or directory | [exec] Result: 1 This could be fixed by adding an explicit Build-Depends on libnsl-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#1065107: exim4: FTBFS: missing build-dep on libnsl-dev
Source: exim4 Version: 4.97-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 exim4 to FTBFS in sid with: | cc buildconfig.c | cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -D_LARGEFILE_SOURCE -fno-strict-aliasing -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -o buildconfig buildconfig.c -lcrypt -lm -lnsl | buildconfig.c: In function 'main': | buildconfig.c:117:5: warning: unused variable 'test_int_t' [-Wunused-variable] | 117 | int test_int_t = 0; | | ^~ | /usr/bin/ld: cannot find -lnsl: No such file or directory | collect2: error: ld returned 1 exit status | make[3]: *** [Makefile:390: buildconfig] Error 1 | make[3]: Leaving directory '/<>/b-exim4-daemon-light/build-Linux-x86_64' | make[2]: *** [Makefile:37: all] Error 2 | make[2]: Leaving directory '/<>/b-exim4-daemon-light' | make[1]: *** [debian/rules:121: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:324: 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 libnsl-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#1065069: apt-move rebuilt with the wrong ABI on 32-bit architectures
Source: apt-move Version: 4.2.27-6+b1 Severity: serious X-Debbugs-Cc: debian-rele...@lists.debian.org apt-move has been binNMUed for the time64_t transition. However due to the lack of extra-depends and the impossibility to recreate chroots on the buildd, it has been built with pre time64_t version of dpkg and gcc-13, probably leading to the wrong ABI. See for instance: https://buildd.debian.org/status/fetch.php?pkg=apt-move=armel=4.2.27-6%2Bb1=1709156067=0
Bug#1064978: android-platform-frameworks-native_10.0.0+r36-1.1_all-buildd.changes REJECTED
Source: android-platform-frameworks-native Version: 10.0.0+r36-1.1 Severity: serious X-Debbugs-Cc: vor...@debian.org On 2024-02-28 02:02, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package > android-platform-frameworks-native-headers, version 1:10.0.0+r36-1.1, for all, > however stable already has version 1:29.0.6-28. > Uploads to unstable must have a higher version than present in stable. > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > signature.asc Description: PGP signature
Bug#1064295: puppet-agent: ununsatisfiable dependencies: depends on ruby-concurrent (< 1.2.0)
Package: puppet-agent Version: 7.23.0-1 Severity: serious X-Debbugs-Cc: d...@debian.org Dear maintainer, puppet-agent in unstable is not installable anymore as it depends on ruby-concurrent (< 1.2.0), while the version in unstable is now 1.2.3-2. Regards Aurelien
Bug#1064294: bind-dyndb-ldap: FTBFS: error: Install BIND9 development files
Source: bind-dyndb-ldap Version: 11.10-6 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, bind-dyndb-ldap fails to build from source, from my build log on amd64: | checking for -fvisibility=hidden compiler flag... yes | checking for -fno-delete-null-pointer-checks compiler flag... yes | checking for -std=gnu11 compiler flag... yes | checking for isc-config.sh... no | checking for working isc-config... no | configure: WARNING: | Could not detect script isc-config.sh. Compilation may fail. | Defining variable BIND9_CFLAGS will fix this problem. | | checking for isc_dir_open in -lisc... yes | checking for dns_name_init in -ldns... no | configure: error: Install BIND9 development files | cd build && tail -v -n \+0 config.log A full build log is also available on riscv64: https://buildd.debian.org/status/fetch.php?pkg=bind-dyndb-ldap=riscv64=11.10-6%2Bb2=1703783350=0 The issue is also visible on the reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/bind-dyndb-ldap_11.10-6.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/bind-dyndb-ldap_11.10-6.rbuild.log.gz Regards Aurelien
Bug#1064139: ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’
Source: ogre-1.12 Version: 1.12.10+dfsg2-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, ogre-1.12 fails to build from source, probably due to a change in imgui. From my build log on amd64: | [ 73%] Building CXX object Components/Overlay/CMakeFiles/OgreOverlay.dir/src/OgreFontManager.cpp.o | cd /<>/obj-x86_64-linux-gnu/Components/Overlay && /usr/bin/c++ -DOgreOverlay_EXPORTS -I/<>/Components/Overlay/include -I/usr/include/freetype2 -I/misc/freetype -I/<>/OgreMain/include -I/<>/obj-x86_64-linux-gnu/include -isystem /usr/include/imgui -isystem /usr/include/stb -Wall -Winit-self -Wcast-qual -Wwrite-strings -Wextra -Wundef -Wmissing-declarations -Wno-unused-parameter -Wshadow -Wno-missing-field-initializers -Wno-long-long -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -pipe -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -msse -std=c++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT Components/Overlay/CMakeFiles/OgreOverlay.dir/src/OgreFontManager.cpp.o -MF CMakeFiles/OgreOverlay.dir/src/OgreFontManager.cpp.o.d -o CMakeFiles/OgreOverlay.dir/src/OgreFontManager.cpp.o -c /<>/Components/Overlay/src/OgreFontManager.cpp | [ 73%] Building CXX object Components/Overlay/CMakeFiles/OgreOverlay.dir/src/OgreImGuiOverlay.cpp.o | cd /<>/obj-x86_64-linux-gnu/Components/Overlay && /usr/bin/c++ -DOgreOverlay_EXPORTS -I/<>/Components/Overlay/include -I/usr/include/freetype2 -I/misc/freetype -I/<>/OgreMain/include -I/<>/obj-x86_64-linux-gnu/include -isystem /usr/include/imgui -isystem /usr/include/stb -Wall -Winit-self -Wcast-qual -Wwrite-strings -Wextra -Wundef -Wmissing-declarations -Wno-unused-parameter -Wshadow -Wno-missing-field-initializers -Wno-long-long -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -pipe -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -msse -std=c++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT Components/Overlay/CMakeFiles/OgreOverlay.dir/src/OgreImGuiOverlay.cpp.o -MF CMakeFiles/OgreOverlay.dir/src/OgreImGuiOverlay.cpp.o.d -o CMakeFiles/OgreOverlay.dir/src/OgreImGuiOverlay.cpp.o -c /<>/Components/Overlay/src/OgreImGuiOverlay.cpp | /<>/Components/Overlay/src/OgreImGuiOverlay.cpp: In member function ‘void Ogre::ImGuiOverlay::ImGUIRenderable::createFontTexture()’: | /<>/Components/Overlay/src/OgreImGuiOverlay.cpp:118:20: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’ | 118 | ImGuiFreeType::BuildFontAtlas(io.Fonts, 0); | |^~ | make[4]: *** [Components/Overlay/CMakeFiles/OgreOverlay.dir/build.make:121: Components/Overlay/CMakeFiles/OgreOverlay.dir/src/OgreImGuiOverlay.cpp.o] Error 1 | make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[3]: *** [CMakeFiles/Makefile2:1187: Components/Overlay/CMakeFiles/OgreOverlay.dir/all] Error 2 | make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[2]: *** [Makefile:159: all] Error 2 | make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' | dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2 | make[1]: *** [debian/rules:65: override_dh_auto_build-indep] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:41: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 A full build log is also available on riscv64: https://buildd.debian.org/status/fetch.php?pkg=ogre-1.12=riscv64=1.12.10%2Bdfsg2-3%2Bb1=1707901622=0 The issue is also visible on the reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ogre-1.12_1.12.10+dfsg2-3.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/ogre-1.12_1.12.10+dfsg2-3.rbuild.log.gz Regards Aurelien
Bug#1063609: texstudio_4.7.2+ds-1_all-buildd.changes REJECTED
Source: texstudio Version: 4.7.2+ds-1 Severity: serious On 2024-02-07 17:06, Debian FTP Masters wrote: > > texstudio-doc_4.7.2+ds-1_all.deb: Built-Using refers to non-existing source > package python3-pygments (= 2.17.2+dfsg-1) > > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1062267: android-platform-frameworks-native_10.0.0+r36-1.1~exp1_all-buildd.changes REJECTED
Source: android-platform-frameworks-native Version: 10.0.0+r36-1.1~exp1 Severity: serious X-Debbugs-Cc: Steve Langasek On 2024-01-31 21:27, Debian FTP Masters wrote: > Version check failed: > Your upload included the binary package android-platform-frameworks-native-he= > aders, version 1:10.0.0+r36-1.1~exp1, for all, > however unstable already has version 1:34.0.4-1. > Uploads to experimental must have a higher version than present in unstable. > > > > =3D=3D=3D > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1062207: gcc-defaults-ports_1.212_amd64-buildd.changes REJECTED
Source: gcc-defaults-ports Version: 1.212 Severity: serious On 2024-01-31 17:59, Debian FTP Masters wrote: > Version check failed: > Your upload included the binary package cpp-alpha-linux-gnu, version 4:13.2.0= > -5, for amd64, > however testing already has version 4:13.2.1-2. > Uploads to unstable must have a higher version than present in testing. > > Mapping sid to unstable. > > =3D=3D=3D > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1061868: kodi: FTBFS: Settings.h:60:3: note: candidate expects 1 argument, 0 provided
Source: kodi Version: 2:20.2+dfsg-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, kodi fails to build from source. From my build log on amd64: | cd /<>/obj-x86_64-linux-gnu/build/interfaces/legacy && /usr/bin/c++ -I/<>/obj-x86_64-linux-gnu -I/<> -I/<>/lib -I/<>/xbmc -I/<>/xbmc/platform/linux -I/<>/xbmc/cores/VideoPlayer -I/<>/obj-x86_64-linux-gnu/build -I/<>/xbmc/platform/posix -isystem /<>/obj-x86_64-linux-gnu/build/include -isystem /usr/include/dbus-1.0 -isystem /usr/lib/x86_64-linux-gnu/dbus-1.0/include -isystem /usr/include/pipewire-0.3 -isystem /usr/include/spa-0.2 -isystem /usr/include/python3.11 -isystem /usr/include/samba-4.0 -isystem /usr/include/libxml2 -isystem /<>/obj-x86_64-linux-gnu/build/cores/RetroPlayer/messages -isystem /usr/include/freetype2 -isystem /usr/include/fribidi -isystem /usr/include/lzo -isystem /usr/include/libdrm -g -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -D_XBMC -DDEB_VERSION=\"2:20.2+dfsg-4\" -Wall -Wdouble-promotion -Wmissing-field-initializers -Wsign-compare -Wextra -Wno-unused-parameter -Wno-cast-function-type -Wnon-virtual-dtor -O2 -g -DNDEBUG -std=c++17 -DTARGET_POSIX -DTARGET_LINUX -D_GNU_SOURCE -DHAVE_LINUX_UDMABUF=1 -DHAVE_LINUX_DMA_HEAP=1 -DHAVE_LINUX_DMA_BUF=1 -DHAVE_MKOSTEMP=1 -DHAVE_LINUX_MEMFD=1 -DHAVE_STATX=1 -DHAVE_SSE=1 -DHAVE_SSE2=1 -DHAVE_SSE3=1 -DHAVE_SSSE3=1 -DHAVE_SSE4_1=1 -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -DHAS_POSIX_NETWORK -DHAS_LINUX_NETWORK -DHAS_BUILTIN_SYNC_ADD_AND_FETCH=1 -DHAS_BUILTIN_SYNC_SUB_AND_FETCH=1 -DHAS_BUILTIN_SYNC_VAL_COMPARE_AND_SWAP=1 -DHAVE_INOTIFY=1 -DHAVE_POSIX_FADVISE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_INTTYPES_H=1 -DHAS_ALSA=1 -DHAS_AVAHI=1 -DHAS_ZEROCONF=1 -DHAVE_LIBBLURAY=1 -DHAVE_LIBBLURAY_BDJ=1 -DHAVE_LIBCEC=1 -DHAS_DBUS=1 -DHAS_ISO9660PP=1 -DHAVE_LCMS2=1 -DCMS_NO_REGISTER_KEYWORD=1 -DHAS_LIRC=1 -DHAS_WEB_SERVER=1 -DHAS_WEB_INTERFACE=1 -DHAS_FILESYSTEM_NFS=1 -DHAS_NFS_SET_TIMEOUT -DHAS_NFS_MOUNT_GETEXPORTS_TIMEOUT -DHAS_PIPEWIRE=1 -DHAS_AIRPLAY=1 -DHAS_PULSEAUDIO=1 -DHAS_PYTHON=1 -DHAS_FILESYSTEM_SMB=1 -DHAS_SNDIO=1 -DHAVE_LIBUDEV=1 -DHAS_UDFREAD=1 -DHAVE_LIBXSLT=1 -DHAVE_LIBVA=1 -DHAS_GLX=1 -DHAVE_LIBVDPAU=1 -DDATE_HAS_STRINGVIEW -DFFMPEG_VER_SHA=\"4.4.1\" -DHAVE_GCRYPT=1 -DSPDLOG_FMT_EXTERNAL -DSPDLOG_DEBUG_ON -DSPDLOG_NO_ATOMIC_LEVELS -DSPDLOG_ENABLE_PATTERN_PADDING -DSPDLOG_COMPILED_LIB -I/usr/include -DSPDLOG_SHARED_LIB -DHAS_EGL=1 -DHAVE_EGLEXTANGLE=1 -DHAVE_X11=1 -DHAVE_LIBXRANDR=1 -DHAVE_HDR_OUTPUT_METADATA=1 -DHAVE_DRM_MODIFIER_NAME=1 -DHAS_GL=1 -DHAVE_WAYLAND=1 -DHAVE_GBM=1 -DHAS_GBM_BO_MAP=1 -DHAS_GBM_MODIFIERS=1 -DHAS_MYSQL=1 -DHAS_UPNP=1 -DHAS_DVD_DRIVE -DHAS_CDDA_RIPPER -DHAS_AIRTUNES=1 -DBIN_INSTALL_PATH=\"/usr/lib/x86_64-linux-gnu/kodi\" -DINSTALL_PATH=\"/usr/share/kodi\" -Werror=double-promotion -Werror=missing-field-initializers -Werror=sign-compare -MD -MT build/interfaces/legacy/CMakeFiles/legacy_interface.dir/InfoTagVideo.cpp.o -MF CMakeFiles/legacy_interface.dir/InfoTagVideo.cpp.o.d -o CMakeFiles/legacy_interface.dir/InfoTagVideo.cpp.o -c /<>/xbmc/interfaces/legacy/InfoTagVideo.cpp | /<>/obj-x86_64-linux-gnu/build/swig/AddonModuleXbmcaddon.i.cpp: In function ‘PyObject* PythonBindings::xbmcaddon_XBMCAddon_xbmcaddon_Settings_New(PyTypeObject*, PyObject*, PyObject*)’: | /<>/obj-x86_64-linux-gnu/build/swig/AddonModuleXbmcaddon.i.cpp:1896:56: error: no matching function for call to ‘XBMCAddon::xbmcaddon::Settings::Settings()’ | 1896 | apiResult = new XBMCAddon::xbmcaddon::Settings( ); | |^ | In file included from /<>/xbmc/interfaces/legacy/Addon.h:14, | from /<>/obj-x86_64-linux-gnu/build/swig/AddonModuleXbmcaddon.i.cpp:31: | /<>/xbmc/interfaces/legacy/Settings.h:60:3: note: candidate: ‘XBMCAddon::xbmcaddon::Settings::Settings(std::shared_ptr)’ |60 | Settings(std::shared_ptr settings); | | ^~~~ | /<>/xbmc/interfaces/legacy/Settings.h:60:3: note: candidate expects 1 argument, 0 provided | make[4]: *** [build/swig/CMakeFiles/python_binding.dir/build.make:121: build/swig/CMakeFiles/python_binding.dir/AddonModuleXbmcaddon.i.cpp.o] Error 1 | make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[3]: *** [CMakeFiles/Makefile2:12028: build/swig/CMakeFiles/python_binding.dir/all] Error 2 | make[3]: *** Waiting for unfinished jobs A full build log on riscv64 is also available there: https://buildd.debian.org/status/fetch.php?pkg=kodi=riscv64=2%3A20.2%2Bdfsg-4%2Bb3=1706500015=0 Regards Aurelien
Bug#1061646: falcosecurity-libs: build-depends on unavailable libluajit-5.1-dev
Source: falcosecurity-libs
Version: 0.14.1-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
falcosecurity-libs now build-depends unconditionally on
libluajit-5.1-dev. This prevents the package to be buildable on some
architectures where it was available before: ppc64el for release
architectures, and riscv64 and ppc64 for non-release architectures.
The version 0.14.1-1 force libsinsp to be linked to a few additional
libraries, including -lluajit-5.1. This causes FTBFS on architectures
where it was not build-depended on. This has been wrongly fixed in
version 0.14.1-2 by changing the build-depends on libluajit-5.1-dev to
be unconditional.
The patch below fixes the issue by using the ${LUAJIT_LIB} cmake
variable instead of using -lluajit-5.1 and reverting the
build-dependency changes. At the same time, the list of architectures
which have libluajit-5.1-dev has been updated to reflect the current
status.
--- falcosecurity-libs-0.14.1/debian/control
+++ falcosecurity-libs-0.14.1/debian/control
@@ -21,7 +21,7 @@
protobuf-compiler,
protobuf-compiler-grpc,
libprotobuf-dev,
- libluajit-5.1-dev,
+ libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el s390x]
| liblua5.1-0-dev,
libelf-dev,
libre2-dev,
libcap-dev,
---
falcosecurity-libs-0.14.1/debian/patches/libsinsp-added-missing-libraries.patch
+++
falcosecurity-libs-0.14.1/debian/patches/libsinsp-added-missing-libraries.patch
@@ -7,7 +7,7 @@
"${JSONCPP_LIB}"
"${RE2_LIB}"
+ -lprotobuf
-+ -lluajit-5.1
++ "${LUAJIT_LIB}"
+ -lgrpc++
)
Bug#1061339: numpy_1.26.3-1_s390x-buildd.changes REJECTED
Source: numpy Version: 1.26.3-1 Severity: serious On 2024-01-22 08:24, Debian FTP Masters wrote: > > > python3-numpy_1.26.3-1_s390x.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#1061159: sdaps: FTBFS: command 'sdaps_clean_i18n' has no such option 'all'
Source: sdaps
Version: 1.9.8-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
sdaps fails to build from source. From my build log on amd64:
| dpkg-buildpackage: info: source package sdaps
| dpkg-buildpackage: info: source version 1.9.8-0.1
| dpkg-buildpackage: info: source distribution unstable
| dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
| fakeroot debian/rules clean
| dh clean --with python3 --buildsystem=pybuild
|dh_auto_clean -O--buildsystem=pybuild
| I: pybuild base:305: python3.11 setup.py clean
| error: error in
/<>/.pybuild/cpython3_3.11_sdaps/.pydistutils.cfg: command
'sdaps_clean_i18n' has no such option 'all'
| E: pybuild pybuild:391: clean: plugin distutils failed with: exit code=1:
python3.11 setup.py clean
| dh_auto_clean: error: pybuild --clean -i python{version} -p 3.11 returned
exit code 13
| make: *** [debian/rules:7: clean] Error 25
| dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
exit status 2
The full build log for riscv64 is also available here:
https://buildd.debian.org/status/fetch.php?pkg=sdaps=riscv64=1.9.8-0.1%2Bb1=1705322530=0
The reproducible builds also show the same issue:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/sdaps_1.9.8-0.1.rbuild.log.gz
Regards
Aurelien
Bug#1061063: armhf: h5py's tests expose unaligned memory accesses during the build
On 2024-01-17 09:33, Matthias Klose wrote: > Package: src:h5py > Version: 3.10.0-1 > Severity: serious > Tags: sid trixie > > armhf: h5py's tests expose unaligned memory accesses during the build, this > not seen with with the 3.9.0 version. You don't see this on the Debian > buildds itself, because they ignore these misalignments. While it is something to fix for performance issues, I hardly see how it is a serious issue. It is not possible to deactivate alignment fixups on a armhf kernel. The Debian arm64 kernels (and not just the buildds) therefore have the COMPAT_ALIGNMENT_FIXUPS kernel option enabled to reproduce the same behaviour for 32-bit processes. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols
Hi Matthieu, On 2024-01-12 11:06, Matthieu Baerts wrote: > Hi Aurélien, > > On 10/01/2024 19:13, Matthieu Baerts wrote: > > On 08/01/2024 21:18, Aurelien Jarno wrote: > > (...) > > >> In the latest rebuild of mptpcd, the conditions where met only on the > >> riscv64 buildd, and riscv64 is not a release architecture. That said a > >> few mips64el buildds also met the 3 conditions and it will be the case > >> of more and more buildds once they are upgraded to bookworm. I am > >> therefore filling this issue as severity serious. > > > > Many thanks for the explanation! > > > > I will wait for the different pipelines to be over, before sending a new > > version to mentors.debian.net! > > This new version has been sent to mentors.debian.net: > > https://mentors.debian.net/package/mptcpd/ > https://mentors.debian.net/debian/pool/main/m/mptcpd/mptcpd_0.12-3.dsc > Thanks for the quick fix, I have just uploaded it! Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols
Source: mptcpd
Version: 0.12-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear maintainer,
On riscv64, mptcpd fails to build from source with a segmentation fault
in the test-mptcpwrap test:
| ===
|mptcpd 0.12: tests/test-suite.log
| ===
|
| # TOTAL: 19
| # PASS: 17
| # SKIP: 1
| # XFAIL: 0
| # FAIL: 1
| # XPASS: 0
| # ERROR: 0
|
| .. contents:: :depth: 2
|
| SKIP: test-start-stop
| =
|
| Running non-interactive sudo check...
| sudo: a password is required
| fail, skipping the test
| SKIP test-start-stop (exit status: 77)
|
| FAIL: test-mptcpwrap
|
|
| Test case 0: PASS
| Test case 1: Segmentation fault
| FAIL test-mptcpwrap (exit status: 139)
A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=mptcpd=riscv64=0.12-2%2Bb1=1704714971=0
Investigation shows that 3 conditions are needed to trigger this issue:
- A recent kernel that supports mptcp, to be checked with
/proc/sys/net/mptcp/enabled
- Something that prevents SCTP to be used, for instance on the build
daemons /proc/sys/kernel/modules_disabled is set to 1, preventing the
sctp.ko module to be loaded
- A system without /etc/protocols, for instance without the netbase
package installed.
With this three conditions, this triggers the following code path from
the mptcpwrap-tester.c file:
| static void test_socket_data(struct socket_data const *data)
| {
| int const fd = socket(data->domain, data->type, data->protocol);
|
| if (fd == -1) {
| if (errno == EPROTONOSUPPORT) {
| struct protoent const *const p =
| getprotobynumber(data->protocol);
|
| fprintf(stderr,
| "WARNING: Ignoring unsupported "
| "protocol: %d - %s\n",
| data->protocol,
| p->p_name);
|
| return;
| }
The output of getprotobynumber() is used directly, without checking for
a NULL pointer in case of error, for instance because /etc/protocols
does not exist. This causes a segmentation fault when trying to
dereference it. A workaround is to build-depends on netbase, and a
proper fix to test for this error.
In the latest rebuild of mptpcd, the conditions where met only on the
riscv64 buildd, and riscv64 is not a release architecture. That said a
few mips64el buildds also met the 3 conditions and it will be the case
of more and more buildds once they are upgraded to bookworm. I am
therefore filling this issue as severity serious.
Regards
Aurelien
Bug#1060067: fuse3: FTBFS: dh_missing: error: missing files, aborting
Package: fuse3 Version: 3.14.0-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, fuse3 fails to build with error in dh_missing. From my build log on amd64: | dh_fixperms | chmod a-x debian/libfuse3-dev/usr/share/doc/libfuse3-dev/examples/cuse_client.c | make[1]: Leaving directory '/<>' |debian/rules override_dh_missing | make[1]: Entering directory '/<>' | dh_missing --fail-missing | dh_missing: warning: usr/lib/udev/rules.d/99-fuse3.rules exists in debian/tmp but is not installed to anywhere | dh_missing: error: missing files, aborting | The following debhelper tools have reported what they installed (with files per package) |* dh_install: fuse3 (3), fuse3-udeb (2), libfuse3-3 (2), libfuse3-3-udeb (2), libfuse3-dev (4) |* dh_installdocs: fuse3 (0), libfuse3-3 (3), libfuse3-dev (0) |* dh_installexamples: fuse3 (0), libfuse3-3 (0), libfuse3-dev (21) |* dh_installman: fuse3 (2), libfuse3-3 (0), libfuse3-dev (0) | If the missing files are installed by another tool, please file a bug against it. | When filing the report, if the tool is not part of debhelper itself, please reference the | "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). | (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz) | Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built | If the omission is intentional or no other helper can take care of this consider adding the | paths to debian/not-installed. | make[1]: *** [debian/rules:73: override_dh_missing] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:76: binary] Error 2 | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 A full build log on riscv64 is available there: https://buildd.debian.org/status/fetch.php?pkg=fuse3=riscv64=3.14.0-4%2Bb1=1704460936=0 A full build log on arm64 is also available from reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/fuse3_3.14.0-4.rbuild.log.gz Regards Aurelien
Bug#1059987: FTBFS: 38 tests failed out of 39
Source: endless-sky Version: 0.10.2-6 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, endless-sky fails to build with errors in the testsuite. From my build log: |debian/rules override_dh_auto_test | make[1]: Entering directory '/<>' | cd obj-x86_64-linux-gnu && ctest --label-exclude "(benchmark|integration-debug)" --timeout 9000 | Test project /<>/obj-x86_64-linux-gnu | Start 1: Afterburner-flight - Simple depart land | 1/39 Test #1: Afterburner-flight - Simple depart land ***Failed 5.60 sec | Start 3: Atrocity Test - New Atrocity | 2/39 Test #3: Atrocity Test - New Atrocity ...***Failed 6.03 sec | Start 5: Boarding Test - Repair Friendly Ship | 3/39 Test #5: Boarding Test - Repair Friendly Ship ...***Failed 6.16 sec | Start 7: Capture Uncapturable With Capturable Override | 4/39 Test #7: Capture Uncapturable With Capturable Override ..***Failed 7.00 sec | Start 9: Clear flagship model condition | 5/39 Test #9: Clear flagship model condition .***Failed 6.82 sec | Start 11: Conditional Test | 6/39 Test #11: Conditional Test ...***Failed 6.58 sec | Start 13: Conditional Test Goto | 7/39 Test #13: Conditional Test Goto ..***Failed 8.27 sec | Start 15: Conditional Test Out of Bound | 8/39 Test #15: Conditional Test Out of Bound ..***Failed 7.23 sec | Start 17: Ember Wastes Navigation | 9/39 Test #17: Ember Wastes Navigation ***Failed 5.92 sec | Start 19: Enter Name in Conversation | 10/39 Test #19: Enter Name in Conversation .***Failed 5.94 sec | Start 21: Flagship Attribute Autoconditions | 11/39 Test #21: Flagship Attribute Autoconditions ..***Failed 6.75 sec | Start 23: Flagship Planet Attribute Test | 12/39 Test #23: Flagship Planet Attribute Test .***Failed 6.11 sec | Start 25: Hyperjumps To Autocondition | 13/39 Test #25: Hyperjumps To Autocondition ***Failed 5.89 sec | Start 27: Illegal Test - Ignore and New Illegal | 14/39 Test #27: Illegal Test - Ignore and New Illegal ..***Failed 6.27 sec | Start 29: Loading and Reloading | 15/39 Test #29: Loading and Reloading ..***Failed 6.26 sec | Start 31: Loading and Saving | 16/39 Test #31: Loading and Saving .***Failed 7.13 sec | Start 33: Outfitter Mission Test | 17/39 Test #33: Outfitter Mission Test .***Failed 5.47 sec | Start 35: Save To Default Snapshot | 18/39 Test #35: Save To Default Snapshot ...***Failed 6.39 sec | Start 37: Saving during conversation | 19/39 Test #37: Saving during conversation .***Failed 6.44 sec | Start 39: Sell 0 ships | 20/39 Test #39: Sell 0 ships ...***Failed 6.07 sec | Start 41: Sell 1 ship | 21/39 Test #41: Sell 1 ship ***Failed 6.98 sec | Start 43: Sell 2 ships | 22/39 Test #43: Sell 2 ships ...***Failed 5.57 sec | Start 45: Sell 3 ships | 23/39 Test #45: Sell 3 ships ...***Failed 5.72 sec | Start 47: Sell Outfit On Take Off | 24/39 Test #47: Sell Outfit On Take Off ***Failed 6.85 sec | Start 49: Shipyard Mission Test | 25/39 Test #49: Shipyard Mission Test ..***Failed 5.91 sec | Start 51: Start Game | 26/39 Test #51: Start Game .***Failed 7.19 sec | Start 53: Store Outfit On Take Off | 27/39 Test #53: Store Outfit On Take Off ...***Failed 5.64 sec | Start 55: Test-Framework - Calling other functions | 28/39 Test #55: Test-Framework - Calling other functions ...***Failed 7.29 sec | Start 57: Test-Framework - Conditions Arithmetic and Loops | 29/39 Test #57: Test-Framework - Conditions Arithmetic and Loops ...***Failed 6.21 sec | Start 59: Test-Framework - Empty Test Sequence | 30/39 Test #59: Test-Framework - Empty Test Sequence ...***Failed 6.72 sec | Start 61: Test-Framework - Empty Testcase | 31/39 Test #61: Test-Framework - Empty Testcase ***Failed 7.22 sec | Start 63: Test-Framework - Load Depart Land | 32/39 Test #63: Test-Framework - Load Depart Land ..***Failed 6.00 sec | Start 65: Test-Framework - Mission Injection | 33/39 Test #65: Test-Framework - Mission Injection
Bug#1059923: spread-sheet-widget_0.10-1_s390x-buildd.changes REJECTED
Source: spread-sheet-widget Version: 0.10-1 Severity: serious On 2024-01-03 17:21, Debian FTP Masters wrote: > > > libspread-sheet-widget-dev_0.10-1_s390x.deb: has 1 file(s) with a timestamp > too far in the past: > usr/share/doc/libspread-sheet-widget-dev/changelog.gz (Thu Jan 1 00:00:00 > 1970) > > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > >
Bug#1057693: valgrind: i386 vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
Hi,
I have done a NMU to fix this issue blocking the migration of many
packages to testing. Please find the debdiff attached.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru valgrind-3.20.0/debian/changelog valgrind-3.20.0/debian/changelog
--- valgrind-3.20.0/debian/changelog2023-12-01 12:53:02.0 +0100
+++ valgrind-3.20.0/debian/changelog2024-01-02 13:09:38.0 +0100
@@ -1,3 +1,11 @@
+valgrind (1:3.20.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply fix from upstream to add support for new x86 nops patterns. Closes
+#1057693.
+
+ -- Aurelien Jarno Tue, 02 Jan 2024 12:09:38 +
+
valgrind (1:3.20.0-2) unstable; urgency=medium
* [armhf] default.supp: add suppression for memory accesses below the stack
diff -Nru valgrind-3.20.0/debian/patches/14-x86-new-nops.patch
valgrind-3.20.0/debian/patches/14-x86-new-nops.patch
--- valgrind-3.20.0/debian/patches/14-x86-new-nops.patch1970-01-01
01:00:00.0 +0100
+++ valgrind-3.20.0/debian/patches/14-x86-new-nops.patch2024-01-02
11:53:58.0 +0100
@@ -0,0 +1,123 @@
+From: Paul Floyd
+Date: Sun, 17 Dec 2023 13:18:51 + (+0100)
+Subject: Bug 478624 - Valgrind incompatibility with binutils-2.42 on x86 with
new nop patterns...
+X-Git-Url:
https://sourceware.org/git/?p=valgrind.git;a=commitdiff_plain;h=d35005cef8ad8207542738812705ceabf137d7e0
+
+Bug 478624 - Valgrind incompatibility with binutils-2.42 on x86 with new nop
patterns (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26)
+
+It was a bit of a struggle to get the testcase to build
+with both clang and gcc (oddly enough gcc was more difficult) so
+I just resorted to using .byte arrays.
+---
+
+diff --git a/VEX/priv/guest_x86_toIR.c b/VEX/priv/guest_x86_toIR.c
+index 5d6e6dc64f..3b6efb3873 100644
+--- a/VEX/priv/guest_x86_toIR.c
b/VEX/priv/guest_x86_toIR.c
+@@ -8198,7 +8198,7 @@ DisResult disInstr_X86_WRK (
+ delta += 5;
+ goto decode_success;
+ }
+- /* Don't barf on recent binutils padding,
++ /* Don't barf on recent (2010) binutils padding,
+ all variants of which are: nopw %cs:0x0(%eax,%eax,1)
+ 66 2e 0f 1f 84 00 00 00 00 00
+ 66 66 2e 0f 1f 84 00 00 00 00 00
+@@ -8223,6 +8223,26 @@ DisResult disInstr_X86_WRK (
+ }
+ }
+
++ /* bug478624 GNU binutils uses a leal of esi into itself with
++ a zero offset and CS prefix as an 8 byte no-op (Dec 2023).
++ Since the CS prefix is hardly ever used we don't do much
++ to decode it, just a few cases for conditional branches.
++ So add handling here with other pseudo-no-ops.
++ */
++ if (code[0] == 0x2E && code[1] == 0x8D) {
++ if (code[2] == 0x74 && code[3] == 0x26 && code[4] == 0x00) {
++DIP("leal %%cs:0(%%esi,%%eiz,1),%%esi\n");
++delta += 5;
++goto decode_success;
++ }
++ if (code[2] == 0xB4 && code[3] == 0x26 && code[4] == 0x00
++ && code[5] == 0x00 && code[6] == 0x00 && code[7] == 0x00) {
++DIP("leal %%cs:0(%%esi,%%eiz,1),%%esi\n");
++delta += 8;
++goto decode_success;
++ }
++ }
++
+ // Intel CET requires the following opcodes to be treated as NOPs
+ // with any prefix and ModRM, SIB and disp combination:
+ // "0F 19", "0F 1C", "0F 1D", "0F 1E", "0F 1F"
+diff --git a/none/tests/x86/Makefile.am b/none/tests/x86/Makefile.am
+index 3ecd1ad3c2..dbae865712 100644
+--- a/none/tests/x86/Makefile.am
b/none/tests/x86/Makefile.am
+@@ -52,6 +52,7 @@ EXTRA_DIST = \
+ fxtract.stdout.exp fxtract.stderr.exp fxtract.vgtest \
+ fxtract.stdout.exp-older-glibc \
+ getseg.stdout.exp getseg.stderr.exp getseg.vgtest \
++ gnu_binutils_nop.stderr.exp gnu_binutils_nop.vgtest \
+ incdec_alt.stdout.exp incdec_alt.stderr.exp incdec_alt.vgtest \
+ int.stderr.exp int.stdout.exp int.disabled \
+ $(addsuffix .stderr.exp,$(INSN_TESTS)) \
+@@ -100,6 +101,7 @@ check_PROGRAMS = \
+ fpu_lazy_eflags \
+ fxtract \
+ getseg \
++ gnu_binutils_nop \
+ incdec_alt \
+ $(INSN_TESTS) \
+ int \
+diff --git a/none/tests/x86/gnu_binutils_nop.c
b/none/tests/x86/gnu_binutils_nop.c
+new file mode 100644
+index 00..412a4c2cbc
+--- /dev/null
b/none/tests/x86/gnu_binutils_nop.c
+@@ -0,0 +1,34 @@
++int main(void)
++{
++// GNU binutils uses various opcodes as alternatives for nop
++// the idea is that it is faster to execute one large opcode
++// with no side-effects than multiple repetitions of the
++// single byte 'nop'. This gives more choice when code
++// needs to be padded.
++
++ // the following is bas
Bug#1038603: libisl23 0.25-1: amd64/i386 baseline violation: uses BMI instructions)
Hi Matthias, On 2023-07-23 02:34, Roman Lebedev wrote: > Package: libisl23 > Followup-For: Bug #1038603 > X-Debbugs-Cc: Debian GCC Maintainers , > debian-rele...@lists.debian.org > > While the issue has been resolved in isl 0.26-3, > which was uploaded to unstable on 2023-06-19, > nothing has been done for the stable release, > and Debian 12.1 still comes with a "miscompiled" isl 0.25-1, > and thus gcc is still somewhat unusable(*) on older hardware(**) Would it be possible to schedule an upload with the same fix to bookworm? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1059266: error: cannot verify inline signature
Hi On 2023-12-22 23:30, Guillem Jover wrote: > I'll prepare an upload right away and force the code to use gpg for > now (as it was used before the recent upload, instead of trying gpgv, > sqop, pgpainless-cli, or sq), until I've devised a better migration > plan, or implemented enough configuration options for people to switch > or use other OpenPGP backends when desired. Thanks, I confirm it fixes the issue. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1059266: error: cannot verify inline signature
On 2023-12-22 19:23, Aurelien Jarno wrote: > control: reopen -1 > > Hi, > > On 2023-12-22 12:16, Guillem Jover wrote: > > Hi! > > > > On Fri, 2023-12-22 at 10:53:18 +0100, Christian Marillat wrote: > > > Package: dupload > > > Version: 2.10.4 > > > Severity: grave > > > > > This version fail to check a signature. Work fine with 2.10.3 > > > > > > , > > > | $ debrelease > > > | dupload note: no announcement will be sent. > > > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri > > > Dec 22 10:50:05 2023 CET > > > | gpgv:using RSA key > > > A401FF99368FA1F98152DE755C808C2B65558117 > > > | gpgv:issuer "maril...@deb-multimedia.org" > > > | gpgv: Can't check signature: No public key > > > | openpgp-check: error: cannot verify inline signature for > > > ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found > > > | > > > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed > > > for ../gerbera-dmo_1.12.1-dmo5_amd64.changes > > > ` > > This also causes issues on the riscv64 build daemons running sid: > > | dupload exit status 9/0 > | Removed to reupload later. > | > | Complete output from dupload: > | > | dupload note: no announcement will be sent. > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 > 18:06:16 2023 UTC > | gpgv:using RSA key 670D3AC041E218107D0DE6F9339F749981589F2F > | gpgv: Can't check signature: No public key > | openpgp-check: error: cannot verify inline signature for > emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature found > | > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for > emmax_0~beta.20100307-4_riscv64-buildd.changes > > > Just to understand what is going wrong, I assume you don't have the > > debian-keyring package installed (where the signing certificate could > > be found in the debian-keyring.gpg keyring), nor the certificate for > > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg? > > For debian build daemons, it is not expected to have the keys in the > debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not > exist. > > > But gpg has it in its certificate store? > > Yes: > > buildd@rv-manda-01:~/.gnupg$ gpg -K > /home/buildd/.gnupg/pubring.kbx > --- > sec rsa4096 2023-12-08 [SC] [expire : 2024-12-07] > 670D3AC041E218107D0DE6F9339F749981589F2F > uid [ ultime ] buildd autosigning key rv-manda-01 > It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg, not from ~/.gnupg/trustedkeys.gpg. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
