Bug#1086747: openjdk-23: Please add patch to fix FTBFS on alpha
Source: openjdk-23 Version: 23.0.1+11-1 Severity: normal Tags: patch User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hi, openjdk-23 currently FTBFS on alpha due to a failing assert: Executing: [/usr/bin/alpha-linux-gnu-g++-14 -MMD -MF /<>/build/hotspot/variant-zero/libjvm/objs/os_linux.d.tmp (...) -O3 -c -o /<>/build/hotspot/variant-zero/libjvm/objs/os_linux_zero.o /<>/src/hotspot/os_cpu/ \ linux_zero/os_linux_zero.cpp -frandom-seed="os_linux_zero.cpp"] cc1plus: warning: '-Werror=' argument '-Werror=implicit-function-declaration' is not valid for C++ /<>/src/hotspot/os/linux/os_linux.cpp:2900:37: error: static assertion failed: MAP_FIXED_NOREPLACE != MAP_FIXED_NOREPLACE_value 2900 | static_assert(MAP_FIXED_NOREPLACE == MAP_FIXED_NOREPLACE_value, "MAP_FIXED_NOREPLACE != MAP_FIXED_NOREPLACE_value"); | ^ /<>/src/hotspot/os/linux/os_linux.cpp:2900:37: note: the comparison reduces to '(2097152 == 1048576)' gmake[4]: *** [lib/CompileJvm.gmk:154: /<>/build/hotspot/variant-zero/libjvm/objs/os_linux.o] Error 1 gmake[3]: *** [make/Main.gmk:253: hotspot-zero-libs] Error 2 gmake[3]: *** Waiting for unfinished jobs The attached patch fixes the problem. Would be great if it could be incldued for the next upload. In the meantime, I have uploaded a patched version of openjdk-22 for alpha to unreleased. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- openjdk-22-22.0.2+9.orig/src/hotspot/os/linux/os_linux.cpp +++ openjdk-22-22.0.2+9/src/hotspot/os/linux/os_linux.cpp @@ -2892,7 +2892,12 @@ void os::pd_commit_memory_or_exit(char* // Note that the value for MAP_FIXED_NOREPLACE differs between architectures, but all architectures // supported by OpenJDK share the same flag value. +#if defined(ALPHA) +#define MAP_FIXED_NOREPLACE_value 0x20 +#else #define MAP_FIXED_NOREPLACE_value 0x10 +#endif + #ifndef MAP_FIXED_NOREPLACE #define MAP_FIXED_NOREPLACE MAP_FIXED_NOREPLACE_value #else
Bug#1086728: openjdk-22: Please add patch to fix FTBFS on alpha
Source: openjdk-22 Version: 22.0.2+9-4 Severity: normal Tags: patch User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hi, openjdk-22 currently FTBFS on alpha due to a failing assert: Executing: [/usr/bin/alpha-linux-gnu-g++-14 -MMD -MF /<>/build/hotspot/variant-zero/libjvm/objs/os_linux.d.tmp (...) -O3 -c -o /<>/build/hotspot/variant-zero/libjvm/objs/os_linux_zero.o /<>/src/hotspot/os_cpu/ \ linux_zero/os_linux_zero.cpp -frandom-seed="os_linux_zero.cpp"] cc1plus: warning: '-Werror=' argument '-Werror=implicit-function-declaration' is not valid for C++ /<>/src/hotspot/os/linux/os_linux.cpp:2900:37: error: static assertion failed: MAP_FIXED_NOREPLACE != MAP_FIXED_NOREPLACE_value 2900 | static_assert(MAP_FIXED_NOREPLACE == MAP_FIXED_NOREPLACE_value, "MAP_FIXED_NOREPLACE != MAP_FIXED_NOREPLACE_value"); | ^ /<>/src/hotspot/os/linux/os_linux.cpp:2900:37: note: the comparison reduces to '(2097152 == 1048576)' gmake[4]: *** [lib/CompileJvm.gmk:154: /<>/build/hotspot/variant-zero/libjvm/objs/os_linux.o] Error 1 gmake[3]: *** [make/Main.gmk:253: hotspot-zero-libs] Error 2 gmake[3]: *** Waiting for unfinished jobs The attached patch fixes the problem. Would be great if it could be incldued for the next upload. In the meantime, I have uploaded a patched version of openjdk-22 for alpha to unreleased. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- openjdk-22-22.0.2+9.orig/src/hotspot/os/linux/os_linux.cpp +++ openjdk-22-22.0.2+9/src/hotspot/os/linux/os_linux.cpp @@ -2892,7 +2892,12 @@ void os::pd_commit_memory_or_exit(char* // Note that the value for MAP_FIXED_NOREPLACE differs between architectures, but all architectures // supported by OpenJDK share the same flag value. +#if defined(ALPHA) +#define MAP_FIXED_NOREPLACE_value 0x20 +#else #define MAP_FIXED_NOREPLACE_value 0x10 +#endif + #ifndef MAP_FIXED_NOREPLACE #define MAP_FIXED_NOREPLACE MAP_FIXED_NOREPLACE_value #else
Bug#1086686: uhd: Please build with -g1 on sh4
Source: uhd Version: 4.7.0.0+ds1-2 Severity: normal Tags: patch User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello, uhd currently FTBFS on sh4 due to the compiler running out of memory [1]: FAILED: python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o /usr/bin/c++ -DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW -DBOOST_ASIO_DISABLE_STD_STRING_VIEW \ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB \ -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK \ -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SERIALIZATION_NO_LIB \ -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB \ -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_NO_LIB -DHAVE_CONFIG_H \ -DUHD_LOG_CONSOLE_COLOR -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_MIN_LEVEL=1 \ -Dpyuhd_EXPORTS -I/<>/obj-sh4-linux-gnu/include -I/<>/host/include \ -I/usr/include/python3.12 -I/usr/lib/python3/dist-packages/numpy/core/include -I/<>/host/lib \ -I/<>/host/lib/deps/pybind11/include -I/<>/obj-sh4-linux-gnu/_cmrc/include \ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security \ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 \ -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++14 -fPIC -Wall -Wextra -Wsign-compare \ -MD -MT python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o -MF python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o.d \ -o python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o -c /<>/host/python/pyuhd.cpp cc1plus: out of memory allocating 847736 bytes after a total of 21823488 bytes This can be fixed by adding "-g1" to DEB_CXXFLAGS_MAINT_APPEND in debian/rules: --- debian/rules.orig 2024-07-11 04:43:50.0 +0200 +++ debian/rules2024-11-03 20:35:06.753875947 +0100 @@ -13,7 +13,7 @@ -DPKG_LIB_DIR="/usr/libexec/uhd" -DDOXYGEN_HAVE_DOT=True \ $(DEB_NEON_SIMD_OPTION)") -ifneq (,$(filter $(DEB_HOST_ARCH), mipsel)) +ifneq (,$(filter $(DEB_HOST_ARCH), mipsel sh4)) export DEB_CXXFLAGS_MAINT_APPEND = -g1 endif Could you apply this patch for the next upload? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2024-07-11 04:43:50.0 +0200 +++ debian/rules2024-11-03 20:35:06.753875947 +0100 @@ -13,7 +13,7 @@ -DPKG_LIB_DIR="/usr/libexec/uhd" -DDOXYGEN_HAVE_DOT=True \ $(DEB_NEON_SIMD_OPTION)") -ifneq (,$(filter $(DEB_HOST_ARCH), mipsel)) +ifneq (,$(filter $(DEB_HOST_ARCH), mipsel sh4)) export DEB_CXXFLAGS_MAINT_APPEND = -g1 endif
Bug#1086594: binary package of gstreamer1.0 fails to install on alpha, hppa, m68k and sh4 architectures
Hello Helge, On Fri, 2024-11-01 at 23:07 +0100, Helge Deller wrote: > On hppa I built a +b1 package with this patch and this solves the issue: > diff -up ./debian/libgstreamer1.0-0.postinst.in.org > ./debian/libgstreamer1.0-0.postinst.in > --- ./debian/libgstreamer1.0-0.postinst.in.org 2024-11-01 20:31:55.842270253 > + > +++ ./debian/libgstreamer1.0-0.postinst.in 2024-11-01 20:32:21.882130791 > + > @@ -2,7 +2,7 @@ > > set -e > > -if [ "$1" = configure ]; then > +if [ "$1" = configure -a -f > /usr/lib/@MULTIARCH@/gstreamer1.0/gstreamer-1.0/gst-ptp-helper ]; then > # If we have setcap is installed, try setting > cap_net_bind_service,cap_net_admin+ep, > # which allows us to install our helper binary without the setuid bit. > > > Not sure if this is the correct fix though... Yes, testing whether the gst-ptp-helper binary exists before trying to run setcap on it is the correct and obvious fix. Thanks for reporting it so quickly! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1078743: vtk9: BD-Uninstallable on 32-bit architectures after #1068320
Hello, On Fri, 2024-11-01 at 22:22 +0100, Paul Gevers wrote: > > No, this can't resolve itself automatically as this is a hard-encoded build > > dependency. What you're seeing here is just the cruft mechanism of DAK in > > action which doesn't exist in Mini DAK which Debian Ports uses. > > Can you elaborate more then? A problem on ports is not "serious", but > I'm not sure if I follow you if there now is or is not a problem for the > release architectures. The Debian Archive Kit, short DAK, has a mechanism called cruft which makes sure that packages never become BD-Uninstallable when build dependencies are removed or changed by keeping obsolete binary packages around as long as they are needed for building. This is to ensure that transitions never make packages BD-Uninstallable so that manual intervention is required. This mechanism does not exist for Debian Ports because it doesn't use DAK but Mini-DAK. However, cruft is not intended as a permanent solution as the binary packages kept around are obsolete versions of a source package which causes problems with Multi-Arch parallel installability and also poses a security risk. In this particular case, src:hdf5 [1] no longer provides the binary package libhdf5-openmpi-dev for any 32-bit architecture since version 1.10.10+repack-4 which means the package is out-of-date for these architectures. If it wasn't for this bug in src:vtk9, DAK would have purged the 1.10.10+repack-3.3 packages already but they are kept around by the cruft mechanism until src:vtk9 has been fixed. Adrian > [1] http://ftp.debian.org/debian/pool/main/h/hdf5/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1078743: vtk9: BD-Uninstallable on 32-bit architectures after #1068320
Hello Paul, On Fri, 2024-11-01 at 21:59 +0100, Paul Gevers wrote: > Hi, > > On Thu, 15 Aug 2024 09:41:31 +0200 John Paul Adrian Glaubitz > wrote: > > the package src:vtk9 has become BD-Uninstallable on 32-bit architectures > > after > > the src:hdf5 package has dropped OpenMPI support for them in #1068320 [1]. > This seems to have been resolved somehow as a binNMU yesterday succeeded > at least on armel, armhf and i386. No, this can't resolve itself automatically as this is a hard-encoded build dependency. What you're seeing here is just the cruft mechanism of DAK in action which doesn't exist in Mini DAK which Debian Ports uses. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1085493: src:kiwi: unsatisfied build dependency in testing: python3-testinfra
Hi, On Sun, 2024-10-20 at 09:30 +0200, John Paul Adrian Glaubitz wrote: > The problem is that Kiwi upstream has decided to add tests that require > Kiwi to be installed on the target system and dh_python currently does > not support running tests like this. > > I have asked for help on the mailing lists - I forgot where - but there > was no one being able to help. So, unless someone helps me out getting > Kiwi's testsuite run with dh_python, I see no chance in updating the > package in the foreseeable future. I have finally sorted these issues out now and I have an up-to-date version of the kiwi package almost ready. It just needs a final do-over and then I'll upload it this weekend. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency
Hello, On Mon, 2024-06-10 at 08:14 +0200, John Paul Adrian Glaubitz wrote: > On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote: > > please package v10.0.21 and remove the obsolete python3-mock build > > dependency > > > > > https://github.com/testing-cabal/mock > > > > > > mock is now part of the Python standard library, available as > > > unittest.mock in Python 3.3 onward > > > > more information cab be find here: > > > > https://github.com/OSInside/kiwi/pull/2470 > > I have tried packaging the latest upstream version but I was unable to get the > testsuite to pass successfully as setting the proper PYTHONPATH for running > the testsuite did not work. I have finally figured this out now. It turned out to be far more trivial than initially I expected. I will update kiwi to the latest upstream version over the weekend and also remove the dependency on python3-mock. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1086227: gcc-snapshot: Missing versioned symbolic links for $ARCH-linux-gnu binaries
Source: gcc-snapshot Version: 1:20241004-1 Severity: normal Hi, while testing snapshot releases to help with the LRA transition of GCC upstream, I noticed that the gcc-snapshot package does not versioned symbolic links for the $ARCH-linux-gnu binaries, i.e. sh4-linux-gnu-g++-15 => sh4-linux-gnu-gcc Oddly, there are both a sh4-linux-gnu-gcc-15 and sh4-linux-gnu-gcc binary but the other versioned links (binaries) are missing. It would be good if these links could be fixed as packages like OpenJDK are looking for these versioned symbolic links. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1086221: openjdk-17: Please disable dtrace on sh4
Source: openjdk-17 Version: 17.0.13+11-2 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello, the configure script for openjdk-17 fails on sh4 with [1]: checking if JVM feature 'zgc' is available... no configure: error: Cannot continue configure: ERROR: Unavailable JVM features explicitly enabled for 'zero': 'dtrace' configure exiting with result code 1 This is because dtrace doesn't seem to be available on sh4. Can you please disable it for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=openjdk-17&arch=sh4&ver=17.0.13%2B11-2&stamp=1730111041&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1086023: binutils: Please drop cross-support for ia64
On Mon, 2024-10-28 at 02:04 +, Pedro Miguel Justo wrote: > > > On Oct 25, 2024, at 00:57, John Paul Adrian Glaubitz > > wrote: > > > > Thus, I suggest we drop cross-support for ia64 from binutils for the time > > being in order to reduce the footprint of the binutils package. > > > > This is sad but I think we have to come to terms with the fact that Itanium > has > moved from working platform to history books. For the very few of us fans, it > will be called Vintage. For everyone else, oblivion. > > It doesn't help that there isn't a proper software Itanium emulator - not one > to > the level of QEMU, for example. Or some piece of personal hardware that was > popular, > as it is the case for m68k. That might has helped keeping the platform alive. > With > just scant access to big iron physical servers, there is just no critical > mass to > keep the platform going just on ephemeral volunteer hours. It's simply not feasible to maintain a Linux distribution for an architecture where the majority of upstream projects have decided to explicitly remove support for it. For Itanium, it doesn't just affect the kernel and glibc but also projects such as Ruby, OpenJDK, WebKit and others which require explicit Itanium support in order to deal with the peculiarities of the architecture. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1086027: binutils: Please add cross-support for 32-bit sparc
Source: binutils Version: 2.43.1-5 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I would like to have a basic cross-toolchain for 32-bit sparc in Debian so that I can cross-compile rustc and the kernel for regular testing. The first package which needs to be enabled is binutils. The attached patch just does that, but feel free to adjust it to your needs. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru binutils/binutils-2.43.1/debian/control.in binutils-sparc/binutils-2.43.1/debian/control.in --- binutils/binutils-2.43.1/debian/control.in 2024-09-18 10:35:40.0 +0200 +++ binutils-sparc/binutils-2.43.1/debian/control.in2024-10-18 21:45:24.869593579 +0200 @@ -21,6 +21,7 @@ g++-powerpc64-linux-gnu [amd64 i386 s390x x32] , g++-riscv64-linux-gnu [amd64 arm64 i386 ppc64el s390x x32] , g++-sh4-linux-gnu [amd64 i386 x32] , + g++-sparc-linux-gnu [amd64 i386 x32] , g++-sparc64-linux-gnu [amd64 i386 x32] , g++-i686-linux-gnu [amd64 arm64 ppc64el s390x x32] , g++-x86-64-linux-gnu [arm64 i386 ppc64el s390x] , diff -Nru binutils/binutils-2.43.1/debian/rules binutils-sparc/binutils-2.43.1/debian/rules --- binutils/binutils-2.43.1/debian/rules 2024-08-18 13:01:48.0 +0200 +++ binutils-sparc/binutils-2.43.1/debian/rules 2024-10-18 16:16:16.122493650 +0200 @@ -104,7 +104,7 @@ NATIVE_ARCHS ?= amd64 i386 arm64 armhf armel ppc64el s390x NATIVE_ARCHS += alpha arc hppa ia64 loong64 m68k powerpc ppc64 \ - riscv64 sh4 sparc64 x32 + riscv64 sh4 sparc sparc64 x32 NATIVE_ARCHS += hurd-amd64 hurd-i386 #NATIVE_ARCHS += nios2 or1k s390 sparc @@ -125,17 +125,17 @@ CROSS_ARCHS ?= amd64 i386 x32 \ s390x ppc64el arm64 armhf armel \ alpha arc hppa loong64 m68k \ - powerpc ppc64 sh4 sparc64 \ + powerpc ppc64 sh4 sparc sparc64 \ ia64 riscv64 \ hurd-amd64 hurd-i386 else ifeq ($(DEB_HOST_ARCH),arm64) CROSS_ARCHS ?= amd64 armel armhf i386 powerpc ppc64el riscv64 s390x \ - alpha arc hppa loong64 m68k sh4 sparc64 x32 + alpha arc hppa loong64 m68k sh4 sparc sparc64 x32 else ifeq ($(DEB_HOST_ARCH),ppc64) CROSS_ARCHS ?= ppc64el else ifeq ($(DEB_HOST_ARCH),ppc64el) CROSS_ARCHS ?= powerpc ppc64 amd64 armel armhf arm64 i386 riscv64 s390x \ - alpha arc hppa loong64 m68k sh4 sparc64 x32 + alpha arc hppa loong64 m68k sh4 sparc sparc64 x32 else ifeq ($(DEB_HOST_ARCH),s390x) CROSS_ARCHS ?= amd64 armhf arm64 i386 riscv64 powerpc ppc64 ppc64el endif @@ -191,6 +191,7 @@ HOST_ARCHS_m68k = amd64 i386 x32 arm64 ppc64el HOST_ARCHS_ppc64 = amd64 i386 x32 ppc64el s390x HOST_ARCHS_sh4 = amd64 i386 x32 arm64 ppc64el +HOST_ARCHS_sparc = amd64 i386 x32 arm64 ppc64el HOST_ARCHS_sparc64 = amd64 i386 x32 arm64 ppc64el HOST_ARCHS_x32 = amd64 arm64 i386 ppc64el
Bug#1086023: binutils: Please drop cross-support for ia64
Source: binutils Version: 2.43.1-5 Severity: normal User: debian-i...@lists.debian.org Usertags: ia64 X-Debbugs-Cc: debian-i...@lists.debian.org Hello, the ia64 port was dropped from both glibc and the kernel upstream so that building anything beyond an old or forked kernel for ia64 has become rather cumbersome. However, anyone wanting to build the kernel can just use the toolchains provided by the kernel mirrors anyway [1]. Thus, I suggest we drop cross-support for ia64 from binutils for the time being in order to reduce the footprint of the binutils package. Dropping support from the GCC cross package is not necessary as ia64 was never supported in the first place. Thanks, Adrian > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1086022: gcc-14: Please disable the rust frontend on x32 temporarily
Source: gcc-14 Version: 14.2.0-7 Severity: normal Hello, the rustc compiler is currently broken on x32 due to an issue with LLVM and cargo is therefore not installable on this target. Could you disable the rust backend in gcc-14 and gcc-snapshot until the rustc issue has been fixed on x32? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033058: Booting mini.iso : kernel hangs on ppc64el
Hello, On Tue, 2024-10-22 at 12:37 +0200, John Paul Adrian Glaubitz wrote: > I have reopened this bug as this problem even shows on ppc64el again > with the latest netinst daily build downloaded from [1]. I have tested > the image on an IBM 8247-42L inside a PowerKVM virtual machine. Here is a short video which demonstrates the hang: > https://people.debian.org/~glaubitz/debian-bug-1033058.mp4 This was reproduced using the following installation image: > https://cdimage.debian.org/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1033058: Booting mini.iso : kernel hangs on ppc64el
Hello, I have reopened this bug as this problem even shows on ppc64el again with the latest netinst daily build downloaded from [1]. I have tested the image on an IBM 8247-42L inside a PowerKVM virtual machine. Removing the patch again fixes the problem for me. However, at least on big-endian ppc64, debian-installer does not accept any keyboard input after the language menu shows up. So, either the system has crashed at this point or there is something wrong with the input device. Adrian > [1] > https://cdimage.debian.org/mirror/cdimage/daily-builds/sid_d-i/current/ppc64el/iso-cd/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1085493: src:kiwi: unsatisfied build dependency in testing: python3-testinfra
Hello Paul, On Sun, 2024-10-20 at 08:58 +0200, Paul Gevers wrote: > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. To uphold our social contract, > Debian requires that packages can be rebuild from source in the suite > we are shipping them, so currently this is a serious issue with your > package in testing. The problem is that Kiwi upstream has decided to add tests that require Kiwi to be installed on the target system and dh_python currently does not support running tests like this. I have asked for help on the mailing lists - I forgot where - but there was no one being able to help. So, unless someone helps me out getting Kiwi's testsuite run with dh_python, I see no chance in updating the package in the foreseeable future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#805988: Build aboot-base on amd64
Hi JH, On Sat, 2024-10-19 at 11:17 +0200, jhcha54008 wrote: > Here is an updated set of patches. > > I haven't tested with schroot on amd64, nor to boot a real alpha workstation > - and I'm afraid it won't happen very soon. > > I hope it will help nevertheless ! Thanks a lot for all the work you put into fixing aboot. Due to the large list of patches, reviewing these patches will take some time, so I can't give you immediate feedback. I'll start with the review process next week and also give those patches a test on real hardware. We should also upstream as many patches as possible so that Gentoo and other interested distributions will profit from these improvements as well. PS: Do you mind using your full name for the git commit messages? Thanks a lot, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1085192: [Debian-on-mobile-maintainers] Bug#1085192: phoc: build-depends on missing: libwlroots-dev:loong64 (>= 0.17.0)
Hi Guido, On Wed, 2024-10-16 at 10:12 +0200, Guido Günther wrote: > How would that change anything? There is not libwlroots-dev >= 0.18.0. Hasn't phoc been ported to wlroots 0.18.0 yet? > Looks like the only solution would be to reintroduce wlroots 0.17 source > package as wlroots-0.17 so both source packages can live in parallel, > right? That would be possible, yes. But I assume the release would prefer to avoid that and rather have phoc ported to wlroots 0.18.0 and later. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1085192: phoc: build-depends on missing: libwlroots-dev:loong64 (>= 0.17.0)
Hello Dandan, On Wed, 2024-10-16 at 14:50 +0800, zhangdandan wrote: > The build status of phoc is BD-Uninstallable for loong64 and other > architectures in the Debian Package Auto-Building environment. Such bugs are actually rated as serious as it makes the package FTBFS on any architectures. Build-depending on cruft is not allowed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084159: Fwd: Accepted libgit2 1.8.2~rc1+ds2-1 (source) into unstable
Hi Timo, On Tue, 2024-10-15 at 21:13 +0200, Timo Röhling wrote: > * John Paul Adrian Glaubitz [2024-10-15 > * 21:04]: > > This solution is still suboptimal as it makes bootstrapping > > Debian from source needlessly harder. > > It is not really a solution but a stopgap, because > the original http-parser no longer works correctly [1]. OK, thanks for taking care of that. And I agree that a stopgap solution was necessary in this case. > > Since libgit2 is a transitive build dependency of rustc which > > is in turn a build dependency of many other packages, a lot of > > packages will be blocked to build unless the nodejs package has > > been built. > > > > The proper fix would be really to untie the llhttp C library from > > NodeJS. I don't really understand what the reason for tying a lean > > C library to such a big code base as NodeJS. It's like adding Libre > > Office as a build dependency to glibc. > > I agree with you 100%. Let's see how [2] pans out. Would be great if upstream could be convinced to untie the library. Adrian PS: Sorry for the accidental use of my work address. Oops. > [1] https://bugs.debian.org/1084223 > [2] https://bugs.debian.org/1081636 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084159: Fwd: Accepted libgit2 1.8.2~rc1+ds2-1 (source) into unstable
Hi Timo, On Tue, 2024-10-15 at 20:36 +0200, Timo Röhling wrote: > * Use vendored llhttp on architectures without nodejs (Closes: #1084223) This solution is still suboptimal as it makes bootstrapping Debian from source needlessly harder. Since libgit2 is a transitive build dependency of rustc which is in turn a build dependency of many other packages, a lot of packages will be blocked to build unless the nodejs package has been built. The proper fix would be really to untie the llhttp C library from NodeJS. I don't really understand what the reason for tying a lean C library to such a big code base as NodeJS. It's like adding Libre Office as a build dependency to glibc. Adrian
Bug#1084905: leptonlib: FTBFS on sparc64 due to unaligned access
Source: leptonlib Version: 1.84.1-4 Severity: normal Tags: upstream User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi, leptonlib currently fails to build from source on sparc64 due to unaligned access: FAIL: ioformats_reg === ioformats_reg /// leptonica-1.84.2 : libgif 5.2.2 : libjpeg 6b (libjpeg-turbo 2.1.5) : libpng 1.6.44 : libtiff 4.5.1 : zlib 1.3.1 : libwebp 1.4.0 : libopenjp2 2.5.0 Test bmp 1 bpp file: Bus error (core dumped) FAIL ioformats_reg (exit status: 138) with the following backtrace: #0 0xfff800010064f9b0 in pixReadMemBmp (cdata=0x1231160 "BMV\r", size=3414) at bmpio.c:181 181 ihbytes = convertOnBigEnd32(*(l_uint32 *)(bmpih)); (gdb) bt #0 0xfff800010064f9b0 in pixReadMemBmp (cdata=0x1231160 "BMV\r", size=3414) at bmpio.c:181 #1 0xfff80001006504dc in pixReadStreamBmp (fp=0x122c1d0) at bmpio.c:102 #2 0xfff80001007aa700 in pixReadStream (fp=0x122c1d0, hint=0) at readfile.c:329 #3 pixReadStream (fp=0x122c1d0, hint=0) at readfile.c:313 #4 0xfff80001007aa8b8 in pixRead (filename=0x1231140 "./weasel2.4c.bmp") at readfile.c:200 #5 pixRead (filename=0x1231140 "./weasel2.4c.bmp") at readfile.c:189 #6 0xfff80001007f538c in writeMultipageTiffSA (sa=0x1204ac0, fileout=0x1002aa8 "/tmp/lept/tiff/weasel_orig.tif") at tiffio.c:1579 #7 0xfff80001007f551c in writeMultipageTiff (dirin=0x1002860 ".", substr=0x1002ac8 "weasel2", fileout=0x1002aa8 "/tmp/lept/tiff/weasel_orig.tif") at tiffio.c:1536 #8 0x01001f1c in main (argc=, argv=) at mtiff_reg.c:270 This has already been reported upstream [1]. Thanks, Adrian > [1] https://github.com/DanBloomberg/leptonica/issues/750 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084865: opencv: FTBFS on alpha due to missing files during dh_install
Source: opencv Version: 4.6.0+dfsg-14 Severity: normal User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-al...@lists.debian.org Hello, opencv currently FTBFS on alpha due to missing files during dh_install [1]: dh_install -a dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz.hpp" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz.hpp dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz/*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz/* dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.a" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.a dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.so dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so.*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz406t64 missing files: usr/lib/*/libopencv_viz.so.* dh_install: error: missing files, aborting make: *** [debian/rules:126: binary-arch] Error 255 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 It's not clear to me at first sight why libopencv_viz.so.* is not built on alpha but it might be either an issue with outdated build dependencies - in that case the build dependencies should have a minimum version requirement - or an FTBFS issue with the package in general. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=alpha&ver=4.6.0%2Bdfsg-14&stamp=1728518202&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084783: RM: debian-installer [i386] -- ROM; i386 support goes away
Hi Cyril, On Tue, 2024-10-08 at 10:03 +0200, Cyril Brulebois wrote: > I have no opinion as to whether (not) cleaning up the installer-i386 > directory[1] should happen in an arch-specific manner. I'd expect having > both initial and current version in the bookworm directory[2] would be > sufficient in case someone needs a DeLorean. I would prefer keeping the source support for i386 in debian-installer to allow anyone interested to perform manual builds. Both the upstream toolchain and kernel still support 32-bit x86 after all. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084146: ausweisapp2: FTBFS against Qt 6.7.2
Hello Patrick, On Sat, 2024-10-05 at 18:56 +0200, Patrick Franz wrote: > your package fails to build against Qt 6.7.2 which has been uploaded > to unstable. The reason is that it uses obsolete package names for > its Qt 6 build-dependencies. > > All Qt 6 dev-packages are now called qt6-$MODULE-dev whereas some older > names were named e.g. libqt6svg6-dev leading to inconsistencies. > > I'm sorry about this, but this is my fault. I was planning to slowly phase > those old names out by first filing bugs against packages and then > removing the virtual packages. But it seems I missed your dependency > on libqt6shadertools6-dev before I removed it :-(. > > However, this fix is easy as no functional changes are expected. In your > case, simply change the following build-dependencies: > > * libqt6opengl6-dev -> can be removed as libqt6opengl6-dev has been merged > into qt6-base-dev. > * libqt6shadertools6-dev -> qt6-shadertools-dev > * libqt6svg6-dev -> qt6-svg-dev > * libqt6websockets6-dev -> qt6-websockets-dev > > After that, your package should build against Qt 6.7.2. Thanks for the heads-up and the instructions! I will take care of this later this week. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1084159: libgit2: Hardcoded dependency on liblhttp-dev prevents installation of libgit2-dev
Source: libgit2 Version: 1.8.2~rc1+ds-2 Severity: normal Hello, while libgit2 was recently switched back to http-parser, the binary package libgit2-dev still has a hardcoded dependency on liblhttp-dev which makes libgit2-dev uninstallable on all architectures without NodeJS support. Could you fix this with the next upload? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082970: ausweisapp: Issues in man pages of AusweisApp
Hello Helge,
On Sun, 2024-09-29 at 10:21 +, Helge Kreutzmann wrote:
> I'm now reporting the errors for your project. If future reports
> should use another channel, please let me know.
>
> Man page: AusweisApp.1
> Issue:can * also → can also
>
> "* A compatible NFC device (most NFC readers should work, NFC-enabled phones "
> "can * also be used)"
> --
> Man page: AusweisApp.1
> Issue:${TMP}/AusweisApp.*.log → I<${TMP}/AusweisApp.*.log>
>
> "By default, AusweisApp writes a log to a file matching ${TMP}/AusweisApp.*."
> "log. When the program terminates, it will be deleted. This setting prevents "
> "deletion."
>
> "Suppress writing a log file to ${TMP}/AusweisApp.*.log. Logs will still be "
> "written to STDOUT."
> --
> Man page: AusweisApp.1
> Issue:${TMP}/AusweisApp.EPIDE.port →
> I<${TMP}/AusweisApp.EPIDE.port>
>
> "Change the listening port for the WebSocket. Default is 24727. Selecting "
> "\"0\" is a special case. AusweisApp will then select a random port and write
> "
> "the port number to a file in ${TMP}/AusweisApp.EPIDE.port."
> --
> Man page: AusweisApp.1
> Issue:Lee Garrett (deb...@rocketjump.eu) → E<.MT deb...@rocketjump.eu>Lee
> GarrettE<.ME>
>
> "This man page was written by Lee Garrett (deb...@rocketjump.eu) for Debian "
> "(but may be used by others)."
Thanks for the bug report. But why not report this particular issue upstream?
The manpage is part of the upstream project source, not the Debian source [1].
I'm CC'ing one of the upstream authors.
Thanks,
Adrian
> [1] https://github.com/Governikus/AusweisApp/blob/community/docs/AusweisApp.1
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082800: python-greenlet: FTBFS on powerpc which is fixed in 3.1.1 upstream
Source: python-greenlet
Version: 3.1.0-1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hi,
python-greenlet currently FTBFS on powerpc during the testsuite [1]:
dh_auto_test
I: pybuild base:311: cd /<>/.pybuild/cpython3_3.12/build;
python3.12 -m unittest discover -v
test_break_ctxvars
(greenlet.tests.test_contextvars.ContextVarsTests.test_break_ctxvars) ...
Segmentation fault
E: pybuild pybuild:389: test: plugin distutils failed with: exit code=139: cd
/<>/.pybuild/cpython3_3.12/build; python3.12 -m unittest discover
-v
dh_auto_test: error: pybuild --test -i python{version} -p 3.12 returned exit
code 13
This is fixed in the upstream version 3.1.1 [2].
Thanks,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=python-greenlet&arch=powerpc&ver=3.1.0-1&stamp=1726870602&raw=0
> [2] https://github.com/python-greenlet/greenlet/blob/master/CHANGES.rst
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082603: Should aboot be removed from unstable?
On Mon, 2024-09-23 at 18:49 +0200, John Paul Adrian Glaubitz wrote: > > Not entirely sure it is exactly correct but it does build and does appear > > to put a reasonable set of files into the packages generated. > > That's not the main problem, but the fact that the code cannot be > cross-compiled: > > > https://github.com/mattst88/aboot/issues/5 > > and: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821332 > > aboot-cross depends on aboot-base, but aboot-base can only be fully built on > alpha: > > > https://salsa.debian.org/debian/aboot/-/blob/master/debian/rules?ref_type=heads > > palo does it correctly: > > > https://tracker.debian.org/pkg/palo > > So, it's really not just as trivial as removing one line. If it was, I would > have > done that long ago. To clarify this a little more: The problem is that the aboot-base package can only be built on alpha which means that alpha-cross becomes uninstallable on the other architectures as anything built on alpha is not available for release architectures. So, the proper fix would be to restructure the package such that the contents of aboot-base are made cross-buildable and thus fully available on any architecture which has a cross-compiler for alpha. See also the corresponding bug report for that change in palo: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851792 This particular issue is also part of the Debian Ports TODO list: > https://people.debian.org/~glaubitz/debian-ports-todo.txt So, if anyone is actually willing to help, please do. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082603: Should aboot be removed from unstable?
On Mon, 2024-09-23 at 11:58 -0400, Lennart Sorensen wrote: > > Fixing this bug requires a little more work and effort and it's on my TODO > > list. But since I am mostly doing this as a one-man show at the moment, it > > takes a little longer. > > Well doing this makes it compile on amd64 for me. > > diff -ru aboot-1.0~pre20200212/debian/compat > aboot-1.0~pre20200212.patched/debian/compat > --- aboot-1.0~pre20200212/debian/compat 2020-03-07 05:33:09.0 -0500 > +++ aboot-1.0~pre20200212.patched/debian/compat 2024-09-23 11:51:00.072830809 > -0400 > @@ -1 +1 @@ > -9 > +10 > diff -ru aboot-1.0~pre20200212/debian/rules > aboot-1.0~pre20200212.patched/debian/rules > --- aboot-1.0~pre20200212/debian/rules 2020-03-07 06:10:21.0 -0500 > +++ aboot-1.0~pre20200212.patched/debian/rules 2024-09-23 11:52:03.572991961 > -0400 > @@ -42,6 +42,7 @@ > $(MAKE) -C srmbootfat srmbootfat srmbootfat.1 CC=$(CC) $(shell > dpkg-buildflags --export=configure) > $(MAKE) -C doc/man > $(MAKE) -C doc/man/de > + $(MAKE) -C doc/faq > rename 's/([a-z]*).([1,5,8])/\1.de.\2/' doc/man/de/*.[1,5,8] > endif > > > Not entirely sure it is exactly correct but it does build and does appear > to put a reasonable set of files into the packages generated. That's not the main problem, but the fact that the code cannot be cross-compiled: > https://github.com/mattst88/aboot/issues/5 and: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821332 aboot-cross depends on aboot-base, but aboot-base can only be fully built on alpha: > https://salsa.debian.org/debian/aboot/-/blob/master/debian/rules?ref_type=heads palo does it correctly: > https://tracker.debian.org/pkg/palo So, it's really not just as trivial as removing one line. If it was, I would have done that long ago. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082614: node-undici: libllhttp-dev and libllhttp9.1 needed on port architectures
Hi Timo, On Mon, 2024-09-23 at 11:39 +0200, Timo Röhling wrote: > the libgit2 project recently moved from http_parser to llhttp as their > default > HTTP parser. Unfortunately, the transitive dependency on nodejs excludes > almost all port architectures from using libllhttp-dev as build dependency > [1]. > > One possible solution would be splitting off the native llhttp code to a > separate source package. Alternatively, a special build profile, e.g. > , might allow porters to build llhttp for > architectures lacking nodejs support. > > Please consider making libllhttp-dev available on more architectures, so that > libgit2 can switch without sacrificing architecture availability. Thanks for your bug report. I think we can merge this one with the one I previously reported as #1081636 [1]. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081636 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082603: Should aboot be removed from unstable?
Control: tags -1 + wontfix Hello Helmut, On Mon, 2024-09-23 at 05:51 +, Helmut Grohne wrote: > I suggest removing aboot from Debian for the following reasons: > * It accumulated one RC-bug: >+ #805988: aboot: FTBFS on amd64 when built with dpkg-buildpackage -A > Last modified: 1 year, 3 months > > * It is not part of bookworm or trixie and is not a key package. It's a key package for booting Debian on alpha, so we absolutely need it. Fixing this bug requires a little more work and effort and it's on my TODO list. But since I am mostly doing this as a one-man show at the moment, it takes a little longer. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1082305: webkit2gtk: Please remove compiler overrides for sh4
Source: webkit2gtk Version: 2.46.0-1 Severity: normal Tags: patch User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello, with GCC upstream being improved on sh4 thanks to the LRA switch [1], it's time to remove the compiler overrides for sh4 (and sh3): --- webkit2gtk-2.46.0/debian/rules.orig 2024-09-17 15:42:38.0 +0200 +++ webkit2gtk-2.46.0/debian/rules 2024-09-19 21:20:08.768120005 +0200 @@ -87,16 +87,6 @@ EXTRA_CMAKE_ARGUMENTS += -DWTF_CPU_ARM64_CORTEXA53=OFF endif -# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 -# and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 -ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) - CFLAGS := $(CFLAGS:-g1=-g0) - CFLAGS := $(CFLAGS:-O2=-O1) - CXXFLAGS := $(CXXFLAGS:-g1=-g0) - CXXFLAGS := $(CXXFLAGS:-O2=-O1) - CPPFLAGS += --param ggc-min-expand=10 -endif - ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) EXTRA_CMAKE_ARGUMENTS += -DUSE_SYSTEM_MALLOC=ON CPPFLAGS += -DRELEASE_WITHOUT_OPTIMIZATIONS Attaching a patch. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- webkit2gtk-2.46.0/debian/rules.orig 2024-09-17 15:42:38.0 +0200 +++ webkit2gtk-2.46.0/debian/rules 2024-09-19 21:20:08.768120005 +0200 @@ -87,16 +87,6 @@ EXTRA_CMAKE_ARGUMENTS += -DWTF_CPU_ARM64_CORTEXA53=OFF endif -# See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 -# and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 -ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) - CFLAGS := $(CFLAGS:-g1=-g0) - CFLAGS := $(CFLAGS:-O2=-O1) - CXXFLAGS := $(CXXFLAGS:-g1=-g0) - CXXFLAGS := $(CXXFLAGS:-O2=-O1) - CPPFLAGS += --param ggc-min-expand=10 -endif - ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) EXTRA_CMAKE_ARGUMENTS += -DUSE_SYSTEM_MALLOC=ON CPPFLAGS += -DRELEASE_WITHOUT_OPTIMIZATIONS
Bug#1065416: Bastian's offer in #1065416
Hi Matthias, On Sun, 2024-09-15 at 13:50 +0200, Matthias Klose wrote: > > It is trivial for us to add support for additional architectures once > > they are minimally supported in upstream Linux (we may also require > > that dpkg recognises their triplet; I'm not sure). There is no > > requirement that we define a kernel configuration for the architecture > > at the same time, or ever (see x32). > > > > Can we assume that new Debian Linux ports will be able to satisfy that > > or would that be a problem sometimes? > > CCing Adrian, he recently wanted to provide cross toolchains for > sparc-linux-gnu and ia64-linux-gnu, which the kernel doesn't provide > anymore. So a design which allows these toolchains would be helpful. I actually don't care about ia64 anymore as the architecture was beyond repair and upstream really wanted to get rid of it. Having said that, a cross-toolchain for 32-bit SPARC would be nice to have (binutils, glibc, gcc and linux-libc-dev) to perform regular integration tests for the sparc-unknown-linux-gnu target as well as the 32-bit SPARC kernel. 32-bit SPARC has been adapted as the Leon CPU for space applications such as satellites and space craft. Thanks to this, SPARC is also being actively maintained in the Linux kernel again and there is solid funding behind the port. Oracle also has some people actively maintaining the software stack for SPARC, allegedly even on Linux although the latter doesn't have high priority at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081542: FTBFS with Python 3.13
Source: python-greenlet Version: 2.0.2-1 Followup-For: Bug #1081542 Hello, just as a heads-up: This issue has been fixed upstream with version 3.1.0, so that this bug report can be closed once that version has been uploaded to unstable. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066996: python-greenlet: Please add patch to support sh4
Hello, On Sat, 2024-03-16 at 18:29 +0100, John Paul Adrian Glaubitz wrote: > the attached patch adds support for building python-greenlet on sh4, it's > a modified (fixed) version that is currently open for review upstream [1]. This patch has now been merged upstream such that this bug can be closed when updating to the recently released greenlet 3.1.0 or newer. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081636: node-undici: Please split out llhttp library into separate package
Source: node-undici Version: 5.28.4+dfsg1+~cs23.12.11-2 Severity: important Hello, while the libllhttp-dev package is being used by other packages such as libgit2, its source package, node-undici, has a transitive build dependency on NodeJS which means that libllhttp-dev can only be built on architectures where NodeJS is available. Since libllhttp-dev itself does not depend on NodeJS, it would be good if the llhttp library could be split out of the node-undici package so it can be built and used on any architecture, even where NodeJS is not available. This also eases the bootstrap process for new architectures. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081534: libgit2: Switch to libllhttp-dev massively reduces installability of libgit2
Source: libgit2 Version: 1.8.1+ds-1 Severity: important User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, libgit2 in experimental has been switched from libhttp-parser-dev to libllhttp-dev which massively reduced installability of libgit2 because the latter has a transistive dependency on nodejs which has only limited platform support. Please switch libgit2 back to libhttp-parser-dev for architectures that don't build libllhttp-dev because they don't have support for nodejs. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081515: gtk4: FTBFS on -ports architectures: many tests fail with --setup=wayland: Failed to open display
Hello Simon, On Thu, 2024-09-12 at 11:48 +0100, Simon McVittie wrote: > weston might be broken on all -ports architectures and functional on > all release architectures, but that level of coincidence seems a little > far-fetched. So my next theory for this is that something is consistently > different about the -ports buildds - perhaps their XDG_RUNTIME_DIR is > set up differently? - and that is causing > "debian/tests/run-with-display wayland" (or the copy of weston that it > runs) to fail? Thanks for the report. The configuration for the Debian Ports buildds is maintained via Puppet[1], the same applies to the release architectures [2]. So, if there is any relevant difference, it should be possible to find that in the Puppet configuration and make necessary changes to the Ports Puppet configuration. Adrian > [1] https://salsa.debian.org/debian-ports-team/dsa-puppet > [2] https://salsa.debian.org/dsa-team/mirror/dsa-puppet -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works
On Wed, 2024-09-04 at 18:51 +0100, Simon McVittie wrote: > I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether > we can use the new ORCJIT llvmpipe and remove the workaround for #1010838, > but it's taking a while (mips64el machines are not fast). So far it's > looking as though we will still get quite a lot of test failures. The powerpc/ppc64 porterbox perotto.debian.net should be considerably faster than any mips64el machine we have. So, you may give it a try there as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1079755: linux: Please disable CONFIG_CRASH_DUMP on powerpc
Source: linux Version: 6.10.6-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, in 75bc255a7444 [1] CONFIG_CRASH_DUMP was enabled by default for all architectures which made the kernel unbootable on 32-bit PowerPC (powerpc) since crash dump kernels cannot be booted from Open Firmware on this target [2]. Thus, please disable CONFIG_CRASH_DUMP on powerpc by default. We may have to disable it on m68k and sh4 as well, but I haven't verified that yet. Thanks, Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75bc255a7444801d64c7a7bd09e3f452f86b3585 > [2] https://lists.debian.org/debian-powerpc/2024/07/msg1.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#856877: schroot: regression presumably in 1.6.13-4 after fixing #856877
Hello, On Mon, 2024-08-19 at 16:46 +0100, Simon McVittie wrote: > What is the reproducer for this? > > - host system: is it testing, or unstable, or stable with a backport of > schroot 1.6.13-4, or what? Host system is unstable. > - host kernel seems to be 6.9.12-powerpc64 6.9.12-1 Yes. I can try with a different kernel if necessary. > - is there any other container/chroot/confinement going on, or is it > sbuild + schroot running on a real machine? It's sbuild + schroot on a real machine running unstable. > - is there a smaller reproducer for the problem than "build gcc", like > perhaps opening a schroot environment and running expect(1) in some > specified way? I haven't tried yet. > I initially provided the patch that was recently applied to schroot > back in 2017, and unfortunately I don't completely remember what I did > 7 years ago, but I think my usual reproducer for "do pseudo-terminals > work?" for #856877/#983423 was to run something like > "script -c 'cat /etc/os-release' /dev/null" inside a schroot. Okay, I can try that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#856877: schroot: Please consider mounting a new instance of /dev/pts
Package: schroot Followup-For: Bug #856877 Hello, this change seems to have broken pseudo-terminals for buildds [1]: The system has no more ptys. Ask your system administrator to create more. while executing "spawn true" expect is failing on your system with the above error, which means the GCC testsuite will fail. Please resolve the above issues and retry the build. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=ppc64&ver=14.2.0-3&stamp=1724003978&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1078743: vtk9: BD-Uninstallable on 32-bit architectures after #1068320
Source: vtk9 Version: 9.3.0+dfsg1-1 Severity: serious Justification: ftbfs Hello, the package src:vtk9 has become BD-Uninstallable on 32-bit architectures after the src:hdf5 package has dropped OpenMPI support for them in #1068320 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068320 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077724: fixed in adequate 0.16.7
Control: reopen -1 On Thu, 2024-08-01 at 22:49 +, Debian FTP Masters wrote: >* Add version constraint to Build-Depends: golang-go, for relatively new > stdlib packages (cmp and slices). Closes: #1077724. This is not what my bug report was about. Please replace "golang-go" with "golang-any" in Build-Depends. There is no reason to artificially limit the support for this package to architectures only which have Google's own Go compiler. See: https://buildd.debian.org/status/package.php?p=adequate&suite=sid Please use "golang-any". The FTBFS will fix itself on the other architectures once gccgo has been brought up to the Golang version that supports "cmd" and "slices". Thanks, Adrian
Bug#1077724: adequate: FTBFS with gccgo
Hello, On Thu, 2024-08-01 at 21:19 +0200, Serafeim Zanikolas wrote: > > src/salsa.debian.org/debian/adequate/binfmt.go:7:2: cannot find package > > "cmp" in any of: > > /home/glaubitz/adequate/adequate-0.16.5/_build/src/slices (from > > $GOPATH) > > that should be fixable on my end, by adding a version constraint on the > golang-go build dependency. Please build-depend on golang-any, not golang-go. The latter enforces the use of the Google Go compiler and blocks the use of golang-gccgo on targets where golang-go is not available. golang-any defaults to the Google Go compiler where available and on gccgo for the other platforms. > slices and cmp have been introduced in 1.21, and presumably gccgo is on 1.20 > (current version of gcc-defaults is 1.203) gccgo is on Go 1.18 with gcc-14: (sid_sparc64-dchroot)glaubitz@stadler:~/adequate/adequate-0.16.5$ go version go version go1.18 gccgo (Debian 14.1.0-5) 14.1.0 linux/sparc64 (sid_sparc64-dchroot)glaubitz@stadler:~/adequate/adequate-0.16.5$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077724: adequate: FTBFS with gccgo
Source: adequate Version: 0.16.5 Severity: normal Hello, I tried to build adequate with gccgo in order to make it available to more architectures but unfortunately the code isn't portable enough at the moment: CGO_CFLAGS="-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=. -Wformat -Werror=format-security" CGO_CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CGO_CXXFLAGS="-g -O2 -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=. -Wformat -Werror=format-security" CGO_FFLAGS="-g -O2 -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=." CGO_LDFLAGS="-Wl,-z,relro" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2873516682=/tmp/go-build -gno-record-gcc-switches -funwind-tables" cd _build && go install -trimpath -v -p 48 salsa.debian.org/debian/adequate salsa.debian.org/debian/adequate/private src/salsa.debian.org/debian/adequate/binfmt.go:7:2: cannot find package "cmp" in any of: /usr/src/cmp (from $GOROOT) /home/glaubitz/adequate/adequate-0.16.5/_build/src/cmp (from $GOPATH) src/salsa.debian.org/debian/adequate/adequate.go:13:2: cannot find package "slices" in any of: /usr/src/slices (from $GOROOT) /home/glaubitz/adequate/adequate-0.16.5/_build/src/slices (from $GOPATH) dh_auto_build: error: cd _build && go install -trimpath -v -p 48 salsa.debian.org/debian/adequate salsa.debian.org/debian/adequate/private returned exit code 1 make: *** [debian/rules:8: binary-arch] Error 1 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 Not sure whether this is an issue that should be reported with gccgo upstream or here. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi Liu, On Fri, 2024-07-26 at 17:09 +0800, Zixing Liu wrote: > > Now you're putting me under pressure. Are you in a hurry? > > No, I am not in a hurry. I just realized I might have made a mistake > by not opening a merge request on Debian Salsa since that may be a > more straightforward solution. > So, I wanted to let you know that I was fixing this mistake. OK, no worries. > Please take as much time as you need to test and upload the fix. I'm > sorry if my wording sounds like I am putting you under pressure, as > English isn't my native language, so miscommunication might have > happened there. > No, it's perfectly fine. I really appreciate your help. I currently have some motivation issues working on Debian but it's getting better now and I want to do it myself to be able to help overcome my mental barrier by forcing myself to do it. Apologies if I sounded harsh. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello, On Fri, 2024-07-26 at 12:14 +0800, Zixing Liu wrote: > I have also prepared > https://salsa.debian.org/debian/hfsutils/-/merge_requests/2 if you are > having issues with your local Git tree. > You can verify the merge with the version I uploaded to > https://mentors.debian.net/debian/pool/main/h/hfsutils/hfsutils_3.2.6-17.dsc. Now you're putting me under pressure. Are you in a hurry? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077042: gcc-14: FTBFS on m68k due to segfault compiling unwind-dw2.c
Source: gcc-14 Version: 14.1.0-5 Severity: normal Tags: upstream User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hi, gcc-14 fails to build from source on m68k due to the compiler segfaulting when compiling unwind-dw2.c. This issue is already being tracked upstream [1], I'm just reporting this bug to raise more awareness and help track the issue within Debian. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Ben, On Mon, 2024-07-22 at 00:07 +0200, Ben Hutchings wrote: > I don't know what differences there are between these builders that > might be relevant. For kapitsa, the installed host system is powerpc while all the others run the ppc64 port. As for the hardware: kapitsa runs bare-metal (inside an LPAR) on a POWER8 machine: root@kapitsa:~# grep model /proc/cpuinfo model : IBM,8284-22A root@kapitsa:~# Both blaauw and perotto are KVMs running on watson which runs Debian's ppc64el port (little-endian): root@watson:~# grep model /proc/cpuinfo model : 8247-42L root@watson:~# root@blaauw:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@blaauw:~# root@perotto:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@perotto:~# Both debian-project-be-01 and debian-project-be-02 are KVMs running on OpenStack at OSUOSL's OpenPOWER platform: root@debian-project-be-1:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-1:~# root@debian-project-be-2:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-2:~# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
On Sat, 2024-07-20 at 21:17 +0200, Ben Hutchings wrote: > I had a go yesterday and ran into the same problem. I couldn't > reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO + > DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of > the Debian kernel flavours. > > > Will take care of it and let you know when it's (some hours). > > Thank you! There are now 120 GB of free disk space. Let me know if that's sufficient or whether I need to clean up more, probably asking others to clean up their home directories. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Domenico, On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote: > > > Is there anything I can do to help? > > > > From the 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > file: > > > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > > --lang_exclude=rust .tmp_vmlinux.btf > > > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > > reproduce it here? > > I don't have access to the build host (blaauw2) and I've some doubts > it would still have that file. > > Maybe our kernel team and powerpc porters have suggestions? I have root access to all powerpc/ppc64 machines (buildds and porterbox). I'm cleaning up the porterbox now, disk is quite full, then you can try to build the kernel package on perotto.debian.net or I can try it myself. I have seen the bug myself and I wanted to debug it, but the attempt was foiled by the fact that the disk on perotto is full (again). Will take care of it and let you know when it's (some hours). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076536: wireshark: Please ignore tests on big-endian architectures in Debian Ports
Source: wirkshark Version: 4.2.6-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, like on s390x, some tests are failing on powerpc, ppc64 and sparc64: > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=powerpc&ver=4.2.6-1&stamp=1720790838&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=ppc64&ver=4.2.6-1&stamp=1720785055&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=sparc64&ver=4.2.6-1&stamp=1720858739&raw=0 Could you ignore the tests on all big-endian architectures in Debian Ports? These are: - hppa - m68k - powerpc - ppc64 - sparc64 Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Mon, 2024-07-01 at 20:05 +0200, John Paul Adrian Glaubitz wrote: > > After digging through the Debian BTS, I can see the patch may fix > > #421457 in BTS. > > Maybe you can edit my changelog entry to indicate that. > > Thanks for the suggestion. I will have a look. Sorry for not getting this > fixed, > there was a lot of work to be done in June. I have started working on this now and I just realized I messed a bit up in my packaging source git tree. So, it might take me a little longer to get this properly fixed up. I will import for patch crediting you, so thanks a lot for fixing this issue! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076424: ausweisapp: UI does not show
Hello Maximilian, On Tue, 2024-07-16 at 10:02 +0200, Maximilian Stein wrote: > I am using KDE on Debian testing and just tried to install and use the > ausweisapp. > > However, I cannot get a UI: When starting the program, the tray icon > appears alongside a notification that the application has been > started. Neither double clicking the tray icon nor right click + open > brings up the UI. Moreover, I tried to run `AusweisApp --show`, > without success. > > The log contains a couple of warnings: > > default 2024.07.16 09:49:52.433 13780 W (:0) >: QQmlApplicationEngine failed to > load component > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/Init/App.qml:483) : > qrc:/qt/qml/Governikus/Init/App.qml:483:4: Type DetachedLogView unavailable > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16) : > qrc:/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16:2: Cannot override > FINAL property > > So, maybe there is a dependency missing? This is a known issue that occurs when using AusweisApp 2.2.0 with Qt 6.6.0. It will be fixed in the upcoming 2.2.1 release. If upstream doesn't release this version in a timely fashion, I am going to backport the patch that fixes the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?
Source: bpfcc Version: 0.26.0+ds-1 Followup-For: Bug #1030657 Hi, looking at [1], the list of architectures is still very limited. Can we at least enable bpfcc on all architectures in Debian Ports? Since Debian Ports is not an officially supported distribution, there shouldn't be any concerns with regressions and bugs once they arise. If the lack of personal time to be able to spend on this package, I would suggest creating a bug report to request for help (RFH). Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=bpfcc&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060195: hfsprogs: install files into /usr (DEP17)
Hello, > On Jul 13, 2024, at 12:39 PM, Chris Hofstaedtler wrote: > > On Sun, Jan 07, 2024 at 12:07:02PM +0100, Chris Hofstaedtler wrote: >> Source: hfsprogs >> Version: 540.1.linux3-5 > [..] >> Please find a patch attached to install aliased files into /usr, >> for the currently ongoing UsrMerge effort [1]. > > Friendly reminder about this bug. > > Please consider fixing it soon. Did not notice this before. Will fix it this weekend. Adrian
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hi Otto, On Fri, 2024-07-05 at 23:00 -0700, Otto Kekäläinen wrote: > Thanks for the tips. Unfortunately running just the single test > without any other load on the system still crashes it and system load > was otherwise zero, so it is not due to slowness. Single-core performance on SPARC is rather poor, especially on older SPARC systems like this SPARC T4. So, if this test requires reasonanbly high single-core performance, you know why it fails on SPARC. We might get a newer, faster SPARC buildd in the near future though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hello Otto, On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote: > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed > on sparc64. > > Are there any sparc64 hackers interested in taking a look? > > The build itself passed and most of the post-build passes, but some > tests cause the database to crash. Stack traces are visible in the > logs: > > https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.4.2-2&stamp=1719891893&raw=0 > https://buildd.debian.org/status/logs.php?pkg=mariadb&arch=sparc64 I would suggest rerun the build plus testsuite on the porterbox stadler with glibc debug packages installed in the chroot so you can get a more usable backtrace. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi, On Mon, 2024-07-01 at 12:03 -0600, Zixing Liu wrote: > On Wed, Jun 12, 2024 at 3:27 PM John Paul Adrian Glaubitz > wrote: > > > > Hello Liu, > > > > On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > > > This patch does the following: > > > > > > * d/rules: switch to use the debhelper autoreconf template. > > > - d/rules: disable parallel testing. > > > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper > > > now. > > > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory > > > corruption > > > issues (LP: #493273). > > > > > > > > > Thanks for considering the patch. > > > > Thanks for your patch. I'll implement your changes in the weekend. > > > > After digging through the Debian BTS, I can see the patch may fix > #421457 in BTS. > Maybe you can edit my changelog entry to indicate that. Thanks for the suggestion. I will have a look. Sorry for not getting this fixed, there was a lot of work to be done in June. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386
Source: gcc-14 Version: 14.1.0-2 Severity: normal User: debian-h...@lists.debian.org Usertags: hurd-i386 X-Debbugs-Cc: debian-h...@lists.debian.org Hi, gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs [1]: configure: error: cargo is required to build rust Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=hurd-i386&ver=14.1.0-2&stamp=1718795837&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: fixed in cups 2.4.7-3
Hi Thorsten, On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote: >[ Thorsten Alteholz ] >* reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) >* debian/rules: no test on riscv64 (Closes: #1073046) Would be great if the testsuite could be disabled for sparc64 as well if there is no prospective fix for the testsuite failures in sight. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 10:33 +0200, Sune Stolborg Vuorela wrote: > On Friday, June 14, 2024 10:25:59 AM CEST John Paul Adrian Glaubitz wrote: > > I'm not denying that. However, a package named "qml6-module-qtquick-effects" > > doesn't sound like an interpreter to me. > > > > Thus, I don't really see how I am supposed to know as a maintainer what > > packages add Depends except for trial and error. Why not have one canonical > > "qt-interpretor" package or similar that applications can depend on? > > This is a module for a interpreted language. It is not much different than a > python package might need a hardcoded dependency on python-foo if it uses > that. or a perl package might need a hardcoded dependency on libperl-foo-bar- > baz if it uses the Foo::Bar::Baz perl module for important functionality. > > all qml*-module packages are qml (interpreted language) extensions. > > And yes. trial and error - or reading the sources - is for many interpreted > languages the only way of figuring it out. Ugh, that's truly a step backwards and way to add more burden to maintainers. I guess we'll be seeing plenty of such bug reports in the future when extensions get moved around or new ones get added. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote: > > Do we still have to build an unregisterised compiler for powerpc > > or can we switch back to NCG (https://bugs.debian.org/1060196)? > > I have not verified that yet. Please let's stay unregisterised for now > and have me verify first whether the NGC has been fixed with 9.6.x or > newer. > > Please let's keep this bug report open and use #1073159 [1] for adding > the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. GHC 9.6.5 still fails on powerpc with the NGC enabled: # rts/include/rts/prof/LDV.h | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o | Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o | Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '- package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc- 9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include - optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno- error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db - package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts - I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 ghc: panic! (the 'impossible' happened) GHC version 9.6.5: PPC.Ppr.pprInstr: JMP to ForeignLabel CallStack (from HasCallStack): panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register * Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library * Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library * Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o at cmd', called at src/Builder.hs:387:23 in main:Builder at cmdArgs, called at src/Builder.hs:540:8 in main:Builder at cmd
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 09:39 +0200, Sune Stolborg Vuorela wrote: > Control: severity -1 serious > > Missing dependencies are RC > > > This is a common problem with Qt6 and has been reported for a different > > dependency before, see [1]. > > It is normal for interpreted languages to have their dependencies managed > manually. This is just another version of that. I'm not denying that. However, a package named "qml6-module-qtquick-effects" doesn't sound like an interpreter to me. Thus, I don't really see how I am supposed to know as a maintainer what packages add Depends except for trial and error. Why not have one canonical "qt-interpretor" package or similar that applications can depend on? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073159: ghc: Please include --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS
Source: ghc Version: 9.4.7-5 Severity: important Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi, after debugging the segmentation faults with the unregisterised GHC on powerpc for a long time, I finally found the culprit which is the fact that GHC is built to default to the gold linker by default. The gold linker is known to be broken on some architectures which is unlikely to change in the future as the project has been abandoned by Google [1], so it has been long disabled for several architectures in debian/rules by passing the flag --disable-ld-override in EXTRA_CONFIGURE_FLAGS. However, as I learnt today, this only affects the linker choice when building GHC but not the default linker for the actual binary packages which still defaulted to gold in /usr/lib/ghc/lib/settings. As one of the upstream developers explained to me today [2], it's necessary to pass --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS as well in order to disable gold for the binary distribution, i.e. what will end up in the Debian package. Thus, please modify debian/rules to also include the flag --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS: --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH))) Also attaching a patch. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/Gold_(linker) > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/24986#note_570504 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote: > Great job! Thanks! > I completely missed the fact this needs to be passes to the bindist's > configure script as well. It took me forever to figure this out ;-). > You need to edit debian/rules here > https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 > and add the following line as well: > > + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override Yes, that's what I suggested, see my patch in [1]. > I will include that in the next upload. Great, thank you. I uploaded a patched version to unreleased in the mean time. > Do we still have to build an unregisterised compiler for powerpc > or can we switch back to NCG (https://bugs.debian.org/1060196)? I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Jeff, On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > Now we just need to figure out how to actually set the default linker back > > to bfd as it was actually explicitly supposed to happen according to > > debian/rules. > > > > This will most likely also unbreak GHC on m68k. > > Good job, Adrian. That's quite a bit of work to track down the issue. Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > This patch does the following: > > * d/rules: switch to use the debhelper autoreconf template. > - d/rules: disable parallel testing. > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper now. > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory corruption > issues (LP: #493273). > > > Thanks for considering the patch. Thanks for your patch. I'll implement your changes in the weekend. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
Control: severity -1 normal Hello Reinhard, On Wed, 2024-06-12 at 18:40 +0200, Reinhard Karcher wrote: > ausweisapp doesn't start the gui, because qml6-module-qtquick-effects > is not installed. It should depend on that package. > Installing qml6-module-qtquick-effects solves the problem. This is a common problem with Qt6 and has been reported for a different dependency before, see [1]. I haven't found a satisfactory solution as hard-coding a dependency as suggested in your bug report would mean that the package cannot undergo automatic transitions. I am therefore reducing the severity to normal as the package would otherwise be removed from testing. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070018#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: cups: FTBFS on riscv64 due to testsuite timeouts
Source: cups Version: 2.4.7-2 Severity: serious Tags: ftbfs Justification: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Hello, src:cups currently FTBFS on riscv64 due to a testsuite timeout [1]: Running command tests... Performing 5.1-lpadmin.sh: FAIL Performing 5.2-lpc.sh: PASS Performing 5.3-lpq.sh: FAIL Performing 5.4-lpstat.sh: FAIL Performing 5.5-lp.sh: FAIL Performing 5.6-lpr.sh: FAIL Performing 5.7-lprm.sh: FAIL Performing 5.8-cancel.sh: FAIL Performing 5.9-lpinfo.sh: FAIL Performing restart test: ./run-stp-tests.sh: 811: kill: No such process E: Build killed with signal TERM after 600 minutes of inactivity This issue has been observed on sparc64, so it seems reproducible. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=cups&arch=riscv64&ver=2.4.7-2&stamp=1718180226&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]
Hi Guillem, On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote: > > I had a look at this, and it seems like this package has never really > > worked on ARM systems at all? And this was hidden due to the missing > > declarations not being an error. > > > > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other > > systems have instead memory mapped I/O, but the code in mem.c is > > unconditionally calling port I/O functions such as in*() and out*(), > > provided by glibc. > > > > Until the upstream code is ported to systems with memory mapper I/O, I > > think the "best" way to resolve this would be to restrict the > > architecture list to: > > > > any-amd64 any-i386 alpha ia64 > > The attached patch implements this. It should not affect reverse build > depending packages (only hwinfo) which is already arch restricted to > «amd64 i386». > > I'm including the arm list to confirm the above, but also in case > someone there feels like porting the library to support memory mapped > I/O? (But perhaps that's not worth the effort.) It's perfectly fine to disable libx86emu on ARM as it has already been correctly stated, there are no I/O ports on ARM so the above code won't work on ARM. I also don't expect that to change in the future, so it's not worth bothering about this in the future, especially since the upstream project hasn't been very active lately [1]. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072940: mailtuils: FTBFS on sparc64 due to outdated symbols file
Source: mailutils Version: 1:3.17-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, mailutils fails to build from source on sparc64 due to an outdated symbols file [1]: dpkg-gensymbols: warning: debian/libmailutils9t64/DEBIAN/symbols doesn't match completely debian/libmailutils9t64.symbols --- debian/libmailutils9t64.symbols (libmailutils9t64_1:3.17-2_sparc64) +++ dpkg-gensymbolsjTYNfd 2024-06-09 13:24:35.314252567 + @@ -1928,6 +1928,7 @@ mu_py_script_run@Base 1:3.17 libmu_scm.so.9 libmailutils9t64 #MINVER# * Build-Depends-Package: libmailutils-dev + _etext@Base 1:3.17-2 _mu_scm_bugreport@Base 1:3.17 _mu_scm_debug@Base 1:3.17 _mu_scm_mailer@Base 1:3.17 dh_makeshlibs: error: failing due to earlier errors make[1]: *** [debian/rules:86: override_dh_makeshlibs] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary-arch] Error 2 Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=mailutils&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency
Hello, On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote: > please package v10.0.21 and remove the obsolete python3-mock build dependency > > > https://github.com/testing-cabal/mock > > > > mock is now part of the Python standard library, available as unittest.mock > > in Python 3.3 onward > > more information cab be find here: > > https://github.com/OSInside/kiwi/pull/2470 I have tried packaging the latest upstream version but I was unable to get the testsuite to pass successfully as setting the proper PYTHONPATH for running the testsuite did not work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072897: rustc: Please ignore test_arc_condvar_poison on powerpc
Source: rustc
Version: 1.75.0+dfsg1-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hi,
the test test_arc_condvar_poison hangs on powerpc for rustc 1.75.0 [1]:
test time::tests::instant_monotonic_concurrent ... ok
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
test sync::mutex::tests::test_arc_condvar_poison has been running for a long
time
E: Build killed with signal TERM after 150 minutes of inactivity
Please include the attached patch to ignore it for the time being.
Thanks,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=powerpc&ver=1.75.0%2Bdfsg1-4&stamp=1717703746&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
===
--- rustc-1.75.0+dfsg1.orig/library/std/src/sync/mutex/tests.rs
+++ rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
@@ -145,6 +145,7 @@ fn test_mutex_arc_condvar() {
}
}
+#[cfg(not(target_arch = "powerpc"))]
#[test]
fn test_arc_condvar_poison() {
let packet = Packet(Arc::new((Mutex::new(1), Condvar::new(;
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hello, On Sun, 2024-06-09 at 16:39 +0200, marillat wrote: > > This can be fixed by switching off vectorization in the »eigen« using the > > preprocessor > > macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line > > using the > > cmake variable COMPILE_DEFINITIONS: > > > > --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 > > 17:52:13.0 +0200 > > +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 > > @@ -9,6 +9,10 @@ > > cmake_extra_args += -DQT_HOST_PATH=/usr > > endif > > > > +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) > > + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" > > +endif > > + > > %: > > dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja > > > > With the above change, cmake defines the preprocessor macro > > EIGEN_DONT_VECTORIZE and > > the build succeeds on powerpc. > > With qt6-multimedia 6.6.2 qt6-multimedia still fail to build even with > this patch. > > I'm unable to find a solution. Adrian do you have an idea ? The syntax of my proposed solution was wrong. My local tests were not performed on a clean source which is why I did not notice the suggested syntax didn't work. The proper syntax is: ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) export DEB_CXXFLAGS_MAINT_APPEND = -DEIGEN_DONT_VECTORIZE endif @Patrick: Could you update the debian/rules file please to use the above syntax? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hi, On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote: > > > I will take care of this myself. Please remove the upload. > > Done. Thanks. > > > I will try to fix the package tomorrow. Apologies for the delay. > > I'll take this opportunity to point out #1060195, a similar bug in > hfsprogs. Thanks for the reminder. Appreciate it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote: > On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > > uploaded it to DELAYED/14. Please feel free to tell me if I > > should delay it longer. > > I will take care of this myself. Please remove the upload. Sorry for the brevity in my previous mail. The reason I didn't fix this bug was because I missed the bug notification mail, so I wasn't aware this bug was around. I will try to fix the package tomorrow. Apologies for the delay. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I > should delay it longer. I will take care of this myself. Please remove the upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051068: sysprof: Should mark test build dependencies as
On Tue, 2024-06-04 at 10:36 -0400, Jeremy Bícha wrote: > On Sat, Sep 2, 2023 at 4:22 PM Jeremy Bícha > wrote: > > > > Control: tags -1 moreinfo > > > > On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz > > wrote: > > > src:sysprof has multiple build dependencies in debian/control which are > > > required for running the testsuite only but yet these build dependencies > > > are not marked as to allow the package to be bootstrapped on > > > a new architecture. > > > > I was unable to identify any build dependencies like that. Please > > submit a merge proposal if you have specific improvements in mind. > > I am closing this bug since there has been no reply and there wasn't > enough information in this bug report to take any action. Hmm, I'm pretty sure that these were obvious. I will have to recheck. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability
Source: ipywidgets Version: 8.1.2-3 Severity: important Hello, the recent change to obsolete some binary packages in ipywidgets [1] introduced a hard dependency on nodejs which is available on a limited set of architectures only making ipywidgets uninstallable on a number of architectures: - alpha - hppa - hurd-amd64 - hurd-i386 - m68k - powerpc - ppc64 - sh4 - sparc64 - x32 Would it be possible to revert this change to remove the introduced dependency on nodejs again? Thanks, Adrian > [1] > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
OK, it seems that this is because of x32 being part of "rs_no_cpu" in debian/rules.defs. So, please remove x32 from the Rust exclusion list and add cargo to BuildDepends in debian/control. It remains to be resolved why the build tries to enable Rust support despite x32 being in "rs_no_cpu" in debian/rules.defs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, trying to build gcc-14 on x32 fails because the package gccrs-14-x86-64-linux-gnux32 is missing in debian/control so that the call to dh_installdirs fails: dh_installdirs -pgccrs-14-x86-64-linux-gnux32 usr/bin usr/share/man/man1 usr/libexec/gcc/x86_64-linux-gnux32/14 usr/share/lintian/overrides dh_installdirs: error: Requested unknown package gccrs-14-x86-64-linux-gnux32 via -p/--package, expected one of: gcc-14-base libgcc-s1 (...) gccrs-14-for-build gccrs-14 gcc-14-source dh_installdirs: error: unknown option or error during option parsing; aborting I assume the oversight was that on x32, the architecture is not used as a package prefix but a package suffix, i.e. gccrs-14-x86-64-linux-gnux32 instead of gccrs-14-x32-linux-gnu. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072336: gcc-14: FTBFS on x32 due to outdated symbols file libasan8.symbols
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, after installing cargo manually in the chroot to work around #1072327 [1], I ran into an FTBFS on x32 due to an outdated symbols file libasan8.symbols: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libasan8/DEBIAN/symbols doesn't match completely debian/libasan8.symbols --- debian/libasan8.symbols (libasan8_14.1.0-1_x32) +++ dpkg-gensymbolsRcyeWc 2024-06-01 08:50:52.822957692 + @@ -402,7 +402,7 @@ ___interceptor_setlocale@Base 14 ___interceptor_setpwent@Base 14 ___interceptor_setvbuf@Base 14 - ___interceptor_shmctl@Base 14 +#MISSING: 14.1.0-1# ___interceptor_shmctl@Base 14 ___interceptor_sigaction@Base 14 ___interceptor_sigaltstack@Base 14 ___interceptor_sigandset@Base 14 @@ -1579,7 +1579,7 @@ __interceptor_trampoline_setlocale@Base 14 __interceptor_trampoline_setpwent@Base 14 __interceptor_trampoline_setvbuf@Base 14 - __interceptor_trampoline_shmctl@Base 14 +#MISSING: 14.1.0-1# __interceptor_trampoline_shmctl@Base 14 __interceptor_trampoline_sigaction@Base 14 __interceptor_trampoline_sigaltstack@Base 14 __interceptor_trampoline_sigandset@Base 14 dh_makeshlibs: error: failing due to earlier errors I have uploaded the full gzipped build log in [2] since there were additional messages regarding symbols. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072327 > [2] http://people.debian.org/~glaubitz/gcc-14_14.1.0-1_x32.build.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1063735: python-maturin - upcoming rust-indexmap update.
Package: python-maturin Followup-For: Bug #1063735 Control: severity -1 serious Hello, I am setting the severity to serious now as this actually causes python-maturin to fails to build from source [1]: cargo generate-lockfile --offline error: failed to select a version for the requirement `indexmap = "^1.9.3"` candidate versions found which didn't match: 2.2.6 location searched: directory source `/usr/share/cargo/registry` (which is replacing registry `crates-io`) required by package `maturin v1.3.2 (/<>)` perhaps a crate was updated and forgotten to be re-vendored? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=python-maturin&arch=sparc64&ver=1.3.2-1&stamp=1717193660&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072328: gcc-14: Please add 32-bit SPARC (sparc) to ada_no_cpu
Source: gcc-14 Version: 14.1.0-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I am currently building a cross-compiler for 32-bit SPARC (sparc) and noticed that I had to disable Ada by adding "sparc" to "ada_no_cpu" in debian/rules.defs to get the compiler to build due to #1072071 [1]. Since I don't expect #1072071 to be fixed quickly, it would be good to just to add "sparc" to "ada_no_cpu" in debian/rules.defs. PS: Please note, this bug does not affect sparc64! There are no changes required for sparc64. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072071 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072327: gcc-14: Missing cargo build dependency on x32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, The gcc-14 source package is missing cargo as build dependency which is why the build currently fails with [1]: > configure: error: cargo is required to build rust cargo was briefly not available on x32, but is installable again. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=x32&ver=14.1.0-1&stamp=1715675531&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)
Hello, the suggested patch is incomplete as it breaks the installation of ptp-helper on architectures with Rust support by just removing it from the .install file. I have improved the patch in this regard by employing dh-exec and extended it for the remaining Debian Ports architectures without Rust support (alpha, m68k and sh4). I intentionally omitted ia64 as it will be dropped from Debian Ports within the next days. NB: For dh-exec to work, the file libgstreamer1.0-0.install *must* be executable. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gstreamer1.0-1.24.3/debian/changelog new/gstreamer1.0-1.24.3/debian/changelog --- old/gstreamer1.0-1.24.3/debian/changelog 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/changelog 2024-05-28 07:57:26.535826780 +0200 @@ -1,3 +1,9 @@ +gstreamer1.0 (1.24.3-1+ports) unreleased; urgency=medium + + * Disable rustc for unsupported architectures + + -- John Paul Adrian Glaubitz Tue, 28 May 2024 07:57:09 +0200 + gstreamer1.0 (1.24.3-1) unstable; urgency=medium * New upstream version 1.24.3 diff -Nru old/gstreamer1.0-1.24.3/debian/control new/gstreamer1.0-1.24.3/debian/control --- old/gstreamer1.0-1.24.3/debian/control 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/control 2024-05-28 11:16:10.247257446 +0200 @@ -6,6 +6,7 @@ Sjoerd Simons , Marc Leeman , Build-Depends: debhelper-compat (= 13), + dh-exec, dh-sequence-gir, meson (>= 0.62), pkgconf, @@ -18,7 +19,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!alpha !hppa !m68k !sh4], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, diff -Nru old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install --- old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-05-28 07:55:56.540429867 +0200 @@ -1,5 +1,6 @@ +#!/usr/bin/dh-exec usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper +[!alpha !hppa !m68k !sh4] usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale diff -Nru old/gstreamer1.0-1.24.3/debian/rules new/gstreamer1.0-1.24.3/debian/rules --- old/gstreamer1.0-1.24.3/debian/rules 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/rules 2024-05-28 09:39:31.503804282 +0200 @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),alpha hppa m68k sh4)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst
Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada
Source: gcc-13 Version: 13.2.0-25 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc) with Ada enabled. The build failed with a linker failure which indicates that linking against libatomic is required: checking float.h presence... yes checking for float.h... yes checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: undefined reference to `__atomic_compare_exchange_8' collect2: error: ld returned 1 exit status Such a patch already exists for armel [1], so it should be easy to extend it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected, linking against libatomic is therefore not required. Thanks, Adrian > [1] > https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
gt; https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html > > In general I thought that UEFI was derived from EFI, so I don't really > see, why both can't coexist together. But I might have to do further > research on that. Apart from that, ELILO is working perfectly fine both > for diskless boots and booting from disk. ELILO is unmaintained and has had various issues and bugs in the past which is why I switched to GRUB on Debian back then. But it also looks like that ia64 support is going to stay in GRUB for a while, I haven't seen any new efforts for removing it lately on the grub-devel mailing list. > > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual > >address space found on x86_64; > > Yes, it was done earlier than x86_64. > > > this causes problems with languages like > >JavaScript which use tagged pointers to encode type information in the > >bits unused on x86_64, see: > > > >> https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) > > > >(NB: This is expected to improve in the future as x86_64 optionally > > supports > > larger virtual address spaces in the kernel nowadays as well). > > > > - the math error handling ABI on ia64 in glibc is different from other > > architectures > >and the code for it in sysdeps/ia64/fpu/libm_error.c is quite > > convoluted; as glibc > >tries to unify and simplify FPU error handling, the different semantics > > of the ia64 > >ABI would require - quoting Adhemerval here - »a lot boilerplate and > > mechanical > >changes« which he doesn't think is worth the effort > > I think we could have done more in this regard, if ia64 support wouldn't > have been removed from Linux last year, requiring additional work > everywhere. But I don't complain, I think it also forced our hands. Well, I have done a lot of work in this regard in the past to get JavaScript fixed on targets with virtual address space sizes beyond 48 bits. But it's still not fixed everywhere, especially not in Qt5. It has been fixed in Qt6 though. > > There are probably more issues and quirks that I don't remember, but I > > think the list > > above already mentions enough show stoppers which mean that upstream > > projects won't be > > willing to re-add support for the architecture. > > Thanks for your assessment. I consider that much more useful than to > advise people against working on ia64. I'm not advising against you to do anything. You are free to spend your free time with whatever you want and if you think that keeping ia64 is worth the effort, more power to you! All I did was giving an elaborate explanation why ia64 is going to be removed from Debian within the next days and why I personally think it's a lost cause. > > Of course, I am not going to stop you from continuing your work and I think > > such efforts > > are always laudable. I just don't think the very limited interest in this > > architecture > > will be enough to overcome the difficulties that ia64 maintainers have to > > face. > > > > This is also the reason why the ia64 maintainers of neither Debian nor > > Gentoo were against > > the removal of support for the architecture in Ruby, the Linux kernel, > > glibc and so on. > > Being not against something and taking care of something are two > different things. But why would maintainers start an argument with upstream developers over something they don't really care about? That makes no sense. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
Hello Frank, On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote: > > ia64 support has been removed from glibc, the Linux kernel and soon gcc, > > First - ia64 support was actually removed from the glibc **because** it > was removed from Linux. It was also removed because there was no maintainer for it in glibc and suffered from a lot of testsuite failures. I tried for a long time to convince Adhemerval to fix these issues, but he explained that it would involve rewriting large parts of the math code for ia64 which he thought wasn't worth the effort. > Second, how did you come to the conclusion that ia64 support will be > removed from the gcc soon? gcc usually drops support for a target when it's no longer present in the kernel and glibc. That happened in the past and that will happen in the future, although there are some targets like Blackfin, CRIS and M32R that are still supported by gcc while being dropped by the kernel. And since ia64 support has already been marked as deprecated, I expect it to be removed from gcc soon. Especially, since ia64 adds a lot of complexity to gcc due to its VLIW design. > Rene said he would step up as maintainer for ia64 in gcc - see the > thread at [1] - and I haven't heard any different since then. > > [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html > > @Rene: Can you confirm? As of now, gcc is still marked as deprecated: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273 > > so it will be removed within the next weeks after we have made an archive > > copy. > > > > There is no need to fix any bugs on ia64. > > Let me correct that for you: > > There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as > that is. Have you already sorted out who is going to maintain ia64 support in glibc and the Linux kernel? And do you already know how to get Ruby upstream to re-add ia64 support? Ruby is required for a lot of other packages that depend on it. As someone who has been maintaining many exotic or deprecated architectures both in Debian and in the Linux kernel, I know how much work it involves to keep a port alive and running. And since I have also maintained ia64 in the past and know about all the quirks and problems the port has, I think the possibility that the port will ever return upstream to the kernel, glibc and the Ruby interpreter is nearly zero. To summarize the known issues and quirks on ia64: - ia64 has two stacks growing in opposite directions making exception handling in languages like Ruby more complicated and requiring additional code, see: > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for IA64) - the VLIW design adds a lot of complexity to the compiler; when it was created, designers expected the design to be superior but it turned out that the implementation was more challenging than expected and left gcc with a lot of unresolved problems on ia64, see: > https://gcc.gnu.org/projects/ia64.html - ia64 comes with its own implementation of EFI which is not fully compatible with UEFI and requires additional support code; this was the main reason why some GRUB developers wanted to get rid of ia64 support, see: > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual address space found on x86_64; this causes problems with languages like JavaScript which use tagged pointers to encode type information in the bits unused on x86_64, see: > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) (NB: This is expected to improve in the future as x86_64 optionally supports larger virtual address spaces in the kernel nowadays as well). - the math error handling ABI on ia64 in glibc is different from other architectures and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as glibc tries to unify and simplify FPU error handling, the different semantics of the ia64 ABI would require - quoting Adhemerval here - »a lot boilerplate and mechanical changes« which he doesn't think is worth the effort There are probably more issues and quirks that I don't remember, but I think the list above already mentions enough show stoppers which mean that upstream projects won't be willing to re-add support for the architecture. Of course, I am not going to stop you from continuing your work and I think such efforts are always laudable. I just don't think the very limited interest in this architecture will be enough to overcome the difficulties that ia64 maintainers have to face. This is also the reason why the ia64 maintainers of neither Debian nor Gentoo were against the removal of support for the architecture in Ruby, the Linux kernel, glibc
Bug#970043: Request to help test ia64 build for galera-4
Hi Otto, On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote: > I have a patch to tentatively fix Debian package galera-4 builds on > ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 > > Would anybody be interested in helping out and testing if the build > fully passes now? > > Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 ia64 support has been removed from glibc, the Linux kernel and soon gcc, so it will be removed within the next weeks after we have made an archive copy. There is no need to fix any bugs on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071542: boost1.83: Please enable context library on ppc64
Source: boost1.83 Version: 1.83.0-2.1+b1 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, the context library is not being installed on ppc64 in debian/control despite being enabled in debian/rules. Please add ppc64 to the list of supported architectures for the context library and make sure it's actually being built and installed. Tests can be performed on the porterbox perotto.debian.net. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071524: git: Please add patch to fix testsuite on sparc64
Source: git
Version: 1:2.45.1-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hello,
the attached patch fixes the Git testsuite on sparc64. I've already
sent it upstream [1]. Could you include it for the next package
upload?
Thanks,
Adrian
> [1]
> https://lore.kernel.org/git/2024052009.99882-1-glaub...@physik.fu-berlin.de
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 6580fdb9004e2d61fcb3d1f04c31bc7e328ed442 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Mon, 20 May 2024 13:03:49 +0200
Subject: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on
Linux SPARC
On SPARC systems running Linux, individual processors are denoted with
"CPUnn:" in /proc/cpuinfo instead of the usual "processor NN:" so that
the current regexp in ncores() returns 0. Extend the regexp to match
lines with "CPUnn:" as well to properly detect the number of available
cores on these systems.
Signed-off-by: John Paul Adrian Glaubitz
---
t/chainlint.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/chainlint.pl b/t/chainlint.pl
index 556ee91a15..63cac942ac 100755
--- a/t/chainlint.pl
+++ b/t/chainlint.pl
@@ -718,7 +718,7 @@ sub ncores {
# Windows
return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
# Linux / MSYS2 / Cygwin / WSL
- do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';
+ do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:||^CPU[\d]*:/, <>)); } if -r '/proc/cpuinfo';
# macOS & BSD
return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
return 1;
--
2.39.2
Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down
Hello, On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on arm64. > (...) > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240420&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. FWIW, I am already working on updating the kiwi package in Debian to the latest upstream version. However, I ran into some testsuite issues that need to be sorted out upstream first [1]. Thanks, Adrian > [1] https://github.com/OSInside/kiwi/issues/2548 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054109: ocaml: lack of LoongArch support
Hi LiXing, > [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)] I'm afraid this patch is way too large to be included in a Debian package. Please make sure these changes are being upstreamed, so that native LoongArch support will be part of the next major Ocaml upstream release in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)
On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote: > Hi, > > [John Paul Adrian Glaubitz 2020-05-10] > > I would like to adopt this package. There is a new upstream available and > > the > > repository has been moved to Github with some recent activity [1]. > > What came out of this intent? > > I just migrated the package to a git repository on > https://salsa.debian.org/debian/unadf >. I started working on this, but I got stuck because of the fact that the upstream package is actually not just unadf but a whole library that might need different treatment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
