Re: On the existance of arm* porters
On 2022-08-25 17:30 +0100, Steve McIntyre wrote: > On Thu, Aug 25, 2022 at 09:15:07AM -0700, ` Vagrant Cascadian wrote: > >On 2022-08-25, Graham Inggs wrote: > > > >Apparently I am the only porter for armhf and arm64? I had assumed there > >would be someone else to fill the gaps in my skillset, but I guess > >not. > > Argh. I used to do this, but I don't have the time or the inclination > to step up any more. I'm very surprised to not see Wookey not list > himself, tbh. Yeah I should be on the list, but it looks like I wrote a reply to the 'call for porters' back in Decemeber, but stopped to look something up, got distracted and never actually sent it. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On the existance of arm* porters
On Thu, Aug 25, 2022 at 09:15:07AM -0700, ` Vagrant Cascadian wrote: >On 2022-08-25, Graham Inggs wrote: >> On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz >> wrote: > >>> it seems superficially plausible that the march=native >>> invocations are just instances of the compiler being probed. >> >> I have also had a look and cannot see that '-march=native' is used in >> the actual builds on any of the architectures. >> >> It would be very much appreciated if the arm porters could take a look >> at this issue, as it still plagues the scikit-learn autopkgtests on >> armhf [2], and currently prevents quite a number of packages from >> being part of testing. It appears that armel [1] has the same error, >> so hopefully one fix could resolve both. > >I pretty much think of myself, at best, as half an armhf/arm64 porter, >but this is a little bit outside of the scope of what I offered to look >after in the porter roll calls... > >Apparently I am the only porter for armhf and arm64? I had assumed there >would be someone else to fill the gaps in my skillset, but I guess >not. Argh. I used to do this, but I don't have the time or the inclination to step up any more. I'm very surprised to not see Wookey not list himself, tbh. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
On the existance of arm* porters
On 2022-08-25, Graham Inggs wrote: > On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz > wrote: >> it seems superficially plausible that the march=native >> invocations are just instances of the compiler being probed. > > I have also had a look and cannot see that '-march=native' is used in > the actual builds on any of the architectures. > > It would be very much appreciated if the arm porters could take a look > at this issue, as it still plagues the scikit-learn autopkgtests on > armhf [2], and currently prevents quite a number of packages from > being part of testing. It appears that armel [1] has the same error, > so hopefully one fix could resolve both. I pretty much think of myself, at best, as half an armhf/arm64 porter, but this is a little bit outside of the scope of what I offered to look after in the porter roll calls... Apparently I am the only porter for armhf and arm64? I had assumed there would be someone else to fill the gaps in my skillset, but I guess not. Help? live well, vagrant signature.asc Description: PGP signature
Re: Bug#1017537: armel buildd misconfiguration
Arnd Bergmann dixit: >Yes, that sounds reasonable in principle. OK, good. I’ll do that then when I’m caught up with dayjob work. >I've tried to come up with a minimal test case like Meh, I’m just going to write a main.s ;-) I like assembly. Also, less surprises there. GCC is… bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Bug#1017537: armel buildd misconfiguration
On Wed, Aug 24, 2022 at 8:03 PM Thorsten Glaser wrote:
> Do you think it would be worth compiling a VERY tiny program from
> execute_before_dh-auto-build that just runs an swp instruction, and
> if that fails, issue a message pointing to your message? I’m doing
> something similar for mksh wrt. the existence of /dev/{tty,pts,ptmx}
> but here it can obviously only be done if not cross-compiling (but
> that’s not a problem because the tests can only run then either).
Yes, that sounds reasonable in principle. I've tried to come up with a
minimal test case like
echo 'int main(void) { static int a, b, c; return
__atomic_exchange_n(, b, 0); }' | \
gcc -S -xc - -O2 -o testswp
However, this does not actually use the swp instruction but calls
the correct libgcc function __sync_val_compare_and_swap_4(),
which in turn uses a VDSO helper provided by the kernel to
do this in a portable way using either swp or ldrex/strex depending
on the running CPU.
So an even better way to handle this would be to use the gcc
builtins in place of the assembler implementation, or copy
the portable code from musl, which uses the VSDO version
explicitly:
#define a_cas a_cas
static inline int a_cas(volatile int *p, int t, int s)
{
for (;;) {
register int r0 __asm__("r0") = t;
register int r1 __asm__("r1") = s;
register volatile int *r2 __asm__("r2") = p;
register uintptr_t r3 __asm__("r3") = __a_cas_ptr;
int old;
__asm__ __volatile__ (
BLX " r3"
: "+r"(r0), "+r"(r3) : "r"(r1), "r"(r2)
: "memory", "lr", "ip", "cc" );
if (!r0) return t;
if ((old=*p)!=t) return old;
}
}
Re: Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi Adrian On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz wrote: > On 2/16/22 12:33, Christian Kastner wrote: > >> Bus errors are normally easy to spot. Just run the code in question through > >> GDB and see where it crashes. Then look at the backtrace with the debug > >> symbols installed. > >> > >> Usually it's a result of bad pointer arithmetics which should definitely be > >> fixed as such operations usually violate the C/C++ standards. > >> > >> I can have quick look. > > > > one of these errors has been reported in the past, and I already did > > some analysis way back then: > > > > https://github.com/scikit-learn/scikit-learn/issues/16443 > > > > Check the last comment. The relevant Cython code doesn't look wrong, so > > I guess the problem is with the binary result produced during build, as > > you point out. > > I'm happy to look at this issue but first the baseline issue must be fixed > as this is a Debian Policy violation. It was pointed out by Gard Spreemann [1], but I notice now that debian-arm was not in CC: > it seems superficially plausible that the march=native > invocations are just instances of the compiler being probed. I have also had a look and cannot see that '-march=native' is used in the actual builds on any of the architectures. It would be very much appreciated if the arm porters could take a look at this issue, as it still plagues the scikit-learn autopkgtests on armhf [2], and currently prevents quite a number of packages from being part of testing. It appears that armel [1] has the same error, so hopefully one fix could resolve both. Regards Graham [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003165#86 [2] https://ci.debian.net/packages/s/scikit-learn/testing/armhf/ [3] https://ci.debian.net/packages/s/scikit-learn/testing/armel/
Re: Bug#1017961: mozjs102: Fails to build on armel
On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote: > Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619 Upstream suggested that I should also turn off the JIT (see patch attached to the upstream bug), but that doesn't seem to have helped with the test failures. The test suite is segfaulting in most tests in the Atomics/*/bigint family: ## test262/built-ins/Atomics/xor/bigint/good-views.js: rc = -11, run time = 0.030321 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/good-views.js | (args: "") [0.0 s] ## test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js: rc = -11, run time = 0.038158 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js | (args: "") [0.0 s] ## test262/built-ins/Atomics/or/bigint/good-views.js: rc = -11, run time = 0.038281 (etc.) and there is also a non-segfault test failure: ## test262/built-ins/Atomics/compareExchange/good-views.js: rc = 3, run time = 0.03819 /home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7 uncaught exception: Test262Error: The value of view[3] is 0 Expected SameValue(«-5», «0») to be true (Testing with Int16Array.) Stack: testWithTypedArrayConstructors@/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7 @/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/compareExchange/good-views.js:16:31 TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/compareExchange/good-views.js | (args: "") [0.0 s] I don't have a good picture of where this puts us on a scale from "it's basically fine" to "armel users will report grave bugs in gjs-based packages whenever they try to run them, because they're hopelessly crashy". Does anyone have a better idea of whether these test failures are ignorable or RC? I don't want to end up in a situation where the GNOME team is responsible for fixing atomic ops that we don't understand, on machines that can't run GNOME and are unsupported by upstream, under the threat of having GNOME removed from Debian if we can't. I'm doing all this remotely on a porterbox, because my only armel machine was de-supported in Debian 11 due to kernel size issues and is headless anyway, so I can't run practical gjs apps on armel myself (and in any case it would take hours if not days to compile mozjs on actually-armel hardware). As another possible route, I've opened a release team bug inquiring about architecture-specific removals of gjs and rdeps from armel (#1018076). smcv
Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel
Package: rele...@debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-arm@lists.debian.org, debian-gtk-gn...@lists.debian.org The plan is for Debian 12 to release with GNOME 43, which is currently in beta upstream. Beta versions of individual GNOME 43 packages are gradually making their way into either unstable if they are not disruptive, or experimental if they are. One of the new packages we need is an update to gjs, GNOME's JavaScript environment, which depends on mozjs102 (Spidermonkey), the latest stable-branch of Mozilla's JavaScript engine. mozjs102 makes more use of atomic operations, which are available on all architectures except for armel (because armel is ARMv5, and useful atomics are ARMv6 or ARMv7 instructions). This has led to a few different failure modes when building mozjs102 on armel (#1017979, #1017961). Even if we can solve them eventually, I think delaying GNOME 43 for the benefit of machines that are not powerful enough to run GNOME would be doing a disservice to our users. So I think we need to be looking at the possibility of doing architecture-specific removals of gjs and dependent packages from armel. Based on prior experience of similar architecture-specific removals from s390x when mozjs was compiling-but-broken on that architecture, I think this would involve: - removing gjs - removing gnome-shell (and its extensions) - removing gdm3 - either hacking gnome-panel to be able to compile without gdm3, or removing it - either hacking meta-gnome3 to install a non-GNOME display manager and the GNOME Flashback desktop environment (basically a GNOME 2 fork) instead of real GNOME, or leaving it unmodified but accepting that gnome-core and therefore task-gnome-desktop are uninstallable on armel - disabling a subset of unit tests in src:ostree (which want gjs) - removing leaf apps written in JavaScript, such as polari Obviously that's quite a bit of churn, mostly in packages that, in practice, have never been useful to run on the 2009-2010 plug computers that seem to be the main use-case for armel. Is armel a realistic candidate for being a Debian 12 release architecture? It's already lacking other important packages like Firefox, and if it ceased to be treated as a release architecture very soon, then we wouldn't have to do all this work to coax GNOME into testing despite armel. Or, failing that, is it still the release team's position that all task packages are required to be installable on all architectures, and that it is preferable to have a task install the wrong things rather than have it be uninstallable? If we could have task-gnome-desktop and gnome-core just be uninstallable on armel, and have the testing machinery accept and ignore that, then that would seem more honest than having to modify them like we did for s390x[1]. As with my previous work on mozjs + s390x, it is worth noting that I am not an ARM porter or an ARM desktop user, my only armel machine is no longer supported as of Debian 11 and was never able to run GNOME in any case, and I have no special knowledge of mozjs. However, the release-architecture constraints demand that someone sorts this out before we can have a new GNOME release in testing, and I am someone, so I'm doing my best. Anyone with useful knowledge of these architectures and packages is very welcome to help! Thanks, smcv [1] https://lists.debian.org/debian-release/2018/12/msg00287.html
