Bug#931873: texlive-bin: FTBFS on sparc64
Package: src:texlive-bin Followup-For: Bug #931873 User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! The attached patch should fix the issue. It just enables the alignment fixes the code has for ARM and Solaris for Linux on SPARC which means all machines where the compiler defines "__sparc__". The most generic approach would be to replace all instances of ( defined(__sun) && defined(__SVR4)) with defined __sparc since "__sparc" is defined on both Solaris/SPARC and Linux/SPARC (and I'm quite confident it's also defined on Free,Open,NetBSD/SPARC). Testing for "( defined(__sun) && defined(__SVR4))" actually assumes that Solaris runs on SPARC only which is not the case. Solaris runs on x86 as well and x86 doesn't have these alignment issues. Hence, the proper way is to detect the architecture and not the opering system. 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 Description: Fix alignment issues on sparc64 Author: John Paul Adrian Glaubitz Last-Update: 2019-08-15 --- texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/ppconf.h +++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/ppconf.h @@ -3,7 +3,7 @@ #define PP_CONF_H //#include "utilarm.h" // keep in sync -#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||( defined(__sun) && defined(__SVR4)) +#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||defined __sparc__ ||( defined(__sun) && defined(__SVR4)) # define ARM_COMPLIANT 1 #else # define ARM_COMPLIANT 0 --- texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/ppheap.c +++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/ppheap.c @@ -15,7 +15,11 @@ #if defined(__sun) && defined(__SVR4) # define PPHEAP_NEED_ALIGNMENT #endif - + +#if defined(__sparc__) +# define PPHEAP_NEED_ALIGNMENT +#endif + #ifdef PPHEAP_NEED_ALIGNMENT /* Tests has shown that long double seems to work: */ /* for 32bit aligned_data has algn: 64 as ppxref and ppref, */ --- texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/util/utilarm.h +++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/util/utilarm.h @@ -1,10 +1,10 @@ #ifndef UTIL_ARM_H #define UTIL_ARM_H -#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||( defined(__sun) && defined(__SVR4)) +#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||defined __sparc__ ||( defined(__sun) && defined(__SVR4)) # define ARM_COMPLIANT 1 #else # define ARM_COMPLIANT 0 #endif -#endif \ No newline at end of file +#endif
Bug#931873: texlive-bin: FTBFS on sparc64
Am 14.08.2019 um 12:44 teilte John Paul Adrian Glaubitz mit: > On 7/29/19 11:49 PM, Hilmar Preuße wrote: Hi, >> My account was approved today. Logging in into that fine server however >> does not work: shortly after I reached the command prompt the connection >> terminates. > > Try using a different host as jumphost. For some reason, I have connection > problems when connecting from but connecting from my work machine works > fine. We haven't found out yet what the problem is. > That works a little better, I could access gcc202: debuild -b: dpkg-buildpackage: info: host architecture sparc64 dpkg-checkbuilddeps: error: Unmet build dependencies: libbrotli-dev libgd-dev libgs-dev libpaper-dev libpotrace-dev (>= 1.11) libteckit-dev libwoff-dev libxxhash-dev libzzip-dev (>= 0.12) You could install the BD's for reproduction, however I'm pretty sure I can't really help here. I'm not a programmer, hence this is out of my scope. I'd wait if Luigi finds something. If not, I'll tag that bug "help". Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#931873: texlive-bin: FTBFS on sparc64
Hi! On 7/29/19 11:49 PM, Hilmar Preuße wrote: >> FWIW, we have another machine set up for sparc64 which is part of the gcc >> compile farm [1]. If you request an account there, the answer should usually >> not take more than 24 hours. Since I have admin rights on all of these >> Linux/sparc64 machines, I can also install build dependencies if you need >> them. >> >> The machine used for the gcc compile farm is also much faster than kyoto. >> > My account was approved today. Logging in into that fine server however > does not work: shortly after I reached the command prompt the connection > terminates. Try using a different host as jumphost. For some reason, I have connection problems when connecting from but connecting from my work machine works fine. We haven't found out yet what the problem is. > Anyway: upstream is aware of the problem, hence I don't see any need to > do something from my side for the time being. Has there been any progress 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
Bug#931873: texlive-bin: FTBFS on sparc64
Am 19.07.2019 um 10:43 teilte John Paul Adrian Glaubitz mit: Hi, > FWIW, we have another machine set up for sparc64 which is part of the gcc > compile farm [1]. If you request an account there, the answer should usually > not take more than 24 hours. Since I have admin rights on all of these > Linux/sparc64 machines, I can also install build dependencies if you need > them. > > The machine used for the gcc compile farm is also much faster than kyoto. > My account was approved today. Logging in into that fine server however does not work: shortly after I reached the command prompt the connection terminates. Anyway: upstream is aware of the problem, hence I don't see any need to do something from my side for the time being. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#931873: texlive-bin: FTBFS on sparc64
On Sun, 21 Jul 2019, John Paul Adrian Glaubitz wrote: > Could you make them aware this issue does not only affect SPARC on Solaris > but also SPARC on Linux? That probably needs to go to the luatex-dev mailing list, as TL just gets what the luatex maintainers put into the repo. It would be a good idea to check whether luatex svn suffers the same problem. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#931873: texlive-bin: FTBFS on sparc64
> On Jul 21, 2019, at 9:44 AM, Hilmar Preuße wrote: > > Two remarks: > > 1. I applied for access to Debian sparc64 porterbox too. > 2. Upstream seems to be aware of the problem: > https://tug.org/pipermail/tlbuild/2018q3/004292.html Looks like they apply the fix conditionally on Solaris only which I think is a rather bad approach. They should fix the alignment unconditionally as you can see there can be architecture/platform combinations they haven’t predicted. Could you make them aware this issue does not only affect SPARC on Solaris but also SPARC on Linux? Thanks, Adrian
Bug#931873: texlive-bin: FTBFS on sparc64
On 19.07.19 10:43, John Paul Adrian Glaubitz wrote: > On 7/19/19 10:33 AM, Hilmar Preuße wrote: Hi, >> Yes, but I'm just a DM, hence I'd need to open an RT to get access. Last >> time I did so, it took > 2 month to get access: [rt.debian.org #7752]. > > I see. I can send the request for you if you want. > Two remarks: 1. I applied for access to Debian sparc64 porterbox too. 2. Upstream seems to be aware of the problem: https://tug.org/pipermail/tlbuild/2018q3/004292.html H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#931873: texlive-bin: FTBFS on sparc64
On 19.07.19 10:43, John Paul Adrian Glaubitz wrote: > On 7/19/19 10:33 AM, Hilmar Preuße wrote: Hi, >> Yes, but I'm just a DM, hence I'd need to open an RT to get access. Last >> time I did so, it took > 2 month to get access: [rt.debian.org #7752]. > > I see. I can send the request for you if you want. > Well, I can send the request myself. Does the processing speed depends on "who" sent the request? >> If you could look into this within the next days, you're probably faster >> than the people processing the RT ticket. ;-( > > FWIW, we have another machine set up for sparc64 which is part of the gcc > compile farm [1]. If you request an account there, the answer should usually > not take more than 24 hours. Since I have admin rights on all of these > Linux/sparc64 machines, I can also install build dependencies if you need > them. > > The machine used for the gcc compile farm is also much faster than kyoto. > Running Debian unstable/testing on an "UltraSparc T5"? Sounds like fun. I've applied for an account there. Let's see how fast they respond. Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#931873: texlive-bin: FTBFS on sparc64
Hi Hilmar! On 7/19/19 10:33 AM, Hilmar Preuße wrote: >> This should be easy to debug. Just build the package on the sparc64 >> porterbox (currently kyoto.debian.net) and let the testsuite run. >> > Yes, but I'm just a DM, hence I'd need to open an RT to get access. Last > time I did so, it took > 2 month to get access: [rt.debian.org #7752]. I see. I can send the request for you if you want. >> I will try to look at this issue and provide a patch within the next >> days. >> > If you could look into this within the next days, you're probably faster > than the people processing the RT ticket. ;-( FWIW, we have another machine set up for sparc64 which is part of the gcc compile farm [1]. If you request an account there, the answer should usually not take more than 24 hours. Since I have admin rights on all of these Linux/sparc64 machines, I can also install build dependencies if you need them. The machine used for the gcc compile farm is also much faster than kyoto. Adrian > [1] https://gcc.gnu.org/wiki/CompileFarm -- .''`. 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#931873: texlive-bin: FTBFS on sparc64
On 19.07.19 09:33, John Paul Adrian Glaubitz wrote: Hi Adrian, > This should be easy to debug. Just build the package on the sparc64 > porterbox (currently kyoto.debian.net) and let the testsuite run. > Yes, but I'm just a DM, hence I'd need to open an RT to get access. Last time I did so, it took > 2 month to get access: [rt.debian.org #7752]. > I will try to look at this issue and provide a patch within the next > days. > If you could look into this within the next days, you're probably faster than the people processing the RT ticket. ;-( Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#931873: texlive-bin: FTBFS on sparc64
Package: src:texlive-bin Followup-For: Bug #931873 User: debian-sp...@lists.debian.org Usertags: sparc64 Hello! This should be easy to debug. Just build the package on the sparc64 porterbox (currently kyoto.debian.net) and let the testsuite run. After the crash has occurred, load the luatex binary into gdb, run it and wait for the crash. Then show the backtrace with "bt" and gdb should be able to tell you where the unaligned access happens. You will most like find some weird pointer arithmetics or casting at the offending code position which you should be able to mitigate by using memcpy() instead of a simple assignment, see for example [1]. I will try to look at this issue and provide a patch within the next days. Adrian > [1] > https://github.com/python-pillow/Pillow/pull/3225/commits/7a4af2b7671b14163f61c7f9fad66e50d77b -- .''`. 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#931873: texlive-bin: FTBFS on sparc64
Source: texlive-bin Version: 2019.20190605.51237-2 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) It fails to build for a few versions now. https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=sparc64=2019.20190605.51237-2=1562791518=0 ./luatex -fmt=luaimage luaimage || exit 1 + ./luatex -fmt=luaimage luaimage This is LuaTeX, Version 1.10.0 (TeX Live 2019/Debian) restricted system commands enabled. (../../../texk/web2c/luatexdir/tests/luaimage.tex [1<../../../texk/web2c/tests/ 1-4.jpg>]Bus error + exit 1 FAIL luatexdir/luaimage.test (exit status: 1) H. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled