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=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please 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#1066216: hfsutils: diff for NMU version 3.2.6-15.1
On Sun, 2024-04-14 at 12:57 +0200, Sebastian Ramacher wrote: > I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Yes, please set it to 14 days. I am currently going through all my packages one after another to fix these issues. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066383: virtualjaguar: FTBFS: ./inlines.h:82:20: error: implicit declaration of function ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration]
Control: tags -1 +patch
Hi,
On Wed, 2024-03-13 at 12:46 +0100, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > gcc -MMD -g -O2 -Werror=implicit-function-declaration
> > -ffile-prefix-map=/<>=. -fstack-protector-strong
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> > -I. -I./obj `sdl-config --cflags` -c obj/cpustbl.c -o obj/cpustbl.o
> > In file included from obj/cpustbl.c:3:
> > ./inlines.h: In function ‘m68k_do_rts’:
> > ./inlines.h:82:20: error: implicit declaration of function
> > ‘m68k_read_memory_32’ [-Werror=implicit-function-declaration]
> >82 | m68k_setpc(m68k_read_memory_32(m68k_areg(regs, 7)));
> > |^~~
> > ./inlines.h: In function ‘m68k_do_bsr’:
> > ./inlines.h:89:9: error: implicit declaration of function
> > ‘m68k_write_memory_32’ [-Werror=implicit-function-declaration]
> >89 | m68k_write_memory_32(m68k_areg(regs, 7), oldpc);
> > | ^~~~
> > ./inlines.h: In function ‘get_ibyte_prefetch’:
> > ./inlines.h:111:25: error: implicit declaration of function
> > ‘m68k_read_memory_8’ [-Werror=implicit-function-declaration]
> > 111 | #define get_ibyte(o)m68k_read_memory_8(regs.pc + (o) + 1)
> > | ^~
> > ./inlines.h:158:16: note: in expansion of macro ‘get_ibyte’
> > 158 | return get_ibyte(o);
> > |^
> > ./inlines.h: In function ‘get_iword_prefetch’:
> > ./inlines.h:112:25: error: implicit declaration of function
> > ‘m68k_read_memory_16’ [-Werror=implicit-function-declaration]
> > 112 | #define get_iword(o)m68k_read_memory_16(regs.pc + (o))
> > | ^~~
> > ./inlines.h:183:16: note: in expansion of macro ‘get_iword’
> > 183 | return get_iword(o);
> > |^
> > cc1: some warnings being treated as errors
> > make[2]: *** [Makefile:58: obj/cpustbl.o] Error 1
Thanks for the bug report! The attached patch fixes the problem for me. I'm
going to upload
an updated packages soon which will also include fixes for #1038585 [1].
Adrian
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038585
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From d0c699e0c6a0781a6dd2f89492b38f9a1d50fa9c Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Sat, 13 Apr 2024 11:18:38 +0200
Subject: [PATCH] Fix missing inclusion of m68kinterface.h in
src/m68000/inlines.h
---
src/m68000/inlines.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/m68000/inlines.h b/src/m68000/inlines.h
index 54de932..c037bd9 100644
--- a/src/m68000/inlines.h
+++ b/src/m68000/inlines.h
@@ -11,6 +11,7 @@
#define __INLINES_H__
#include "cpudefs.h"
+#include "m68kinterface.h"
STATIC_INLINE int cctrue(const int cc)
{
--
2.44.0
Bug#1067141: kcemu: FTBFS with -Werror=implicit-function-declaration
Hello Zixing, On Wed, 2024-04-10 at 17:34 -0600, Zixing Liu wrote: > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/add-missing-includes.patch: Add missing includes. > Closes LP: #2060887. The issue has already been fixed upstream. I am waiting for upstream to make a new release as this would also fix #970666 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970666 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1067386: anymarkup-core: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: reassign -1 src:python-flexmock Control: merge -1 1067358 Hi Lucas, On Wed, 2024-03-20 at 21:56 +0100, Lucas Nussbaum wrote: > > ERRORS > > > > _ ERROR collecting > > .pybuild/cpython3_3.12_anymarkup-core/build/test/test_libs_not_installed.py > > _ > > test/test_libs_not_installed.py:1: in > > from flexmock import flexmock > > /usr/lib/python3/dist-packages/flexmock/__init__.py:2: in > > from flexmock import _integrations # pylint: disable=unused-import > > /usr/lib/python3/dist-packages/flexmock/_integrations.py:101: in > > saved_pytest = runner.call_runtest_hook > > E AttributeError: module '_pytest.runner' has no attribute > > 'call_runtest_hook' > > === short test summary info > > > > ERROR test/test_libs_not_installed.py - AttributeError: module > > '_pytest.runne... > > Interrupted: 1 error during collection > > > > === 1 error in 0.21s > > === > > I think this is the same bug you reported in #1067358 [1]. anymarkup-core is affected since it uses python-flexmock as a build-dependency. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067358 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066995: pulseaudio: FTBFS with _TIME_BITS=64 on 32-bit systems
Source: pulseaudio Version: 16.1+dfsg1-3 Severity: serious Tags: upstream Justification: ftbfs User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi, pulseaudio fails to built from source with _TIME_BITS=64 [1]: [632/648] cc -Isrc/utils/libpulsedsp.so.p -Isrc/utils -I../src/utils -I. -I.. -Isrc -I../src -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11 -g -O2 -Werror=implicit-function-declaration -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 -fPIC -pthread -DHAVE_CONFIG_H -D_GNU_SOURCE -Wno-nonnull-compare -MD -MQ src/utils/libpulsedsp.so.p/padsp.c.o -MF src/utils/libpulsedsp.so.p/padsp.c.o.d -o src/utils/libpulsedsp.so.p/padsp.c.o -c ../src/utils/padsp.c FAILED: src/utils/libpulsedsp.so.p/padsp.c.o cc -Isrc/utils/libpulsedsp.so.p -Isrc/utils -I../src/utils -I. -I.. -Isrc -I../src -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11 -g -O2 -Werror=implicit-function-declaration -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 -fPIC -pthread -DHAVE_CONFIG_H -D_GNU_SOURCE -Wno-nonnull-compare -MD -MQ src/utils/libpulsedsp.so.p/padsp.c.o -MF src/utils/libpulsedsp.so.p/padsp.c.o.d -o src/utils/libpulsedsp.so.p/padsp.c.o -c ../src/utils/padsp.c In file included from /usr/include/features.h:393, from /usr/include/endian.h:21, from /usr/include/linux/soundcard.h:43, from /usr/include/powerpc-linux-gnu/sys/soundcard.h:1, from ../src/utils/padsp.c:33: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" 26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" | ^ This needs to be fixed for the time_t transition [2]. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=pulseaudio=powerpc=16.1%2Bdfsg1-3%2Bb1=1710500596=0 > [2] https://wiki.debian.org/ReleaseGoals/64bit-time -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 # This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. ## Configuration file for PulseAudio clients. See pulse-client.conf(5) for ## more information. Default values are commented out. Use either ; or # for ## commenting. ; default-sink = ; default-source = ; default-server = ; default-dbus-server = ; autospawn = yes ; daemon-binary = /usr/bin/pulseaudio ; extra-arguments = --log-target=syslog ; cookie-file = ; enable-shm = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; auto-connect-localhost = no ; auto-connect-display = no # This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. ## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for ## more information. Default values are commented out. Use either ; or # for ## commenting. ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; enable-memfd = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-scr
Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2
Hi Adrian, On Sun, 2024-03-03 at 18:13 +0200, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1 > > ... > /<>/src/card/pcsc/PcscUtils.h:112:46: error: > ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean > ‘SCARD_E_UNKNOWN_RES_MSG’? > 112 | Scard_E_Unknown_Res_Mng = > returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error code > was returned from a layered component. */ > | ^~~ > ... > > > This is not a regression in the new ausweisapp2 upload, > but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed): > > https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237 > "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG" I've already seen that and also notified upstream. He is also now CC'ed here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1062333: discover: NMU diff for 64-bit time_t transition
Hi, On Thu, 2024-02-01 at 04:31 +, mwhud...@debian.org wrote: > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for discover > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. Isn't a 0-day a bit too tight to give the maintainer some chance to answer? Since this package is owned by the installer-team, I would suggest sending a pull request on salsa instead [1]. Adrian > [1] https://salsa.debian.org/installer-team/discover -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1055066: usrmerge: Cannot update to version 38 on sbuild
Control: reopen -1 Control: reassign -1 src:debootstrap Hello! On Tue, 2023-10-31 at 09:02 +0100, John Paul Adrian Glaubitz wrote: > Could it be that debootstrap needs to be switched to enabled usrmerge by > default? I can confirm that passing --merged-usr to debootstrap fixes the problem. Reopening the bug and assigning accordingly. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1055066: usrmerge: Cannot update to version 38 on sbuild
Hello! I am not sure whether this issue has been fixed. We're seeing this issue on buildds and porterboxes on Debian Ports, regenerating the chroots fails: dpkg: warning: ignoring pre-dependency problem! Preparing to unpack .../tar_1.34+dfsg-1.2_ppc64.deb ... Unpacking tar (1.34+dfsg-1.2) ... Selecting previously unselected package usr-is-merged. Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Selecting previously unselected package util-linux. dpkg: regarding .../util-linux_2.39.2-5_ppc64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libblkid1 (>= 2.37.2) libblkid1:ppc64 is unpacked, but has never been configured. Could it be that debootstrap needs to be switched to enabled usrmerge by default? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022
> On Jun 18, 2023, at 3:53 PM, Simon McVittie wrote: > > On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote: >> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can >> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must >> have triggered a regression between September 2022 and now. > > It would be helpful if someone with suitable hardware could put this > through debbisect or similar to find out which build-dependency triggered > this. TIL about debbisect. I can try to bisect this on big-endian PowerPC, I have root on multiple big-endian machines. Adrian
Bug#1011530: FTBFS: fails to include system headers
Hello! On Tue, 2023-05-16 at 22:13 +0200, Bastian Germann wrote: > I am uploading a NMU to fix this. > Please find the debdiff attached. Please don't do NMUs without using a delay [1]. I did not get a chance to review your change. Adrian > [1] https://ftp-master.debian.org/deferred.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1025848: src:kiwi: unsatisfied build dependency in testing: python3-testinfra
Hello Paul! On 12/10/22 15:13, 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. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. I'm not sure what the point of this bug report is. If any of the build dependencies are missing because someone reported a RC bug against it, it's not really my job to fix that particular bug. There is no apparent bug in kiwi that I know of, so I don't see what the purpose of this bug report is and what I am supposed to do except maybe go talk to the maintainer of python3-testinfra to tell him to fix their bugs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1018039: FTBFS on ppc64el with gcc-12
Hi! On 8/24/22 16:50, Frédéric Bonnard wrote: powerpc-utils 1.3.9-1 fails to build atm with gcc-12. I checked latest 1.3.10 and it's roughly the same. I've opened an issue upstream. Interestingly, the error due to "-Werror=maybe-uninitialized" does not show on the openSUSE builds, see [1]. openSUSE does not ship any patch to address the issue though. Fedora doesn't seem to have a patch to address the issue either [2]. Also, no update from upstream either. Adrian [1] https://build.opensuse.org/package/live_build_log/hardware/powerpc-utils/openSUSE_Factory_PPC/ppc64le [2] https://src.fedoraproject.org/rpms/powerpc-utils/tree/rawhide -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0
Hello Agathe! On 5/17/22 18:48, Agathe Porte wrote: > I do not know when that was done, but the two latest Fedora releases have > been using >=35 > versions which properly support OpenSSL 3.0 [1]. I have opened #1011155 in > order to discuss > why we cannot just update to latest upstream versions, if that is the case, > and to not pollute > this thread. At least for Debian Ports, updating to python-cryptography 35 or newer would mean that the package becomes BD-Uninstallable, i.e. not buildable as the Rust compiler is not available on all architectures yet. Rust support is slowly coming to more architectures with the rustc_codegen_gcc backend and gccrs, so this problem will be eventually resolved. However, this work is not completed yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0
Control: reopen -1 On 5/17/22 08:50, John Paul Adrian Glaubitz wrote: > I just noticed the patches for OpenSSL 3.0 support have already been added to > the > Debian package [1]. I also verified that the package builds fine in unstable > with OpenSSL 3.0. > > Therefore closing this bug report. Hmm, I was too quick here. While the build itself succeeds, 17 tests are failing: === short test summary info SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:192: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:233: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:240: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:251: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:262: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:270: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:285: Requires OpenSSL with ENGINE support and OpenSSL < 1.1.1d SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:425: Requires OpenSSL without rsa_oaep_md (< 1.0.2) SKIPPED [1] ../../../tests/hazmat/backends/test_openssl.py:441: Requires OpenSSL without rsa_oaep_md (< 1.0.2) SKIPPED [3] ../../../tests/hazmat/backends/test_openssl.py:612: Requires OpenSSL without EVP_PKEY_DHX (< 1.0.2) SKIPPED [2] ../../../tests/hazmat/backends/test_openssl.py:642: Requires OpenSSL without EVP_PKEY_DHX (< 1.0.2) SKIPPED [2] ../../../tests/hazmat/backends/test_openssl.py:664: Requires OpenSSL without EVP_PKEY_DHX (< 1.0.2) SKIPPED [1] ../../../tests/hazmat/primitives/test_aead.py:41: Requires OpenSSL without ChaCha20Poly1305 support SKIPPED [1] ../../../tests/hazmat/primitives/test_aes.py:258: AES in dummy-mode mode not supported SKIPPED [1] ../../../tests/utils.py:30: 256-bit DH keys are not supported in OpenSSL 3.0.0+ () SKIPPED [1] ../../../tests/hazmat/primitives/test_dh.py:432: DH keys less than 512 bits are unsupported SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without Ed25519 support () SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without Ed448 support () SKIPPED [1] ../../../tests/hazmat/primitives/test_ed448.py:60: ed448 contexts are not currently supported SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA ECB () SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA CBC () SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA OFB () SKIPPED [1] ../../../tests/utils.py:30: Does not support IDEA CFB () SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not support algorithm: cmac_aes128 SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not support algorithm: cmac_aes192 SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not support algorithm: cmac_aes256 SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not support algorithm: cmac_tdes2 SKIPPED [480] ../../../tests/hazmat/primitives/utils.py:432: KBKDF does not support algorithm: cmac_tdes3 SKIPPED [800] ../../../tests/hazmat/primitives/utils.py:438: Does not support counter location: middle_fixed SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without poly1305 support () SKIPPED [1] ../../../tests/utils.py:30: Requires backend without RSA OAEP label support () SKIPPED [4] ../../../tests/hazmat/primitives/test_serialization.py:1910: Requires bcrypt module SKIPPED [1] ../../../tests/utils.py:30: Requires that bcrypt exists () SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without X25519 support () SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL without X448 support () SKIPPED [23] ../../../../../../usr/lib/python3/dist-packages/_pytest/config/__init__.py:1473: no 'wycheproof_root' option found SKIPPED [1] ../../../tests/utils.py:30: Requires OpenSSL < 1.1.0f () SKIPPED [1] ../../../tests/utils.py:30: Requires LibreSSL () == 17 failed, 2726 passed, 3261 skipped in 203.25s (0:03:23) === So, we need to ignore these failures for the package to build with OpenSSL. Ignoring the failures should be safe as it's just the tests that assume OpenSSL to be version <= 1.1.1. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0
Hi! > Looks like an upgrade to at least v35.0.0 is needed to fix this issue: > https://github.com/pyca/cryptography/issues/7039#issuecomment-1088566628= Not necessarily. One of the Python core developers, Christian Heimes, actually backported fixes for Python3.10 and OpenSSL 3.0.0 for Fedora [1]. I have extracted the patches and I'm attaching them to this bug report. I will test whether they fix the build on Debian. Adrian > [1] > https://src.fedoraproject.org/rpms/python-cryptography/c/b166e77e86d756b18cd79aeced13f5f3b6341a50?branch=rawhide -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From cb1908043d5daa7c5c38945c048c4a2477a46221 Mon Sep 17 00:00:00 2001 From: Paul Kehrer Date: Sun, 28 Feb 2021 16:06:11 -0600 Subject: [PATCH 1/4] fix pkcs12 parse ordering. fixes #5872 (#5879) * fix pkcs12 parse ordering. fixes #5872 * remove an unneeded print * simplify the test a bit more * index * black * Update tests/hazmat/primitives/test_pkcs12.py Co-authored-by: Alex Gaynor Co-authored-by: Alex Gaynor --- .../hazmat/backends/openssl/backend.py| 5 +- tests/hazmat/primitives/test_pkcs12.py| 58 ++- 2 files changed, 59 insertions(+), 4 deletions(-) diff --git a/src/cryptography/hazmat/backends/openssl/backend.py b/src/cryptography/hazmat/backends/openssl/backend.py index 271873d9..a96d08d8 100644 --- a/src/cryptography/hazmat/backends/openssl/backend.py +++ b/src/cryptography/hazmat/backends/openssl/backend.py @@ -6,6 +6,7 @@ import collections import contextlib import itertools +import typing import warnings from contextlib import contextmanager @@ -2562,9 +2563,7 @@ class Backend(object): sk_x509 = self._lib.sk_X509_new_null() sk_x509 = self._ffi.gc(sk_x509, self._lib.sk_X509_free) -# reverse the list when building the stack so that they're encoded -# in the order they were originally provided. it is a mystery -for ca in reversed(cas): +for ca in cas: res = self._lib.sk_X509_push(sk_x509, ca._x509) backend.openssl_assert(res >= 1) diff --git a/tests/hazmat/primitives/test_pkcs12.py b/tests/hazmat/primitives/test_pkcs12.py index b5de09f9..b1759a1b 100644 --- a/tests/hazmat/primitives/test_pkcs12.py +++ b/tests/hazmat/primitives/test_pkcs12.py @@ -4,13 +4,15 @@ import os +from datetime import datetime import pytest from cryptography import x509 from cryptography.hazmat.backends.interfaces import DERSerializationBackend from cryptography.hazmat.backends.openssl.backend import _RC2 -from cryptography.hazmat.primitives import serialization +from cryptography.hazmat.primitives import hashes, serialization +from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives.serialization import load_pem_private_key from cryptography.hazmat.primitives.serialization.pkcs12 import ( load_key_and_certificates, @@ -273,3 +275,57 @@ class TestPKCS12Creation(object): DummyKeySerializationEncryption(), ) assert str(exc.value) == "Unsupported key encryption type" + + +def test_pkcs12_ordering(): +""" +In OpenSSL < 3.0.0 PKCS12 parsing reverses the order. However, we +accidentally thought it was **encoding** that did it, leading to bug +https://github.com/pyca/cryptography/issues/5872 +This test ensures our ordering is correct going forward. +""" + +def make_cert(name): +key = ec.generate_private_key(ec.SECP256R1()) +subject = x509.Name( +[ +x509.NameAttribute(x509.NameOID.COMMON_NAME, name), +] +) +now = datetime.utcnow() +cert = ( +x509.CertificateBuilder() +.subject_name(subject) +.issuer_name(subject) +.public_key(key.public_key()) +.serial_number(x509.random_serial_number()) +.not_valid_before(now) +.not_valid_after(now) +.sign(key, hashes.SHA256()) +) +return (key, cert) + +# Make some certificates with distinct names. +a_name = "A" * 20 +b_name = "B" * 20 +c_name = "C" * 20 +a_key, a_cert = make_cert(a_name) +_, b_cert = make_cert(b_name) +_, c_cert = make_cert(c_name) + +# Bundle them in a PKCS#12 file in order A, B, C. +p12 = serialize_key_and_certificates( +b"p12", a_key, a_cert, [b_cert, c_cert], serialization.NoEncryption() +) + +# Parse them out. The API should report them in the same order. +(key, cert, certs) = load_key_and_certificates(p12, None) +assert cert == a_cert +assert certs == [b_cert, c_cert] + +# The ordering in the PKCS#12 file itself should also match. +a_idx = p12.i
Bug#1010189: fs-uae-launcher is broken in Sid
Control: severity -1 normal Control: forcemerge 1010048 -1 Hello! On 4/26/22 00:44, Miguel A. Vallejo wrote: > FS-UAE-Launcher in Debian Sid is now broken. It opens with a totally > corrupted window and the terminal outputs a ton of errors. fs-uae-launcher is not part of Debian unstable. It's available in stable only at the moment. Please see the explanation for the reasons here [1]. Adrian > [1] http://bugs.debian.org/1010048 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1010048: fs-uae-launcher: GUI is corrupted.
Control: severity -1 normal On 4/23/22 09:26, waxhead wrote: > Tried to start fs-uae-launcher, the GUI looks "corrupted" like below... > > ++ > |[start] [][][] | > || > |+-+ | > |[cfgwindow] | > || | | > |+-+ | > ++ > > A start button, a config windows and some widgets overlapping [][][]. > (...) > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 fs-uae-launcher is currently not part of Debian unstable or testing due to insufficient clarification of the copyright of various files shipped with the source code, see [1]. However, the package is part of the stable distribution and works fine there, just tested it on a freshly installed system. Thus, you are using the stable package on Debian testing which may result the bug you described. But since the package isn't part of testing/unstable anyway, I don't really consider this to be a valid bug report. Therefore downgrading the severity to normal. Adrian > [1] https://github.com/FrodeSolheim/fs-uae-launcher/issues/143 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006702: mariadb-10.6: Baseline violation on at least i386 via CXXFLAGS
Source: mariadb-10.6 Version: 1:10.6.7-2 Severity: serious Justification: baseline violation Hello! The file mysys/CMakeFiles.txt overrides the compiler machine flags [1] and causes mariadb-10.6 to be build with the CPU baseline of the buildd which results in binaries that will crash on the target platform such as i386. As can be seen in the build log for i386, the code is being built with "-msse4.2 -mpclmul" with at least SSE 4.2 which is not available before Intel Core i7, according to Wikipedia [3]. On ppc64, the code is being built with VSX, Crypto and POWER8 vector instructions which are all not available on the POWER5 baseline that the ppc64 port in Debian uses. I suggest patching out the whole section in mysys/CMakeFiles.txt which may also help fixing testsuite failures on some architectures. Thanks, Adrian > [1] > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L62 > [2] > https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=i386=1%3A10.6.7-2=1646205322=0 > [3] https://en.wikipedia.org/wiki/SSE4#SSE4.2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi Christian! On 2/16/22 12:33, Christian Kastner wrote: >> Bus errors are normally easy to spot. Just run the code in question through >> GDB and see where it crashes. Then look at the backtrace with the debug >> symbols installed. >> >> Usually it's a result of bad pointer arithmetics which should definitely be >> fixed as such operations usually violate the C/C++ standards. >> >> I can have quick look. > > one of these errors has been reported in the past, and I already did > some analysis way back then: > > https://github.com/scikit-learn/scikit-learn/issues/16443 > > Check the last comment. The relevant Cython code doesn't look wrong, so > I guess the problem is with the binary result produced during build, as > you point out. I'm happy to look at this issue but first the baseline issue must be fixed as this is a Debian Policy violation. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
HellO! On 2/16/22 11:57, John Paul Adrian Glaubitz wrote: > On 2/16/22 11:36, Graham Inggs wrote: >> Is anyone able to help with the bus error on armhf please? > > Bus errors are normally easy to spot. Just run the code in question through > GDB and see where it crashes. Then look at the backtrace with the debug > symbols installed. > > Usually it's a result of bad pointer arithmetics which should definitely be > fixed as such operations usually violate the C/C++ standards. So, I have skimmed over the build logs and one of the main issues is the use of -march flags to enforce a certain baseline [1]: powerpc64le-linux-gnu-gcc: error: unrecognized command-line option ‘-march=native’; did you mean ‘-mcpu=native’? This is a policy violation and must be fixed in any case. Blacklisting architectures is not enough in this case as forcing the baseline of the buildds can lead to code that won't run on the user's machines. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=1.0.2-1=1644956229=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hello! On 2/16/22 11:36, Graham Inggs wrote: > Is anyone able to help with the bus error on armhf please? Bus errors are normally easy to spot. Just run the code in question through GDB and see where it crashes. Then look at the backtrace with the debug symbols installed. Usually it's a result of bad pointer arithmetics which should definitely be fixed as such operations usually violate the C/C++ standards. I can have quick look. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002143: xserver-xorg-video-qxl: FTBFS: xf86Opt.h:44:10: error: two or more data types in declaration specifiers
Hello! There is an upstream fix available which fixes the FTBFS, see [1]. Adrian > [1] > https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/merge_requests/6 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1004454: kiwi-systemdeps-bootloaders is not installable on several architectures
Hi Adrian! On 1/27/22 23:40, Adrian Bunk wrote: > The following packages have unmet dependencies: > kiwi-systemdeps-bootloaders : Depends: grub2 but it is not installable > > > Package: grub2 > Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc > any-sparc64 I have already prepared a fix for that. I was just waiting for the mips* builds to finish to see whether any other issues occur [1]. Adrian > [1] https://buildd.debian.org/status/package.php?p=kiwi=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target
Hi Vagrant!
On 1/11/22 02:10, Vagrant Cascadian wrote:
> Something in the toolchain recently changed which causes u-boot arch:all
> build to FTBFS... I suspect binutils, as building in "bookworm" still
> works fine where binutils hasn't yet migrated.
>
> On arch:all builds the qemu-ppce500 target is cross-compiled.
>
> Full log:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
>
> The hopefully relevent lines from the build log:
> ...
> {standard input}: Assembler messages:
> {standard input}:127: Error: unrecognized opcode: `tlbre'
> {standard input}:418: Error: unrecognized opcode: `tlbre'
> {standard input}:821: Error: unrecognized opcode: `msync'
> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> make[4]: *** [/<>/scripts/Makefile.build:253:
> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] Error
> 2
> make[3]: *** Waiting for unfinished jobs
> powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
>
>
> If anyone has thoughts what might be the issue, please chime in!
It's most likely this upstream change [1] in binutils that broke the build.
It also affects glibc [2] and the kernel [3][4], for example.
Adrian
> [1]
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003847
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> [4]
> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
Hello! On 1/19/22 22:38, Jeffrey Walton wrote: > On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz > wrote: >> >> Unfortunately, glibc no longer builds with this change on powerpc and ppc64 >> and kernel builds still fails on both targets: >> >>> https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 >>> https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 >> >>> https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0 >>> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0 > > This seems to be related to the ones stamped 1642542048 and 1642542055 > (the first two): > https://patchwork.sourceware.org/project/glibc/patch/20210925202746.819385-1...@us.ibm.com/ It will be fixed in glibc_2.33-4 [1] which has not been released yet. Adrian > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/20e02061f900515ebac6ee3872c5cd22ea5801d2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
Hi Aurelien! Unfortunately, glibc no longer builds with this change on powerpc and ppc64 and kernel builds still fails on both targets: > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0 > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#999249: Package will now be considered for auto-removal
Hello! On 1/8/22 20:35, Graham Inggs wrote: > The release team no longer [1] considers popcon a criterion for > inclusion in the list of key packages [2]. > > This email is a courtesy reminder of this bug, and should prevent > instant auto-removal once the rule is changed in britney. discover has an installation count of nearly 200.000. Do we really remove a package that is being installed on so many machines? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hi Camm! On 12/28/21 19:52, John Paul Adrian Glaubitz wrote: > On 12/28/21 19:20, Camm Maguire wrote: >> Correction, that is current autobuilders on 68k and sh4. > > That's a known issue, see [1]. I will patch the glibc packages for m68k > and sh4 again to address this issue. I have uploaded patched versions of glibc for m68k and sh4 and blocked the autobuild for glibc on the buildds. You may want to merge the bug with the existing bug report [1] and adjust the severity to normal. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer
Hello Camm! On 12/28/21 19:20, Camm Maguire wrote: > Correction, that is current autobuilders on 68k and sh4. That's a known issue, see [1]. I will patch the glibc packages for m68k and sh4 again to address this issue. Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)
Hi Matthias!
On 10/11/21 15:27, John Paul Adrian Glaubitz wrote:
> This did not fix the bug, unfortunately. libffi is still being built with
> "-mcpu=power8" on ppc64, see the full build log in [1].
>
> We didn't need --enable-portable before, so this isn't the issue but I assume
> the problem is the new autoconf version which is not compatible with libffi
> [2].
Julien has suggested on #debian-devel to build with --without-gcc-arch instead
of
--enable-portable-binary and it indeed fixes the problem for me:
--- debian/rules.orig 2021-09-15 09:03:02.0 -0700
+++ debian/rules2021-10-28 05:10:01.357633494 -0700
@@ -53,6 +53,7 @@
--infodir=\$${prefix}/share/info \
--enable-pax_emutramp \
--disable-exec-static-tramp \
+ --without-gcc-arch \
CC="$(CC)" \
CXX="$(CXX)" \
CPPFLAGS="$(CPPFLAGS)" \
Could you update the debian/rules accordingly?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault
On 10/18/21 13:16, Antonio Terceiro wrote:
> I don't think we are on the right track here. I need to read the failing
> test correctly. this "test case" alone is bogus, as
>
> ruby -e 'END {Process.kill :SEGV, $$}'
>
> is _expected_ to segfault, i.e. the process is sending a SEGV signal to
> itself. This test case is not complete.
It might be an idea to look at the Fedora package:
> https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec
It has a number of patches against 3.x:
> https://src.fedoraproject.org/rpms/ruby/tree/rawhide
It builds fine on ppc64el:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1801321
OTOH, ruby3.0 builds fine in openSUSE Factory on ppc64el, but they're still at
version 3.0.1, so it might be an issue that will only show with 3.0.2?
> https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/ruby3.0
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault
On 10/18/21 12:51, Antonio Terceiro wrote: >> So, we need a backtrace to see where the crash actually happens. I assume >> it's in one >> of the build dependencies. > > it happens in glibc: > > Program received signal SIGSEGV, Segmentation fault. > 0x77a48f04 in kill () from /lib/powerpc64le-linux-gnu/libc.so.6 Hmm, both were built with glibc 2.32-4. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault
Hello! On 10/17/21 21:50, John Paul Adrian Glaubitz wrote: > Ah, so the last successful build was 3.0.2-2 and the first failure was in > 3.0.2-3, > the only difference being the mipsel patch to fix an unaligned access. > > However, 3.0.2-2 was built with gcc-10: > >> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-2=1633362713=0 > > while 3.0.2-3 was built with gcc-11: > >> https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-3=1634169532=0 > > So, first we should try building with gcc-10 and see if that makes a > difference. I have tested the build with gcc-10 but the problem remains, so it's not a compiler issue. Dropping the patch rand_init-fix-off-by-one-error.patch that was introduced with 3.0.2-3 doesn't help either. So, we need a backtrace to see where the crash actually happens. I assume it's in one of the build dependencies. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault
Hi! On 10/17/21 21:47, John Paul Adrian Glaubitz wrote: > Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would > be to just bisect the issue. I can give it a try and see if I can find the > problematic commit. Ah, so the last successful build was 3.0.2-2 and the first failure was in 3.0.2-3, the only difference being the mipsel patch to fix an unaligned access. However, 3.0.2-2 was built with gcc-10: > https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-2=1633362713=0 while 3.0.2-3 was built with gcc-11: > https://buildd.debian.org/status/fetch.php?pkg=ruby3.0=ppc64el=3.0.2-3=1634169532=0 So, first we should try building with gcc-10 and see if that makes a difference. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault
Hello Antonio!
On 10/17/21 20:57, Antonio Terceiro wrote:
> I'm copying the debian-powerpc list to see if anyone can help.
>
> ruby3.0 fails to build on ppc64el. 4 test cases results in Segmentation
> faults.
>
> I was able to reproduce this on the porter box, and the minimal test
> case, inside a build source tree, is this:
>
> ./miniruby -e 'END {Process.kill :SEGV, $$}'
Since ruby3.0 used to build fine on ppc64el in the past, the easiest way would
be to just bisect the issue. I can give it a try and see if I can find the
problematic commit.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)
Control: reopen -1 Hello! This did not fix the bug, unfortunately. libffi is still being built with "-mcpu=power8" on ppc64, see the full build log in [1]. We didn't need --enable-portable before, so this isn't the issue but I assume the problem is the new autoconf version which is not compatible with libffi [2]. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libffi=ppc64=3.4.2-3=1633957534=0 > [2] https://github.com/libffi/libffi/issues/662 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#984138: fs-uae: ftbfs with GCC-11
Control: tags -1 +patch
Hi!
On 3/3/21 17:12, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.
FWIW, upstream has fixed the issue on the stable branch already [1], see
attached patch. I'm just waiting for the upcoming stable version to be
released.
I'll then uploaded the fixed version immediately.
Adrian
> [1]
> https://github.com/FrodeSolheim/fs-uae/commit/bf81e7d2a60b2c8646663889e4a4431b988ae972
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From bf81e7d2a60b2c8646663889e4a4431b988ae972 Mon Sep 17 00:00:00 2001
From: Frode Solheim
Date: Fri, 8 Oct 2021 11:39:16 +0200
Subject: [PATCH] Work around an incompatibility with C++17
---
src/dosbox/setup.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/dosbox/setup.h b/src/dosbox/setup.h
index db75ada8..e0a3a75d 100644
--- a/src/dosbox/setup.h
+++ b/src/dosbox/setup.h
@@ -54,6 +54,12 @@ public:
};
+#ifdef FSUAE
+// Work around an incompatibility with C++17. It does not seem like these
+// functions are used anyway.
+#define throw(...) throw()
+#endif
+
class Value {
/*
* Multitype storage container that is aware of the currently stored type in it.
@@ -113,6 +119,11 @@ private:
void set_double(std::string const& in);
};
+#ifdef FSUAE
+#undef throw
+#endif
+
+
class Property {
public:
struct Changeable { enum Value {Always, WhenIdle,OnlyAtStart};};
--
2.33.0
Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8
Hello! On 9/29/21 00:38, John Paul Adrian Glaubitz wrote: > There is actually a baseline violation on i386 as "-march=amdfam10" is > passed to the compiler, see the build log in [1], for example. Comparing the build logs, it seems that this an issue with the newer version of autoconf that was used to build version 3.4.2-2. Looking at the log for 3.4.2-2, a lot of autoconf warnings can be seen which are not present in the log for 3.4.1-1. > https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-1=1626443428=0 > https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-2=1632868252=0 So, upstream needs to fix compatibility issues with the newer autoconf version. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8
Hi! On 9/28/21 22:40, John Paul Adrian Glaubitz wrote: > We should therefore pass "--enable-portable-binary" in debian/rules. There is actually a baseline violation on i386 as "-march=amdfam10" is passed to the compiler, see the build log in [1], for example. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libffi=i386=3.4.2-2=1632469242=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):
Control: severity -1 normal Hello Rick! On 6/9/21 11:15 AM, Rick Thomas wrote: > Package: grub-common > Version: 2.04-18 > Severity: grave > File: /usr/sbin/grub-mkconfig > Justification: renders package unusable Since powerpc is not a release architecture, setting the severity to "grave" is not allowed here. I am therefore downgrading this to "normal". > This is what happens when I attempt to do "aptitude full-upgrade" on my > PowerPC machine: > > root@dillserver:/home/rbthomas# aptitude full-upgrade > The following partially installed packages will be configured: > linux-image-5.10.0-7-powerpc linux-image-powerpc > No packages will be installed, upgraded, or removed. > 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B of archives. After unpacking 0 B will be used. > Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ... > /etc/kernel/postinst.d/initramfs-tools: > update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc > /etc/kernel/postinst.d/zz-update-grub: > /usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: > Read-only file system Your HFS filesystem on /boot/grub is read-only. This is not related to GRUB but to either your custom environment or something in the partitioning setup in d-i that I need to fix. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#987441: Bug#926539: Bug#987441: s390x installation bugs
Hi! On 5/3/21 12:21 PM, Valentin Vidic wrote: >>> I'd suggest at least retitling the bug report to mention s390x (release >>> arch, affected) instead of sparc64 (port arch, no longer affected), to >>> lower the chances people could overlook this issue, thinking it's only >>> about a port arch. >> >> We could also unmerge #926539 and #961056 again, then close the former bug >> which was sparc64-specific. > > I have unmerged the bugs now, so the sparc one can be closed. Alright, done. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#987441: Bug#926539: Bug#987441: s390x installation bugs
Hi! On 5/3/21 8:36 AM, Cyril Brulebois wrote: > From skimming through the bug log, it seems it was initially a sparc64 > problem, that was fixed in the kernel (inconsistent naming) eventually. Correct. > The same issue exists on s390x but isn't apparently going to get fixed > so we need to have d-i be smarter (hence the merge request)? Seems so. > I'd suggest at least retitling the bug report to mention s390x (release > arch, affected) instead of sparc64 (port arch, no longer affected), to > lower the chances people could overlook this issue, thinking it's only > about a port arch. We could also unmerge #926539 and #961056 again, then close the former bug which was sparc64-specific. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#980607: [PATCH] netcfg: FTBFS: test/test_inet_mton.c:12:15: error: too many arguments for format [-Werror=format-extra-args]
> On Feb 22, 2021, at 12:24 AM, Francisco Vilmar Cardoso Ruviaro > wrote: > > Hello everyone, > > I would like to help with this, > I reviewed the patches (thanks Dennis) and created an MR at > https://salsa.debian.org/installer-team/netcfg/-/merge_requests/5. > > As Bart said, the patches solve the FTBFS. > > I intend to make a delayed NMU in 7 days. That shouldn’t be necessary as Holger is usually very quick working on d-i issues. If Holger isn’t available, I can merge the patch and upload the updated package. Adrian
Bug#982825: netcfg: FTBFS with current bullseye version
Hello Holger! On 2/15/21 12:02 AM, Holger Wansing wrote: > While trying to upload a new version of netcfg, I found that current testing > version of netcfg fails to build from source, in a stable sbuild environment > as well as in an unstable one. Did you see #980607 [1]? Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980607 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#982380: funcparserlib: Package contains dfsg-incompatible documentation files
Source: funcparserlib Severity: serious Justification: non-free software in main (2.2.1) Hello! The following files in the doc directory are covered by a license that is non-free (non-compatible with DFSG), see [1] and [2]: - Brackets.md - Illustrated.md - Tutorial.md These files need to be removed or the package moved to non-free. Issue also reported upstream [3]. Adrian > [1] > https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution-Non_Commercial-Share_Alike_.28CC-by-nc-sa.29 > [2] > https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area > [3] https://github.com/vlasovskikh/funcparserlib/issues/64 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2
Hello Chris! On 2/7/21 3:04 PM, Chris Hofstaedtler wrote: >> I don't think we're doing ourselves a favor by rushing hotfixes in to get >> these >> packages into the next release. > > Given I saw you making this argument in another bug report - what > other options do we have? > > For packages that are not yet O:, or those well-connected like a key > package, we could only wait for someone to show up and do the work. > How long are we willing to wait? I think the problem is that hardly anyone was aware of the situation which is why people weren't actually waiting but simply didn't care. If I had known much earlier that cdrkit is still that relevant, I would have switched priorities and worked on cdrkit much earlier. I thought that the only reason for the package's existence were some features in mkisofs that are present in cdrkit but not yet in xorroisofs, primarily the support for legacy HFS filesystems which we needed in Debian Ports for creating images that can be read on older Apple Macintosh systems. Legacy HFS support was the primary reason why I volunteered to adopt the package. And all of a sudden I'm notified that cdrkit is way more important and is actually needed by multiple packages. > Right now we can only go with "this was good enough in the last > release" and ignore (possibly perceived) larger problems until after > the release. And then we hope for the volunteers to show up and do > the necessary cleanups. I personally do not understand why there needs to be such a hard deadline. Sure, we don't want the release process to take forever, but I think key packages should be in shape before starting with a release. If we realize there are some important key packages that are in bad shape, why should we be so strict with the testing freeze? Why not let these improvements in? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2
On 2/7/21 2:00 PM, Sebastian Ramacher wrote: > I'm not sure how you've reached that conclusion. dak definitely > disagrees: > > $ dak rm -Rn cdrkit > Will remove the following packages from unstable: I know what dak says I looked that up myself after you made that statement. I previously thought that libburnia is already being used by all relevant packages and that cdrkit is required only for mkisofs, in particular for creating ISO images with a HFS (not HFS+) filesystem. If cdrkit is actually being used by so many packages, then it should have been in much better shape before being shipped with a Debian release. Just painting over this single issue is not the right approach in my opinion and there are certainly more issues with cdrkit than just the FTBFS. The number of patches in the Fedora package speaks for itself [1]. I don't think we're doing ourselves a favor by rushing hotfixes in to get these packages into the next release. Adrian > [1] https://src.fedoraproject.org/rpms/cdrkit/tree/rawhide -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#966638: gkrellm2-cpufreq: diff for NMU version 0.6.4-6.1
On 2/7/21 12:46 PM, Adrian Bunk wrote: > I've prepared an NMU for gkrellm2-cpufreq (versioned as 0.6.4-6.1). The > diff is attached to this message. What's the exact point of this message when the upload was already performed and what exactly is the point of uploading package that was just hardly patched to it can make to testing? Do we no longer have quality standards in Debian? Is it more important to meet release dates and "get things in somehow" rather than doing this properly? Maybe the FOSS community should actually come back to proper quality management rather than pushing out releases like crazy. I'm really frustrated by this situation and it really wants to make me stop working on Debian. I don't want to be pressured into working on something, this is my free time, my package and I should be able to determine the pace. When the package hasn't been touched for a long time, it makes zero sense to just patch over this one little thing just to get it into the release. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#966638: gkrellm2-cpufreq: diff for NMU version 0.6.4-6.1
Hi Adrian! On 2/7/21 12:46 PM, Adrian Bunk wrote: > I've prepared an NMU for gkrellm2-cpufreq (versioned as 0.6.4-6.1). The > diff is attached to this message. Thanks for the patch. I haven't touched that package for a while and can take this opportunity to refresh it and move the packaging to salsa. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2
On 2/5/21 11:11 AM, Sebastian Ramacher wrote: >> Is there a reason why this was uploaded so hastily? Is cdrkit a dependeny >> for anything else? > > It's a key package with an old RC bug and a trivial fix (not even > speaking of a bunch of important reverse dependencies). We (the release > team) are trying to stabilze testing to get release done and key > packages causing extra work on our side. I thought that packages should have been switched to liburnia by now? And as far as I remember, the freeze date is February 12, assuming the five-day testing migration, there is plenty of time to work on this. > I saw your mail too late to cancel the upload. Sorry. Well, to be honest, it lowers the motivation that I have to adopt orphaned packages. It would have been avoidable by using DELAYED/3, for example. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2
On 2/4/21 10:58 PM, John Paul Adrian Glaubitz wrote: >> the ITA bug has been filed, but nothing happended since then. So I've >> prepared an NMU for cdrkit (versioned as 9:1.1.11-3.2). The diff is >> attached to this message. It would have been nice if the package had been uploaded to DELAYED which exists for this very reason instead of just uploading the package without giving anyone the chance to intervene? Is there a reason why this was uploaded so hastily? Is cdrkit a dependeny for anything else? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2
Please don’t. I am planning to work on this in the following days. I was stuck with hfsprogs. Thanks, Adrian > On Feb 4, 2021, at 10:41 PM, Sebastian Ramacher wrote: > > Control: tags 957074 + patch > > Dear maintainer, > > the ITA bug has been filed, but nothing happended since then. So I've > prepared an NMU for cdrkit (versioned as 9:1.1.11-3.2). The diff is > attached to this message. > > Cheers > -- > Sebastian Ramacher >
Bug#948739: Bug #948739: gparted should not mask .mount units
Hello! It looks like this particular issue has been fixed in gparted 1.2.0 which was just released a few days ago [1]: > - Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129, !64) Might be an idea to update gparted to version 1.2.0 before the Bullseye freeze which is coming in Mid-February [2]. Adrian > [1] https://sourceforge.net/projects/gparted/files/gparted/gparted-1.2.0/ > [2] https://release.debian.org/bullseye/freeze_policy.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976952: [Help] Re: lmfit-py: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
On 12/18/20 4:49 PM, Andreas Tille wrote: >> Well, the test is obviously broken and upstream currently can't be bothered >> to fix >> it on non-x86 targets. He will certainly have to do it at some point given >> that ARM64 >> is replacing more and more x86_64 systems, but I wouldn't bother, personally. > > But its on ppc64el not arm64. This is no argument to ignore the issue, > but the practical relevance of ppc64el is smaller than amd64 and arm64 > theses days if I'm not misleaded. I was referring to the comment in the openSUSE spec file which claims the tests are broken on all non-x86_64 targets. I have not verified whether this is correct, though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976952: [Help] Re: lmfit-py: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
On 12/18/20 4:42 PM, PICCA Frederic-Emmanuel wrote: >> Yes, good catch. The spec file for the openSUSE package has this [1]: > > so it does not fit with our policy: do not hide problems ;) > > The problem is that I do not have enougt time to investigate... on a porter > box Well, the test is obviously broken and upstream currently can't be bothered to fix it on non-x86 targets. He will certainly have to do it at some point given that ARM64 is replacing more and more x86_64 systems, but I wouldn't bother, personally. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976952: [Help] Re: lmfit-py: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Hi Frederic! On 12/18/20 4:00 PM, PICCA Frederic-Emmanuel wrote: > looking at the Opensuze log, I can find this > > [ 93s] + pytest-3.8 --ignore=_build.python2 --ignore=_build.python3 > --ignore=_build.pypy3 -v -k 'not speed and not (test_model_nan_policy or > test_shgo_scipy_vs_lmfit_2)' > [ 97s] = test session starts > == > > does it means that the failling test on Debian is skipped during the build on > OBS ? Yes, good catch. The spec file for the openSUSE package has this [1]: # We don't care about speed, and test_itercb is architecture-specific # test_model_nan_policy - fails on non x86_64 # test_shgo_scipy_vs_lmfit_2 - fails on non x86_64 %pytest -k 'not speed and not (test_model_nan_policy or test_shgo_scipy_vs_lmfit_2)' Adrian > [1] > https://build.opensuse.org/package/view_file/devel:languages:python:numeric/python-lmfit/python-lmfit.spec?expand=1 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976952: [Help] Re: lmfit-py: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
On 12/18/20 3:19 PM, Andreas Tille wrote: > I wonder whether we could get some help from PowerPC team to solve this > issue. If we can not get that test working I see only two options: > >1. Skip this specific test >2. Exclude ppc64el from architecture list > > Any help would be really welcome. The testsuite passes on ppc64el on openSUSE: > https://build.opensuse.org/package/show/devel:languages:python:numeric/python-lmfit > https://build.opensuse.org/build/devel:languages:python:numeric/openSUSE_Factory_PowerPC/ppc64le/python-lmfit/_log So this might be related to the build environment? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
On 12/10/20 10:16 PM, Michael Biebl wrote: >>> Did the test machine you used actually have that many cores? >> >> No idea > > But given that there is only a single test, I wonder if that is really > relevant anyway. You're right. That's rather strange. Hmm. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Hi! On 12/10/20 10:12 PM, Michael Biebl wrote: >> Did the test machine you used actually have that many cores? > > No idea I just checked plummer.debian.org and it has only 16 (virtual) CPUs. Would be curious to hear whether Lucas' test machine had >= 160 CPUs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Hi Michael! On 12/10/20 8:42 PM, Michael Biebl wrote: > > Testsuite summary for systemd-bootchart 233 > > # TOTAL: 1 > # PASS: 1 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > Did the test machine you used actually have that many cores? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976922: systemd-bootchart: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 returned exit code 2
Hi Michael! On 12/10/20 7:53 PM, Michael Biebl wrote: > Unfortunately, I can't reproduce the issue on a porter box (plummer). > So I'm not sure if I can do something about it. It might be an issue with parallel jobs as Lucas built the package with make -j160 and some packages can't cope with that many parallel jobs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Hello! On 12/6/20 7:38 PM, Nilesh Patra wrote: > I've no clue of where to even start debugging this. Any help/hints are > welcome and highly appreciated. My suggestion would be to report this issue upstream [1]. Since ARM is going to be more popular in the future with Apple switching their all their machines over from x86, I expect such issues to become more relevant. Adrian > [1] https://github.com/jeffdaily/parasail-python -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: ftbfs with GCC-10
Hi Steve! On 11/15/20 7:58 PM, Steve McIntyre wrote: >> Is anyone taking care of this package at the moment? >> >> I'm happy to adopt cdrkit for the time being until libisofs from libburnia >> has gained support for creating legacy HFS filesystems which is required >> for older Macintosh systems. >> >> For this reason, I'm currently using genisoimage when creating Debian CD >> images for m68k. > > ACK. If you're happy to take ove cdrkit for now, I'd be very happy. I > don't have the time to care for it any more. Thomas has been doing a > great job with xorriso and friends, so it would be lovely to see us no > longer need to keep the old code around any more... I agree. I'm trying to help Thomas to add HFS support to libburnia/xorriso so we can finally get rid of cdrkit but I would like to keep cdrkit in Debian until that has happened. I'll file an O:/ITA: bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#957074: cdrkit: ftbfs with GCC-10
Hello! > Fedora has a patch for gcc-10 > > https://src.fedoraproject.org/rpms/cdrkit/blob/master/f/cdrkit-1.1.11-gcc10.patch Is anyone taking care of this package at the moment? I'm happy to adopt cdrkit for the time being until libisofs from libburnia has gained support for creating legacy HFS filesystems which is required for older Macintosh systems. For this reason, I'm currently using genisoimage when creating Debian CD images for m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972848: kdevelop: FTBFS - dh_install: error: missing files, aborting
Source: kdevelop Severity: serious Justification: FTBFS Hi! kdevelop fails to build from source due to dh_install missing files: make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' debian/rules override_dh_install make[1]: Entering directory '/<>' # create this directory if not existing, so kdevelop-data.install # is the same, no matter whether clang is built mkdir -p debian/tmp/usr/share/kdevclangsupport/ dh_install dh_install: warning: Cannot find (any matches for) "usr/share/kservices5/kdevelopsessions.desktop" (tried in ., debian/tmp) dh_install: warning: plasma-kdevelop missing files: usr/share/kservices5/kdevelopsessions.desktop dh_install: error: missing files, aborting make[1]: *** [debian/rules:18: override_dh_install] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:9: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972556: ffmpeg: Fails to build from source with newer src:srt
On 10/20/20 12:05 PM, Sebastian Ramacher wrote: >> So, this patch and the patch from #968574 would be great! > > Has the patch from #968574 been merged upstream in the meantime? Apparently not. But merging won't break anything due to the #ifdef guards and unbreaks ffmpeg on powerpc and ppc64 which is important due to the way Debian Ports works with no support for cruft [1]. Adrian > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972556: ffmpeg: Fails to build from source with newer src:srt
Control: tags -1 +patch Hello! This FTBFS is fixed by the following upstream patch [1]: From: Jun Zhao Date: Sun, 12 Jul 2020 05:48:48 + (+0800) Subject: lavf/srt: fix build fail when used the libsrt 1.4.1 X-Git-Url: http://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff_plain/7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315 lavf/srt: fix build fail when used the libsrt 1.4.1 libsrt changed the: SRTO_SMOOTHER -> SRTO_CONGESTION SRTO_STRICTENC -> SRTO_ENFORCEDENCRYPTION and removed the front of deprecated options (SRTO_SMOOTHER/SRTO_STRICTENC) in the header, it's lead to build fail fix #8760 Signed-off-by: Jun Zhao So, this patch and the patch from #968574 would be great! Thanks, Adrian > [1] > https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972556: ffmpeg: Fails to build from source with newer src:srt
error: debian/rules binary-arch subprocess returned exit status 2 While you're fixing this bug, could you please also backport the fix for #968574 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968574 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#971794: fakeroot: testsuite fails on mipsel
On 10/9/20 11:16 PM, John Paul Adrian Glaubitz wrote: >> libfakeroot, when sending message: Invalid argument > > I assume that using INT_SEND_GET_STAT instead of SEND_GET_STAT may have broken > it. I don't know what the difference between both is but m68k is a bit > peculiar in its ABI so such changes may not work. Okay, it's 1.25.2-1 that broke m68k. 1.25.1-1 works. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#971794: fakeroot: testsuite fails on mipsel
On 10/9/20 11:04 PM, John Paul Adrian Glaubitz wrote: > This last upload somehow broke fakeroot on m68k [1]. I'm not sure what's > happening but the build just hangs. Ah, I skipped a line, there is actually an error message: > libfakeroot, when sending message: Invalid argument I assume that using INT_SEND_GET_STAT instead of SEND_GET_STAT may have broken it. I don't know what the difference between both is but m68k is a bit peculiar in its ABI so such changes may not work. > I also can't seem to find Aurelien's patch in the source package after > downloading the source. It's also not present in the Git source [2], > am I missing soemthing? Okay, I realized the change was merged in the upstream code. It's a bit confusing as the package seems to be something between a native Debian and a non-native package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#971794: fakeroot: testsuite fails on mipsel
Source: fakeroot Followup-For: Bug #971794 User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! This last upload somehow broke fakeroot on m68k [1]. I'm not sure what's happening but the build just hangs. I also can't seem to find Aurelien's patch in the source package after downloading the source. It's also not present in the Git source [2], am I missing soemthing? Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=mergerfs=m68k=2.31.0-1=1602276375=0 > [2] https://salsa.debian.org/clint/fakeroot -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970194: pmix FTBFS on armel/mipsel: No atomic primitives available
Control: retitle -1 pmix FTBFS on armel/m68k/mipsel/sh4: No atomic primitives available Hi Adrian! This issue affects m68k and sh4 as well, so the architecture list should include them: +ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mipsel sh4)) + export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic -Wl,--as-needed +endif Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#961841: fontforge FTBFS on 64bit big endian: test failures
Hello! This bug blocks a couple of packages from being built on big-endian targets in Debian Ports and also causes the package to be still affected by an RC for too long. Any chance this can be fixed the next days? Apparently the necessary changes have already been merged in Salsa. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960867: Solved installing the Debian testing version
On 5/25/20 3:33 PM, Davide Lombardo wrote: > Ok I solved installing the Debian testing version with the following shell > commands: > > $ wget > http://ftp.de.debian.org/debian/pool/main/f/fs-uae/fs-uae-launcher_3.0.5+dfsg-1_all.deb > > > # dpkg -i ./fs-uae-launcher_3.0.5+dfsg-1_all.deb > > # apt-get install --fix-broken I have backported 3.0.5 for Debian Buster as well, it should be available within the next days. However, I'm still not convinced that this is a bug in fs-uae as a normal Python application doesn't provoke a crash in glibc. When you ran "apt-get install --fix-broken", you probably upgraded some additional packages which fixed the problem - for example, libc6 and related. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 1:18 PM, Philipp Kern wrote: > But then I keep wondering how representative qemu is. Is VT220 SCLP even > something you get on a real z machine? Not that we shouldn't fix qemu, > of course. But Hercules might be closer to the real thing in this regard. Hercules shows the exact same behavior. I also don't think the emulation is relevant as the underlying issue is a naming inconsistency in the kernel which is only present on s390x and used to be present on sparc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 12:42 PM, Valentin Vidić wrote: > It is hard to tell, but it seems the current state is hardcoded > in different places: > > https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html This wouldn't cause breakage as with your change, the console name would actually be ttysclp0. > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html Well, IBM could just update their documentation. > I think it would be better to make debian-installer smarter about > this since we will probably run into the same problem again with > a different architecture/driver. It was only SPARC which had this issue as well and where it was fixed. For all the other architectures, the console and driver names already match. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
On 5/20/20 11:17 AM, John Paul Adrian Glaubitz wrote: > I don't see any discussion in this thread. I would like to know the reasoning > why kernel upstream thinks that this naming inconsistency is correct. It > makes no sense, in my opinion and it can potentially trigger more problems. Ah, sorry. I was seeing the cached version of the thread, refreshing helped. In any case, the SPARC kernel maintainer (Dave Miller) had the same argument that it would potentially break existing setups but eventually I could convince him that the change was right. Not sure which distributions he has in mind. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#926539: rootskel: steal-ctty no longer works on s390x
Hi! On 5/20/20 11:00 AM, Valentin Vidić wrote: > Similar change for console name on s390x was not accepted: > > https://lkml.org/lkml/2020/5/19/854 > > so please fix in rootskel. I don't see any discussion in this thread. I would like to know the reasoning why kernel upstream thinks that this naming inconsistency is correct. It makes no sense, in my opinion and it can potentially trigger more problems. Also, this bug report should be merged with the other one that I referenced yesterday. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960867: fs-uae-launcher: The application crash every time at the beginning
(You should not remove the bug tracker from the CC) On 5/17/20 9:11 PM, Davide Lombardo wrote: > Nope I had the quite same crash output with the backport version: > > $fs-uae-launcher > [LOGGING] Logging to /home/davide/Documents/FS-UAE/Cache/Logs/fs-uae- > launcher.log.txt > FS-UAE Launcher 3.0.2 > ['/usr/bin/fs-uae-launcher'] > uname_result(system='Linux', node='PC0', release='4.19.0-9-amd64', > version='#1 > SMP Debian 4.19.118-2 (2020-04-29)', machine='x86_64', processor='') > Traceback (most recent call last): > File "/usr/share/fs-uae-launcher/fsgs/archive.py", line 15, in > from lhafile import LhaFile > ModuleNotFoundError: No module named 'lhafile' > [ARCHIVE] LhaFile module import problem > [SETTINGS] No settings path specified > [SETTINGS] Using default /home/davide/Documents/FS-UAE/Data/Settings.ini > [SETTINGS] File /home/davide/Documents/FS-UAE/Data/Settings.ini does not exist > [I18N] Initialize_locale language = > [I18N] Locale is en_GB > [I18N] Checking /usr/bin/share/fs-uae-launcher/share-dir > [I18N] Checking /usr/bin/../share/fs-uae-launcher/share-dir > [I18N] bindtextdomain fs-uae-launcher: /usr/bin/../share/locale > [I18N] find translations for en_GB in local directory /usr/bin/../share/locale > [I18N] Path to mo file: None > [I18N] Translations object: 0x7f88fb118e80> > corrupted size vs. prev_size in fastbins > KCrash: crashing... crashRecursionCounter = 2 > KCrash: Application Name = python3.7 path = /usr/bin pid = 5149 > KCrash: Arguments: > Alarm clock Which is a good indicator that's not a bug in fs-uae-launcher but some other package. > #apt-get reinstall libc6 && apt-get reinstall libgettextpo0 apt-get reinstall > python3 didn't work Just re-installing packages doesn't magically fix bugs, I'm afraid. I need to install a fresh Debian stable VM next week and see if I can reproduce the problem, but I'm very sure it's not a problem with fs-uae-launcher as even buggy Python code shouldn't be able to provoke a crash in glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960867: fs-uae-launcher: The application crash every time at the beginning
Control: tags -1 moreinfo Hello! On 5/17/20 7:57 PM, Davide Lombardo wrote: > [I18N] Initialize_locale language = > [I18N] Locale is en_GB > [I18N] Checking /usr/bin/share/fs-uae-launcher/share-dir > [I18N] Checking /usr/bin/../share/fs-uae-launcher/share-dir > [I18N] bindtextdomain fs-uae-launcher: /usr/bin/../share/locale > [I18N] find translations for en_GB in local directory /usr/bin/../share/locale > [I18N] Path to mo file: None > [I18N] Translations object: 0x7fd7ddc11eb8> > corrupted size vs. prev_size in fastbins > KCrash: crashing... crashRecursionCounter = 2 > KCrash: Application Name = python3.7 path = /usr/bin pid = 7000 > KCrash: Arguments: > Alarm clock The error message "corrupted size vs. prev_size in fastbins" indicates a crash in the C library which can normally not happen when Python code is executed. So I'm not sure this is actually a bug in fs-uae-launcher, it looks more like a problem with gettext. You can try to install fs-uae from stable-backports and see if that helps. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960263: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x
Hi Xavier! On 5/12/20 10:09 AM, Xavier wrote: >>> The problem here is va_list. On some architectures, the calling convention >>> doesn't seem to allow comparing va_list against NULL due to the way va_list >>> is implemented on a particular architecture. >> Correction: The va_list problem seems to affect ARM architectures only. >> >> The other architectures have testsuite failures which seem unrelated. >> >> Adrian > > Thanks a lot! I had to modify your patch: I had to declare a va_list > "noargs" variable to fix the problem. Glad it works and thanks for the additional modifications and for testing it. It was actually a shot in the dark yesterday shortly before I went to bed :-). I'll have a look whether I can help with the testsuite failures as well in the evening or tomorrow. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960263: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x
On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote: > On 5/11/20 11:56 PM, Xavier wrote: >> Could someone help us here ? I forwarded this bug to upstream ([1]) but >> didn't receive any response for now. >> >> (Cc to RFH bug) > > The problem here is va_list. On some architectures, the calling convention > doesn't seem to allow comparing va_list against NULL due to the way va_list > is implemented on a particular architecture. Correction: The va_list problem seems to affect ARM architectures only. The other architectures have testsuite failures which seem unrelated. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#960263: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x
Hi Xavier!
On 5/11/20 11:56 PM, Xavier wrote:
> Could someone help us here ? I forwarded this bug to upstream ([1]) but
> didn't receive any response for now.
>
> (Cc to RFH bug)
The problem here is va_list. On some architectures, the calling convention
doesn't seem to allow comparing va_list against NULL due to the way va_list
is implemented on a particular architecture.
You could maybe add an auxiliary boolean variable to control whether
"va_list args" is empty or not, i.e. something like this:
Index: cyrus-imapd-3.2.0/imap/httpd.c
===
--- cyrus-imapd-3.2.0.orig/imap/httpd.c
+++ cyrus-imapd-3.2.0/imap/httpd.c
@@ -2350,7 +2350,7 @@ EXPORTED void simple_hdr(struct transact
simple_hdr(txn, "Access-Control-Expose-Headers", hdr)
static void comma_list_body(struct buf *buf,
-const char *vals[], unsigned flags, va_list args)
+const char *vals[], unsigned flags, int has_args,
va_list args)
{
const char *sep = "";
int i;
@@ -2358,11 +2358,11 @@ static void comma_list_body(struct buf *
for (i = 0; vals[i]; i++) {
if (flags & (1 << i)) {
buf_appendcstr(buf, sep);
-if (args) buf_vprintf(buf, vals[i], args);
+if (has_args) buf_vprintf(buf, vals[i], args);
else buf_appendcstr(buf, vals[i]);
sep = ", ";
}
-else if (args) {
+else if (has_args) {
/* discard any unused args */
vsnprintf(NULL, 0, vals[i], args);
}
@@ -2377,7 +2377,7 @@ EXPORTED void comma_list_hdr(struct tran
va_start(args, flags);
-comma_list_body(, vals, flags, args);
+comma_list_body(, vals, flags, 1, args);
va_end(args);
@@ -3077,17 +3077,17 @@ EXPORTED void response_header(long code,
}
if (code == HTTP_SWITCH_PROT || code == HTTP_UPGRADE) {
buf_printf(logbuf, "%supgrade=", sep);
-comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, NULL);
+comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, 0, 0);
sep = "; ";
}
if (txn->flags.te) {
buf_printf(logbuf, "%stx-encoding=", sep);
-comma_list_body(logbuf, te, txn->flags.te, NULL);
+comma_list_body(logbuf, te, txn->flags.te, 0, 0);
sep = "; ";
}
if (txn->resp_body.enc.proc) {
buf_printf(logbuf, "%scnt-encoding=", sep);
-comma_list_body(logbuf, ce, txn->resp_body.enc.type, NULL);
+comma_list_body(logbuf, ce, txn->resp_body.enc.type, 0, 0);
sep = "; ";
}
if (txn->location) {
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Don't try to compare va_list against NULL
Author: John Paul Adrian Glaubitz
Last-Update: 2020-05-12
Index: cyrus-imapd-3.2.0/imap/httpd.c
===
--- cyrus-imapd-3.2.0.orig/imap/httpd.c
+++ cyrus-imapd-3.2.0/imap/httpd.c
@@ -2350,7 +2350,7 @@ EXPORTED void simple_hdr(struct transact
simple_hdr(txn, "Access-Control-Expose-Headers", hdr)
static void comma_list_body(struct buf *buf,
-const char *vals[], unsigned flags, va_list args)
+const char *vals[], unsigned flags, int has_args, va_list args)
{
const char *sep = "";
int i;
@@ -2358,11 +2358,11 @@ static void comma_list_body(struct buf *
for (i = 0; vals[i]; i++) {
if (flags & (1 << i)) {
buf_appendcstr(buf, sep);
-if (args) buf_vprintf(buf, vals[i], args);
+if (has_args) buf_vprintf(buf, vals[i], args);
else buf_appendcstr(buf, vals[i]);
sep = ", ";
}
-else if (args) {
+else if (has_args) {
/* discard any unused args */
vsnprintf(NULL, 0, vals[i], args);
}
@@ -2377,7 +2377,7 @@ EXPORTED void comma_list_hdr(struct tran
va_start(args, flags);
-comma_list_body(, vals, flags, args);
+comma_list_body(, vals, flags, 1, args);
va_end(args);
@@ -3077,17 +3077,17 @@ EXPORTED void response_header(long code,
}
if (code == HTTP_SWITCH_PROT || code == HTTP_UPGRADE) {
buf_printf(logbuf, "%supgrade=", sep);
-comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, NULL);
+comma_list_body(logbuf, upgrd_tokens, txn->flags.upgrade, 0, 0);
sep = "; ";
}
if (txn->flags.te) {
buf_printf(logbuf, "%stx-encoding=", sep);
-
Bug#958646: ffmpegfs: FTBFS caused by passing custom target flags in CFLAGS
Package: ffmpegfs Version: 1.98-1 Severity: serious Tags: upstream Justification: ftbfs User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 ppc64el Hello! ffmpegfs fails to build from source on multiple architectures [1], including release architectures because it passes target flags via -march in CFLAGS which is not allowed: g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? make[3]: *** [Makefile:559: ffmpegfs.o] Error 1 make[3]: *** Waiting for unfinished jobs g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? make[3]: *** [Makefile:559: cache.o] Error 1 g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? g++: error: unrecognized command line option ‘-march=native’; did you mean ‘-mcpu=native’? For one, as you can see, "-march" is not supported on every architecture, and, secondly, you are not allowed to build a package with "-march=native" as this will adjust the baseline to the one on the buildd hardware instead of using the baseline that is determined by the gcc specs set by dpkg which is not allowed according to Debian Policy. Adrian > [1] https://buildd.debian.org/status/package.php?p=ffmpegfs=unstable -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#944017: libsoxr: autopkgtest regression: segmentation fault
Hi Bernhard! On 12/12/19 2:42 AM, Bernhard Übelacker wrote: > In the end it runs: > > dd if=/dev/urandom count=1000 | /tmp/tmp.bQI47Dtfhv/4-split-channels 7 > 6 2 2 3 > (...) > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, > src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 > 67 DO_16; > (gdb) bt > #0 0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, > src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67 > #1 _soxr_interleave_f (data_type=, dest0=0x4c241a0, > src=, n=6735, ch=1, seed=0x4c51500) at ./src/data-io.c:213 > #2 0x0484d60f in soxr_output_1ch (p=p@entry=0x4c513e0, i=0, > dest=dest@entry=0x4c24100, len=, len@entry=6923, > separated=separated@entry=true) at ./src/soxr.c:664 > #3 0x0484d8cc in soxr_process._omp_fn.0 () at ./src/soxr.c:786 > #4 0x04bcaa42 in GOMP_parallel (fn=0x484d830 > , data=0x1fff000800, num_threads=4, flags=0) at > ../../../src/libgomp/parallel.c:171 > #5 0x0484ef78 in soxr_process (p=0x4c513e0, in=0x4c24150, > ilen0=, idone0=0x0, out=0x4c24100, olen=6923, > odone0=0x1fff0008a8) at ./src/soxr.c:781 > #6 0x00109fd8 in main (n=0, arg=0x1fff000b28) at > 4-split-channels.c:142 Thanks. This helps. I can reproduce the issue now. I'm looking into this now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#666707: hfsprogs is not DFSG-Free
Hello! I have done some research and I do not think that the claim that this software is not dfsg-free is correct. First of all, the license claimed in debian/copyright is incorrect. The upstream package that hfsprogs is based on - diskdev_cmds-332.25 [1] - is not covered by the APSL-2.0 but versions 1.0, 1.1 and 1.2 [2, 3, 4]. Secondly, the APSL-1.2 [5] does not fail the dissident test in my opinion as claimed in [6] as the paragraph 2.2 (c), which mandates the public distribution of modifications to the software package, talks about "Deployed Modifications", i.e. public distribution: > (c) You must make Source Code of all Your Deployed Modifications publicly > available under the terms of this License, including the license grants > set forth in Section 3 below, for as long as you Deploy the Covered Code > or twelve (12) months from the date of initial Deployment, whichever > is longer. You should preferably distribute the Source Code of Your > Deployed Modifications electronically (e.g. download from a web site); > and What "Deploy" means, is explained in 1.4: > 1.4 "Deploy" means to use, sublicense or distribute Covered Code other than > for Your internal research and development (R) and/or Personal Use, > and includes without limitation, any and all internal use or distribution > of Covered Code within Your business or organization except for R use > and/or Personal Use, as well as direct or indirect sublicensing or > distribution > of Covered Code by You to any third party in any form or manner. Thus, the license does not fail the dissident test as explained in [7] as the requirement for public distribution of modifications explicitly excludes personal use and/or use in research and development. I do not see how the APSL-1.2 deviates from the GPL-2 here which also requires the distribution of modifications outside personal use [8]: > 3. You may copy and distribute the Program (or a work based on it, under > Section > 2) in object code or executable form under the terms of Sections 1 and 2 > above > provided that you also do one of the following: > > a) Accompany it with the complete corresponding machine-readable source > code, >which must be distributed under the terms of Sections 1 and 2 above on > a >medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to > give >any third party, for a charge no more than your cost of physically > performing >source distribution, a complete machine-readable copy of the > corresponding >source code, to be distributed under the terms of Sections 1 and 2 > above on >a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to > distribute >corresponding source code. (This alternative is allowed only for > noncommercial >distribution and only if you received the program in object code or > executable >form with such an offer, in accord with Subsection b above.) The GPL-2 is even stricter as it mandates three years of availability of modifications in 3. b) while the APSL-1.2 requires only 12 months. Adrian > [1] https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/ > [2] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/newfs_hfs.tproj/newfs_hfs.c.auto.html > [3] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/fsck_hfs.tproj/fsck_hfs.c.auto.html > [4] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-332.25/mount_hfs.tproj/mount_hfs.c.auto.html > [5] https://opensource.apple.com/source/hfs/hfs-522.0.9/APPLE_LICENSE > [6] https://lists.debian.org/debian-legal/2001/09/msg00103.html > [7] https://wiki.debian.org/DissidentTest > [8] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#927255: powerpc-utils is uninstallable
Control: severity -1 normal Hi! Lowering the severity as this affects powerpc and ppc64 only [1], so no release architectures. On the other hand, I have uploaded pmac-utils to unreleased for powerpc and ppc64. On the other hand, it looks like that the package seems orphaned, so I will try to adopt it, update it to the latest version and possibly figure out whether pmac-utils is still required or not. Thanks, Adrian > [1] https://sources.debian.org/src/powerpc-utils/1.3.2-1.1/debian/control/#L13 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956400: pdf: FTBFS on multiple 32-bit architectures, needs libatomic
Source: qpdf Version: 10.0.1-1 Severity: serious Justification: ftbfs User: debian-...@lists.debian.org Usertags: armel Hi! qpdf fails to build from source on multiple architectures due to missing symbols from libatomic [1]: /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status make[1]: *** [libtests/build.mk:52: libtests/build/aes] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: *** [libtests/build.mk:52: libtests/build/bits] Error 1 make[1]: *** [zlib-flate/build.mk:22: zlib-flate/build/zlib-flate] Error 1 /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status make[1]: *** [libtests/build.mk:52: libtests/build/buffer] Error 1 /usr/bin/ld: /<>/libqpdf/build/.libs/libqpdf.so: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status This is a known issue with gcc [2] and can be fixed by linking against libatomic, similar to apt-cacher-ng [3] and [4]. Please apply such a fix for armel, mipsel, m68k, powerpc and sh4. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qpdf=armel=10.0.1-1=1586486160=0 > > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862002 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859689
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Control: reopen -1 On 3/28/20 6:16 PM, John Paul Adrian Glaubitz wrote: > On 3/28/20 5:39 PM, Ivo De Decker wrote: >> This bug wasn't fixed in time for buster. Is it still present in bullseye? If >> so, it might be good to try to fix it this time. > > I fixed the bug upstream [1], so we can safely close the issue here. Ah, I just realized this bug also affected s390x. Sorry, I will reopen it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954134: [d-i bullseye alpha2] installing grub fails
On 3/17/20 12:49 PM, Holger Wansing wrote: > However: > >> Mar 16 09:55:43 main-menu[285]: (process:1258): grub-probe: error: unknown >> filesystem. > [...] >> Mar 16 09:55:43 main-menu[285]: (process:1258): corrupted size vs. prev_size >> Mar 16 09:55:43 main-menu[285]: (process:1258): Aborted >> Mar 16 09:55:43 main-menu[285]: WARNING **: Configuring 'grub-installer' >> failed with error code 134 >> Mar 16 09:55:43 main-menu[285]: WARNING **: Menu item 'grub-installer' >> failed. Yes, I have seen that. However, grub-installer is basically a script which invokes grub-install, so I'm not sure where that crash should come from. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954134: [d-i bullseye alpha2] installing grub fails
On 3/17/20 11:05 AM, Holger Wansing wrote: > Logs attached. grub-installer did not report any problems: Mar 16 09:55:41 grub-installer: info: Installing grub on '/dev/sda' Mar 16 09:55:41 grub-installer: info: grub-install does not support --no-floppy Mar 16 09:55:41 grub-installer: info: Running chroot /target grub-install --force "/dev/sda" Mar 16 09:55:41 grub-installer: Installing for i386-pc platform. Mar 16 09:55:42 grub-installer: Installation finished. No error reported. Mar 16 09:55:42 grub-installer: info: grub-install ran successfully Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953958: Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Hi Marco! On 3/15/20 2:33 AM, Marco d'Itri wrote: > On Mar 15, John Paul Adrian Glaubitz wrote: > >> Do you have a patch handy, then I'll fix the package manually for the time >> being for ia64 only? > Just edit debian/patch_libtool. Works. I had to modify debian/libcrypt1.symbols.ia64 as well: --- libcrypt1.symbols.ia64~ 2020-02-28 20:26:01.0 +0100 +++ libcrypt1.symbols.ia64 2020-03-15 09:20:38.110547617 +0100 @@ -1,4 +1,4 @@ -libcrypt.so.1.1 libcrypt1 #MINVER# +libcrypt.so.1 libcrypt1 #MINVER# #include "libcrypt1.symbols.common" GLIBC_2.0@GLIBC_2.0 1:4.1.0 crypt@GLIBC_2.0 1:4.1.0 So, please don't forget this. > Let me know if it works and I will apply the change. Thanks. Please go ahead changing debian/patch_libtool and debian/libcrypt1.symbols.ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
On 3/14/20 5:19 PM, James Clarke wrote: > This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not > libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1] > for an old glibc build log to demonstrate the correct name (and note that, > unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override > libcrypt's version). Do you have a patch handy, then I'll fix the package manually for the time being for ia64 only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Package: libcrypt1 Version: 1:4.4.15-1 Followup-For: Bug #953562 User: debian-i...@lists.debian.org Usertags: ia64 Hello! This actually causes issues on ia64 now: Setting up libc6.1:ia64 (2.30-2) ... /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory dpkg: error processing package libc6.1:ia64 (--configure): installed libc6.1:ia64 package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: libc6.1:ia64 E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. E: Package installation failed So it's not just a theoretical issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#950974: sqlite3: Regressions on big-endian targets break other packages
Source: sqlite3
Severity: critical
Tags: patch
Justification: breaks unrelated software
User: debian-s...@lists.debian.org
Usertags: s390x
Hi!
Due to a regression in sqlite3, git has been failing to build from source
on multiple big-endian targets, including the release target s390x [1].
openSUSE has recently cherry-picked two upstream commits which address
this issue [2, 3, 4] and I have verified that these patches fix git
in Debian on ppc64 (and I assume s390x and sparc64 as well). Thus, please
include these patches to unbreak git on ppc64, sparc64 and s390x.
Severity set to 'critical' as this bug breaks unrelated software.
Attaching the two patches taken from openSUSE.
Thanks,
Adrian
> [1] https://marc.info/?l=git=158120991004802=2
> [2]
> https://build.opensuse.org/package/rdiff/server:database/sqlite3?linkrev=base=241
> [3] https://sqlite.org/src/info/04885763c4cd00cb
> [4] https://sqlite.org/src/info/b20503aaf5b6595a
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: ext/fts5/test/fts5matchinfo.test
==
--- ext/fts5/test/fts5matchinfo.test
+++ ext/fts5/test/fts5matchinfo.test
@@ -498,23 +498,26 @@
CREATE VIRTUAL TABLE t1 USING fts5(x, y);
INSERT INTO t1 VALUES('a', 'b');
INSERT INTO t1 VALUES('c', 'd');
}
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res {X'0200'}
+} else {
+ set res {X'0002'}
+}
do_execsql_test 15.1 {
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
-
+} $res
do_execsql_test 15.2 {
DELETE FROM t1_content WHERE rowid=1;
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
+} $res
fts5_aux_test_functions db
do_execsql_test 15.3 {
SELECT fts5_test_all(t1) FROM t1 LIMIT 1;
} {
{columnsize {0 0} columntext {c d} columntotalsize {2 2} poslist {} tokenize
{c d} rowcount 2}
}
finish_test
-
Index: test/fts4aa.test
==
--- test/fts4aa.test
+++ test/fts4aa.test
@@ -227,17 +227,22 @@
} {1 {database disk image is malformed}}
# 2019-11-18 https://bugs.chromium.org/p/chromium/issues/detail?id=1025467
db close
sqlite3 db :memory:
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res
{X'02000E000E000100010001000100'}
+} else {
+ set res
{X'0002000E000E0001000100010001'}
+}
do_execsql_test fts4aa-6.10 {
CREATE VIRTUAL TABLE f USING fts4();
INSERT INTO f_segdir VALUES (77,91,0,0,'255
77',x'000130804d5c4ddd4d4d7b4d4d4d614d8019ff4d0501204d4d2e4d6e4d4d4d4b4d6c4d004d4d4d4d4d4d3d4d5d4d4d645d4d004d4d4d4d4d4d4d4d4d454d6910004d05054d646c4d004d5d4d4d4d4d3d4d4d4d4d4d4d4d4d4d4d4d69624d4d4d04004d4d4d4d4d604d4ce1404d554d45');
INSERT INTO f_segdir VALUES (77,108,0,0,'255
77',x'000131fa64004d4d4d3c5d4d654d4d4d614d8000ff4d0501204d4d2e4d6e4d4d4dff4d4d4d4d4d4d00104d4d4d4d4d4d4d0400311d4d4d4d4d4d4d4d4d4d684d6910004d05054d4d6c4d004d4d4d4d4d4d3d4d4d4d4d644d4d4d4d4d4d69624d4d4d03ed4d4d4d4d4d604d4ce1404d550080');
INSERT INTO f_stat VALUES
(0,x'808080801064004d4d4d3c4d4d654d4d4d614d8000ff4df6ff1a00204d4d2e4d6e4d4d4d104d4d4d4d4d4d00104d4d4d4d4d4d69574d4d4d31044d4d4d3e4d4d4c4d05004d6910');
SELECT quote(matchinfo(f,'pnax')) from f where f match '0 1';
-} {X'02000E000E000100010001000100'}
+} $res
# 2019-11-18 Detect infinite loop in fts3SelectLeaf()
db close
sqlite3 db :memory:
do_catchsql_test fts4aa-7.10 {
Index: src/insert.c
==
--- src/insert.c
+++ src/insert.c
@@ -2168,16 +2168,18 @@
** Hence, make a complete copy of the opcode, rather than using
** a pointer to the opcode. */
x = *sqlite3VdbeGetOp(v, addrConflictCk);
if( x.opcode!=OP_IdxRowid ){
int p2; /* New P2 value for copied conflict check opcode */
+ const char *zP4;
if( sqlite3OpcodeProperty[x.opcode]_JUMP ){
p2 = lblRecheckOk;
}else{
p2 = x.p2;
}
- sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, x.p4.z, x.p4type);
+ zP4 = x.p4type==P4_INT32 ? SQLITE_INT_TO_PTR(x.p4.i) : x.p4.z;
+ sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, zP4, x.p4type);
sqlite3VdbeChangeP5(v, x.p5);
VdbeCoverageIf(v, p2!=x.p2);
}
nConflictCk--;
addrConflictCk++;
Bug#948371: ruby2.7: FTBFS on multiple architectures due to outdated symbols file(s)
Source: ruby2.7 Severity: serious Tags: ftbfs Justification: fails to build from source Hello! ruby2.7 fails to build from source on multiple architectures due to mismatched symbols files: - armel - armhf - i386 - mips64el - mipsel - s390x - m68k - ppc64 - sparc64 Architectures not listed above have different issues and need to be fixed separately. To update the symbols file, the easiest way is to use the helper utilities by the Qt/KDE team [1]. Adrian > [1] https://wiki.debian.org/UsingSymbolsFiles -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL
On 12/29/19 12:58 PM, Patrick Matthäi wrote: >> It pretty much looks like the development files for OpenGL are missing >> and the linker is complaining it can't find libGL to link against. > > > I think this just happens because of the added -latomic flag. See the > build logs and the changelog from -1 to -3 I don't think so. It builds fine on ia64 after all. I think it's more related to recent changes in libglvnd, see: > https://packages.qa.debian.org/libg/libglvnd/news/20191220T191934Z.html I'll try a give-back on one of the buildds. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL
Hi! On 12/29/19 10:36 AM, Patrick Matthäi wrote: >> collect2: error: ld returned 1 exit status >> make[3]: *** [Makefile:61: ../libmltopengl.so] Error 1 >> make[3]: Leaving directory '/<>/src/modules/opengl' > > Yes, I already asked for help here: > https://lists.debian.org/debian-arm/2019/12/msg00017.html Did you try adding libgl1-dev to Build-Depends in debian/control? It pretty much looks like the development files for OpenGL are missing and the linker is complaining it can't find libGL to link against. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
