Re: Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

[Simon McVittie]

On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote:
> Package: libmozjs-115-dev
> Justification: makes gjs FTBFS (#1063433)

I believe mozjs115_115.7.0-3 should fix this.

wb-team: Please could someone with wanna-build access schedule gjs
on mips64el to be built after the fixed version of mozjs115 becomes
available? I believe the correct spelling is:

dw gjs_1.78.3-1 . unstable . mips64el . -m 'libmozjs-115-dev (>= 115.7.0-3)'

mips team, or mozjs experts: Please could someone look into upstreaming
the attached mips-specific patch?

Thanks,
smcv
From: Simon McVittie 
Date: Thu, 8 Feb 2024 10:36:53 +
Subject: Export js::detail::CanonicalizedNaNBits on architectures that use it

Otherwise the inline function JS::CanonicalizeNaN(double), which is
called by gjs, cannot validly refer to it.

Bug-Debian: https://bugs.debian.org/1063446
Signed-off-by: Simon McVittie 
---
 js/public/Value.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/public/Value.h b/js/public/Value.h
index de8db0f..d934b59 100644
--- a/js/public/Value.h
+++ b/js/public/Value.h
@@ -445,7 +445,7 @@ constexpr uint64_t CanonicalizedNaNSignificand = 0x8;
 #endif
 
 #if defined(JS_RUNTIME_CANONICAL_NAN)
-extern uint64_t CanonicalizedNaNBits;
+extern JS_PUBLIC_DATA uint64_t CanonicalizedNaNBits;
 #else
 constexpr uint64_t CanonicalizedNaNBits =
 mozilla::SpecificNaNBits

Re: Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

[Simon McVittie]

On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote:
> Simplified steps to reproduce:
> Try to compile the attached, with:
> g++ test.cpp -o test $(pkgconf --cflags --libs mozjs-115)

Oops, really attached now.

> I'm preparing a possible patch (but it will take a long time to test,
> because compiling mozjs on mips64el is extremely slow).

Untested patch attached. I'm trying to build with this change on eberlin.

smcv
// Copyright 2024 Simon McVittie
// SPDX-License-Identifier: MIT

#include 
#include 

#include 
#include 

int main(int argc, char** argv)
{
// Smoke-test
const char* reason = JS_InitWithFailureDiagnostic();
if (reason) {
std::fprintf(stderr, "Fatal error: %s\n", reason);
return 1;
}
JSContext* cx = JS_NewContext(32 * 1024 * 1024);

// https://bugs.debian.org/1063446
uint64_t u64;
double d = JS::CanonicalizeNaN(0.0/0.0);
static_assert(sizeof(u64) == sizeof(d));
memcpy(, , sizeof(d));
std::printf("Representation of a canonicalized NaN: %" PRIx64 "\n", u64);

JS_DestroyContext(cx);
JS_ShutDown();
return 0;
}
>From ac5a01642f111e88cb80aa54b1ee438b3bc6d07e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 8 Feb 2024 10:36:53 +
Subject: [PATCH] Export js::detail::CanonicalizedNaNBits on architectures that
 use it

Otherwise the inline function JS::CanonicalizeNaN(double), which is
called by gjs, cannot validly refer to it.

Bug-Debian: https://bugs.debian.org/1063446
Signed-off-by: Simon McVittie 

Gbp-Pq: Name Export-js-detail-CanonicalizedNaNBits-on-architectures-th.patch
---
 js/public/Value.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/public/Value.h b/js/public/Value.h
index de8db0fed8..d934b59dd4 100644
--- a/js/public/Value.h
+++ b/js/public/Value.h
@@ -445,7 +445,7 @@ constexpr uint64_t CanonicalizedNaNSignificand = 0x8;
 #endif
 
 #if defined(JS_RUNTIME_CANONICAL_NAN)
-extern uint64_t CanonicalizedNaNBits;
+extern JS_PUBLIC_DATA uint64_t CanonicalizedNaNBits;
 #else
 constexpr uint64_t CanonicalizedNaNBits =
 mozilla::SpecificNaNBits

Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

[Simon McVittie]

Package: libmozjs-115-dev
Version: 115.7.0-2
Severity: serious
Tags: upstream
Justification: makes gjs FTBFS (#1063433)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el
Control: block 1063433 by -1

Original steps to reproduce:
Try to compile gjs 1.78.3-1 (#1063433), which calls this public API:
double JS::CanonicalizeNaN(double)

Simplified steps to reproduce:
Try to compile the attached, with:
g++ test.cpp -o test $(pkgconf --cflags --libs mozjs-115)

Expected result:
gjs or the simplified test compiles, links and runs successfully

Actual result:
On amd64 and other architectures, linking succeeds.
On mips64el, linking fails:
/usr/bin/ld: /tmp/cc41qWiD.o: in function `main':
test.cpp:(.text+0x22c): undefined reference to 
`JS::detail::CanonicalizedNaNBits'

I think this is because mozjs has mips-specific code to detect which is
the preferred representation of NaN, with the result stored in a global
variable that is read by the inline function JS::CanonicalizeNaN(double);
but that global variable is not exported, so gjs cannot validly refer to it.

I'm preparing a possible patch (but it will take a long time to test,
because compiling mozjs on mips64el is extremely slow).

smcv

Re: Bug#1056116: llvm-toolchain-17 ftbfs on mips64el

[Simon McVittie]

Control: forwarded -1 https://github.com/llvm/llvm-project/pull/76894

On Fri, 17 Nov 2023 at 16:31:24 +0800, YunQiang Su wrote:
> On Fri, Nov 17, 2023 at 09:28:38AM +0100, Sylvestre Ledru wrote:
> > We (llvm) moved to github for contributions
> > 
> > please move [https://reviews.llvm.org/D158491] on this platform
>
> The red banner on Phabricator tells us don't do so.

This situation seems to have changed. The LLVM Phabricator now has a banner
that reads:

This is an archive of the discontinued LLVM Phabricator instance

and pull requests seem to be happening in
.

Please could the MIPS porting team follow up on this, responding to prior
review in https://reviews.llvm.org/D158491 where appropriate? This has
been holding back migration of important packages like mesa for quite
a long time.

It looks as though https://github.com/llvm/llvm-project/pull/76894 might be
the new upstream location for this change. Is that correct? If not, please
adjust bug metadata as necessary.

Thanks,
smcv

Re: Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el

[Simon McVittie]

On Sun, 14 Jan 2024 at 08:39:52 +0100, Paul Gevers wrote:
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:mesa has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. The version in unstable build depends on
> binaries from llvm-toolchain-17, which haven't been built on mips64el yet
> (reported in bug 1056116).

Adding mips64el porting team to Cc for visibility.

Mesa could probably work around this by disabling the LLVM parts on
mips64el (removing mips64 from LLVM_ARCHS in d/rules and from various
lists of LLVM-capable architectures in d/control).

The cost would be that most mips64el users would have to use slow
fallback software rendering, because disabling LLVM support would
disable llvmpipe (which it seems doesn't actually work properly
on mips* in any case) but also the AMD driver (which is what
graphical MIPS users rely on in practice, according to discussion on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71).

That's a high cost for mips64el users, but the alternative seems to be
letting mips64el hold back all of our other architectures, and I don't
think that's really viable.

Thanks,
smcv

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

[Simon McVittie]

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/gtk/-/issues/6260 and proposed a patch in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6653, but upstream is
reluctant to apply the patch because they think it is the wrong solution:

> I would rather people fix the actual issue, which is the large table
> mapping GdkMemoryFormat to the corresponding GL format (and I bet the
> one for dmabufs is broken, too, but we don't have tests for that).

librsvg also has long-standing unsolved endianness-related issues, most
likely in one of its dependencies (#1038447, which has affected bookworm
since September 2022).

The GNOME team does not have big-endian hardware where we can run manual
tests, so we do not know how much of an impact this has on practical
usability of GTK and librsvg on big-endian architectures: it's entirely
possible that they have always been misrendered or broken on big-endian,
but the bug was never reported because there were no users, and we
are only noticing this now as a result of wider test coverage being
introduced.

If porters are interested in having GTK and librsvg continue to be
available on big-endian, please work with upstream to get them to a point
where endianness-specific bugs can be taken seriously in the upstream
projects. I do not consider doing this downstream-only to be a solution.

If endianness-specific issues become a blocker for the Debian release
process at some point in the future, then it is likely that I will have
to start the process of doing architecture-specific removals for these
packages and their reverse dependencies. For s390x this is likely to
have little user-visible effect, because I find it unlikely that there
are genuinely users running GUI applications on IBM mainframes, but for
-ports architectures this will probably be a larger regression.

Thanks,
smcv

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-mips@lists.debian.org, bl...@debian.org, 
debian-wb-t...@lists.debian.org

Luca Boccassi and I have been preparing stable and oldstable updates for
debootstrap so that the transition described in DEP-17 can continue.
Because DEP-17 involves changes to trixie/sid chroots' bootstrap
procedures, the updated debootstrap needs to be deployable to every
official buildd, and we've been told that (old)stable point releases
are the preferred way to achieve that.

When Luca asked how many suites we needed this change in, we were hoping
the answer would be stable only, and maybe oldstable (which is still
in its 1 year of overlapping support from the security team and DDs
in general).

However, if I understand correctly, Luca has been told that some official
mips64el buildds are running mipsel user-space on mips64el hardware which
only works with the buster kernel, and therefore those official buildds
are still stuck on buster, meaning we also need to prepare a buster
version of debootstrap and get it into Debian 10 LTS via buster-security.

Is this true?

>From the point of view of the project having control over its own future,
I would have hoped that official Debian infrastructure would only be using
suites that are supported by Debian as a whole, rather than handing over
control and responsibility to the Debian-LTS subproject.

Also, from the point of view of continued development of testing/unstable,
I would have hoped that packages in testing/unstable could safely
assume that they will run on at least the kernel from stable (or maybe
oldstable for a short time after a new stable release), following our
usual "skipping a release is unsupported" rule. Obviously if the buildds
are running on an oldoldstable kernel, any mips64el package that might
be used at compile-time or for build-time tests will be unable to make
that assumption.

Please could someone with knowledge of the buildds clarify the situation?

If our official buildds for a release architecture are unable to run on
either the stable or oldstable kernel, I think that raises some important
questions about suitability for inclusion in future releases.

Thanks,
smcv

Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

[Simon McVittie]

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el mipsel

gtk4 4.12.0 in experimental has test failures on multiple buildds.
Of those, mips64el and mipsel seem to have the same failure mode:
failure mode:

  72/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
border-one-rounded flipped   FAIL   
  5.47s   exit status 1
 315/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl opacity-overdraw   
 FAIL   
  4.89s   exit status 1
 316/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
opacity-overdraw flipped FAIL   
  4.94s   exit status 1
 317/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-repeated-gl / 
gl opacity-overdraw repeated   FAIL 
5.05s   exit status 1
 318/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-rotated-gl / gl 
opacity-overdraw rotated FAIL   
  4.95s   exit status 1
 319/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-masked-gl / gl 
opacity-overdraw masked   FAIL  
   5.02s   exit status 1
1406/1464 gtk:reftest / reftest label-sizing.ui 
 FAIL   
 19.29s   0/1 subtests passed
1422/1464 gtk:reftest / reftest opacity.ui  
 FAIL   
  6.79s   0/1 subtests passed

These are "reftests", which work by rendering the same image in two
different ways and then doing a pixel-by-pixel comparison. Because
Debian buildds do not give us a way to capture test artifacts, the images
are output into the log with uuencode, for example these:

begin-base64 644 testsuite/gsk/compare/opacity-overdraw.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iRklEQVRIie3WMQ4AIAxCUWo8uDev
B7BjYwc+I8tLmAgpjwayJlDgr9lVmYpWJJRP5zc1MDAwMDAwsDFcfq7qI3XHb2o/+AJ0lQS/vZJx
GQBJRU5ErkJggg==


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.out.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iS0lEQVRIie3WMQ4AIAhD0aIe3Isb
vACDA5GB35HlJWWpSb5VkFGBAn/Nio5HlopM+Rv8o4Z+PwYGBgYGBgauh8PpY8FGyk6/qvvBF6Er
BMOKG8HLAElFTkSuQmCC


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.diff.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iKklEQVRIie3NoQEAIAzEwGdvZPeG
BUBR3J2MSQKfjFOsZHVO5uUDAAC82WlIAgJv9eZaAElFTkSuQmCC


The way these work is that they are output in sets of three: a reference
image, an actual output, and an artifically-enhanced diff image to
highlight what the difference is. See #1024391, #993550, #1003348 for
previous examples of architecture-specific rendering differences (#1024391
was not on mips*, but has details of how to run individual tests which
might be useful, while the other two were on mips*el).

I haven't reconstructed the actual images for a visual comparison yet.
If the mis-rendering doesn't seem release-critically bad then we'll work
around this by ignoring those particular test failures on mips*el.

mips*el are the only architectures where we are using the softpipe GL
driver (because llvmpipe appears to be otherwise broken there) so that is a
possible root cause.

Having to investigate and work around failing tests in GL-dependent
packages on mips*el is becoming a significant time sink for the GNOME team,
so I would appreciate it if mips porters could fix its llvmpipe so that it
can be back in the same situation as every other release architecture.

smcv

Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

Version: 44.3-3

gnome-shell/experimental is now building successfully on mips(64)el.
We discovered two related bugs which have not yet been fixed:

There is an apparent bug in llvmpipe, which we would normally use to run
the build-time tests: https://bugs.debian.org/1049404

There is also an apparent timing-, thread- or race-condition-related bug
in gnome-shell or one of its dependencies, seen only when using softpipe:
https://bugs.debian.org/1049407

I think neither of these needs to be RC or block the GNOME 44 transition,
since GNOME is primarily designed to be used on hardware GPUs (and
secondarily on fast x86 VMs with working llvmpipe), so we're now skipping
the affected tests on mips(64)el.

On Fri, 04 Aug 2023 at 15:20:08 +0100, Simon McVittie wrote:
> I notice that the perf-* tests are new in version 44, so if the equivalent
> functionality had been failing on mips*el before, we wouldn't know.
> 
> Can you confirm whether gnome-shell/unstable works on a mips*el desktop
> system?

>From comments on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71 the
answer is: yes it does work, as long as the mips*el desktop system has a
hardware GPU (in practice it would be from AMD).

> If that works, please try building
> https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71 with
> DEB_BUILD_OPTIONS=nocheck: does that work or crash on a mips*el desktop?

>From comments on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71 the
answer is: yes version 44 also works, again with a hardware GPU.

smcv

Bug#1049404: mesa: gnome-shell crashes when using llvmpipe on mips64el

[Simon McVittie]

Source: mesa
Version: 23.1.4-1
Severity: normal
X-Debbugs-Cc: debian-mips@lists.debian.org, wzss...@gmail.com
User: debian-mips@lists.debian.org
Usertags: mips64el mipsel

gnome-shell (>= 44) fails its build-time tests on the mips64el porterbox
'eller', using llvmpipe for 3D graphics. I don't know whether a simpler
accelerated 3D application would reproduce the same crash.

According to mips porter YunQiang Su, the same version of
gnome-shell works well on an AMD GPU, so this is an llvmpipe-specific
bug. Unfortunately, llvmpipe is the only thing we have available for
smoke-testing on buildds and other infrastructure.

To reproduce this with a current version of gnome-shell, it will be
necessary to remove this workaround from debian/rules:

ifneq ($(filter mips%,$(DEB_HOST_ARCH_CPU)),)
# gnome-shell on mips(64)el works on a real GPU (in practice usually an
# AMD GPU), but crashes when using llvmpipe or softpipe, which is all that
# is available on the buildds, so we only run the unit tests at build time
# and skip the tests that would run the whole Shell. See discussion in
# https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71
meson_test_options += --no-suite shell
endif

This might have the same root cause as some or all of #868745, #935884,
#1010838, #993550, #1003348.

YunQiang Su writes:
> on MIPS with MSA, mesa try to use it, and trigger some
> problems. It is still the bug of LLVM. So maybe we should
> revert the changes to mesa before LLVM MSA JIT is fixed.
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/88b234d7a7cd71fcb4955428010f238ec9530431

There is further discussion on
.
(Note that there is also discussion there of a different failure with the
softpipe renderer, which is out of scope for this bug report.)

I do not intend to work on this myself: I do not have any mips hardware,
any particular interest in mips, or any Mesa or LLVM expertise.

Thanks,
smcv

Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

On Fri, 04 Aug 2023 at 23:27:18 +0800, YunQiang Su wrote:
> Ohh, Mozjs102 is using WASM now, which generates some MIPS SIMD instructions.

Does this mean gnome-shell 43 is already crashing on mips*el?

The reason I ask is that I want to get 44 into unstable soon, and to do
that, it would be good to know whether this is a regression or a
pre-existing problem.

smcv

Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

On Fri, 04 Aug 2023 at 13:21:59 +0100, Simon McVittie wrote:
> On Fri, 04 Aug 2023 at 20:05:20 +0800, YunQiang Su wrote:
> > I am continue working on (EE) failed to write to Xwayland fd: Broken
> > pipe problem.

I notice that the perf-* tests are new in version 44, so if the equivalent
functionality had been failing on mips*el before, we wouldn't know.

Can you confirm whether gnome-shell/unstable works on a mips*el desktop
system?

If that works, please try building
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71 with
DEB_BUILD_OPTIONS=nocheck: does that work or crash on a mips*el desktop?

Thanks
smcv

Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

On Fri, 04 Aug 2023 at 20:05:20 +0800, YunQiang Su wrote:
> > > Instead of doing this low-level ELF manipulation, I'm testing a patch 
> > > which
> > > uses an environment variable to propagate the search path into the
> > > executable - that seems less likely to go wrong on unusual architectures.

This is https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2858
and is also available as part of
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71.
I think that's a more future-proof approach than adjusting the pointer
based on guessing what the base address is.

> FYI: this patch can fix the segfault problem in
> maybe_add_rpath_introspection_paths

I think my approach seems more likely to be reliable, but we can use
yours as a plan B.

> I am continue working on (EE) failed to write to Xwayland fd: Broken
> pipe problem.

Thanks!

smcv

Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6877

On Fri, 04 Aug 2023 at 15:50:32 +0800, YunQiang Su wrote:
> 156   if (rpath)
> 157 paths = g_strsplit (strtab + rpath->d_un.d_val, ":", -1);
> 158   else
> 159 paths = g_strsplit (strtab + runpath->d_un.d_val, ":", -1);
>  // <- segfault here due to

Thanks, that's very useful information.

After some printf debugging on eller, I think what is happening here is
that GNOME Shell is assuming that the d_un.d_val of the DT_STRTAB is
an absolute pointer, but on mips64el for whatever reason it's only an
offset, and it needs to be added to the base address of the executable
to get a real pointer.

If I understand correctly, the value in the header in the binary on-disk
is just an offset, and on most architectures the dynamic linker overwrites
the offset with (base_address + offset) during loading/relocation - but
for whatever reason, mips64el isn't doing that.

Instead of doing this low-level ELF manipulation, I'm testing a patch which
uses an environment variable to propagate the search path into the
executable - that seems less likely to go wrong on unusual architectures.

smcv

Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

[Simon McVittie]

Source: gnome-shell
Version: 44.3-1
Severity: serious
Tags: ftbfs experimental help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el mipsel

gnome-shell 44 builds successfully on all release architectures except
mips*el, but fails to build on mips*el. The three perf-* unit tests fail
with exit status 1 and no obvious error messages:



At the moment this is only in experimental, but we want to upload it to
unstable soon, as part of the libmutter-12-0 transition
.

Is gnome-shell practically useful on mips-based hardware, or does it
have hardware requirements that the mips family do not meet in practice?
If nobody really uses it on mips*el, it might be better to do
architecture-specific removals rather than attempting to debug and fix it.

Or, if the mips porting team can confirm that GNOME 43 works in practice
as a desktop environment on mips*el hardware, then it would be useful
to try GNOME 44 from experimental on the same hardware (after building
gnome-shell locally with DEB_BUILD_OPTIONS=nocheck) to check whether
this is a practical problem.

Thanks,
smcv

Re: Bug#1040827: RM: firefox [mipsel] -- RoQA; severely outdated, depends on transitional libgdk-pixbuf2.0-0

[Simon McVittie]

On Tue, 11 Jul 2023 at 09:26:04 -0400, Jeffrey Walton wrote:
> On Tue, Jul 11, 2023 at 5:09 AM Simon McVittie  wrote:
> > firefox:mipsel still exists in the archive, but is severely outdated and
> > likely to have a very large number of security vulnerabilities.
> 
> Is there an upgrade path for users on mipsel? Do they have a graphical
> web browser they can install, even if it is not Firefox or Chrome?

Please note that this is firefox (the short-term-support browser that is
considered unsuitable for stable releases and only exists in unstable),
not firefox-esr (the longer-term-support browser that exists in testing
and stable). firefox-esr already disappeared from mipsel before bookworm,
and is out of date on the mips* architecture family in bullseye-security
and buster-security, but that's out of scope for this request.

But, yes, there is an upgrade path. GNOME Web (epiphany-browser) is
a fully-featured WebKit-based browser and apparently exists on mipsel
(although probably nobody has ever tried it on that architecture, so it's
anyone's guess whether it works). More minimal browsers like netsurf-gtk
also exist, and are probably more viable on 32-bit mips hardware than
any of the major browser engines would be.

smcv

Bug#1040827: RM: firefox [mipsel] -- RoQA; severely outdated, depends on transitional libgdk-pixbuf2.0-0

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: fire...@packages.debian.org, debian-mips@lists.debian.org
Control: affects -1 + src:firefox

firefox:mipsel still exists in the archive, but is severely outdated and
likely to have a very large number of security vulnerabilities. Newer
versions of firefox do not build successfully on mipsel. I think it would
be better for this package to be missing from mipsel altogether (the same
as firefox-esr), rather than existing but being old and dangerous.

It's also one of the few packages still depending on the transitional
libgdk-pixbuf2.0-0 package, which should be removed in trixie (ideally
it should have been removed already in bookworm, but that didn't happen).

Thanks,
smcv

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Simon McVittie]

Package: libc6-dev
Version: 2.35-4
Severity: normal
X-Debbugs-Cc: debian-mips@lists.debian.org, lint...@packages.debian.org, 
jrt...@debian.org
User: debian-mips@lists.debian.org
Usertags: mips mipsel

All mips*el executables and libraries appear to have an executable stack,
resulting in very large numbers of Lintian warnings, particularly for
packages with many small ELF objects like
.

Jessica Clarke looked into this and found that this is intentionally done
by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143

Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
doesn't need to go that far into backwards compatibility? If the mips
porters agree, then glibc on mips*el should stop forcing an executable
stack, either by increasing the minimal kernel version or by patching
this out. That will provide some security hardening on mips*el.

Or, if the mips porters consider this backwards compatibility to be
more important than the security hardening of a non-executable stack,
then Lintian should stop issuing warnings about the executable stack on
mips*el to improve its signal/noise ratio.

Thanks,
smcv

Bug#1022169: llvm-toolchain-15: FTBFS on mips*el: static assertion failed: struct_kernel_stat_sz == sizeof(stat)

[Simon McVittie]

Source: llvm-toolchain-15
Version: 1:15.0.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source, making mesa unbuildable
User: debian-mips@lists.debian.org
Usertags: mipsel mips64el
X-Debbugs-Cc: debian-mips@lists.debian.org, m...@packages.debian.org
Control: affects -1 + src:mesa

Quoting from mips64el buildd logs, but mipsel has a similar failure:

> /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cpp:67:1:
>  error: static assertion failed due to requirement 'struct_kernel_stat_sz == 
> sizeof(stat)':
> COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));

Strictly speaking this is not a regression because llvm-toolchain-15 was
never built successfully on mips*el, but I think it should be treated as
RC anyway, because older llvm-toolchain-* were buildable on mips*el (and
mesa is already using llvm-toolchain-15, making it a key package).

smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Simon McVittie]

Source: webkit2gtk
Version: 2.38.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mipsel

webkit2gtk repeatedly failed to compile on the mipsel buildds:

:
> FAILED: 
> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-32.cpp.o
>  
> /usr/bin/ccache /usr/bin/c++ [long command-line removed]
> virtual memory exhausted: Cannot allocate memory

Can we perhaps disable the use of "unified" sources (fewer, larger
translation units) for architectures where address space is limited?
Or maybe tell the compiler not to attempt memory-hungry optimizations,
or something like that?

I see this unreleased commit is available in git:
https://salsa.debian.org/webkit-team/webkit/-/commit/e92e4c4654e6fd116ef30c5cc767cc25b675ed1f
which might also help.

jbicha says this is stalling several unstable -> testing transitions, so it
would be good for the release process to get this resolved soon.

smcv

Re: Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[Simon McVittie]

Control: reassign -1 src:mesa
Control: affects -1 + src:gtk4

On Fri, 03 Sep 2021 at 00:19:29 +0100, Simon McVittie wrote:
> GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
> preferred implementation and a Cairo fallback. Its regression tests draw
> various combinations of "render nodes" and check the results against
> reference PNG images.
> 
> When using the "new" OpenGL renderer, "ngl", there's a weird rendering
> glitch on mips*el on two tests involving repeating a pattern: the top
> left pixel in each 2x2 block is darker than the other three.
> For more details and comparison images:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
> 
> Is there anything unusual about the OpenGL implementation on mips*el
> that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
> (which I think is llvmpipe?), the same as any other machine without a GPU.

This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some
dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I
can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe
and LIBGL_ALWAYS_SOFTWARE=true in the environment.

I've set up the GTK build to use GALLIUM_DRIVER=softpipe and
LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to
investigate this further from GTK's point of view. Investigation by the
mips porting team would be appreciated.

smcv

Re: Bug#1003348: gtk4: Background blend mode clip interaction not working as intended on mips*el

[Simon McVittie]

Control: reassign -1 src:mesa
Control: affects -1 + src:gtk4

On Sat, 08 Jan 2022 at 18:35:20 +, Simon McVittie wrote:
> Similar to #993550, GTK 4 has a new test failure on mips*el.
> Please see https://gitlab.gnome.org/GNOME/gtk/-/issues/4618 for details.

This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some
dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I
can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe
and LIBGL_ALWAYS_SOFTWARE=true in the environment.

I've set up the GTK build to use GALLIUM_DRIVER=softpipe and
LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to
investigate this further from GTK's point of view. Investigation by the
mips porting team would be appreciated.

smcv

Bug#1010838: gtk4: FTBFS on mipsel: rendering testsuite/gsk/compare/rounded-clip-in-clip-3d.node segfaults

[Simon McVittie]

Source: gtk4
Version: 4.6.3+ds1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mipsel
Control: block 1010813 by -1

During GTK 4's test suite, it carries out the drawing operations described
in testsuite/gsk/compare/rounded-clip-in-clip-3d.node, expecting the result
to match testsuite/gsk/compare/rounded-clip-in-clip-3d.png. On the mipsel
buildds, instead this resulted in a segfault.

This appears to be a regression in 4.6.3, or a regression in some
dependency (perhaps Mesa?) that changed at around the same time we
uploaded 4.6.3. I'm setting up a chroot on the porterbox 'eller' to see
whether I can get a backtrace for this.

I don't know what implications (if any) this has for practical usability
of GTK 4 applications on mipsel.

See also #993550, #1003348 which are other mips*el-specific issues in GTK4
(although they are not crashes, and they affect mips64el, which this one
does not).

smcv

Bug#1003348: gtk4: Background blend mode clip interaction not working as intended on mips*el

[Simon McVittie]

Source: gtk4
Version: 4.6.0+ds1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-mips@lists.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/issues/4618

Similar to #993550, GTK 4 has a new test failure on mips*el.
Please see https://gitlab.gnome.org/GNOME/gtk/-/issues/4618 for details.

As with #993550, I'm going to ignore this specific test failure for now. I
don't know what implications (if any) this has for practical usability
of GTK 4 on mips*el, and I would recommend that people who are interested
in GUIs on mips*el should try the gtk-4-examples package when mips*el
builds of 4.6.x become available (initially in experimental), and find out.

smcv

Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

On Mon, 27 Dec 2021 at 14:36:01 +, Simon McVittie wrote:
> I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a
> regression in some other package - I suspect it was, since clutter-1.0
> has had no code changes since 2020, but it would be good to be more sure
> of this.

Yes, I think this is a regression in some other component, probably Mesa
or LLVM. 1.26.4+dfsg-2 passed unit tests on the buildds, but when rebuilt
on eller with current versions, it fails the same 5 tests as 1.26.4+dfsg-3
(although the failure is ignored by the d/rules from 1.26.4+dfsg-2).

smcv

Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

Control: user debian-mips@lists.debian.org
Control: usertags -1 + mips64el

On Mon, 27 Dec 2021 at 14:26:56 +, Simon McVittie wrote:
> The clutter-1.0 unit tests fail on mips64el with segmentation faults in
> actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and
> texture.
> 
> This (or at least a similar crash) is reproducible in a sid mips64el
> chroot on eller, and can be reproduced in the built tree with a command
> like:
> 
> dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb 
> ./tests/conform/texture

This might be related to https://bugs.debian.org/935884 and/or
https://bugs.debian.org/868745, which are other mips-specific crashes
involving llvmpipe.

I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a
regression in some other package - I suspect it was, since clutter-1.0
has had no code changes since 2020, but it would be good to be more sure
of this.

smcv

Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

Source: clutter-1.0
Version: 1.26.4+dfsg-3
Severity: important
Tags: ftbfs
X-Debbugs-Cc: debian-mips@lists.debian.org, m...@packages.debian.org

The clutter-1.0 unit tests fail on mips64el with segmentation faults in
actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and
texture.

This (or at least a similar crash) is reproducible in a sid mips64el
chroot on eller, and can be reproduced in the built tree with a command
like:

dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb 
./tests/conform/texture

By installing libgl1-mesa-dri-dbgsym on eller, I was able to get the
backtrace below. This might indicate that this is actually a Mesa bug,
I don't know.

Before version 1.26.4+dfsg-3, the result of clutter-1.0 unit tests was
ignored on mips*el. For now I'm going to resume ignoring the failed result:
I suspect that Mesa and Clutter have few or no users on mips*.

Clutter is essentially unmaintained upstream (see #996690) so if it needs
anything architecture-specific, that will have to come from architecture
porters, and is vanishingly unlikely to come from upstream.

smcv

Thread 10 (Thread 0xffe17f9e50 (LWP 25902) "texture:disk$0"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff4c20e44 in cnd_wait (mtx=0xb30ba8, cond=0xb30bd0) at 
../include/c11/threads_posix.h:155
#3  util_queue_thread_func (input=) at ../src/util/u_queue.c:294
#4  0x00fff4c206e0 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 9 (Thread 0xffe1ffae50 (LWP 25901) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 8 (Thread 0xffe27fbe50 (LWP 25900) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 7 (Thread 0xffe2ffce50 (LWP 25899) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 6 (Thread 0xffe37fde50 (LWP 25898) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 5 (Thread 0xffe3ffee50 (LWP 25897) "llvmpipe-3"):
#0  0x00fff6f79420 in pthread_barrier_wait () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff5374944 in util_barrier_wait (barrier=0xb220a0) at 
../src/util/u_thread.h:301
#2  thread_function (init_data=0xb20e38) at 
../src/gallium/drivers/llvmpipe/lp_rast.c:887
#3  0x00fff5374350 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#4  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 4 (Thread 0xffe8f5ae50 (LWP 25896) "llvmpipe-2"):
#0  

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

[Simon McVittie]

Source: llvm-toolchain-13
Version: 1:13.0.0-2
Severity: important
X-Debbugs-Cc: m...@packages.debian.org, debian-mips@lists.debian.org, 
debian-...@lists.debian.org

llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el.
This makes mesa BD-Uninstallable on those release architectures since
its move to llvm-toolchain-13.

On armel:
> FAILED: bin/llvm-profdata 
> : && /<>/build-llvm/./bin/clang++ -fPIC 
> -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC 
> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override 
> -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color 
> -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -marm -Wl,-z,relro
> -Wl,-rpath-link,/<>/build-llvm/tools/clang/stage2-bins/./lib  
> -Wl,-O3 -Wl,--gc-sections 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o -o 
> bin/llvm-profdata  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVM-13.so.1  
> -lpthread && :
> /usr/bin/arm-linux-gnueabi-ld: 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o: 
> undefined reference to symbol '__atomic_fetch_add_4@@LIBATOMIC_1.0'
> /usr/bin/arm-linux-gnueabi-ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: 
> error adding symbols: DSO missing from command line

On mips*el, the failure is in a different place, but might have the same
root cause (or not, clone this bug if necessary):
> FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> : && /usr/bin/g++-10 -fPIC -fPIC -Wno-unused-command-line-argument 
> -Wno-unknown-warning-option -fPIC -fno-semantic-interposition 
> -fno-shrink-wrap -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wno-missing-field-initializers -pedantic -Wno-long-long 
> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
> -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type 
> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
> -Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
> -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O2 -DNDEBUG -g1  
> -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option 
> -Wl,--build-id -Wl,-z,defs -Wl,-z,nodelete   -mips32r2 -mabi=32 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,defs,-z,now,-z,relro 
> -ffunction-sections -fdata-sections -Wl,--gc-sections -pthread 
> -Wl,-rpath-link,/<>/build-llvm/./lib -shared 
> -Wl,-soname,libclang_rt.scudo_standalone-mipsel.so -o 
> lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/checksum.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/common.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/crc32_hw.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags_parser.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/fuchsia.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/linux.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/release.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/report.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/string_utils.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_cpp.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" && :
> /usr/bin/ld: 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
>  in function `scudo::atomic_u64::Type 
> scudo::atomic_load(scudo::atomic_u64 const volatile*, 
> scudo::memory_order)':
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'
> /usr/bin/ld: 
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'

smcv

Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[Simon McVittie]

Source: gtk4
Version: 4.4.0+ds1-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-mips@lists.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/issues/4228

GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
preferred implementation and a Cairo fallback. Its regression tests draw
various combinations of "render nodes" and check the results against
reference PNG images.

When using the "new" OpenGL renderer, "ngl", there's a weird rendering
glitch on mips*el on two tests involving repeating a pattern: the top
left pixel in each 2x2 block is darker than the other three.
For more details and comparison images:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4228

Is there anything unusual about the OpenGL implementation on mips*el
that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
(which I think is llvmpipe?), the same as any other machine without a GPU.

The "old" OpenGL renderer, "gl", does not seem to suffer from this - but
it is no longer the default, has been deleted in newer upstream versions,
and crashes in two (unrelated) tests on mipsel, so I'm going to disable
testing for "gl" in the next upload to avoid wasting machine resources and
developer time on it.

I'm going to skip these two tests on mips*el. I don't know what practical
effect this will have on GTK applications; I would recommend that people
who are interested in GUIs on mips*el should try the gtk-4-examples package
when mips*el builds become available, and find out.

smcv

Bug#972269: dwz: dbus-python FTFBS on mipsel: dwz: debian/python3-dbus-tests/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug: .debug_line reference above end of section

[Simon McVittie]

Package: dwz
Version: 0.13-5
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: binut...@packages.debian.org, debian-mips@lists.debian.org
Control: affects -1 + src:dbus-python

During the binNMUs to add Python 3.9 support, dbus-python_1.2.16-3+b1
failed to build on mipsel with binutils_2.35.1-2:

   dh_dwz -a -O--buildsystem=autoconf
dwz: 
debian/python3-dbus-tests/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug:
 .debug_line reference above end of section
dh_dwz: error: dwz 
-mdebian/python3-dbus-tests/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug
 -M/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug -- 
debian/python3-dbus-tests/usr/lib/python3/dist-packages/dbus_py_test.cpython-38-mipsel-linux-gnu.so
 
debian/python3-dbus-tests/usr/lib/python3/dist-packages/dbus_py_test.cpython-39-mipsel-linux-gnu.so
 
debian/python3-dbus-tests/usr/libexec/installed-tests/dbus-python/python3.8/test/test-import-repeatedly
 
debian/python3-dbus-tests/usr/libexec/installed-tests/dbus-python/python3.9/test/test-import-repeatedly
 returned exit code 1
make: *** [debian/rules:19: binary-arch] Error 25

Full log:
https://buildd.debian.org/status/fetch.php?pkg=dbus-python=mipsel=1.2.16-3%2Bb1=1602770087=0

I don't know whether this is a binutils regression, a dwz regression or
something else. I'll try to work around it by disabling dh_dwz on mipsel
so that dbus-python isn't holding up transitions.

smcv

Re: Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))

[Simon McVittie]

Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed: 
t1.y0.approx_eq(t2.y0, (epsilon, 1))
Control: severity -1 wishlist
Control: tags -1 + confirmed wontfix
Control: notforwarded -1

On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote:
> On 2020-05-06 11:19, Simon McVittie wrote:
> > There seems to be a strong correlation where this test passes on a Rhino
> > Labs UTM8 but fails on a Loongson 3A. Are there known issues with
> > Loongson 3A hardware, or is there different FPU behaviour, or something?
> 
> Thanks for the analysis. Yep the Loongson 3A is known for having an FPU
> bug that could explain that behaviour. Basically it treats the madd,
> msub, nmadd and nmsub instructions as fused while they should not.

It seems strange to me that a release architecture is using
known-to-be-faulty hardware for buildds. Is there any possibility of
replacing those machines, or taking them out of the buildd rotation
entirely?

In particular, we treated this as a RC bug, and prioritized reporting
it upstream; but we should not be wasting upstreams' time with issues
that are a result of faulty hardware. I don't think we can expect every
package maintainer, or every upstream maintainer, to know that Debian's
mips*el buildds have this bug and that failing build-time tests that
touch floating-point are likely to be not a real bug in the software.

At the same time, I don't want to disable build-time tests or ignore
their results, because for most architectures they are the only evidence
we have that a package works at all.

> I am going to blacklist librsvg from the Loongson 3A based buildds so
> that it doesn't happen again.

Thanks. I'll add a check to d/rules to make the build fail sooner if a
Loongson-3A CPU is detected (when not building with nocheck), to make
sure this blacklisting mechanism doesn't regress.

smcv

Re: Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/librsvg/-/issues/580
Control: found -1 2.48.2-1

On Wed, 06 May 2020 at 08:54:04 +0100, Simon McVittie wrote:
> > failures:
> >
> >  transform::tests::parses_transform_list stdout 
> > thread 'transform::tests::parses_transform_list' panicked at 'assertion 
> > failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))', 
> > rsvg_internals/src/transform.rs:398:9
> >
> >  transform::tests::parses_valid_transform stdout 
> > thread 'transform::tests::parses_valid_transform' panicked at 'assertion 
> > failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))', 
> > rsvg_internals/src/transform.rs:398:9
> >
> >
> > failures:
> > transform::tests::parses_transform_list
> > transform::tests::parses_valid_transform
> >
> > test result: FAILED. 172 passed; 2 failed; 0 ignored; 0 measured; 0 
> > filtered out

This seems to be either intermittent or machine-dependent: when retried
on a different machine, the tests often pass.

There seems to be a strong correlation where this test passes on a Rhino
Labs UTM8 but fails on a Loongson 3A. Are there known issues with
Loongson 3A hardware, or is there different FPU behaviour, or something?

Good:
2.48.0-1, mips64el, mipsel-aql-03 (Rhino Labs UTM8)
2.48.0-2, mipsel, mipsel-osuosl-02 (Rhino Labs UTM8)
2.48.2-1, mips64el, mipsel-aql-03 (Rhino Labs UTM8)
2.48.2-1, mipsel, mipsel-sil-01 (Rhino Labs UTM8)
2.48.3-1, mips64el, mipsel-osuosl-01 (Rhino Labs UTM8)
2.48.3-1, mipsel, mipsel-manda-03 (Rhino Labs UTM8)

Bad:
2.48.0-2, mips64el, mipsel-manda-01 (Lemote 3A ITX-A1101 (Quad Core Loongson 
3A))
2.48.2-1, mipsel, mipsel-aql-01 (LS3A-RS780-1w (Quad Core Loongson 3A))
2.48.3-1, mipsel, eberlin (LS3A-RS780-1w (Quad Core Loongson 3A))
2.48.4-1, mipsel, mipsel-aql-02 (LS3A-RS780-1w (Quad Core Loongson 3A))
2.48.4-1, mips64el, eberlin (LS3A-RS780-1w (Quad Core Loongson 3A))

Regards,
smcv

Bug#954196: gegl: FTBFS on mipsel: tests/compositions/reference/rgbe-save.hdr and .../output/rgbe-save.hdr differ

[Simon McVittie]

Source: gegl
Version: 0.4.22-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Control: block 951821 by -1

https://buildd.debian.org/status/fetch.php?pkg=gegl=mipsel=0.4.22-2=1584490046=0
> [swscaler @ 0x5617e750] No accelerated colorspace conversion found from 
> yuv420p to rgb24.
> missing reference, assuming SUCCESS
> PASS color-reduction.xml
> missing reference, assuming SUCCESS
> PASS jpg-load-datauri.xml
> missing reference, assuming SUCCESS
> PASS pnm-ascii-load.xml
> missing reference, assuming SUCCESS
> PASS pnm-raw-load.xml
> missing reference, assuming SUCCESS
> PASS rgbe-load.xml
> 
> (gegl-imgcmp:1189): GEGL-WARNING **: 00:03:06.812: max diff is not a valid 
> property of gegl:image-compare 0x55776830
> /<>/tests/compositions/reference/rgbe-save.hdr and 
> /<>/obj-mipsel-linux-gnu/tests/compositions/output/rgbe-save.hdr 
> differ
>   wrong pixels   : 165/12288 (1.34%)
>   max ?e : 
> 67326627421669684888669005176245981626127818201330704240878079155477023449696839256119546828890322554026762884581407459611684012658109431614078423083822172532225793664776343589445197580928856114285850164049130170201566309394530763936055595205809030148151018621390290944.000
>   avg ?e (wrong) : 
> 67326627421669684888669005176245981626127818201330704240878079155477023449696839256119546828890322554026762884581407459611684012658109431614078423083822172532225793664776343589445197580928856114285850164049130170201566309394530763936055595205809030148151018621390290944.000(wrong)
>  
> 57895085948248197003310861778540597530344540911046658743056637836873978536706733178284242874418852779814501765638059266549873720618904958362702683089689120708187862881929758991439906547451878104338721332513031507467342755888365810233077968491152966828328813401751945216.000(total)
> FAIL rgbe-save.xml
> missing reference, assuming SUCCESS
> PASS shift.xml
> missing reference, assuming SUCCESS
> PASS stretch-contrast-hsv.xml
> missing reference, assuming SUCCESS
> PASS tiff-load.xml
> missing reference, assuming SUCCESS
> PASS tile.xml
> === Test Results ===
>  tests passed:  9
>  tests skipped: 0
>  tests failed:  1
> ==  FAIL  ==

We can't get the binary output from a failing build on a buildd, so it's
impossible to say whether this is serious or not unless it can be
reproduced on a porterbox or similar (which I'm trying to do now).

smcv

Bug#935884: libgl1-mesa-dri: regression on mips64el llvmpipe: segfault in clutter-1.0 test actor-offscreen-limit-max-size

[Simon McVittie]

Package: libgl1-mesa-dri
Version: 19.1.4-1
Severity: important
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el

Steps to reproduce:

* have unstable
* try to build the clutter-1.0 package from source, for example
  
https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0=mips64el=1.26.2%2Bdfsg-11=1566879693=0
* if the build fails with the test failure that I am reporting, you can
  retry without rebuilding everything using a command like:
  ./libtool --mode=execute xvfb-run -a 
tests/conform/actor-offscreen-limit-max-size --verbose
  (possibly adding environment variables, gdb --args, etc.)

Alternative steps to reproduce:

* have unstable
* install precompiled clutter-1.0-tests, xauth, xvfb
  (this demonstrates that the bug is not a regression in clutter-1.0)
* xvfb-run -a 
/usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
 --verbose

Expected result, as seen in a buster chroot:

> % xvfb-run -a 
> /usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
>  --verbose
> GTest: random seed: R02Sbfd7336fb33bfafdd68baabe91d5b162
> GTest: run: /actor/offscreen/limit-max-size
> Checking effect1 size: 207.00 x 207.00
> Checking effect2 size: 300.00 x 300.00
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
...
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
> GTest: result: OK

This test was also successful on all other release architectures (in
particular mipsel), except for armel and s390x where the tests are
skipped because they have been known to block indefinitely in the past.

Actual result, as seen in a sid chroot:

> % xvfb-run -a 
> /usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
>  --verbose
> GTest: random seed: R02S765417d5fb8d7844862eea7de5c996db
> GTest: run: /actor/offscreen/limit-max-size
> Checking effect1 size: 207.00 x 207.00
> Checking effect2 size: 300.00 x 300.00
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
...
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
> Segmentation fault (core dumped)

Unfortunately the backtrace is not very enlightening, at least to me:

> Thread 3 "llvmpipe-1" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xffefe34f00 (LWP 14160)]
> (gdb) thread apply all bt
> 
> Thread 5 (Thread 0xffeee32f00 (LWP 14162)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 4 (Thread 0xffef633f00 (LWP 14161)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 3 (Thread 0xffefe34f00 (LWP 14160)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 2 (Thread 0xfff0635f00 (LWP 14159)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 1 (Thread 0xfff643b010 (LWP 11652)):
> #0  0x00fff6fd97e0 in futex_wait_cancelable (private=0, expected=0, 
> futex_word=0xb84578) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  0x00fff6fd97e0 in __pthread_cond_wait_common (abstime=0x0, 
> mutex=0xb84528, cond=0xb84550) at pthread_cond_wait.c:502
> #2  0x00fff6fd97e0 in __pthread_cond_wait (cond=0xb84550, 
> mutex=0xb84528) at pthread_cond_wait.c:655   
> #3  0x00fff538bb2c in cnd_wait (mtx=0xb84528, cond=0xb84550) at 
> ../include/c11/threads_posix.h:155
> #4  0x00fff538bb2c in pipe_semaphore_wait (sema=0xb84528) at 
> ../src/gallium/auxiliary/os/os_thread.h:108
> warning: GDB can't find the start of the function at 0xfff7e7e0f7.
> #5  0x00fff538bb2c in lp_rast_finish (rast=0xb84410) at 
> ../src/gallium/drivers/llvmpipe/lp_rast.c:770
> #6  0x00fff539a160 in lp_setup_rasterize_scene (setup=0xc31090) at 
> ../src/gallium/drivers/llvmpipe/lp_setup.c:181
> #7  0x00fff539a160 in set_scene_state (setup=0xc31090, 
> new_state=, reason=) at 
> ../src/gallium/drivers/llvmpipe/lp_setup.c:331
> #8  0x00fff539af20 in lp_setup_flush (setup=0xc31090, fence=0x0, 
> reason=) at ../src/gallium/drivers/llvmpipe/lp_setup.c:360
> #9  0x00fff5389698 in llvmpipe_flush (pipe=0xb1fce0, fence=0x0, 
> reason=0xfff5d1e490 <__func__.18359> "do_flush") at 
> ../src/gallium/drivers/llvmpipe/lp_flush.c:56
> #10 0x00fff5388858 in do_flush (pipe=, fence= out>, flags=) at 
> ../src/gallium/drivers/llvmpipe/lp_context.c:117
> #11 0x00fff58d720c in st_glFlush (ctx=) at 
> 

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

[Simon McVittie]

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.

Am I right in thinking that the reason for both these requirements is that
when packages have build-time tests, you want them to be run; and you want
them to be run on real hardware, so that they will not incorrectly pass
(when they would have failed on real hardware) due to flaws in emulation?

> As we
> already stated in the past, we would really prefer if more release
> architectures had some type of automated testing (piuparts,
> autopkgtests, archive rebuilds, etc). Eventually, this will probably
> become a requirement for release architectures.

This seems like a good direction to be going in: not all packages can
be tested realistically at build-time, and expanding that to include
as-installed tests (autopkgtest) can only help to improve coverage.
In particular, relatively simple autopkgtests can often identify bugs of
the form "this package has always been compiled on (for example) mips,
but has never actually worked there, because it crashes on startup".

smcv

Re: Bug#932678: glib2.0: tests timeout on i386 and mips

[Simon McVittie]

On Sun, 28 Jul 2019 at 00:04:01 +0200, Aurelien Jarno wrote:
> The UTM8 based buildds like mips-sil-01 are much faster than the
> mips-aql-0{1,2,4,5} buildds, and also have an FPU, although I am not
> sure it plays a role here.

The test that timed out uses g_random_double_range() in a fairly tight
loop, and that function casts random integers to doubles, so if mips-aql-*
is emulating floating point in software I'm not necessarily surprised
it's so slow.

> After giving back this package, it built successfully on mips-manda-01.
> I have therefore blacklisted glib2.0 from the slowest buildds.

In 2.60.6 I've also disabled that test on mips.

smcv

Re: Bug#932678: glib2.0: tests timeout on i386 and mips

[Simon McVittie]

On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote:
> On i386, the gmenumodel test timed out.

I can't reproduce this locally, and it normally takes about 6-7 seconds
on an i386 VM on my laptop. It has had issues with arbitrary delays in
the past, and got moved to the "slow" test suite because it was sometimes
taking more than 60s in upstream's CI, so I'm quite prepared to believe
that there is some intermittent problem.

The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which
has a watchdog timer that is meant to kill the process with SIGALRM
after 65 seconds, so I'm surprised it survived to 360s - either the
watchdog timer isn't working, or multiple test-cases must have taken a
lot longer than they are meant to.

If I can't reproduce this well enough to debug it, the best I'll be able
to do is to disable this particular test at build-time.

> On mips, the gvariant test timed out.

This is failing a fuzz-test that randomly modifies binary data and
tries to parse it. I thought it might be reaching some pathological
case where the parser breaks, but no - it looks like the actual problem
is that g_random_double_range() is really slow on at least some mips
hardware (repeatedly calling g_random_double_range() in a loop is 100
times as fast on my laptop as on the porterbox minkus, which according
to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01,
the buildd where this test timed out).

mips porters: Is this something that is expected to be so slow? The
same test took 60 seconds (so at least 6 times as fast) on mips-sil-01,
which is apparently a Rhino Labs UTM8 with a somewhat newer CPU.
For comparison, it took 8 seconds on the i386 buildd.

There probably isn't much point in trying very hard to run this test on
mips, so I'll disable this one as a build-time test too.

smcv

Re: Bug#932287: glib2.0: FTBFS on mips64el: linking 32-bit code with 64-bit code

[Simon McVittie]

On Wed, 17 Jul 2019 at 12:18:14 +0100, Simon McVittie wrote:
> It looks like the culprit might be commit 
> d04b9c371d277fa45ba20ad83642e57af50381e7:
> https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
> Is that objcopy invocation wrong for mips64el? Does mips64el objcopy perhaps
> default to a different ABI?

Looks like plain objcopy produces MIPS-I objects, whereas invoking it
in the normal way via the compiler frontend produces MIPS64r2 objects:

(sid_mips64el-dchroot)smcv@eller ~/glib % file 
debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o
debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o: ELF 64-bit LSB 
relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), with debug_info, not stripped
(sid_mips64el-dchroot)smcv@eller ~/glib % file 
debian/build/deb/gio/tests/test_resources2.o
debian/build/deb/gio/tests/test_resources2.o: ELF 64-bit LSB relocatable, MIPS, 
MIPS-I version 1 (SYSV), not stripped

Regards,
smcv

Bug#932287: glib2.0: FTBFS on mips64el: linking 32-bit code with 64-bit code

[Simon McVittie]

Source: glib2.0
Version: 2.59.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org

Something involving GResource appears to have regressed between 2.58.x in
buster/bullseye and the more current GLib in experimental:

> [661/1146] objcopy --add-symbol _g_binary_test1_resource_data=.data:0 
> gio/tests/test_resources.o gio/tests/test_resources2.o
...
> [924/1146] cc  -o gio/tests/resources gio/tests/test_resources2.o 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources.c.o' 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources2.c.o' 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources_binary.c.o'
>  'gio/tests/bcb7ac7@@resources@exe/resources.c.o' -Wl,--no-undefined 
> -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now -Wl,-z,defs -Wl,--no-as-needed -Wl,-O1 -Wl,--start-group 
> glib/libglib-2.0.so.0.5900.0 gmodule/libgmodule-2.0.so.0.5900.0 
> gobject/libgobject-2.0.so.0.5900.0 gio/libgio-2.0.so.0.5900.0 -Wl,--end-group 
> -pthread 
> '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..'
>  
> -Wl,-rpath-link,/<>/debian/build/deb/glib:/<>/debian/build/deb/gmodule:/<>/debian/build/deb/gobject:/<>/debian/build/deb/gio
> FAILED: gio/tests/resources
> cc  -o gio/tests/resources gio/tests/test_resources2.o 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources.c.o' 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources2.c.o' 
> 'gio/tests/bcb7ac7@@resources@exe/meson-generated_.._test_resources_binary.c.o'
>  'gio/tests/bcb7ac7@@resources@exe/resources.c.o' -Wl,--no-undefined 
> -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now -Wl,-z,defs -Wl,--no-as-needed -Wl,-O1 -Wl,--start-group 
> glib/libglib-2.0.so.0.5900.0 gmodule/libgmodule-2.0.so.0.5900.0 
> gobject/libgobject-2.0.so.0.5900.0 gio/libgio-2.0.so.0.5900.0 -Wl,--end-group 
> -pthread 
> '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..'
>  
> -Wl,-rpath-link,/<>/debian/build/deb/glib:/<>/debian/build/deb/gmodule:/<>/debian/build/deb/gobject:/<>/debian/build/deb/gio
> /usr/bin/ld: gio/tests/test_resources2.o: warning: linking abicalls files 
> with non-abicalls files
> /usr/bin/ld: gio/tests/test_resources2.o: linking 32-bit code with 64-bit code
> /usr/bin/ld: failed to merge target specific data of file 
> gio/tests/test_resources2.o
> collect2: error: ld returned 1 exit status

Essentially the same thing is still reproducible in 2.60.4-1 and 2.61.1-2.
Presumably some change between 2.58.x and 2.59.0 can be blamed for this.

Maybe GLib's build system is invoking the wrong flavour of objcopy for
mips64el?

It looks like the culprit might be commit 
d04b9c371d277fa45ba20ad83642e57af50381e7:
https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
Is that objcopy invocation wrong for mips64el? Does mips64el objcopy perhaps
default to a different ABI?

smcv

Bug#909242: Xvfb: segfaults on mips during gtk+3.0 build-time tests

[Simon McVittie]

Package: xvfb
Version: 2:1.20.1-2
Severity: important
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips

My recent gtk+3.0 upload to experimental failed many of its build-time
tests on mips. The tests could not connect to the Xvfb server run by the
upstream build system, which later crashed with a segmentation fault.

https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0=mips=3.24.1-1=1537406479=log

I can reproduce this reliably on the mips porterbox, minkus, by running
Xvfb in a schroot with the options shown below.

Core was generated by `Xvfb -ac -noreset -screen 0 1024x768x16 :1 -nolisten tcp 
-auth /dev/null'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
(gdb) bt
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#1  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#2  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#3  0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#4  0x55eaaff0 in xorg_backtrace () at ../../../../os/backtrace.c:72
#5  0x55eb0444 in OsSigHandler (signo=11, sip=0x7fd51fc8, unused=) at ../../../../os/osinit.c:135
#6  
#7  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#8  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#9  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#10 0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#11 0x77a7a8f8 in unw_backtrace () from /usr/lib/mips-linux-gnu/libunwind.so.8
#12 0x55eb06b0 in OsInit () at ../../../../os/osinit.c:217
#13 0x55e4d708 in dix_main (argc=11, argv=0x7fd639e4, envp=) at 
../../../../dix/main.c:154
#14 0x7759ccf8 in __libc_start_main () from /lib/mips-linux-gnu/libc.so.6
#15 0x55d28e34 in __start ()
Backtrace stopped: frame did not save the PC

Line 217 is this backtrace() call:

#ifdef HAVE_BACKTRACE
/*
 * initialize the backtracer, since the ctor calls dlopen(), which
 * calls malloc(), which isn't signal-safe.
 */
do {
void *array;

backtrace(, 1); <--- here
} while (0);
#endif

so this might really be a libunwind bug (please reassign if you think so).
libunwind8:mips 1.2.1-8 was installed.

I thought this might be hardware-specific, but according to machines.cgi,
mips-sil-01 (where gtk+3.0 failed) and mips-manda-01 (where a libepoxy
build with the same xvfb and libunwind8 versions, also using Xvfb for
tests, succeeded) are matching hardware, a Rhino Labs UTM8.  minkus,
the porterbox where I reproduced this, is apparently an EdgeRouter Pro.

Xvfb is used in many packages' build-time tests, which for most
maintainers are the only evidence we have that our packages are at all
functional on mips, so it might be a good idea to work around this in
Xvfb by disabling backtrace support and/or libunwind on mips.

smcv

Bug#908487: mozjs60: FTBFS on mips: error: static assertion failed: atomics supported up to pointer size only

[Simon McVittie]

Source: mozjs60
Version: 60.1.0-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips

mozjs60 fails to build on mips:

/<>/js/src/jit/mips-shared/AtomicOperations-mips-shared.h: In 
instantiation of 'static T js::jit::AtomicOperations::loadSafeWhenRacy(T*) 
[with T = long long int]':
/<>/js/src/jit/AtomicOperations.h:227:32:   required from 'static 
T js::jit::AtomicOperations::loadSafeWhenRacy(SharedMem) [with T = long 
long int]'
/<>/js/src/builtin/AtomicsObject.cpp:591:48:   required from 
'js::FutexThread::WaitResult AtomicsWait(JSContext*, js::SharedArrayRawBuffer*, 
uint32_t, T, const 
mozilla::Maybe 
>&) [with T = long long int; uint32_t = unsigned int]'
/<>/js/src/builtin/AtomicsObject.cpp:630:60:   required from here
/<>/js/src/jit/mips-shared/AtomicOperations-mips-shared.h:383:29: 
error: static assertion failed: atomics supported up to pointer size only
 static_assert(sizeof(T) <= sizeof(void*), "atomics supported up to pointer 
size only");
   ~~^~~~

We can't upgrade gjs to a version that uses mozjs60 until either this is
fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
removed from mips.

smcv

Bug#908485: mozjs60: FTBFS on mipsel: error: static assertion failed: MIPS32 jit only supports FR=0 fpu mode

[Simon McVittie]

Source: mozjs60
Version: 60.1.0-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mipsel

mozjs60 fails to build on mipsel:

/<>/js/src/jit/mips32/Architecture-mips32.h:55:26: error: static 
assertion failed: MIPS32 jit only supports FR=0 fpu mode.
 static_assert(__mips_fpr == 32, "MIPS32 jit only supports FR=0 fpu mode.");
  ^

We can't upgrade gjs to a version that uses mozjs60 until either this is
fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
removed from mipsel.

smcv

Bug#908486: mozjs60: FTBFS on mips64el: error: no matching function for call to [...]: candidate expects 1 argument, 0 provided

[Simon McVittie]

Source: mozjs60
Version: 60.1.0-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el

mozjs60 fails to build on mips64el. It looks as though some
mips64-specific code might need updating for API changes or similar?

We can't upgrade gjs to a version that uses mozjs60 until either this is
fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
removed from mips64el.

/<>/js/src/jit/mips64/LIR-mips64.h: In constructor 
'js::jit::LUnbox::LUnbox(const js::jit::LAllocation&)':
/<>/js/src/jit/mips64/LIR-mips64.h:18:47: error: no matching 
function for call to 'js::jit::LInstructionHelper<1, 1, 
0>::LInstructionHelper()'
 explicit LUnbox(const LAllocation& input) {
   ^
In file included from /<>/js/src/jit/JitFrames-inl.h:12,
 from /<>/js/src/vm/Interpreter.cpp:52:
/<>/js/src/jit/LIR.h:1176:14: note: candidate: 
'js::jit::LInstructionHelper::LInstructionHelper(js::jit::LNode::Opcode) [with long unsigned int Defs 
= 1; long unsigned int Operands = 1; long unsigned int Temps = 0]'
 explicit LInstructionHelper(LNode::Opcode opcode)
  ^~
/<>/js/src/jit/LIR.h:1176:14: note:   candidate expects 1 
argument, 0 provided
/<>/js/src/jit/LIR.h:1171:7: note: candidate: 
'js::jit::LInstructionHelper<1, 1, 
0>::LInstructionHelper(js::jit::LInstructionHelper<1, 1, 0>&&)'
 class LInstructionHelper : public 
details::LInstructionFixedDefsTempsHelper
   ^~
/<>/js/src/jit/LIR.h:1171:7: note:   candidate expects 1 argument, 
0 provided
In file included from /<>/js/src/jit/LIR.h:2028,
 from /<>/js/src/jit/JitFrames-inl.h:12,
 from /<>/js/src/vm/Interpreter.cpp:52:
/<>/js/src/jit/mips64/LIR-mips64.h: In constructor 
'js::jit::LDivOrModI64::LDivOrModI64(const js::jit::LAllocation&, const 
js::jit::LAllocation&, const js::jit::LDefinition&)':
/<>/js/src/jit/mips64/LIR-mips64.h:54:91: error: no matching 
function for call to 'js::jit::LBinaryMath<1>::LBinaryMath()'
 LDivOrModI64(const LAllocation& lhs, const LAllocation& rhs, const 
LDefinition& temp) {

   ^
In file included from /<>/js/src/jit/LIR.h:2012,
 from /<>/js/src/jit/JitFrames-inl.h:12,
 from /<>/js/src/vm/Interpreter.cpp:52:
/<>/js/src/jit/shared/LIR-shared.h:46:14: note: candidate: 
'js::jit::LBinaryMath::LBinaryMath(js::jit::LNode::Opcode) 
[with long unsigned int Temps = 1; long unsigned int ExtraUses = 0]'
 explicit LBinaryMath(LNode::Opcode opcode)
  ^~~
/<>/js/src/jit/shared/LIR-shared.h:46:14: note:   candidate 
expects 1 argument, 0 provided
/<>/js/src/jit/shared/LIR-shared.h:43:7: note: candidate: 
'js::jit::LBinaryMath<1>::LBinaryMath(js::jit::LBinaryMath<1>&&)'
 class LBinaryMath : public LInstructionHelper<1, 2 + ExtraUses, Temps>
   ^~~
/<>/js/src/jit/shared/LIR-shared.h:43:7: note:   candidate expects 
1 argument, 0 provided
[... and more errors like those ...]

Regards,
smcv

Re: Bug#878284: mozjs52: FTBFS on mips: thousands of TEST-UNEXPECTED-FAIL

[Simon McVittie]

On Mon, 16 Oct 2017 at 07:57:45 +0100, Simon McVittie wrote:
> My changes in pkg-gnome git are not believed to be sufficient: in
> addition to turning off the JIT, Adrian says we need to fix atomic
> operations to not use jit/none/AtomicOperations-none.h. (It isn't
> at all clear to me why disabling the JIT has any effect on the atomic
> operations used, but that's how it's written...)

This looks like a promising approach:
https://anonscm.debian.org/cgit/users/smcv/mozjs52.git/log/?h=wip/mips
and will also get us a clean #error on unsupported architectures,
instead of a (non-functional?) binary with atomic operations that
MOZ_CRASH(), which seems like a good thing.

smcv

Re: Bug#878284: mozjs52: FTBFS on mips: thousands of TEST-UNEXPECTED-FAIL

[Simon McVittie]

Control: severity 878284 serious

On Thu, 12 Oct 2017 at 23:22:27 +0100, Simon McVittie wrote:
> The test failures clearly indicate at least one bug, but it isn't clear
> what the severity of that bug is: it could be anything from minor (if
> trivial functionality is broken) to RC (if mozjs52 is basically unusable
> on this architecture).

Summarizing for those not following #debian-gnome:

It appears that the mips test failures are actually quite bad (as
indicated by there being thousands of them rather than just a few),
and might be causing #878519. Adrian Bunk has been looking into a
solution.

My changes in pkg-gnome git are not believed to be sufficient: in
addition to turning off the JIT, Adrian says we need to fix atomic
operations to not use jit/none/AtomicOperations-none.h. (It isn't
at all clear to me why disabling the JIT has any effect on the atomic
operations used, but that's how it's written...)

smcv

Bug#878519: gjs: doesn't seem to work on mips (at least on minkus and mips-aql-01)

[Simon McVittie]

Package: gjs
Version: 1.50.1-2
Severity: serious
Affects: gnome-documents
X-Debbugs-Cc: debian-mips@lists.debian.org

mozjs52 now works at least partially on mips (although there are thousands
of test failures, #878284) but gjs doesn't even start:

(sid_mips-dchroot)smcv@minkus ~ % js52
js> print("hello, world")
hello, world
js>
(sid_mips-dchroot)smcv@minkus ~ % gjs

(gjs:13738): Gjs-WARNING **: gjs_eval_in_scope called with a pending 
exception

(gjs:13738): Gjs-WARNING **: JS ERROR: TypeError: can't assign to 
properties of (new Number(1.629847465960073e+237)): not an object

JS_EvaluateScript() failed

This causes gnome-documents to FTBFS (#878431, which I can also reproduce
for 3.22.5-2 in unstable):
https://buildd.debian.org/status/fetch.php?pkg=gnome-documents=mips=3.26.1-1=1507913495=0

I thought gjs had build-time tests, but this doesn't exactly look
thorough, so perhaps they aren't run or something:

   dh_auto_test -a
make -j2 test VERBOSE=1
make[1]: Entering directory '/<>'
XMLLINT not set and xmllint not found in path; skipping xml preprocessing.
XMLLINT not set and xmllint not found in path; skipping xml preprocessing.
XMLLINT not set and xmllint not found in path; skipping xml preprocessing.
make[1]: Nothing to be done for 'test'.

We should at least do a smoke-test (run the interpreter with a "hello
world" program, like I added to mozjs52) to demonstrate that it has some
basic level of functionality.

As for the actual bug, sorry, I have no idea. If there isn't a
likely-looking patch in Firefox or something, we might have to go the
architecture-specific removal route, which would mean no gjs and no
task-gnome-desktop on mips. I don't imagine there are very many GNOME
users on mips...

Are the 32-bit mips ports planned to still be release architectures in
buster? How much effort is it worth putting into them?

Regards,
smcv

Re: Bug#878284: mozjs52: FTBFS on mips: thousands of TEST-UNEXPECTED-FAIL

[Simon McVittie]

On Thu, 12 Oct 2017 at 08:08:42 +0100, Simon McVittie wrote:
> On Thu, 12 Oct 2017 at 01:31:08 +0100, Simon McVittie wrote:
> > I've left mozjs52
> > compiling on mips (minkus) overnight to see whether both big-endian
> > 32-bit architectures behave the same.
> 
> Unfortunately mips has new and exciting failures, and lots of them:
> 
> % grep -c UNEXPECTED-FAIL ../mozjs52.log
> 4913
> 
> so is in a considerably worse state than s390x or the powerpc family.

I've committed changes to pkg-gnome git to make these failures
non-fatal, and will downgrade the severity of this bug to non-RC when
those changes have been released.

The test failures clearly indicate at least one bug, but it isn't clear
what the severity of that bug is: it could be anything from minor (if
trivial functionality is broken) to RC (if mozjs52 is basically unusable
on this architecture).

Any testing and patches that mips users can provide would be
appreciated. If the bug(s) isn't/aren't fixed, mozjs52 will either remain
available with known test failures if it does basically work, or have its
old binaries removed from mips (with the test failures becoming a FTBFS)
if feedback indicates that the test failures are evidence of RC bugs.

mozjs52 is used by current versions of gjs, so architecture-specific
removal of mozjs52 would also require architecture-specific removal of
gnome-shell, gnome-maps, polari etc., which would in turn make the GNOME
task and metapackages uninstallable on this architecture.

Thanks,
smcv

Re: Bug#877428: mozjs52: FTBFS on mips64el: regress-157652.js timeout; regress-422348.js timeout; ecma_6/Array/for_of_1.js got 150, expected 300

[Simon McVittie]

On Thu, 12 Oct 2017 at 01:37:51 +0100, Simon McVittie wrote:
> On mips64el there are a couple of timeouts (knowing mips*, probably
> an arbitrary timeout is just too short):
> 
> TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "") | (TIMEOUT)
> TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "") | 
> (TIMEOUT)
> 
> and one more interesting-looking failure:
> 
> ## ecma_6/Array/for_of_1.js: rc = 3, run time = 0.483245
> ecma_6/Array/for_of_1.js:100:5 Error: Assertion failed: got 150, expected 300
> Stack:
>   TestChangeArrayPrototype@ecma_6/Array/for_of_1.js:100:5
>   @ecma_6/Array/for_of_1.js:102:1
> TEST-UNEXPECTED-FAIL | ecma_6/Array/for_of_1.js | (args: "")

I've committed changes to pkg-gnome git to make these failures
non-fatal, and will downgrade the severity of this bug to non-RC when
those changes have been released.

The test failures clearly indicate at least one bug, but it isn't clear
what the severity of that bug is: it could be anything from minor (if
trivial functionality is broken) to RC (if mozjs52 is basically unusable
on this architecture).

Any testing and patches that mips64el users can provide would be
appreciated. If the bug(s) isn't/aren't fixed, mozjs52 will either
remain available with known test failures if it does basically work,
or have its old binaries removed from mips64el (with the test failures
becoming a FTBFS) if feedback indicates that the test failures
are evidence of RC bugs.

mozjs52 is used by current versions of gjs, so architecture-specific
removal of mozjs52 would also require architecture-specific removal of
gnome-shell, gnome-maps, polari etc., which would in turn make the
GNOME task and metapackages uninstallable on this architecture.

Thanks,
smcv

Bug#877428: mozjs52: FTBFS on mips64el: regress-157652.js timeout; regress-422348.js timeout; ecma_6/Array/for_of_1.js got 150, expected 300

[Simon McVittie]

Control: retitle 877428 mozjs52: FTBFS on mips64el: regress-157652.js timeout; 
regress-422348.js timeout; ecma_6/Array/for_of_1.js got 150, expected 300

[Re-sending to the correct clone, sorry for the noise]

On Sun, 01 Oct 2017 at 19:03:46 +0100, Simon McVittie wrote:
> On Sat, 23 Sep 2017 at 12:29:08 +0200, Emilio Pozuelo Monfort wrote:
> > Let's track the mips64el failure in a different bug, as it's
> > completely different from this.
> 
> Cloned away. I haven't investigated those failures at all.

On mips64el there are a couple of timeouts (knowing mips*, probably
an arbitrary timeout is just too short):

TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "") | (TIMEOUT)
TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "") | (TIMEOUT)

and one more interesting-looking failure:

## ecma_6/Array/for_of_1.js: rc = 3, run time = 0.483245
ecma_6/Array/for_of_1.js:100:5 Error: Assertion failed: got 150, expected 300
Stack:
  TestChangeArrayPrototype@ecma_6/Array/for_of_1.js:100:5
  @ecma_6/Array/for_of_1.js:102:1
TEST-UNEXPECTED-FAIL | ecma_6/Array/for_of_1.js | (args: "")

These don't match the failures I see on s390x, powerpc or powerpc64
porterboxes with
<https://anonscm.debian.org/cgit/users/smcv/mozjs52.git/log/?h=wip/s390x>.

Regards,
smcv

Re: Bug#827473: ostree: FTBFS on mipsel: "ostree pull" sometimes gets SIGBUS, SIGSEGV

[Simon McVittie]

Control: reopen 827473
Control: found 827473 2016.6-2

On Sun, 26 Jun 2016 at 19:54:11 +, Debian Bug Tracking System wrote:
>* New upstream release
...
>  - this version is more careful about thread-safety, which appears
>to fix the test failures that caused FTBFS on mipsel
>(Closes: #827473)

I thought this was true, and it seems to have worked on eberlin and etler
with 2016.6-1; but with 2016.6-2 (which makes no source changes, just
switches one test to LC_ALL=C) it's back to failing with sporadic
bus errors in "ostree pull" on eberlin. 5 out of 5 test runs failed,
but the test that fails in each run is different.

On Tue, 21 Jun 2016 at 11:55:29 +0100, Simon McVittie wrote:
> I'm going to try with valgrind, and if I can't get anything useful out of
> that, either ignore the test failure on mipsel, or ask for the 2016.5-3
> binaries to be removed so they don't block ostree migrating to testing
> on other architectures.

I was unable to get any useful information from valgrind either.

mips porters, is there something special that maintainers are expected
to do to be able to debug or diagnose mips-specific issues? As noted in
an earlier mail to this bug, inspecting the core dump was not helpful.
It's entirely possible that this is an ostree bug, but I'm unlikely to
be able to do anything about it without some indication of where it is.

How confident are we that these machines have reliable hardware,
and that the mipsel toolchain is reliable?

I would really like to resolve this somehow so that ostree and flatpak
can migrate to testing, either by getting enough information to be able
to diagnose and fix what is wrong, by having the mipsel binaries removed,
or by ignoring test failures on mipsel and assuming that if anyone
actually *uses* ostree there, they will also step forward to diagnose and
fix it.

S

Re: Bug#827473: ostree: FTBFS on mipsel: "ostree pull" sometimes gets SIGBUS, SIGSEGV

[Simon McVittie]

On Thu, 16 Jun 2016 at 12:06:12 -0400, Simon McVittie wrote:
> I'm trying to reproduce this failure on the porterbox etler.debian.org
> by rebuilding the package or by using the installed-tests from 2016.5-3.

I can reproduce it eventually, but the gdb report is unhelpful. Is there
anything special that I'd need to do to get a useful backtrace on mipsel?

(gdb) thread apply all bt full

Thread 3 (LWP 4232):
#0  0x775b697c in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (LWP 4215):
#0  0xec60 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (LWP 4231):
#0  0x777d151c in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

To reproduce:

* build ostree (I used 2016.5-4)
* while TEST_SKIP_CLEANUP=1 make check-TESTS 
TESTS=tests/test-pull-archive-z.sh; do :; done
  (and let it run for a while until it fails)
* look for a line like "Skipping cleanup of /var/tmp/tap-test.7eaT36" in
  test-suite.log
* ./libtool --mode=execute gdb ostree /var/tmp/tap-test.7eaT36/core

I'm going to try with valgrind, and if I can't get anything useful out of
that, either ignore the test failure on mipsel, or ask for the 2016.5-3
binaries to be removed so they don't block ostree migrating to testing
on other architectures.

S

Bug#827473: ostree: FTBFS on mipsel: "ostree pull" sometimes gets SIGBUS, SIGSEGV

[Simon McVittie]

Source: ostree
Version: 2016.5-4
Severity: important
Tags: help

[X-Debbugs-Cc set to debian-mips@lists.debian.org, please include them
in follow-ups.]

ostree failed to build on the mipsel buildd eberlin.debian.org:

I'm reporting this as important rather than serious because it seems
to be hard to reproduce, so I suspect a rebuild would probably be fine,
but it probably points to an underlying problem in either ostree or the
mipsel toolchain/machine.

I'm trying to reproduce this failure on the porterbox etler.debian.org
by rebuilding the package or by using the installed-tests from 2016.5-3.

One of the changes I made in 2016.5-4 was to repeat the tests 4 times
if they fail the first time, so we can see how reproducible things are.
In the failing build on eberlin, the results were:

tests/test-pull-archive-z.sh (1/5, 5/5): ostree command-line tool killed by
signal 10, which I think is SIGBUS, during "ostree pull"

tests/test-pull-large-metadata.sh (1/5): ostree command-line tool killed
by SIGBUS with no output, again during "ostree pull"

tests/test-oldstyle-partial.sh (1/5): ostree command-line tool killed
by SIGSEGV, again during "ostree pull"

tests/test-pull-metalink.sh (2/5): another SIGBUS during "ostree pull"

tests/test-pull-resume.sh (3/5, 4/5): SIGBUS during "ostree pull"

tests/test-admin-upgrade-not-backwards.sh (4/5): another SIGBUS during
"ostree pull"

tests/test-pull-depth.sh (5/5): another SIGBUS during "ostree pull"

If ostree's tests are reliable on architectures other than mipsel and
we can't reproduce the failure in an environment where stack traces are
available, I would prefer to exclude it from being built on mipsel rather
than ignore test failures, but I'm willing to be persuaded otherwise.

Any porter advice or help welcome. ostree has a standard Autotools
"make check", and GNOME-style installed-tests (mostly the same code)
wrapped in autopkgtest; if you haven't encountered those before,
the tl;dr version is that you install gnome-desktop-testing and
ostree-tests, then run "gnome-desktop-testing-runner ostree", or read
the underlying shell command-lines out of the .desktop-style files in
/usr/share/installed-tests/ostree).

Thanks,
S

Re: Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)

[Simon McVittie]

Control: retitle 796069 protobuf: built with -O0 on mips{,el} due to test 
failure at -O2
Control: severity 796069 normal

On Wed, 26 Aug 2015 at 23:17:06 +0100, Simon McVittie wrote:
> On 26/08/15 17:36, Robert Edmonds wrote:
> > I'm OK with a NMU that disables optimization of the entire build on
> > mips{,el} for now, though, if it will keep the GCC-5 transition moving
> > along.  Please feel free to upload to incoming rather than DELAYED.
> 
> I'll reduce this bug to non-RC when the buildds have produced a complete
> set of builds, which will hopefully happen overnight.

Sorry, forgot about this until now. Dropping the severity to something
more realistic.

S

Re: Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)

[Simon McVittie]

On 27/08/15 05:16, Robert Edmonds wrote:
 It looks like you did a source-only upload, and it also looks like I
 have a debian/rules build-indep bug.

Yeah, I just spotted that. With hindsight, approximately nothing is
going to build successfully with build-indep until its maintainer has
tested it, so I should have continued to do source+all uploads for NMUs.

 Can you upload either a binary+source NMU, or a source-only NMU that
 fixes the FTBIFS?

I still have the binaries I built to confirm that protobuf still gets
-O2 on amd64, so I'll upload my own libprotobuf-java_2.6.1-1.3_all.deb
and hopefully that will sort this out. If not, I'll look into the
build-indep issue.

I don't think many of the rdeps actually need libprotobuf-java, so
hopefully this has already unblocked C++ builds anyway.

S

Re: Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)

[Simon McVittie]

On 26/08/15 17:36, Robert Edmonds wrote:
 This sounds very vaguely similar to #572923, for which the workaround
 was to disable optimization of a single function

If you can find the right single function, please do :-) Both minkus
(mips porterbox) and eder (mipsel porterbox) can be used to reproduce
this. I would recommend minkus as the one to try first, it's
significantly faster.

 I'm OK with a NMU that disables optimization of the entire build on
 mips{,el} for now, though, if it will keep the GCC-5 transition moving
 along.  Please feel free to upload to incoming rather than DELAYED.

Thanks, I NMU'd the attached without going via DELAYED. I'm sure it
isn't the most elegant way to disable optimization, but it can be
superseded by a better maintainer-upload once the dust has settled.

I'll reduce this bug to non-RC when the buildds have produced a complete
set of builds, which will hopefully happen overnight.

S

diffstat for protobuf-2.6.1 protobuf-2.6.1

 changelog |   10 ++
 rules |6 ++
 2 files changed, 16 insertions(+)

diff -Nru protobuf-2.6.1/debian/changelog protobuf-2.6.1/debian/changelog
--- protobuf-2.6.1/debian/changelog	2015-08-06 07:48:15.0 +0100
+++ protobuf-2.6.1/debian/changelog	2015-08-26 21:38:00.0 +0100
@@ -1,3 +1,13 @@
+protobuf (2.6.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable optimization on mips and mipsel so that the tests pass.
+To keep the g++-5 transition moving, optimization is completely
+disabled here; someone who knows better can be more selective
+later. (Mitigates: #796069)
+
+ -- Simon McVittie s...@debian.org  Wed, 26 Aug 2015 21:37:58 +0100
+
 protobuf (2.6.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru protobuf-2.6.1/debian/rules protobuf-2.6.1/debian/rules
--- protobuf-2.6.1/debian/rules	2015-07-29 16:26:56.0 +0100
+++ protobuf-2.6.1/debian/rules	2015-08-26 21:37:55.0 +0100
@@ -1,5 +1,11 @@
 #!/usr/bin/make -f
 
+ifneq (,$(filter mips mipsel,$(shell dpkg-architecture -qDEB_HOST_ARCH)))
+export DEB_CFLAGS_MAINT_APPEND = -O0
+export DEB_CXXFLAGS_MAINT_APPEND = -O0
+endif
+
+
 %:
 	dh $@ --with autoreconf,python2
 

Re: Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)

[Simon McVittie]

On Tue, 25 Aug 2015 at 22:54:43 +0200, Julien Cristau wrote:
 On Wed, Aug 19, 2015 at 09:15:55 +0200, Julien Cristau wrote:
  protobuf no longer builds on the mips/mipsel buildds:
   ../test-driver: line 107:  6224 Segmentation fault  $@  $log_file 
   21
   FAIL: protobuf-test

 This bug is blocking the current gcc 5 / libstdc++6 transition.

If it's any help, this is reproducible on minkus.debian.org (mips, Octeon),
but is not reproducible with DEB_BUILD_OPTIONS=noopt on the same machine.
So it might be possible to coax it into working (well enough to get
through this transition) by reducing or omitting optimization on mips.

I'll try the same thing on eder (mipsel, Loongson-2) next.

S

Re: Bug#770009: convert(1) very slow on mips with no FPU

[Simon McVittie]

On 15/08/15 19:02, roucaries bastien wrote:
 On Sat, Aug 15, 2015 at 3:08 PM, Simon McVittie s...@debian.org wrote:
 Bastien: perhaps the conversion of SVG to 14 PNG icons could move to the
 arch-indep part of the build, and the smoke-test could be something
 simpler, like a single image-resize operation? Even if that takes an
 hour (leading to maybe a 3-4 hour total build time), that's way better
 than spending 16 hours on a smoke-test.
 
 Yes but I do not want to do that before next version. My priority is
 the new c++ library.

Someone (possibly jcristau?) seems to have rescheduled the
imagemagick/8:6.8.9.9-5.1 build on mips with a longer-than-default
inactivity timeout. We should know by tomorrow morning whether that has
worked; if it has, I'll leave it alone. If it has not worked, I might
NMU with the attached patch so that this part of the libstdc++
transition can start moving forward again. The release team probably
don't want to start binNMUs against the new imagemagick until it has
built on all architectures.

The attached patch moves the icons from imagemagick-6.q16 to
imagemagick-common so that they can be built by one of the -indep
stages. This does increase the installed size on systems that have the
imagemagick libraries, but not the executables, by around 350K; that
doesn't seem too expensive (and it saves space in the archive, by not
duplicating the icons). Installed size on systems that have the
executables is unaffected.

To get some trivial testing on each architecture even on non-FPU
machines, I've added a very simple format conversion (GIF to PNG) as an
alternative to the test suite.

S
diffstat for imagemagick-6.8.9.9 imagemagick-6.8.9.9

 changelog  |   10 
 display-im6.desktop.in |4 +--
 display.desktop.in |4 +--
 imagemagick-6.q16.install  |2 -
 imagemagick-common.install |2 +
 rules  |   51 +
 6 files changed, 45 insertions(+), 28 deletions(-)

diff -Nru imagemagick-6.8.9.9/debian/changelog imagemagick-6.8.9.9/debian/changelog
--- imagemagick-6.8.9.9/debian/changelog	2015-08-12 07:58:40.0 +0100
+++ imagemagick-6.8.9.9/debian/changelog	2015-08-15 19:29:13.0 +0100
@@ -1,3 +1,13 @@
+imagemagick (8:6.8.9.9-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move icons from imagemagick-6.q16 to imagemagick-common so that
+they don't have to be built by each architecture. mips buildds
+don't have a FPU, making convert(1) prohibitively slow there.
+(Closes: #770009)
+
+ -- Simon McVittie s...@debian.org  Sat, 15 Aug 2015 19:29:11 +0100
+
 imagemagick (8:6.8.9.9-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru imagemagick-6.8.9.9/debian/display.desktop.in imagemagick-6.8.9.9/debian/display.desktop.in
--- imagemagick-6.8.9.9/debian/display.desktop.in	2015-08-12 07:58:40.0 +0100
+++ imagemagick-6.8.9.9/debian/display.desktop.in	2015-08-15 18:45:46.0 +0100
@@ -6,9 +6,9 @@
 Comment[pt]=Exiba e edite arquivos de imagem
 Exec=/usr/lib/$(DEB_HOST_MULTIARCH)/ImageMagick-$(DEB_UPSTREAM_VERSION_DROPREVISION)/bin-$(QUANTUMDEPTH)/display %f
 Terminal=false
-Icon=display-im$(IMVERSION).$(LCQUANTUMDEPTH)
+Icon=display-im$(IMVERSION)
 Type=Application
 Categories=Graphics;
 Keywords=Image;Slideshow;View;Transform;Enhance;F/X;Special Effects
 Keywords[fr]=Image;Diaporama;Visualiser;Transformer;Améliorer;Effets spéciaux
-MimeType=image/avs;image/bie;image/x-ms-bmp;image/cmyk;image/dcx;image/eps;image/fax;image/fits;image/gif;image/gray;image/jpeg;image/pjpeg;image/miff;image/mono;image/mtv;image/x-portable-bitmap;image/pcd;image/pcx;image/pdf;image/x-portable-graymap;image/pict;image/png;image/x-portable-anymap;image/x-portable-pixmap;image/ps;image/rad;image/x-rgb;image/rgba;image/rla;image/rle;image/sgi;image/sun-raster;image/targa;image/tiff;image/uyvy;image/vid;image/viff;image/x-xbitmap;image/x-xpixmap;image/x-xwindowdump;image/x-icon;image/yuv;
\ No newline at end of file
+MimeType=image/avs;image/bie;image/x-ms-bmp;image/cmyk;image/dcx;image/eps;image/fax;image/fits;image/gif;image/gray;image/jpeg;image/pjpeg;image/miff;image/mono;image/mtv;image/x-portable-bitmap;image/pcd;image/pcx;image/pdf;image/x-portable-graymap;image/pict;image/png;image/x-portable-anymap;image/x-portable-pixmap;image/ps;image/rad;image/x-rgb;image/rgba;image/rla;image/rle;image/sgi;image/sun-raster;image/targa;image/tiff;image/uyvy;image/vid;image/viff;image/x-xbitmap;image/x-xpixmap;image/x-xwindowdump;image/x-icon;image/yuv;
diff -Nru imagemagick-6.8.9.9/debian/display-im6.desktop.in imagemagick-6.8.9.9/debian/display-im6.desktop.in
--- imagemagick-6.8.9.9/debian/display-im6.desktop.in	2015-08-12 07:58:40.0 +0100
+++ imagemagick-6.8.9.9/debian/display-im6.desktop.in	2015-08-15 18:45:59.0 +0100
@@ -6,9 +6,9 @@
 Comment[pt]=Exiba e edite arquivos de imagem
 Exec=/usr/bin/display-im$(IMVERSION) %f
 Terminal

Re: Bug#770009: convert(1) very slow on mips with no FPU

[Simon McVittie]

(debian-mips: please keep me and the bug in Cc if replying.)

On Wed, 28 Jan 2015 at 08:00:53 +0100, roucaries bastien wrote:
 Smell like an openmp bug ny memory they are a enviroment variable to
 disable openmp.

I tried building with --disable-openmp on a mips porterbox
(minkus.debian.org, which I believe is a dual Cavium Octeon II with no FPU,
the same as the buildds where imagemagick has been failing).

Unfortunately building with --disable-openmp doesn't seem to help.

On Thu, 29 Jan 2015 at 19:59:45 +0100, Bastien ROUCARIES wrote:
 try to add to convert command line -limit thread 1

Sadly that doesn't seem to help either.

 On Fri, Jan 30, 2015 at 2:37 PM, Dejan Latinovic
 dejan.latino...@imgtec.com wrote:
  did anyone tried to wait some longer time to see if command will execute?
 
   No, but the build machines wait for a pretty long time before
 killing (5 hours), and I've checked that it uses the proc at 200%. We
 can't burden the build machines like that...

The latest experimental build (which adds some echo, to stop sbuild
killing the build process after 5 hours of apparent inactivity) took
19 hours. That's longer than gcc-5 took on the same hardware.

While doing test builds yesterday evening, I was able to compile
imagemagick more than once, so it can't have taken longer than 2 or 3 hours;
assuming the porterbox and the buildd have a similar spec, that means
converting a SVG to a PNG 14 times is taking at least 16 hours.
That seems unusably slow to me. It's entirely possible that imagemagick
built for mips is currently only really useful on mips hardware that has
a FPU. Unfortunately, the mips buildds don't seem to have FPUs.

mips porters: how common are FPUs expected to be among mips machines
where Debian will run? Also, is it an ABI break for a mips library to
be built with -msoft-float? If mips FPUs are rare, and -msoft-float
produces a compatible ABI, then perhaps we should be compiling imagemagick
with -msoft-float, so it will use libgcc for somewhat slow floating
point emulation (like armel does), rather than very slow kernel traps
(like the old arm port)?

If -msoft-float is not viable, either because FPUs are common or because
it produces a different ABI, then it seems to me as though we need
some sort of compromise to make imagemagick builds complete in a finite time.
Bastien doesn't want to remove the smoke-test of the built binaries,
which I can understand; but at the same time, building imagemagick
shouldn't take 19 hours.

Bastien: perhaps the conversion of SVG to 14 PNG icons could move to the
arch-indep part of the build, and the smoke-test could be something
simpler, like a single image-resize operation? Even if that takes an
hour (leading to maybe a 3-4 hour total build time), that's way better
than spending 16 hours on a smoke-test.

   I could try building with another version of gcc, though.

Unfortunately, this has ceased to be an option, because g++-4.x and g++-5
produce a different ABI for libmagick++.

S

problems with mips builds on ball (potential mass give-back)

[Simon McVittie]

(Re-sending to a wider audience than mips@b.d.o, with more information and
a somewhat complete list of give-backs.)

ball.debian.org seems to be rather unhappy. My recent dbus upload failed
with this in the log:

../../dbus/dbus-transport.c: In function
'_dbus_transport_get_is_authenticated':
../../dbus/dbus-transport.c:788:1: internal compiler error: Segmentation
fault
[... log noise from a parallel compilation omitted ...]
The bug is not reproducible, so it is likely a hardware or OS problem.

I assume that last line means that recent gcc automatically retries
compilations that failed with a segfault, to see whether they work the
second time?

It's not the only package in a similar situation: when I picked some examples
at random, nipy's tests segfaulted, and nmap and gamera
suffered an unreproducible compiler segfault similar to dbus. Each of
those packages built successfully on the other architectures.

Ben Hutchings reported a similar problem on kernel backport builds
https://lists.debian.org/debian-kernel/2012/07/msg00105.html.

I've attempted to provide a list of affected packages in sid (by looking at
buildd.debian.org, I know nothing about most of these packages). See below
for that; it's a list of gb commands which can be given when ball has been
repaired or removed from service. I haven't done this for any other suites
so far, but ball appears to build at least squeeze-backports too.

The list does not include builds on ball which failed for similar reasons
on other architectures, on the assumption that those are more likely to be
package bugs.

This could be rather unfortunate for packages' testing migration, which
is why I've cc'd the release team.

Regards,
S

# based on 
https://buildd.debian.org/status/architecture.php?a=mipssuite=sidbuildd=buildd_mips-ball

# gcc segfaulted then said The bug is not reproducible, potentially
# bad hardware
gb dbus_1.6.2-2 . mips
gb gamera_3.3.3-2 . mips
gb llvm_3.1-2 . mips
gb loqui_0.5.3-4 . mips
gb nmap_6.00-0.1 . mips
gb python-pyo_0.6.2-1 . mips
gb sane-backends_1.0.22-7.2 . mips
gb sblim-wbemcli_1.6.2-7 . mips
gb scikit-learn_0.11.0-2 . mips

# gcc segfaulted but the bug was reported to be reproducible; could
# still be bad hardware?
gb terminal.app_0.9.8-1 . mips

# gcc PIC build succeeded, but the corresponding static build failed, with
# errors hidden by libtool; potentially bad hardware?
gb 389-adminutil_1.1.15-1 . mips
gb spandsp_0.0.6~pre20-3 . mips

# ld segfaulted, potentially bad hardware
gb eigen3_3.1.0-1 . mips

# Doxygen segfaulted, potentially bad hardware
gb cctools_3.5.1-2 . mips
gb freefoam_0.1.0-1 . mips

# Tests segfaulted, potentially bad hardware
gb nipy_0.2.0~rc2+git27-g7b9b5a5-1 . mips
gb ruby-raindrops_0.10.0-1 . mips

# Bus error, potentially bad hardware
gb gmsh_2.6.0.dfsg-2 . mips
gb haskell-github_0.4.0-1 . mips
gb haskell-system-fileio_0.3.8-1 . mips
gb haskell-tagstream-conduit_0.3.2-1 . mips
gb xdffileio_0.3-1 . mips

# Impossible to tell from the log because its stderr and exit code were
# suppressed, but pdflatex might have segfaulted
gb apparmor_2.7.103-3 . mips

# Python error wrongly claiming that 'int' is not an integer type,
# possibly due to memory corruption caused by bad hardware?
gb statsmodels_0.4.2-1 . mips

# Python internal errors, possibly memory corruption caused by bad hardware?
gb obnam_1.1-1 . mips


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120714225602.ga17...@reptile.pseudorandom.co.uk