Bug#970043: Request to help test ia64 build for galera-4
Hi Otto, On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote: > I have a patch to tentatively fix Debian package galera-4 builds on > ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 > > Would anybody be interested in helping out and testing if the build > fully passes now? > > Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 ia64 support has been removed from glibc, the Linux kernel and soon gcc, so it will be removed within the next weeks after we have made an archive copy. There is no need to fix any bugs on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071542: boost1.83: Please enable context library on ppc64
Source: boost1.83 Version: 1.83.0-2.1+b1 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, the context library is not being installed on ppc64 in debian/control despite being enabled in debian/rules. Please add ppc64 to the list of supported architectures for the context library and make sure it's actually being built and installed. Tests can be performed on the porterbox perotto.debian.net. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071524: git: Please add patch to fix testsuite on sparc64
Source: git
Version: 1:2.45.1-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hello,
the attached patch fixes the Git testsuite on sparc64. I've already
sent it upstream [1]. Could you include it for the next package
upload?
Thanks,
Adrian
> [1]
> https://lore.kernel.org/git/2024052009.99882-1-glaub...@physik.fu-berlin.de
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 6580fdb9004e2d61fcb3d1f04c31bc7e328ed442 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Mon, 20 May 2024 13:03:49 +0200
Subject: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on
Linux SPARC
On SPARC systems running Linux, individual processors are denoted with
"CPUnn:" in /proc/cpuinfo instead of the usual "processor NN:" so that
the current regexp in ncores() returns 0. Extend the regexp to match
lines with "CPUnn:" as well to properly detect the number of available
cores on these systems.
Signed-off-by: John Paul Adrian Glaubitz
---
t/chainlint.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/chainlint.pl b/t/chainlint.pl
index 556ee91a15..63cac942ac 100755
--- a/t/chainlint.pl
+++ b/t/chainlint.pl
@@ -718,7 +718,7 @@ sub ncores {
# Windows
return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
# Linux / MSYS2 / Cygwin / WSL
- do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';
+ do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:||^CPU[\d]*:/, <>)); } if -r '/proc/cpuinfo';
# macOS & BSD
return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
return 1;
--
2.39.2
Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down
Hello, On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on arm64. > (...) > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=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#1054109: ocaml: lack of LoongArch support
Hi LiXing, > [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)] I'm afraid this patch is way too large to be included in a Debian package. Please make sure these changes are being upstreamed, so that native LoongArch support will be part of the next major Ocaml upstream release in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)
On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote: > Hi, > > [John Paul Adrian Glaubitz 2020-05-10] > > I would like to adopt this package. There is a new upstream available and > > the > > repository has been moved to Github with some recent activity [1]. > > What came out of this intent? > > I just migrated the package to a git repository on > https://salsa.debian.org/debian/unadf >. I started working on this, but I got stuck because of the fact that the upstream package is actually not just unadf but a whole library that might need different treatment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1070018: ausweisapp: Mising dependency to libqt6svg6
Hello Juergen, On Sun, 2024-04-28 at 18:09 +0200, Juergen Bausa wrote: > I run ausweisapp backport on bookworm. However, it doesnt display an icon in > the control panel of KDE. > Ausweisapp2 (which is actually a slightly older version) did display an icon. > While ausweisapp2 depended > on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the > icon is displayed in ausweisapp > also. So I think the dependency on libqt6svg6 is just missing in ausweisapp. This is a known issue and a result of a potential bug in Qt6 which results in dpkg-shlibdeps not adding the runtime dependency for libqt6svg6 during build. While I could hardwire libqt6svg6 as a runtime dependency into debian/control, this would cause problems when the ABI of the Qt6 SVG library is being bumped resulting in the library package being renamed from libqt6svg6 to libqt6svg7. Currently, the workaround is to install the missing libqt6svg6 package manually. > In addition it seems to me that the window of AusweisApp looks extremely > clean (just white background). > Ausweisapp2 was much more colourful. I guess that another lib is missing for > ausweisapp to display > the intended look. No, this is by design. The upstream developers have decided to make the user interface as minimalistic as possible. I'm not such a fan of the new design either, but that's just how it looks now. Adrian -- .''`. 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#1060196: fixed in ghc 9.4.7-5
On Fri, 2024-04-12 at 22:35 +, Debian FTP Masters wrote:
>* Build unregisterised on powerpc (Closes: #1060196)
I am not 100% sure what happened, but this upload produced another
broken GHC compiler on powerpc. Lots of packages fail to build now
due to GHC segfaulting [1]:
Running dh_listpackages
libghc-splitmix-dev
libghc-splitmix-prof
libghc-splitmix-doc
-e: error: debian/hlibrary.setup build --builddir=dist-ghc died with signal 11
at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build
--builddir=dist-ghc died with sig"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build",
"--builddir=dist-ghc") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned
exit status 2
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=haskell-splitmix=powerpc=0.1.0.5-1%2Bb1=1713046430=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1046444: virtualjaguar: Fails to build source after successful build
Hi, On Sun, 2023-08-13 at 21:21 +0200, Lucas Nussbaum wrote: > Relevant part of the build log: > > cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S > > - > > > > dpkg-buildpackage: info: source package virtualjaguar > > dpkg-buildpackage: info: source version 2.1.3-2 > > dpkg-buildpackage: info: source distribution unstable > > dpkg-buildpackage: info: source changed by John Paul Adrian Glaubitz > > > > dpkg-source --before-build . > > fakeroot debian/rules clean > > dh clean > > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) > >dh_auto_clean > > dh_auto_clean: warning: Compatibility levels before 10 are deprecated > > (level 9 in use) > > make -j1 clean > > make[1]: Entering directory '/<>' > > -ne [01;33m***[00;32m Cleaning out the garbage...[00m > > done! > > make[1]: Leaving directory '/<>' > >dh_clean > > dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 > > in use) > > dpkg-source -b . > > dpkg-source: info: using source format '3.0 (quilt)' > > dpkg-source: info: building virtualjaguar using existing > > ./virtualjaguar_2.1.3.orig.tar.bz2 > > dpkg-source: info: using patch list from debian/patches/series > > dpkg-source: warning: ignoring deletion of file src/m68000/m68kdasm.c.bak, > > use --include-removal to override > > dpkg-source: info: local changes detected, the modified files are: > > virtualjaguar-2.1.3/.qmake.stash > > virtualjaguar-2.1.3/src/version.h > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/virtualjaguar_2.1.3-2.diff.v1VkyG > > dpkg-source: info: Hint: make sure the version in debian/changelog matches > > the unpacked source tree > > dpkg-source: info: you can integrate the local changes with dpkg-source > > --commit > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 > > > > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S' failed to run. After close inspection of the build log and the original tarball, it turns out that the tarball used is not identical to the one available from the upstream FTP server [1]: glaubitz@z6:~/debian> wget -q http://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.3.tar.bz2 -O virtualjaguar-upstream-2.1.3.tar.bz2 glaubitz@z6:~/debian> md5sum virtualjaguar-upstream-2.1.3.tar.bz2 virtualjaguar_2.1.3.orig.tar.bz2 17af87b3a7cfd9106e49afc56d4858e6 virtualjaguar-upstream-2.1.3.tar.bz2 0e3f30737c171c096ac2690a38f7029a virtualjaguar_2.1.3.orig.tar.bz2 glaubitz@z6:~/debian> Further inspection reveals that the file src/m68000/m68kdasm.c.bak that is deleted during build and prevents a second successful build is not part of the original source: glaubitz@z6:~/debian> tar tf virtualjaguar_2.1.3.orig.tar.bz2 |grep bak linux-2.1.3/src/m68000/m68kdasm.c.bak glaubitz@z6:~/debian> tar tf virtualjaguar-upstream-2.1.3.tar.bz2 |grep bak glaubitz@z6:~/debian> I don't really remember how I created the first upload of the 2.1.3 upstream version, but since upstream development has ceased, I can upload a fixed version only with a forged upstream version using "really" or similar since there won't be a new upstream release unless the upstream project is forked. 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#1068691: util-linux: enosys program missing on m68k and sh4
Hi Christian, On Tue, 2024-04-09 at 10:00 +0200, Chris Hofstaedtler wrote: > * John Paul Adrian Glaubitz [240409 09:36]: > > the program enosys doesn't seem to be available on m68k and sh4, so it > > needs to > > be excluded from the install files with the help of dh-exec: > > I imagine the other option is to expand audit-arch.h to cover these > archs. Do you mind reviewing this, then I could sent it upstream? Do > note that I've mostly guessed what might be right. Ah, I wasn't aware it's related to seccomp ;-). > Relevant uapi header: > https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L432 > > diff --git a/include/audit-arch.h b/include/audit-arch.h > index ade182417..9afc663cd 100644 > --- a/include/audit-arch.h > +++ b/include/audit-arch.h > @@ -35,6 +35,8 @@ > #endif > #elif __powerpc__ > #define SECCOMP_ARCH_NATIVE AUDIT_ARCH_PPC > +#elif __m68k__ > +#define SECCOMP_ARCH_NATIVE AUDIT_ARCH_M68K > #elif __mips__ > #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_MIPS > @@ -47,6 +49,12 @@ > #else > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_ARCV2 > #endif > +#elif __sh__ > +#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SH > +#else > +# define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SHEL > +#endif > #elif __sparc__ > #if __SIZEOF_POINTER__ == 4 > # define SECCOMP_ARCH_NATIVE AUDIT_ARCH_SPARC Looks good to me. I was actually the person who added support for m68k and sh4 to libseccomp. Unfortunately, upstream still hasn't released the a new stable version which includes my patches. This is planned for 2.6.0. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068691: util-linux: enosys program missing on m68k and sh4
Source: util-linux Version: 2.40-5 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello, the program enosys doesn't seem to be available on m68k and sh4, so it needs to be excluded from the install files with the help of dh-exec: dh_install \ -Nfdisk-udeb -Nlibblkid1-udeb \ -Nlibfdisk1-udeb -Nlibsmartcols1-udeb -Nlibuuid1-udeb \ -Nutil-linux-udeb dh_install: warning: Cannot find (any matches for) "usr/bin/enosys" (tried in ., debian/tmp) Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1068081: rust-dns-lookup: "lookup::test_rev_localhost' panicked at 'assertion failed" on loong64
Hi Dandan, please report this bug upstream as it's not Debian-specific. The upstream bug tracker can be found in [1]. Adrian > [1] https://github.com/keeperofdakeys/dns-lookup/issues -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat
Hello Thomas, On Wed, 2024-04-03 at 12:22 +, PEPONAS Thomas wrote: > On IBM Power paltform , add cpu entitlement can not be done without > LPARCFG=Y , because /proc/ppc64/lparcfg could not open: > Logs from drmgr : > ## Apr 03 10:54:41 2024 ## > drmgr: -c cpu -r -q 10 -p ent_capacity -w 5 -d 1 > Validating CPU DLPAR capability...yes. > Could not open "/proc/ppc64/lparcfg" > No such file or directory > CPU entitlement capability is not enabled on this platform. > Could not update system parameter ent_capacity > ## Apr 03 10:54:41 2024 ## > > will the LPARCFG option be activated on future versions? The Debian kernel maintainers are informed since I have reassigned the bug to the kernel package. I assume this will be fixed in the near future. I might do it myself if I find the time during the next weeks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057050: closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1057050: fixed in qt6-multimedia 6.6.1-1)
Control: reopen -1 Hi, looks like this didn't work: > https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia=powerpc=6.4.2-11=1705003199=0 Reopening the bug therefore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1067735: www.debian.org: Please update links for PowerPC CHRP port
Package: www.debian.org Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, the following page for the PowerPC CHRP has some dead links: > https://www.debian.org/ports/powerpc/inst/chrp These links can be updated to point to archive.debian.org: linux.bin: http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/linux.bin rescue.bin: http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/rescue.bin driver-1.bin: http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/driver-1.bin driver-2.bin: http://archive.debian.org/debian/dists/woody/main/disks-powerpc/current/chrp/images-1.44/driver-2.bin basedebs.tar: http://archive.debian.org/debian/dists/woody/main/disks-powerpc/base-images-current/basedebs.tar CHRP System from Geert Uytterhoeven: https://web.archive.org/web/20140625035302/http://users.telenet.be/geertu/Linux/PPC/ In the long term, it might be a good idea to move the documentation for old architectures to Debian Ports. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1067646: llvm-toolchain-17: please enable m68k build
Hi Thorsten, On Mon, 2024-03-25 at 00:33 +, Thorsten Glaser wrote: > Attempts to build llvm-toolchain-15 (needed for qt6) and 17 (which > is apparently what everyone should switch to, but 16 might also need > it) fail at configure stage: > > The target `M68k' is experimental and must be passed via > LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. > > Please do so ;-) I guess. Unless we switch to 32-bit alignment, LLVM won't build natively on m68k :-(. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1038585: virtualjaguar: Depends on SDL 1.2
Control: tags -1 +patch
Hello,
On Tue, 2023-08-29 at 13:05 +0200, John Paul Adrian Glaubitz wrote:
> Any chance this can get a proper release so that we can update the Debian
> package
> without having to add local patches?
Attaching the two patches that I used for porting the openSUSE package to SDL-2.
The patch virtualjaguar-sdl2.patch required some rebasing before it applied
against
the original tarball source.
I will try to take care of this bug and the FTBFS over the Easter holidays.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From 05c2e7989d2c73fcfa5e01b014ac6ee649ba3de2 Mon Sep 17 00:00:00 2001
From: Teemu Hukkanen
Date: Thu, 3 Aug 2023 02:43:04 +0300
Subject: [PATCH 2/3] Use joystick identifier from SDL_JoystickOpen for
SDL_JoystickName
---
src/gui/gamepad.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gui/gamepad.cpp b/src/gui/gamepad.cpp
index a7a9498..f72cc0c 100644
--- a/src/gui/gamepad.cpp
+++ b/src/gui/gamepad.cpp
@@ -55,7 +55,7 @@ void Gamepad::AllocateJoysticks(void)
// We need to copy the contents of this pointer, as SDL will change it
// willy nilly to suit itself
// padName[i] = SDL_JoystickName(i);
- strncpy(padName[i], SDL_JoystickName(i), 127);
+ strncpy(padName[i], SDL_JoystickName(pad[i]), 127);
padName[i][127] = 0; // Just in case name's length > 127
if (pad[i])
--
2.43.0
From 5bfd43189df61e1f49b9186bcfce129f2a643e9b Mon Sep 17 00:00:00 2001
From: Teemu Hukkanen
Date: Thu, 3 Aug 2023 02:37:07 +0300
Subject: [PATCH 1/3] Switch to SDL2
---
jaguarcore.mak | 3 ++-
src/dac.cpp | 2 +-
src/dsp.cpp | 2 +-
src/gui/app.cpp | 2 +-
src/gui/gamepad.h | 2 +-
src/gui/mainwin.cpp | 2 +-
src/jaguar.cpp | 3 +--
src/m68000/Makefile | 2 +-
virtualjaguar.pro | 8
9 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/jaguarcore.mak b/jaguarcore.mak
index 7252be7..e4a39c2 100644
--- a/jaguarcore.mak
+++ b/jaguarcore.mak
@@ -41,8 +41,9 @@ LD := $(CROSS)gcc
AR := $(CROSS)ar
ARFLAGS := -rs
-SDL_CFLAGS = `$(CROSS)sdl-config --cflags`
+SDL_CFLAGS = `$(CROSS)sdl2-config --cflags`
DEFINES = -D$(SYSTYPE) $(HAVECDIO)
+
GCC_DEPS = -MMD
INCS := -I./src
diff --git a/src/dac.cpp b/src/dac.cpp
index e94d564..3745846 100644
--- a/src/dac.cpp
+++ b/src/dac.cpp
@@ -43,7 +43,7 @@
#include "dac.h"
//#include
-#include "SDL.h"
+#include
#include "cdrom.h"
#include "dsp.h"
#include "event.h"
diff --git a/src/dsp.cpp b/src/dsp.cpp
index 8853f94..f9f3f8b 100644
--- a/src/dsp.cpp
+++ b/src/dsp.cpp
@@ -16,7 +16,7 @@
#include "dsp.h"
-#include // Used only for SDL_GetTicks...
+#include // Used only for SDL_GetTicks...
#include
#include "dac.h"
#include "gpu.h"
diff --git a/src/gui/app.cpp b/src/gui/app.cpp
index 9414dd4..347be00 100644
--- a/src/gui/app.cpp
+++ b/src/gui/app.cpp
@@ -17,7 +17,7 @@
#include "app.h"
-#include
+#include
#include
#include "gamepad.h"
#include "log.h"
diff --git a/src/gui/gamepad.h b/src/gui/gamepad.h
index 902dae1..2c62932 100644
--- a/src/gui/gamepad.h
+++ b/src/gui/gamepad.h
@@ -21,7 +21,7 @@
#define JOY_AXISDIR_MASK 0x01
#include
-#include "SDL.h"
+#include
// buttonID is the combination of the type (BUTTON, HAT) and the button #
// (0-255 for buttons, 0-31 for hats). Hats also have 0-7 for a button #
diff --git a/src/gui/mainwin.cpp b/src/gui/mainwin.cpp
index cb01b02..a9f9cfc 100644
--- a/src/gui/mainwin.cpp
+++ b/src/gui/mainwin.cpp
@@ -36,7 +36,7 @@
#include "mainwin.h"
-#include "SDL.h"
+#include
#include "app.h"
#include "about.h"
#include "configdialog.h"
diff --git a/src/jaguar.cpp b/src/jaguar.cpp
index f829892..5d7726f 100644
--- a/src/jaguar.cpp
+++ b/src/jaguar.cpp
@@ -17,8 +17,7 @@
#include "jaguar.h"
#include
-#include
-#include "SDL_opengl.h"
+#include
#include "blitter.h"
#include "cdrom.h"
#include "dac.h"
diff --git a/src/m68000/Makefile b/src/m68000/Makefile
index 16ed159..6796a85 100644
--- a/src/m68000/Makefile
+++ b/src/m68000/Makefile
@@ -23,7 +23,7 @@ HOSTCC := gcc
ARFLAGS := -rs
GCC_DEPS = -MMD
-INCS:= -I. -I./obj `$(CROSS)sdl-config --cflags`
+INCS:= -I. -I./obj `$(CROSS)sdl2-config --cflags`
OBJS = \
obj/cpustbl.o \
diff --git a/virtualjaguar.pro b/virtualjaguar.pro
index a53b444..6b6e651 100644
--- a/virtualjaguar.pro
+++ b/virtualjaguar.pro
@@ -33,8 +33,8 @@ else:macx { DEFINES += __GCCUNIX__ __THINK_STUPID__ }
else:unix { DEFINES += __GCCUNIX__ }
# SDL (to link statically on Mac)
-macx { LIBS += `sdl-config --static-libs` }
-else { LIBS += `$(CROSS)sdl-config --libs` }
+macx { LIBS += `sd
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Hi! On Thu, 2024-03-21 at 16:26 +, Thorsten Glaser wrote: > > please? I wanted to use the mitchy.debian.net porterbox but I got > > ECONNREFUSED. > > Adrian, do you have an idea about that? mitchy is back up again. The hosting server was forcefully rebooted without me being notified. I assume that happened due to maintenance reasons since the other Gandi machines were rebooted as well. Adrian -- .''`. 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#1067213: git: please consider temporarily disabling subversion/libsvn-perl build-dependencies on armhf and armel
Hello, On Wed, 2024-03-20 at 10:08 +0100, Emanuele Rocca wrote: > on armhf and armel both subversion and libsvn-perl are currently not > installable due to the ongoing 64-bit time_t transition. It seems > however that git builds fine without those, and the build dependencies > are just needed for the git-svn selftests. > > The attached patch drops the build dependencies on armhf and armel, and > could of course be reverted once subversion and libsvn-perl are > installable again on the affected architectures. If you do it, please do it for all affected architectures, i.e.: armel, armhf, hppa, m68k, powerpc and sh4 Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066996: python-greenlet: Please add patch to support sh4
Source: python-greenlet
Version: 3.0.1-3
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org
Hi,
the attached patch adds support for building python-greenlet on sh4, it's
a modified (fixed) version that is currently open for review upstream [1].
The fixed version can be found here [2].
Thanks,
Adrian
> [1] https://github.com/python-greenlet/greenlet/pull/398
> [2]
> https://github.com/glaubitz/greenlet/commit/e73592dec7950ad9fcdb5c0287ef3758df010f11
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From e73592dec7950ad9fcdb5c0287ef3758df010f11 Mon Sep 17 00:00:00 2001
From: Pietro Monteiro
Date: Wed, 6 Mar 2024 21:59:14 -0500
Subject: [PATCH] Add support for SuperH
---
src/greenlet/platform/switch_sh_gcc.h | 36 +++
src/greenlet/slp_platformselect.h | 2 ++
2 files changed, 38 insertions(+)
create mode 100644 src/greenlet/platform/switch_sh_gcc.h
diff --git a/src/greenlet/platform/switch_sh_gcc.h
b/src/greenlet/platform/switch_sh_gcc.h
new file mode 100644
index 000..5ecc3b3
--- /dev/null
+++ b/src/greenlet/platform/switch_sh_gcc.h
@@ -0,0 +1,36 @@
+#define STACK_REFPLUS 1
+
+#ifdef SLP_EVAL
+#define STACK_MAGIC 0
+#define REGS_TO_SAVE "r8", "r9", "r10", "r11", "r13", \
+ "fr12", "fr13", "fr14", "fr15"
+
+// r12 Global context pointer, GP
+// r14 Frame pointer, FP
+// r15 Stack pointer, SP
+
+static int
+slp_switch(void)
+{
+int err;
+void* fp;
+int *stackref, stsizediff;
+__asm__ volatile("" : : : REGS_TO_SAVE);
+__asm__ volatile("mov.l r14, %0" : "=m"(fp) : :);
+__asm__("mov r15, %0" : "=r"(stackref));
+{
+SLP_SAVE_STATE(stackref, stsizediff);
+__asm__ volatile(
+"add %0, r15\n"
+"add %0, r14\n"
+: /* no outputs */
+: "r"(stsizediff));
+SLP_RESTORE_STATE();
+__asm__ volatile("mov r0, %0" : "=r"(err) : :);
+}
+__asm__ volatile("mov.l %0, r14" : : "m"(fp) :);
+__asm__ volatile("" : : : REGS_TO_SAVE);
+return err;
+}
+
+#endif
diff --git a/src/greenlet/slp_platformselect.h
b/src/greenlet/slp_platformselect.h
index c959f0f..8a77328 100644
--- a/src/greenlet/slp_platformselect.h
+++ b/src/greenlet/slp_platformselect.h
@@ -64,6 +64,8 @@ extern "C" {
# include "platform/switch_aarch64_gcc.h" /* LLVM Aarch64 ABI for Windows */
#elif defined(__GNUC__) && defined(__loongarch64) && defined(__linux__)
# include "platform/switch_loongarch64_linux.h" /* LoongArch64 */
+#elif defined(__GNUC__) && defined(__sh__)
+# include "platform/switch_sh_gcc.h" /* SuperH */
#endif
#ifdef __cplusplus
--
2.44.0
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#1059991: grub-installer: build loong64.udeb for loongarch64
Hi Dandan, On Tue, 2024-03-12 at 16:07 +0800, zhangdandan wrote: > Thanks for your heads up. > I have updated the patch (Add support for loongarch64). > Please consider the patch I have attached. > Your suggestions are always welcome. I already made the changes before you sent this mail, so we're all good. See: https://salsa.debian.org/installer-team/grub-installer/-/commit/0962896894d83716dec19a60ba9db94fdc807a1c Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066023: libdebian-installer: Add subarch detection for loongarch64
Hi, On Mon, 2024-03-11 at 16:36 +0800, zhangdandan wrote: > I have added subarch detection for loongarch64 in libdebian-installer > source package. > Please consider the patch I have attached. > > The libdebian-installer source package was compiled successfully on my > local loong64 rootfs environment. > If you have any questions, you can contact me at any time. I have just added subarch detection for 64-bit LoongArch [1]. However, the proper filename is "subarch-loong64-linux.c" as the filename has to match the Debian architecture name, not the GNU triplet name (see the configure.ac). Adrian > [1] > https://salsa.debian.org/installer-team/libdebian-installer/-/commit/4ca769d4ba26ca4fa2e35f6932ee2a123cdf5312 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1065595: cyrus-sasl2: Please add nodoc build profile to allow disabling documentation
Source: cyrus-sasl2 Version: 2.1.28+dfsg1-4 Severity: normal User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: helm...@debian.org Hello, cyrus-sasl2 is one of the core dependencies required for bootstrapping Debian but requires the Pyton package Sphinx for building documentation. This can be easily avoided by removing the "doc-html" target during build. This way, the python3-sphinx-rtd-theme build dependency can be omitted. It would be ideal for a "nodoc" build profile which I am asking to be added here. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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#990913: Fixed
Hello André, On Fri, 2024-03-01 at 13:39 +0100, A. Klitzing wrote: > This is fixed with 2.1.0! Thanks for the feedback. I will upload version 2.1.0 within the next days and close this bug with the upload. I would like to wait a few for days as Debian's build host are currently very busy with the time64_t transition. > But I stick to it this is the real bug and should be fixed in Qt. > https://bugreports.qt.io/browse/QTBUG-82888 I agree. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1065132: rakudo: Please allow build on any architecture
Source: rakudo Version: 2022.12-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi, similar to #1065050 [1], there should be no reason to disable src:rakudo on any architecture, so please set the architecture fields in debian/ control to "any". Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065050 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1065050: moarvm: Please allow build on any architecture
Source: moarvm Version: 2022.12+dfsg-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi, the architecture list for moarvm (and rakudo) is limited to a set of architectures for no obvious reason. A quick build test on stadler.debian.net showed that the package builds find on sparc64. Thus, could you enable the build on all architectures for both moarvm and rakudo and anything else required for Perl 6? If packages fail to build from source, the porters can take care of the issues. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed
Hi! On Mon, 2024-02-26 at 08:25 +, Gayathri Berli wrote: > e cloned the gtk repo and built it with the following meson > commands.. But we see that almost all of the tests are failing. > So,we are suspecting thatwe might be missing something here.. > There could besome dependency packagesthatwe are missing?... The problem seems to be that XDG_RUNTIME_DIR is not set: Gdk-DEBUG: error: XDG_RUNTIME_DIR is invalid or not set in the environment. Looking at the debian/rules of the gtk4 package, there is a dedicated script in the package that the Debian package uses to run the tests: > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/run-tests.sh?ref_type=heads It's reference from here: > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L288 Or check what upstream states about running the tests. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1063937: glibc: Please add workaround to fix posix_spawn() on sparc64
Source: glibc Version: 2.37-15 Severity: important Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org,ker...@mkarcher.dialup.fu-berlin.de,s...@gentoo.org Hello, there is currently a nasty bug on sparc64 that breaks posix_spawn() [1] and potentially any package that uses gcc since libiberty switched to using posix_spawn() with gcc-14. The attached patch comes from Michael Karcher (CC'ed) and unbreaks posix_spawn() so that gcc works again without posix_spawn() failing with "Bad Address". Since this patch is just a workaround and we're not even sure whether the bug is in the kernel or glibc, it's not been pushed upstream yet. Adrian > [1] > https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.ca...@physik.fu-berlin.de -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S +++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S @@ -28,6 +28,9 @@ .text ENTRY (__clone) save%sp,-96,%sp + save%sp,-96,%sp + flushw + restore cfi_def_cfa_register(%fp) cfi_window_save cfi_register(%o7, %i7) --- glibc-2.37.orig/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S +++ glibc-2.37/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S @@ -32,6 +32,9 @@ ENTRY (__clone) save%sp, -192, %sp + save%sp, -192, %sp + flushw + restore cfi_def_cfa_register(%fp) cfi_window_save cfi_register(%o7, %i7)
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#1061879: webkit2gtk: Incorrect build-dependency on libseccomp-dev for m68k
Hello, On Mon, 2024-01-29 at 23:41 +, Alberto Garcia wrote: > On Mon, Jan 29, 2024 at 11:57:31PM +0100, John Paul Adrian Glaubitz wrote: > > src:webkit2gtk is currently BD-Uninstallable on m68k [1] since > > libseccomp is currently not available yet. > > I guess that the main problem is that webkit2gtk hasn't built in > m68k since the 2.36.x branch[1]. Is there anyone with the time and > knowledge to make it work again? It's not building because of the natural 16-bit alignment on m68k which means that the size asserts fail. However, I am building packages like webkit2gtk manually from time to time when I need them and upload them to unreleased if they become too old. In the long term, we're going to switch the default alignment on m68k to 32 bits which will fix these issues once and for all. > Otherwise changing the libseccomp build depencency is not really going to > solve anything, it only adds additional complexity to the build scripts. Please just fix the build dependencies and let the rest be my problem. It will eventually be fixed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1061879: webkit2gtk: Incorrect build-dependency on libseccomp-dev for m68k
Source: webkit2gtk Version: 2.42.4-1 Severity: normal User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello, src:webkit2gtk is currently BD-Uninstallable on m68k [1] since libseccomp is currently not available yet. While we actually added m68k to libseccomp upstream [2], it won't be available before upstream version 2.6.0. The same applies for sh4. Thus, please disable the libseccomp-dev build dependency on m68k for the time being until Debian has libseccomp 2.6.0. Once that has happened, libseccomp can be enabled for loong64, m68k and sh4. I assume this also applies to the build dependencies bubblewrap and xdg-dbus-proxy. Adrian > [1] https://buildd.debian.org/status/package.php?p=webkit2gtk=sid > [2] https://github.com/seccomp/libseccomp/pull/397 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1061133: libsoup3: Build profiles don't actually work
Hi Simon, On Fri, 2024-01-19 at 10:47 +, Simon McVittie wrote: > > From a quick look at libsoup3, it seems like it might only need > > GNUTLS for part of the test suite, and therefore needs to pass > > -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding > > -Dauto_features=enabled) whenever both of these profiles are disabled? > > Yes, this. Please see the commit that I'm about to push (the commit hook > should set this bug as pending when I do). Thanks for the very quick fix. Could you perform a new upload of libsoup3 within the next days so I can bootstrap the package for sh4 again? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1061133: libsoup3: Build profiles don't actually work
Source: libsoup3 Version: 3.4.4-2 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello, I was just trying to bootstrap libsoup3 for sh4 using build profiles. Unfortunately, that doesn't work since it seems that specifying multiple build profiles for a build dependency means that the build dependency is removed only if all of the specified profiles are activated. Thus, in order to strip "libapache2-mod-php" from the build dependencies, one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the libapache2-mod-php build dependency is still pulled in. This, however, means that that the "nocheck" profile has to be there to boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the build fail since this build dependency is mandatory. Not sure if it's actually a bug in apt which handles multiple profiles per build dependency other than one would expect. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1061125: rustc: Please disable profiler builtin on sparc64
Source: rustc Version: 1.70.0+dfsg1-5 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! The recently enabled profiler builtin is currently not supported on sparc64 and therefore leads to rustc failing to build from source [1]: error: could not find native static library `/usr/lib/llvm-16/lib/clang/16/lib/\ linux/libclang_rt.profile-sparc64.a`, perhaps an -L flag is missing? We need to fix the profiler in LLVM upstream on sparc64 first before we can enable it in Debian. Could you disable the profiler builtin for sparc64 again? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=rustc=sparc64=1.70.0%2Bdfsg1-5=1705412917=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
e software as it is provided by upstream. If upstream doesn't support usecase X, I am not the person to be blamed. > > Neither me nor the upstream maintainer are actually getting paid to provide > > this application > > on Linux or on Debian, so it's perfectly fine that we get to decide how we > > spend our free > > time. > > Nobody said otherwise. But literally with a bug this severe v2 can't and > shouldn't be accepted > into stable with Trixie. And if nobody fixes it, it's questionable how long > this package will be > accepted to stay in the repos at all. Again, the package is working as intended by upstream and the issue you are seeing is a known limitation. Software is never perfect and has always known issues. And instead of trying to educate people who do the actual work on how they are supposed to do the work, you could roll up your sleeves and try to help resolve this issue. Apparently, using AusweisApp on GNOME is very important to you. So I recommend you get start and help upstream, who has been CC'ed on this issue by me, fix the bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hello, On Tue, 2024-01-16 at 15:53 +0100, Richard wrote: > Am Mo., 15. Jan. 2024 um 21:38 Uhr schrieb John Paul Adrian Glaubitz > : > > On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > > > I second this report. The app did use to work actually, but recently - > > > not sure with > > > transitioning to ausweisapp with v2.0 or later, this breaks for me too. > > > > What breaks? Please be more specific! > > > > I mean the exact same behavior. App starts, it has an entry in the tray, but > no icon, > also none in the Gnome dock and no window is opening, OK, it wasn't clear from your initial message. In any case, upstream is aware of the problem. > > > This renders the app completely unusable, at least using Gnome, which > > > should justify a > > > severity of important. It's quite irrelevant if the app is a Gnome, Gt or > > > whatever app. > > > > It is actually quite relevant because it is up to the upstream developer > > which configurations > > they support and which not. There is an endless number of Linux > > distributions and desktop > > environments, so it's naturally impossible to support all of them. > > > Sure, but it's part of Debian's repository. And if it's supposed to stay that > way, something > needs to be fixed. And for all I know this app doesn't have an official Linux > version. The > website calls it a community version. So whoever feels responsible, the > person maintaining it > in the Debian repositories and keeping it there or the person that ported the > app (not even > sure if the official app uses Qt). But the current state needs to be resolved > at least by the > time Trixie hits stable. Sure, it wouldn't be the best solution to dropp the > app altogether, > but having the app only on paper for many users isn't one either. As I said in my previous mail, this is not a packaging issue but an issue with the upstream source code itself. I am not really in the position to fix this as I am not familiar with the code. > > > > > Sure, the newer version right now is only available in testing and sid > > > (tested both, same > > > result). > > > > Errm, you shouldn't be installing packages from unstable on a stable system > > [1]. > > > > Who says I am? I am running testing. Also, getting security updates from > unstable is actually > recommended behavior, so the stuff around "FrankenDebian" is contradicting > itself. There is no version 2.0.x in Debian stable nor stable-backports yet, so unless you built the package yourself from the unstable sources or installed the Flatpak version, you created a "FrankenDebian". And, no, the wiki page regarding "FrankenDebian" is not contradicting itself because security updates are provided through debian-security. These updates are built to target Debian stable, so it's perfectly fine to install them without risking to break anything. > > > But that just makes it more important that this is sorted out before this > > > package is made > > > available in stable or stable-backports. Especially since running it as > > > Flatpak would > > > probably render half the app unusable since the communication with the > > > browser would > > > probably not work. > > > > FWIW, I am merely packaging the software for Debian. I am not the upstream > > developer. If > > you have problems with the software itself which is not related to > > packaging, you should > > direct your bug reports upstream. > > > > Unfortunately though, upstream actually does not officially support Linux, > > so they don't > > really care if it breaks. Thus, if you are really so annoyed by the > > software not working > > on your particular system, I am happy to request a removal of the package > > from the Debian > > archive mirrors so that I don't have to bother with such entitled bug > > reports anymore. > > > > Entitled? Well that's rich. The point of the whole bug reporting system is > exactly what we > are doing here. So yes, if you are unwilling to maintain the package, which > will always > include getting bug reports if things don't behave as intended, then don't do > it. Not really. If someone steps up to maintain something, it doesn't automatically mean they are responsible for supporting all possible configurations that exist within Debian which is what you are asking for. The package works perfectly fine on KDE which is what I am using myself. The limitations around GNOME support are an upstream issue and not related to packaging which is what I am
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > I second this report. The app did use to work actually, but recently - not > sure with > transitioning to ausweisapp with v2.0 or later, this breaks for me too. What breaks? Please be more specific! > This renders the app completely unusable, at least using Gnome, which should > justify a > severity of important. It's quite irrelevant if the app is a Gnome, Gt or > whatever app. It is actually quite relevant because it is up to the upstream developer which configurations they support and which not. There is an endless number of Linux distributions and desktop environments, so it's naturally impossible to support all of them. > Like any app, if it's included in Debian it should not be broken beyond > usability. It's not broken beyond usability. It works for me perfectly fine. There is no guarantee you though that it will work in your particular configuration. And, as you can read from the license, Debian comes with absolutely no warranty whatsoever, so I am not sure what you are expecting. > Sure, the newer version right now is only available in testing and sid > (tested both, same > result). Errm, you shouldn't be installing packages from unstable on a stable system [1]. > But that just makes it more important that this is sorted out before this > package is made > available in stable or stable-backports. Especially since running it as > Flatpak would > probably render half the app unusable since the communication with the > browser would > probably not work. FWIW, I am merely packaging the software for Debian. I am not the upstream developer. If you have problems with the software itself which is not related to packaging, you should direct your bug reports upstream. Unfortunately though, upstream actually does not officially support Linux, so they don't really care if it breaks. Thus, if you are really so annoyed by the software not working on your particular system, I am happy to request a removal of the package from the Debian archive mirrors so that I don't have to bother with such entitled bug reports anymore. Thanks, Adrian > [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060822: choose-mirror: please add support for loong64
Hi Wuruilong, On Mon, 2024-01-15 at 02:21 +, wuruilong wrote: > Please modify Mirrors.masterlist to support loong64 architecture Please open a pull request here [1] to edit the master list. Make sure you cover all servers which already mirror loong64. Adrian > [1] https://salsa.debian.org/mirror-team/masterlist -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057717: cmake ftbfs on ppc64el (and ppc64)
Control: tags -1 +patch
On Fri, 2024-01-12 at 01:31 +0100, John Paul Adrian Glaubitz wrote:
> This has now been tracked down to the libuv upstream change that introduced
> support
> for io_uring [1]. This regression is tracked now in a new issue for libuv [2].
The attached patch disables io_uring on ppc64 and ppc64el for the time being
until
the upstream issue has been resolved.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From 3b6a1a14caeeeaf5510f2939a8e28ed9ba0ad968 Mon Sep 17 00:00:00 2001
From: Brad King
Date: Sat, 13 Jan 2024 06:04:01 -0500
Subject: [PATCH] linux: disable io_uring on ppc64 and ppc64le (#4285)
Since `io_uring` support was added, libuv's signal handler randomly
segfaults on ppc64 when interrupting `epoll_pwait`. Disable it
pending further investigation.
Issue: https://github.com/libuv/libuv/issues/4283
---
src/unix/linux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/unix/linux.c b/src/unix/linux.c
index 3c1313e7..4164e90d 100644
--- a/src/unix/linux.c
+++ b/src/unix/linux.c
@@ -463,6 +463,9 @@ static int uv__use_io_uring(void) {
#elif defined(__arm__) && __SIZEOF_POINTER__ == 4
/* See https://github.com/libuv/libuv/issues/4158. */
return 0; /* All 32 bits kernels appear buggy. */
+#elif defined(__powerpc64__) || defined(__ppc64__)
+ /* See https://github.com/libuv/libuv/issues/4283. */
+ return 0; /* Random SIGSEGV in signal handler. */
#else
/* Ternary: unknown=0, yes=1, no=-1 */
static _Atomic int use_io_uring;
--
2.43.0
Bug#1057717: cmake ftbfs on ppc64el (and ppc64)
Hello, On Thu, 2024-01-11 at 19:15 +0100, John Paul Adrian Glaubitz wrote: > This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said > he > would be looking into it. In case he comes up with a solution, I will report > it > here. This has now been tracked down to the libuv upstream change that introduced support for io_uring [1]. This regression is tracked now in a new issue for libuv [2]. Adrian > [1] > https://github.com/libuv/libuv/commit/d2c31f429b87b476a7f1344d145dad4752a406d4 > [2] https://github.com/libuv/libuv/issues/4283 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057717: cmake ftbfs on ppc64el (and ppc64)
Hi Jeff, On Thu, 2024-01-11 at 13:25 -0500, Jeffrey Walton wrote: > > > It may be a good idea to give the CMake folks the first chance at the > fix. It does not look like it has been reported to them: > <https://gitlab.kitware.com/cmake/cmake/-/issues>. Searching with > 'ppc' and 'llvm' tags returned 0 hits: > <https://gitlab.kitware.com/cmake/cmake/-/issues/?sort=created_date=all=ppc=llvm>. > (Maybe I missed it in their bug tracker). It was actually reported upstream and this bug report also forwards to the corresponding issue [1]. However, cmake upstream does not consider it a bug on their side which is why they closed the bug. Adrian > [1] https://gitlab.kitware.com/cmake/cmake/-/issues/25500 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057717: cmake ftbfs on ppc64el (and ppc64)
Hello, the bug is definitely still present and I'm therefore not sure whether downgrading the priority to normal is justified. On ppc64, cmake still crashes regularly when configuring the LLVM build for example [1]: -- Looking for pow in m - found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for backtrace in execinfo Segmentation fault I have performed a local LLVM test build and obtained a backtrace with gdb which also indicates a crash in libuv: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x in ?? () [Current thread is 1 (Thread 0x7fff811f6e60 (LWP 2635470))] (gdb) bt #0 0x in ?? () #1 #2 0x7fff82eee784 in __GI_epoll_pwait (epfd=4, events=0x7fffd3808cc8, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40 #3 0x7fff83545238 in uv__io_poll (loop=0x10015e8edd0, timeout=-1) at ./src/unix/linux.c:1365 #4 0x7fff8352aa84 in uv_run (loop=0x10015e8edd0, mode=UV_RUN_ONCE) at ./src/unix/core.c:447 #5 0x000132669d8c in cmExecuteProcessCommand (args=..., status=...) at ./Source/cmExecuteProcessCommand.cxx:358 #6 0x000132561d38 in InvokeBuiltinCommand (status=..., args=..., command=@0x133045248: 0x1326682b0 , std::allocator >, std::allocator, std::allocator > > > const&, cmExecutionStatus&)>) at ./Source/cmState.cxx:420 #7 operator() (status=..., args=..., __closure=) at ./Source/cmState.cxx:430 #8 std::__invoke_impl&, cmExecutionStatus&)>&, const std::vector >&, cmExecutionStatus&> (__f=...) at /usr/include/c++/13/bits/invoke.h:61 #9 std::__invoke_r&, cmExecutionStatus&)>&, const std::vector >&, cmExecutionStatus&> (__fn=...) at /usr/include/c++/13/bits/invoke.h:114 #10 std::_Function_handler >&, cmExecutionStatus&), cmState::AddBuiltinCommand(const std::string&, BuiltinCommand):: >&, cmExecutionStatus&)> >::_M_invoke(const std::_Any_data &, const std::vector > &, cmExecutionStatus &) (__functor=..., __args#0=..., __args#1=...) at /usr/include/c++/13/bits/std_function.h:290 This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said he would be looking into it. In case he comes up with a solution, I will report it here. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17=ppc64=1%3A17.0.6-4%2Bb2=1704985815=0 > [2] https://bugzilla.suse.com/show_bug.cgi?id=1218365 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059991: grub-installer: build loong64.udeb for loongarch64
Hi Dandan! On Thu, 2024-01-04 at 20:55 +0800, zhangdandan wrote: > The grub-installer source package was compiled successfully on my local > environment. > I integrated grub-installer_1.197_loong64.udeb in my local DVD iso. When > installing the DVD iso through debian-installer, grub2 software packages > can be installed normally. I don't think this is true since the grub2 source is actually not building any loong64 packages yet. We will need to change the grub2 source first to build at packages such as grub-efi-loong64 and so on similar to riscv64 [1]. After that, loong64 can be added to grub-installer as it was be done for riscv64 [2] (except for the case for "riscv64/*)"). Adrian > [1] > https://salsa.debian.org/grub-team/grub/-/commit/bed7e96f581c983e9bea6701bb6780ece9e91d82 > [2] > https://salsa.debian.org/installer-team/grub-installer/-/commit/50c372d0b4fa2025f17d7d87a6eb5656baba0724 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051931: fixed in obs-studio 30.0.2+dfsg-2
Control: reopen -1 >* Add Unconditional B-D on luajit > (dropping support for ppc64el) > (Closes: #1051931) That doesn't really fix the original bug report as suggested. My suggestion was to disable lua scripting on architectures where libluajit-5.1-dev is not (yet available.) Can you implement the fix as proposed in the original report? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060196: ghc: Please build unregisterised compiler with --param ggc-min-expand=10 -O3 on powerpc
Source: ghc Version: 9.4.7-2 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! Due to the current regression in the native code generator for PowerPC on 32-bit targets [1], GHC can only be built as an unregisterised compiler on the target. Thus, please configure GHC with --enable-unregisterised on powerpc. Also, since building an unregisterised GHC generates very large intermediate C sources, we additionally have to pass both "--param ggc-min-expand=10" and "-O3" to reduce the memory footprint and the size of the generated assembly code respectively [2]. Thus, please pass -optc--param -optcggc-min-expand=10 and -optc-O3 to the GHC build flags. With these changes, GHC should build successfully on powerpc. Thanks, Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23969 > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059991: grub-installer: build loong64.udeb for loongarch64
Hi Dandan! On Thu, 2024-01-04 at 20:55 +0800, zhangdandan wrote: > We need to add build support for loongarch64 in debian/control. > Please consider the patch I have attached. > > The grub-installer source package was compiled successfully on my local > environment. > I integrated grub-installer_1.197_loong64.udeb in my local DVD iso. When > installing the DVD iso through debian-installer, grub2 software packages > can be installed normally. > If you have any questions, you can contact me at any time. I have commit access and will take care of this over the weekend. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059870: aboot: Please help testing dropping a.out.h support
On Tue, 2024-01-02 at 18:07 +, Dimitri John Ledkov wrote: > For cross building, as far as I can tell one needs to build the tool > twice - once for the BUILD architecture and once for HOST > architecture, use one during the build and package the other one into > the deb. That's correct and I am currently pondering over a clever way to do that. > > I will most likely just copy the relevant definitions out of aout.h, both > > the generic and the alpha-specific stuff in order to both be able to drop > > reliance on aout.h in the kernel as well as make the package fully cross- > > buildable. > > But why? as far as I can tell, the a.out code path is never executed > as it seems like Debian has been using ELF based vmlinuz since like > before 2009. Are you sure that the a.out codepath of objstrip.c is > needed or executed at all? > > Or am I missing something, and like objstrip.c portions are executed > against some other a.out formatted things which are not Linux kernel? > > Should I provide a patch that adds printfs during a.out codepath > block, to see if it actually is ever executed? I think it's still reasonable to keep a.out support in the tool because users might use it for a.out binaries generated from other tools. Besides, it's just a matter of copying a few header definitions, so not really a blocker unless I am missing something. > > > > I would also prefer to get all relevant changes upstreamed. > > > > Upstream has policy of not carrying dead code, which in this case its > what it is for kernels built in like last decade. I was talking about aboot upstream which is maintained by Matt Turner from Gentoo these days [1]. Adrian > [1] https://github.com/mattst88/aboot/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059870: aboot: Please help testing dropping a.out.h support
Hi Dimitri! On Tue, 2024-01-02 at 17:37 +, Dimitri John Ledkov wrote: > a.out support has been dropped in upstream kernel. However a.out.h > header is still being using by abootimg tool via objstrip.c. It has > support for both a.out image types and ELF. I have blidly dropped > a.out.h support and made ELF support mandatory in > https://lore.kernel.org/all/20231123180246.750674-2-dimitri.led...@canonical.com/ > but I have no way to build it for alpha or test if everything still > works. Upgrades, installed systems, and cd-boot. > > Could you please consider the attached NMU, build it and test it, and > let me know if everything still works. Cause then a.out.h header can > be removed from upstream linux kernel on all architectures. I have actually already looked into patching aboot myself to deal with the aout.h issue since I want to make the bootloader fully cross-buildable [1]. I will most likely just copy the relevant definitions out of aout.h, both the generic and the alpha-specific stuff in order to both be able to drop reliance on aout.h in the kernel as well as make the package fully cross- buildable. I would also prefer to get all relevant changes upstreamed. Thanks, Adrian > [1] https://github.com/mattst88/aboot/issues/5 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059703: binutils: Please drop nocheck override for powerpc and sparc64
Source: binutils Version: 2.41.50.20231227-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! The debian/rules file for binutils currently overrides the nocheck build option with the following code snippet: ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) # override buildd admins to run the testsuite anyway ... ifeq (,$(filter $(DEB_HOST_ARCH), m68k powerpc sh4 sparc64)) with_check := disabled through DEB_BUILD_OPTIONS endif endif Since both the powerpc and sparc64 buildds don't build with "nocheck" there is no need to override it. It only annoys porters when they want to build binutils locally with the testsuite disabled. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059676: kernel FTBFS on hppa
Hello! > The best solution is probably to fix binutils for hppa to cope > with 32- and 64-bit hppa binaries. For that I opened ticket #1059674 On powerpc for example, binutils is configured with: --enable-targets=powerpc64-linux-gnu Thus, we should just do this on hppa as well and close this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed
Hello Simon! On Fri, 2023-12-15 at 11:35 +, Simon McVittie wrote: > gtk4 had a recent test failure regression on s390x and other big-endian > architectures like ppc64 (#1057782). I sent this upstream to > https://gitlab.gnome.org/GNOME/gtk/-/issues/6260 and proposed a patch in > https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6653, but upstream is > reluctant to apply the patch because they think it is the wrong solution: > > > I would rather people fix the actual issue, which is the large table > > mapping GdkMemoryFormat to the corresponding GL format (and I bet the > > one for dmabufs is broken, too, but we don't have tests for that). Is there someone working on that? > librsvg also has long-standing unsolved endianness-related issues, most > likely in one of its dependencies (#1038447, which has affected bookworm > since September 2022). The fact that librsvg isn't fixing these issues is surprising to me. Back when the library was converted to Rust, I was raising concerns that this will reduce portability which was dismissed by the main author as unjustified. > The GNOME team does not have big-endian hardware where we can run manual > tests, so we do not know how much of an impact this has on practical > usability of GTK and librsvg on big-endian architectures: it's entirely > possible that they have always been misrendered or broken on big-endian, > but the bug was never reported because there were no users, and we > are only noticing this now as a result of wider test coverage being > introduced. There are both QEMU-based solutions available as well as big-endian machines in the GCC Compiler Farm [1]. There is also the OpenPOWER Openstack platform which has both little- and big-endian targets available [2]. So, I don't think the argument there is no way to test on big-endian targets is justified. > If porters are interested in having GTK and librsvg continue to be > available on big-endian, please work with upstream to get them to a point > where endianness-specific bugs can be taken seriously in the upstream > projects. I do not consider doing this downstream-only to be a solution. Looking at both Fedora [3] and openSUSE [4], tests aren't executed on s390x for these distributions either. > If endianness-specific issues become a blocker for the Debian release > process at some point in the future, then it is likely that I will have > to start the process of doing architecture-specific removals for these > packages and their reverse dependencies. For s390x this is likely to > have little user-visible effect, because I find it unlikely that there > are genuinely users running GUI applications on IBM mainframes, but for > -ports architectures this will probably be a larger regression. Well, removing librsvg will certainly disable quite large number of packages on s390x. Maybe someone should CC an engineer from IBM on the bug report and ask for help to fix the testsuite issues. Adrian > [1] https://portal.cfarm.net/machines/list/ > [2] https://osuosl.org/services/powerdev/request_hosting/ > [3] > https://src.fedoraproject.org/rpms/librsvg2/blob/rawhide/f/librsvg2.spec#_153 > [4] > https://build.opensuse.org/package/view_file/GNOME:Next/librsvg/librsvg.spec?expand=1 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64
Hi Ilias! On Thu, 2023-11-16 at 20:23 +0200, Ilias Tsitsimpis wrote: > Thanks for working on this. I fear that applying this patch will change > the ABI for Cabal, and hence we will have to rebuild every Haskell > package in Debian. Because of that, I plan on waiting for the current > transition to finish, and then include this patch in the next GHC > upload. Are you sure that this actually the case [1]? Adrian > [1] https://github.com/haskell/cabal/pull/9445#issuecomment-1811780089 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hi Christian! On Thu, 2023-12-07 at 08:09 +0100, Christian Marillat wrote: > > It's always safe to apply this patch. > > It is possible to see this bug fixed ? I have uploaded a patched version to unreleased for the time being. However, fixing this should be a no-brainer and wouldn't affect anything else. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057624: ausweisapp2: new upstream version (and name)
Hello Christoph! On Wed, 2023-12-06 at 04:04 +0100, Christoph Anton Mitterer wrote: > A new upstream major version (2.x) is out, and they've apparently also > rebranded it back to just "AusweisApp" (i.e. no longer a 2 in the name). I am naturally aware of the new release because I am in direct contact with one of the upstream maintainers. The withheld update to 2.x is intentional for two reasons. First, the new version introduces a completely new user interface with features removed such as the integrated list of service providers. The user interface basically now looks like a scaled up phone app on the desktop which I consider a huge step back. And, secondly, the change of name of the binary package will result in the package being stuck in NEW for a while which is why I backported the two fixes for Qt 6.6 compatibility first to make sure the app doesn't break once Qt 6.6 is uploaded to unstable (it's currently in experimental). Overall, there is no urgent need to update to version 2.x right now, so I rather want to take my time to come up with a proper transition plan with the potential prospect of a better user interface. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057390: openjdk-21: Please add patch to support SPARCV9
Source: openjdk-21
Version: 21.0.1+12-2
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hello!
The attached patch adds SPARCV9 support to OpenJDK. It has been successfully
tested against OpenJDK 21 on stadler.debian.net. I will use this patch now
to build openjdk-21 and upload to unreleased.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index:
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/Architecture.java
===
---
openjdk-21-21.0.1+12.orig/src/java.base/share/classes/jdk/internal/util/Architecture.java
+++
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/Architecture.java
@@ -50,6 +50,7 @@ public enum Architecture {
IA64,
M68K,
SH,
+SPARCV9,
X32,
PPC,
MIPSEL,
@@ -171,6 +172,15 @@ public enum Architecture {
}
/**
+ * {@return {@code true} if the current architecture is SPARCV9}
+ * Use {@link #isLittleEndian()} to determine big or little endian.
+ */
+@ForceInline
+public static boolean isSPARCV9() {
+return PlatformProps.TARGET_ARCH_IS_SPARCV9;
+}
+
+/**
* {@return {@code true} if the current architecture is M68K}
* Use {@link #isLittleEndian()} to determine big or little endian.
*/
Index: openjdk-21-21.0.1+12/test/jdk/jdk/internal/util/ArchTest.java
===
--- openjdk-21-21.0.1+12.orig/test/jdk/jdk/internal/util/ArchTest.java
+++ openjdk-21-21.0.1+12/test/jdk/jdk/internal/util/ArchTest.java
@@ -41,6 +41,7 @@ import static jdk.internal.util.Architec
import static jdk.internal.util.Architecture.IA64;
import static jdk.internal.util.Architecture.PPC;
import static jdk.internal.util.Architecture.SH;
+import static jdk.internal.util.Architecture.SPARCV9;
import static jdk.internal.util.Architecture.X32;
import static jdk.internal.util.Architecture.M68K;
import static jdk.internal.util.Architecture.MIPSEL;
@@ -93,6 +94,7 @@ public class ArchTest {
case "m68k" -> M68K;
case "ppc" -> PPC;
case "sh" -> SH;
+case "sparcv9" -> SPARCV9;
case "x32" -> X32;
default -> OTHER;
};
@@ -121,6 +123,7 @@ public class ArchTest {
Arguments.of(HPPA, Architecture.isHPPA()),
Arguments.of(IA64, Architecture.isIA64()),
Arguments.of(SH, Architecture.isSH()),
+Arguments.of(SPARCV9, Architecture.isSPARCV9()),
Arguments.of(X32, Architecture.isX32()),
Arguments.of(PPC64, Architecture.isPPC64())
);
Index:
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
===
---
openjdk-21-21.0.1+12.orig/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
+++
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
@@ -64,6 +64,7 @@ class PlatformProps {
static final boolean TARGET_ARCH_IS_MIPS64EL= "@@OPENJDK_TARGET_CPU@@" ==
"mips64el";
static final boolean TARGET_ARCH_IS_X32 = "@@OPENJDK_TARGET_CPU@@" ==
"x32";
static final boolean TARGET_ARCH_IS_SH = "@@OPENJDK_TARGET_CPU@@" ==
"sh";
+static final boolean TARGET_ARCH_IS_SPARCV9 = "@@OPENJDK_TARGET_CPU@@" ==
"sparcv9";
static final boolean TARGET_ARCH_IS_M68K= "@@OPENJDK_TARGET_CPU@@" ==
"m68k";
static final boolean TARGET_ARCH_IS_PPC = "@@OPENJDK_TARGET_CPU@@" ==
"ppc";
static final boolean TARGET_ARCH_IS_ALPHA = "@@OPENJDK_TARGET_CPU@@" ==
"alpha";
Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures
Hi! > Guillem curated a list in /usr/share/perl5/Dpkg/Vendor/Debian.pm: > > * arm > * armeb > * armel > * armhf > * hppa > * i386 > * hurd-i386 > * kfreebsd-i386 > * m68k > * mips > * mipsel > * mipsn32 > * mipsn32el > * mipsn32r6 > * mipsn32r6el > * mipsr6 > * mipsr6el > * nios2 > * powerpc > * powerpcel > * powerpcspe > * s390 > * sh3 > * sh3eb > * sh4 > * sh4eb > * sparc > > This looks more complete, but it misses arm64ilp32. > > Maybe instead of duplicating this, debhelper can access it? I agree with Helmut's suggestion. debhelper should be able to deal with 32-bit architectures that already support 64-bit time_t. If we ignore these, we could run into issues with potential new 32-bit ports such as ARC. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hi! On Sat, 2023-12-02 at 00:46 +0100, Patrick Franz wrote: > We're in the middle of packaging Qt 6.6 and I had not planned to do any > more 6.4.2 updates unless absolutely necessary. > > Do you know whether this patch will also work on Qt 6.6.1 ? Yes, absolutely. And since it only adds some powerpc-specific lines to debian/rules, there is nothing really that would need to be rebased when updating to a newer Qt version. It's always safe to apply this patch. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051757: libunwind8 doesn't support loongarch64
Hi! Since upstream supports LoongArch since version 1.7.0, it's enough to update src:libunwind in unstable to version 1.7.0 or higher. Please note that the dpkg version on DAK already support loong64, so introducing the architecture in debian/control won't result in the package being rejected. See also #1054285 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054285 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057091: perl: FTBFS on sparc64 due to alignment issues
Source: perl Version: 5.36.0-10 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! src:perl currently fails to build from source on sparc64 due to an alignment issue which results in two testsuite failures: Failed 2 tests out of 2623, 99.92% okay. re/reg_mesg.t re/regex_sets.t This alignment issue has already been fixed upstream [1] and has also been backported to Perl 5.36.1. Thus, in order to fix this bug, it's enough to update the perl package to 5.36.1 or newer. Thanks, Adrian > [1] > https://github.com/Perl/perl5/commit/89d80cc9efb3eefc31aa62b32c9e745f8de6412f -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Source: qt6-multimedia Version: 6.4.2-11 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! The package src:qt6-multimedia fails to build from source on powerpc since version 6.4.0-1 due to the use of some AltiVec instrisics that are not supported on 32-bit PowerPC: /usr/bin/c++ -DEIGEN_MPL2_ONLY -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS -DQT_NO_JAVA_STYLE_ITERATORS \ (...) In file included from /usr/include/eigen3/Eigen/Core:210, from /usr/include/eigen3/Eigen/Dense:1, from /<>/src/resonance-audio/../3rdparty/resonance-audio/platforms/common/utils.h:20, from /<>/src/3rdparty/resonance-audio/platforms/common/utils.cc:17: /usr/include/eigen3/Eigen/src/Core/arch/AltiVec/PacketMath.h: In function \ ‘Packet Eigen::internal::pblend(const Selector::size>&, const Packet&, const Packet&) [with Packet = __vector(2) double]’: /usr/include/eigen3/Eigen/src/Core/arch/AltiVec/PacketMath.h:2702:17: error: invalid parameter combination for AltiVec intrinsic ‘__builtin_vec_sel’ 2702 | return vec_sel(elsePacket, thenPacket, mask); | ^ This can be fixed by switching off vectorization in the »eigen« using the preprocessor macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line using the cmake variable COMPILE_DEFINITIONS: --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 17:52:13.0 +0200 +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 @@ -9,6 +9,10 @@ cmake_extra_args += -DQT_HOST_PATH=/usr endif +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" +endif + %: dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja With the above change, cmake defines the preprocessor macro EIGEN_DONT_VECTORIZE and the build succeeds on powerpc. Could you apply this change for the next upload in order to fix the build on powerpc? Attaching a patch for a convenience. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 17:52:13.0 +0200 +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 @@ -9,6 +9,10 @@ cmake_extra_args += -DQT_HOST_PATH=/usr endif +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" +endif + %: dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja
Bug#985465: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Control: retitle -1 'FTBFS on multiple architectures due to incorrect LD_LIBRARY_PATH' Control: tags -1 +patch Hi! On Tue, 2023-11-28 at 10:13 +0100, John Paul Adrian Glaubitz wrote: > --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 > +0200 > +++ qscintilla2-2.14.1+dfsg/debian/rules2023-11-28 10:12:29.317757619 > +0100 > @@ -46,7 +46,7 @@ > Python/build-%/configure-stamp: build-library-stamp > dh_testdir > cp -f Python/pyproject-qt5.toml Python/pyproject.toml > - cd Python && python$* /usr/bin/sip-build \ > + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* > /usr/bin/sip-build \ > --verbose --no-make --pep484-pyi \ > --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ > --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' > \ > @@ -59,7 +59,7 @@ > --qsci-library-dir $(CURDIR)/QSciQt5 > ifeq ($(qt6), "yes") > cp -f Python/pyproject-qt6.toml Python/pyproject.toml > - cd Python && python$* /usr/bin/sip-build \ > + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* > /usr/bin/sip-build \ > --verbose --no-make --pep484-pyi \ > --qmake /usr/bin/qmake6 \ > --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' > \ I can confirm that this patch fixes the problem for me. Attaching it as a file. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 +0200 +++ qscintilla2-2.14.1+dfsg/debian/rules 2023-11-28 10:12:29.317757619 +0100 @@ -46,7 +46,7 @@ Python/build-%/configure-stamp: build-library-stamp dh_testdir cp -f Python/pyproject-qt5.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ @@ -59,7 +59,7 @@ --qsci-library-dir $(CURDIR)/QSciQt5 ifeq ($(qt6), "yes") cp -f Python/pyproject-qt6.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/qmake6 \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \
Bug#985465: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Hi! Testing the following patch now which seems to work: --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 +0200 +++ qscintilla2-2.14.1+dfsg/debian/rules2023-11-28 10:12:29.317757619 +0100 @@ -46,7 +46,7 @@ Python/build-%/configure-stamp: build-library-stamp dh_testdir cp -f Python/pyproject-qt5.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ @@ -59,7 +59,7 @@ --qsci-library-dir $(CURDIR)/QSciQt5 ifeq ($(qt6), "yes") cp -f Python/pyproject-qt6.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/qmake6 \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#985465: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Hi David! The issue exists on sparc64 as well [1] and I'm not quite sure why it does not seem to affect the release architectures: make[2]: Entering directory '/<>/Python/build-3.11/cfgtest_Qsci' sparc64-linux-gnu-g++ -c -pipe -g -O2 -ffile-prefix-map=/<>=. \ -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time \ -D_FORTIFY_SOURCE=2 -O2 -Wall -Wextra -D_REENTRANT -fPIC -DQSCINTILLA_DLL \ -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB \ -I. -I../../../QSciQt5 -I/usr/include/sparc64-linux-gnu/qt5 \ -I/usr/include/sparc64-linux-gnu/qt5/QtPrintSupport -I/usr/include/sparc64-linux-gnu/qt5/QtWidgets \ -I/usr/include/sparc64-linux-gnu/qt5/QtGui -I/usr/include/sparc64-linux-gnu/qt5/QtCore -I. \ -I/usr/lib/sparc64-linux-gnu/qt5/mkspecs/linux-g++ -o cfgtest_Qsci.o ../../config-tests/cfgtest_Qsci.cpp sparc64-linux-gnu-g++ -Wl,-z,relro -Wl,-O1 -o Qsci cfgtest_Qsci.o \ -L../../../QSciQt5 -L/usr/lib/sparc64-linux-gnu -lqscintilla2_qt5 /usr/lib/sparc64-linux-gnu/libQt5PrintSupport.so \ /usr/lib/sparc64-linux-gnu/libQt5Widgets.so /usr/lib/sparc64-linux-gnu/libQt5Gui.so \ /usr/lib/sparc64-linux-gnu/libQt5Core.so -lGL -lpthread make[2]: Leaving directory '/<>/Python/build-3.11/cfgtest_Qsci' /<>/Python/build-3.11/cfgtest_Qsci/./Qsci /<>/Python/build-3.11/cfgtest_Qsci/cfgtest_Qsci.out sip-build: '/<>/Python/build-3.11/cfgtest_Qsci/./Qsci' didn't create any output /<>/Python/build-3.11/cfgtest_Qsci/./Qsci: error while loading shared libraries: libqscintilla2_qt5.so.15: \ cannot open shared object file: No such file or directory Might be a race condition. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qscintilla2=sparc64=2.14.1%2Bdfsg-1=1701131767=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056742: ghc: Please pass number of parallel jobs from DEB_BUILD_OPTIONS to hadrian
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch Hi! When src:ghc was switched from GNU Make to Hadrian, the build system lost the ability to pass the parallel jobs provided in DEB_BUILD_OPTIONS to the build process. Luckily, Hadrian knows how to deal with parallel jobs using the -j option, so we can just extract the number of parallel jobs from DEB_BUILD_OPTIONS which is what the attached patch does: --- ghc-9.4.7/debian/rules.orig 2023-10-18 21:49:38.0 +0200 +++ ghc-9.4.7/debian/rules 2023-11-25 19:59:40.401680294 +0100 @@ -95,6 +95,10 @@ EXTRA_HADRIAN_FLAGS += "*.*.rts.*.opts += -O0" endif +ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +endif + # Use system libffi EXTRA_CONFIGURE_FLAGS += --with-system-libffi @@ -152,7 +156,7 @@ $(error cross-compilation is not supported) endif hadrian/hadrian \ - -V -j \ + -V -j$(NUMJOBS) \ --docs=no-haddocks --docs=no-sphinx-html --docs=no-sphinx-pdfs \ binary-dist-dir \ $(EXTRA_HADRIAN_FLAGS) @@ -175,7 +179,7 @@ $(error override_dh_auto_build-indep is not supported when cross compiling) endif hadrian/hadrian \ - -V -j \ + -V -j$(NUMJOBS) \ --docs=no-sphinx-pdfs \ binary-dist-dir \ $(EXTRA_HADRIAN_FLAGS) I adapted the above snippet from the debian/rules file for src:cmake [1] in case you want to credit the original authors. Thanks, Adrian > [1] https://salsa.debian.org/cmake-team/cmake/-/blob/master/debian/rules#L54 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- ghc-9.4.7/debian/rules.orig 2023-10-18 21:49:38.0 +0200 +++ ghc-9.4.7/debian/rules 2023-11-25 19:59:40.401680294 +0100 @@ -95,6 +95,10 @@ EXTRA_HADRIAN_FLAGS += "*.*.rts.*.opts += -O0" endif +ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) +endif + # Use system libffi EXTRA_CONFIGURE_FLAGS += --with-system-libffi @@ -152,7 +156,7 @@ $(error cross-compilation is not supported) endif hadrian/hadrian \ - -V -j \ + -V -j$(NUMJOBS) \ --docs=no-haddocks --docs=no-sphinx-html --docs=no-sphinx-pdfs \ binary-dist-dir \ $(EXTRA_HADRIAN_FLAGS) @@ -175,7 +179,7 @@ $(error override_dh_auto_build-indep is not supported when cross compiling) endif hadrian/hadrian \ - -V -j \ + -V -j$(NUMJOBS) \ --docs=no-sphinx-pdfs \ binary-dist-dir \ $(EXTRA_HADRIAN_FLAGS)
Bug#1056636: ghc: Please restore --disable-ld-override after build system switch
Hi! On Fri, 2023-11-24 at 09:34 +0100, John Paul Adrian Glaubitz wrote: > After the build system was switched from GNU Make to Hadrian, the configure > option --disable-ld-override was lost in the process but is still required > for previously affected architectures powerpc, powerpcspe and sparc64. I just realized that we're still calling the configure script. Thus, just removing the comment signs (#) in front of the section for disabling the linker override should fix the problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056636: ghc: Please restore --disable-ld-override after build system switch
Source: ghc Version: 9.4.7-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! After the build system was switched from GNU Make to Hadrian, the configure option --disable-ld-override was lost in the process but is still required for previously affected architectures powerpc, powerpcspe and sparc64. This became evident after building GHC on sparc64 and ld.gold segfaulted in the final stage when linking more than 600 object files which does not seem to be 100% on sparc64 (and 32-bit PowerPC). I will file a separate upstream bug report for binutils regarding that issue. I have not figured out yet what the proper option would be but looking at [1], it would be something like *.*.ghc.link.opts+=bla. I have already asked on the #ghc IRC channel for advise and will report back once I know more. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056570: openjdk-8: Please drop sparc64 from hotspot_archs for the time being
Source: openjdk-8 Version: 8u392-ga-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello! The native code generator in openjdk-8 currently segfaults on sparc64 and prevents a successful build. Removing sparc64 from "hotspot_archs" in debian/rules restricts the build to Zero builds which fixes the build. Thus, please disable the native build on sparc64 for the time being until we have sorted out the regression. FWIW, I assume there was some change in the Hotspot code on sparc64 that was most likely implemented for the Solaris port only since the native Linux sparc64 port has been unmaintained in OpenJDK for quite some time. This has happened in the past before. I will try to bisect the problem later and report it upstream. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat
Control: reassign -1 src:linux Control: retitle -1 "linux: Please enable CONFIG_LPARCFG for ppc64 and ppc64el" Hello Thomas! On Wed, 2023-11-22 at 13:02 +0100, peponas wrote: > lparstat report "Could not open /proc/ppc64/lparcfg" exemple : > lparstat 1 1 > Could not open /proc/ppc64/lparcfg > > System Configuration > type=Dedicated mode=Uncapped smt=8 lcpu=- mem=16653440 kB cpus=0 ent=0.00 > > %user %sys %wait%idlephysc %entc lbusy app vcsw phint > - - --- - - - - - > Could not open /proc/ppc64/lparcfg > 0.12 0.12 0.0099.75 0.00 nan 0.25 0.00 - 350 > > kernel with config LPARCFG=Y resolv problem. Since this is obviously something that needs to be changed in the kernel configuration, the bug should be reported against src:linux and not against the powerpc-utils package. Thanks, Adrian -- .''`. 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.
On Tue, 2023-11-21 at 15:12 +0100, Miguel A. Vallejo wrote: > What a plot twist! :-) > > Do you think there is any possibility to have fs-uae-launcher back in > Debian anytime soon? If someone bothers fixing those copyright issues, yes. > Configuring FS-UAE by hand is tedious. we really need fs-uae-launcher > back in Debian So is fixing the copyright issues. It's a lot of work and it seems no one can be bothered to do that. Adrian -- .''`. 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.
On Mon, 2023-11-20 at 22:13 +0100, Miguel A. Vallejo wrote: > I revisited https://github.com/FrodeSolheim/fs-uae-launcher/issues/143 > and I noticed user glaubitz is open to make the changes needed to have > this package back in Debian. > > Dear maintainer, please explain to GitHub / glaubitz what is needed to > have fs-uae-launcher back in Debian. That user "glaubitz" is me ;-). Someone actually sent me a mail in private and offered to help sorting out with the packaging issues but I haven't heard back from him. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch upstream User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! As discussed in private, here is a patch which fixes the arch detection for sparc64 in cabal. Previously, cabal treated "sparc64" as an alias for 32-bit sparc which results in the GHC build process not being able to find the built binaries as these are stored in a $ARCH-$OS subfolder. The patch has already been pushed upstream, approved and should be merged within the next hours after some more waiting [1]. The attached patch is a backported version of the patch which applies to GHC 9.4.7. Thanks, Adrian > [1] https://github.com/haskell/cabal/pull/9445 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- ghc-9.4.6.orig/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs +++ ghc-9.4.6/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs @@ -158,19 +158,17 @@ buildOS = classifyOS Permissive System.I -- -- | These are the known Arches: I386, X86_64, PPC, PPC64, Sparc, --- Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, Rs6000, --- M68k, Vax, JavaScript and Wasm32. --- +-- Sparc64, Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, +-- Rs6000, M68k, Vax, JavaScript and Wasm32. -- The following aliases can also be used: --* PPC alias: powerpc --* PPC64 alias : powerpc64, powerpc64le ---* Sparc aliases: sparc64, sun4 --* Mips aliases: mipsel, mipseb --* Arm aliases: armeb, armel --* AArch64 aliases: arm64 -- data Arch = I386 | X86_64 | PPC | PPC64 | Sparc - | Arm | AArch64 | Mips | SH + | Sparc64 | Arm | AArch64 | Mips | SH | IA64 | S390| S390X | Alpha | Hppa| Rs6000 | M68k | Vax @@ -185,7 +183,7 @@ instance NFData Arch where rnf = generic knownArches :: [Arch] knownArches = [I386, X86_64, PPC, PPC64, Sparc - ,Arm, AArch64, Mips, SH + ,Sparc64 ,Arm, AArch64, Mips, SH ,IA64, S390, S390X ,Alpha, Hppa, Rs6000 ,M68k, Vax @@ -197,7 +195,6 @@ archAliases Strict _ = [] archAliases Compat _ = [] archAliases _ PPC = ["powerpc"] archAliases _ PPC64 = ["powerpc64", "powerpc64le"] -archAliases _ Sparc = ["sparc64", "sun4"] archAliases _ Mips= ["mipsel", "mipseb"] archAliases _ Arm = ["armeb", "armel"] archAliases _ AArch64 = ["arm64"] --- ghc-9.4.6.orig/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs +++ ghc-9.4.6/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs @@ -717,6 +717,7 @@ platformDefines lbi = PPC -> ["powerpc"] PPC64 -> ["powerpc64"] Sparc -> ["sparc"] + Sparc64 -> ["sparc64"] Arm -> ["arm"] AArch64 -> ["aarch64"] Mips-> ["mips"]
Bug#1055884: ghc: Please update sparc-support patch to fix FTBFS on sparc64
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! src:ghc currently FTBFS on sparc64 since libraries/ghc-boot/GHC/Platform/ArchOS.hs is missing the architecture names for sparc and sparc64 [1]. I have therefore updated the sparc-support patch to address this and also opened a pull request upstream [2]. Can you update the patch for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ghc=sparc64=9.4.7-1=1699776000=0 > [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11599 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: ghc-9.4.7/m4/ghc_convert_cpu.m4 === --- ghc-9.4.7.orig/m4/ghc_convert_cpu.m4 +++ ghc-9.4.7/m4/ghc_convert_cpu.m4 @@ -68,6 +68,12 @@ case "$1" in sh4) $2="sh4" ;; + sparc64*) +$2="sparc64" +;; + sparc*) +$2="sparc" +;; vax) $2="vax" ;; Index: ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 === --- ghc-9.4.7.orig/m4/fptools_set_haskell_platform_vars.m4 +++ ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 @@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V riscv64) test -z "[$]2" || eval "[$]2=ArchRISCV64" ;; -hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax) +hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax) test -z "[$]2" || eval "[$]2=ArchUnknown" ;; *) Index: ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs === --- ghc-9.4.7.orig/libraries/ghc-boot/GHC/Platform/ArchOS.hs +++ ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs @@ -38,6 +38,8 @@ data Arch | ArchPPC | ArchPPC_64 PPC_64ABI | ArchS390X + | ArchSPARC + | ArchSPARC64 | ArchARM ArmISA [ArmISAExt] ArmABI | ArchAArch64 | ArchAlpha @@ -124,6 +126,8 @@ stringEncodeArch = \case ArchPPC_64 ELF_V1 -> "powerpc64" ArchPPC_64 ELF_V2 -> "powerpc64le" ArchS390X -> "s390x" + ArchSPARC -> "sparc" + ArchSPARC64 -> "sparc64" ArchARM ARMv5 _ _ -> "armv5" ArchARM ARMv6 _ _ -> "armv6" ArchARM ARMv7 _ _ -> "armv7"
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#1054463: kodi: FTBFS: add support for loongarch64
Hi! On Tue, 2023-10-24 at 08:21 +, Vasyl Gello wrote: > One question: is there a perspective for anything TV-related poweted by > loongarch64? It's a brand-new CPU architecture with a potentially large userbase across Asia, especially China. So, I think it's reasonable to expect there to be some users of Kodi on loongarch64. > If one can build a TV box on this platform, we should mention that because > some Kodi teammates > argued to me in the past that I should not bloat the platform code with > platforms no user would > run Kodi on. To minimize this friction, lets mention TV boxes are possible > with that CPU :) That's not really a convincing argument. Kodi has build support for various POWER targets and even IBM zSeries. I don't think we will ever see a TV box with a mainframe CPU in it, will we? FWIW, I think the changes required are so minimal that "bloat" is not really an argument here. It's an excuse. And, while we're at it, we should also add support for mips64el. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054463: kodi: FTBFS: add support for loongarch64
Hello, On Tue, 2023-10-24 at 14:33 +0800, zhangdandan wrote: > I have added loongarch64 support in the SystemInfo.cpp file. > Please consider the patch I have attached. > Would it be possible to include the support for LoongArch in the next > upload? Did you forward this patch upstream already? The patch should always be sent upstream first, so that we can keep the number of patches in Debian to a minimum. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054272: gcc-13: Regression in SH backend results in binutils FTBFS
Source: gcc-13 Version: 13.2.0-5 Severity: normal Tags: upstream User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello! There is currently a known regression in gcc-13 which causes binutils and e2fsprogs to FTBFS on sh4 [1][2]: libtool: compile: sh4-linux-gnu-gcc (...) .deps/elf64-aarch64.Tpo -c elf64-aarch64.c -fPIC -DPIC -o .libs/elf64-aarch64.o elfnn-aarch64.c: In function ‘elf64_aarch64_merge_gnu_properties’: elfnn-aarch64.c:10408: warning: ‘/<>/builddir-multi/bfd/.libs/elf64-aarch64.gcda’ profile count data file not found [-Wmissing-profile] terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Unhandled trap: 0x180 pc=0x3f9a38e0 sr=0x0001 pr=0x3f9a38d2 fpscr=0x00080004 spc=0x ssr=0x gbr=0x3f975aa0 vbr=0x sgr=0x dbr=0x delayed_pc=0x3f9a38d2 fpul=0x0064 r0=0x0004 r1=0x3fb01170 r2=0x0005 r3=0x r4=0x002e5a00 r5=0x002e5a00 r6=0x0006 r7=0x011c r8=0x3fb01164 r9=0x0518 r10=0x3f9755e0 r11=0x09bc r12=0x3fb00c58 r13=0x01766344 r14=0x01bed424 r15=0x407fb580 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x Testing on real hardware reveals the actual bug: root@tirpitz:..lib/ext2fs> gcc-13 -I. -I../../lib -I../../../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=$(pwd)=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -pthread -DHAVE_CONFIG_H -c ../../../../lib/ext2fs/rw_bitmaps.c -o rw_bitmaps.o terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc during RTL pass: sh_treg_combine2 ../../../../lib/ext2fs/rw_bitmaps.c: In function ‘read_bitmaps_range_start’: ../../../../lib/ext2fs/rw_bitmaps.c:447:1: internal compiler error: Illegal instruction 447 | } | ^ 0x29a738e0 __GI_abort ./stdlib/abort.c:107 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. root@tirpitz:..lib/ext2fs> which has been been reported upstream [3]. The issue does not reproduce on gcc-12. This bug report has been created to raise awareness within Debian. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=binutils=sh4=2.41-6=1697044502=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs=sh4=1.47.0-2%2Bb1=1697478803=0 > [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote: > A small update here. I didn't manage to use the LLVM backend on i386, > seems to be broken [1]. I am trying to figure out now what it takes to build GHC using the LLVM backed on 32-bit PowerPC but it currently doesn't seem to be supported. I am not sure what needs to be patched to enable LLVM code generation for this target, but we will most likely need at least modify the script utils/llvm-targets/gen-data-layout.sh and probably a little more. If enabling LLVM support for a given target is not too involved, we could also look into enabling it for loong64, m68k and sparc64 which also have LLVM backends although the one for m68k is still in development. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054165: ffmpeg: FTBFS when trying to bootstrap with pkg.ffmpeg.stage1
Source: ffmpeg Version: 6.0-7 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! I just tried to rebootstrap ffmpeg for all Debian Ports architectures and noticed that this no longer works due to the build dependency libcjson-dev missing for build profile "pkg.ffmpeg.stage1": pkg-config --exists --print-errors librist >= 0.2.7 Package libcjson was not found in the pkg-config search path. Perhaps you should add the directory containing `libcjson.pc' to the PKG_CONFIG_PATH environment variable Package 'libcjson', required by 'librist', not found ERROR: librist >= 0.2.7 not found using pkg-config This can be fixed by manually installing libcjson-dev into the chroot, so adding the build dependency "libcjson-dev [pkg.ffmpeg.stage1]" to debian/control should fix this bug. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054035: mpich: FTBFS on ppc64 due to bogus architecture check in debian/rules
Source: mpch Version: 4.1.2-2 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello! The configure scirpt for src:mpich is run with --with-ucx on ppc64 despite the architecture not being whitelisted in the architecture check in debian/ rules [1]: checking for rdma/fabric.h... yes checking for fi_getinfo in -lfabric... yes checking for ucp/api/ucp.h... no configure: error: --with-ucx is given but not found tail -v -n \+0 config.log This is because the architecture check in debian/rules uses findstring() which matches "ppc64" in "UCX_ARCH" which is set to "amd64 ppc64el arm64". The proper approach would be to use filter() instead of findstring() since the former matches only words separated by whitespaces [2]. I have verified that this fixes the FTBFS on ppc64. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=mpich=ppc64=4.1.2-2=1694900148=0 > [2] https://www.gnu.org/software/make/manual/html_node/Text-Functions.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1052144: ghc: Needs to link against libatomic on at least m68k
Hello! On Sat, 2023-10-14 at 16:37 +0200, John Paul Adrian Glaubitz wrote: > Hi! > > On Sat, 2023-10-14 at 17:33 +0300, Ilias Tsitsimpis wrote: > > As a side note, I believe the attached patch is wrong, it changes the > > semantics of the functions. Notice that __sync_val_compare_and_swap() > > returns the initial value of the variable x, whereas > > __atomic_compare_exchange() returns true/false, depending on whether the > > operation succeeded. The correct patch is here [1]. > > > > Could this be the reason why your cross-compiler for m68k seg-faults? > > Hmm, good point. I will verify that. Thanks for pointing this out! Cherry-picked the patches from 9.4.7 to fix the 32-bit unregisterised builds plus the patch to use modern atomics now but the cross-compiled package still crashes on m68k: Setting up ghc (9.4.6-1+ports) ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hello! I have built a patched version 9.0.1 of GHC for powerpc with a forged 9.0.3 version number and uploaded it to unreleased so that we have a working bootstrap compiler to build 9.4.7 for powerpc once the bug has been fixed. Unfortunately, we're running into another familiar problem which is a missing -latomic when building hadrian using the bootstrap.py script which does not take any build flags, the build of the »shake« package fails with the linker complaining about unresolved references to 64-bit atomic helper functions: Linking /home/glaubitz/ghc18/ghc-9.4.7/hadrian/_build/dists/shake-0.19.4/build/shake/shake ... /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmStartTransaction': (.text.stmStartTransaction+0xe4): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmStartTransaction+0xfc): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmCommitTransaction': (.text.stmCommitTransaction+0x40): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmCommitTransaction+0x118): undefined reference to `__atomic_load_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(ThreadPaused.thr_o): in function `threadPaused': (.text.threadPaused+0x314): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.threadPaused+0x32c): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(Threads.thr_o): in function `tryWakeupThread': (.text.tryWakeupThread+0x194): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.tryWakeupThread+0x1a8): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.tryWakeupThread+0x1c4): undefined reference to `__atomic_load_8' (...) /usr/bin/ld: (.text.throwToMsg+0x444): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x458): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.throwToMsg+0x478): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x490): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(SpinLock.thr_o): in function `acquire_spin_lock_slow_path': (.text.acquire_spin_lock_slow_path+0x64): undefined reference to `__atomic_fetch_add_8' /usr/bin/ld: (.text.acquire_spin_lock_slow_path+0x80): undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status `powerpc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) When building hadrian with "./hadrian/build -j", it's possible to pass the necessary "-latomic" with the help of "*.*.ghc.link.opts = -latomic". I assume, for the bootstrap python script, will have to patch either the Haskell sources or the Python script. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1052144: ghc: Needs to link against libatomic on at least m68k
Hi! On Sat, 2023-10-14 at 17:33 +0300, Ilias Tsitsimpis wrote: > As a side note, I believe the attached patch is wrong, it changes the > semantics of the functions. Notice that __sync_val_compare_and_swap() > returns the initial value of the variable x, whereas > __atomic_compare_exchange() returns true/false, depending on whether the > operation succeeded. The correct patch is here [1]. > > Could this be the reason why your cross-compiler for m68k seg-faults? Hmm, good point. I will verify that. Thanks for pointing this out! Adrian
Bug#1052144: ghc: Needs to link against libatomic on at least m68k
Hello!
On Fri, 2023-09-22 at 09:20 +0200, John Paul Adrian Glaubitz wrote:
> The attached patch fixes the issue for me. The underlying problem is
> the use of legacy atomic functions for which no 64-bit variants exist
> on some architectures [1]. See also the upstream discussion here [2].
Attaching an updated version of the patch which applies against the 9.4.7-1
version of the ghc package. Would be nice if it could be included for the
next upload.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- ghc-9.4.7.orig/libraries/ghc-prim/cbits/atomic.c
+++ ghc-9.4.7/libraries/ghc-prim/cbits/atomic.c
@@ -291,28 +291,28 @@ extern StgWord hs_cmpxchg8(StgWord x, St
StgWord
hs_cmpxchg8(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord8 *) x, (StgWord8) old, (StgWord8) new);
+ return __atomic_compare_exchange((volatile StgWord8 *) x, (StgWord8 *) , (StgWord8 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord hs_cmpxchg16(StgWord x, StgWord old, StgWord new);
StgWord
hs_cmpxchg16(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord16 *) x, (StgWord16) old, (StgWord16) new);
+ return __atomic_compare_exchange((volatile StgWord16 *) x, (StgWord16 *) , (StgWord16 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord hs_cmpxchg32(StgWord x, StgWord old, StgWord new);
StgWord
hs_cmpxchg32(StgWord x, StgWord old, StgWord new)
{
- return __sync_val_compare_and_swap((volatile StgWord32 *) x, (StgWord32) old, (StgWord32) new);
+ return __atomic_compare_exchange((volatile StgWord32 *) x, (StgWord32 *) , (StgWord32 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
extern StgWord64 hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new);
StgWord64
hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new)
{
- return __sync_val_compare_and_swap((volatile StgWord64 *) x, old, new);
+ return __atomic_compare_exchange((volatile StgWord64 *) x, (StgWord64 *) , (StgWord64 *) , false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}
// Atomic exchange operations
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Wed, 2023-10-11 at 18:29 +0300, Ilias Tsitsimpis wrote: > I think our best bet here is to bootstap GHC on these architectures, > that's why I have introduced the 'pkg.ghc.nohadrian' build profile. Let > me know if I can help, or if there is a better way to do it that I am > missing. OK, good to know about the build profile. However, on powerpc I will most likely still have to cross-compile the package as I don't really have a working native 9.0.x compiler on the target at the moment unless there is a 9.0.x version without the patch [1] that introduced the regression. Adrian > [1] > https://gitlab.haskell.org/ghc/ghc/-/commit/ba089952f034d91718c71f5ef297fe54818559df -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote: > A small update here. I didn't manage to use the LLVM backend on i386, > seems to be broken [1]. > > Instead, I believe I have managed to fix unregisterised GHC on 32-bit, > by backporting these two patches [2] [3]. Can you try building an > unregisterised GHC 9.4.7 on powerpc and see if this resolves the issues > you have with integer overflows? Note that GHC 9.4.7 *with* the Hadrian > build system is now available on experimental. I think you created a little hen and egg problem here by incorporating both the switch to the Hadrian build system as well as the 32-bit unregisterised and sparc64 build fixes into the same upload. Might a good idea to upload the two build fixes unstable first to get a working 9.4.x compiler for all targets so we're able to build haskell-hadrian first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1053767: chromium: please to add support for s390x or armel
Hello William! On Tue, 2023-10-10 at 20:34 +0200, William Desportes wrote: > Chromium could be built on Debian s390x or armel, but it would probably > require some upstream work. > > For now when trying to build on my Linux One s390x VM I got this: > > ERROR at //base/allocator/partition_allocator/partition_alloc.gni:25:3: > Assertion failed. >assert(false, "Unknown CPU: $current_cpu") > Unknown CPU: s390x > > Let me know what direction to go if it's worth trying to add support for > s390x or not. > I would definitely like to have armel supported, maybe it's a more > suitable target. (https://wiki.debian.org/RaspberryPi) > > Once both architectures are built DEP-8 tests will be able to use > chromium-driver on them. I'm afraid this is far beyond the possibilities that a Debian maintainer has. Unless Chromium upstream has full support for a given architecture, it's next to impossible to support the browser or its engine on that particular platform. WebKit and KHTML are currently the most portable browsers followed by Firefox while Chromium really only works on the targets that Google supports. And unless you have a dedicated maintainer, it's next to impossible to get Google upstream support a new architecture. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1053717: glibc: Please add build support for loong64
Source: glibc Version: 2.37-12 Severity: normal User: debian-de...@lists.debian.org Usertags: loong64 X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! Now that Bullseye has been updated to 11.8 which has a dpkg version that supports loong64 [1], we should be all set to be able to upload source packages that have loong64 in their debian/control files. Could you add build support for loong64 to glibc? The changes should be straight- forward but feel free to take a look at the current glibc package in unreleased which was built with loong64 support [2]. Thanks, Adrian > [1] https://www.debian.org/News/2023/2023100702 > [2] > http://ftp.ports.debian.org/debian-ports/pool-loong64/main/g/glibc/glibc_2.37-9+loong64.dsc -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! On Mon, 2023-10-09 at 09:25 +0200, Christian Marillat wrote: > > On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote: > > > > Could you provide the disassembled code for the affected code section? > > Is this enough ? > > , > > Dump of assembler code for function __GI_kill: > >0xf7644b94 <+0>: li r0,37 > >0xf7644b98 <+4>: sc > > => 0xf7644b9c <+8>: bnslr+ > >0xf7644ba0 <+12>:b 0xf762a200 <__syscall_error> > > End of assembler dump. > ` I think the interesting part would be the disassembly of base_GHCziFloat_floatToDigits_closure () where the actual crash happened. Your disassembly seems to show parts of the segfault handler. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote: > > Could you provide the disassembled code for the affected code section? > > I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is > available. The bug affects GHC 9.0.2 as the change was backported. GHC 9.4.x was never available for powerpc at the moment due this particular bug. > Is it important ? It would save me some time, so it would be very helpful. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! > , > | Reading symbols from > /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup... > | (No debugging symbols found in > /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup) > | [New LWP 9082] > | [Thread debugging using libthread_db enabled] > | Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". > | Core was generated by `debian/hlibrary.setup build --builddir=dist-ghc'. > | Program terminated with signal SIGSEGV, Segmentation fault. > | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 > | 122 ../sysdeps/unix/syscall-template.S: No such file or directory. > | (gdb) bt > | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 > | #1 0x108f27b4 in exitBySignal () > | #2 0x108f29f4 in shutdownHaskellAndSignal () > | #3 0x1088c828 in ?? () > | #4 0x108f55a0 in scheduleWaitThread () > | #5 0x108f21c8 in hs_main () > | #6 0x10007408 in main () > | (gdb) > ` Could you provide the disassembled code for the affected code section? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-10-04 at 12:26 +0200, John Paul Adrian Glaubitz wrote: > Looking at the ghc package in openSUSE, I found this patch [1] which disables > unboxed arrays > in order to fix the build on big-endian systems. And, indeed, disabling > unboxed arrays in > libraries/containers/containers/include/containers.h allows me to fully build > ghc from git > on 32-bit PowerPC. See also [2]. I managed to track this down to this commit [1]: ba089952f034d91718c71f5ef297fe54818559df is the first bad commit commit ba089952f034d91718c71f5ef297fe54818559df Author: Sylvain Henry Date: Fri Jan 15 12:33:40 2021 +0100 Bignum: add Natural constant folding rules (#15821) * Implement constant folding rules for Natural (similar to Integer ones) * Add mkCoreUbxSum helper in GHC.Core.Make * Remove naturalTo/FromInt We now only provide `naturalTo/FromWord` as the semantics is clear (truncate/zero-extend). For Int we have to deal with negative numbers (throw an exception? convert to Word beforehand?) so we leave the decision about what to do to the caller. Moreover, now that we have sized types (Int8#, Int16#, ..., Word8#, etc.) there is no reason to bless `Int#` more than `Int8#` or `Word8#` (for example). * Replaced a few `()` with `void#` compiler/GHC/Builtin/Names.hs | 310 +++--- compiler/GHC/Core/Make.hs | 14 +- compiler/GHC/Core/Opt/ConstantFold.hs | 670 +++-- compiler/GHC/HsToCore/Expr.hs | 6 +- compiler/GHC/Types/Id/Make.hs-boot | 1 + libraries/base/GHC/Enum.hs | 4 +- libraries/base/GHC/Float.hs| 6 +- libraries/base/GHC/Int.hs | 16 +- libraries/base/GHC/Natural.hs | 20 +- libraries/base/GHC/Num.hs | 12 +- libraries/base/GHC/Real.hs | 2 +- libraries/ghc-bignum/src/GHC/Num/BigNat.hs | 64 +- libraries/ghc-bignum/src/GHC/Num/Integer.hs| 14 +- libraries/ghc-bignum/src/GHC/Num/Natural.hs| 162 +++-- libraries/ghc-bignum/src/GHC/Num/Primitives.hs | 4 +- libraries/ghc-bignum/src/GHC/Num/WordArray.hs | 4 +- .../integer-gmp/src/GHC/Integer/GMP/Internals.hs | 8 +- testsuite/tests/lib/integer/Makefile | 50 +- testsuite/tests/lib/integer/all.T | 1 + .../tests/lib/integer/naturalConstantFolding.hs| 172 ++ .../lib/integer/naturalConstantFolding.stdout | 38 ++ testsuite/tests/perf/compiler/T16473.stdout| 2 +- .../tests/simplCore/should_compile/T15445.stderr | 2 +- 23 files changed, 1057 insertions(+), 525 deletions(-) create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.hs create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.stdout And I have verified that this commit actually introduced the segfault on 32-bit PowerPC. Adrian > [1] > https://gitlab.haskell.org/ghc/ghc/-/commit/ba089952f034d91718c71f5ef297fe54818559df -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi! On Wed, 2023-10-04 at 11:59 +0200, John Paul Adrian Glaubitz wrote: > FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for > 8.10.7. I assume, > I will need to add some of Debian's patches on top of vanilla GHC in order to > get the build > to succeed. > > Trying to build GHC 9.0.2 fails for example with: > > > http://paste.debian.net/hidden/31954e9a/ Looking at the ghc package in openSUSE, I found this patch [1] which disables unboxed arrays in order to fix the build on big-endian systems. And, indeed, disabling unboxed arrays in libraries/containers/containers/include/containers.h allows me to fully build ghc from git on 32-bit PowerPC. See also [2]. I have now a working reproducer and can now start bisecting between 8.10.7 and 9.0.2. Adrian > [1] > https://build.opensuse.org/package/view_file/devel:languages:haskell/ghc/Disable-unboxed-arrays.patch?expand=1 > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/16998 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-09-20 at 14:54 +0300, Ilias Tsitsimpis wrote: > Thanks for working on this, comments inline. Thanks for the useful hints! > On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote: > > I have been bisecting this issue but in order to be successful, I need a > > simple > > reproducer which isn't trivial since I cannot just reuse the build > > directory of > > an unsuccessful build due to the changing Haskell libraries for different > > GHC > > versions. > > > > Ideally, we should have a single command line with GHC which will trigger > > the > > segmentation fault. > > Are you bisecting the segfault issue? If yes, then a simple reproducer > would be to try and compile haskell-random. > > Since you already have cabal-install on your system, you can do > something like: > > $ cabal install --with-ghc=/usr/bin/ghc --with-ghc-pkg=/usr/bin/ghc-pkg > random-1.2.1.1 > > (replace ghc and ghc-pkg with the ones you have built). Thanks, this is the exact reproducer I need. I can reproduce the crash using this command line inside a 32-bit PowerPC chroot on perotto with ghc 9.0.2. > > To bisect, I have done the following: > > > > # git bisect start > > # git bisect good ghc-8.10.7-release > > # git bisect bad ghc-9.2.7-release > > Since this issue is also present in ghc-9.0.2, maybe we can start from > there. Yes, that's what I am trying now as well. > > # git submodule update --init > > # ./boot ; python3 boot > > # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ > > echo "Stage1Only := YES" >> mk/build.mk && \ > > echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ > > >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += > > "-f-build-tool-depends"' \ > > >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += > > "-f-build-tool-depends"' \ > > >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ > > && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo > > "BUILD_SPHINX_PDF := NO" \ > > >> mk/build.mk > > # ./configure && make -j32 > > > > For newer versions, the build has to be performed with Hadrian, so the last > > step > > would be: > > > > # ./hadrian/build -j > > Keep in mind that hadrian doesn't take into account 'mk/build.mk'. You > will have to configure hadrian in the same way, see also > https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html. Thanks, good to know! > Let me summarize the current state to make sure we are not missing > anything: > > 1. GHC 9.0.2 with the native code generator is currently broken on > powerpc and segfaults while building (at least) haskell-random and > GHC-9.4.6. Strangely enough, we can compile GHC 9.0.2 itself. > > 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing > code that overflows integers. We are also seeing unregisterised GHC > 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail > (see > https://buildd.debian.org/status/package.php?p=haskell-quickcheck=sid). > The plan for i386 is to registerise GHC and use the LLVM backend by > default (to avoid the baseline violation). I see. > 3. We cannot cross-compile GHC 9.4 and newer any more (we are discussing > this here as well https://gitlab.haskell.org/ghc/ghc/-/issues/23975). This can be trivially fixed with the help of this patch: > https://gitlab.haskell.org/ghc/ghc/-/commit/9cb385098f2dfd647c13ca509d71786c56277cff > Given the above, I can think of the following: > > 1. Fix the native code generator in GHC 9.0.2 > 2. Fix unregisterised GHCs on 32-bit architectures FWIW, I am seeing the overflow on 32-bit PowerPC only. I don't see it on m68k, for example. > 3. Try and use the LLVM backend in GHC 9.0.2 on powerpc, and see if this > produces valid code and allows us to compile GHC 9.4.6. Ah, that's actually a possible approach to take. FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for 8.10.7. I assume, I will need to add some of Debian's patches on top of vanilla GHC in order to get the build to succeed. Trying to build GHC 9.0.2 fails for example with: > http://paste.debian.net/hidden/31954e9a/ > For the record, I have started working on migrating GHC in Debian to use > the new Hadrian build system, you can find the latest code here > https://salsa.debian.org/haskell-team/DHG_packages/-/tree/hadrian. I am > at a really good state right now where I can build GHC, and doing a lot > of tests to verify I haven't missed anything. If you are working on GHC > right now as well, I would appreciate if you can take a look, and/or > start using this branch for all your tests, so we catch any errors > early. I want to get the build issue on 32-bit PowerPC sorted out first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
