Bug#1065416: Bastian's offer in #1065416
Hi Matthias, On Sun, 2024-09-15 at 13:50 +0200, Matthias Klose wrote: > > It is trivial for us to add support for additional architectures once > > they are minimally supported in upstream Linux (we may also require > > that dpkg recognises their triplet; I'm not sure). There is no > > requirement that we define a kernel configuration for the architecture > > at the same time, or ever (see x32). > > > > Can we assume that new Debian Linux ports will be able to satisfy that > > or would that be a problem sometimes? > > CCing Adrian, he recently wanted to provide cross toolchains for > sparc-linux-gnu and ia64-linux-gnu, which the kernel doesn't provide > anymore. So a design which allows these toolchains would be helpful. I actually don't care about ia64 anymore as the architecture was beyond repair and upstream really wanted to get rid of it. Having said that, a cross-toolchain for 32-bit SPARC would be nice to have (binutils, glibc, gcc and linux-libc-dev) to perform regular integration tests for the sparc-unknown-linux-gnu target as well as the 32-bit SPARC kernel. 32-bit SPARC has been adapted as the Leon CPU for space applications such as satellites and space craft. Thanks to this, SPARC is also being actively maintained in the Linux kernel again and there is solid funding behind the port. Oracle also has some people actively maintaining the software stack for SPARC, allegedly even on Linux although the latter doesn't have high priority at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081542: FTBFS with Python 3.13
Source: python-greenlet Version: 2.0.2-1 Followup-For: Bug #1081542 Hello, just as a heads-up: This issue has been fixed upstream with version 3.1.0, so that this bug report can be closed once that version has been uploaded to unstable. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1066996: python-greenlet: Please add patch to support sh4
Hello, On Sat, 2024-03-16 at 18:29 +0100, John Paul Adrian Glaubitz wrote: > the attached patch adds support for building python-greenlet on sh4, it's > a modified (fixed) version that is currently open for review upstream [1]. This patch has now been merged upstream such that this bug can be closed when updating to the recently released greenlet 3.1.0 or newer. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081636: node-undici: Please split out llhttp library into separate package
Source: node-undici Version: 5.28.4+dfsg1+~cs23.12.11-2 Severity: important Hello, while the libllhttp-dev package is being used by other packages such as libgit2, its source package, node-undici, has a transitive build dependency on NodeJS which means that libllhttp-dev can only be built on architectures where NodeJS is available. Since libllhttp-dev itself does not depend on NodeJS, it would be good if the llhttp library could be split out of the node-undici package so it can be built and used on any architecture, even where NodeJS is not available. This also eases the bootstrap process for new architectures. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081534: libgit2: Switch to libllhttp-dev massively reduces installability of libgit2
Source: libgit2 Version: 1.8.1+ds-1 Severity: important User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, libgit2 in experimental has been switched from libhttp-parser-dev to libllhttp-dev which massively reduced installability of libgit2 because the latter has a transistive dependency on nodejs which has only limited platform support. Please switch libgit2 back to libhttp-parser-dev for architectures that don't build libllhttp-dev because they don't have support for nodejs. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081515: gtk4: FTBFS on -ports architectures: many tests fail with --setup=wayland: Failed to open display
Hello Simon, On Thu, 2024-09-12 at 11:48 +0100, Simon McVittie wrote: > weston might be broken on all -ports architectures and functional on > all release architectures, but that level of coincidence seems a little > far-fetched. So my next theory for this is that something is consistently > different about the -ports buildds - perhaps their XDG_RUNTIME_DIR is > set up differently? - and that is causing > "debian/tests/run-with-display wayland" (or the copy of weston that it > runs) to fail? Thanks for the report. The configuration for the Debian Ports buildds is maintained via Puppet[1], the same applies to the release architectures [2]. So, if there is any relevant difference, it should be possible to find that in the Puppet configuration and make necessary changes to the Ports Puppet configuration. Adrian > [1] https://salsa.debian.org/debian-ports-team/dsa-puppet > [2] https://salsa.debian.org/dsa-team/mirror/dsa-puppet -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works
On Wed, 2024-09-04 at 18:51 +0100, Simon McVittie wrote: > I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether > we can use the new ORCJIT llvmpipe and remove the workaround for #1010838, > but it's taking a while (mips64el machines are not fast). So far it's > looking as though we will still get quite a lot of test failures. The powerpc/ppc64 porterbox perotto.debian.net should be considerably faster than any mips64el machine we have. So, you may give it a try there as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1079755: linux: Please disable CONFIG_CRASH_DUMP on powerpc
Source: linux Version: 6.10.6-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, in 75bc255a7444 [1] CONFIG_CRASH_DUMP was enabled by default for all architectures which made the kernel unbootable on 32-bit PowerPC (powerpc) since crash dump kernels cannot be booted from Open Firmware on this target [2]. Thus, please disable CONFIG_CRASH_DUMP on powerpc by default. We may have to disable it on m68k and sh4 as well, but I haven't verified that yet. Thanks, Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75bc255a7444801d64c7a7bd09e3f452f86b3585 > [2] https://lists.debian.org/debian-powerpc/2024/07/msg1.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#856877: schroot: regression presumably in 1.6.13-4 after fixing #856877
Hello, On Mon, 2024-08-19 at 16:46 +0100, Simon McVittie wrote: > What is the reproducer for this? > > - host system: is it testing, or unstable, or stable with a backport of > schroot 1.6.13-4, or what? Host system is unstable. > - host kernel seems to be 6.9.12-powerpc64 6.9.12-1 Yes. I can try with a different kernel if necessary. > - is there any other container/chroot/confinement going on, or is it > sbuild + schroot running on a real machine? It's sbuild + schroot on a real machine running unstable. > - is there a smaller reproducer for the problem than "build gcc", like > perhaps opening a schroot environment and running expect(1) in some > specified way? I haven't tried yet. > I initially provided the patch that was recently applied to schroot > back in 2017, and unfortunately I don't completely remember what I did > 7 years ago, but I think my usual reproducer for "do pseudo-terminals > work?" for #856877/#983423 was to run something like > "script -c 'cat /etc/os-release' /dev/null" inside a schroot. Okay, I can try that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#856877: schroot: Please consider mounting a new instance of /dev/pts
Package: schroot Followup-For: Bug #856877 Hello, this change seems to have broken pseudo-terminals for buildds [1]: The system has no more ptys. Ask your system administrator to create more. while executing "spawn true" expect is failing on your system with the above error, which means the GCC testsuite will fail. Please resolve the above issues and retry the build. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=ppc64&ver=14.2.0-3&stamp=1724003978&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1078743: vtk9: BD-Uninstallable on 32-bit architectures after #1068320
Source: vtk9 Version: 9.3.0+dfsg1-1 Severity: serious Justification: ftbfs Hello, the package src:vtk9 has become BD-Uninstallable on 32-bit architectures after the src:hdf5 package has dropped OpenMPI support for them in #1068320 [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068320 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077724: fixed in adequate 0.16.7
Control: reopen -1 On Thu, 2024-08-01 at 22:49 +, Debian FTP Masters wrote: >* Add version constraint to Build-Depends: golang-go, for relatively new > stdlib packages (cmp and slices). Closes: #1077724. This is not what my bug report was about. Please replace "golang-go" with "golang-any" in Build-Depends. There is no reason to artificially limit the support for this package to architectures only which have Google's own Go compiler. See: https://buildd.debian.org/status/package.php?p=adequate&suite=sid Please use "golang-any". The FTBFS will fix itself on the other architectures once gccgo has been brought up to the Golang version that supports "cmd" and "slices". Thanks, Adrian
Bug#1077724: adequate: FTBFS with gccgo
Hello, On Thu, 2024-08-01 at 21:19 +0200, Serafeim Zanikolas wrote: > > src/salsa.debian.org/debian/adequate/binfmt.go:7:2: cannot find package > > "cmp" in any of: > > /home/glaubitz/adequate/adequate-0.16.5/_build/src/slices (from > > $GOPATH) > > that should be fixable on my end, by adding a version constraint on the > golang-go build dependency. Please build-depend on golang-any, not golang-go. The latter enforces the use of the Google Go compiler and blocks the use of golang-gccgo on targets where golang-go is not available. golang-any defaults to the Google Go compiler where available and on gccgo for the other platforms. > slices and cmp have been introduced in 1.21, and presumably gccgo is on 1.20 > (current version of gcc-defaults is 1.203) gccgo is on Go 1.18 with gcc-14: (sid_sparc64-dchroot)glaubitz@stadler:~/adequate/adequate-0.16.5$ go version go version go1.18 gccgo (Debian 14.1.0-5) 14.1.0 linux/sparc64 (sid_sparc64-dchroot)glaubitz@stadler:~/adequate/adequate-0.16.5$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077724: adequate: FTBFS with gccgo
Source: adequate Version: 0.16.5 Severity: normal Hello, I tried to build adequate with gccgo in order to make it available to more architectures but unfortunately the code isn't portable enough at the moment: CGO_CFLAGS="-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=. -Wformat -Werror=format-security" CGO_CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CGO_CXXFLAGS="-g -O2 -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=. -Wformat -Werror=format-security" CGO_FFLAGS="-g -O2 -ffile-prefix-map=/home/glaubitz/adequate/adequate-0.16.5=." CGO_LDFLAGS="-Wl,-z,relro" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2873516682=/tmp/go-build -gno-record-gcc-switches -funwind-tables" cd _build && go install -trimpath -v -p 48 salsa.debian.org/debian/adequate salsa.debian.org/debian/adequate/private src/salsa.debian.org/debian/adequate/binfmt.go:7:2: cannot find package "cmp" in any of: /usr/src/cmp (from $GOROOT) /home/glaubitz/adequate/adequate-0.16.5/_build/src/cmp (from $GOPATH) src/salsa.debian.org/debian/adequate/adequate.go:13:2: cannot find package "slices" in any of: /usr/src/slices (from $GOROOT) /home/glaubitz/adequate/adequate-0.16.5/_build/src/slices (from $GOPATH) dh_auto_build: error: cd _build && go install -trimpath -v -p 48 salsa.debian.org/debian/adequate salsa.debian.org/debian/adequate/private returned exit code 1 make: *** [debian/rules:8: binary-arch] Error 1 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 Not sure whether this is an issue that should be reported with gccgo upstream or here. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi Liu, On Fri, 2024-07-26 at 17:09 +0800, Zixing Liu wrote: > > Now you're putting me under pressure. Are you in a hurry? > > No, I am not in a hurry. I just realized I might have made a mistake > by not opening a merge request on Debian Salsa since that may be a > more straightforward solution. > So, I wanted to let you know that I was fixing this mistake. OK, no worries. > Please take as much time as you need to test and upload the fix. I'm > sorry if my wording sounds like I am putting you under pressure, as > English isn't my native language, so miscommunication might have > happened there. > No, it's perfectly fine. I really appreciate your help. I currently have some motivation issues working on Debian but it's getting better now and I want to do it myself to be able to help overcome my mental barrier by forcing myself to do it. Apologies if I sounded harsh. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello, On Fri, 2024-07-26 at 12:14 +0800, Zixing Liu wrote: > I have also prepared > https://salsa.debian.org/debian/hfsutils/-/merge_requests/2 if you are > having issues with your local Git tree. > You can verify the merge with the version I uploaded to > https://mentors.debian.net/debian/pool/main/h/hfsutils/hfsutils_3.2.6-17.dsc. Now you're putting me under pressure. Are you in a hurry? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077042: gcc-14: FTBFS on m68k due to segfault compiling unwind-dw2.c
Source: gcc-14 Version: 14.1.0-5 Severity: normal Tags: upstream User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hi, gcc-14 fails to build from source on m68k due to the compiler segfaulting when compiling unwind-dw2.c. This issue is already being tracked upstream [1], I'm just reporting this bug to raise more awareness and help track the issue within Debian. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Ben, On Mon, 2024-07-22 at 00:07 +0200, Ben Hutchings wrote: > I don't know what differences there are between these builders that > might be relevant. For kapitsa, the installed host system is powerpc while all the others run the ppc64 port. As for the hardware: kapitsa runs bare-metal (inside an LPAR) on a POWER8 machine: root@kapitsa:~# grep model /proc/cpuinfo model : IBM,8284-22A root@kapitsa:~# Both blaauw and perotto are KVMs running on watson which runs Debian's ppc64el port (little-endian): root@watson:~# grep model /proc/cpuinfo model : 8247-42L root@watson:~# root@blaauw:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@blaauw:~# root@perotto:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@perotto:~# Both debian-project-be-01 and debian-project-be-02 are KVMs running on OpenStack at OSUOSL's OpenPOWER platform: root@debian-project-be-1:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-1:~# root@debian-project-be-2:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-2:~# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
On Sat, 2024-07-20 at 21:17 +0200, Ben Hutchings wrote: > I had a go yesterday and ran into the same problem. I couldn't > reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO + > DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of > the Debian kernel flavours. > > > Will take care of it and let you know when it's (some hours). > > Thank you! There are now 120 GB of free disk space. Let me know if that's sufficient or whether I need to clean up more, probably asking others to clean up their home directories. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Domenico, On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote: > > > Is there anything I can do to help? > > > > From the 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1 > > file: > > > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > > --lang_exclude=rust .tmp_vmlinux.btf > > > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > > reproduce it here? > > I don't have access to the build host (blaauw2) and I've some doubts > it would still have that file. > > Maybe our kernel team and powerpc porters have suggestions? I have root access to all powerpc/ppc64 machines (buildds and porterbox). I'm cleaning up the porterbox now, disk is quite full, then you can try to build the kernel package on perotto.debian.net or I can try it myself. I have seen the bug myself and I wanted to debug it, but the attempt was foiled by the fact that the disk on perotto is full (again). Will take care of it and let you know when it's (some hours). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076536: wireshark: Please ignore tests on big-endian architectures in Debian Ports
Source: wirkshark Version: 4.2.6-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, like on s390x, some tests are failing on powerpc, ppc64 and sparc64: > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=powerpc&ver=4.2.6-1&stamp=1720790838&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=ppc64&ver=4.2.6-1&stamp=1720785055&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=sparc64&ver=4.2.6-1&stamp=1720858739&raw=0 Could you ignore the tests on all big-endian architectures in Debian Ports? These are: - hppa - m68k - powerpc - ppc64 - sparc64 Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Mon, 2024-07-01 at 20:05 +0200, John Paul Adrian Glaubitz wrote: > > After digging through the Debian BTS, I can see the patch may fix > > #421457 in BTS. > > Maybe you can edit my changelog entry to indicate that. > > Thanks for the suggestion. I will have a look. Sorry for not getting this > fixed, > there was a lot of work to be done in June. I have started working on this now and I just realized I messed a bit up in my packaging source git tree. So, it might take me a little longer to get this properly fixed up. I will import for patch crediting you, so thanks a lot for fixing this issue! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076424: ausweisapp: UI does not show
Hello Maximilian, On Tue, 2024-07-16 at 10:02 +0200, Maximilian Stein wrote: > I am using KDE on Debian testing and just tried to install and use the > ausweisapp. > > However, I cannot get a UI: When starting the program, the tray icon > appears alongside a notification that the application has been > started. Neither double clicking the tray icon nor right click + open > brings up the UI. Moreover, I tried to run `AusweisApp --show`, > without success. > > The log contains a couple of warnings: > > default 2024.07.16 09:49:52.433 13780 W (:0) >: QQmlApplicationEngine failed to > load component > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/Init/App.qml:483) : > qrc:/qt/qml/Governikus/Init/App.qml:483:4: Type DetachedLogView unavailable > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16) : > qrc:/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16:2: Cannot override > FINAL property > > So, maybe there is a dependency missing? This is a known issue that occurs when using AusweisApp 2.2.0 with Qt 6.6.0. It will be fixed in the upcoming 2.2.1 release. If upstream doesn't release this version in a timely fashion, I am going to backport the patch that fixes the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?
Source: bpfcc Version: 0.26.0+ds-1 Followup-For: Bug #1030657 Hi, looking at [1], the list of architectures is still very limited. Can we at least enable bpfcc on all architectures in Debian Ports? Since Debian Ports is not an officially supported distribution, there shouldn't be any concerns with regressions and bugs once they arise. If the lack of personal time to be able to spend on this package, I would suggest creating a bug report to request for help (RFH). Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=bpfcc&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060195: hfsprogs: install files into /usr (DEP17)
Hello, > On Jul 13, 2024, at 12:39 PM, Chris Hofstaedtler wrote: > > On Sun, Jan 07, 2024 at 12:07:02PM +0100, Chris Hofstaedtler wrote: >> Source: hfsprogs >> Version: 540.1.linux3-5 > [..] >> Please find a patch attached to install aliased files into /usr, >> for the currently ongoing UsrMerge effort [1]. > > Friendly reminder about this bug. > > Please consider fixing it soon. Did not notice this before. Will fix it this weekend. Adrian
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hi Otto, On Fri, 2024-07-05 at 23:00 -0700, Otto Kekäläinen wrote: > Thanks for the tips. Unfortunately running just the single test > without any other load on the system still crashes it and system load > was otherwise zero, so it is not due to slowness. Single-core performance on SPARC is rather poor, especially on older SPARC systems like this SPARC T4. So, if this test requires reasonanbly high single-core performance, you know why it fails on SPARC. We might get a newer, faster SPARC buildd in the near future though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hello Otto, On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote: > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed > on sparc64. > > Are there any sparc64 hackers interested in taking a look? > > The build itself passed and most of the post-build passes, but some > tests cause the database to crash. Stack traces are visible in the > logs: > > https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.4.2-2&stamp=1719891893&raw=0 > https://buildd.debian.org/status/logs.php?pkg=mariadb&arch=sparc64 I would suggest rerun the build plus testsuite on the porterbox stadler with glibc debug packages installed in the chroot so you can get a more usable backtrace. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi, On Mon, 2024-07-01 at 12:03 -0600, Zixing Liu wrote: > On Wed, Jun 12, 2024 at 3:27 PM John Paul Adrian Glaubitz > wrote: > > > > Hello Liu, > > > > On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > > > This patch does the following: > > > > > > * d/rules: switch to use the debhelper autoreconf template. > > > - d/rules: disable parallel testing. > > > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper > > > now. > > > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory > > > corruption > > > issues (LP: #493273). > > > > > > > > > Thanks for considering the patch. > > > > Thanks for your patch. I'll implement your changes in the weekend. > > > > After digging through the Debian BTS, I can see the patch may fix > #421457 in BTS. > Maybe you can edit my changelog entry to indicate that. Thanks for the suggestion. I will have a look. Sorry for not getting this fixed, there was a lot of work to be done in June. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386
Source: gcc-14 Version: 14.1.0-2 Severity: normal User: debian-h...@lists.debian.org Usertags: hurd-i386 X-Debbugs-Cc: debian-h...@lists.debian.org Hi, gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs [1]: configure: error: cargo is required to build rust Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=hurd-i386&ver=14.1.0-2&stamp=1718795837&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: fixed in cups 2.4.7-3
Hi Thorsten, On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote: >[ Thorsten Alteholz ] >* reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) >* debian/rules: no test on riscv64 (Closes: #1073046) Would be great if the testsuite could be disabled for sparc64 as well if there is no prospective fix for the testsuite failures in sight. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 10:33 +0200, Sune Stolborg Vuorela wrote: > On Friday, June 14, 2024 10:25:59 AM CEST John Paul Adrian Glaubitz wrote: > > I'm not denying that. However, a package named "qml6-module-qtquick-effects" > > doesn't sound like an interpreter to me. > > > > Thus, I don't really see how I am supposed to know as a maintainer what > > packages add Depends except for trial and error. Why not have one canonical > > "qt-interpretor" package or similar that applications can depend on? > > This is a module for a interpreted language. It is not much different than a > python package might need a hardcoded dependency on python-foo if it uses > that. or a perl package might need a hardcoded dependency on libperl-foo-bar- > baz if it uses the Foo::Bar::Baz perl module for important functionality. > > all qml*-module packages are qml (interpreted language) extensions. > > And yes. trial and error - or reading the sources - is for many interpreted > languages the only way of figuring it out. Ugh, that's truly a step backwards and way to add more burden to maintainers. I guess we'll be seeing plenty of such bug reports in the future when extensions get moved around or new ones get added. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote: > > Do we still have to build an unregisterised compiler for powerpc > > or can we switch back to NCG (https://bugs.debian.org/1060196)? > > I have not verified that yet. Please let's stay unregisterised for now > and have me verify first whether the NGC has been fixed with 9.6.x or > newer. > > Please let's keep this bug report open and use #1073159 [1] for adding > the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. GHC 9.6.5 still fails on powerpc with the NGC enabled: # rts/include/rts/prof/LDV.h | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o | Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o | Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '- package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc- 9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include - optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno- error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db - package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts - I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 ghc: panic! (the 'impossible' happened) GHC version 9.6.5: PPC.Ppr.pprInstr: JMP to ForeignLabel CallStack (from HasCallStack): panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register * Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library * Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library * Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o at cmd', called at src/Builder.hs:387:23 in main:Builder at cmdArgs, called at src/Builder.hs:540:8 in main:Builder at cmd
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 09:39 +0200, Sune Stolborg Vuorela wrote: > Control: severity -1 serious > > Missing dependencies are RC > > > This is a common problem with Qt6 and has been reported for a different > > dependency before, see [1]. > > It is normal for interpreted languages to have their dependencies managed > manually. This is just another version of that. I'm not denying that. However, a package named "qml6-module-qtquick-effects" doesn't sound like an interpreter to me. Thus, I don't really see how I am supposed to know as a maintainer what packages add Depends except for trial and error. Why not have one canonical "qt-interpretor" package or similar that applications can depend on? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073159: ghc: Please include --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS
Source: ghc Version: 9.4.7-5 Severity: important Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi, after debugging the segmentation faults with the unregisterised GHC on powerpc for a long time, I finally found the culprit which is the fact that GHC is built to default to the gold linker by default. The gold linker is known to be broken on some architectures which is unlikely to change in the future as the project has been abandoned by Google [1], so it has been long disabled for several architectures in debian/rules by passing the flag --disable-ld-override in EXTRA_CONFIGURE_FLAGS. However, as I learnt today, this only affects the linker choice when building GHC but not the default linker for the actual binary packages which still defaulted to gold in /usr/lib/ghc/lib/settings. As one of the upstream developers explained to me today [2], it's necessary to pass --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS as well in order to disable gold for the binary distribution, i.e. what will end up in the Debian package. Thus, please modify debian/rules to also include the flag --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS: --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH))) Also attaching a patch. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/Gold_(linker) > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/24986#note_570504 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote: > Great job! Thanks! > I completely missed the fact this needs to be passes to the bindist's > configure script as well. It took me forever to figure this out ;-). > You need to edit debian/rules here > https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 > and add the following line as well: > > + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override Yes, that's what I suggested, see my patch in [1]. > I will include that in the next upload. Great, thank you. I uploaded a patched version to unreleased in the mean time. > Do we still have to build an unregisterised compiler for powerpc > or can we switch back to NCG (https://bugs.debian.org/1060196)? I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Jeff, On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > Now we just need to figure out how to actually set the default linker back > > to bfd as it was actually explicitly supposed to happen according to > > debian/rules. > > > > This will most likely also unbreak GHC on m68k. > > Good job, Adrian. That's quite a bit of work to track down the issue. Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > This patch does the following: > > * d/rules: switch to use the debhelper autoreconf template. > - d/rules: disable parallel testing. > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper now. > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory corruption > issues (LP: #493273). > > > Thanks for considering the patch. Thanks for your patch. I'll implement your changes in the weekend. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
Control: severity -1 normal Hello Reinhard, On Wed, 2024-06-12 at 18:40 +0200, Reinhard Karcher wrote: > ausweisapp doesn't start the gui, because qml6-module-qtquick-effects > is not installed. It should depend on that package. > Installing qml6-module-qtquick-effects solves the problem. This is a common problem with Qt6 and has been reported for a different dependency before, see [1]. I haven't found a satisfactory solution as hard-coding a dependency as suggested in your bug report would mean that the package cannot undergo automatic transitions. I am therefore reducing the severity to normal as the package would otherwise be removed from testing. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070018#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: cups: FTBFS on riscv64 due to testsuite timeouts
Source: cups Version: 2.4.7-2 Severity: serious Tags: ftbfs Justification: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Hello, src:cups currently FTBFS on riscv64 due to a testsuite timeout [1]: Running command tests... Performing 5.1-lpadmin.sh: FAIL Performing 5.2-lpc.sh: PASS Performing 5.3-lpq.sh: FAIL Performing 5.4-lpstat.sh: FAIL Performing 5.5-lp.sh: FAIL Performing 5.6-lpr.sh: FAIL Performing 5.7-lprm.sh: FAIL Performing 5.8-cancel.sh: FAIL Performing 5.9-lpinfo.sh: FAIL Performing restart test: ./run-stp-tests.sh: 811: kill: No such process E: Build killed with signal TERM after 600 minutes of inactivity This issue has been observed on sparc64, so it seems reproducible. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=cups&arch=riscv64&ver=2.4.7-2&stamp=1718180226&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]
Hi Guillem, On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote: > > I had a look at this, and it seems like this package has never really > > worked on ARM systems at all? And this was hidden due to the missing > > declarations not being an error. > > > > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other > > systems have instead memory mapped I/O, but the code in mem.c is > > unconditionally calling port I/O functions such as in*() and out*(), > > provided by glibc. > > > > Until the upstream code is ported to systems with memory mapper I/O, I > > think the "best" way to resolve this would be to restrict the > > architecture list to: > > > > any-amd64 any-i386 alpha ia64 > > The attached patch implements this. It should not affect reverse build > depending packages (only hwinfo) which is already arch restricted to > «amd64 i386». > > I'm including the arm list to confirm the above, but also in case > someone there feels like porting the library to support memory mapped > I/O? (But perhaps that's not worth the effort.) It's perfectly fine to disable libx86emu on ARM as it has already been correctly stated, there are no I/O ports on ARM so the above code won't work on ARM. I also don't expect that to change in the future, so it's not worth bothering about this in the future, especially since the upstream project hasn't been very active lately [1]. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072940: mailtuils: FTBFS on sparc64 due to outdated symbols file
Source: mailutils Version: 1:3.17-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, mailutils fails to build from source on sparc64 due to an outdated symbols file [1]: dpkg-gensymbols: warning: debian/libmailutils9t64/DEBIAN/symbols doesn't match completely debian/libmailutils9t64.symbols --- debian/libmailutils9t64.symbols (libmailutils9t64_1:3.17-2_sparc64) +++ dpkg-gensymbolsjTYNfd 2024-06-09 13:24:35.314252567 + @@ -1928,6 +1928,7 @@ mu_py_script_run@Base 1:3.17 libmu_scm.so.9 libmailutils9t64 #MINVER# * Build-Depends-Package: libmailutils-dev + _etext@Base 1:3.17-2 _mu_scm_bugreport@Base 1:3.17 _mu_scm_debug@Base 1:3.17 _mu_scm_mailer@Base 1:3.17 dh_makeshlibs: error: failing due to earlier errors make[1]: *** [debian/rules:86: override_dh_makeshlibs] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary-arch] Error 2 Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=mailutils&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency
Hello, On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote: > please package v10.0.21 and remove the obsolete python3-mock build dependency > > > https://github.com/testing-cabal/mock > > > > mock is now part of the Python standard library, available as unittest.mock > > in Python 3.3 onward > > more information cab be find here: > > https://github.com/OSInside/kiwi/pull/2470 I have tried packaging the latest upstream version but I was unable to get the testsuite to pass successfully as setting the proper PYTHONPATH for running the testsuite did not work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072897: rustc: Please ignore test_arc_condvar_poison on powerpc
Source: rustc
Version: 1.75.0+dfsg1-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hi,
the test test_arc_condvar_poison hangs on powerpc for rustc 1.75.0 [1]:
test time::tests::instant_monotonic_concurrent ... ok
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
test sync::mutex::tests::test_arc_condvar_poison has been running for a long
time
E: Build killed with signal TERM after 150 minutes of inactivity
Please include the attached patch to ignore it for the time being.
Thanks,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=powerpc&ver=1.75.0%2Bdfsg1-4&stamp=1717703746&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
===
--- rustc-1.75.0+dfsg1.orig/library/std/src/sync/mutex/tests.rs
+++ rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
@@ -145,6 +145,7 @@ fn test_mutex_arc_condvar() {
}
}
+#[cfg(not(target_arch = "powerpc"))]
#[test]
fn test_arc_condvar_poison() {
let packet = Packet(Arc::new((Mutex::new(1), Condvar::new(;
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hello, On Sun, 2024-06-09 at 16:39 +0200, marillat wrote: > > This can be fixed by switching off vectorization in the »eigen« using the > > preprocessor > > macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line > > using the > > cmake variable COMPILE_DEFINITIONS: > > > > --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 > > 17:52:13.0 +0200 > > +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 > > @@ -9,6 +9,10 @@ > > cmake_extra_args += -DQT_HOST_PATH=/usr > > endif > > > > +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) > > + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" > > +endif > > + > > %: > > dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja > > > > With the above change, cmake defines the preprocessor macro > > EIGEN_DONT_VECTORIZE and > > the build succeeds on powerpc. > > With qt6-multimedia 6.6.2 qt6-multimedia still fail to build even with > this patch. > > I'm unable to find a solution. Adrian do you have an idea ? The syntax of my proposed solution was wrong. My local tests were not performed on a clean source which is why I did not notice the suggested syntax didn't work. The proper syntax is: ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) export DEB_CXXFLAGS_MAINT_APPEND = -DEIGEN_DONT_VECTORIZE endif @Patrick: Could you update the debian/rules file please to use the above syntax? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hi, On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote: > > > I will take care of this myself. Please remove the upload. > > Done. Thanks. > > > I will try to fix the package tomorrow. Apologies for the delay. > > I'll take this opportunity to point out #1060195, a similar bug in > hfsprogs. Thanks for the reminder. Appreciate it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote: > On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > > uploaded it to DELAYED/14. Please feel free to tell me if I > > should delay it longer. > > I will take care of this myself. Please remove the upload. Sorry for the brevity in my previous mail. The reason I didn't fix this bug was because I missed the bug notification mail, so I wasn't aware this bug was around. I will try to fix the package tomorrow. Apologies for the delay. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I > should delay it longer. I will take care of this myself. Please remove the upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1051068: sysprof: Should mark test build dependencies as
On Tue, 2024-06-04 at 10:36 -0400, Jeremy Bícha wrote: > On Sat, Sep 2, 2023 at 4:22 PM Jeremy Bícha > wrote: > > > > Control: tags -1 moreinfo > > > > On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz > > wrote: > > > src:sysprof has multiple build dependencies in debian/control which are > > > required for running the testsuite only but yet these build dependencies > > > are not marked as to allow the package to be bootstrapped on > > > a new architecture. > > > > I was unable to identify any build dependencies like that. Please > > submit a merge proposal if you have specific improvements in mind. > > I am closing this bug since there has been no reply and there wasn't > enough information in this bug report to take any action. Hmm, I'm pretty sure that these were obvious. I will have to recheck. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability
Source: ipywidgets Version: 8.1.2-3 Severity: important Hello, the recent change to obsolete some binary packages in ipywidgets [1] introduced a hard dependency on nodejs which is available on a limited set of architectures only making ipywidgets uninstallable on a number of architectures: - alpha - hppa - hurd-amd64 - hurd-i386 - m68k - powerpc - ppc64 - sh4 - sparc64 - x32 Would it be possible to revert this change to remove the introduced dependency on nodejs again? Thanks, Adrian > [1] > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
OK, it seems that this is because of x32 being part of "rs_no_cpu" in debian/rules.defs. So, please remove x32 from the Rust exclusion list and add cargo to BuildDepends in debian/control. It remains to be resolved why the build tries to enable Rust support despite x32 being in "rs_no_cpu" in debian/rules.defs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, trying to build gcc-14 on x32 fails because the package gccrs-14-x86-64-linux-gnux32 is missing in debian/control so that the call to dh_installdirs fails: dh_installdirs -pgccrs-14-x86-64-linux-gnux32 usr/bin usr/share/man/man1 usr/libexec/gcc/x86_64-linux-gnux32/14 usr/share/lintian/overrides dh_installdirs: error: Requested unknown package gccrs-14-x86-64-linux-gnux32 via -p/--package, expected one of: gcc-14-base libgcc-s1 (...) gccrs-14-for-build gccrs-14 gcc-14-source dh_installdirs: error: unknown option or error during option parsing; aborting I assume the oversight was that on x32, the architecture is not used as a package prefix but a package suffix, i.e. gccrs-14-x86-64-linux-gnux32 instead of gccrs-14-x32-linux-gnu. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072336: gcc-14: FTBFS on x32 due to outdated symbols file libasan8.symbols
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, after installing cargo manually in the chroot to work around #1072327 [1], I ran into an FTBFS on x32 due to an outdated symbols file libasan8.symbols: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libasan8/DEBIAN/symbols doesn't match completely debian/libasan8.symbols --- debian/libasan8.symbols (libasan8_14.1.0-1_x32) +++ dpkg-gensymbolsRcyeWc 2024-06-01 08:50:52.822957692 + @@ -402,7 +402,7 @@ ___interceptor_setlocale@Base 14 ___interceptor_setpwent@Base 14 ___interceptor_setvbuf@Base 14 - ___interceptor_shmctl@Base 14 +#MISSING: 14.1.0-1# ___interceptor_shmctl@Base 14 ___interceptor_sigaction@Base 14 ___interceptor_sigaltstack@Base 14 ___interceptor_sigandset@Base 14 @@ -1579,7 +1579,7 @@ __interceptor_trampoline_setlocale@Base 14 __interceptor_trampoline_setpwent@Base 14 __interceptor_trampoline_setvbuf@Base 14 - __interceptor_trampoline_shmctl@Base 14 +#MISSING: 14.1.0-1# __interceptor_trampoline_shmctl@Base 14 __interceptor_trampoline_sigaction@Base 14 __interceptor_trampoline_sigaltstack@Base 14 __interceptor_trampoline_sigandset@Base 14 dh_makeshlibs: error: failing due to earlier errors I have uploaded the full gzipped build log in [2] since there were additional messages regarding symbols. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072327 > [2] http://people.debian.org/~glaubitz/gcc-14_14.1.0-1_x32.build.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1063735: python-maturin - upcoming rust-indexmap update.
Package: python-maturin Followup-For: Bug #1063735 Control: severity -1 serious Hello, I am setting the severity to serious now as this actually causes python-maturin to fails to build from source [1]: cargo generate-lockfile --offline error: failed to select a version for the requirement `indexmap = "^1.9.3"` candidate versions found which didn't match: 2.2.6 location searched: directory source `/usr/share/cargo/registry` (which is replacing registry `crates-io`) required by package `maturin v1.3.2 (/<>)` perhaps a crate was updated and forgotten to be re-vendored? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=python-maturin&arch=sparc64&ver=1.3.2-1&stamp=1717193660&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072328: gcc-14: Please add 32-bit SPARC (sparc) to ada_no_cpu
Source: gcc-14 Version: 14.1.0-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I am currently building a cross-compiler for 32-bit SPARC (sparc) and noticed that I had to disable Ada by adding "sparc" to "ada_no_cpu" in debian/rules.defs to get the compiler to build due to #1072071 [1]. Since I don't expect #1072071 to be fixed quickly, it would be good to just to add "sparc" to "ada_no_cpu" in debian/rules.defs. PS: Please note, this bug does not affect sparc64! There are no changes required for sparc64. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072071 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072327: gcc-14: Missing cargo build dependency on x32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, The gcc-14 source package is missing cargo as build dependency which is why the build currently fails with [1]: > configure: error: cargo is required to build rust cargo was briefly not available on x32, but is installable again. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=x32&ver=14.1.0-1&stamp=1715675531&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)
Hello, the suggested patch is incomplete as it breaks the installation of ptp-helper on architectures with Rust support by just removing it from the .install file. I have improved the patch in this regard by employing dh-exec and extended it for the remaining Debian Ports architectures without Rust support (alpha, m68k and sh4). I intentionally omitted ia64 as it will be dropped from Debian Ports within the next days. NB: For dh-exec to work, the file libgstreamer1.0-0.install *must* be executable. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gstreamer1.0-1.24.3/debian/changelog new/gstreamer1.0-1.24.3/debian/changelog --- old/gstreamer1.0-1.24.3/debian/changelog 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/changelog 2024-05-28 07:57:26.535826780 +0200 @@ -1,3 +1,9 @@ +gstreamer1.0 (1.24.3-1+ports) unreleased; urgency=medium + + * Disable rustc for unsupported architectures + + -- John Paul Adrian Glaubitz Tue, 28 May 2024 07:57:09 +0200 + gstreamer1.0 (1.24.3-1) unstable; urgency=medium * New upstream version 1.24.3 diff -Nru old/gstreamer1.0-1.24.3/debian/control new/gstreamer1.0-1.24.3/debian/control --- old/gstreamer1.0-1.24.3/debian/control 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/control 2024-05-28 11:16:10.247257446 +0200 @@ -6,6 +6,7 @@ Sjoerd Simons , Marc Leeman , Build-Depends: debhelper-compat (= 13), + dh-exec, dh-sequence-gir, meson (>= 0.62), pkgconf, @@ -18,7 +19,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!alpha !hppa !m68k !sh4], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, diff -Nru old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install --- old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-05-28 07:55:56.540429867 +0200 @@ -1,5 +1,6 @@ +#!/usr/bin/dh-exec usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper +[!alpha !hppa !m68k !sh4] usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale diff -Nru old/gstreamer1.0-1.24.3/debian/rules new/gstreamer1.0-1.24.3/debian/rules --- old/gstreamer1.0-1.24.3/debian/rules 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/rules 2024-05-28 09:39:31.503804282 +0200 @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),alpha hppa m68k sh4)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst
Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada
Source: gcc-13 Version: 13.2.0-25 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc) with Ada enabled. The build failed with a linker failure which indicates that linking against libatomic is required: checking float.h presence... yes checking for float.h... yes checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: undefined reference to `__atomic_compare_exchange_8' collect2: error: ld returned 1 exit status Such a patch already exists for armel [1], so it should be easy to extend it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected, linking against libatomic is therefore not required. Thanks, Adrian > [1] > https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
gt; https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html > > In general I thought that UEFI was derived from EFI, so I don't really > see, why both can't coexist together. But I might have to do further > research on that. Apart from that, ELILO is working perfectly fine both > for diskless boots and booting from disk. ELILO is unmaintained and has had various issues and bugs in the past which is why I switched to GRUB on Debian back then. But it also looks like that ia64 support is going to stay in GRUB for a while, I haven't seen any new efforts for removing it lately on the grub-devel mailing list. > > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual > >address space found on x86_64; > > Yes, it was done earlier than x86_64. > > > this causes problems with languages like > >JavaScript which use tagged pointers to encode type information in the > >bits unused on x86_64, see: > > > >> https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) > > > >(NB: This is expected to improve in the future as x86_64 optionally > > supports > > larger virtual address spaces in the kernel nowadays as well). > > > > - the math error handling ABI on ia64 in glibc is different from other > > architectures > >and the code for it in sysdeps/ia64/fpu/libm_error.c is quite > > convoluted; as glibc > >tries to unify and simplify FPU error handling, the different semantics > > of the ia64 > >ABI would require - quoting Adhemerval here - »a lot boilerplate and > > mechanical > >changes« which he doesn't think is worth the effort > > I think we could have done more in this regard, if ia64 support wouldn't > have been removed from Linux last year, requiring additional work > everywhere. But I don't complain, I think it also forced our hands. Well, I have done a lot of work in this regard in the past to get JavaScript fixed on targets with virtual address space sizes beyond 48 bits. But it's still not fixed everywhere, especially not in Qt5. It has been fixed in Qt6 though. > > There are probably more issues and quirks that I don't remember, but I > > think the list > > above already mentions enough show stoppers which mean that upstream > > projects won't be > > willing to re-add support for the architecture. > > Thanks for your assessment. I consider that much more useful than to > advise people against working on ia64. I'm not advising against you to do anything. You are free to spend your free time with whatever you want and if you think that keeping ia64 is worth the effort, more power to you! All I did was giving an elaborate explanation why ia64 is going to be removed from Debian within the next days and why I personally think it's a lost cause. > > Of course, I am not going to stop you from continuing your work and I think > > such efforts > > are always laudable. I just don't think the very limited interest in this > > architecture > > will be enough to overcome the difficulties that ia64 maintainers have to > > face. > > > > This is also the reason why the ia64 maintainers of neither Debian nor > > Gentoo were against > > the removal of support for the architecture in Ruby, the Linux kernel, > > glibc and so on. > > Being not against something and taking care of something are two > different things. But why would maintainers start an argument with upstream developers over something they don't really care about? That makes no sense. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
Hello Frank, On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote: > > ia64 support has been removed from glibc, the Linux kernel and soon gcc, > > First - ia64 support was actually removed from the glibc **because** it > was removed from Linux. It was also removed because there was no maintainer for it in glibc and suffered from a lot of testsuite failures. I tried for a long time to convince Adhemerval to fix these issues, but he explained that it would involve rewriting large parts of the math code for ia64 which he thought wasn't worth the effort. > Second, how did you come to the conclusion that ia64 support will be > removed from the gcc soon? gcc usually drops support for a target when it's no longer present in the kernel and glibc. That happened in the past and that will happen in the future, although there are some targets like Blackfin, CRIS and M32R that are still supported by gcc while being dropped by the kernel. And since ia64 support has already been marked as deprecated, I expect it to be removed from gcc soon. Especially, since ia64 adds a lot of complexity to gcc due to its VLIW design. > Rene said he would step up as maintainer for ia64 in gcc - see the > thread at [1] - and I haven't heard any different since then. > > [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html > > @Rene: Can you confirm? As of now, gcc is still marked as deprecated: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273 > > so it will be removed within the next weeks after we have made an archive > > copy. > > > > There is no need to fix any bugs on ia64. > > Let me correct that for you: > > There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as > that is. Have you already sorted out who is going to maintain ia64 support in glibc and the Linux kernel? And do you already know how to get Ruby upstream to re-add ia64 support? Ruby is required for a lot of other packages that depend on it. As someone who has been maintaining many exotic or deprecated architectures both in Debian and in the Linux kernel, I know how much work it involves to keep a port alive and running. And since I have also maintained ia64 in the past and know about all the quirks and problems the port has, I think the possibility that the port will ever return upstream to the kernel, glibc and the Ruby interpreter is nearly zero. To summarize the known issues and quirks on ia64: - ia64 has two stacks growing in opposite directions making exception handling in languages like Ruby more complicated and requiring additional code, see: > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for IA64) - the VLIW design adds a lot of complexity to the compiler; when it was created, designers expected the design to be superior but it turned out that the implementation was more challenging than expected and left gcc with a lot of unresolved problems on ia64, see: > https://gcc.gnu.org/projects/ia64.html - ia64 comes with its own implementation of EFI which is not fully compatible with UEFI and requires additional support code; this was the main reason why some GRUB developers wanted to get rid of ia64 support, see: > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual address space found on x86_64; this causes problems with languages like JavaScript which use tagged pointers to encode type information in the bits unused on x86_64, see: > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) (NB: This is expected to improve in the future as x86_64 optionally supports larger virtual address spaces in the kernel nowadays as well). - the math error handling ABI on ia64 in glibc is different from other architectures and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as glibc tries to unify and simplify FPU error handling, the different semantics of the ia64 ABI would require - quoting Adhemerval here - »a lot boilerplate and mechanical changes« which he doesn't think is worth the effort There are probably more issues and quirks that I don't remember, but I think the list above already mentions enough show stoppers which mean that upstream projects won't be willing to re-add support for the architecture. Of course, I am not going to stop you from continuing your work and I think such efforts are always laudable. I just don't think the very limited interest in this architecture will be enough to overcome the difficulties that ia64 maintainers have to face. This is also the reason why the ia64 maintainers of neither Debian nor Gentoo were against the removal of support for the architecture in Ruby, the Linux kernel, glibc
Bug#970043: Request to help test ia64 build for galera-4
Hi Otto, On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote: > I have a patch to tentatively fix Debian package galera-4 builds on > ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 > > Would anybody be interested in helping out and testing if the build > fully passes now? > > Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 ia64 support has been removed from glibc, the Linux kernel and soon gcc, so it will be removed within the next weeks after we have made an archive copy. There is no need to fix any bugs on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071542: boost1.83: Please enable context library on ppc64
Source: boost1.83 Version: 1.83.0-2.1+b1 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, the context library is not being installed on ppc64 in debian/control despite being enabled in debian/rules. Please add ppc64 to the list of supported architectures for the context library and make sure it's actually being built and installed. Tests can be performed on the porterbox perotto.debian.net. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071524: git: Please add patch to fix testsuite on sparc64
Source: git
Version: 1:2.45.1-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Hello,
the attached patch fixes the Git testsuite on sparc64. I've already
sent it upstream [1]. Could you include it for the next package
upload?
Thanks,
Adrian
> [1]
> https://lore.kernel.org/git/2024052009.99882-1-glaub...@physik.fu-berlin.de
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From 6580fdb9004e2d61fcb3d1f04c31bc7e328ed442 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Mon, 20 May 2024 13:03:49 +0200
Subject: [PATCH] chainlint.pl: Extend regexp pattern for /proc/cpuinfo on
Linux SPARC
On SPARC systems running Linux, individual processors are denoted with
"CPUnn:" in /proc/cpuinfo instead of the usual "processor NN:" so that
the current regexp in ncores() returns 0. Extend the regexp to match
lines with "CPUnn:" as well to properly detect the number of available
cores on these systems.
Signed-off-by: John Paul Adrian Glaubitz
---
t/chainlint.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/chainlint.pl b/t/chainlint.pl
index 556ee91a15..63cac942ac 100755
--- a/t/chainlint.pl
+++ b/t/chainlint.pl
@@ -718,7 +718,7 @@ sub ncores {
# Windows
return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
# Linux / MSYS2 / Cygwin / WSL
- do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';
+ do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:||^CPU[\d]*:/, <>)); } if -r '/proc/cpuinfo';
# macOS & BSD
return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
return 1;
--
2.39.2
Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down
Hello, On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on arm64. > (...) > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240420&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. FWIW, I am already working on updating the kiwi package in Debian to the latest upstream version. However, I ran into some testsuite issues that need to be sorted out upstream first [1]. Thanks, Adrian > [1] https://github.com/OSInside/kiwi/issues/2548 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1054109: ocaml: lack of LoongArch support
Hi LiXing, > [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)] I'm afraid this patch is way too large to be included in a Debian package. Please make sure these changes are being upstreamed, so that native LoongArch support will be part of the next major Ocaml upstream release in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)
On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote: > Hi, > > [John Paul Adrian Glaubitz 2020-05-10] > > I would like to adopt this package. There is a new upstream available and > > the > > repository has been moved to Github with some recent activity [1]. > > What came out of this intent? > > I just migrated the package to a git repository on > https://salsa.debian.org/debian/unadf >. I started working on this, but I got stuck because of the fact that the upstream package is actually not just unadf but a whole library that might need different treatment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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&arch=powerpc&ver=0.1.0.5-1%2Bb1&stamp=1713046430&raw=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&arch=powerpc&ver=6.4.2-11&stamp=1705003199&raw=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 --li
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&arch=powerpc&ver=16.1%2Bdfsg1-3%2Bb1&stamp=1710500596&raw=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 arch
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&ver=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&suite=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&arch=sparc64&ver=1.70.0%2Bdfsg1-5&stamp=1705412917&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
