Re: Linux kernel stability fixes for older SPARCs
_probe+0xb8/0x2e0 > [ +0.11] [<00896f04>] driver_probe_device+0x24/0xe0 > [ +0.07] [<00897104>] __driver_attach+0x64/0x120 > [ +0.07] [<00894c10>] bus_for_each_dev+0x50/0xa0 > [ +0.07] [<00895d3c>] bus_add_driver+0x17c/0x1e0 > [ +0.06] [<008979d4>] driver_register+0x74/0x120 > [ +0.08] [<0151ab90>] sunsu_init+0x170/0x1d4 > [ +0.09] [<00427bf4>] do_one_initcall+0x34/0x220 > [ +0.08] [<014f8fb4>] kernel_init_freeable+0x210/0x274 > [ +0.12] [<00b3c1bc>] kernel_init+0x18/0x13c > > On 6.6, I also found these messages in the kernel log (but apparently no > negative consequences): > > [ +0.371437] Kernel unaligned access at TPC[4ea294] load_module+0xff4/0x1c60 > [ +0.091825] Kernel unaligned access at TPC[4ea294] load_module+0xff4/0x1c60 > [ +0.091734] Kernel unaligned access at TPC[4ea294] load_module+0xff4/0x1c60 > [ +0.091763] Kernel unaligned access at TPC[4ea294] load_module+0xff4/0x1c60 > [ +0.091757] Kernel unaligned access at TPC[4ea294] load_module+0xff4/0x1c60 > [ +0.252176] log_unaligned: 4200 callbacks suppressed > [ +0.055120] Kernel unaligned access at TPC[4e75e0] cmp_name+0x0/0x20 > [ +0.23] Kernel unaligned access at TPC[4e75e0] cmp_name+0x0/0x20 > [ +0.09] Kernel unaligned access at TPC[4e75e0] cmp_name+0x0/0x20 > [ +0.09] Kernel unaligned access at TPC[4e75e0] cmp_name+0x0/0x20 > > > Conclusion: > > It looks very much like it isn't specifically a kernel bug at all, but either > something > wrong with the Debian kernel config, or with newer gcc versions. I still think it's a kernel bug. > I will test some other gcc versions next. > > Unfortunately, I couldn't test the config from the Debian > linux-image-6.10.7-sparc64-smp package. > Trying to build a kernel with this config produced a 700MB package, and the > resulting initrd was > too large to fit into my boot partition. Is there something special about how > Debian builds kernel packages? It's probably due to CONFIG_DEBUG_INFO. Try turning that off. Debian builds the kernel with debug symbols enabled and then runs the strip command afterwards. This way both a debug and a standard kernel package can be provided from the same build. 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-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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
Re: Linux kernel stability fixes for older SPARCs
Hi Gregor, On Wed, 2024-09-04 at 01:22 +0200, Gregor Riepl wrote: > > > > It's actually pretty simple these days as the kernel.org mirrors provide > > binary > > distributions of freestanding toolchains for all major supported > > architectures > > of the Linux kernel. > > > > To set up on any x86_64 machine, do the following: > > > > # wget > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/14.2.0/x86_64-gcc-14.2.0-nolibc-sparc64-linux.tar.gz > > # tar xf x86_64-gcc-14.2.0-nolibc-sparc64-linux.tar.gz > > # export PATH=$PATH:$PWD/gcc-14.2.0-nolibc/sparc64-linux/bin/ > > # git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > # cd linux > > # export ARCH=sparc > > # export CROSS_COMPILE=sparc64-linux- > > # make sparc64_defconfig > > # make -j > > > > The cross-compiled kernel will be available as "vmlinux". > > Very good, thanks! Thanks for looking into it! I'm especially interested in finding a proper reproducer which would make the bisecting process much easier. So far, the crashes seem to be rather random although they mainly occur with newer kernels. FWIW, I found a very handy patch yesterday which could help debugging these crashes once it's been merged into the upstream kernel [1]. What it does is that it dumps the back of the stack after a stack corruption has occurred which should in theory help find what part of the kernel is responsible for the stack corruption. It looks like this particular crash we have been seeing on the older SPARCs was always due to stack corruption which could mean that it's related to a driver or arch-specific code that is used on the older SPARCs but not on the newer machines. Adrian > [1] https://lore.kernel.org/lkml/20231219032254.96685-1-feng.t...@intel.com/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linux kernel stability fixes for older SPARCs
Hi Gregor, On Tue, 2024-09-03 at 19:19 +0200, Gregor Riepl wrote: > > > If you have issues to bi-sect just let us know for any arch. Given T2’s > > > cross-compile > > > support and I have most hardware in my museum now, I can usually bisect > > > issues > > > within a day or two. > > > > I don't have issues with bisecting, I'm just rather time-constrained at the > > moment, so > > I'm always happy when someone else can step in and help. Would be great to > > get this issue > > fixed upstream. > > My Ultra 10 and Fire V215 are desperately waiting for a more stable kernel. > I actually wanted to offer help with bisecting, but kept back due to a lack > of time and also suitable build system (compiling kernels is so > time-consuming). Any help is welcome ;-). > I may have some time to do test runs next week. > Could you give me some quick starters for setting up a kernel cross build env > on > an amd64 machine, or maybe access to a Sun box I could use? It's actually pretty simple these days as the kernel.org mirrors provide binary distributions of freestanding toolchains for all major supported architectures of the Linux kernel. To set up on any x86_64 machine, do the following: # wget https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/14.2.0/x86_64-gcc-14.2.0-nolibc-sparc64-linux.tar.gz # tar xf x86_64-gcc-14.2.0-nolibc-sparc64-linux.tar.gz # export PATH=$PATH:$PWD/gcc-14.2.0-nolibc/sparc64-linux/bin/ # git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # cd linux # export ARCH=sparc # export CROSS_COMPILE=sparc64-linux- # make sparc64_defconfig # make -j The cross-compiled kernel will be available as "vmlinux". Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linux kernel stability fixes for older SPARCs
Hello Rene, On Tue, 2024-09-03 at 11:09 +0200, René Rebe wrote: > > according to these posts [1][2] by Iggi, you figured out the stability > > problem > > No, we are just sometimes lucky it run that long stable. I was only made aware > recently that sun4u was not 100% and my fasted UltraSPARC until some year ago > was only a 360MHz Ultra5 until I was donated a Sun Blade 1000 recently. I see > some MM corruption that I wanted to hunt next. Hmm, ok. I was under the impression that you made some changes that made the kernel on Iggi's machine stable. Currently, the kernel crashes randomly on older SPARCs such as reported by Iggi: > https://x.com/Iggi76123640/status/1827658841581896152 > > with newer kernels on older SPARC machines. There has been a regression on > > older > > SPARCs since around kernel 4.19.x which I haven't gotten around to > > bisecting yet. > > Happy to bi-sect. I guess you mean random memory corruption I see or anything > else? Not sure what the underlying issue is, but the kernel just crashes completely. > If you have issues to bi-sect just let us know for any arch. Given T2’s > cross-compile > support and I have most hardware in my museum now, I can usually bisect issues > within a day or two. I don't have issues with bisecting, I'm just rather time-constrained at the moment, so I'm always happy when someone else can step in and help. Would be great to get this issue fixed upstream. > > If you've found and fixed the bug in question, it would be great if you > > could share > > your fix with the community and maybe whip up a kernel patch to fix the bug > > upstream. > > > Of course - all patches are always nicely sorted in our public and nicely > readable > SVN tree in any case. > > https://t2linux.com Is there a web view available? I'm not really a big fan of SVN, to be honest. > > Newer SPARCs are not affected by this bug, although there are other issues. > > You mean sun4v? I found a cheap T4-1 some month ago, and T2/Linux appears > to run stable on that. Any list of issues w/ sun4v I should be aware of? Linux runs mostly stable on sun4v, but there are filesystem corruption issues when you run Linux inside an LDOM on Solaris 11.3 and 11.4 even with the latest SRU of Solaris. These happen rarely, but they do occur and they are quite annoying as they mandate rebooting the LDOM as the root filesystem is mounted read-only and the filesystems as errors afterwards. It seems to be a bug in the LDOM vdisk driver (drivers/block/sunvdc.c). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Linux kernel stability fixes for older SPARCs
Hi Rene, according to these posts [1][2] by Iggi, you figured out the stability problem with newer kernels on older SPARC machines. There has been a regression on older SPARCs since around kernel 4.19.x which I haven't gotten around to bisecting yet. If you've found and fixed the bug in question, it would be great if you could share your fix with the community and maybe whip up a kernel patch to fix the bug upstream. Newer SPARCs are not affected by this bug, although there are other issues. Thanks, Adrian > [1] https://x.com/Iggi76123640/status/1828396228444389600 > [2] https://x.com/Iggi76123640/status/1828673611080589641 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Ultra 45/Debian 12 stuck at language selection while install
Hello, On Sun, 2024-08-25 at 12:58 +0200, Ignacio Soriano Hernandez wrote: > thanks for the updated ISO. So took some hours this morning to do testing on > the dual Ultra 45. > > 1). So no change wrt to being able to install at the console with USB > kbd/mouse attached. Same behavour as before, kbd input ignored. Did you check whether your USB controller is actually supported by the Linux kernel? > 2). Switched to input and ouput-device ttya. Installer works (used the > tu-dresden mirror as > the default one has basically no sparc64 packages and I wanted the default > desktop). The default mirror for Debian Ports is http://ftp.ports.debian.org/ and, of course, it has all the packages for sparc64. Not sure what you were seeing there, it might be related to a recent change to the choose-mirror package. > 3). Reboot went once through and while trying to add some further packages > (build-essential, ssh) it crashed (ssh)) > 4). Connected USB kbd/mouse and switched back to input and output-device > keyboard screen and it crashes with the USB errors. Yeah, the Linux kernel is buggy on older SPARCs. No one has ever bisected this problem though, unfortunately. I do actually own an Ultra 45 and I have long wanted to do the bisecting myself, but I haven't gotten around to doing it. If we want to make Linux work on older SPARCs, we actually need more people join the efforts. FWIW, Linux runs without issues on the sun4v machines such as the SPARC T4. If you want, you can just install the last 4.19 kernel which is known to be stable on the older SPARCs: # wget https://snapshot.debian.org/archive/debian-ports/20190719T183113Z/pool-sparc64/main/l/linux/linux-image-4.19.0-5-sparc64-smp_4.19.37-6_sparc64.deb # dpkg -i linux-image-4.19.0-5-sparc64-smp_4.19.37-6_sparc64.deb Then boot into 4.19.0-5. > I have attached links to the screenshots .. so the SMP stuff could be an > issue, the USB surely seems to very very pitty and specific to these machines. > > https://ibb.co/2W4rY2J > https://ibb.co/Jzc2L9R > https://ibb.co/qyMLDTq > https://ibb.co/5jB5RzG > https://ibb.co/b6833bK > > I would now try on the Ultra 25 with an XVR-300 to see this one works better. Good luck. PS: Please keep the discussion on the list. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Ultra 45/Debian 12 stuck at language selection while install
Hello Iggi, On Sat, 2024-08-24 at 17:25 +0200, Ignacio Soriano Hernandez wrote: > Wanted to once again try Debian 12 on my Sun Ultra 45 (XVR-2500, USB > kbd/mouse) and at > the language selection screen it is stuck (well no kbd input) because i can > push the > power buttom and it powers down. I just created a fresh installation image for you for sparc64 using the latest kernel: > https://cdimage.debian.org/cdimage/ports/tests/sparc64-20240824/debian-12.0.0-sparc64-NETINST-1.iso Please give it a try. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: 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
Re: 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
Re: 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
Re: Failures attempting to install in an LDOM
Hi Peter, On Tue, 2024-06-11 at 10:52 +0100, Peter Tribble wrote: > Sadly, that one fails as well. OK, then my memory was incorrect. > I had repeated unpack failures - debootstrap really doesn't like unpacking > util-linux. And software > installation eventually failed with > > Jun 11 08:34:09 debootstrap: Errors were encountered while processing: > Jun 11 08:34:09 debootstrap: vim-tiny > Jun 11 08:34:10 debootstrap: dpkg: dependency problems prevent configuration > of vim-tiny: > Jun 11 08:34:10 debootstrap: vim-tiny depends on vim-common (= > 2:9.0.2087-1); however: > Jun 11 08:34:10 debootstrap: Versio > Jun 11 08:34:10 debootstrap: n of vim-common on system is 2:9.0.2103-1. Yeah, that's a common problems and occurs whenever vim fails to build on sparc64, I have explained the reason behind this here: > https://lists.debian.org/debian-sparc/2017/12/msg00060.html > However, the very latest snapshot from > https://cdimage.debian.org/cdimage/ports/snapshots/2024-02-25/ > does install successfully: > > $ uname -a > Linux debian-sparc 6.8.12-sparc64-smp #1 SMP Debian 6.8.12-1 (2024-05-31) > sparc64 GNU/Linux That's great to hear. I hope the Linux LDOM will enable you fix some SPARC-related upstream bugs ;-). Let me know if you have any more questions, I'm happy to help! 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-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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
Re: Failures attempting to install in an LDOM
Hi Peter, On Mon, 2024-06-10 at 15:37 +0100, Peter Tribble wrote: > I finally got round to trying to install debian-sparc in an LDOM on my T4 > server. > > Sadly, this didn't work. > > With Debian 12, software installation fails. I see > > Jun 10 08:43:02 in-target: The following packages have unmet dependencies: > Jun 10 08:43:03 in-target: console-setup-linux : Depends: > keyboard-configuration (= 1.220) but 1.227 is installed > > along with some unrelated dpkg-deb segfaults. Ignoring that, the bootloader > won't install. > > With Debian 10, it appears that software installation succeeds, but again > the bootloader fails to install. > > Is there a known-to-work set of instructions available that would get me > closer to a working install? Which image did you use? You might have caught a broken image. The problem with Debian Ports is that the images are generated from Debian unstable, so there is always a chance of downloading an image that is broken. This one should work: > https://cdimage.debian.org/cdimage/ports/snapshots/2023-11-17/debian-12.0.0-sparc64-NETINST-1.iso Adrian -- .''`. 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-sparc@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sparc@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#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada
Source: gcc-13 Version: 13.2.0-25 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sparc@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#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-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@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
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hi Peter, On Fri, 2024-05-10 at 12:07 +0100, Peter Tribble wrote: > Tribblix is built from the last commit that worked (November 2021), with any > relevant changes > since cherry-picked on top. So in terms of timeline Tribblix is contemporary > with 11.4, with > hardware support matching the original Solaris 11 release. Thanks, good to know! And thanks a lot for your efforts! > But we're well into the second decade since the fork, so there's enough > divergence that illumos > and Solaris are really different, even if some of what you see looks very > similar. > > (And illumos on SPARC uses gcc4 to build the kernel [!], although > applications on Tribblix use gcc7. > Given the target market, having the latest and greatest toolchains isn't the > highest priority.) Well, at some point you will run into code that won't build with that old toolchain anymore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
On Fri, 2024-05-10 at 12:14 +0200, Richard Biener wrote: > > Because I wasn't subscribed to gcc-patches and I'm also only subscribed now > > without receiving messages due to the large message volume on this list. > > https://gcc.gnu.org/gcc-13/changes.html > > > The problem with announcements on developer mailing lists is usually that > > they > > usually don't reach any users. I was made aware of this change only when I > > checked about the recent changes to GCC Git. > > Where do you expect such announcement then? That's a difficult question, to be honest. From a user perspective, it's hard to track these upstream announcements. I would argue that most users don't follow all such changes in the upstream projects they are using and, to be honest, I really wouldn't have expected that Solaris 11.3 would be considered obsolete. If it had been for Solaris 7, 8 or 9, I would totally understand. But even Solaris 10 is something that Oracle still supports [1]. Adrian > [1] > https://blogs.oracle.com/support/post/extended-support-for-oracle-solaris-10-operating-system -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hello Rainer, On Fri, 2024-05-10 at 10:20 +0200, Rainer Orth wrote: > > > Support for Solaris 11.3 had already been obsoleted in GCC 13. However, > > > since the only Solaris system in the cfarm was running 11.3, I've kept > > > it in tree until now when both Solaris 11.4/SPARC and x86 systems have > > > been added. > > > > > > This patch actually removes the Solaris 11.3 support. > > > > I'm not sure I like this change since Solaris 11.3 is the last version of > > Solaris supported by a large number of SPARC systems. > > > > Oracle unfortunately raised the hardware baseline with Solaris 11.4 such > > that every system older than the SPARC T4 is no longer supported by 11.4 > > while 11.3 still runs perfectly fine on these machines. > > I wonder why you didn't raise your concerns 1 1/2 years ago when I > announced the obsoletion of Solaris 11.3 support? Because I wasn't subscribed to gcc-patches and I'm also only subscribed now without receiving messages due to the large message volume on this list. The problem with announcements on developer mailing lists is usually that they usually don't reach any users. I was made aware of this change only when I checked about the recent changes to GCC Git. > > While Oracle does no longer provide feature updates to Solaris 11.3, there > > is still LTSS security support so that users still receive security updates > > so that their systems are continued to be protected against vulnerabilities. > > The Solaris 11.3 ESUs (Extended Support Updates) are available at a > premium only, and just contain the bare minimum of security updates, > often 6 to 9 month in between. That's not an argument for throwing away hardware that still works perfectly fine and that still has some users. > > I think Solaris 11.3 support should be kept since the resulting code removal > > is not that large that it would justify dropping support for such a large > > userbase. > > Do you have any indication on the size of the userbase? I seriously > doubt it's large beyond some hobbyists that keep the old hardware > running. I don't have the exact numbers, no. But I know there are many users out there with pre-11.4 hardware that they still use. As you may know, there are no 11.4 SPARC desktop systems and most 11.4-capable hardware is usually very expensive. > You also seem to forget that my GCC (and LLVM) Solaris support work is > purely voluntary, done in my spare time. Not sure what makes you think so. I'm perfectly aware of the fact that lots of people do this work in their spare time as this applies to me as well. I'm not getting paid for my Debian work, my kernel maintenance and all the other stuff that I'm doing either. That doesn't mean users are not allowed to ask me questions or send me comments about my work. > Keeping Solaris 11.3 support working would be much more than restoring > the removal patch: > > * For each and every of my Solaris patches, I'd have to investigate if > it works on 11.3 or needs adjustments and workarounds. > > * I'd also need to regularly test the result to keep things working. > > I honestly don't have the time or the energy to do this, nor the > hardware required for testing Besides, I have too much on my plate > already, and rather spend it on more beneficial work. Does Solaris support in GCC really change that often that the necessary tests cannot be run by volunteers? I'd be happy to test changes for Solaris 11.3 which can be installed inside an LDOM. > Above all, I always wonder why people insist on running ancient hardware > with an almost-unsupported OS, but require a bleeding edge version of > GCC. What's wrong with continuing to use GCC 13 (or even 14, although I > haven't tested that on Solaris 11.3) instead? You could also ask why people use operating systems other than Linux and architectures other than x86_64. I don't think you will get a satisfactory answer to that question. > > Removing Solaris 11.3 support might make sense in the future when SPARC > > support in Illumos has matured enough that people can switch over their > > machines. > > As has been noted, SPARC is on its way out for Illumos. Which makes my point to keep Solaris 11.3 support even more valid. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [COMMITTED] Remove obsolete Solaris 11.3 support
Hello Rainer, > Support for Solaris 11.3 had already been obsoleted in GCC 13. However, > since the only Solaris system in the cfarm was running 11.3, I've kept > it in tree until now when both Solaris 11.4/SPARC and x86 systems have > been added. > > This patch actually removes the Solaris 11.3 support. I'm not sure I like this change since Solaris 11.3 is the last version of Solaris supported by a large number of SPARC systems. Oracle unfortunately raised the hardware baseline with Solaris 11.4 such that every system older than the SPARC T4 is no longer supported by 11.4 while 11.3 still runs perfectly fine on these machines. While Oracle does no longer provide feature updates to Solaris 11.3, there is still LTSS security support so that users still receive security updates so that their systems are continued to be protected against vulnerabilities. I think Solaris 11.3 support should be kept since the resulting code removal is not that large that it would justify dropping support for such a large userbase. Removing Solaris 11.3 support might make sense in the future when SPARC support in Illumos has matured enough that people can switch over their machines. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: gcc compile farm machines down?
Hello, On Mon, 2024-04-29 at 22:09 +0100, Mark Cave-Ayland wrote: > Someone mentioned to me that the SPARC gcc compile farm machines are down, > which > means getting access to real hardware to test patches for QEMU is proving to > be tricky. > > Does anyone know what the current status of these machines is, or if there > are any > alternatives available? The old SPARC T5 porterbox died due to hardware issues and so far we have been unable to replace it. I don't have any possibilities to host a SPARC server for that, however Zach van Rijn (CC'ed) is planning to help replace the T5 with a working one. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: 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#1065132: rakudo: Please allow build on any architecture
Source: rakudo Version: 2022.12-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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#1063937: glibc: Please add workaround to fix posix_spawn() on sparc64
Source: glibc Version: 2.37-15 Severity: important Tags: patch User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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)
Re: xserver-xorg-video-sunffb oudated
Hi Gregor, On Fri, 2024-02-02 at 12:46 +0100, Gregor Riepl wrote: > Work was stalled previously, because the package was broken and stopped > building with newer Xorg releases. The Xorg team was also reluctant to > introduce a maintainer-fixed package that is only relevant for one > Debian ports architecture. I think this should no longer be an issue if > upstream is working on it. Adrian Bunk has reintroduced several legacy X.Org drivers that Debian's X.Org team previously removed and it was not a problem at all. Since you're going to be the maintainer, there is no additional burden to Debian's X.Org team. Let me know when you have something to review. Adrian
Re: xserver-xorg-video-sunffb oudated
Hi Gregor, On Thu, 2024-02-01 at 07:57 +0100, Gregor Riepl wrote: > Just wanted to point out that I forked and patched the Salsa repo a while > ago: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb > > Unfortunately, I couldn't get it reintroduced, not even into Debian ports. > If the project is still alive upstream, chances are a bit higher, I think. > I still have two of these cards lying around. I can review and sponsor the package for you, I wasn't aware that you had a package ready. 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-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@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
New LLVM buildbot for SPARC online
Hello! I'm happy to announce that the LLVM buildbot for SPARC is back in service on much faster and newer hardware. Previously, the buildbot was running on an SPARC T5120 with an 8-core T2 CPU clocked at 1.2 GHz. The new buildbot is based on an 8-core SPARC T4-1 clocked at 2.85 GHz, so it should be quite faster. Thanks to Alex Perez for providing the hardware and Palle Lyckegaard for helping with the setup, especially with figuring out the NAT setup. Once the build results have stayed green for a longer time indicating a successful build, I will ask the LLVM buildbot master maintainers to move the buildbot out of the staging area. Adrian > [1] https://lab.llvm.org/staging/#/builders/159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1059703: binutils: Please drop nocheck override for powerpc and sparc64
Source: binutils Version: 2.41.50.20231227-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! The debian/rules file for binutils currently overrides the nocheck build option with the following code snippet: ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) # override buildd admins to run the testsuite anyway ... ifeq (,$(filter $(DEB_HOST_ARCH), m68k powerpc sh4 sparc64)) with_check := disabled through DEB_BUILD_OPTIONS endif endif Since both the powerpc and sparc64 buildds don't build with "nocheck" there is no need to override it. It only annoys porters when they want to build binutils locally with the testsuite disabled. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64
Hi Ilias! On Thu, 2023-11-16 at 20:23 +0200, Ilias Tsitsimpis wrote: > Thanks for working on this. I fear that applying this patch will change > the ABI for Cabal, and hence we will have to rebuild every Haskell > package in Debian. Because of that, I plan on waiting for the current > transition to finish, and then include this patch in the next GHC > upload. Are you sure that this actually the case [1]? Adrian > [1] https://github.com/haskell/cabal/pull/9445#issuecomment-1811780089 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057390: openjdk-21: Please add patch to support SPARCV9
Source: openjdk-21
Version: 21.0.1+12-2
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
The attached patch adds SPARCV9 support to OpenJDK. It has been successfully
tested against OpenJDK 21 on stadler.debian.net. I will use this patch now
to build openjdk-21 and upload to unreleased.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index:
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/Architecture.java
===
---
openjdk-21-21.0.1+12.orig/src/java.base/share/classes/jdk/internal/util/Architecture.java
+++
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/Architecture.java
@@ -50,6 +50,7 @@ public enum Architecture {
IA64,
M68K,
SH,
+SPARCV9,
X32,
PPC,
MIPSEL,
@@ -171,6 +172,15 @@ public enum Architecture {
}
/**
+ * {@return {@code true} if the current architecture is SPARCV9}
+ * Use {@link #isLittleEndian()} to determine big or little endian.
+ */
+@ForceInline
+public static boolean isSPARCV9() {
+return PlatformProps.TARGET_ARCH_IS_SPARCV9;
+}
+
+/**
* {@return {@code true} if the current architecture is M68K}
* Use {@link #isLittleEndian()} to determine big or little endian.
*/
Index: openjdk-21-21.0.1+12/test/jdk/jdk/internal/util/ArchTest.java
===
--- openjdk-21-21.0.1+12.orig/test/jdk/jdk/internal/util/ArchTest.java
+++ openjdk-21-21.0.1+12/test/jdk/jdk/internal/util/ArchTest.java
@@ -41,6 +41,7 @@ import static jdk.internal.util.Architec
import static jdk.internal.util.Architecture.IA64;
import static jdk.internal.util.Architecture.PPC;
import static jdk.internal.util.Architecture.SH;
+import static jdk.internal.util.Architecture.SPARCV9;
import static jdk.internal.util.Architecture.X32;
import static jdk.internal.util.Architecture.M68K;
import static jdk.internal.util.Architecture.MIPSEL;
@@ -93,6 +94,7 @@ public class ArchTest {
case "m68k" -> M68K;
case "ppc" -> PPC;
case "sh" -> SH;
+case "sparcv9" -> SPARCV9;
case "x32" -> X32;
default -> OTHER;
};
@@ -121,6 +123,7 @@ public class ArchTest {
Arguments.of(HPPA, Architecture.isHPPA()),
Arguments.of(IA64, Architecture.isIA64()),
Arguments.of(SH, Architecture.isSH()),
+Arguments.of(SPARCV9, Architecture.isSPARCV9()),
Arguments.of(X32, Architecture.isX32()),
Arguments.of(PPC64, Architecture.isPPC64())
);
Index:
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
===
---
openjdk-21-21.0.1+12.orig/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
+++
openjdk-21-21.0.1+12/src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template
@@ -64,6 +64,7 @@ class PlatformProps {
static final boolean TARGET_ARCH_IS_MIPS64EL= "@@OPENJDK_TARGET_CPU@@" ==
"mips64el";
static final boolean TARGET_ARCH_IS_X32 = "@@OPENJDK_TARGET_CPU@@" ==
"x32";
static final boolean TARGET_ARCH_IS_SH = "@@OPENJDK_TARGET_CPU@@" ==
"sh";
+static final boolean TARGET_ARCH_IS_SPARCV9 = "@@OPENJDK_TARGET_CPU@@" ==
"sparcv9";
static final boolean TARGET_ARCH_IS_M68K= "@@OPENJDK_TARGET_CPU@@" ==
"m68k";
static final boolean TARGET_ARCH_IS_PPC = "@@OPENJDK_TARGET_CPU@@" ==
"ppc";
static final boolean TARGET_ARCH_IS_ALPHA = "@@OPENJDK_TARGET_CPU@@" ==
"alpha";
Re: Sun Ultra 25 / Debian 12 install/progress
Hi Connor! On Wed, 2023-11-29 at 21:51 +0100, Connor McLaughlan wrote: > just for reference, i was experiencing the same usb problem on my > Ultra 25 as mentioned here: > https://lists.debian.org/debian-sparc/2022/12/msg0.html > > So for newer kernels than 5.6.0 usb is dying during boot rendering > mouse and keyboard unusable on the machine. Bisecting this issue would be incredibly helpful. We could then notify the kernel developer who introduced the regression so they can provide a fix we can test. I assume it's a trivial fix. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057091: perl: FTBFS on sparc64 due to alignment issues
Source: perl Version: 5.36.0-10 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! src:perl currently fails to build from source on sparc64 due to an alignment issue which results in two testsuite failures: Failed 2 tests out of 2623, 99.92% okay. re/reg_mesg.t re/regex_sets.t This alignment issue has already been fixed upstream [1] and has also been backported to Perl 5.36.1. Thus, in order to fix this bug, it's enough to update the perl package to 5.36.1 or newer. Thanks, Adrian > [1] > https://github.com/Perl/perl5/commit/89d80cc9efb3eefc31aa62b32c9e745f8de6412f -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Control: retitle -1 'FTBFS on multiple architectures due to incorrect LD_LIBRARY_PATH' Control: tags -1 +patch Hi! On Tue, 2023-11-28 at 10:13 +0100, John Paul Adrian Glaubitz wrote: > --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 > +0200 > +++ qscintilla2-2.14.1+dfsg/debian/rules2023-11-28 10:12:29.317757619 > +0100 > @@ -46,7 +46,7 @@ > Python/build-%/configure-stamp: build-library-stamp > dh_testdir > cp -f Python/pyproject-qt5.toml Python/pyproject.toml > - cd Python && python$* /usr/bin/sip-build \ > + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* > /usr/bin/sip-build \ > --verbose --no-make --pep484-pyi \ > --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ > --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' > \ > @@ -59,7 +59,7 @@ > --qsci-library-dir $(CURDIR)/QSciQt5 > ifeq ($(qt6), "yes") > cp -f Python/pyproject-qt6.toml Python/pyproject.toml > - cd Python && python$* /usr/bin/sip-build \ > + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* > /usr/bin/sip-build \ > --verbose --no-make --pep484-pyi \ > --qmake /usr/bin/qmake6 \ > --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' > \ I can confirm that this patch fixes the problem for me. Attaching it as a file. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 +0200 +++ qscintilla2-2.14.1+dfsg/debian/rules 2023-11-28 10:12:29.317757619 +0100 @@ -46,7 +46,7 @@ Python/build-%/configure-stamp: build-library-stamp dh_testdir cp -f Python/pyproject-qt5.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ @@ -59,7 +59,7 @@ --qsci-library-dir $(CURDIR)/QSciQt5 ifeq ($(qt6), "yes") cp -f Python/pyproject-qt6.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/qmake6 \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \
Re: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Hi! Testing the following patch now which seems to work: --- qscintilla2-2.14.1+dfsg/debian/rules.orig 2023-07-22 20:17:16.0 +0200 +++ qscintilla2-2.14.1+dfsg/debian/rules2023-11-28 10:12:29.317757619 +0100 @@ -46,7 +46,7 @@ Python/build-%/configure-stamp: build-library-stamp dh_testdir cp -f Python/pyproject-qt5.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt5 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ @@ -59,7 +59,7 @@ --qsci-library-dir $(CURDIR)/QSciQt5 ifeq ($(qt6), "yes") cp -f Python/pyproject-qt6.toml Python/pyproject.toml - cd Python && python$* /usr/bin/sip-build \ + cd Python && LD_LIBRARY_PATH=$(CURDIR)/QSciQt6 python$* /usr/bin/sip-build \ --verbose --no-make --pep484-pyi \ --qmake /usr/bin/qmake6 \ --qmake-setting 'QMAKE_CXXFLAGS += "$(CXXFLAGS) $(CPPFLAGS)"' \ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: qscintilla2: FTBFS on hppa - LD_LIBRARY_PATH incorrectly set
Hi David! The issue exists on sparc64 as well [1] and I'm not quite sure why it does not seem to affect the release architectures: make[2]: Entering directory '/<>/Python/build-3.11/cfgtest_Qsci' sparc64-linux-gnu-g++ -c -pipe -g -O2 -ffile-prefix-map=/<>=. \ -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time \ -D_FORTIFY_SOURCE=2 -O2 -Wall -Wextra -D_REENTRANT -fPIC -DQSCINTILLA_DLL \ -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB \ -I. -I../../../QSciQt5 -I/usr/include/sparc64-linux-gnu/qt5 \ -I/usr/include/sparc64-linux-gnu/qt5/QtPrintSupport -I/usr/include/sparc64-linux-gnu/qt5/QtWidgets \ -I/usr/include/sparc64-linux-gnu/qt5/QtGui -I/usr/include/sparc64-linux-gnu/qt5/QtCore -I. \ -I/usr/lib/sparc64-linux-gnu/qt5/mkspecs/linux-g++ -o cfgtest_Qsci.o ../../config-tests/cfgtest_Qsci.cpp sparc64-linux-gnu-g++ -Wl,-z,relro -Wl,-O1 -o Qsci cfgtest_Qsci.o \ -L../../../QSciQt5 -L/usr/lib/sparc64-linux-gnu -lqscintilla2_qt5 /usr/lib/sparc64-linux-gnu/libQt5PrintSupport.so \ /usr/lib/sparc64-linux-gnu/libQt5Widgets.so /usr/lib/sparc64-linux-gnu/libQt5Gui.so \ /usr/lib/sparc64-linux-gnu/libQt5Core.so -lGL -lpthread make[2]: Leaving directory '/<>/Python/build-3.11/cfgtest_Qsci' /<>/Python/build-3.11/cfgtest_Qsci/./Qsci /<>/Python/build-3.11/cfgtest_Qsci/cfgtest_Qsci.out sip-build: '/<>/Python/build-3.11/cfgtest_Qsci/./Qsci' didn't create any output /<>/Python/build-3.11/cfgtest_Qsci/./Qsci: error while loading shared libraries: libqscintilla2_qt5.so.15: \ cannot open shared object file: No such file or directory Might be a race condition. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qscintilla2&arch=sparc64&ver=2.14.1%2Bdfsg-1&stamp=1701131767&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1056636: ghc: Please restore --disable-ld-override after build system switch
Hi! On Fri, 2023-11-24 at 09:34 +0100, John Paul Adrian Glaubitz wrote: > After the build system was switched from GNU Make to Hadrian, the configure > option --disable-ld-override was lost in the process but is still required > for previously affected architectures powerpc, powerpcspe and sparc64. I just realized that we're still calling the configure script. Thus, just removing the comment signs (#) in front of the section for disabling the linker override should fix the problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056636: ghc: Please restore --disable-ld-override after build system switch
Source: ghc Version: 9.4.7-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! After the build system was switched from GNU Make to Hadrian, the configure option --disable-ld-override was lost in the process but is still required for previously affected architectures powerpc, powerpcspe and sparc64. This became evident after building GHC on sparc64 and ld.gold segfaulted in the final stage when linking more than 600 object files which does not seem to be 100% on sparc64 (and 32-bit PowerPC). I will file a separate upstream bug report for binutils regarding that issue. I have not figured out yet what the proper option would be but looking at [1], it would be something like *.*.ghc.link.opts+=bla. I have already asked on the #ghc IRC channel for advise and will report back once I know more. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056570: openjdk-8: Please drop sparc64 from hotspot_archs for the time being
Source: openjdk-8 Version: 8u392-ga-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! The native code generator in openjdk-8 currently segfaults on sparc64 and prevents a successful build. Removing sparc64 from "hotspot_archs" in debian/rules restricts the build to Zero builds which fixes the build. Thus, please disable the native build on sparc64 for the time being until we have sorted out the regression. FWIW, I assume there was some change in the Hotspot code on sparc64 that was most likely implemented for the Solaris port only since the native Linux sparc64 port has been unmaintained in OpenJDK for quite some time. This has happened in the past before. I will try to bisect the problem later and report it upstream. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch upstream User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hi! As discussed in private, here is a patch which fixes the arch detection for sparc64 in cabal. Previously, cabal treated "sparc64" as an alias for 32-bit sparc which results in the GHC build process not being able to find the built binaries as these are stored in a $ARCH-$OS subfolder. The patch has already been pushed upstream, approved and should be merged within the next hours after some more waiting [1]. The attached patch is a backported version of the patch which applies to GHC 9.4.7. Thanks, Adrian > [1] https://github.com/haskell/cabal/pull/9445 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- ghc-9.4.6.orig/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs +++ ghc-9.4.6/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs @@ -158,19 +158,17 @@ buildOS = classifyOS Permissive System.I -- -- | These are the known Arches: I386, X86_64, PPC, PPC64, Sparc, --- Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, Rs6000, --- M68k, Vax, JavaScript and Wasm32. --- +-- Sparc64, Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, +-- Rs6000, M68k, Vax, JavaScript and Wasm32. -- The following aliases can also be used: --* PPC alias: powerpc --* PPC64 alias : powerpc64, powerpc64le ---* Sparc aliases: sparc64, sun4 --* Mips aliases: mipsel, mipseb --* Arm aliases: armeb, armel --* AArch64 aliases: arm64 -- data Arch = I386 | X86_64 | PPC | PPC64 | Sparc - | Arm | AArch64 | Mips | SH + | Sparc64 | Arm | AArch64 | Mips | SH | IA64 | S390| S390X | Alpha | Hppa| Rs6000 | M68k | Vax @@ -185,7 +183,7 @@ instance NFData Arch where rnf = generic knownArches :: [Arch] knownArches = [I386, X86_64, PPC, PPC64, Sparc - ,Arm, AArch64, Mips, SH + ,Sparc64 ,Arm, AArch64, Mips, SH ,IA64, S390, S390X ,Alpha, Hppa, Rs6000 ,M68k, Vax @@ -197,7 +195,6 @@ archAliases Strict _ = [] archAliases Compat _ = [] archAliases _ PPC = ["powerpc"] archAliases _ PPC64 = ["powerpc64", "powerpc64le"] -archAliases _ Sparc = ["sparc64", "sun4"] archAliases _ Mips= ["mipsel", "mipseb"] archAliases _ Arm = ["armeb", "armel"] archAliases _ AArch64 = ["arm64"] --- ghc-9.4.6.orig/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs +++ ghc-9.4.6/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs @@ -717,6 +717,7 @@ platformDefines lbi = PPC -> ["powerpc"] PPC64 -> ["powerpc64"] Sparc -> ["sparc"] + Sparc64 -> ["sparc64"] Arm -> ["arm"] AArch64 -> ["aarch64"] Mips-> ["mips"]
Re: Bug#1055884: ghc: Please update sparc-support patch to fix FTBFS on sparc64
Looks like this needs to be fixed in src:haskell-cabal. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1055884: ghc: Please update sparc-support patch to fix FTBFS on sparc64
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hi! src:ghc currently FTBFS on sparc64 since libraries/ghc-boot/GHC/Platform/ArchOS.hs is missing the architecture names for sparc and sparc64 [1]. I have therefore updated the sparc-support patch to address this and also opened a pull request upstream [2]. Can you update the patch for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=9.4.7-1&stamp=1699776000&raw=0 > [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11599 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: ghc-9.4.7/m4/ghc_convert_cpu.m4 === --- ghc-9.4.7.orig/m4/ghc_convert_cpu.m4 +++ ghc-9.4.7/m4/ghc_convert_cpu.m4 @@ -68,6 +68,12 @@ case "$1" in sh4) $2="sh4" ;; + sparc64*) +$2="sparc64" +;; + sparc*) +$2="sparc" +;; vax) $2="vax" ;; Index: ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 === --- ghc-9.4.7.orig/m4/fptools_set_haskell_platform_vars.m4 +++ ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 @@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V riscv64) test -z "[$]2" || eval "[$]2=ArchRISCV64" ;; -hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax) +hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax) test -z "[$]2" || eval "[$]2=ArchUnknown" ;; *) Index: ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs === --- ghc-9.4.7.orig/libraries/ghc-boot/GHC/Platform/ArchOS.hs +++ ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs @@ -38,6 +38,8 @@ data Arch | ArchPPC | ArchPPC_64 PPC_64ABI | ArchS390X + | ArchSPARC + | ArchSPARC64 | ArchARM ArmISA [ArmISAExt] ArmABI | ArchAArch64 | ArchAlpha @@ -124,6 +126,8 @@ stringEncodeArch = \case ArchPPC_64 ELF_V1 -> "powerpc64" ArchPPC_64 ELF_V2 -> "powerpc64le" ArchS390X -> "s390x" + ArchSPARC -> "sparc" + ArchSPARC64 -> "sparc64" ArchARM ARMv5 _ _ -> "armv5" ArchARM ARMv6 _ _ -> "armv6" ArchARM ARMv7 _ _ -> "armv7"
Re: Sun Ultra 25 / Debian 12 install/progress
Hi Iggi! On Fri, 2023-11-10 at 18:56 +, Ignacio Soriano Hernandez wrote: > so installed it with the latest image you had posted. It boots into the > login but USB is not supported, so only terminal. Can you post the output of "lsusb" and "lspci" so I can see what kind of USB controller your machine has? Maybe it's just disabled in the Debian kernel configuration. > What I was feeling is that even 5.16 is very unstable .. a simple apt > install openssh-server crashed the machine. Kernel after 4.19 were actually not very stable on older SPARCs like yours while there were no problems on the newer SPARCs like T2, T3, T4 and so on. Bisecting these kernel issues on my Ultra 45 is still on my TODO list. If you want to have a stable kernel, use this image from July 2019 and make sure you always boot the machine into kernel 4.19 from GRUB: > https://cdimage.debian.org/cdimage/ports/snapshots/2019-07-16/ > Btw. What is the recommended way of updating the keyring so that I could > install some further packages and a desktop? What it be possible to exit > to the shell within the installer to update the keyring so that it could > use the mirror to get the packages? You can download and install the keyring package like this: # wget http://ftp.ports.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb # dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb > Thanks a lot for your support. You're welcome and sorry for the current issues you're seeing. I haven't had time to work on Debian's sparc64 port for a while and only recently had the time to setup the two new SPARC T4-1 that we purchased for Debian. These machines are running now and I am currently going through all kind of packages which have regressed on sparc64 and I'm filing bug reports and sending patches upstream. Also, I am going to updated debian-installer images soon so you can test a more recent kernel. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New sparc64 porterbox available
Hi! After a long time since the previous sparc64 porterbox went offline since it had to move out of the data center at my old university, I am happy to announce that a new sparc64 porterbox is now available. The porterbox is a virtual machine (LDOM) hosted on a SPARC T4-1 with 96 GB of RAM and more than 500 GB of disk space (I hope we will be able to increase the available disk space in the near future). Hosting is kindly provided by Cononva Communications GmbH in Salzburg, Austria. I have already verified that creating a chroot works as expected and I could test-build a package without any issues, so I am confident it should work for everyone else. For questions and problems reports, please drop me an email or join #debian-ports on OFTC IRC network. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=stadler -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Sun Ultra 25 / Debian 12 install/progress
Hi Iggi!
On Thu, 2023-11-09 at 15:16 +0100, Ignacio Soriano Hernandez wrote:
> Loading Linux 6.5.0-4-sparc64 ...
> Loading initial ramdisk ...
>
> [ 0.721550] pci :05:1d.0: unsupported PM cap regs version (4)
> [ 7.135075] Unable to handle kernel paging request at virtual address
> 000406131004
> [ 7.230283] tsk->{mm,active_mm}->context = 0040
> [ 7.297222] tsk->{mm,active_mm}->pgd = fff211c3
> [ 7.365556] Unable to handle kernel paging request at virtual address
> 0004061110184000
> [ 7.460774] tsk->{mm,active_mm}->context = 003d
> [ 7.527753] tsk->{mm,active_mm}->pgd = fff211c04000
> [ 7.661424] Kernel panic - not syncing: corrupted stack end detected
> inside scheduler
> [ 7.761835] Press Stop-A (L1-A) from sun keyboard or send break
> [ 7.761835] twice on console to return to the boot prom
> [ 7.904298] ---[ end Kernel panic - not syncing: corrupted stack end
> detected inside scheduler ]---
>
> And this happens via the serial console, no USB devices connected.
Can you try an older image? I used an image from last year when I installed
Debian inside
two SPARC T4-1 LDOMs which I have freshly set up for Debian Ports:
> https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-24/debian-11.0.0-sparc64-NETINST-1.iso
I have seen some issue with most recent kernels on SPARC which is why I have
currently booted
one LDOM into kernel 5.16.14.
When you install with the image above, you will be able to boot into kernel
5.16.14 from GRUB.
Note: Due to the expired APT keys in the above image, you should skip the
mirror setup during
installation which will fail unless you installed the updated Debian
Ports Archive Keyring
package.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Sun Ultra 25 / Debian 12 install/progress
Hello Iggi, On Wed, 2023-11-08 at 11:09 +0100, Ignacio Soriano Hernandez wrote: > just a short heads-up because I did not find teh Ultra 25 on the list of > "supported" systems. We don't really have a list of supported systems, just systems that are known to work. > I wanted to give it a try and can confirm that it boots from CD and gets into > the "Select a > language" screen but the keyboard is not working. It should be working. Did you try connecting a PS/2 keyboard? Although USB should be working. > System: Sun Ultra 25, 1 GB RAM, 250 GB SATA, XVR-300, kbd/mouse connected to > the USB ports > > I will try a serial install once I find the adaptor. Good luck. Let me know if you run into any other issues. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Installing Debian - Sun Ultra1
Hi Jeremy! On Wed, 2023-10-11 at 16:01 -0400, Jeremy Leonard wrote: > [ 10.116921] Initramfs unpacking failed: write error > (...) > Where should I look to start resolving this? Your problem is the failed attempt to unpack the initramfs and apparently the problem is that it's failing to write the unpacked data somewhere. Might be a problem with bad or insufficient memory. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1052142: ghc: Please add patch to restore minimal build support for sparc and sparc64
Source: ghc Version: 9.4.6-1 Severity: normal Tags: patch User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! When upstream dropped NGC support for SPARC, they also accidentally removed build support for unregisterised builds by removing sparc* and sparc64* from m4/ghc_convert_cpu.m4 and m4/fptools_set_haskell_platform_vars.m4 meaning that building on sparc64 is no longer possible. The attached patch re-adds sparc and sparc64 to re-enable builds. The problem has also been reported upstream [1]. Thanks, Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23959 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: ghc-9.4.6/m4/ghc_convert_cpu.m4 === --- ghc-9.4.6.orig/m4/ghc_convert_cpu.m4 +++ ghc-9.4.6/m4/ghc_convert_cpu.m4 @@ -68,6 +68,12 @@ case "$1" in sh4) $2="sh4" ;; + sparc64*) +$2="sparc64" +;; + sparc*) +$2="sparc" +;; vax) $2="vax" ;; Index: ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4 === --- ghc-9.4.6.orig/m4/fptools_set_haskell_platform_vars.m4 +++ ghc-9.4.6/m4/fptools_set_haskell_platform_vars.m4 @@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V riscv64) test -z "[$]2" || eval "[$]2=ArchRISCV64" ;; -hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax) +hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax) test -z "[$]2" || eval "[$]2=ArchUnknown" ;; *)
Bug#1050503: suitesparse: FTBFS on loong64 and sparc64 due to packaging issues
Source: suitesparse Version: 1:7.1.0+dfsg-3 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! suitesparse FTBFS on loong64 and sparc64 due a packaging issue with an implicit CUDA dependency. The failing build step is actually at dpkg-shlibdeps which fails since it cannot find the lib*_cuda.so shared libraries anywhere [1][2]: dpkg-shlibdeps: error: cannot find library libspqr_cuda.so.3 needed by debian/libspqr3/usr/ \ lib/sparc64-linux-gnu/libspqr.so.3.0.4 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') dpkg-shlibdeps: error: cannot find library libcholmod_cuda.so.4 needed by debian/libumfpack6/ \ usr/lib/sparc64-linux-gnu/libumfpack.so.6.1.1 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') dpkg-shlibdeps: error: cannot find library libcholmod_cuda.so.4 needed by debian/libklu2/usr/ \ lib/sparc64-linux-gnu/libklu_cholmod.so.2.0.4 (ELF format: 'elf64-sparc' abi: '0202002b'; RPATH: '') This is not surprising since the corresponding lib*_cuda.so shared libraries are being deleted in debian/rules [3]. However, I have no clue why this affects loong64 and sparc64 only. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=suitesparse&arch=loong64&ver=1%3A7.1.0%2Bdfsg-3&stamp=1692910284&raw=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=suitesparse&arch=sparc64&ver=1%3A7.1.0%2Bdfsg-3&stamp=1692414038&raw=0 > [3] > https://salsa.debian.org/science-team/suitesparse/-/blob/master/debian/rules#L57 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: with kernel 6.4 update, boot fails drops into maintenance
> On Jul 31, 2023, at 2:46 PM, Riccardo Mottola > wrote: > > after several reboots, I could not reproduce "that" looping crash anymore, > but I always got into maintenance mode. > Is that a kernel issue too? Yes, see the other thread which also reports a regression on older SPARCs. There are no issues on the T5220 or SPARC-T4. Adrian
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
> On Jul 31, 2023, at 4:33 PM, Stan Johnson wrote: > > I don't think a kernel bisect will identify the issue, since the kernel > boots ok. This has something to do with the initrd, and I don't know how > to troubleshoot that. Any recommendations? It can still be a bug in the kernel, especially since we’re not seeing this issue on the T5220 and the SPARC-T4. I bet if you rebuild the initrd for the older kernels, these will still boot fine which would prove my theory. Adrian
Re: with kernel 6.4 update, boot fails drops into maintenance
Hi Riccardo!
On Mon, 2023-07-31 at 12:21 +0200, Riccardo Mottola wrote:
> I have a Fire T2000 which has been stable for my usage for months.
> Now I upgraded kernel (and userland) in debian to:
>
> Yesterday, when hooking up a serial console, i was getting asked for
> root password and dropped into maintenance mode.
> Today I hooked up better through a console with minicom to be able to
> copy the error, but I get these errors again and again:
>
>
> [ 17.134833] OOPS: RPC [0042ce10]
> [ 17.134843] OOPS: RPC
> [ 17.134875] OOPS: Fault was to vaddr[bc0]
> [ 17.134885] CPU: 25 PID: 0 Comm: swapper/25 Tainted: G D
> 6.4.0-1-sparc64-smp #1 Debian 6.4.4-2
> [ 17.134908] Call Trace:
> [ 17.134915] [<00de9614>] dump_stack+0x8/0x18
> [ 17.134948] [<00df547c>] do_sparc64_fault+0x4bc/0xb00
> [ 17.134979] [<00407714>] sparc64_realfault_common+0x10/0x20
> [ 17.135017] [<0bc0>] 0xbc0
> [ 17.135034] [<00dea050>] default_idle_call+0x30/0x120
> [ 17.135067] [<004c32f8>] do_idle+0xd8/0x1a0
> [ 17.135095] [<004c3684>] cpu_startup_entry+0x24/0x40
> [ 17.135123] [<00440f28>] smp_callin+0xe8/0x120
> [ 17.135145] [<010d8c14>] 0x10d8c14
> [ 17.135162] [<>] 0x0
> [ 17.135179] Unable to handle kernel NULL pointer dereference
> [ 17.135187] tsk->{mm,active_mm}->context = 0041
> [ 17.135197] tsk->{mm,active_mm}->pgd = 80001727
> [ 17.135207] \|/ \|/
> [ 17.135207] "@'/ .. \`@"
> [ 17.135207] /_| \__/ |_\
> [ 17.135207] \__U_/
> [ 17.135216] swapper/25(0): Oops [#49]
> [ 17.135230] CPU: 25 PID: 0 Comm: swapper/25 Tainted: G D
> 6.4.0-1-sparc64-smp #1 Debian 6.4.4-2
> [ 17.135253] TSTATE: 004411001605
>
>
> so something worsened! darn! this looks as back when all kernels failed
> to boot on the Niagara.
> I set up minicom to log to a file and see see if I can catch something
> before the crashes.
Kernel regressions should be reported to the sparclinux kernel mailing list [1].
Also, a bisect would be helpful to determine which commit broke the kernel.
Thanks,
Adrian
> [1] http://vger.kernel.org/vger-lists.html#sparclinux
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Hi Stan! On Mon, 2023-07-24 at 15:46 -0600, Stan Johnson wrote: > The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun > Ultra 30 with the following error at the PROM: > > - > ... > Loaded kernel version 6.4.4 > Loading initial ramdisk (23022746 bytes at 0x6400 phys, 0x40C0 > virt)... > Fast Data Access MMU Miss > ok > - > > I have been running a custom 6.2.10 kernel, and that continues to work. > I'm not sure whether this is related to Joacim Nilsson's cgroup fail > error on his Sun Ultra 5, but the failure message is different. I'll > have to investigate whether this could be a kernel regression. Thanks for the report. If you could bisect this issue and report the commit to the original author who introduced it while CC'ing the SPARC LKML, that would be extremely helpful. I have some older SPARCs myself, but currently no space to set them up for testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Sun Ultra 5 cgroup fail after clean install
Hi! On Sun, 2023-07-23 at 11:36 +0200, Joacim Nilsson wrote: > Never done it before. > i found this > https://wiki.debian.org/DebianKernel/GitBisect Yes, this basically explains how to do it. However, I would recommend using a fast x86_64 machine for cross-compiling the kernel as building the kernel natively on the Sun Ultra 5 will take forever. A cross-toolchain for building a sparc64 kernel can be found here: > https://mirrors.edge.kernel.org/pub/tools/crosstool/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Sun Ultra 5 cgroup fail after clean install
Hi! On Sun, 2023-07-23 at 11:27 +0200, Joacim Nilsson wrote: > To get more information i booted the 6.1.0-9 kernel > That one works! OK, so it seems we have found a kernel regression here. Do you know how to bisect a kernel? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Sun Ultra 5 cgroup fail after clean install
Hi Joacim! On Sat, 2023-07-22 at 22:53 +0200, Joacim Nilsson wrote: > Hi! > After installning debian-12.0.0-sparc64-NETINST-1.iso > on my Sun Ultra 5 > > i get > > Loading Linux 6.3.0-2-sparc64 ... > Loading initial ramdisk ... > > Failed to get cgroup, ignoring: No medium found > /dev/sda2: recovering journal > /dev/sda2: clean, 32037/15204352 files, 1785366/60804430 blocks > [ 49.359252] /dev/sda: Can't open blockdev > [FAILED] Failed to mount boot.mount - /boot. > [DEPEND] Dependency failed for local-fs.target - Local File Systems. > You are in emergency mode. After logging in, type "journalctl -xb" to view > system logs, "systemctl reboot" to reboot, or "exit"Give root password for > maintenance > (or press Control-D to continue): > > I can mount the boot device if i log in > I thought at first my hardware was causing issues > But i have removed all non sun cards from the machine > > And *BSD installs just fine > > Can it be a too large disk? > Installer was complaning about a huge cylinder count. How was the disk partioned? Did you use manual partioning or did you use the installer's suggested defaults? The disk itself won't be too large, but it could be that you created a partition that does not fit the geometry of the Sun partioning theme. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:59 +0200, John Paul Adrian Glaubitz wrote: > With the above fix for the audit tests, the tests to ignore should be: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Just verified this. With both patches above applied, the failures reduce to the four tests above. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1040817: glibc: Please ignore some tests on sparc64
On Tue, 2023-07-11 at 20:57 +0200, Aurelien Jarno wrote: > > Correction: These two tests should be ignored as well: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > Noted. > > > So, it's only this failure that just got fixed today upstream [1]: > > > > FAIL: nptl/tst-cancel30 > > Ok, I see it's also fixed on the 2.37 branch, I'll pull it from there. And there is now a fix for the audit issues: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ And re-enable the 32-bit tests then. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 20:52 +0200, Aurelien Jarno wrote: > > According to upstream, the following audit tests are not going to be > > fixed soon since the SPARC ABI makes it more difficult: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > Ok. It happens that Adhemerval just posted a patch for the audit issue a few hours ago: > https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/ So, we might not have the blacklist these as well. > > These are going to be fixed upstream soon, the fixes are supposedly > > trivial: > > > > FAIL: elf/tst-rtld-run-static > > FAIL: nptl/tst-cancel24-static > > FAIL: nptl/tst-cancel30 > > Great. > > > This test is supposedly a kernel issue: > > > > FAIL: socket/tst-socket-timestamp > > > > And this one allegedly not related to sparc64: > > > > FAIL: stdlib/isomac > > What do you mean by "allegedly not related to sparc64"? This failure > only appears on sparc*. The sparc32 has the following comment in > debian/testsuite-xfail-debian.mk to ignore the failure: > > # Even if configured using --with-long-double-128, the biarch32 compiler > # on sparc64 defaults to 64-bit doubles, causing the failure below. This > # should be fixed by the following gcc patch: > # http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html > test-xfail-stdlib/isomac = yes > > Can you please check if there is a similar issue with the GCC > configuration on sparc64? That was the comment by Adhemerval when he looked at the issue. > > So, my suggestion would be to ignore the following tests for now: > > > > FAIL: elf/tst-audit24a > > FAIL: elf/tst-audit24b > > FAIL: elf/tst-audit24c > > FAIL: elf/tst-audit24d > > FAIL: socket/tst-socket-timestamp > > FAIL: stdlib/isomac > > Ok. > > > And looking at the testsuite results with 32-bit tests enabled [1], it > > looks like > > the failures are the same. So, I think we can just ignore the above tests > > and then > > re-enable testing on 32 bit as well. > > It appears that none of those fails on sparc32. Looking at it again, it > even appears that the sparc32 build passed the testsuite without issue, > so there was no need to disable it. Hmm, then I actually mixed up the two testsuites, sorry. You can re-enable it then. With the above fix for the audit tests, the tests to ignore should be: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1040817: glibc: Please ignore some tests on sparc64
Hi! On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote: > The list of currently failing tests on sparc64 is: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac > > According to upstream, the following audit tests are not going to be > fixed soon since the SPARC ABI makes it more difficult: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > > These are going to be fixed upstream soon, the fixes are supposedly > trivial: > > FAIL: elf/tst-rtld-run-static > FAIL: nptl/tst-cancel24-static > FAIL: nptl/tst-cancel30 > > This test is supposedly a kernel issue: > > FAIL: socket/tst-socket-timestamp > > And this one allegedly not related to sparc64: > > FAIL: stdlib/isomac > > So, my suggestion would be to ignore the following tests for now: > > FAIL: elf/tst-audit24a > FAIL: elf/tst-audit24b > FAIL: elf/tst-audit24c > FAIL: elf/tst-audit24d > FAIL: socket/tst-socket-timestamp > FAIL: stdlib/isomac Correction: These two tests should be ignored as well: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static So, it's only this failure that just got fixed today upstream [1]: FAIL: nptl/tst-cancel30 Adrian > [1] > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260d4b742bc36744aa2282421547f1a7b483d2f8 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Hi Matthew! On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote: > Hi, > > On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote: > > > While we're currently not building Debian for 32-bit SPARC (sparc), > > it's still being bootstrapped in the Debian rebootstrap project [1]. > > > > The CI job for sparc is currently failing because pcre2 is still being > > configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was > > dropped upstream [3]. See also for the corresponding change in buildroot > > [4]. > > I can remove sparc, certainly. Is this something you would like me to > try and get through the freeze? If not, I'd like to hold off making any > pcre2 uploads until after the release. Any chance this can be done now? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040817: glibc: Please ignore some tests on sparc64
Source: glibc Version: 2.37-5 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hi! The list of currently failing tests on sparc64 is: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac According to upstream, the following audit tests are not going to be fixed soon since the SPARC ABI makes it more difficult: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d These are going to be fixed upstream soon, the fixes are supposedly trivial: FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 This test is supposedly a kernel issue: FAIL: socket/tst-socket-timestamp And this one allegedly not related to sparc64: FAIL: stdlib/isomac So, my suggestion would be to ignore the following tests for now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac And looking at the testsuite results with 32-bit tests enabled [1], it looks like the failures are the same. So, I think we can just ignore the above tests and then re-enable testing on 32 bit as well. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=sparc64&ver=2.37-1&stamp=1684283585&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1040462: glibc: Please ignore testsuite failures for 32-bit builds on sparc64
Source: glibc Version: 2.37-3 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! On sparc64, the following tests for the 32-bit build have been failing for a while now: FAIL: elf/tst-audit24a FAIL: elf/tst-audit24b FAIL: elf/tst-audit24c FAIL: elf/tst-audit24d FAIL: elf/tst-rtld-run-static FAIL: nptl/tst-cancel24-static FAIL: nptl/tst-cancel30 FAIL: socket/tst-socket-timestamp FAIL: stdlib/isomac See: https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=sparc64&ver=2.37-3&stamp=1688236651&raw=0 Since we don't care so much about 32-bit SPARC these days, I think it's safe to ignore these testsuite failures. Can you therefore ignore the testsuite failures for 32-bit for the time being? I will report each of the testsuite failures in case this has not happened yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: M4000 failing to boot Debian Sparc64
Hello! On Mon, 2023-07-03 at 05:28 -0400, Dennis Clarke wrote: > > I don't think that's true. Since it has been reported that these machines > > run OpenBSD, it should be a matter of reading the OpenBSD kernel sources > > and add the missing bits and pieces for the SPARC64 VII(+) machines to the > > Linux kernel. > > Are we certain about NetBSD or OpenBSD? I did try to install NetBSD and > that failed also. I think I have my notes on that somewhere but it would > be easy enough for me to try again. OpenBSD lists the M4000 as supported: > https://www.openbsd.org/sparc64.html While I didn't actually mention NetBSD here, since it's not the same as OpenBSD, I checked that as well now and it currently doesn't support Fujitsu CPUs, but that's work-in-progress, same applies to sun4v, i.e. T1-T5. For sun4v, I'm actually in contact with the developer doing the work. > https://wiki.netbsd.org/ports/sparc64/ > > I don't think that would be much as this it just some board-specific code > > and it wouldn't probably take an experienced kernel developer longer than > > a month if at all. > > That brings the costs down to the level of reasonable. Let me ponder > that a while. Find someone on the sparclinux Linux kernel mailing list willing to do the work and create a Bountysource campaign to sponsor the work. I assume, you can get it done for maybe $5000-$10.000. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: M4000 failing to boot Debian Sparc64
Hi Dennis! On Sun, 2023-07-02 at 14:34 -0400, Dennis Clarke wrote: > You are likely kicking a dead horse. That M4000 is similar to my M3000 > and you will never ever get Linux to run there. Ever. Unless you have a > few million dollars for research and development and then be able to > push all the good research upstream into the Linux kernel. I don't think that's true. Since it has been reported that these machines run OpenBSD, it should be a matter of reading the OpenBSD kernel sources and add the missing bits and pieces for the SPARC64 VII(+) machines to the Linux kernel. I don't think that would be much as this it just some board-specific code and it wouldn't probably take an experienced kernel developer longer than a month if at all. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please help reporting upstream bugs
On Sat, 2023-06-24 at 13:04 +0200, John Paul Adrian Glaubitz wrote: > For the bug report, please include: > > - the full URL to the build log of the affected package on buildd.debian.org > - an excerpt from the build log like the one above that shows the actual > build error > - a mention of the "GCC Compile Farm" (https://gcc.gnu.org/wiki/CompileFarm) > explaining > that PowerPC machines for debugging the problem on the target architecture > can be > found there; access to the "GCC Compile Farm" is free for every open source > developer This is meant to say "SPARC machines for debugging the problem", of course. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Please help reporting upstream bugs
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00
?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ??
test_sm "option scan_data_type string;\" ${huge_string};exit"
scanmem version 0.17
libscanmem version 0.17
Copyright (C) 2006-2017 Scanmem authors
See https://github.com/scanmem/scanmem/blob/master/AUTHORS for a full author
list
scanmem comes with ABSOLUTELY NO WARRANTY; for details type `show warranty'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show copying' for details.
warn: Run scanmem as root if memory regions are missing. See scanmem man page.
error: failed to open maps file /proc/3148168/maps.
error: sorry, there was a problem getting a list of regions to search.
warn: the pid may be invalid, or you don't have permission.
Enter the pid of the process to search using the "pid" command.
Enter "help" for other commands.
> option scan_data_type string
> "
a
# Clean up
kill $memfake_pid
./sm_test.sh: line 36: kill: (3148168) - No such process
FAIL sm_test.sh (exit status: 1)
Go back to the other tab which shows the build results for the packages on all
architectures,
click "Tracker" to get to the package's overview page. Click onto "Homepage" to
get to the
homepage of the original package and navigate through the webpage to create a
bug report.
For the bug report, please include:
- the full URL to the build log of the affected package on buildd.debian.org
- an excerpt from the build log like the one above that shows the actual build
error
- a mention of the "GCC Compile Farm" (https://gcc.gnu.org/wiki/CompileFarm)
explaining
that PowerPC machines for debugging the problem on the target architecture
can be
found there; access to the "GCC Compile Farm" is free for every open source
developer
Due to the large amount of packages that FTBFS on sparc64, reporting
arch-specific upstream
bugs is the perfect task that can be crowd-sourced. In order to avoid redundant
bug reports,
it's probably a good idea to create a Google Doc sheet to document all packages
where a bug
report has already been created.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: unbreaking LibreOffices tests on at least release architectures
Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > I don't really like sweeping it under the carpet again and would > actually pursue the "getting those architectures removed from unstable" > way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Running Debian-sparc64 on qemu
Hi Carlos! On Wed, 2023-06-14 at 11:43 -0300, Carlos Roberto wrote: > I'm trying to install and run debian-sparc64 on qemu, but I'm having some > difficulties... I just uploaded new installation images today which use an updated kernel (6.1.x -> 6.3.x). > https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-14/ Can you give it a try with the sparc64 image from there? Also, what version of QEMU is that? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated installation images for Debian Ports
Hello! I have created updated installation images for Debian Ports. These can be found here: - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-14/ On ia64, these images should be usable on all machines again since the previous regression in kernel 6.1 has been fixed in 6.3 which is now the kernel version that the installer uses. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2023-06-06
On Wed, 2023-06-07 at 03:36 -0400, Dennis Clarke wrote: > One of the first things I plan on doing is a bootstrap of GCC 13.x > and then also binutils ( maybe? maybe not? ) and of course a kernel. > That will keep the machine thrashing for at least a week. With Gentoo I > saw an update time of the machine take well over 190 hours. Awesome > throughput with plenty of swap needed. You should run the GCC testsuite which really tortures the hardware. Btw, I had a quick glimpse through your video and saw that you were confused by the kernel used by the installer which is still at 6.1.x. The 6.3.x kernels are part of experimental only at the moment since Debian Bookworm is going to be released with a 6.1.x kernel which is an LTS kernel. Since debian-installer images are always built from unstable, the installer is currently stuck at kernel 6.1.x but you can install the experimental kernel using this sources.list [1] afterwards with: # apt install linux-image-sparc64-smp -t=experimental Adrian > [1] https://people.debian.org/~glaubitz/sources.list.experimental -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2023-06-06
Hi! On Wed, 2023-06-07 at 03:10 -0400, Dennis Clarke wrote: > Sadly the machine isa bit of a brick. Maybe NetBSD works? No idea. > > However a much older and smaller UltraSPARC IIi Netra seems to be > working just perfect. I am doing the install now, live, streaming on > YouTube. > > To say the least it is a slow and boring stream :) > > But it works ! That's good to hear. You should run some CPU-intensive code on the machine once it's installed to see how reliable the current kernel is. Also, try kernel 6.3 from experimental. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2023-06-06
Hi Dennis! On Wed, 2023-06-07 at 02:02 -0400, Dennis Clarke wrote: > On 6/6/23 09:52, John Paul Adrian Glaubitz wrote: > > Hello! > > > > I have created updated installation images for Debian Ports. > > > > These can be found here: > > > > - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/ > > > > I have already successfully tested the sparc64 installer. > > > > > Sadly the Fujitsu M3000 SPARC64 VII+ does bad things after we see GRUB : > (...) > Sadly this machine seems to be nothing but a fancy brick with 64G of > expensive ECC memory etc etc. I don't think the Fujitsu SPARC64 CPUs were ever officially supported by the Linux kernel, were they? Probably not going to happen in the future either. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated installation images for Debian Ports 2023-06-06
Hello! On Tue, 2023-06-06 at 16:19 +0200, Frank Scheiner wrote: > On 06.06.23 15:52, John Paul Adrian Glaubitz wrote: > > Hello! > > > > I have created updated installation images for Debian Ports. > > > > These can be found here: > > > > - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/ > > > > I have already successfully tested the sparc64 installer. > > On what machine did you test it? Inside an LDOM on a SPARC-T5. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated installation images for Debian Ports 2023-06-06
Hello! I have created updated installation images for Debian Ports. These can be found here: - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/ I have already successfully tested the sparc64 installer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Current kernels run stable on older SPARC systems
Hello! I have updated the UltraSPARC IIIi to kernel 6.3 from experimental and it has been running very stable for almost a week now despite the server being run as a CI machine for the Free Pascal Compiler. So, it seems the Linux kernel is finally usable on older SPARC systems again. I'm curious to hear if anyone can confirm this on their own machines. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled
Source: webkit2gtk Version: 2.40.2-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! webkit2gtk currently FTBFS on multiple architectures since it tries to build Bubblewrap support code despite being configured with -DENABLE_BUBBLEWRAP_SANDBOX=OFF. On sparc64, for example, at the configure stage, the feature is clearly off: -- Enabled features: -- ENABLE_BUBBLEWRAP_SANDBOX . OFF However, the build system still tries to build the corresponding code in Sandbox.cpp: [151/6185] /usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 \ -DBUILDING_WTF -DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 \ -I/<>/build-soup2 -I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF \ -I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa -I/<>/Source/WTF/wtf/fast_float \ -I/<>/Source/WTF/wtf/persistence -I/<>/Source/WTF/wtf/text \ -I/<>/Source/WTF/wtf/text/icu -I/<>/Source/WTF/wtf/threads \ -I/<>/Source/WTF/wtf/unicode -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/glib-2.0 -isystem \ /usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem /usr/include/libmount -isystem /usr/include/blkid \ -fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread \ -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type \ -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith \ -Wmissing-format-attribute -Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 \ -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security \ -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions \ -fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -c /<>/Source/WTF/wtf/glib/Sandbox.cpp FAILED: Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o /usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 -DBUILDING_WTF \ -DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 \ -I/<>/build-soup2 -I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF \ -I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa -I/<>/Source/WTF/wtf/fast_float \ -I/<>/Source/WTF/wtf/persistence -I/<>/Source/WTF/wtf/text \ -I/<>/Source/WTF/wtf/text/icu -I/<>/Source/WTF/wtf/threads -I/<>/Source/WTF/wtf/unicode \ -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem \ /usr/include/libmount -isystem /usr/include/blkid -fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr \ -Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type \ -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith -Wmissing-format-attribute \ -Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong \ -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing \ -fno-exceptions -fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \ -MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o -c \ /<>/Source/WTF/wtf/glib/Sandbox.cpp /<>/Source/WTF/wtf/glib/Sandbox.cpp: In function ‘bool WTF::isInsideUnsupportedContainer()’: /<>/Source/WTF/wtf/glib/Sandbox.cpp:49:13: error: ‘BWRAP_EXECUTABLE’ was not declared in this scope 49 | BWRAP_EXECUTABLE, | ^~~~ See: https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk&arch=sparc64&ver=2.40.2-1&stamp=1685439602&raw=0 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Need advise setting up NAT for LDOMs
Hello! We have one SPARC T4 that is running Solaris 11.4 CBE and is waiting for its final setup. One of the problems is that the machine has one external IP only and the LDOMs therefore need to be set up using NAT. Unfortunately, I have so far been unable to understand how NAT on Solaris is configured since the documentation is very vague on this topic. Does anyone know how to set up NAT for LDOMs? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Help needed to make Lazarus compile on Sparc64
Hi Abou! On Sun, 2023-05-28 at 10:27 +0200, John Paul Adrian Glaubitz wrote: > I will try again later today. it fails with a different error now which indicates that the Lazarus build system doesn't know about sparc64 as an architecture [1]: (9009) Assembling lazbuild (9022) Compiling resource ../units/sparc64-linux/nogui/lazbuild.or Error: Unknown architecture 'sparc64' Error: (9029) Error while compiling resources Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted Adrian > [1] > https://people.debian.org/~glaubitz/lazarus_2.2.6+dfsg2-2_sparc64.build.experimental -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Help needed to make Lazarus compile on Sparc64
> On May 28, 2023, at 10:13 AM, Abou Al Montacir wrote: > > > Hi Adrian, > >> On Sun, 2023-05-28 at 02:10 +0200, John Paul Adrian Glaubitz wrote: >> On Sun, 2023-05-28 at 01:25 +0200, John Paul Adrian Glaubitz wrote: >>>> Can anyone please, try to rebuild Lazarus on Sparc64 with FPC from >>>> experimental and let me know if that is OK? >>> >>> I'll give it a try. >> >> Still fails, unfortunately. >> >> See: https://people.debian.org/~glaubitz/lazarus_2.2.6+dfsg2-2_sparc64.build > This fails because the build process pulled FPC 3.2.2+dfsg-20 from unstable > instead of 3.2.2+dfsg-21~rc1 from experimental. > One way would be to force FPC version either in the Lazarus control file or > on the machine itself. Odd, I actually preinstalled fpc from experimental in the chroot. But it was late yesterday and I probably mixed up the chroots. I will try again later today. Adrian
Re: Help needed to make Lazarus compile on Sparc64
Hi! On Sun, 2023-05-28 at 01:25 +0200, John Paul Adrian Glaubitz wrote: > > Can anyone please, try to rebuild Lazarus on Sparc64 with FPC from > > experimental and let me know if that is OK? > > I'll give it a try. Still fails, unfortunately. See: https://people.debian.org/~glaubitz/lazarus_2.2.6+dfsg2-2_sparc64.build Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Help needed to make Lazarus compile on Sparc64
Hello Abou! On Sat, 2023-05-27 at 20:44 +0200, Abou Al Montacir wrote: > I was trying to make Lazarus compile on Sparc64 for long time. > There was a bug in Free Pascal Compiler that prevented that: > https://gitlab.com/freepascal.org/fpc/source/-/issues/40252 > I manged to make upstream generate a patch for that and uploaded it to > experimental: > https://tracker.debian.org/news/1432268/accepted-fpc-322dfsg-21rc1-source-into-experimental/ Thanks for fixing this bug! > I tried to connect to kyoto.debian.net to test it, but I got timout on SSH > connection. kyoto is unfortunately offline because I lost the place for hosting it and I haven't found a new home for this server yet. At the moment, the machine is sitting in my shelf at home in storage. There is some hope we will have a SPARC-T4 available soon that is currently being set up for the GCC compile farm and that we can get some LDOMs on (SPARC virtual machines). > I've spent the day trying to update my QEMU VM or to install a new one, but > it seems that QEMU version shipped with Bookworm is buggy on Sparc64. > So that to say I completely lost he day without any success. You can use qemu-user which is easier to use: > https://wiki.debian.org/M68k/sbuildQEMU > https://wiki.debian.org/SH4/sbuildQEMU > Can anyone please, try to rebuild Lazarus on Sparc64 with FPC from > experimental and let me know if that is OK? I'll give it a try. > Or at least provide access to a Sparc64 machine where I can do it myself? > > PS: I'm not subscribed to this list, so please keep me in copy. Noted. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Follow up on smp kernel for V210/V240
Hi Brian! On Sun, 2023-05-07 at 07:25 +, Brian Noonan wrote: > We chatted some weeks ago about upgrading my V210 to a second cpu and > using the downgraded smp kernel you sent a link to. > Well, I had a bit of a disaster initially. The second cpu I installed > initially was faulty. (I must have had it as a spare part for 15 years) > and it burnt the cpu and socket. *doh*. Anyway, I swapped out the motherboard > for one from a Netra V240 I had around and stuck in another spare cpu I had. > This is all working now. Unbalanced ram does seem to work too. I have 3.5gb > installed currently. The only minor issue to resolve now is i have a fan > failure on one cpu heatsink but a replacement fan should be easy to find. > Then I want some more ram (I will take this to 16Gb) and get an xvr-100 to > get a desktop so I can hook this up to my kvm. > > So, some issues along the way but all working now. I am currently managing > this system via cockpit since I don't think I can get webmin working. Sounds very good. Which kernel version are you running now? And is it a custom kernel or Debian's stock kernel? And do you see any applications crashing when using a recent 6.x kernel? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules
Source: pcre2 Version: 10.36-2+deb11u1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sparc@lists.debian.org Hello! While we're currently not building Debian for 32-bit SPARC (sparc), it's still being bootstrapped in the Debian rebootstrap project [1]. The CI job for sparc is currently failing because pcre2 is still being configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was dropped upstream [3]. See also for the corresponding change in buildroot [4]. Could you drop "sparc" from the list in [3]? Thanks, Adrian > [1] https://jenkins.debian.net/view/rebootstrap/ > [2] https://salsa.debian.org/debian/pcre2/-/blob/master/debian/rules#L16 > [3] > https://github.com/PCRE2Project/pcre2/commit/b67d5682019fd192a615a1d5ed254b564f54126b > [4] > https://patchwork.ozlabs.org/project/buildroot/patch/20230221115001.190317-1-fontaine.fabr...@gmail.com/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: V210 booted from iso and installed but could not find mirror?
Hi Brian! On Sat, 2023-03-25 at 10:39 +, Brian Noonan wrote: > Thanks Adrian! > That appears to work! > Now installing packages. But i just got a kernel panic with openssh-server. 😞 Try installing and booting an older kernel first: # wget http://snapshot.debian.org/archive/debian-ports/20190719T183113Z/pool-sparc64/main/l/linux/linux-image-4.19.0-5-sparc64-smp_4.19.37-6_sparc64.deb # dpkg -i linux-image-4.19.0-5-sparc64-smp_4.19.37-6_sparc64.deb Newer kernels are known to be unstable on older sparc64 machines. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: V210 booted from iso and installed but could not find mirror?
Hi! On Sat, 2023-03-25 at 09:03 +, Brian Noonan wrote: > Thanks for the fast response on your weekend! > Unfortunately not. > > root@daffy:/usr/bin# gpg --keyserver keyserver.ubuntu.com --recv-keys > 8D69674686 > -bash: gpg: command not found > > I've run a find in /usr and also checked /usr/bin and /usr/sbin plus > /usr/local/bin > manually just in case the issue was my PATH. No luck there either. Try: # apt update -o Acquire::Check-Valid-Until=false -o Acquire::AllowInsecureRepositories=true -o Acquire::AllowDowngradeToInsecureRepositories=true then: # apt install debian-ports-archive-keyring Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: V210 booted from iso and installed but could not find mirror?
Hi! On Sat, 2023-03-25 at 01:59 +, Brian2 wrote: > I seem to be chasing my tail a bit though as I am getting that wget is > not installed so can't install the keyring to install stuff... You can fetch the key with GPG which should be installed: # gpg --keyserver keyserver.ubuntu.com --recv-keys 8D69674688B6CB36 # gpg --export --armor 8D69674688B6CB36 | apt-key add - Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: V210 booted from iso and installed but could not find mirror?
Hi Brian! On Fri, 2023-03-24 at 03:07 +, Brian2 wrote: > Booting from the iso in the DVD allowed me to install without an issue. Great. > However, I was unable to find a mirror to download any packages from. I'm > only after basic stuff like tcsh, alpine, openssh-server, etc. > > What are my next steps now to make this system useful? Make sure you have these lines in your /etc/apt/sources.list: # binary default deb http://ftp.ports.debian.org/debian-ports/ unstable main deb http://incoming.ports.debian.org/buildd/ unstable main deb http://ftp.ports.debian.org/debian-ports/ unreleased main # contrib and non-free arch:all packages (i.e. firmware) deb [arch=all] http://ftp.debian.org/debian/ unstable contrib non-free # source deb-src http://ftp.debian.org/debian/ unstable main deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main You can fetch the file from here: > https://people.debian.org/~glaubitz/sources.list You may have to install the Debian Ports Archive Keyring: # wget http://ftp.ports.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb # dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb before running: # apt update > Thanks Adrian for keeping Debian alive on Sparc. You're welcome. > Now to add a second CPU to this box and up the RAM a bit. Good idea. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1030053: rustc: Please add patch to fix FTBFS on sparc64
Source: rustc
Version: 1.64.0+dfsg1-1~exp3
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hi!
The attached patch is a backport of the commit in [1] which fixes the
rustix (and therefore rustc) FTBFS on sparc64 [2].
Could you apply it for the next rustc upload for version 1.64.x?
Thanks,
Adrian
> [1]
> https://github.com/bytecodealliance/rustix/commit/85ed94efa3d4ce05ba7edaacc78b37cd8fbf6793
> [2]
> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=sparc64&ver=1.64.0%2Bdfsg1-1%7Eexp3&stamp=1674399404&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/process/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/process/types.rs
@@ -199,7 +199,12 @@ pub enum Signal {
target_os = "openbsd",
all(
any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
)
)))]
Stkflt = c::SIGSTKFLT,
@@ -276,7 +281,12 @@ impl Signal {
target_os = "openbsd",
all(
any(target_os = "android", target_os = "linux"),
-any(target_arch = "mips", target_arch = "mips64"),
+any(
+target_arch = "mips",
+target_arch = "mips64",
+target_arch = "sparc",
+target_arch = "sparc64"
+),
)
)))]
c::SIGSTKFLT => Some(Self::Stkflt),
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/libc/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/libc/termios/types.rs
@@ -704,6 +704,8 @@ pub const B200: Speed = c::B200;
/// `B250`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -715,6 +717,8 @@ pub const B250: Speed = c::B250;
/// `B300`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -726,6 +730,8 @@ pub const B300: Speed = c::B300;
/// `B350`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -737,6 +743,8 @@ pub const B350: Speed = c::B350;
/// `B400`
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/imp/linux_raw/termios/types.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/imp/linux_raw/termios/types.rs
@@ -338,15 +338,19 @@ pub const B150: Speed = linux_raw_sy
pub const B200: Speed = linux_raw_sys::general::B200;
/// `B250`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B250: Speed = linux_raw_sys::general::B250;
/// `B300`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B300: Speed = linux_raw_sys::general::B300;
/// `B350`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B350: Speed = linux_raw_sys::general::B350;
/// `B400`
+#[cfg(not(any(target_arch = "sparc", target_arch = "sparc64",)))]
pub const B400: Speed = linux_raw_sys::general::B400;
/// `CSIZE`
--- rustc-1.64.0+dfsg1.orig/vendor/rustix/src/termios/constants.rs
+++ rustc-1.64.0+dfsg1/vendor/rustix/src/termios/constants.rs
@@ -45,6 +45,8 @@ pub use imp::termios::types::B200;
)))]
pub use imp::termios::types::B250;
#[cfg(not(any(
+target_arch = "sparc",
+target_arch = "sparc64",
target_os = "dragonfly",
target_os = "freebsd",
target_os = "ios",
@@ -54,6 +56,8 @@ pub use imp::termios::types::B250;
)))]
pub use imp::termios::types::B300;
#[cfg(not(any(
+target_arch = "sparc",
+target_arch =
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
Hello! On 1/11/23 18:30, Rene Engelhard wrote: But I was more aiming at (and sparc* has the same issue) is libreoffice build-depends on: - libkf5config-dev:m68k libkf5config-dev depends on: - libkf5configqml5:m68k (= 5.101.0-1) libkf5configqml5 depends on: - libqt5qml5:m68k (>= 5.15.2~) libqt5qml5 depends on missing: - qtbase-abi-5-15-6:m68k And that transition happened already. And it was even BD-Uninstallable on Qt before that one. Indeed. But those transitions have been done already. KDE uninstallable is a bug of those ports. It's actually an inherent bug in the JavaScript engine of Qt that makes assumptions about the hardware that it shouldn't make. For example, that it can use the upper bits of a pointer to encode type information of a JavaScript object (tagged pointers) [1]. You may argue that it's okay because it works on x86_64. However, it only works because Intel didn't make use of the upper 16 bits of a 64-bit pointer in the past although these were always reserved. But that has changed now with the advent of 5-level paging [2] where the bits 48-56 are used as well. Luckily, the Qt developers have understood that their code is broken on systems with large virtual address spaces, so they have reworked it and if you look at the corresponding Qt6 packages, you will see that these all build fine on sparc64. Adrian [1] https://bugreports.qt.io/browse/QTBUG-56264 [2] https://en.wikipedia.org/wiki/Intel_5-level_paging -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sparc64 pbuilder/cowbuilder setup with qemu
Hi Gregor! On 12/26/22 11:01, Gregor Riepl wrote: Since gcc102 is available right now, I tested the libnss build on that machine. libnspr4-dev isn't installed, but the build got sufficiently far to compare output with the Debian build machines. We should probably set up schroot on these machines so that users can set up their own build environments. For gcc102, Zach van Rijn is actually the admin of the machine. Unfortunately, the uname issue does not occur there, which leads me to believe something is different between gcc102 and the Debian build hosts[1]. gcc102 has coreutils 9.1-1, libc6 2.36-4 and uname reports: Linux gcc102.fsffrance.org 6.1.0+ #1 SMP Tue Dec 13 08:35:29 CST 2022 sparc64 GNU/Linux The buildds are normally updating their chroots regularly. Maybe that regression hasn't hit gcc102 yet? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sparc64 pbuilder/cowbuilder setup with qemu
On 12/25/22 14:38, Gregor Riepl wrote: I suggest reporting this as a QEMU bug first and they'll tell you whether you're at the right address or need to forward this to the kernel or glibc people. Done: https://gitlab.com/qemu-project/qemu/-/issues/1394 Exemplary bug report, thanks a lot! I'll create an appropriate Debian bug when I have more information (i.e. which package needs to be fixed). Great, thanks! I hacked apt (see below) to get around the issue and started what I was originally trying to do: https://buildd.debian.org/status/logs.php?pkg=nss&ver=2%3A3.85-1&arch=sparc64 As I mentioned earlier in this thread, you can just configure apt to run as root to avoid this problem. Unfortunately, the "uname: Bad address" doesn't appear in qemu. Looks like I'll have to debug this on the actual hardware after all. Is this a known issue? Not that I know of. However, I would just bisect the issue in nss. FWIW, I know that there is going to be a new SPARC machine in the GCC compile farm based on a SPARC T4-2 that should become available soonish. While trying to trace the libnss issue, I also encountered a crash in g++, which I haven't been able to debug yet. I bet you will run into some more issues as qemu-user with sparc64 has seen little testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sparc64 pbuilder/cowbuilder setup with qemu
Hi Gregor! On 12/23/22 17:13, Gregor Riepl wrote: Where should I report this bug, then? On the glibc Bugzilla, or on https://gitlab.com/qemu-project/qemu/-/issues ? Or is this a kernel bug? I suggest reporting this as a QEMU bug first and they'll tell you whether you're at the right address or need to forward this to the kernel or glibc people. Thanks for finding and debugging this! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sparc64 pbuilder/cowbuilder setup with qemu
Hi Gregor! On 12/23/22 13:52, Gregor Riepl wrote: Comparing these two values: 42 0x2A 2752512 0x2A uid_t is defined as: /usr/include/sparc64-linux-gnu/sys/types.h:typedef __uid_t uid_t; /usr/include/sparc64-linux-gnu/bits/types.h:__STD_TYPE __UID_T_TYPE __uid_t; /* Type of user identifications. */ /usr/include/sparc64-linux-gnu/bits/typesizes.h:#define __UID_T_TYPE __U32_TYPE /usr/include/sparc64-linux-gnu/bits/types.h:#define __U32_TYPE unsigned int struct passwd uses: __uid_t pw_uid; /* User ID. */ It looks like another case of values not properly passed between the host and guest in a qemu-user setup. Another very prominent case are file handles, see [1]. Adrian [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sparc64 pbuilder/cowbuilder setup with qemu
Hello Gregor! On 12/18/22 18:11, Gregor Riepl wrote: E: Method gave invalid 400 URI Failure message: Could not switch saved set-user-ID E: Method http has died unexpectedly! E: Sub-process http returned an error code (112) This seems to be the problem and related to apt. For some reason, apt is not able to switch its user id to "_apt". I'm not sure yet why. However, I could create a chroot with sbuild-createchroot: # sbuild-createchroot --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --arch=sparc64 \ --include=debian-ports-archive-keyring sid /srv/chroot/sid-sparc64-sbuild \ http://ftp.ports.debian.org/debian-ports/ and then fix the apt error with: # echo "APT::Sandbox::User root;" > /srv/chroot/sid-sparc64-sbuild/etc/apt/apt.conf.d/10userid We need to find out what the reason for the apt user-mapping problem is. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: unable to install (upgrade) git - git-man dependency
Hello! On 11/23/22 16:27, John Paul Adrian Glaubitz wrote: FWIW, I also upgraded one of the buildds that is an UltraSPARC IIIi as well that never ran stable with kernels beyond 4.19 to 6.0.8. Let's see how reliable the machine is with the new kernel. Would be a nice surprise if this particular stability issue has been fixed now. Machine is still running with the 6.0.0 kernel which is definitely a huge improvement over the 5.x kernels which would have already crashed the machine. Guess it's time to build new installation images based on the 6.0.0 kernels then ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: unable to install (upgrade) git - git-man dependency
Hi! On 11/23/22 17:23, Riccardo Mottola wrote: let's see how 6.0 will fare for you. FWIW, I also upgraded one of the buildds that is an UltraSPARC IIIi as well that never ran stable with kernels beyond 4.19 to 6.0.8. Let's see how reliable the machine is with the new kernel. Would be a nice surprise if this particular stability issue has been fixed now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: openldap: FTBFS on sparc64 due to unaligned access in testsuite
Control: tags -1 +patch
Hello!
Upstream has provided a patch now [1] which fixes the issue for me.
It applies against both OpenLDAP 2.5.13 and 2.6.3 with fuzz and by fixing
a single printf() statement manually. I am attaching the backported patch
which applies cleanly.
Thanks,
Adrian
[1] https://git.openldap.org/openldap/openldap/-/merge_requests/582
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- openldap-2.5.13+dfsg.orig/libraries/liblmdb/mdb.c
+++ openldap-2.5.13+dfsg/libraries/liblmdb/mdb.c
@@ -823,8 +823,6 @@ typedef struct MDB_page {
#define P_KEEP 0x8000 /**< leave this page alone during spill */
/** @} */
uint16_t mp_flags; /**< @ref mdb_page */
-#define mp_lower mp_pb.pb.pb_lower
-#define mp_upper mp_pb.pb.pb_upper
#define mp_pages mp_pb.pb_pages
union {
struct {
@@ -833,9 +831,26 @@ typedef struct MDB_page {
} pb;
uint32_t pb_pages; /**< number of overflow pages */
} mp_pb;
- indx_t mp_ptrs[1]; /**< dynamic size */
+ indx_t mp_ptrs[0]; /**< dynamic size */
} MDB_page;
+/** Alternate page header, for 2-byte aligned access */
+typedef struct MDB_page2 {
+ uint16_t mp_p[sizeof(pgno_t)/2];
+ uint16_t mp_pad;
+ uint16_t mp_flags;
+ indx_t mp_lower;
+ indx_t mp_upper;
+ indx_t mp_ptrs[0];
+} MDB_page2;
+
+#define MP_PGNO(p) (((MDB_page2 *)(void *)(p))->mp_p)
+#define MP_PAD(p) (((MDB_page2 *)(void *)(p))->mp_pad)
+#define MP_FLAGS(p) (((MDB_page2 *)(void *)(p))->mp_flags)
+#define MP_LOWER(p) (((MDB_page2 *)(void *)(p))->mp_lower)
+#define MP_UPPER(p) (((MDB_page2 *)(void *)(p))->mp_upper)
+#define MP_PTRS(p) (((MDB_page2 *)(void *)(p))->mp_ptrs)
+
/** Size of the page header, excluding dynamic data at the end */
#define PAGEHDRSZ ((unsigned) offsetof(MDB_page, mp_ptrs))
@@ -846,10 +861,10 @@ typedef struct MDB_page {
#define PAGEBASE ((MDB_DEVEL) ? PAGEHDRSZ : 0)
/** Number of nodes on a page */
-#define NUMKEYS(p) (((p)->mp_lower - (PAGEHDRSZ-PAGEBASE)) >> 1)
+#define NUMKEYS(p) ((MP_LOWER(p) - (PAGEHDRSZ-PAGEBASE)) >> 1)
/** The amount of space remaining in the page */
-#define SIZELEFT(p) (indx_t)((p)->mp_upper - (p)->mp_lower)
+#define SIZELEFT(p) (indx_t)(MP_UPPER(p) - MP_LOWER(p))
/** The percentage of space used in the page, in tenths of a percent. */
#define PAGEFILL(env, p) (1000L * ((env)->me_psize - PAGEHDRSZ - SIZELEFT(p)) / \
@@ -860,15 +875,15 @@ typedef struct MDB_page {
#define FILL_THRESHOLD 250
/** Test if a page is a leaf page */
-#define IS_LEAF(p) F_ISSET((p)->mp_flags, P_LEAF)
+#define IS_LEAF(p) F_ISSET(MP_FLAGS(p), P_LEAF)
/** Test if a page is a LEAF2 page */
-#define IS_LEAF2(p) F_ISSET((p)->mp_flags, P_LEAF2)
+#define IS_LEAF2(p) F_ISSET(MP_FLAGS(p), P_LEAF2)
/** Test if a page is a branch page */
-#define IS_BRANCH(p) F_ISSET((p)->mp_flags, P_BRANCH)
+#define IS_BRANCH(p) F_ISSET(MP_FLAGS(p), P_BRANCH)
/** Test if a page is an overflow page */
-#define IS_OVERFLOW(p) F_ISSET((p)->mp_flags, P_OVERFLOW)
+#define IS_OVERFLOW(p) F_ISSET(MP_FLAGS(p), P_OVERFLOW)
/** Test if a page is a sub page */
-#define IS_SUBP(p) F_ISSET((p)->mp_flags, P_SUBP)
+#define IS_SUBP(p) F_ISSET(MP_FLAGS(p), P_SUBP)
/** The number of overflow pages needed to store the given size. */
#define OVPAGES(size, psize) ((PAGEHDRSZ-1 + (size)) / (psize) + 1)
@@ -936,7 +951,7 @@ typedef struct MDB_node {
#define LEAFSIZE(k, d) (NODESIZE + (k)->mv_size + (d)->mv_size)
/** Address of node \b i in page \b p */
-#define NODEPTR(p, i) ((MDB_node *)((char *)(p) + (p)->mp_ptrs[i] + PAGEBASE))
+#define NODEPTR(p, i) ((MDB_node *)((char *)(p) + MP_PTRS(p)[i] + PAGEBASE))
/** Address of the key for the node */
#define NODEKEY(node) (void *)((node)->mn_data)
@@ -964,6 +979,8 @@ typedef struct MDB_node {
/** Copy a page number from src to dst */
#ifdef MISALIGNED_OK
#define COPY_PGNO(dst,src) dst = src
+#undef MP_PGNO
+#define MP_PGNO(p) ((p)->mp_pgno)
#else
#if SIZE_MAX > 4294967295UL
#define COPY_PGNO(dst,src) do { \
@@ -1554,7 +1571,7 @@ static pgno_t
mdb_dbg_pgno(MDB_page *mp)
{
pgno_t ret;
- COPY_PGNO(ret, mp->mp_pgno);
+ COPY_PGNO(ret, MP_PGNO(mp));
return ret;
}
@@ -1601,13 +1618,13 @@ void
mdb_page_list(MDB_page *mp)
{
pgno_t pgno = mdb_dbg_pgno(mp);
- const char *type, *state = (mp->mp_flags & P_DIRTY) ? ", dirty" : "";
+ const char *type, *state = (MP_FLAGS(mp) & P_DIRTY) ? ", dirty" : "";
MDB_node *node;
unsigned int i, nkeys, nsize, total = 0;
MDB_val key;
DKBUF;
- switch (mp->mp_flags & (P_BRANCH|P_LEAF|P_LEAF2|P_META|P_OVERFLOW|P_SUBP)) {
+ switch (MP_FLAGS(mp) & (P_BRANCH|P_LEAF|P_LEAF2|P_META|P_OVERFLOW|P_SUBP)) {
case P_BRANCH: type = "Branch page"; break;
case P_LEAF:
