Bug#1093861: mame: FTBFS on armel: ld.gold: out of memory

Source: mame Version: 0.273+dfsg.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-arm@lists.debian.org Usertags: armel X-Debbugs-CC: debian-arm@lists.debian.org Control: block 1092719 by -1 As noted in #1092719, mame fail

Re: RM: directfb -- RoQA; RC-buggy, unmaintained

eps remains (BTS blocker set, so it will disappear once the fix > is uploaded). I believe this was gst-plugins-bad1.0, which was uploaded today to disable the directfb feature. Original report quoted below for the ftp team. > On Mon, 30 Sep 2024 12:06:52 +0100 Simon McVittie wrote

Re: Bug#1087824: openal-soft: FTBFS on armel: static assertion failed: std::atomic::is_always_lock_free

Control: forwarded -1 https://github.com/kcat/openal-soft/issues/1059 On Tue, 19 Nov 2024 at 09:33:52 +0100, Matthias Klose wrote: > /<>/core/device.cpp:12:54: error: static assertion failed >12 | > static_assert(std::atomic::is_always_lock_free); If OpenAL now requires lock-free atomics, the

Bug#1087563: pcre2: FTBFS on armel: RunTest and pcre2_jit_test segfault

Source: pcre2 Version: 10.44-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel https://buildd.debian.org/status/fetch.php?pkg=pcre2&arch=armel&ve

Bug#1087564: pcre2: FTBFS on 32-bit: test failures, memory allocations smaller than expected

Source: pcre2 Version: 10.44-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org, debian-h...@lists.debian.org, debian-powe...@lists.debian.org, b...@debian.org User: debian-arm@lists.debian.org Us

Bug#1086231: libchamplain: FTBFS on 32-bit with 64-bit time_t: passing argument 1 of ‘gmtime’ from incompatible pointer type

Source: libchamplain Version: 0.12.21-1 Severity: serious Tags: ftbfs trixie sid upstream Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel armhf Forwarded: https://gitlab.gnome.

Re: Bug#1084133: mutter: FTBFS on armhf: Directory "/tmp/.X11-unix" is not writable

Control: tags -1 + pending On Sun, 06 Oct 2024 at 22:54:54 +0100, Simon McVittie wrote: > I think what is happening in mutter could perhaps be this: > > mutter requires /tmp/.X11-unix (for Xwayland) for some of its unit tests. > > On architectures where xvfb-run works as inten

Re: Bug#1084133: mutter: FTBFS on armhf: Directory "/tmp/.X11-unix" is not writable

On Sat, 05 Oct 2024 at 14:19:50 +0100, Simon McVittie wrote: > The error message suggests that there might be a problem with the > chroot/container, or possibly with the host /tmp being shared with it: > > > Bail out! libmutter-FATAL-ERROR: Failed to start X Wayland: Directory

Re: Bug#1084133: mutter: FTBFS on armhf: Directory "/tmp/.X11-unix" is not writable

On Sat, 05 Oct 2024 at 17:35:46 +0200, Aurelien Jarno wrote: > Everything is fine on the buildds side. Both arm64 and armhf chroots on > the above buildds have an empty 1777 root:root /tmp directory. ... > Chroots are created identically in schroot and unshare mode. /tmp is > part of the chroot, an

Bug#1084133: mutter: FTBFS on armhf: Directory "/tmp/.X11-unix" is not writable

Source: mutter Version: 47.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org, ar...@buildd.debian.org User: debian-arm@lists.debian.org Usertags: armhf Control: block 1081519 by -1 The recent u

Bug#1083037: directfb: Should this package be removed?

Source: directfb Severity: serious Justification: ensure visibility for potential adopters X-Debbugs-Cc: debian-arm@lists.debian.org, debian...@lists.debian.org User: debian...@lists.debian.org Usertags: directfb directfb has been unmaintained in Debian since 2018, and its web pages directfb.org a

Bug#1082659: libunwind8: 1.7 regression: Xvfb segfaults on armhf

Package: libunwind8 Version: 1.7.2-1 Severity: serious Justification: results in FTBFS in unrelated packages X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armhf The test suite for the libportal package, like many packages that use GUI libraries, is run under

Bug#1082588: libportal: FTBFS on armhf: tests pass but then command exits with status 1

Source: libportal Version: 0.8.1-1 Severity: serious Tags: ftbfs help Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armhf My recent libportal upload repeatably fails to build on a

Bug#1082389: RM: src:gjs and rdeps [armel] -- RoM/RoQA; #1080521

Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, eos-...@packages.debian.org, foli...@packages.debian.org, gnome-shell-extension-panel-...@packages.debian.org, gnome-shell-pomod...@packages.debian.org, gpa...@packages.debian.org, debian-arm@lists.debian.

Bug#1082284: libunwind: FTBFS on arm64: expected 'unw_tdep_context_t *' but argument is of type 'ucontext_t *'

Source: libunwind Version: 1.7.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-arm@lists.debian.org Usertags: arm64 X-Debbugs-Cc: debian-arm@lists.debian.org Vaguely similar to the i386 build failure in the same version

Re: Bug#1081515: gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display

Control: retitle -1 gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display Control: severity -1 serious (Please remove -ports from cc in replies, this is no longer believed to be -ports specific) On Thu, 12 Sep 2024 at 11:48:21 +0100, Simon McVittie wrote

Bug#1081515: gtk4: FTBFS on -ports architectures: many tests fail with --setup=wayland: Failed to open display

Source: gtk4 Version: 4.14.4+ds-8 Severity: important Tags: ftbfs help X-Debbugs-Cc: debian-po...@lists.debian.org Until recently, gtk4 was not buildable on any -ports architectures because its build-dependency, weston, was uninstallable. Now it's installable, and building and testing can be attem

Re: Bug#1080521: transition: Removing gjs and GNOME Shell from armel

On Thu, 05 Sep 2024 at 11:44:31 +0100, Simon McVittie wrote: > mozjs128 fails several tests on armel (#108) because armel's > lack of atomic integer operations results in [badness] Deja vu: we had a very similar situation almost exactly 2 years ago, when we were integrating the GN

Bug#1080521: transition: Removing gjs and GNOME Shell from armel

Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, debian-arm@lists.debian.org Control: affects -1 + src:gjs User: release.debian@packages.debian.org Usertags: transition gjs is a JavaScript language binding for GLib-based libraries, required by GNOME

Bug#1080323: gnome-snapshot: FTBFS on armel, armhf: LLVM runs out of memory

Source: gnome-snapshot Version: 47~beta-1 Severity: serious Tags: experimental ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-arm@lists.debian.org Usertags: armel armhf X-Debbugs-CC: debian-arm@lists.debian.org, debian-r...@lists.debian.org The ne

Re: Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

On Sun, 01 Sep 2024 at 13:01:17 +, Martin wrote: > My company is still a heavy user of glib and gobject on armel. But > certainly not of GTK. Is there still any use case for GTK on armel? Probably not, but Debian has never really managed to do partial architectures, which is why I felt obliged

Re: Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

a first-class-citizen architecture for GTK for whatever reason, please take over here. Thanks, smcv From: Simon McVittie Date: Sat, 31 Aug 2024 10:13:48 +0100 Subject: gtkcssnumbervalue: Don't use fesetround() on ARM softfloat Older ARM CPUs have to emulate floating-point in softwar

Bug#1080000: mozjs128: SharedArrayBuffer feature unavailable on armel

Source: mozjs128 Version: 128.1.0-3 Severity: important Tags: ftbfs User: debian-arm@lists.debian.org Usertags: armel X-Debbugs-CC: debian-arm@lists.debian.org After fixing #1079077, mozjs128 still fails to build on armel, because the lack of lockless atomic operations results in the SharedArrayBu

Re: Bug#1079077: mozjs128: Fails to build on armel

Control: tags -1 + upstream pending Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1915578 On Mon, 19 Aug 2024 at 16:51:35 -0400, Jeremy Bícha wrote: > I attempted a very simple -latomic fix but it failed. mozjs has a more > complicated buildsystem so maybe I didn't set it in t

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

It seems that some of the dependency chains for packages that are still waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the default Java version for most architectures and Build-Depends on itself (with an alternative dependency on openjdk-16, but that no longer exists). evoluti

Bug#1067559: nmu: roc-toolkit_0.3.0+dfsg-7

Package: release.debian.org Severity: normal X-Debbugs-Cc: roc-tool...@packages.debian.org, debian-arm@lists.debian.org Control: affects -1 + src:roc-toolkit User: release.debian@packages.debian.org Usertags: binnmu Another binNMU suggestion for the 64-bit time_t transition. This one would par

Bug#1067430: nmu: graphviz_2.42.2-9

Package: release.debian.org Severity: normal X-Debbugs-Cc: graph...@packages.debian.org, debian-arm@lists.debian.org Control: affects -1 + src:graphviz User: release.debian@packages.debian.org Usertags: binnmu libgvc6_2.42.2-9_armel depends on libglib2.0-0t64 (the "new" side of the 64-bit time

Re: Bug#1067421: nmu: gstreamer1.0_1.24.0-1

On Thu, 21 Mar 2024 at 11:49:22 +, Simon McVittie wrote: > gst-plugins-base1.0 is currently unbuildable on armel and armhf due to > gstreamer1.0 having been built before libdw1 transitioned to libdw1t64. > Please consider: > > nmu gstreamer1.0_1.24.0-1 . armel armhf . unstabl

Bug#1067421: nmu: gstreamer1.0_1.24.0-1

Package: release.debian.org Severity: normal X-Debbugs-Cc: gstreamer...@packages.debian.org, debian-arm@lists.debian.org Control: affects -1 + src:gstreamer1.0 User: release.debian@packages.debian.org Usertags: binnmu gst-plugins-base1.0 is currently unbuildable on armel and armhf due to gstre

Re: Bug#1062847: protobuf: Use dh-sequence-elpa in Build-Depends-Indep

Control: block 1036884 by -1 Control: block -1 by 1062840 On Sat, 03 Feb 2024 at 15:14:57 -0500, Jeremy Bícha wrote: > dh-elpa is only used to build an Architecture: all package. Therefore, > it is more correct to use Build-Depends-Indep instead of specifying > specific architectures. > > We can

Bug#1067043: libruby: needs updating for libruby3.1t64

Package: libruby Version: 1:3.1 Severity: serious Justification: blocker for 64-bit time_t transition X-Debbugs-Cc: z...@debian.org, debian-arm@lists.debian.org Control: affects -1 + src:graphviz src:vala Now that libruby3.1t64 has reached unstable, libruby is uninstallable on the architectures af

Bug#1066982: curl: please consider temporarily disabling LDAP and build-time tests on 32-bit non-x86

temporary and should be reverted when the transition has finished. Thanks, smcv >From bc8cd5d7a40c8acaf2c164c538b6c0b07f2d3dab Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Sat, 16 Mar 2024 11:36:05 + Subject: [PATCH 2/3] Temporarily disable LDAP support on 32-bit non-x86 This m

Bug#1066847: openssh: please consider disabling ssh-askpass-gnome on 32-bit during the time_t transition

attach a possible patch. I've verified that it compiles successfully in an armhf porterbox chroot (without ssh-askpass-gnome) and on amd64 (with ssh-askpass-gnome), but I haven't otherwise tested it. Thanks, smcv >From bbefe785a6ab567677af77ccd12b1fbb59a42d8d Mon Sep 17 00:00:00 2

Bug#1066844: at-spi2-core: needs re-bootstrapping on armel, armhf for 64-bit time_t transition

Package: at-spi2-core Version: 2.51.90-3 Severity: important X-Debbugs-Cc: debian-arm@lists.debian.org Tags: patch at-spi2-core has a circular build-dependency on itself when tests are enabled, which makes its build-dependencies unsatisfiable (libglib2.0-dev depends on libglib2.0-0t64, but at-spi2

Re: Bug#1036884: transition: time64_t

Control: block -1 by 1065787 1066049 One dependency chain that is blocking a lot of rebuilds right now is this one: ... => curl -> stunnel4 -> python-cryptography => cargo => ... key: => mandatory dependency -> nocheck dependency In the medium term, cargo needs re-bootstrapping

Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"

Source: mesa Version: 23.3.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel Control: block 1060779 by -1 The armel baseline does not have lock

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

Source: gtk4,librsvg Severity: important Tags: upstream help X-Debbugs-Cc: debian-s...@lists.debian.org, debian-po...@lists.debian.org gtk4 had a recent test failure regression on s390x and other big-endian architectures like ppc64 (#1057782). I sent this upstream to https://gitlab.gnome.org/GNOME

Bug#1057797: glib2.0: thread-pool-slow test intermittently times out on 32-bit ARM

Source: glib2.0 Version: 2.78.2-1 Severity: important Tags: help X-Debbugs-Cc: debian-arm@lists.debian.org Similar to threadtests in #1023652, the single test-case in glib/tests/thread-pool-slow.c intermittently times out (takes more than 10 minutes) on armel and armhf. It seems to be reasonably r

Re: Bug#1023652: glib2.0: gobject/tests/threadtests.c can take more than 5 minutes on armhf, armel

Control: tags -1 + help On Tue, 08 Nov 2022 at 09:47:15 +, Simon McVittie wrote: > On Mon, 07 Nov 2022 at 21:51:05 +0100, Paul Gevers wrote: > > # Executing: glib/threadtests.test > > # Executing: glib/threadtests.test > > # Executing: glib/threadtests.test > > no

Bug#1050014: mutter: rethink the approach to forcing gles2 as default on armel, armhf

Source: mutter Version: 44.3-4 Severity: normal Tags: upstream X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel armhf mutter currently carries a non-upstreamable patch for its internal fork of cogl, to make gles2 (as opposed to gl3) its default driver on

Re: Bug#1029167: mozjs78: Fails to build on armhf and armel

On Wed, 18 Jan 2023 at 19:08:22 +, Joshua Peisach wrote: > CJS ported to mozjs78 in October 2020, and Cinnamon is still finishing their > 5.6x releases/making cleanups. > > Considering upstream uses Ubuntu Jammy, mozjs102 isn’t an option unless they > are willing to build it for their main d

Re: Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed

Control: severity -1 important On Tue, 20 Dec 2022 at 11:47:10 +, Simon McVittie wrote: > Recent uploads of mutter have had a FTBFS on armhf and sometimes armel, > with this test failure in "mutter:core+mutter/wayland / xwayland" In 43.2-4 I've downgraded failures i

Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed

Source: mutter Version: 43.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: lib...@packages.debian.org, debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel armhf Recent uploads of mutter have ha

Re: Bug#1018076: mini-transition: gjs built against mozjs102

Control: retitle -1 mini-transition: gjs built against mozjs102 Control: unblock -1 by 1018819 Control: tags -1 = pending On Thu, 25 Aug 2022 at 11:19:30 +0100, Simon McVittie wrote: > I think we need to be looking at the possibility of doing > architecture-specific removals of gjs and dep

Re: Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

Control: tags -1 + patch On Tue, 23 Aug 2022 at 21:39:50 +0100, Simon McVittie wrote: > On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote: > > The final link fails with multiple definitions of the various atomic > > builtins: > > > > > (.tex

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

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 indi

Re: Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

On Tue, 23 Aug 2022 at 16:44:54 -0400, Jeffrey Walton wrote: > On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie wrote: > > On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote: > > > The final link fails with multiple definitions of the various atomic > > > builtin

Re: Bug#1017961: mozjs102: Fails to build on armel

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619 On Tue, 23 Aug 2022 at 13:31:21 +0100, Simon McVittie wrote: > I tried the attached patch Sorry, now attached. > The next thing I'm going to try is using gcc 11 on armel as a workaround > for #1017979. Th

Re: Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623 Control: affects -1 + src:mozjs102 On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote: > The final link fails with multiple definitions of the various atomic > builtins: > > > (.text+0x0): multipl

Re: Bug#1017962: mozjs102: Fails to build on armhf

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1761665 On Tue, 23 Aug 2022 at 10:27:02 +0100, Simon McVittie wrote: > Here's the generated file. The build is still going, so I don't know > whether the FTBFS will be reproducible. Looks like yes. I think this i

Re: Bug#1017961: mozjs102: Fails to build on armel

On Tue, 23 Aug 2022 at 10:07:47 +0100, Simon McVittie wrote: > On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote: > > I did notice this repeatedly in the build log: > > > > {standard input}: Assembler messages: > > {standard input}: Error: selected process

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

Source: mozjs91 Version: 91.10.0-1 Severity: serious Tags: ftbfs help X-Debbugs-Cc: debian-arm@lists.debian.org Control: block 1017961 by -1 Versions of mozjs91 newer than 91.10.0-1 failed to build on the armel buildds. I tried building 91.10.0-1 in an armel chroot on amdahl, and that also fails,

Re: Bug#1017962: mozjs102: Fails to build on armhf

On Tue, 23 Aug 2022 at 10:10:53 +0100, Simon McVittie wrote: > On Mon, 22 Aug 2022 at 20:25:54 -0400, Jeremy Bicha wrote: > > mozjs102 fails to build on armhf > ... > > In function ‘uint64_t js::jit::AtomicCmpXchg64SeqCst(uint64_t*, > > uint64_t, uint64_t)’, > >

Re: Bug#1017962: mozjs102: Fails to build on armhf

On Mon, 22 Aug 2022 at 20:25:54 -0400, Jeremy Bicha wrote: > mozjs102 fails to build on armhf ... > In function ‘uint64_t js::jit::AtomicCmpXchg64SeqCst(uint64_t*, > uint64_t, uint64_t)’, > inlined from ‘static T > js::jit::AtomicOperations::fetchAndSeqCst(T*, T) [with T = long long > int]’ at

Re: Bug#1017961: mozjs102: Fails to build on armel

On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote: > I did notice this repeatedly in the build log: > > {standard input}: Assembler messages: > {standard input}: Error: selected processor does not support `dmb sy' > in ARM mode > {standard input}: Error: selected processor does not support

Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

On Wed, 08 Dec 2021 at 20:11:55 +, peter green wrote: > The default -march value on Debian armhf is "armv7-a+fp". You should > *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3 > with 32 double precision registers which is above the Debian baseline. https://github.com/alexcricht

Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

On Wed, 08 Dec 2021 at 09:41:29 +, Simon McVittie wrote: > At a guess, perhaps the problem is that the mozjs build system is explicitly > specifying -march=armv7-a when it should be something like > -march=armv7-a+vfpv3 or accepting the compiler's default? Looks like this mig

Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

Control: retitle -1 mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU Control: tags -1 + help On Wed, 08 Dec 2021 at 10:14:55 +0100, Fabio Fantoni wrote: > Hi, as can be see in reproducible tests > (https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/

Bug#995929: mutter: FTBFS on armel|armhf|arm64: build-time test core+mutter/unit / normal times out

Source: mutter Version: 41.0-1 Severity: serious Tags: ftbfs experimental Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-arm@lists.debian.org The new version of mutter in experimental includes a build-time unit test "core+mutter/unit / normal" w

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

Source: llvm-toolchain-13 Version: 1:13.0.0-2 Severity: important X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, debian-arm@lists.debian.org llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el. This makes mesa BD-Uninstallable on those release architectu

Re: Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else

On Tue, 13 Oct 2020 at 13:10:46 +, Paul Wise wrote: > On Tue, Oct 13, 2020 at 11:12 AM Simon McVittie wrote: > > Or is there anything odd about arm-conova-03's TCP or other networking > > setup? > > arm-conova-03 does not have an IPv4 address/route except on the &g

Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else

Source: glib2.0 Version: 2.66.1-1 Severity: important Tags: ftbfs help X-Debbugs-Cc: debian-arm@lists.debian.org One of the tests in GLib's test suite is gdbus-server-auth, which tests the GDBusServer IPC server, among other things verifying that a libdbus client can interoperate with the GDBusSer

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On Fri, 09 Aug 2019 at 14:31:47 +0200, Ivo De Decker wrote: > On 8/8/19 10:38 PM, Aurelien Jarno wrote: > > This is still a kind of cross-compiler > > As you noted, our current policy doesn't allow that. ... > The resulting (32-bit) binaries still need to run natively in the build > environment. A

Bug#908481: mozjs60: FTBFS on armel: test262/built-ins/TypedArray/prototype/fill/fill-values-conversion-operations-consistent-nan.js: Test262Error: NaN value #2 (Testing with Float32Array.)

Source: mozjs60 Version: 60.1.0-1 Severity: serious Tags: help X-Debbugs-Cc: debian-arm@lists.debian.org User: debian-arm@lists.debian.org Usertags: armel In mozjs60 (Spidermonkey 60, the standalone version of the Mozilla JavaScript interpreter corresponding to Firefox 60.x ESR), the test test262/

Re: The (uncalled for) toolchain maintainers roll call for stretch

On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote: > The arm-linux-gnueabi is not that well defined, so it may include the hard > float > variant as well. However Debian default to armv4t, while the default > configuration for upstream is armv5. However with the selected defaults > Deb

Bug#795331: iceweasel: backport/security builds (bundled libvpx) FTBFS on armhf

Package: iceweasel Version: 38.1.1esr-1 Severity: important [X-Debbugs-Cc: debian-arm to get an expert opinion on how the ABIs fit together] As described on , a rebuild of iceweasel/38.1.1esr-1 with ~deb9u1 appended to the version number, in a stretch environment,

Re: Bug#546823: __thread usage in libcap-ng0 broken on armel if optimizing

und overly aggressive optimization (?) +on __thread variable. Closes: #546823 + * Fix NAME sections of man pages so whatis can understand them (Lintian +warning). + * Install .pc file so pkg-config can be used to find libcap-ng (dh_install +warning). + + -- Simon McVittie Thu, 22 Oct

Re: Bug#546823: __thread usage in libcap-ng0 broken on armel

ARM porters: can you shed any light on this? If I compile libcap-ng0 on armel, then run "make check", the segfault described in the bug appears: > make[3]: Entering directory `/home/smcv/bugsquash/libcap-ng-0.6.1/src/test' > Doing basic bit tests... > /bin/bash: line 5: 25105 Segmentation fault