Re: Bug#1082603: Should aboot be removed from unstable?
On Mon, 2024-09-23 at 18:49 +0200, John Paul Adrian Glaubitz wrote: > > Not entirely sure it is exactly correct but it does build and does appear > > to put a reasonable set of files into the packages generated. > > That's not the main problem, but the fact that the code cannot be > cross-compiled: > > > https://github.com/mattst88/aboot/issues/5 > > and: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821332 > > aboot-cross depends on aboot-base, but aboot-base can only be fully built on > alpha: > > > https://salsa.debian.org/debian/aboot/-/blob/master/debian/rules?ref_type=heads > > palo does it correctly: > > > https://tracker.debian.org/pkg/palo > > So, it's really not just as trivial as removing one line. If it was, I would > have > done that long ago. To clarify this a little more: The problem is that the aboot-base package can only be built on alpha which means that alpha-cross becomes uninstallable on the other architectures as anything built on alpha is not available for release architectures. So, the proper fix would be to restructure the package such that the contents of aboot-base are made cross-buildable and thus fully available on any architecture which has a cross-compiler for alpha. See also the corresponding bug report for that change in palo: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851792 This particular issue is also part of the Debian Ports TODO list: > https://people.debian.org/~glaubitz/debian-ports-todo.txt So, if anyone is actually willing to help, please do. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1082603: Should aboot be removed from unstable?
On Mon, 2024-09-23 at 11:58 -0400, Lennart Sorensen wrote: > > Fixing this bug requires a little more work and effort and it's on my TODO > > list. But since I am mostly doing this as a one-man show at the moment, it > > takes a little longer. > > Well doing this makes it compile on amd64 for me. > > diff -ru aboot-1.0~pre20200212/debian/compat > aboot-1.0~pre20200212.patched/debian/compat > --- aboot-1.0~pre20200212/debian/compat 2020-03-07 05:33:09.0 -0500 > +++ aboot-1.0~pre20200212.patched/debian/compat 2024-09-23 11:51:00.072830809 > -0400 > @@ -1 +1 @@ > -9 > +10 > diff -ru aboot-1.0~pre20200212/debian/rules > aboot-1.0~pre20200212.patched/debian/rules > --- aboot-1.0~pre20200212/debian/rules 2020-03-07 06:10:21.0 -0500 > +++ aboot-1.0~pre20200212.patched/debian/rules 2024-09-23 11:52:03.572991961 > -0400 > @@ -42,6 +42,7 @@ > $(MAKE) -C srmbootfat srmbootfat srmbootfat.1 CC=$(CC) $(shell > dpkg-buildflags --export=configure) > $(MAKE) -C doc/man > $(MAKE) -C doc/man/de > + $(MAKE) -C doc/faq > rename 's/([a-z]*).([1,5,8])/\1.de.\2/' doc/man/de/*.[1,5,8] > endif > > > Not entirely sure it is exactly correct but it does build and does appear > to put a reasonable set of files into the packages generated. That's not the main problem, but the fact that the code cannot be cross-compiled: > https://github.com/mattst88/aboot/issues/5 and: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821332 aboot-cross depends on aboot-base, but aboot-base can only be fully built on alpha: > https://salsa.debian.org/debian/aboot/-/blob/master/debian/rules?ref_type=heads palo does it correctly: > https://tracker.debian.org/pkg/palo So, it's really not just as trivial as removing one line. If it was, I would have done that long ago. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1082603: Should aboot be removed from unstable?
Control: tags -1 + wontfix Hello Helmut, On Mon, 2024-09-23 at 05:51 +, Helmut Grohne wrote: > I suggest removing aboot from Debian for the following reasons: > * It accumulated one RC-bug: >+ #805988: aboot: FTBFS on amd64 when built with dpkg-buildpackage -A > Last modified: 1 year, 3 months > > * It is not part of bookworm or trixie and is not a key package. It's a key package for booting Debian on alpha, so we absolutely need it. Fixing this bug requires a little more work and effort and it's on my TODO list. But since I am mostly doing this as a one-man show at the moment, it takes a little longer. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
Hi Ulrich,
On Fri, 2024-05-10 at 23:19 +0200, Arnd Bergmann wrote:
> The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7:
>
> Linux 6.9-rc3 (2024-04-07 13:22:46 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
> tags/asm-generic-alpha
>
> for you to fetch changes up to a4184174be36369c3af8d937e165f28a43ef1e02:
>
> alpha: drop pre-EV56 support (2024-05-06 12:05:00 +0200)
>
>
> alpha: cleanups and build fixes
>
> I had investigated dropping support for alpha EV5 and earlier a while
> ago after noticing that this is the only supported CPU family
> in the kernel without native byte access and that Debian has already
> dropped support for this generation last year [1] in order to
> improve performance for the newer machines.
>
> This topic came up again when Paul E. McKenney noticed that
> parts of the RCU code already rely on byte access and do not
> work on alpha EV5 reliably, so we decided on using my series to
> avoid the problem entirely.
>
> Al Viro did another series for alpha to address all the known build
> issues. I rebased his patches without any further changes and included
> it as a baseline for my work here to avoid conflicts and allow
> backporting the fixes to stable kernels for the now removed hardware
> support as well.
>
>
> Al Viro (9):
> alpha: sort scr_mem{cpy,move}w() out
> alpha: fix modversions for strcpy() et.al.
> alpha: add clone3() support
> alpha: don't make functions public without a reason
> alpha: sys_sio: fix misspelled ifdefs
> alpha: missing includes
> alpha: core_lca: take the unused functions out
> alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest
> alpha: trim the unused stuff from asm-offsets.c
>
> Arnd Bergmann (5):
> alpha: remove DECpc AXP150 (Jensen) support
> alpha: sable: remove early machine support
> alpha: remove LCA and APECS based machines
> alpha: cabriolet: remove EV5 CPU support
> alpha: drop pre-EV56 support
There are currently efforts to remove kernel support for older Alpha machines
before EV56 such as the Jensen machines and I was wondering what the current
status of the Linux kernel on your machine was.
Arnd and Paul claim it's broken and no longer works, but not too long ago you
confirmed that Linux 5.14 booted fine on your machine.
Do you have any current data?
Thanks,
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
Re: Bug#1059870: aboot: Please help testing dropping a.out.h support
On Tue, 2024-01-02 at 18:07 +, Dimitri John Ledkov wrote: > For cross building, as far as I can tell one needs to build the tool > twice - once for the BUILD architecture and once for HOST > architecture, use one during the build and package the other one into > the deb. That's correct and I am currently pondering over a clever way to do that. > > I will most likely just copy the relevant definitions out of aout.h, both > > the generic and the alpha-specific stuff in order to both be able to drop > > reliance on aout.h in the kernel as well as make the package fully cross- > > buildable. > > But why? as far as I can tell, the a.out code path is never executed > as it seems like Debian has been using ELF based vmlinuz since like > before 2009. Are you sure that the a.out codepath of objstrip.c is > needed or executed at all? > > Or am I missing something, and like objstrip.c portions are executed > against some other a.out formatted things which are not Linux kernel? > > Should I provide a patch that adds printfs during a.out codepath > block, to see if it actually is ever executed? I think it's still reasonable to keep a.out support in the tool because users might use it for a.out binaries generated from other tools. Besides, it's just a matter of copying a few header definitions, so not really a blocker unless I am missing something. > > > > I would also prefer to get all relevant changes upstreamed. > > > > Upstream has policy of not carrying dead code, which in this case its > what it is for kernels built in like last decade. I was talking about aboot upstream which is maintained by Matt Turner from Gentoo these days [1]. Adrian > [1] https://github.com/mattst88/aboot/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1059870: aboot: Please help testing dropping a.out.h support
Hi Dimitri! On Tue, 2024-01-02 at 17:37 +, Dimitri John Ledkov wrote: > a.out support has been dropped in upstream kernel. However a.out.h > header is still being using by abootimg tool via objstrip.c. It has > support for both a.out image types and ELF. I have blidly dropped > a.out.h support and made ELF support mandatory in > https://lore.kernel.org/all/20231123180246.750674-2-dimitri.led...@canonical.com/ > but I have no way to build it for alpha or test if everything still > works. Upgrades, installed systems, and cd-boot. > > Could you please consider the attached NMU, build it and test it, and > let me know if everything still works. Cause then a.out.h header can > be removed from upstream linux kernel on all architectures. I have actually already looked into patching aboot myself to deal with the aout.h issue since I want to make the bootloader fully cross-buildable [1]. I will most likely just copy the relevant definitions out of aout.h, both the generic and the alpha-specific stuff in order to both be able to drop reliance on aout.h in the kernel as well as make the package fully cross- buildable. I would also prefer to get all relevant changes upstreamed. Thanks, Adrian > [1] https://github.com/mattst88/aboot/issues/5 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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
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
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
Re: Linux 6.1.27, cgroup: Instruction fault 4 with systemd
Hello Frank! On Mon, 2023-05-22 at 11:34 +0200, Frank Scheiner wrote: > Maybe someone on linux-alpha has an idea what could be the reason? Try reproducing it with libcgroup to see if it's a systemd or a kernel bug: > https://wiki.archlinux.org/title/cgroups#Examples Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd 252.6-1 produces an Instruction fault, sysvinit works
Hello Frank! On Thu, 2023-05-18 at 13:01 +0200, Frank Scheiner wrote: > subject says it all: I yesterday upgraded my root FS(es) on my DS25 and > noticed the following issue with the systemd version right where the > login prompt should appear (I seem to remember that I recognized > something similar already late last year with a self-compiled kernel but > attributed it to the kernel being self-compiled): > > ``` > aboot: Linux/Alpha SRM bootloader version 1.0_pre20040408 > aboot: switching to OSF/1 PALcode version 1.92 > aboot: loading initrd (5376720 bytes/10502 blocks) at 0xfc00ffacc000 > aboot: starting kernel network with arguments root=/dev/nfs > ip=:enP2p2s5:dhcp console=ttyS0,9600n8 > [0.00] Linux version 6.1.0-9-alpha-smp > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU > ld (GNU Binutils for Debian) 2.40) #1 SMP Debian > 6.1.27-1 (2023-05-08) > [0.00] Booting GENERIC on Titan variation Granite using machine > vector PRIVATEER from SRM > [0.00] Major Options: SMP MAGIC_SYSRQ > [0.00] Command line: root=/dev/nfs ip=:enP2p2s5:dhcp > console=ttyS0,9600n8 > [...] > Begin: Running /scripts/nfs-bottom ... done. > Begin: Running /scripts/init-bottom ... done. > [9.820307] systemd[1]: systemd 252.6-1 running in system mode (+PAM > +AUDIT +SELINUX +APPARMOR +IMA +SMACK -SECCOMP +GCRYPT -GNUTLS +OPENSSL > +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP > +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ > +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT > default-hierarchy=unified) > [ 10.202143] systemd[1]: Detected architecture alpha. > > Welcome to Debian GNU/Linux 12 (bookworm)! > > [ 11.864251] systemd[1]: Queued start job for default target > graphical.target. > [ 11.958978] CPU 1 > [ 11.958978] systemd(1): Instruction fault 4 > [ 12.032220] pc = [] ra = [] ps > = Not tainted > [ 12.131829] pc is at 0xfc0005163bfc > [ 12.177728] ra is at 0xfc0005163bf8 > [ 12.223626] v0 = t0 = 0023 t1 = > fc00066eb800 > [ 12.310540] t2 = fc000512e680 t3 = 00f0 t4 = > 0008 > [ 12.398431] t5 = 0001 t6 = t7 = > fc000516 > [ 12.486321] a0 = a1 = fc0005163bc0 a2 = > fc0005163bf8 > [ 12.573235] a3 = 0001 a4 = 0002c8cf86cc a5 = > 0001 > [ 12.661126] t8 = 0080 t9 = 0001 t10= > fc0002891148 > [ 12.749016] t11= pv = fc00011d4a40 at = > 5f19e10505e118bf > [ 12.835930] gp = fc0002871148 sp = 440a695e > [ 12.899407] Disabling lock debugging due to kernel taint > [ 12.962883] Trace: > [ 12.987298] [] cgroup_migrate_execute+0x338/0x600 > [ 13.062493] [] cgroup_update_dfl_csses+0x2c8/0x330 > [ 13.138665] [] cgroup_subtree_control_write+0x56c/0x5e0 > [ 13.219719] [] cgroup_file_write+0xa4/0x1a0 > [ 13.288079] [] kernfs_fop_write_iter+0x1a4/0x330 > [ 13.362297] [] vfs_write+0x250/0x4c0 > [ 13.423821] [] ksys_write+0x8c/0x140 > [ 13.485344] [] entSys+0xac/0xc0 > [ 13.541985] > [ 13.559563] Code: > [ 13.559563] fc00 > [ 13.582024] > [ 13.610344] > [ 13.638664] 05163bfc > [ 13.666985] fc00 > [ 13.695305] 02871148 > [ 13.723625] > [ 13.751946] > [ 13.779289] > ``` > > With the sysvinit version of the root FS and initramfs everything works > (did some `7z b` runs and an `openssl speed -elapsed` w/o an issue after > booting, too): As you can see from the backtrace, the issue is triggered somewhere in the CGroup code. Since SysVInit doesn't use CGroups, it's not surprising that you don't see the backtrace there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
Hi Michael! On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote: > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote: > > After a long discussion on IRC and the mailing list, we have agreed to > > raise the > > baseline for the alpha architecture to EV56 to improve the generated code > > and fix > > a number of issues. The change is already being implemented in the glibc > > packages > > which switches to EV56 [1] since hwcaps are no longer available with glibc > > 2.37 [2]. > > > > Could you raise the baseline for gcc on alpha to EV56? > > > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". > > Yes, please! > > I suggest the following in debian/rules2: > > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH))) > CONFARGS += --with-cpu=ev56 --with-tune=ev6 > endif > > (the --with-tune only affects instruction scheduling and better tunes > code for ev6 and more recent machines, but allows execution down to > ev56.) I have tested this in the past with a rebuild of most packages > that are in the base essential chroot in the past and it works well. Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is currently the baseline for QEMU when emulating Alpha. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
Source: gcc-13 Version: 13.1.0-2 Severity: normal User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! After a long discussion on IRC and the mailing list, we have agreed to raise the baseline for the alpha architecture to EV56 to improve the generated code and fix a number of issues. The change is already being implemented in the glibc packages which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2]. Could you raise the baseline for gcc on alpha to EV56? I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56". Thanks, Adrian > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/7af7b56d5f5fef7a4f3c011b36774e4556563d3d > [2] > https://salsa.debian.org/glibc-team/glibc/-/commit/4d57b6af3efd1d6af277b2eb67fe9ee500e7ae68 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: future of the libc6.1-alphaev67 package
Hi Aurelien! On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote: > On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote: > > Hello! > > > > On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote: > > > Therefore the libc6.1-alphaev67 package will be removed from the debian > > > package with glibc 2.37. We can take the opportunity to raise the > > > baseline if needed. > > > > I think we agreed on raising it to EV56, didn't we? > > It was not clear to me from the current thread, but I guess the > discussion have been continued somewhere else. > > Could you please take care of raising the baseline at the GCC level? In > the meantime, I'll force -mcpu=ev56 at the glibc level. Yes, absolutely. I will file a bug report against GCC asking for the baseline raise. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: future of the libc6.1-alphaev67 package
Hello! On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote: > Therefore the libc6.1-alphaev67 package will be removed from the debian > package with glibc 2.37. We can take the opportunity to raise the > baseline if needed. I think we agreed on raising it to EV56, didn't we? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS
Source: libdeflate Version: 1.14-1 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hi! libdeflate currently FTBFS on alpha due to linker issues: cc -o libdeflate.so.0 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -fprofile-generate -O2 -fomit-frame-pointer -std=c99 -I. -Wall -Wundef -Wdeclaration-after-statement -Wimplicit-fallthrough -Wmissing-prototypes -Wpedantic -Wshadow -Wstrict-prototypes -Wvla -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security -fprofile-generate -fvisibility=hidden -D_ANSI_SOURCE \ -Wl,-soname=libdeflate.so.0 -shared lib/deflate_decompress.shlib.o lib/utils.shlib.o lib/arm/cpu_features.shlib.o lib/x86/cpu_features.shlib.o lib/deflate_compress.shlib.o lib/adler32.shlib.o lib/zlib_decompress.shlib.o lib/zlib_compress.shlib.o lib/crc32.shlib.o lib/gzip_decompress.shlib.o lib/gzip_compress.shlib.o lib/deflate_compress.shlib.o: in function `deflate_choose_match': ./lib/deflate_compress.c:2185:(.text+0x832c): relocation truncated to fit: GPRELHIGH against `.rodata' ./lib/deflate_compress.c:2185:(.text+0xa28c): relocation truncated to fit: GPRELHIGH against `.rodata' ./lib/deflate_compress.c:2185:(.text+0xbfa0): relocation truncated to fit: GPRELHIGH against `.rodata' collect2: error: ld returned 1 exit status This problem can be worked around by building the source -O1 which is what the attached patch does. Could you apply it for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libdeflate&arch=alpha&ver=1.14-1&stamp=1673418504&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-10-03 13:55:19.0 +0200 +++ debian/rules2023-01-13 16:48:12.970221727 +0100 @@ -4,6 +4,10 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all +ifeq (alpha,$(DEB_HOST_ARCH)) + export DEB_CFLAGS_MAINT_APPEND=-O1 +endif + %: dh $@
Re: Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64
Hi! On 1/11/23 19:45, John Paul Adrian Glaubitz wrote: Attaching a patch which modifies debian/rules accordingly so that the build dependencies are corrected after running "debian/rules debian/control". Please consider including it for the next upload. Oops, I just realized I forgot to add the line for "llvm". Please find an updated patch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-12-29 23:21:43.0 + +++ debian/rules 2023-01-11 18:53:56.537857661 + @@ -688,7 +688,7 @@ else ifeq "$(ALLOW_CLANG)" "y" ifeq "$(CLANG_VERSION)" "default" - BUILD_DEPS += , llvm [$(OOO_LE_ARCHS)] + BUILD_DEPS += , llvm [$(filter-out alpha ia64,$(OOO_LE_ARCHS))] else BUILD_DEPS += , llvm-$(CLANG_VERSION)-linker-tools [$(OOO_LE_ARCHS)] endif @@ -766,7 +766,7 @@ ifeq "$(CLANG_VERSION)" "default" export LO_CLANG_CC=clang export LO_CLANG_CXX=clang++ - BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))] + BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))] # see #963162, #963167 which apparently don't exist on 11 BUILD_DEPS += , clang (>= 1:11) [armel] else
Re: Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64
Control: tags -1 +patch Hi! Attaching a patch which modifies debian/rules accordingly so that the build dependencies are corrected after running "debian/rules debian/control". Please consider including it for the next upload. Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-12-29 23:21:43.0 + +++ debian/rules 2023-01-11 18:40:30.535026543 + @@ -766,7 +766,7 @@ ifeq "$(CLANG_VERSION)" "default" export LO_CLANG_CC=clang export LO_CLANG_CXX=clang++ - BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))] + BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))] # see #963162, #963167 which apparently don't exist on 11 BUILD_DEPS += , clang (>= 1:11) [armel] else
Bug#1028200: glibc: FTBFS on alpha due to buggy GL(dl_phdr) and GL(dl_phnum) [BZ #29864]
Source: glibc
Version: 2.36-8
Severity: normal
Tags: patch upstream
User: debian-alpha@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-alpha@lists.debian.org
Hello!
glibc fails to build from source on alpha with many testsuite failures [1]
due to a regression introduced in glibc 2.34 [2].
According to the discussion on the libc-alpha mailing list, this issue
affects multiple architectures for static builds. It just happens that
it causes segmentation faults on alpha [3].
A proposed patch by Adhemveral Zanella has been posted on the list [4]
but not been merged yet. I tested the first version of the patch [3] and
can confirm that it works. I will test the posted version [4] now.
Adhemerval said that he plans to backport the patch down to 2.34, so it
will eventually show up in 2.36 as well. Either way, it might be a good
idea to already carry the patch in Debian but I'm not sure.
Thanks,
Adrian
> [1] https://buildd.debian.org/status/logs.php?pkg=glibc&arch=alpha
> [2] https://sourceware.org/pipermail/libc-alpha/2023-January/15.html
> [3] https://sourceware.org/pipermail/libc-alpha/2023-January/144452.html
> [4] https://sourceware.org/pipermail/libc-alpha/2023-January/144457.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- Begin Message ---
The 73fc4e28b9464f0e refactor did not add the GL(dl_phdr) and
GL(dl_phnum) for static build, relying on the __ehdr_start symbol,
which is always added by the static linker, to get the correct values.
This is problematic in some ways:
- The segment may see its in-memory size differ from its in-file
size (or the binary may have holes). The Linux has fixed is to
provide concise values for both AT_PHDR and AT_PHNUM (commit
0da1d5002745c - "fs/binfmt_elf: Fix AT_PHDR for unusual ELF files")
- Some archs (alpha for instance) the hidden weak reference is not
correctly pulled by the static linker and __ehdr_start address
end up being 0, which makes GL(dl_phdr) and GL(dl_phnum) have both
invalid values (and triggering a segfault later on libc.so while
accessing TLS variables).
The safer fix is to just restore the previous behavior to setup
GL(dl_phdr) and GL(dl_phnum) for static based on kernel auxv. The
__ehdr_start fallback can also be simplified by not assuming weak
linkage (as for PIE).
The libc-static.c auxv init logic is moved to dl-support.c, since
the later is build without SHARED and then GLRO macro is defined
to access the variables directly.
The _dl_phdr is also assumed to be always non NULL, since an invalid
NULL values does not trigger TLS initialization (which is used in
various libc systems).
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
---
csu/libc-start.c| 21 --
csu/libc-tls.c | 25 ++--
elf/dl-support.c| 52 -
sysdeps/unix/sysv/linux/dl-parse_auxv.h | 1 +
4 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/csu/libc-start.c b/csu/libc-start.c
index 543560f36c..bfeee6d851 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -262,28 +262,7 @@ LIBC_START_MAIN (int (*main) (int, char **, char **
MAIN_AUXVEC_DECL),
}
# endif
_dl_aux_init (auxvec);
- if (GL(dl_phdr) == NULL)
# endif
-{
- /* Starting from binutils-2.23, the linker will define the
- magic symbol __ehdr_start to point to our own ELF header
- if it is visible in a segment that also includes the phdrs.
- So we can set up _dl_phdr and _dl_phnum even without any
- information from auxv. */
-
- extern const ElfW(Ehdr) __ehdr_start
-# if BUILD_PIE_DEFAULT
- __attribute__ ((visibility ("hidden")));
-# else
- __attribute__ ((weak, visibility ("hidden")));
- if (&__ehdr_start != NULL)
-# endif
-{
- assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr));
- GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff;
- GL(dl_phnum) = __ehdr_start.e_phnum;
-}
-}
__tunables_init (__environ);
diff --git a/csu/libc-tls.c b/csu/libc-tls.c
index ca4def2613..51d3cf99bf 100644
--- a/csu/libc-tls.c
+++ b/csu/libc-tls.c
@@ -119,19 +119,18 @@ __libc_setup_tls (void)
__tls_pre_init_tp ();
/* Look through the TLS segment if there is any. */
- if (_dl_phdr != NULL)
-for (phdr = _dl_phdr; phdr < &_dl_phdr[_dl_phnum]; ++phdr)
- if (phdr->p_type == PT_TLS)
- {
- /* Remember the values we need. */
- memsz = phdr->p_memsz;
- filesz = phdr->p_filesz;
- initimage = (void *) phdr->p_vaddr + main_map->l_addr;
- align = phdr->p_align;
- if (phdr->p_align > max_align)
- max_align = phdr->p_alig
Re: Unversioned symbols when building kernel package
Hi Ben! On 1/5/23 17:39, John Paul Adrian Glaubitz wrote: I noticed that the object files for these 4 functions are handled specially at the bottom of arch/alpha/lib/Makefile, and that interacts badly with this change to modpost. The attached patch fixes this for me, but please test it to check that the output actually works. I'll test the patch and report back as soon as possible! I can confirm that your patch fixes the FTBFS for me and the package builds fine. Would be great if the patch could be part of the next Debian revision of the kernel so I can build the kernel package manually to unbreak the dependency cycle. Build Architecture: alpha Build Profiles: nocheck Build Type: any Build-Space: 31984520 Build-Time: 32932 Distribution: sid Host Architecture: alpha Install-Time: 63 Job: /local_scratch/glaubitz/linux/linux_6.0.12-1.dsc Lintian: error Machine Architecture: amd64 Package: linux Package-Time: 33070 Source-Version: 6.0.12-1 Space: 31984520 Status: successful Version: 6.0.12-1 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Unversioned symbols when building kernel package
Hi Ben! On 1/5/23 17:15, Ben Hutchings wrote: From the Debian build logs, this regressed between 5.18 and 5.19. I have bisected this to: commit f292d875d0dc700b3af0bef04c5abc1dc7b3b62c Author: Masahiro Yamada Date: Fri May 13 20:39:21 2022 +0900 modpost: extract symbol versions from *.cmd files Following this, although the 4 problem symbols have CRCs listed in their respective cmd files (arch/alpha/.strcat.o.cmd etc.) those don't end up in Modules.symvers. Awesome, thanks for the work! I noticed that the object files for these 4 functions are handled specially at the bottom of arch/alpha/lib/Makefile, and that interacts badly with this change to modpost. The attached patch fixes this for me, but please test it to check that the output actually works. I'll test the patch and report back as soon as possible! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Unversioned symbols when building kernel package
Hi Frank!
On 1/4/23 23:31, John Paul Adrian Glaubitz wrote:
Looking at [4] the message "Can't read ABI reference." could indicate a missing
file - filename
is defined in line 51 ([5]) and `/debian/abi/` does not exist in [3].
I don't think it's a bug in the Debian scripts. Otherwise it wouldn't just
affect alpha.
Some more diagnostics, it seems that the sh4 FTBFS is related to the alpha
problem.
On sh4, the builds are also failing due to issues with local symbols [1]:
/<>/scripts/check-local-export fs/reiserfs/xattr_security.o
/<>/scripts/check-local-export: line 54: symbol_types[${name}]:
bad array subscript
make[5]: *** [/<>/scripts/Makefile.build:254:
fs/reiserfs/xattr_security.o] Error 1
make[5]: *** Deleting file 'fs/reiserfs/xattr_security.o'
make[4]: *** [/<>/scripts/Makefile.build:470: fs/reiserfs] Error 2
make[3]: *** [/<>/Makefile:1876: fs] Error 2
And for a local build, I'm getting the following failure:
/<>/scripts/check-local-export fs/unicode/utf8-core.o
fs/unicode/utf8-core.o: error: local symbol '__ksymtab_utf8_casefold' was
exported
make[5]: *** [/<>/scripts/Makefile.build:254:
fs/unicode/utf8-core.o] Error 1
make[5]: *** Deleting file 'fs/unicode/utf8-core.o'
make[4]: *** [/<>/scripts/Makefile.build:470: fs/unicode] Error 2
make[4]: *** Waiting for unfinished jobs
So, we might have to investigate the recent changes to the
scripts/check-local-export script.
Adrian
[1]
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=6.0.2-1&stamp=1665950645&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1027974: linux: FTBFS on alpha due to unversioned symbols
Source: linux Version: 6.0.12-1 Severity: normal User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! Since upstream version 5.19.x, src:linux FTBFS on alpha due to unversioned symbols [1]: > ABI is not completely versioned! Refusing to continue. > Unversioned symbols: > strcat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strcpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncat module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > strncpy module: vmlinux, version: > 0x, export: EXPORT_SYMBOL > Can't read ABI reference. ABI not checked! A local build showed that this is still present in the latest package version 6.0.12-1. According to this comment [2], this issue can be fixed by adding the appropriate include to arch/$ARCH/include/asm/asm-prototypes.h but the include for is already present, so I'm not sure what the actual problem is. I'm reporting this issue to hopefully get some feedback on what else to try to fix this issue. I'm happy to provide any patches once I know what to fix. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=alpha&ver=5.19.6-1&stamp=1663530012&raw=0 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Update on the glibc segfault issue on Alpha
Hi Adhemveral! On 1/4/23 13:00, Adhemerval Zanella Netto wrote: I can confirm that this patch fixes the problem for me. I have uploaded a manually built glibc package with the patch applied to Debian »unreleased« so that the buildds can resume building packages again. Would it be possible to backport this patch to 2.36 once it has been merged with the current development tree? The reason is that I don't think that Debian is going to switch to anything beyond 2.36 anytime soon due to the upcoming feature freeze in January. I have sent a more detailed patch [1] and I will probably backport to all affected releases once it is accepted. Great, thanks a lot! This means, the fix will eventually be available in Debian and we won't have to carry the patch for a long time. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Unversioned symbols when building kernel package
Hi! On 1/4/23 23:00, Frank Scheiner wrote: According to this comment by Ben [1], this is an issue that is trivially fixed by adding the appropriate header to arch/$ARCH/include/asm-prototypes.h. However, looking at the header file, "#include " is already present so I'm not sure what else we're missing. Indeed, and that file ([1]) wasn't touched in 5 years. I wonder if that then is not an error of the Debian build scripts. [1]: https://github.com/torvalds/linux/blob/master/arch/alpha/include/asm/string.h That's not really an argument. It's also possible that the file needs to be updated. BTW the same error is already present for 5.19.6-1 - the build ran on 2022-09-18. Maybe the error corresponds with a change in the Debian linux repo ([3]) before that date. Looking at [4] the message "Can't read ABI reference." could indicate a missing file - filename is defined in line 51 ([5]) and `/debian/abi/` does not exist in [3]. I don't think it's a bug in the Debian scripts. Otherwise it wouldn't just affect alpha. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Unversioned symbols when building kernel package
Hello! I just tried to build the Debian kernel package for alpha which fails with: debian/bin/buildcheck.py debian/build/build_alpha_none_alpha-generic alpha none alpha-generic ABI is not completely versioned! Refusing to continue. Unversioned symbols: strcat module: vmlinux, version: 0x, export: EXPORT_SYMBOL strcpy module: vmlinux, version: 0x, export: EXPORT_SYMBOL strncat module: vmlinux, version: 0x, export: EXPORT_SYMBOL strncpy module: vmlinux, version: 0x, export: EXPORT_SYMBOL Can't read ABI reference. ABI not checked! make[2]: *** [debian/rules.real:218: debian/stamps/build_alpha_none_alpha-generic] Error 1 make[2]: Leaving directory '/<>' make[1]: *** [debian/rules.gen:426: build-arch_alpha_none_alpha-generic_real] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:39: build-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 According to this comment by Ben [1], this is an issue that is trivially fixed by adding the appropriate header to arch/$ARCH/include/asm-prototypes.h. However, looking at the header file, "#include " is already present so I'm not sure what else we're missing. Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Update on the glibc segfault issue on Alpha
Hi Adhemerval!
On 1/3/23 13:09, Adhemerval Zanella Netto wrote:
Thanks, this commits helps narrow down the issue. The 73fc4e28b9464f0e
refactor did not
add the GL(dl_phdr) and GL(dl_phnum) for static case, relying on the
__ehdr_start symbol
to get the correct values.
The issue is for some archs, alpha for instance, the hidden weak reference is
not making
the static linker to define the __ehdr_start address correctly: it is being set
to 0 and
thus GL(dl_phdr) and GL(dl_phnum) are set to invalid values.
And I am not sure if the hidden weak __ehdr_start does work on all
architectures, so I
think it would be safer to just restore the previous behavior to setup
GL(dl_phdr) and
GL(dl_phnum) for static and we can simplify __ehdr_start fallback case to not
use
a weak ref (as for PIE). I am checking if the following patch trigger any
regression,
at least for alpha it fixes the static failures:
diff --git a/csu/libc-start.c b/csu/libc-start.c
index 543560f36c..63a3eceaea 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -271,18 +271,10 @@ LIBC_START_MAIN (int (*main) (int, char **, char **
MAIN_AUXVEC_DECL),
So we can set up _dl_phdr and _dl_phnum even without any
information from auxv. */
- extern const ElfW(Ehdr) __ehdr_start
-# if BUILD_PIE_DEFAULT
- __attribute__ ((visibility ("hidden")));
-# else
- __attribute__ ((weak, visibility ("hidden")));
- if (&__ehdr_start != NULL)
-# endif
-{
- assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr));
- GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff;
- GL(dl_phnum) = __ehdr_start.e_phnum;
-}
+ extern const ElfW(Ehdr) __ehdr_start attribute_hidden;
+ assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr));
+ GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff;
+ GL(dl_phnum) = __ehdr_start.e_phnum;
}
__tunables_init (__environ);
diff --git a/sysdeps/unix/sysv/linux/dl-parse_auxv.h
b/sysdeps/unix/sysv/linux/dl-parse_auxv.h
index bf9374371e..5913c9d6e5 100644
--- a/sysdeps/unix/sysv/linux/dl-parse_auxv.h
+++ b/sysdeps/unix/sysv/linux/dl-parse_auxv.h
@@ -56,6 +56,10 @@ void _dl_parse_auxv (ElfW(auxv_t) *av, dl_parse_auxv_t
auxv_values)
if (GLRO(dl_sysinfo_dso) != NULL)
GLRO(dl_sysinfo) = auxv_values[AT_SYSINFO];
#endif
+#ifndef SHARED
+ GL(dl_phdr) = (void*) auxv_values[AT_PHDR];
+ GL(dl_phnum) = auxv_values[AT_PHENT];
+#endif
DL_PLATFORM_AUXV
}
I can confirm that this patch fixes the problem for me. I have uploaded a
manually built glibc
package with the patch applied to Debian »unreleased« so that the buildds can
resume building
packages again.
Would it be possible to backport this patch to 2.36 once it has been merged
with the current
development tree? The reason is that I don't think that Debian is going to
switch to anything
beyond 2.36 anytime soon due to the upcoming feature freeze in January.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Update on the glibc segfault issue on Alpha
Hello! On 1/2/23 12:44, John Paul Adrian Glaubitz wrote: Adhemerval from glibc upstream is aware of the problem but he has not found yet a solution to this issue as it needs to be debugged further. I will try to bisect which particular introduced the regression and file a new upstream bug report. During our discussion, Adhemerval pointed out that this change [3] might be the culprit but I have not been able to verify this yet. My latest bisecting has shown this change to be the responsible change, CC'ing the author: commit 73fc4e28b9464f0e13edc719a5372839970e7ddb (refs/bisect/bad) Author: Florian Weimer Date: Mon Feb 28 11:50:41 2022 +0100 Linux: Consolidate auxiliary vector parsing (redo) And optimize it slightly. This is commit 8c8510ab2790039e58995ef3a22309582413d3ff revised. In _dl_aux_init in elf/dl-support.c, use an explicit loop and -fno-tree-loop-distribute-patterns to avoid memset. Reviewed-by: Szabolcs Nagy Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Update on the glibc segfault issue on Alpha
Hello! Just a quick update on the glibc issue we're seeing on Alpha! My previous bisecting result was wrong and the segfault I ran into was the result of combining ld.so and libc.so files from different builds by not including all necessary paths in my LD_LIBRARY_PATH. So, my previously reported bug report was invalid [1]. However, as can be seen from the build logs, there are still clearly issues with the testsuite [2]. Further analysis showed that the problem are static binaries which segfault. Anything dynamically linked, works. This becomes obvious when building the glibc Debian package manually with the testsuite disabled and then installing these packages inside a test chroot. While the libc-bin package is being configured, ldconfig is run - a statically linked binary - and crashes with a segfault. Adhemerval from glibc upstream is aware of the problem but he has not found yet a solution to this issue as it needs to be debugged further. I will try to bisect which particular introduced the regression and file a new upstream bug report. During our discussion, Adhemerval pointed out that this change [3] might be the culprit but I have not been able to verify this yet. Adrian [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29899 [2] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.36-6&stamp=1669706903&raw=0 [3] https://sourceware.org/pipermail/glibc-cvs/2020q2/069444.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hello! I have not been able to identify the commit that introduced the floating point issue. However, I seem to have found what fixes the segfault properly and also another fix for a third problem, see below. FWIW, Adhemeveral told me he would be looking into the glibc issues on alpha in the following days. Currently, I am out of ideas myself. Adrian === Issue: (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash /bin/bash: symbol lookup error: /home/glaubitz/glibc-git/build/libc.so.6.1: undefined symbol: _dl_audit_preinit, version GLIBC_PRIVATE (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ Fixed by: commit 144761540a1e40b85997d195d9a226a500531dc9 Author: Adhemerval Zanella Date: Thu Jan 13 18:04:49 2022 -0300 elf: Remove LD_USE_LOAD_BIAS It is solely for prelink with PIE executables [1]. [1] https://sourceware.org/legacy-ml/libc-hacker/2003-11/msg00127.html Reviewed-by: Siddhesh Poyarekar Issue: (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash Segmentation fault (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ Fixed by: commit 0b98a8748759e88b58927882a8714109abe0a2d6 Author: Adhemerval Zanella Date: Thu Jul 22 17:10:57 2021 -0300 elf: Add _dl_audit_preinit It consolidates the code required to call la_preinit audit callback. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Florian Weimer csu/libc-start.c | 23 +++ elf/Versions | 2 +- elf/dl-audit.c | 15 +++ sysdeps/generic/ldsodefs.h | 3 +++ 4 files changed, 22 insertions(+), 21 deletions(-) Issue: (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash Floating point exception (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ Introduced by: (not found) -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hello! On 12/15/22 09:09, John Paul Adrian Glaubitz wrote: If your glibc fails with Floating Point exception, I fear there might be a second bug hiding somewhere which we need to bisect as well. This is particularly annoying since we would have to apply the above diff for every bisecting step. FWIW, I'm still working on this issue and made some progress. Apparently, the segfault was fixed somewhere in the 2.36 development cycle but on the other hand, the floating point exception issue was introduced. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi!
On 12/15/22 10:49, Frank Scheiner wrote:
Maybe adding [1] might help, but the patch actually removes it.
It's missing this hunk:
diff --git a/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
b/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
index 64d450b22c..4552e77d59 100644
--- a/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
+++ b/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
@@ -21,7 +21,7 @@
static long int
sysconf_sigstksz (void)
{
- long int minsigstacksize = GLRO(dl_minsigstacksize);
+ long int minsigstacksize = 4096 ; //GLRO(dl_minsigstacksize);
assert (minsigstacksize != 0);
_Static_assert (__builtin_constant_p (MINSIGSTKSZ),
"MINSIGSTKSZ is constant");
I was experimenting with a custom sysconf-sigstksz.h like on ia64 which I
forgot to purge, sorry.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi! On 12/14/22 21:44, Frank Scheiner wrote: I'm attaching the second diff as a patch. I think there's some whitespace difference. I manually applied the rejected stuff, made a `git diff` and comparing that to your attached patch gives: Or just use the attached patch file from my previous mail. If your glibc fails with Floating Point exception, I fear there might be a second bug hiding somewhere which we need to bisect as well. This is particularly annoying since we would have to apply the above diff for every bisecting step. But we'll see. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi!
On 12/14/22 21:16, Frank Scheiner wrote:
I'll do that tomorrow. The thing is that this diff doesn't apply cleanly:
Which version of the workaround diff did you use? There are two.
There is one that applies cleanly on top of
6c57d320484988e87e446e2e60ce42816bf51d53
and a second one that applies cleanly on top of glibc-2.34, I posted both.
There were
some changes between 6c57d320484988e87e446e2e60ce42816bf51d53 and glibc-2.34 in
the
minstksize/stksize code which is why you need the second diff that was also
part of
my mail.
I'm attaching the second diff as a patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
diff --git a/elf/dl-sysdep.c b/elf/dl-sysdep.c
index d47bef1340..8462e5859a 100644
--- a/elf/dl-sysdep.c
+++ b/elf/dl-sysdep.c
@@ -116,10 +116,10 @@ _dl_sysdep_start (void **start_argptr,
user_entry = (ElfW(Addr)) ENTRY_POINT;
GLRO(dl_platform) = NULL; /* Default to nothing known about the platform. */
- /* NB: Default to a constant CONSTANT_MINSIGSTKSZ. */
- _Static_assert (__builtin_constant_p (CONSTANT_MINSIGSTKSZ),
- "CONSTANT_MINSIGSTKSZ is constant");
- GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ;
+ /* /\* NB: Default to a constant CONSTANT_MINSIGSTKSZ. *\/ */
+ /* _Static_assert (__builtin_constant_p (CONSTANT_MINSIGSTKSZ), */
+ /* "CONSTANT_MINSIGSTKSZ is constant"); */
+ /* GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ; */
for (av = GLRO(dl_auxv); av->a_type != AT_NULL; set_seen (av++))
switch (av->a_type)
@@ -185,9 +185,9 @@ _dl_sysdep_start (void **start_argptr,
case AT_RANDOM:
_dl_random = (void *) av->a_un.a_val;
break;
- case AT_MINSIGSTKSZ:
- GLRO(dl_minsigstacksize) = av->a_un.a_val;
- break;
+ /* case AT_MINSIGSTKSZ: */
+ /* GLRO(dl_minsigstacksize) = av->a_un.a_val; */
+ /* break; */
DL_PLATFORM_AUXV
}
diff --git a/elf/rtld_static_init.c b/elf/rtld_static_init.c
index 3f8abb6800..aeac492235 100644
--- a/elf/rtld_static_init.c
+++ b/elf/rtld_static_init.c
@@ -67,9 +67,9 @@ __rtld_static_init (struct link_map *map)
dl->_dl_hwcap = _dl_hwcap;
extern __typeof (dl->_dl_hwcap2) _dl_hwcap2 attribute_hidden;
dl->_dl_hwcap2 = _dl_hwcap2;
- extern __typeof (dl->_dl_minsigstacksize) _dl_minsigstacksize
-attribute_hidden;
- dl->_dl_minsigstacksize = _dl_minsigstacksize;
+ /* extern __typeof (dl->_dl_minsigstacksize) _dl_minsigstacksize */
+ /* attribute_hidden; */
+ /* dl->_dl_minsigstacksize = _dl_minsigstacksize; */
extern __typeof (dl->_dl_pagesize) _dl_pagesize attribute_hidden;
dl->_dl_pagesize = _dl_pagesize;
extern __typeof (dl->_dl_tls_static_align) _dl_tls_static_align
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h
index 9c15259236..62117727e1 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -545,9 +545,6 @@ struct rtld_global_ro
/* Cached value of `getpagesize ()'. */
EXTERN size_t _dl_pagesize;
- /* Cached value of `sysconf (_SC_MINSIGSTKSZ)'. */
- EXTERN size_t _dl_minsigstacksize;
-
/* Do we read from ld.so.cache? */
EXTERN int _dl_inhibit_cache;
diff --git a/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h b/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
index 9e0eb0f7fc..2ba132e1fe 100644
--- a/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
+++ b/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
@@ -22,7 +22,7 @@ static inline long int
__get_pthread_stack_min (void)
{
/* sysconf (_SC_THREAD_STACK_MIN) >= sysconf (_SC_MINSIGSTKSZ). */
- long int pthread_stack_min = GLRO(dl_minsigstacksize);
+ long int pthread_stack_min = 4096;
assert (pthread_stack_min != 0);
_Static_assert (__builtin_constant_p (PTHREAD_STACK_MIN),
"PTHREAD_STACK_MIN is constant");
diff --git a/sysdeps/unix/sysv/linux/sysconf.c b/sysdeps/unix/sysv/linux/sysconf.c
index daaeeb7d36..24afb2fdc5 100644
--- a/sysdeps/unix/sysv/linux/sysconf.c
+++ b/sysdeps/unix/sysv/linux/sysconf.c
@@ -84,11 +84,11 @@ __sysconf (int name)
break;
case _SC_MINSIGSTKSZ:
- assert (GLRO(dl_minsigstacksize) != 0);
- return GLRO(dl_minsigstacksize);
+ // assert (GLRO(dl_minsigstacksize) != 0);
+ return 4096; // GLRO(dl_minsigstacksize);
case _SC_SIGSTKSZ:
- return sysconf_sigstksz ();
+ return 16384 ; //sysconf_sigstksz ();
default:
break;
Re: glibc regression on alpha with 2.34+
Hi!
On 12/14/22 20:46, Frank Scheiner wrote:
```
root@ds15:/srv/storage/build/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67#
CC="alpha-linux-gnu-gcc-12 -mcpu=ev67 -mtune=ev67 "
CXX="alpha-linux-gnu-g++-12 -mcpu=ev67 -mtune=ev67 "
MIG="alpha-linux-gnu-mig" ../../glibc/configure
--host=alphaev67-linux-gnu --disable-werror --prefix=/usr
--disable-sanity-checks
[...]
root@ds15:/srv/storage/build#
LD_LIBRARY_PATH=$PWD/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67
/bin/bash
Segmentation fault
```
Unfortunately it also doesn't work here when optimized for EV67.
OK, this just confirms what my cross-compile tests with "-mcpu=ev67 -mtune=ev67"
where the segfault wasn't fixed either by raising the baseline.
If you have a user account for glibc bugzilla, you should subscribe to the bug
report I opened for this particular issue [1]. H. J. Lu raises a good question,
namely whether alpha has any hardcoded values for "struct rtld_global_ro {}".
Adrian
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29899
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
eneric/ldsodefs.h
index 9720a4e446..9ead714718 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -536,8 +536,8 @@ struct rtld_global_ro
/* Cached value of `getpagesize ()'. */
EXTERN size_t _dl_pagesize;
- /* Cached value of `sysconf (_SC_MINSIGSTKSZ)'. */
- EXTERN size_t _dl_minsigstacksize;
+ /* /\* Cached value of `sysconf (_SC_MINSIGSTKSZ)'. *\/ */
+ /* EXTERN size_t _dl_minsigstacksize; */
/* Do we read from ld.so.cache? */
EXTERN int _dl_inhibit_cache;
Interestingly, when I checkout the tag glibc-2.34 and disabled the
_dl_minsigstacksize symbol
in "struct rtld_global_ro {}" again with the following hack, I'm no longer
getting a segfault
but a floating point exception:
diff --git a/elf/dl-sysdep.c b/elf/dl-sysdep.c
index d47bef1340..8462e5859a 100644
--- a/elf/dl-sysdep.c
+++ b/elf/dl-sysdep.c
@@ -116,10 +116,10 @@ _dl_sysdep_start (void **start_argptr,
user_entry = (ElfW(Addr)) ENTRY_POINT;
GLRO(dl_platform) = NULL; /* Default to nothing known about the platform. */
- /* NB: Default to a constant CONSTANT_MINSIGSTKSZ. */
- _Static_assert (__builtin_constant_p (CONSTANT_MINSIGSTKSZ),
- "CONSTANT_MINSIGSTKSZ is constant");
- GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ;
+ /* /\* NB: Default to a constant CONSTANT_MINSIGSTKSZ. *\/ */
+ /* _Static_assert (__builtin_constant_p (CONSTANT_MINSIGSTKSZ), */
+ /* "CONSTANT_MINSIGSTKSZ is constant"); */
+ /* GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ; */
for (av = GLRO(dl_auxv); av->a_type != AT_NULL; set_seen (av++))
switch (av->a_type)
@@ -185,9 +185,9 @@ _dl_sysdep_start (void **start_argptr,
case AT_RANDOM:
_dl_random = (void *) av->a_un.a_val;
break;
- case AT_MINSIGSTKSZ:
- GLRO(dl_minsigstacksize) = av->a_un.a_val;
- break;
+ /* case AT_MINSIGSTKSZ: */
+ /* GLRO(dl_minsigstacksize) = av->a_un.a_val; */
+ /* break; */
DL_PLATFORM_AUXV
}
diff --git a/elf/rtld_static_init.c b/elf/rtld_static_init.c
index 3f8abb6800..aeac492235 100644
--- a/elf/rtld_static_init.c
+++ b/elf/rtld_static_init.c
@@ -67,9 +67,9 @@ __rtld_static_init (struct link_map *map)
dl->_dl_hwcap = _dl_hwcap;
extern __typeof (dl->_dl_hwcap2) _dl_hwcap2 attribute_hidden;
dl->_dl_hwcap2 = _dl_hwcap2;
- extern __typeof (dl->_dl_minsigstacksize) _dl_minsigstacksize
-attribute_hidden;
- dl->_dl_minsigstacksize = _dl_minsigstacksize;
+ /* extern __typeof (dl->_dl_minsigstacksize) _dl_minsigstacksize */
+ /* attribute_hidden; */
+ /* dl->_dl_minsigstacksize = _dl_minsigstacksize; */
extern __typeof (dl->_dl_pagesize) _dl_pagesize attribute_hidden;
dl->_dl_pagesize = _dl_pagesize;
extern __typeof (dl->_dl_tls_static_align) _dl_tls_static_align
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h
index 9c15259236..62117727e1 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -545,9 +545,6 @@ struct rtld_global_ro
/* Cached value of `getpagesize ()'. */
EXTERN size_t _dl_pagesize;
- /* Cached value of `sysconf (_SC_MINSIGSTKSZ)'. */
- EXTERN size_t _dl_minsigstacksize;
-
/* Do we read from ld.so.cache? */
EXTERN int _dl_inhibit_cache;
diff --git a/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h b/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
index 9e0eb0f7fc..2ba132e1fe 100644
--- a/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
+++ b/sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
@@ -22,7 +22,7 @@ static inline long int
__get_pthread_stack_min (void)
{
/* sysconf (_SC_THREAD_STACK_MIN) >= sysconf (_SC_MINSIGSTKSZ). */
- long int pthread_stack_min = GLRO(dl_minsigstacksize);
+ long int pthread_stack_min = 4096;
assert (pthread_stack_min != 0);
_Static_assert (__builtin_constant_p (PTHREAD_STACK_MIN),
"PTHREAD_STACK_MIN is constant");
diff --git a/sysdeps/unix/sysv/linux/sysconf.c
b/sysdeps/unix/sysv/linux/sysconf.c
index daaeeb7d36..24afb2fdc5 100644
--- a/sysdeps/unix/sysv/linux/sysconf.c
+++ b/sysdeps/unix/sysv/linux/sysconf.c
@@ -84,11 +84,11 @@ __sysconf (int name)
break;
case _SC_MINSIGSTKSZ:
- assert (GLRO(dl_minsigstacksize) != 0);
- return GLRO(dl_minsigstacksize);
+ // assert (GLRO(dl_minsigstacksize) != 0);
+ return 4096; // GLRO(dl_minsigstacksize);
case _SC_SIGSTKSZ:
- return sysconf_sigstksz ();
+ return 16384 ; //sysconf_sigstksz ();
Could you verify this on your DS-15?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
On 12/13/22 17:25, John Paul Adrian Glaubitz wrote: On 11/13/22 00:45, John Paul Adrian Glaubitz wrote: I just noticed that there is a regression in glibc on alpha with version 2.34 or later. Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious there is something wrong given the many "Segmentation Fault" errors. This regression was introduced by the following commit: Reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=29899 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi! On 11/13/22 00:45, John Paul Adrian Glaubitz wrote: I just noticed that there is a regression in glibc on alpha with version 2.34 or later. Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious there is something wrong given the many "Segmentation Fault" errors. This regression was introduced by the following commit: 6c57d320484988e87e446e2e60ce42816bf51d53 is the first bad commit commit 6c57d320484988e87e446e2e60ce42816bf51d53 Author: H.J. Lu Date: Mon Feb 1 11:00:38 2021 -0800 sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] Add _SC_MINSIGSTKSZ for the minimum signal stack size derived from AT_MINSIGSTKSZ, which is the minimum number of bytes of free stack space required in order to gurantee successful, non-nested handling of a single signal whose handler is an empty function, and _SC_SIGSTKSZ which is the suggested minimum number of bytes of stack space required for a signal stack. FWIW, it does not seem to affect alpha systems with a higher baseline such as EV67. Adrian [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.34-8&stamp=1662963628&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.35-4&stamp=1666729919&raw=0 [3] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.36-4&stamp=1667607306&raw=0 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=29575 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi! On 12/13/22 10:52, John Paul Adrian Glaubitz wrote: You could cross-compile glibc. That's most likely what I am going to do. For the record, here's how I am doing it. 1. Create an alpha chroot on an x86_64 host system using debootstrap on a system with qemu-user-static installed. # debootstrap --no-check-gpg --arch=alpha unstable /srv/sid-alpha-sbuild http://ftp.ports.debian.org/debian-ports (See below for schroot configuration). 2. Install cross-compiler for alpha as well as build dependencies for glibc: # apt install g++-alpha-linux-gnu # apt build-dep --arch-only glibc 3. Cross-compile glibc on x86_64 on host system: $ cd /path/to/glibc/ $ mkdir build && cd build $ ../configure --host=alpha-linux-gnu --disable-werror --prefix=/usr --disable-sanity-checks && make -j8 4. Enter alpha schroot and run the the following command from the build directory: (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash If the bug is present, this command will segfault: Segmentation fault Otherwise it will just spawn another bash which can be exited with "exit": (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ exit (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ The trick is to share the glibc source directory into the schroot. This is achieved by the following two configuration files: root@z6:~> cat /etc/schroot/chroot.d/sid-alpha-sbuild [sid-alpha-sbuild] description=Debian sid chroot for alpha type=directory directory=/local_scratch/sid-alpha-sbuild profile=sbuild #aliases=sid groups=root,sbuild,glaubitz,buildd root-groups=root,sbuild,glaubitz,buildd root@z6:~> root@z6:~> cat /etc/schroot/sbuild/fstab # fstab: static file system information for chroots. # Note that the mount point will be prefixed by the chroot path # (CHROOT_PATH) # # /proc /proc nonerw,bind 0 0 /sys/sysnonerw,bind 0 0 /dev/pts/dev/ptsnonerw,bind 0 0 tmpfs /dev/shmtmpfs defaults0 0 # Mount a large scratch space for the build, so we don't use up # space on an LVM snapshot of the chroot itself. /home/glaubitz /home/glaubitz nonerw,bind 0 0 root@z6:~> To bisect, just run the normal git bisect process from the and just run the test command in the emulated schroot from a second terminal. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hello! On 12/13/22 10:33, Frank Scheiner wrote: Hi guys, On 13.12.22 06:15, John Paul Adrian Glaubitz wrote: [...] I am still interested in fixing the glibc bug and will work on bisecting it. I yestderday did give that a try on a DS15, but it took already hours to get glibc 2.33 compiled. During this compilation I got 4 segfaults from the compiler (gcc-12) and a "gcc: internal compiler error: Aborted signal terminated program cc1". If you are interested in the details, I have all the error messages available. Is that glibc from upstream or the Debian package? Also, is the machine's memory known to be good? Please make sure to test it. This went on during `make test` with another segfault and this one here after more than 2 hours of processing: ``` root@ds15:/srv/storage/build/glibc-2.33# time make test [...] g++ tst-thread_local1.cc -c -I/srv/storage/build/glibc-2.33/ -g -O2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fno-stack-protector -mlong-double-128 -mieee -mfp-rounding-mode=d -std=gnu++11 -I../include -I/srv/storage/build/glibc-2.33/nptl -I/srv/storage/build/glibc-2.33 -I../sysdeps/unix/sysv/linux/alpha/fpu -I../sysdeps/alpha/fpu -I../sysdeps/unix/sysv/linux/alpha -I../sysdeps/alpha/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/ieee754/ldbl-64-128 -I../sysdeps/ieee754/ldbl-opt -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/alpha -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/alpha -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include /srv/storage/build/glibc-2.33/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h -DTOP_NAMESPACE=glibc -o /srv/storage/build/glibc-2.33/nptl/tst-thread_local1.o -MD -MP -MF /srv/storage/build/glibc-2.33/nptl/tst-thread_local1.o.dt -MT /srv/storage/build/glibc-2.33/nptl/tst-thread_local1.o tst-thread_local1.cc: In function ‘int do_test()’: tst-thread_local1.cc:177:5: error: variable ‘std::array >, 2> do_thread_X’ has initializer but incomplete type 177 | do_thread_X | ^~~ tst-thread_local1.cc: At global scope: tst-thread_local1.cc:133:1: warning: ‘void* thread_with_access(void*)’ defined but not used [-Wunused-function] 133 | thread_with_access (void *) | ^~ tst-thread_local1.cc:127:1: warning: ‘void* thread_without_access(void*)’ defined but not used [-Wunused-function] 127 | thread_without_access (void *) | ^ make[2]: *** [../o-iterator.mk:9: /srv/storage/build/glibc-2.33/nptl/tst-thread_local1.o] Error 1 make[2]: Leaving directory '/srv/storage/glibc/nptl' make[1]: *** [Makefile:479: nptl/tests] Error 2 make[1]: Leaving directory '/srv/storage/glibc' make: *** [Makefile:9: check] Error 2 real129m3.940s user104m25.441s sys11m36.611s ``` ...after which I stopped. I did use `--disable-werror` during the configure step, but maybe this is not enough. OTOH it's only a warning so why does it err? Ah, I see it `-Wundef` is set. I'll have a look what the buildds use for the configure step. Today I'll also give it another try, but with gcc-11 this time - just in case something is wrong with gcc-12 - but frankly I don't think this goes anywhere on the DS15: Even with a DS25 I have available here I can only speed up the compilation and it takes already more than twice the power of the DS15, so nothing gained. My ES45s are in cold storage and I don't dare to start them up in such a low temperature environment. Summarizing it, I'd be grateful if someone could do the bisecting on one of the buildds or developer machines. You could cross-compile glibc. That's most likely what I am going to do. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hi! On 12/13/22 08:44, Michael Cree wrote: So what baseline do we want? Would EV56 be sufficient? Because that would still work with my AlphaStation 433au and XP1000 and gets us BWX. Yes. The first extension added is the byte-word extension which came in with EV56. That provides CPU instructions for byte and word (16-bit) memory accesses. That is the most important one: possibly a third of the bugs in the repository extend from non-atomic byte and word accesses. The kernel developers have expressed a view that they would like to assume on all arches that byte and word memory accesses are atomic and the only architecture that is holding them back from that assumption are old Alphas without BWX. There is an old open bug on gcc related to the non-atomic memory accesses of old Alphas and that one is basically cannot fix. If we went to BWX (i.e. EV56) then as you say that means the personal workstations (e.g. PWS433au and PWS500au), which a lot of Alpha users have and AlphaStations such as the 433au will still be supported. Thanks for the confirmation and clarification! I don't want to use something like EV67 as I think that would limit the usable hardware too much. Yes, that's the problem going fully to EV67. The CPU extensions we would get are MVI (motion video instructions) that came in with PCA56, CIX (count integer instructions with the like of counting trailing zeros) that came in with EV67 and FIX (floating point extensions primarily for efficient conversion between float and integer and a sqrt instruction) with EV6, but these are nowhere near as important as BWX in terms of reducing bug fixing workload in maintaining the port. OK, so EV56 sounds like a very good compromise. I guess we can still keep the -ev67 glibc package for people with these CPUs. I guess I can live with dropping EV4 since NetBSD and Gentoo would still run on these. Gentoo has the advantage (and disadvantage) of compiling from source so one can optimise their own installation for their hardware. Yes, of couse. I am still interested in fixing the glibc bug and will work on bisecting it. If EV56 is the baseline we can agree on, please go ahead and rebuild glibc and gcc using this baseline. I am currently building gcc-12 to default to EV56/BWX. In the test suite now so probably won't be finished till tomorrow. Then I will try building latest glibc (2.36-6) with that gcc. I suspect there will still be a couple of test suite failures so there will probably be a further delay before I have it ready to upload to the repository. In any case I will give fair warning before I do. Feel free to open bugs against glibc and gcc to request the raise of the baseline. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
Hello! On 12/12/22 20:45, Michael Cree wrote: Either the arch baseline is raised to something that is easier to maintain (which, frankly, I think is essential if the Alpha port is to survive any longer), someone else steps up to fix the brokenness that arises from non-atomic multi-cpu-instruction 8-bit and 16-bit memory accesses, or I bail out of maintaining Debian-Ports Alpha. So what baseline do we want? Would EV56 be sufficient? Because that would still work with my AlphaStation 433au and XP1000 and gets us BWX. I don't want to use something like EV67 as I think that would limit the usable hardware too much. I guess I can live with dropping EV4 since NetBSD and Gentoo would still run on these. I am still interested in fixing the glibc bug and will work on bisecting it. If EV56 is the baseline we can agree on, please go ahead and rebuild glibc and gcc using this baseline. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: glibc regression on alpha with 2.34+
> On Dec 12, 2022, at 7:17 PM, Michael Cree wrote: > > On Mon, Dec 12, 2022 at 12:24:59PM +0100, John Paul Adrian Glaubitz wrote: >> >> >>>> On Dec 12, 2022, at 9:27 AM, Michael Cree wrote: >>> >>> I am not interested in supporting old Alphas without BWX anymore. >>> I am drawing the line. Either someone steps up to support non-BWX >>> Alpha and promptly fixes glibc or the architecture baseline is >>> increased to include BWX (thereby fixing most of the glibc issues). >>> Without either of those happening I give up being an Alpha porter >>> and switch off my Alpha buildd permanently. I have many other >>> interesting projects I could be working on! >> >> As a compromise, how about we fix the bug, create a final set of CD >> images for old Alphas, then raise the baseline after having verified >> it does not break QEMU (both -user and -system)? > > You fix the bug then. I'm not interested so there is no "we" in this. Please don’t be so negative. We should be able to have a discussion on this topic without such sentiments. There are valid arguments for both sides, so it’s not helpful to lead a discussion like this. Adrian
Re: glibc regression on alpha with 2.34+
> On Dec 12, 2022, at 9:27 AM, Michael Cree wrote: > > I am not interested in supporting old Alphas without BWX anymore. > I am drawing the line. Either someone steps up to support non-BWX > Alpha and promptly fixes glibc or the architecture baseline is > increased to include BWX (thereby fixing most of the glibc issues). > Without either of those happening I give up being an Alpha porter > and switch off my Alpha buildd permanently. I have many other > interesting projects I could be working on! As a compromise, how about we fix the bug, create a final set of CD images for old Alphas, then raise the baseline after having verified it does not break QEMU (both -user and -system)? Adrian
Re: glibc regression on alpha with 2.34+
Hi Frank! > On Dec 12, 2022, at 8:57 AM, Frank Scheiner wrote: > > I'm not sure I fully understand the issue here: > > See, glibc used to work for alpha up until 2.33 as I read. Then a change > broke it for alpha with 2.34. Does the respective glibc maintainer for > alpha (Richard Henderson according to [1]) really have no interest in > fixing it? Any chance you can bisect the issue? FWIW, it’s not been reported upstream yet. Adrian
Re: Bug#1025376: libcds: FTBFS on mips64el, s390x, riscv64
Hello Bo! On 12/3/22 14:12, Bo YU wrote: The patch I have tested it on my local machines, please consider to apply it in next upload. thanks. Could you please extend your patch to add support for alpha as well? For alpha, we need: #elif defined(__alpha__) #define CDS_PROCESSOR_ARCHCDS_PROCESSOR_ALPHA #define CDS_BUILD_BITS64 #define CDS_PROCESSOR__NICK "alpha" Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
glibc regression on alpha with 2.34+
Hello! I just noticed that there is a regression in glibc on alpha with version 2.34 or later. Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious there is something wrong given the many "Segmentation Fault" errors. I had hoped I could fix this issue by passing "--disable-default-pie" like we already did on sparc64, but it seems it's not the same bug [4]. At least, this particular workaround does not help. I think the best approach would be bisecting this from 2.33 to 2.34 using the glibc sources from git. I assume building glibc and running the testsuite should be enough for bisecting. Adrian [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.34-8&stamp=1662963628&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.35-4&stamp=1666729919&raw=0 [3] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.36-4&stamp=1667607306&raw=0 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=29575 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linux 6.0.7 MP kernel works on DS25
Hi Frank! On 11/11/22 12:03, Frank Scheiner wrote: It looks like MP operation is working **again** on Alpha with recent kernels - which is just a pleasure to see! I'm unsure what was fixed in the kernel to make it work again, quickly scanning through the changes I didn't find anything related to Titan, only changes regarding Marvel. Nevertheless a **big thank you** to all people involved in "fixing" this! That's great news! Don't know what to make out of this. Is this a problem in the kernel sources or a problem for the Debian kernel team? [2]: https://buildd.debian.org/status/logs.php?pkg=linux&arch=alpha No idea, really. We need to ask someone from the Debian kernel team, they probably know how to fix this. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: error installing busybox on target system. Check /var/log/syslog or virtual console number 4 for details
Hi! > On Aug 14, 2022, at 11:33 AM, John Paul Adrian Glaubitz > wrote: > > Hello! > >> On Aug 14, 2022, at 9:15 AM, Linux-RISC wrote: >> >> >> I am trying to install Debian 5.0.10 on an AlphaServer DS10. It worked in >> the past but now during installation it returns "error installing busybox on >> target system. Check /var/log/syslog or virtual console number 4 for >> details". >> Virtual console number 4 displays: "WARNING: the following packages cannot >> be authenticated: busybox. There are problems and -y was used without >> --force-yes > > This indicates that the repository key being used has expired, thus you’re > using an older image. > > Which one did you use? Please provide the full URL. Ah, sorry, just saw that you are using a Lenny image? Any chance you could use a recent unstable image? Adrian
Re: error installing busybox on target system. Check /var/log/syslog or virtual console number 4 for details
Hello! > On Aug 14, 2022, at 9:15 AM, Linux-RISC wrote: > > > I am trying to install Debian 5.0.10 on an AlphaServer DS10. It worked in the > past but now during installation it returns "error installing busybox on > target system. Check /var/log/syslog or virtual console number 4 for details". > Virtual console number 4 displays: "WARNING: the following packages cannot be > authenticated: busybox. There are problems and -y was used without --force-yes This indicates that the repository key being used has expired, thus you’re using an older image. Which one did you use? Please provide the full URL. Adrian
Re: Updated Debian Ports installation images
Hi Ulrich! On 3/20/22 20:22, Ulrich Teichert wrote: > I tried the basic image on a miata with mixed success. I could boot it, > but the devices on the QLA1040 SCSI controler were not detected - which is > the build-in SCSI controler on that machine type, so I could not even mount > the CD from which I booted, nor any of the disks. It could not load the > firmware - OK, I so tried the non-free image, but it failed with the same > error: > > ... > qla1280: QLA1040 found on PCI bus 1, dev 4 > qla1280 :01:04.0: firmware: failed to load qlogic/1040.bin (-2) > ... The firmware images are missing the files in the firmware folder which contain information about matching hardware IDs with firmware. Consequently, the firmware is not loaded automatically. However, the firmware packages are still on the CD, located in pool/non-free/f/firmware-nonfree Maybe you can try installing the packages manually until we have sorted out the issue with the meta-data. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated Debian Ports installation images
Hello! I have created the first set of installation images in 2022, these are available at the usual location in [1]. The ISO image for sparc64 has been verified to work correctly, I don't know about the other architectures, however. I have also created the first images which include non-free firmware packages but these are completely untested and firmware installation might not work correctly as DEP-11 information is not available on the Debian Ports mirrors. The non-free images can be found here [2]. Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-18/ > [2] https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-18/non-free/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1007925: ruby3.0: Please include patch to fix incorrect libc SO names on alpha
Source: ruby Version: 3.0.3-1 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! The testsuite currently fails on alpha because the code in test/fiddle/helper.rb assumes that the filenames for the libc and libm shared objects files are always libc.so.6 and libm.so.6 on Linux which is not the case on at least alpha and ia64. The failure looks like this: exec ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/excludes --name=!/memory_leak/ -v --excludes-dir=debian/tests/excludes/any/ --excludes-dir=debian/tests/excludes/alpha/ /<>/.ext/common/fiddle.rb:61:in `initialize': libc.so.6: cannot open shared object file: No such file or directory (Fiddle::DLError) from /<>/.ext/common/fiddle.rb:61:in `new' from /<>/.ext/common/fiddle.rb:61:in `dlopen' from /<>/.ext/common/fiddle/import.rb:86:in `block in dlload' from /<>/.ext/common/fiddle/import.rb:77:in `collect' from /<>/.ext/common/fiddle/import.rb:77:in `dlload' from /<>/test/fiddle/test_import.rb:12:in `' from /<>/test/fiddle/test_import.rb:10:in `' from /<>/test/fiddle/test_import.rb:9:in `' from /<>/tool/lib/test/unit.rb:1049:in `require' from /<>/tool/lib/test/unit.rb:1049:in `block in non_options' from /<>/tool/lib/test/unit.rb:1043:in `each' from /<>/tool/lib/test/unit.rb:1043:in `non_options' from /<>/tool/lib/test/unit.rb:65:in `process_args' from /<>/tool/lib/test/unit.rb:143:in `process_args' from /<>/tool/lib/test/unit.rb:1237:in `process_args' from /<>/tool/lib/test/unit.rb:1242:in `run' from /<>/tool/lib/test/unit.rb:1249:in `run' from /<>/tool/test/runner.rb:23:in `' from ./test/runner.rb:11:in `require_relative' from ./test/runner.rb:11:in `' The attached patch fixes the issue. I have reported the bug upstream [2] and sent a pull request to fix it [3]. Please also don't forget to add the test excludes for alpha from # [4]. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ruby3.0&arch=alpha&ver=3.0.3-1&stamp=1647549307&raw=0 > [2] https://bugs.ruby-lang.org/issues/18645 > [3] https://github.com/ruby/ruby/pull/5681 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999444 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >From 53fc7d085c6929d920b2a915d33931478aded7fa Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Fri, 18 Mar 2022 16:36:16 +0100 Subject: [PATCH] [ruby/fiddle] Fix filenames for glibc SO files on alpha and ia64 Fixes [Bug #18645] --- test/fiddle/helper.rb | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/test/fiddle/helper.rb b/test/fiddle/helper.rb index 0ea3bf57f4..e470f5a276 100644 --- a/test/fiddle/helper.rb +++ b/test/fiddle/helper.rb @@ -49,8 +49,14 @@ libm_so = libc_so else # glibc -libc_so = "libc.so.6" -libm_so = "libm.so.6" +case RUBY_PLATFORM +when /alpha-linux/, /ia64-linux/ + libc_so = "libc.so.6.1" + libm_so = "libm.so.6.1" +else + libc_so = "libc.so.6" + libm_so = "libm.so.6" +end end when /mingw/, /mswin/ require "rbconfig" -- 2.30.2
Re: Bug#1006363: gcc-12: Patch alpha-ieee.diff no longer applies due to changed filename
Hello! On 2/24/22 11:12, John Paul Adrian Glaubitz wrote: > The patch alpha-ieee.diff no longer applies as the filename for > gcc/config/alpha/alpha.c > changed to gcc/config/alpha/alpha.cc: Just noticed this was just fixed in the latest upload of the gcc-12 package [1]. Closing again. Adrian > [1] > https://salsa.debian.org/toolchain-team/gcc/-/commit/ed23b2846e128363e1ff997209d34fabbeb10216 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006363: gcc-12: Patch alpha-ieee.diff no longer applies due to changed filename
Source: gcc-12 Version: 12-20220222-1 Severity: normal User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! The patch alpha-ieee.diff no longer applies as the filename for gcc/config/alpha/alpha.c changed to gcc/config/alpha/alpha.cc: Applying patch alpha-ieee.diff can't find file to patch at input line 11 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |# DP: #212912 |# DP: on alpha-linux, make -mieee default and add -mieee-disable switch |# DP: to turn default off | |--- | gcc/config/alpha/alpha.c |4 | 1 files changed, 4 insertions(+), 0 deletions(-) | |--- a/src/gcc/config/alpha/alpha.c |+++ b/src/gcc/config/alpha/alpha.c -- No file to patch. Skipping patch. 1 out of 1 hunk ignored Patch alpha-ieee.diff does not apply (enforce with -f) Changing "alpha.c" to "alpha.cc" in the patch fixes the problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1004747: r-base: Please include patch to fix build on alpha
Source: r-base
Version: 4.1.2-1
Severity: normal
User: debian-alpha@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-alpha@lists.debian.org,b...@debian.org
Hi!
r-base currently FTBFS on alpha with:
gfortran -fno-optimize-sibling-calls -fpic -g -O2
-ffile-prefix-map=/<>=. -c xxxpr.f -o xxxpr.o
gcc -std=gnu99 -shared -fopenmp -Wl,-z,relro -o libR.so CommandLineArgs.o
Rdynload.o Renviron.o RNG.o agrep.o altclasses.o altrep.o apply.o arithmetic.o
array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o
connections.o context.o cum.o dcf.o datetime.o debug.o deparse.o devices.o
dotcode.o dounzip.o dstruct.o duplicate.o edit.o engine.o envir.o errors.o
eval.o format.o gevents.o gram.o gram-ex.o graphics.o grep.o identical.o
inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o
logic.o main.o mapply.o match.o memory.o names.o objects.o options.o paste.o
patterns.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o
printvector.o printutils.o qsort.o radixsort.o random.o raw.o registration.o
relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o
sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o
times.o unique.o util.o version.o g_alab_her.o g_cntrlify.o g_fontdb.o
g_her_glyph.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o`
../extra/tre/libtre.a-lblas -lgfortran -lm -lreadline -lpcre2-8 -llzma
-lbz2 -lz -ltirpc -lrt -ldl -lm -licuuc -licui18n
platform.o: in function `machar':
./src/main/machar.c:128:(.text+0x21dc): relocation truncated to fit: GPREL16
against `.rodata.cst16'
../nmath/pnchisq.o: in function `Rf_pnchisq_raw':
./src/nmath/pnchisq.c:125:(.text+0x48c): relocation truncated to fit: GPREL16
against `.rodata.cst16'
./src/nmath/pnchisq.c:230:(.text+0x818): relocation truncated to fit: GPREL16
against `.rodata.cst16'
./src/nmath/pnchisq.c:230:(.text+0xb08): relocation truncated to fit: GPREL16
against `.rodata.cst16'
collect2: error: ld returned 1 exit status
Adrian Bunk found out that this is an issue of linking with -fpic instead of
-fPIC. Adjusting the
flags fixes the linker error. Attaching a patch which patches both configure.ac
and configure. The
latter is necessary since the package currently doesn't regenerate the
configure before build auto-
matically.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: r-base-4.1.2/configure.ac
===
--- r-base-4.1.2.orig/configure.ac
+++ r-base-4.1.2/configure.ac
@@ -1316,7 +1316,7 @@ if test "${GCC}" = yes; then
## has 32k and so can use -fpic.
## However, although the gcc docs do not mention it, it seems s390/s390x
## also supports and needs -fPIC
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
cpicflags="-fPIC"
;;
*)
@@ -1327,7 +1327,7 @@ if test "${GCC}" = yes; then
fi
if test "${ac_cv_fc_compiler_gnu}" = yes; then
case "${host_cpu}" in
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
fpicflags="-fPIC"
;;
*)
@@ -1343,7 +1343,7 @@ case "${FC}" in
esac
if test "${GXX}" = yes; then
case "${host_cpu}" in
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
cxxpicflags="-fPIC"
;;
*)
Index: r-base-4.1.2/configure
===
--- r-base-4.1.2.orig/configure
+++ r-base-4.1.2/configure
@@ -28883,7 +28883,7 @@ if test "${GCC}" = yes; then
## has 32k and so can use -fpic.
## However, although the gcc docs do not mention it, it seems s390/s390x
## also supports and needs -fPIC
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
cpicflags="-fPIC"
;;
*)
@@ -28894,7 +28894,7 @@ if test "${GCC}" = yes; then
fi
if test "${ac_cv_fc_compiler_gnu}" = yes; then
case "${host_cpu}" in
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
fpicflags="-fPIC"
;;
*)
@@ -28910,7 +28910,7 @@ case "${FC}" in
esac
if test "${GXX}" = yes; then
case "${host_cpu}" in
-sparc*|ppc64*|powerpc64*|s390*)
+alpha*|sparc*|ppc64*|powerpc64*|s390*)
cxxpicflags="-fPIC"
;;
*)
Subscription - Re: Error in the Debian archive.
Hello Kirsten! On 12/31/21 12:18, Kirsten Bromilow wrote: > Wrong email!!! As already mentioned in my previous personal mail to you, you are receiving this email through an email list from which you need to unsubscribe. Please go to the following website, enter your email address and click "Unsubscribe": > https://lists.debian.org/debian-alpha/ Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Error in the Debian archive.
Hi Mike! On 12/31/21 10:24, Mike Hosken wrote: > Happy New Year, Happy New Year! > I sent an email to al...@buildd.debian.org back in August I think. That address reaches the administrators of the buildd machines, not the Debian FTP archive. I also think that there is currently no one behind this address. I may ask Aurelien Jarno to add me to this alias. > I suspect that it’s a file system error that has been synced with the other > mirrors. > I’ve come across a similar error before with hppa and Helge rebuilt the > packages that > were affected and it went away. I’m not sure if that’s the case here though. > I do know > that it’s been there for over a year now. I started setting up a mirror > server for debian > ports a year ago with this error, it was only in August when I put a new > mirror server I > online that it became an issue. I’ve been trying to resolve it since. What package was it that Helge rebuilt? I can rebuilt bustle, of course, although I think this error is rather unusual. > Any help with this issue would be very appreciated. Sure. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Error in the Debian archive.
Hello Mike! On 12/31/21 05:21, Mike Hosken wrote: > I’ve tried a number of emails to get this fixed and have had zero response > from the alpha or the ftp master at debian ports over the last 3 months. You most likely used outdated email addresses then. There is no "alpha master" anymore, so I'm not sure what email address you used. > I’m trying to mirror the debian ports repo as the connection speed is dreadful > where I live to the main repos. It always fails to sync correctly due to an > error > with an alpha package that either needs removed or rebuilt. Any help with this > would be very much appreciated as I’ve had zero luck getting it resolved > elsewhere. > > rsync: send_files failed to open > "pool-alpha/main/b/bustle/.bustle_0.4.8-1_alpha.deb.xRxejE" (in > debian-ports): Permission denied (13) Did you try syncing the repo with reprepro? I just checked the permissions on one of the Debian mirrors and they seem to be fine: glaubitz@casulana:/srv/mirrors/debian-ports/pool-alpha/main/b/bustle$ ls -l total 4340 -rw-r--r-- 1 archvsync archvsync 14889 Oct 7 18:03 bustle_0.8.0-1+b2_alpha.buildinfo -rw-r--r-- 1 archvsync archvsync 4365736 Oct 7 18:03 bustle_0.8.0-1+b2_alpha.deb -rw-r--r-- 1 archvsync archvsync 17216 Oct 7 18:03 bustle-pcap_0.8.0-1+b2_alpha.deb -rw-r--r-- 1 archvsync archvsync 39720 Oct 7 18:03 bustle-pcap-dbgsym_0.8.0-1+b2_alpha.deb glaubitz@casulana:/srv/mirrors/debian-ports/pool-alpha/main/b/bustle$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: kronosnet: FTBFS on alpha, hppa and ia64 due to uncondtional use of -fstack-protector
Control: tags -1 +patch
Upstream has already come up with a patch [1] to fix the issue, see attached.
Adrian
> [1] https://github.com/kronosnet/kronosnet/pull/372
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From 4b765d6c3a994fe15abf2b9861109373ffe36322 Mon Sep 17 00:00:00 2001
From: "Fabio M. Di Nitto"
Date: Tue, 30 Nov 2021 10:32:18 +0100
Subject: [PATCH] [build] fix flag detections for gcc
Resolves: https://github.com/kronosnet/kronosnet/issues/371
Signed-off-by: Fabio M. Di Nitto
---
configure.ac | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index d9adc50..f90baca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -186,10 +186,7 @@ AM_CONDITIONAL([BUILD_RUST_BINDINGS], [test x$enable_rust_bindings = xyes])
# args. Global CPPFLAGS are ignored during this test.
cc_supports_flag() {
saveCPPFLAGS="$CPPFLAGS"
- CPPFLAGS="$@"
- if echo $CC | grep -q clang; then
- CPPFLAGS="-Werror $CPPFLAGS"
- fi
+ CPPFLAGS="-Werror $@"
AC_MSG_CHECKING([whether $CC supports "$@"])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
[RC=0; AC_MSG_RESULT([yes])],
--
2.34.0
Bug#1000853: kronosnet: FTBFS on alpha, hppa and ia64 due to uncondtional use of -fstack-protector
Source: kronosnet Severity: normal Tags: upstream User: debian-alpha@lists.debian.org Usertags: alpha hppa ia64 X-Debbugs-Cc: debian-alpha@lists.debian.org,debian-h...@lists.debian.org,debian-i...@lists.debian.org Hi! kronosnet FTBFS on alpha, hppa and ia64 due to unconditional use of -fstack-protector which is not supported on these targets and hence generates a compiler warning. Since the package is being built with -Werror, this causes the package to FTBFS: /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -ggdb3 -Werror -Wall -Wextra -fPIC -DPIC -pie -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fexceptions -D_GLIBCXX_ASSERTIONS -Wl,-z,now -fstack-clash-protection -Wno-unused-parameter -pthread -I/usr/include/libnl3 -I/usr/include/libnl3 -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security -c -o libnozzle_la-libnozzle.lo `test -f 'libnozzle.c' || echo './'`libnozzle.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -ggdb3 -Werror -Wall -Wextra -fPIC -DPIC -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fexceptions -D_GLIBCXX_ASSERTIONS -Wl,-z,now -fstack-clash-protection -Wno-unused-parameter -pthread -I/usr/include/libnl3 -I/usr/include/libnl3 -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security -c libnozzle.c -fPIC -DPIC -o .libs/libnozzle_la-libnozzle.o cc1: error: ‘-fstack-protector’ not supported for this target [-Werror] cc1: all warnings being treated as errors Full log in [1]. Reported upstream as [2]. For a possible fix, have a look at this similar bug in libfido2 [3]. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=kronosnet&arch=alpha&ver=1.23-1&stamp=1638252618&raw=0 > [2] https://github.com/kronosnet/kronosnet/issues/371 > [3] https://bugs.debian.org/996428 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#999444: ruby3.0: Please disable some tests on alpha
Source: ruby3.0 Version: 3.0.2-5 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! A small number of tests is failing specifically on alpha. Disabling them allows the testsuite to pass. Could you apply the attached patch for the next upload so that ruby3.0 is fixed on alpha? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb --- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb 1970-01-01 01:00:00.0 +0100 +++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb 2021-11-10 23:53:44.685985756 +0100 @@ -0,0 +1 @@ +exclude :test_bug_reporter_add, 'fails, ENOTIME to investigate' diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb --- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb1970-01-01 01:00:00.0 +0100 +++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb2021-11-10 23:53:44.689985737 +0100 @@ -0,0 +1,2 @@ +exclude :test_compile_insn_local, 'fails, ENOTIME to investigate' +exclude :test_compile_insn_newarray, 'fails, ENOTIME to investigate' diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb --- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb 1970-01-01 01:00:00.0 +0100 +++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb 2021-11-10 23:53:44.689985737 +0100 @@ -0,0 +1,3 @@ +exclude :test_segv_loaded_features, 'fails, ENOTIME to investigate' +exclude :test_segv_setproctitle, 'fails, ENOTIME to investigate' +exclude :test_segv_test, 'fails, ENOTIME to investigate' diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb --- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb 1970-01-01 01:00:00.0 +0100 +++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb 2021-11-10 23:53:44.693985717 +0100 @@ -0,0 +1 @@ +exclude :test_world_writable, 'fails, ENOTIME to investigate'
Bug#999351: ruby3.0: Please build with -O1 on alpha
Source: ruby2.7 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hi! ruby3.0 currently FTBFS on alpha with an GCC internal compiler error [1]. This can be worked around by passing -O1 to the compiler. Could you patch debian/rules so that -O1 is passed to the compiler? --- debian/rules.orig 2021-10-18 14:52:16.0 +0200 +++ debian/rules2021-11-07 23:12:07.114346920 +0100 @@ -62,6 +62,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow configure_options += $(shell dpkg-buildflags --export=configure) +ifneq (,$(filter $(DEB_HOST_ARCH),alpha)) +export DEB_CFLAGS_MAINT_APPEND += -O1 +endif + # See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4)) export DEB_CFLAGS_MAINT_APPEND += -fno-crossjumping Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ruby3.0&arch=alpha&ver=3.0.2-5&stamp=1635296543&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Update Debian Ports installation images 2021-04-14
Hi Rafael! On 11/1/21 09:37, Rafael Ruiz wrote: > Yes, that was the reason. Automatic partitioning already does it like that, > as Adrian told me. aboot partition must be the first slice as you said, and > with 1.0 MB is enough (I forgot these details). All done. > Now I'm dusting off other machines like Alphaserver DS10L (21264) and AlphaPC > LX164 (21164) to test Debian releases on them again. That's great to hear. Please keep reporting back in case you run into issues or also when stuff works well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Update Debian Ports installation images 2021-04-14
Hello Rafael! On 10/31/21 19:35, Rafael Ruiz wrote: > I tried it on my API UP1100 with Debian 3.0 (Woody) from years ago. Your > snapshot is fine, but the only problem I found is respect aboot > installation. > > As far as i remember, aboot needs ext2 partition. Well, I have created a > 10GB partition with ext2 for it, but always I get the same message like > aboot needs more disk space. More than 10GB for a tiny aboot code? I don't > think so. > > When I installed older versions, never saw this problem. That's really strange. Did you try automatic partitioning? I installed on my XP1000 using the new images and didn't see that problem. I'm curious why you're getting this message. The installation log from /var/log/syslog would be helpful. Also, normally you should be able to ignore the warning and continue. > Until aboot install, I can not to boot it from SRM console. Yep. > Thanks for your job for Alpha! You're welcome. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
apt sometimes fails with 'getline (12: Cannot allocate memory)'
Hello! We have been observing an issue on alpha for since the beginning of September where an "apt-get update" in sbuild would fails with 'getline (12: Cannot allocate memory)' [1]: > Get:1 http://ftp.ports.debian.org/debian-ports unstable InRelease [24.2 kB] > Get:2 http://ftp.ports.debian.org/debian-ports unreleased InRelease [24.0 kB] > Get:3 http://ftp.debian.org/debian unstable InRelease [165 kB] > Get:4 http://incoming.debian.org/debian-buildd buildd-unstable InRelease > [39.7 kB] > Get:5 http://incoming.ports.debian.org/buildd unstable InRelease [41.2 kB] > Get:6 http://ftp.ports.debian.org/debian-ports unreleased/main alpha Packages > [113 kB] > Get:7 http://ftp.debian.org/debian unstable/main Sources [9272 kB] > Get:8 http://incoming.debian.org/debian-buildd buildd-unstable/main Sources > [90.8 kB] > Get:9 http://incoming.ports.debian.org/buildd unstable/main alpha Packages > [62.9 kB] > Reading package lists... > E: Could not read from > /var/lib/apt/lists/partial/ftp.ports.debian.org_debian-ports_dists_unstable_InRelease > - getline (12: Cannot allocate memory) > E: The repository 'http://ftp.ports.debian.org/debian-ports unstable > InRelease' provides only weak security information. After that, the resolver is unable to find any packages and hence install the build dependencies which results the build to fail. This issue occurs just sometimes and so far has only been observed on alpha. Does anyone have a clue what could be the problem? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=libayatana-indicator&arch=alpha&ver=0.8.4-2&stamp=1634646985&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: OpenSSH upgrade problem (8.0 => 8.4)
Control: tags -1 +patch
Hello!
On 10/17/21 19:38, John Paul Adrian Glaubitz wrote:
> This should be reported upstream. Chances are higher that upstream will see
> the bug and fix it.
>
> I'll forward it.
The attached patch fixes the problem for me and allows the build to succeed on
hppa without any problems. I have also opened a pull request upstream [1].
Adrian
> [1]
> https://github.com/Yubico/libfido2/pull/444/commits/257e380a0e8433d9579606580bdaaba15e802c5c.
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From 257e380a0e8433d9579606580bdaaba15e802c5c Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Sun, 17 Oct 2021 19:49:00 +0200
Subject: [PATCH] cmake: Add -Werror when checking host compiler for
-fstack-protector
Since calling GCC with -fstack-protector will just generate a warning
when it doesn't support the flag on a given host architecture, we need
to add -Werror so the warning turns into an error and cause the cmake
check HAVE_STACK_PROTECTOR_ALL to fail when the flag is not supported.
fixes gh#443
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ed3819e..64013ca 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -80,7 +80,7 @@ if(NOT MSVC)
endif()
check_c_compiler_flag("-Wshorten-64-to-32" HAVE_SHORTEN_64_TO_32)
-check_c_compiler_flag("-fstack-protector-all" HAVE_STACK_PROTECTOR_ALL)
+check_c_compiler_flag("-Werror -fstack-protector-all" HAVE_STACK_PROTECTOR_ALL)
check_include_files(cbor.h HAVE_CBOR_H)
check_include_files(endian.h HAVE_ENDIAN_H)
--
2.30.2
Re: OpenSSH upgrade problem (8.0 => 8.4)
Hello! On 10/14/21 00:14, John David Anglin wrote: > There's a bug in the check for -fstack-protector-all: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996428 This should be reported upstream. Chances are higher that upstream will see the bug and fix it. I'll forward it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/13/21 13:04, John Paul Adrian Glaubitz wrote: > It just got merged: > >> https://salsa.debian.org/kernel-team/linux/-/commit/5c1572cf356ce31f1b8f9a3ffb26a8498617035e > > Will take some more days until I can provide new installation images, however. > > I will let you know, then you can try again. OK, an updated kernel was just uploaded today which contains the fix: > https://buildd.debian.org/status/package.php?p=linux&suite=sid Now we just have to wait until the alpha build server has picked up the package which can take some time as we don't have a lot of build capacity for alpha at the moment. FWIW, if you know anyone with a fast alpha server who would be willing to help, let me know. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/11/21 20:44, Ulrich Teichert wrote: >> FWIW, the change to re-enable EISA on alpha in the Debian kernel config has >> not been >> merged yet due to bike-shedding over the proper changelog entry ... [1]. > > Oh well, eventually, it will get merged ;-? It just got merged: > https://salsa.debian.org/kernel-team/linux/-/commit/5c1572cf356ce31f1b8f9a3ffb26a8498617035e Will take some more days until I can provide new installation images, however. I will let you know, then you can try again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Thomas! On 10/11/21 22:17, Thomas Schmitt wrote: > @John Paul Adrian Glaubitz: > Where can i see the code with the xorriso run which produced the ISO ? mkisofs options are here: > https://salsa.debian.org/images-team/debian-cd/-/blob/master/tools/boot/bullseye/boot-alpha Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/11/21 20:44, Ulrich Teichert wrote: > That's why I used two different CD-ROM drives *and* burned two CD-ROMs on > different > types of blank CDs. I think that rules out hardware issues, as the error is > exactly > the same, even happens on the same sector, when I try to mount the CD-ROM from > a shell: > > With Liftec media: > Oct 11 20:15:08 main-menu[268]: INFO: Menu item 'di-utils-shell' selected > Oct 11 20:15:32 kernel: [ 260.904163] sr 0:0:4:0: [sr0] tag#33 unaligned > transfer > Oct 11 20:15:32 kernel: [ 260.905139] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 11 20:15:32 kernel: [ 260.905139] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 > > With Medion media: > Oct 11 20:34:10 main-menu[269]: INFO: Menu item 'di-utils-shell' selected > Oct 11 20:34:30 kernel: [ 258.741078] sr 0:0:4:0: [sr0] tag#380 unaligned > transfer > Oct 11 20:34:30 kernel: [ 258.742055] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 11 20:34:30 kernel: [ 258.742055] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 OK, I don't want to rule out a software problem. However, I would advise to use Taiyo Yuden media if you still can those. Those are usually those with the highest quality and reliability. > I am getting a lot of other messages for unaligned transfers on /dev/sr0, too: > > Oct 11 20:11:49 kernel: [ 28.658188] sr 0:0:4:0: [sr0] scsi-1 drive > Oct 11 20:11:49 kernel: [ 28.659165] cdrom: Uniform CD-ROM driver Revision: > 3.--More-- (32% of 53020 > Oct 11 20:11:49 kernel: [ 28.706039] sr 0:0:4:0: Attached scsi CD-ROM sr0 > ... > Oct 11 20:11:49 kernel: [ 30.755843] sr 0:0:4:0: [sr0] tag#20 unaligned > transfer > Oct 11 20:11:49 kernel: [ 30.756820] blk_update_request: I/O error, dev > sr0, sector 583127 op 0x0:(READ) flags 0x0 phys_seg 9 prio class 0 > Oct 11 20:11:49 kernel: [ 30.759749] Buffer I/O error on dev sr0, logical > block 583127, async page read > Oct 11 20:11:49 kernel: [ 30.760726] Buffer I/O error on dev sr0, logical > block 583128, async page read > ... etc.. > > Getting the full log would be a bit tedious, as I can't proceed to the network > configuration... I had another idea after I replied your last mail and I think one possible culprit could be xorrisofs which was used for building the ISO image instead of genisoimage which Debian used in the past. I can actually create an installation image with genisoimage instead and you can test it. Also, let's pull Thomas Schmitt from libburnia upstream who might know more. >> FWIW, the change to re-enable EISA on alpha in the Debian kernel config has >> not been >> merged yet due to bike-shedding over the proper changelog entry ... [1]. > > Oh well, eventually, it will get merged ;-? Yes, it will be merged. No worries. Hopefully later this week. I didn't have the time for a rebase yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Updated Debian Ports installation images 2021-09-23
Hi Ulrich! On 10/10/21 19:38, Ulrich Teichert wrote: > Just tested on a Alphastation 400 4/233. Booting went smooth (serial > console) but the CDROM (in a DEC RRD45) could not be mounted: > > > Oct 10 19:20:19 kernel: [ 324.340654] sr 0:0:4:0: [sr0] tag#265 unaligned > transfer > Oct 10 19:20:19 kernel: [ 324.340654] blk_update_request: I/O error, dev > sr0, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 > Oct 10 19:20:19 kernel: [ 324.340654] isofs_fill_super: bread failed, > dev=sr0, iso_blknum=16, block=32 > ... > > I've burned another CD-ROM and tried booting from that one, but got the > same error, so I assume the unaligned transfer is the problem. Tried > a Plextor UltraPlex instead of the RRD45 as well, same problem, I have not seen this issue before on any machine and usually, reading problems are due to hardware issues. Maybe the CD was not correctly burned? FWIW, the change to re-enable EISA on alpha in the Debian kernel config has not been merged yet due to bike-shedding over the proper changelog entry ... [1]. Adrian > [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/402 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
On 10/8/21 20:52, Rob Browning wrote: > Then, once that's uploaded were you planning to handle the reverse dep > rebuilds, and/or what coordination might we need there? We can just rebuild all of these reverse dependencies, yes. Adrian Bunk is probably happy to take care of that job, he has access to wanna-build, too, and has recently done a lot of work in this area. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
On 10/8/21 05:08, Michael Cree wrote: > I am still of the opinion that we should try in the first instance > to find the real problem in the toolchain and fix it there. The bug > affects packages other than guile and only on SMP systems. I'm not arguing against fixing this bug. But without building guile with "--without-threads" we will have a large number of BD-Uninstallable packages until this bug gets fixed. And a guile interpreter that crashes on any SMP system. > When I get my hands on Electro I can boot with a generic kernel > and build guile-3.0 there which hopefully will overcome the memory > exhaustion and time-out problems seen on the XP1000s. That doesn't really help here though as the compiled guile package will still crash on SMP systems and cause packages like gnul28 to FTBFS on imago. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
On 10/8/21 03:13, Rob Browning wrote: > And while we can, of course, rebuild all the reverse deps (presumably > only acceptable for testing/sid), doing so may still break things for > anyone outside debian who's been relying on our packages (if we'd ever > had any in testing -- sounds like maybe we haven't for 3.0 for alpha). But again, we're doing this all the time and this affects a non-release architecture. I never said this flag should be passed for amd64 or arm64. A compiled guile-2.2 and guile-3.0 will also crash immediately on any alpha SMP system, so it never really worked. Only building both guile-2.2 and guile-3.0 with "--without-threads" makes the package actually usable on alpha. So, I'm not sure how any outside user was supposed to be testing a guile binary that was crashing all the time on SMP machines. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
On 10/8/21 03:00, Rob Browning wrote: > If we've never had a 3.0 viable for alpha, for example, then we can of > course do whatever we like, with the realization that if we disable > threads there now, we may be stuck with that choice until 3.2. We can always break the ABI in a controlled manner. That's what binNMUs are for. I don't understand the discussion. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
Hello Rob! On 10/8/21 02:56, Rob Browning wrote: > I've checked with upstream, and while they were not certain that > changing the --with-threads setting still breaks the library API, they > thought it probably did, which I believe means we have to assume that it > does (or could in the future), i.e. upstream makes no guarantees that > you can ever change that option without breaking the ABI. > > Given that, I think we may have at least these constraints: > > - For any guile X.Y version (for a given arch) that's in a stable > distribution (buster, bullseye, etc.) we cannot change the setting > because it would break the contract and could crash existing debian > and non-debian applications linked to the relevant guile-X.Y-libs. The alpha architecture is not part of any distribution which is why this argument is moot. I was not asking for this option to be set to an release architecture. Also, *if* we break the ABI, we can just rebuild all affected packages. We do that with binNMUs for various reverse dependencies all the time. Finally, without this change, guile will not work on alpha at all. So, we cannot break the ABI in the first place, because we didn't have a properly working guile package on alpha yet. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ffmpeg: Please don't unconditionally build depend on clang
Hi! > Build depending on clang made ffmpeg unbuildable on several ports > architectures where clang is not available. > > Please excelude from the clang build dependency architectures > where llvm-toolchain-11 is not available: > [!alpha !hppa !ia64 !kfreebsd-amd64 !kfreebsd-i386 !m68k !sh4 !x32] Thanks for reporting this. I just ran into this as well. FWIW, x32 can be removed from this list once clang defaults to version 13. m68k might follow in the future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS
Hi Michael! On 10/3/21 20:29, Michael Cree wrote: > On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote: >> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread >> support. Passing --without-threads to configure disables thread >> support and fixes the build. > > The issue only appears on SMP systems. They build correctly on UP > systems. This issue affects a number of package builds including > gnutls and autogen. I often just manually build them on a UP system > and upload to the archive, and I could do that with guile-2.2. As > to where the issue really is ... I am not sure. The problem is that even the built guile package will crash on SMP systems without "--without-threads". So, currently, we have no other choice than disabling threads if we want guile and others to not FTBFS on imago and electro and other SMP buildds in the future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
Hi Rob! On 10/3/21 20:27, Rob Browning wrote: > John Paul Adrian Glaubitz writes: > >> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread >> support. Passing --without-threads to configure disables thread >> support and fixes the build. > > Hmm, I'm not certain we can do this unless we've never had a successful > build on the relevant platforms. At least in the past, disabling > threads changed the library ABI in a backward incompatible way. Without --without-threads, guile would not build on SMP systems and even the built package would crash on SMP systems. If disabling threads would break the ABI, we could just rebuild the affected reverse dependencies on the builds using the normal binNMU method. I don't think we have any other choice at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
Source: guile-3.0 Version: 3.0.7-1 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread support. Passing --without-threads to configure disables thread support and fixes the build. We also suspect that the threading problems in guile affect other packages on alpha such as gnutls28 but we're not sure yet. Could you apply the attached patch for the next upload of guile-3.0? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2021-08-26 22:10:35.0 +0200 +++ debian/rules2021-10-03 11:29:06.180438779 +0200 @@ -88,6 +88,11 @@ deb_config_args += --enable-jit=no endif +deb_target_arch := $(shell dpkg-architecture -qDEB_TARGET_ARCH) +ifneq (,$(filter $(deb_target_arch),alpha)) + deb_config_args += --without-threads +endif + export DEB_CFLAGS_MAINT_APPEND := \ -DPACKAGE_PACKAGER='"Debian"' \ -DPACKAGE_PACKAGER_VERSION='"$(upstream_ver)-deb+$(deb_src_src_rev)-$(deb_src_rev)"' \
Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS
Source: guile-2.2 Version: 2.2.7+1-6 Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hello! Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread support. Passing --without-threads to configure disables thread support and fixes the build. We also suspect that the threading problems in guile affect other packages on alpha such as gnutls28 but we're not sure yet. Could you apply the attached patch for the next upload of guile-2.2? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2021-06-18 20:12:50.0 +0200 +++ debian/rules2021-10-03 03:28:45.001439990 +0200 @@ -88,6 +88,11 @@ march = endif +deb_target_arch := $(shell dpkg-architecture -qDEB_TARGET_ARCH) +ifneq (,$(filter $(deb_target_arch),alpha)) + deb_config_args += --without-threads +endif + export DEB_CFLAGS_MAINT_APPEND := \ -DPACKAGE_PACKAGER='"Debian"' \ -DPACKAGE_PACKAGER_VERSION='"$(upstream_ver)-deb+$(deb_src_src_rev)-$(deb_src_rev)"' \ @@ -182,7 +187,7 @@ override_dh_auto_configure: dh_auto_configure -- --disable-error-on-warning --disable-rpath \ - --program-suffix "-$(deb_src_eff_ver)" + --program-suffix "-$(deb_src_eff_ver)" $(deb_config_args) # Because some of the bootstrapping files compile for a very long time # with no output, the buildds don't have per-package limits, and we
Re: Newer kernels on the Jensen (was: [PATCH v2 0/4] Introduce and
Hi Ulrich! On 9/26/21 19:16, John Paul Adrian Glaubitz wrote: > That might be possible but I'm not sure whether there are any limitations with > a-boot in this regard. Either way, you helped me find another kernel > configuration > issue in Debian that I am going to fix, so thanks for that. I have opened a merge request for the Debian kernel configuration now to enable EISA support in the Debian kernel package on alpha [1]. Thus, the installer images should fully work on your machine once this change has been merged. Thanks, Adrian > [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/401 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Newer kernels on the Jensen (was: [PATCH v2 0/4] Introduce and
Hi Ulrich! On 9/26/21 19:12, Ulrich Teichert wrote: >> On 9/26/21 13:35, John Paul Adrian Glaubitz wrote: >>> This can be fixed, either by updating the kernel module package lists >>> or adding a missing firmware package - if needed. >> >> OK, the problem is that the Alpha kernel in Debian is currently being built >> without ISA and EISA support. I will fix that for the next kernel upload. > > Nice! I think I found out what my main problem is: my bootloader setup. > I copied the kernel from the CD-ROM (boot/vmlinuz), which booted, to my > hard drive - where it did not boot at all! Perhaps a newer aboot is needed > for newer kernels? That might be possible but I'm not sure whether there are any limitations with a-boot in this regard. Either way, you helped me find another kernel configuration issue in Debian that I am going to fix, so thanks for that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated Debian Ports installation images 2021-09-23
Hi! I have just built and uploaded updated Debian Ports installation images. These images contain an updated apt-setup package which fixes the APT problem that occurred during installation with the 2021-09-21 images. I have performed a successful test installation on sparc64 and will perform a test on ia64 on my RX2660 later as well. I will provide more images updates in the following days which will contain more fixes such as for the hd-media installation as well as improvements on Apple PowerMac. The images can be obtained from [1]. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-23/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated Debian Ports installation images 2021-09-21
Hello! I just built a fresh set of Debian Ports installation images which are using the latest Debian unstable kernel 5.14.6. The images have not been tested as I currently cannot start my testvm on the SPARC server I usually use for testing, so testing is currently up to the users. Since kernel version 5.12, Linux is finally working on larger ia64 systems such as the RX2800 again where the kernel previously failed to boot. So, if anyone has such a machine and wants to install it, it should now work. On some ia64 machines, it may be necessary to pass the option "hardened_usercopy=off" on the kernel command line. For that, press "e" on the GRUB menu and append the line above without quotes to the boot command. PowerMac installation should also work with these images again, although I haven't tested that yet. Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-21/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: future of the libc6.1-alphaev67 package
Hello! On 8/24/21 10:59 PM, Aurelien Jarno wrote: > With the removal of the libc6-xen package in glibc 2.32, the only > package still using the hwcap infrastructure is libc6.1-alphaev67. The > hwcap infrastructure consists in upstream support for looking for > libraries in the hwcap directories, plus Debian specific patches to > support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism > in the maintainer scripts to disable hwcap support until all libc6 > packages are configured. > > The various optimized packages have been replaced with time by other > mechanisms such as indirect function support (IFUNC), or runtime atomic > selection in GCC (-moutline-atomics). Isn't this type of architecture optimization support currently seeing a revival due to many distributions looking into providing optimized x86_64 variants? [1] Adrian > [1] > https://www.phoronix.com/scan.php?page=news_item&px=Fedora-2021-x86_64-Level -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Update Debian Ports installation images 2021-04-14
Hello! I just uploaded updated Debian Ports installation images that were created today and ship with the latest Debian unstable kernel (5.10) and all other packages updated to their latest version in Debian unstable. If you test these images, please let me know if you run into any issues. Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-14/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: X11 system lockup with 5.11.0 kernel
Hi Christian! On 4/6/21 12:15 PM, Christian König wrote: > Am 06.04.21 um 11:14 schrieb Michael Cree: >> On Tue, Apr 06, 2021 at 09:08:10AM +0200, Christian König wrote: >>> That is a known issue fixed in follow up 5.11.x kernels. >> Well, it's intriguing that you say that because the latest 5.11.x >> kernel available from >> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kernel.org%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C4bc7eae6b1c14259a35608d8f8dc6908%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637532973258538981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hgwidEjS4X1IBGx7koSUTWW0y3WHAN4AT4moJvf%2BK3s%3D&reserved=0 >> (i.e. 5.11.11) is also bad >> and locks up hard when X is started on my Alpha XP1000. > > Well *that* is rather interesting. We have considered dropping Alpha support > because we couldn't find somebody with that hardware any more. There are plenty of us within the Gentoo, Debian and NetBSD projects, just ask :-). We're also supporting everything else that most commercial vendors consider obsolete such as PA-RISC, M68k, big-endian PowerPC (32 and 64 bits) SPARC and so on, in case you need testing there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#986009: installation-reports: document qemu workarounds and bug in newer d-i image
On 3/27/21 10:18 PM, Thorsten Glaser wrote: >> The debian-installer tarballs are completely untested. We have ISO images >> in the snapshots folder which you should use. > > Yeah, I did that later. The tarball there was the first thing I found, > though, and its ISO subdirectory contains only kernel and initrd :/ > > In contrast to e.g. ppc64el, which ISO to use is hard to figure out. > > (As I wrote, the latest ISO didn’t work, I had to use an older one.) I'm basically maintaining this as a one-man army while the release architectures have lots of people taking care of the development and testing. >> If the nic-modules package is missing, it needs to be added to the pkg-list >> for d-i for netboot. > > No, this was the ISO subdirectory, not netboot, I use -net nic -net user > and so don’t have netboot set up. This is a throwaway VM for a oneshot. In any case, you used the wrong image. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#986009: installation-reports: document qemu workarounds and bug in newer d-i image
Hi Thorsten! On 3/27/21 8:32 PM, Thorsten Glaser wrote: > - > https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz > is insufficient, it lacks the ISO which contains nic-modules The debian-installer tarballs are completely untested. We have ISO images in the snapshots folder which you should use. If the nic-modules package is missing, it needs to be added to the pkg-list for d-i for netboot. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#983308: vim: Please disable Ruby interpretor support on alpha and ia64
Source: vim Severity: normal Tags: patch User: debian-alpha@lists.debian.org Usertags: alpha ia64 X-Debbugs-Cc: debian-alpha@lists.debian.org,debian-i...@lists.debian.org Hi! The Ruby interpretor is not fully working on alpha and ia64 and regularly causes the vim testsuite to fail on these architectures. Since vim is a key package that must always be up to date for debootstrap to work properly (and hence every FTBFS causes debootstrap to fail on these targets), I would like to disable Ruby interpreter support on alpha and ia64 to make sure that debootstrap will always succeed on these targets. Could you make the following change to debian/rules to disable Ruby on alpha and ia64? --- debian/rules.orig 2021-02-20 19:46:51.0 +0100 +++ debian/rules2021-02-22 10:56:44.629286099 +0100 @@ -94,7 +94,10 @@ ALLINTERPFLAGS += --enable-perlinterp ALLINTERPFLAGS += --enable-python3interp --with-python3-config-dir=$(shell python3-config --configdir) ALLINTERPFLAGS += --disable-pythoninterp +# Disable Ruby support where it's unreliable +ifeq (,$(filter alpha ia64, $(DEB_HOST_ARCH))) ALLINTERPFLAGS += --enable-rubyinterp +endif ALLINTERPFLAGS += --enable-tclinterp ALLINTERPFLAGS += --with-tclsh=/usr/bin/tclsh I'm also attaching a patch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2021-02-20 19:46:51.0 +0100 +++ debian/rules2021-02-22 10:56:44.629286099 +0100 @@ -94,7 +94,10 @@ ALLINTERPFLAGS += --enable-perlinterp ALLINTERPFLAGS += --enable-python3interp --with-python3-config-dir=$(shell python3-config --configdir) ALLINTERPFLAGS += --disable-pythoninterp +# Disable Ruby support where it's unreliable +ifeq (,$(filter alpha ia64, $(DEB_HOST_ARCH))) ALLINTERPFLAGS += --enable-rubyinterp +endif ALLINTERPFLAGS += --enable-tclinterp ALLINTERPFLAGS += --with-tclsh=/usr/bin/tclsh
Bug#979757: scummvm: Please disable Ultima on the remaining big-endian targets as well
Source: scummvm Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-alpha@lists.debian.org,debian-powe...@lists.debian.org,,debian-h...@lists.debian.org,,debian-...@lists.debian.org,debian-sp...@lists.debian.org,debian-ri...@lists.debian.org,debian-i...@lists.debian.org Hi! The fix for #975492 [1] unfortunately covered a few of the big-endian targets we have in Debian only, namely s390x, which is why src:scummvm is still failing to build from source on alpha, hppa, powerpc, ppc64, riscv64 and sparc64 [2]. It would FTBFS on m68k and sh4 as well but the buildds currently don't run the testsuites there on these targets as these buildds are QEMU-based. Could you disable Ultima on the following targets as well? - alpha - hppa - ia64 - m68k - powerpc - ppc64 - riscv64 - sh4 - sparc64 Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975492 > [2] https://buildd.debian.org/status/package.php?p=scummvm&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Updated installer images 2020-12-02
Hi! I uploaded updated Debian installer CD images today. These come with the latest versions of the kernel and the debian-installer application as well as various other updates. The images can be found at the usual location [1] as well as the debian-installer for netboot [2]. Known issues: - We still don't have support for contrib and non-free, so the images are missing non-free firmware. It is planned that the Debian Ports FTP server will be extended to support contrib and non-free but I don't have any influence on that as this is up to the Debian Ports FTP maintainers. So far, I have tested the images on sparc64 only. Please test on the other architectures and report back. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2020-12-03/ > [2] https://cdimage.debian.org/cdimage/ports/debian-installer/2020-12-03/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#974878: libio-pty-perl: Patch Add-termios-data-structures-for-alpha.patch can be dropped
Source: libio-pty-perl Severity: normal User: debian-alpha@lists.debian.org Usertags: alpha X-Debbugs-Cc: debian-alpha@lists.debian.org Hi! The patch Add-termios-data-structures-for-alpha.patch that was introduced in #82627 [1] in 2001 is no longer necessary and can safely be dropped, the package builds fine without the patch - although the testsuite sometimes struggles on the buildds which are SMP machines. That's unreleated to the patch though. Can you drop the patch Add-termios-data-structures-for-alpha.patch for the next upload? Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=82627 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972510: (no subject)
Source: glibc Version: 2.31-4 Severity: normal User: debian-sp...@lists.debian.org Usertags: alpha hppa ia64 m68k sh4 sparc64 Hello! The two tests: FAIL: misc/tst-sbrk FAIL: misc/tst-sbrk-pie fail on multiple architectures. According to the discussion in #debian-ports, the tests are broken and not really necessary anyway: jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a *lot* of architectures jrtc27 | if it were up to me the problem would be solved by just deleting sbrk... jrtc27 | FreeBSD just took the stance of not implementing them for new ports jrtc27 | so it's arm64 and riscv64 ports just have no sbrk jrtc27 | cbmuser: looks like the tests are Debian-specific jrtc27 | added as part of Hurd sbrk reworking to test it didn't break Can we disable them? With the tests disabled, glibc should pass its testsuite on at least alpha and sparc64. Not sure what the problem with hppa is at the moment. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: DS15 with kernel 5.8.1
On 8/17/20 9:42 PM, Michael Cree wrote: >> As I posted last month, my old version of iceweasel was deleted by apt. >> I downloaded the deb file for firefox 52.6 alpha, but when trying to install >> I get the following errors: > > I doubt if we ever will have firefox built on Alpha again. It now > depends on the rust compiler which depends on LLVM, which does not > support Alpha and it would be a major piece of work to implement. I don't think rustc will be the only Rust compiler in the foreseeable future as there are two gcc-based [1, 2] and one freestanding approach [3] in development. Adrian > [1] https://github.com/philberty/gccrs/ > [2] https://github.com/sapir/gcc-rust > [3] https://github.com/thepowersgang/mrustc -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: sources.list for debian alpha
Hello! On 7/31/20 7:51 AM, Ivan Carrillo-Nava wrote: > My debian alpha box was off for a long time (over 2 years). > When I turned it back on a few days ago and tried to update, the keys had > expired so I got a new one and started updating. > apt reported several packages had to be deleted (cinnamon amongst them). > So my alpha debian box runs mate now. But I believe I'm not getting many of > the updates. > The framebuffer seems very slow now compared to how it was working before it > went on "vacation". > I remember several xserver packages were among those listed for deletion. Can you run provide information on the graphics adapter you are using, i.e. by providing the output of "lspci" and "glixinfo"? Chances are that the drivers for your graphics adapter were removed. > Hardinfo GPU test now takes forever. > Tried to download the firefox-esr 52.6 but it was "not found". There is no current version of Firefox for Alpha as building Firefox requires Rust and NodeJS these days which we don't have for Alpha yet. > Does anyone have a sources.list file example for debian alpha? > The machine is a DS15. The DS-15 would be very useful for helping us build packages for Debian Alpha. Do you think you could set up the machine as a build machine? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
