Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64

[Simon McVittie]

Source: libgl1-mesa-dri
Version: 24.2.2-1
Severity: normal
X-Debbugs-Cc: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64

To reproduce:
- install gtk4 build-dependencies on sparc64 porterbox with no access to a
  real GPU
- get gtk4 source
- edit debian/rules to remove the special case that forces use of softpipe
  on sparc64
- build and run tests

Expected result: either of these:
- llvmpipe exists, is used, and works
- llvmpipe doesn't exist and softpipe is automatically used instead

Actual result:
- all tests that use OpenGL fail with message "Target has no JIT support"

I would suggest special-casing llvmpipe (and anything else requiring LLVM
JIT: lavapipe?) to be built on most of the $(LLVM_ARCHS), but not sparc64.

smcv

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

[Simon McVittie]

Control: retitle -1 gtk4: FTBFS with weston 14: many tests fail with 
--setup=wayland: Failed to open display
Control: severity -1 serious

(Please remove -ports from cc in replies, this is no longer believed to
be -ports specific)

On Thu, 12 Sep 2024 at 11:48:21 +0100, Simon McVittie wrote:
> gtk4's test suite is failing on all -ports architectures that have buildds
>
> (/<>/debian/build/deb/testsuite/gtk/spinbutton:12693): 
> Gtk-WARNING **: 17:54:18.469: Failed to open display

It seems that it's now also failing on release architectures, and the
failure seems well-correlated with weston being upgraded to version 14.
The reason this particularly affected -ports is that -ports didn't have
an installable version of weston 13, so by definition all of their recent
gtk4 builds had to be with weston 14.

My current working theory is either a behaviour change in Weston 14,
or Weston 14 is crashing part way through testing and all subsequent
tests fail.

smcv

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

[Simon McVittie]

Source: gtk4
Version: 4.14.4+ds-8
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-po...@lists.debian.org

Until recently, gtk4 was not buildable on any -ports architectures because
its build-dependency, weston, was uninstallable. Now it's installable, and
building and testing can be attempted.

gtk4's test suite is failing on all -ports architectures that have buildds,
except for m68k (which I believe builds with nocheck and therefore does not
run the test suite at all).

The GNOME team is busy with GNOME 47 on release architectures and
unlikely to have time to look into this in detail any time soon, but if
porting teams would like to have GTK 4 available (it will be increasingly
important for desktop architectures in trixie), it would be useful if
someone from -ports could investigate.

The gtk4 test suite is run in two phases:

1. with --setup=x11, wrapped by "debian/tests/run-with-display x11" which
   is basically xvfb-run

2. with --setup=wayland, wrapped by "debian/tests/run-with-display wayland"
   which is intended to be a Wayland equivalent of xvfb-run, using weston
   in headless mode as the compositor

Taking powerpc as my arbitrary example, most tests are passing during the
x11 phase. On powerpc, I see a failure in "gtk:gtk / sorter" (unstable
and experimental) and in "gtk:gdk / memorytexture" (experimental only)
which can be investigated separately; please treat those isolated failures
as out-of-scope for the purposes of this bug.

However, in the wayland phase, most tests are failing with (fatal) warnings
like:

(/<>/debian/build/deb/testsuite/gtk/spinbutton:12693): Gtk-WARNING 
**: 17:54:18.469: Failed to open display

weston might be broken on all -ports architectures and functional on
all release architectures, but that level of coincidence seems a little
far-fetched. So my next theory for this is that something is consistently
different about the -ports buildds - perhaps their XDG_RUNTIME_DIR is
set up differently? - and that is causing
"debian/tests/run-with-display wayland" (or the copy of weston that it
runs) to fail?

After the failure mode discussed in this bug report has been addressed,
it will become more useful to look at individual/isolated test
failures (as separate bug reports, please). Based on the status of the
less-production-ready release architectures like mips64el and riscv64, I
suspect that the most common root cause for individual test failures will
be the software OpenGL stack: implementation issues in Mesa's llvmpipe
and softpipe, implementation issues in LLVM's old MCJIT and new ORCJIT,
and the GTK packaging's choice of whether to mitigate llvmpipe bugs by
forcing softpipe (currently done on mips*, riscv*, powerpc, sparc*)
or test with llvmpipe (as we do on x86, ARM, etc.).

Thanks,
smcv

Re: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

Control: tags -1 + pending

On Wed, 04 Sep 2024 at 18:51:11 +0100, Simon McVittie wrote:
> src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
> around #1010838. Mesa 24.2.x is no longer built with softpipe enabled

24.2.1-4 re-enables softpipe (#1080475) which should resolve this for
mips*, powerpc and sparc*. The new Mesa version has not compiled on
buildds yet, but when it has, I'll check whether it fixes the build
regression on mips64el. Hopefully we can also start using softpipe on
riscv64 as a workaround for #1080435, until that gets fixed.

If there are -ports architectures where llvmpipe is known-broken,
I don't mind adding them to the list of architectures where we use
GALLIUM_DRIVER=softpipe - but I would suggest that as a longer-term
plan to have working GL everywhere, porters should look into fixing
llvmpipe for their architecture (via changes in Mesa and/or LLVM) if
necessary. The addition of an ORCJIT code path in Mesa seems like a
really big step towards this.

> I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
> we can use the new ORCJIT llvmpipe and remove the workaround for #1010838

Unfortunately the answer seems to be "no we can't": lots of tests still
fail on mips64el with ORCJIT llvmpipe. I haven't looked into the failures
in detail, but this does not seem to be the same problem as on riscv64
(#1080435, #1080493) since the patch that has been suggested for the
riscv64 issue is in riscv64-specific code.

I haven't tried the -ports architectures with llvmpipe: they might be OK
with llvmpipe now, or they might still have similar problems. If a porter
wants to look into this, please look for "GALLIUM_DRIVER=softpipe"
in debian/rules and it should be obvious from there how to disable the
workaround. Testing the gtk4 4.15.x from experimental is more important
than the gtk4 4.14.x in testing/unstable right now, because we're hoping
to upload 4.15.x/4.16.x to unstable soon (it's required for GNOME 47).

smcv

Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

Source: gtk4
Version: 4.14.4+ds-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-powe...@lists.debian.org, debian-sparc@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el

src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
around #1010838. Mesa 24.2.x is no longer built with softpipe enabled,
so this makes the softpipe driver fail to load and as a result makes (E)GL
initialization fail, breaking the test suite on these architectures, for
example:

> test: gtk:gsk / normalize
> ...
> not ok /node/normalize/color - 
> ERROR:../../../testsuite/gsk/normalize.c:18:test_normalize: assertion failed 
> (error == NULL): Could not initialize EGL display (gdk-gl-error-quark, 0)

Affected tests are

* gtk:gsk / normalize (run twice, for X11 and Wayland)
* gtk:gsk / misc (run twice, ditto)
* gtk:tools / validate (only run once, for Wayland)

I have only verified this on mips64el, but it probably affects the powerpc
and sparc64 -ports architectures equally.

My preferred solution for this would be for Mesa to re-enable softpipe,
at least on the affected architectures (I've opened a src:mesa bug #1080475
requesting that). If we stop using softpipe in gtk4 before Mesa 24.2.x
migrates to testing, then we will likely get a different failure mode
with the Mesa from testing: #1010838.

I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
we can use the new ORCJIT llvmpipe and remove the workaround for #1010838,
but it's taking a while (mips64el machines are not fast). So far it's
looking as though we will still get quite a lot of test failures.

smcv

Re: Bug#1079124: schroot: regression in 1.6.13-4 when local configuration makes /dev/pts a bind mount

[Simon McVittie]

On Tue, 20 Aug 2024 at 12:33:22 +0100, Simon McVittie wrote:
> Please see attached. As with the other known regression from 1.6.13-4
> (#1078539), the proposed solution is a change to a conffile, so buildd
> operators could try this manually if desired.

The patch I previously attached here is also available as part of
<https://salsa.debian.org/debian/schroot/-/merge_requests/4>,
which fixes both this bug and #1078539.

smcv

Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

[Simon McVittie]

On Tue, 20 Aug 2024 at 01:30:55 +0100, Simon McVittie wrote:
> The reason for the regression is probably that /dev/pts/ptmx on the host
> has permissions 000, making it inaccessible (despite being functionally
> equivalent to /dev/ptmx which is available to everyone).

Yes, it seems to be this. I've reported the regression as #1079124, please
send any further replies regarding this regression to there.

In future it would be more discoverable (and probably also less effort for
the bug reporter) to report regressions as a new bug with an appropriate
severity, rather than as replies to a closed bug whose solution introduced
the regression.

> It would probably be possible to drop the bind-mounting onto
> /dev/ptmx with modern kernels

Yes, it seems OK: see the patch proposed on #1079124 (tested on 4.19.x
and 6.9.x).

On Tue, 20 Aug 2024 at 01:07:55 +, Thorsten Glaser wrote:
> The varios MIPS buildds run 4.19 and some even 4.9 kernels

I'm aware of mips64el buildds (and a porterbox) still running 4.19
(Debian 10 kernel), and I've reminded #1050872 that this continues to be
a cause for concern.

I was not aware of any mips* buildds still on 4.9 (Debian 9 kernel). The
only mips family architecture listed on buildd.debian.org is mips64el, for
which I've been able to confirm that every machine listed on db.debian.org
has at least a Debian 10 kernel, or at least had one in the past and was
working well enough at the time to be able to build and upload some packages.

If there are unofficial mips* buildds outside the buildd.debian.org
infrastructure, then I would hope that either they can be upgraded to a
Debian 10 or later kernel, or they can run a Debian 12 or older user-space
(in particular, not keeping up with the latest sbuild). However, if I'm
reading kernel git history correctly, the patch proposed on #1079124
should in principle work with any 4.7+ kernel (not tested). This would
not have been broad enough compatibility in 2017, but seems OK now.

smcv

Re: Bug#1079124: schroot: regression in 1.6.13-4 when local configuration makes /dev/pts a bind mount

[Simon McVittie]

Control: tags -1 + patch

On Tue, 20 Aug 2024 at 12:10:33 +0100, Simon McVittie wrote:
> I'm testing a patch now.

Please see attached. As with the other known regression from 1.6.13-4
(#1078539), the proposed solution is a change to a conffile, so buildd
operators could try this manually if desired.

Tested successfully on a Debian unstable amd64 VM booted into either a
semi-recent unstable kernel (6.9.12-1, the same as the affected -ports
buildds) or the Debian 10 kernel (4.19.249-2 as used on some mips64el
buildds, see also #1050872).

With the unstable kernel, I can rebuild mksh successfully without changes.

With the Debian 10 kernel, I had to edit mksh's debian/control to remove
the klibc build-dependency (use of which requires a Debian 11+ kernel)
but otherwise the build also succeeds.

If I'm reading the kernel's git history correctly, applying the attached
patch would cause schroot to regress on v4.6 or older kernels, which
I hope are not at all relevant to Debian: Debian 9 'stretch' had v4.9,
so even if Thorsten was correct to say that some mips-family buildds are
still on v4.9, this shouldn't break them either (but I hope that he was
misinformed about that, because v4.19 kernels are already a cause for
concern, and we defintely shouldn't be relying on v4.9 in 2024).

> To reproduce:
...
> * edit /etc/schroot/buildd/fstab

Correction, if you are using sbuild in its default configuration on a
developer system, the reproducer is to edit /etc/schroot/sbuild/fstab
instead. To be sure, apply the change to each /etc/schroot/*/fstab.

smcv
From: Simon McVittie 
Date: Tue, 20 Aug 2024 11:37:25 +0100
Subject: setup.d/10mount: Don't bind-mount /dev/pts/ptmx onto
 /dev/ptmx

If /dev/pts is a new instance of devpts with ptmxmode=666, as it is since
commit 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot",
then it's safe to bind-mount /dev/pts/ptmx onto /dev/ptmx because
we explicitly make its mode 0666.

However, if an old conffile has been kept or overwritten by configuration
management (as on debian-ports buildds), or if a profile has been
explicitly configured to bind-mount the host's /dev/pts in preference
to using a new instance, then it is not safe to bind-mount the host's
/dev/pts/ptmx onto /dev/ptmx, because the host's /dev/pts/ptmx will
often have permissions 000 for reasons that are not clear to me.

With recent-ish kernels (v4.7+, with commit eedf265a
"devpts: Make each mount of devpts an independent filesystem" included),
this bind-mount becomes unnecessary, because the kernel automatically
redirects actions on /dev/ptmx to work with an adjacent devpts mount.
It was included in my 2017 patch to accommodate older kernels like
the one in Debian 8 'jessie', but is unnecessary if we can assume a
Debian 9 'stretch' or later kernel.

Bug-Debian: https://bugs.debian.org/1079124
Fixes: 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot"
Signed-off-by: Simon McVittie 
---
 etc/setup.d/10mount | 10 --
 1 file changed, 10 deletions(-)

diff --git a/etc/setup.d/10mount b/etc/setup.d/10mount
index 010b8b4c..31e817dc 100755
--- a/etc/setup.d/10mount
+++ b/etc/setup.d/10mount
@@ -286,16 +286,6 @@ fi
 
 if [ $STAGE = "setup-start" ] || [ $STAGE = "setup-recover" ]; then
 if [ "$(uname -s)" = "Linux" ]; then
-# Depending on how /dev was set up, /dev/ptmx might either be
-# character device (5,2), or a symbolic link to pts/ptmx.
-# Either way we want it to be equivalent to /dev/pts/ptmx, assuming
-# both exist.
-if [ -e "$CHROOT_PATH/dev/pts/ptmx" ] && \
-[ -e "$CHROOT_PATH/dev/ptmx" ] && \
-! [ "$CHROOT_PATH/dev/pts/ptmx" -ef "$CHROOT_PATH/dev/ptmx" ]; then
-mount --bind "$CHROOT_PATH/dev/pts/ptmx" "$CHROOT_PATH/dev/ptmx"
-fi
-
 # If schroot was invoked from a terminal, we still want to be able to
 # access that terminal. lxc and systemd-nspawn achieve this by
 # binding it onto /dev/console; so can we.

Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

[Simon McVittie]

On Tue, 20 Aug 2024 at 00:59:30 +0100, Jessica Clarke wrote:
> On 20 Aug 2024, at 00:23, Simon McVittie  wrote:
> > I was unable to reproduce this build failure
...
> > There must presumably be something different about how sbuild-createchroot
> > and schroot are configured or invoked on the affected buildds
> 
> Possibly relevant is that dsa-puppet’s buildd schroot fstab, which we
> also use for the -ports buildds, has:
> 
> > /dev/pts/dev/ptsnonerw,bind 0   0
> 
> Looking at the patch you applied to schroot, schroot’s own fstab
> templates had that line modified. So I suspect your patch assumes that
> the fstab doesn’t just bind-mount /dev/pts, which fails to account for
> dsa-puppet’s config?

Yes, probably that. The patch I contributed to schroot involves a
coordinated change to the various profiles' fstab templates and the
10mount script, so it's unlikely to work as intended if local configuration
reverts half of that change while keeping the other half intact.

The reason for the regression is probably that /dev/pts/ptmx on the host
has permissions 000, making it inaccessible (despite being functionally
equivalent to /dev/ptmx which is available to everyone). I'm not sure I
ever understood why that was considered to be a useful default, even
in 2017 when I originally looked at this. Bind-mounting the inaccessible
device onto /dev/ptmx results in an inaccessible /dev/ptmx, which is
certainly not what we want.

It would probably be possible to drop the bind-mounting onto
/dev/ptmx with modern kernels - it was functionally relevant
when I originally contributed the patch in 2017 because the commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=eedf265aa003b4781de24cfed40a655a664457e6
was rather recent at that time, but hopefully we no longer have any
machines that are running Debian 8 kernels...

Unfortunately I'm not seeing a way to get the behaviour where schroot
behaves like other container managers (mounting a new instance of
/dev/pts) while being resilient against local configuration that
continues to hard-code that we will not be doing that. Possibly some
sort of fstab.d arrangement so that it's possible to override part of
/etc/schroot/*/fstab without having to copy-and-modify the whole thing?
But then the configuration in dsa-puppet would still have to change to
accommodate that.

(As far as I can see, the fstab configuration in dsa-puppet is intended to
add some lines to schroot's defaults, rather than forcing specific handling
for /dev/pts, but it forces specific handling for /dev/pts as a side-effect
because it's overwriting the whole file.)

smcv

Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

[Simon McVittie]

I'm using Thorsten's regression report in #983423 as my representative
sample of a package that regressed with schroot 1.6.13-4, because mksh
builds much more quickly than gcc-14, but I suspect that the same would
apply equally to Adrian's regression report in #856877: the important
factor is probably just "any package that wants to run script(1)
or expect(1)".

I was not able to reproduce the mksh build failure, so there must be
some relevant difference in setup (other than CPU architecture, which
shouldn't actually matter here) between the affected -ports buildds and
my attempt to set up a mockup of a buildd. Please could a buildd operator
provide more details of how something resembling the -ports buildd
environment can be replicated in a test VM?

On Mon, 19 Aug 2024 at 17:02:33 +0100, Simon McVittie wrote:
> On Sun, 18 Aug 2024 at 23:44:57 +, Thorsten Glaser wrote:
> > On three buildds, mksh FTBFS already because the whole
> > /dev/ptmx and /dev/pts stuff is malfunctioning again
> 
> Which buildds? Are you referring to -ports builds
> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0,
> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0,
> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0
> each of which reported
> "script: failed to create pseudo-terminal: Permission denied"?

I was unable to reproduce this build failure in an amd64 unstable VM
(created with autopkgtest-build-qemu, if it matters), coincidentally
with a 6.9.12-1 kernel matching those buildds, by running these commands
as a user in the sudo and sbuild groups from a virtual console or from
an interactive ssh shell:

sudo sbuild-createchroot sid /srv/sid http://192.168.122.1:3142/debian
sbuild -dsid mksh

where http://192.168.122.1:3142 is an apt-cacher-ng instance
(replace that argument with http://deb.debian.org/debian or similar if
required).

I also tried running sbuild with no controlling tty, by doing this outside
the test VM:

ssh -T user@testvm sbuild -n -dsid mksh

and that also seems to be working fine: mksh can run its test suite
involving script(1), and the test suite and build succeed.

sbuild-createchroot defaulted to creating this schroot configuration:

[sid-amd64-sbuild]
description=Debian sid/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=directory
directory=/srv/sid
union-type=overlay

There must presumably be something different about how sbuild-createchroot
and schroot are configured or invoked on the affected buildds, but I don't
know specifically what.

On my test VM, while I have one ssh session active (logged in as 'user'
on /dev/pts/0), some relevant parts of the VM's /dev look like this:

$ ls -l /dev/console /dev/ptmx /dev/pts/* /dev/tty
crw--- 1 root root   5, 1 Aug 19 22:06 /dev/console
crw-rw-rw- 1 root tty5, 2 Aug 19 23:08 /dev/ptmx
crw--w 1 user tty  136, 0 Aug 19 23:08 /dev/pts/0
c- 1 root root   5, 2 Aug 19 22:06 /dev/pts/ptmx
crw-rw-rw- 1 root tty5, 0 Aug 19 22:55 /dev/tty

(/dev/pts/ptmx having permissions 000 is strange, but seems to be expected,
and does not cause observable brokenness for the VM: in particular
script(1) still works fine there, because accessing /dev/ptmx is
successful.)

The /dev in /srv/sid/dev (the base chroot created by debootstrap) has:

crw-rw-rw- 1 root root 5, 1 Aug 19 22:47 console
lrwxrwxrwx 1 root root   13 Aug 19 22:47 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Aug 19 22:47 full
crw-rw-rw- 1 root root 1, 3 Aug 19 22:47 null
crw-rw-rw- 1 root root 5, 2 Aug 19 22:47 ptmx
drwxr-xr-x 2 root root 4096 Aug 19 22:47 pts# is empty
crw-rw-rw- 1 root root 1, 8 Aug 19 22:47 random
drwxr-xr-x 2 root root 4096 Aug 19 22:47 shm# is empty
lrwxrwxrwx 1 root root   15 Aug 19 22:47 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root   15 Aug 19 22:47 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root   15 Aug 19 22:47 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Aug 19 22:47 tty
crw-rw-rw- 1 root root 1, 9 Aug 19 22:47 urandom
crw-rw-rw- 1 root root 1, 5 Aug 19 22:47 zero

The /dev in the schroot environment while one of my mksh builds was
running (ls -l /run/schroot/mount/sid-*/dev) has:

crw--w 1 user tty  136, 0 Aug 19 22:51 console
lrwxrwxrwx 1 root root 13 Aug 19 22:47 fd -> /proc/self/fd
crw-rw-rw- 1 root root   1, 7 Aug 19 22:47 full
crw-rw-rw- 1 root root   1, 3 Aug 19 22:47 null
crw-rw-rw- 1 root root   5, 2 Aug 19 22:50 ptmx
drwxr-xr-x 2 root root  0 Aug 19 22:48 pts  # devpts mounted
crw-rw-rw- 1 root root   1, 8 Aug 19 22:47 random
drwxrwxrwt 2 root root 40 Aug 19 22:48 shm  # tmpfs mounted
lrwxrwxrwx 1 root root 15 Aug 19

Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

[Simon McVittie]

On Mon, 19 Aug 2024 at 16:27:24 +, Thorsten Glaser wrote:
> mksh actually does things inside script(1) that use the tty

For the purposes of having a test-case for schroot that doesn't require
mksh, perhaps a good approximation to this would be asserting that
tty(1) from coreutils exits successfully and prints the path to a char
device that exists and is rw?

For a manual smoke-test for this change, having a known-good version
of mksh build and pass its test suite seems like a better indicator
that the terminal is indeed working, but I think that's too large and
involved to make a reasonable autopkgtest for schroot to guard against
this maybe regressing.

> case $(script -c 'echo true | env -i /bin/mksh-static -i' 2>&1) in
> *[!\ \#\$]*) echo fail ;;
> esac

I assume this is basically testing a code path inside mksh that calls
isatty(3) on one or more of the standard fds 0-2, because mksh -i should
set the prompt to (something that will expand to) "# " or "$ " if running
on a pty or tty, or produce some other output if not?

For schroot's purposes, it seems close enough to assert that any single
tty ioctl or termios function call works successfully (indicating that,
yes, it genuinely is a working tty).

smcv

Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

[Simon McVittie]

On Sun, 18 Aug 2024 at 23:44:57 +, Thorsten Glaser wrote:
> On three buildds, mksh FTBFS already because the whole
> /dev/ptmx and /dev/pts stuff is malfunctioning again

Which buildds? Are you referring to -ports builds
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0,
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0,
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0
each of which reported
"script: failed to create pseudo-terminal: Permission denied"?

-powerpc, -sparc teams: how are those buildds
(debian-project-be-1.buildd.org, blaauw.buildd.org, sompek.debian.net)
set up?
* host system suite: testing? unstable? other?
* kernel: seems to be 6.9.12 in each case, presumably from testing/unstable
* schroot: 1.6.13-4 or some sort of backport?
* is there any container/chroot/other confinement between the host system
  and sbuild+schroot?
* any special schroot or kernel configuration?

Thorsten, I see that
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=59c-39&stamp=1724031130&raw=0,
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sh4&ver=59c-39&stamp=1724031300&raw=0
seem to be running script(1) successfully, but failing with an error
that looks different (possibly related to using qemu-user on an amd64
system). Can I assume that those are out-of-scope here?

> have you actually tested that this works?

I initially provided the patch that was recently applied to schroot back
in 2017, and unfortunately I don't completely remember what I did 7 years
ago, but I think my usual reproducer for "do pseudo-terminals work?" was
to run something like "script -c 'cat /etc/os-release' /dev/null" inside
a schroot. Is that a good mockup of what mksh needs to do, or is there
something more complicated (but hopefully simpler than mksh's full test
suite) that would be a better reproducer?

I have not been continually testing that patch for 7 years, and I didn't
make the decision to integrate it now, so I can't speak to what testing
was done before the upload that integrated it.

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

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

[Simon McVittie]

On Sun, 25 Sep 2022 at 15:41:04 +0200, John Paul Adrian Glaubitz wrote:
> Could you blacklist the test
> 
> “ large-arraybuffers/basic.js”
> 
> on all affected big-endian targets (powerpc, ppc64, sparc64)?
> 
> The test is blacklist on s390x and fails on powerpc and ppc64 as well.

I'm not intending to touch it until the current version has either
migrated or failed to migrate, but after that, sure. Please open a
mozjs102 bug as a reminder.

(Obviously I'd prefer a fix for whatever endianness assumption is causing
this test to fail, if a porter for big-endian architectures can find the
root cause and suggest a patch.)

smcv

Re: Bug #905825: mozjs52: test failure on alpha: Expected value 'InternalError: allocation size overflow', Actual value 'out of memory'

[Simon McVittie]

Control: retitle -1 mozjs52: test failure on alpha|sparc64: Expected value 
'InternalError: allocation size overflow', Actual value 'out of memory'
Control: user debian-sparc@lists.debian.org
Control: usertags -1 + sparc64

On Fri, 10 Aug 2018 at 11:05:33 +0100, Simon McVittie wrote:
> Two mozjs52 tests fail on alpha:
> 
> ## js1_5/Array/regress-157652.js: rc = 0, run time = 0.418948
> BUGNUMBER: 157652
> STATUS: Testing that Array.sort() doesn't crash on very large arrays
> --- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 0 ---
> --- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 5 ---
>  FAILED! [reported from top level script] Testing that Array.sort() doesn't 
> crash on very large arrays : Expected value 'InternalError: allocation size 
> overflow', Actual value 'out of memory'
> TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "")
> 
> and
> 
> ## js1_5/Regress/regress-422348.js: rc = 0, run time = 0.458987
> BUGNUMBER: 422348
> STATUS: Proper overflow error reporting
>  FAILED! [reported from test()] Proper overflow error reporting : Expected 
> value 'InternalError: allocation size overflow', Actual value 'out of memory'
> TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "")
> 
> I suspect that alpha just needs to be added to the list of 64-bit
> architectures where tests like these are skipped, similar to how mips64
> was added in
> debian/patches/tests-For-tests-that-are-skipped-on-64-bit-mips64-is-also.patch
> (generalizing that patch to be more like "add more 64-bit architectures"
> would probably be the best solution).

sparc64 also has a similar failure mode and should probably also be
added to that list of 64-bit architectures, although on sparc64 this
is swamped by a different failure mode where tests expect NaN and get
undefined instead (I've opened a separate sparc64-specific bug for that).

riscv64 and other new 64-bit architectures would probably have the same
bug if mozjs supported them.

If someone who likes portability and understands the Mozilla build/test
system better than I do could upstream a patch that replaces
skip-if(xulRuntime.XPCOMABI.match(...)) with some sort of
skip-if(xulRuntime.WORDSIZE == 64) or similar, that would be an even better
solution; the build system already has a concept of matching architectures
to word sizes.

smcv

Bug#905829: mozjs52: tests fail on sparc64: numeric operations expecting NaN get undefined instead

[Simon McVittie]

Source: mozjs52
Version: 52.9.1-1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64

Lots of mozjs52 tests fail on sparc64 because the test does some numeric
operation that expects NaN (not a number) as result, but gets undefined
back instead, for example:

FAILED! Number.NEGATIVE_INFINITY % Number.NEGATIVE_INFINITY = undefined 
expected: NaN
FAILED! VAR1 =-Infinity; VAR2=-Infinity; VAR1 %= VAR2; VAR1 = undefined 
expected: NaN
FAILED! [reported from top level script] testfunc : Expected value 'NaN', 
Actual value 'undefined'

Does sparc64 have an unusual binary representation of NaN and undefined
or something?

John Paul Adrian Glaubitz asked me to mark sparc64 as one of the
architectures where build-time test failures are ignored, which I will do
when I have a bug number for this that I can refer to.

smcv

Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults

[Simon McVittie]

Source: mozjs52
Version: 52.3.1-7
Severity: normal

mozjs52 runs a smoke-test on the js sample interpreter (which is no longer
installed, but is still built) to check whether the built binaries are
in any way functional. On sparc64, the answer is that they are not:

>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> SRCDIR=/<>/js/src DEB_HOST_ARCH=sparc64 
> /<>/debian/test.sh
> Segmentation fault
> Smoke-test failed: did interpreter initialization fail? (see #873778)
> debian/rules:99: recipe for target 'override_dh_auto_test' failed

The failing command is:

"$SRCDIR/js/src/js" -e 'print("Hello, world")'

so this probably indicates that sparc64 builds of mozjs are unable to
interpret JavaScript at all.

This appears to be a regression since mozjs24, which passed at least some
of its build-time tests on sparc64. Maybe mozjs52 is making assumptions
about the layout of virtual memory that are not true on sparc64?

If there are patches for sparc64 in firefox-esr or in upstream Firefox,
they are probably also applicable to mozjs52.

Regards,
smcv

Bug#884951: glib2.0: FTBFS on sparc64 landau.east.ru: gio/tests/network-address.c:212

[Simon McVittie]

Source: glib2.0
Version: 2.54.2-4
Severity: important
X-Debbugs-Cc: debian-sparc@lists.debian.org

Some but not all glib2.0 builds on sparc64 fail with:

GLib-GIO:ERROR:../../../../../gio/tests/network-address.c:212:test_resolve_address_gresolver:
 'test->valid_resolve' should be FALSE

which means that g_resolver_lookup_by_name() failed for address_tests[2],
which expected to pass (because of the second TRUE):

  /* GResolver accepts this by ignoring the scope ID. This was not
   * intentional, but it's best to not "fix" it at this point.
   */
  { "fe80::42%1",  TRUE,  TRUE,  FALSE },

These failures seem well-correlated with the build happening on landau.
This might be related to the network interfaces or address families that
are (not) configured on this particular buildd, which presumably differs
from all release architecture buildds in some way.

smcv

Bug#873823: dbus: FTBFS on sparc64: test-dbus-daemon: FATAL-ERROR: timed out

[Simon McVittie]

Source: dbus
Version: 1.11.16+really1.11.16-2
Severity: normal

I recently enabled build-time tests for dbus, having first fixed the
home directory issue that made them fail on all buildds. They pass on
most Linux architectures, but fail on sparc64.

https://buildd.debian.org/status/fetch.php?pkg=dbus&arch=sparc64&ver=1.11.16%2Breally1.11.16-2&stamp=1501416799&raw=0
> ** 
> (/<>/dbus-1.11.16+really1.11.16/debian/build-debug/test/.libs/test-dbus-daemon:7617):
>  ERROR **: timed out

This test times out after 60 seconds:

>   /* Prevent tests from hanging forever. This is intended to be long enough
>* that any reasonable regression test on any reasonable hardware would
>* have finished. */
> #define TIMEOUT 60
— test/test-utils-glib.c

I think the timeout is during the /echo/limited test-case, which severely
cuts down the number of messages that the dbus-daemon is willing to keep
in-flight at a time, cutting throughput from 250 to 200 messages per
second. This seems really slow: on my 5 year old x86-64 laptop I get
more than 20 times that throughput.

If sparc64 is really that slow, it's just an arbitrary timeout and could
be increased (the only purpose is to make each test take a finite time
to fail if something gets wedged). Is it?

(X-Debbugs-Cc to debian-sparc)

S

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

[Simon McVittie]

On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
> For the time being, Firefox upstream is now using the arm64 workaround on 
> sparc64
> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
> version 53.

Can you point those interested in this bug to a patch/commit/something that
describes "the arm64 workaround"? Is it related to #839050?

S

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

[Simon McVittie]

Control: retitle 827815 libmozjs-24-0: initialization segfaults on sparc64
Control: user debian-sparc@lists.debian.org
Control: usertags 827815 + sparc64

This is easy to reproduce on the sparc64 porterbox, with or without gjs.
Possibly related to 
since standalone mozjs (SpiderMonkey) is essentially a fork of the Firefox
JavaScript engine.

Sample backtraces below. The expected result of running either js24 or
gjs-console is an interactive prompt at which you can type
print("hello, world!") and get "hello, world!" printed in response.

mozjs24 currently ignores errors during "make check" because not all
tests are reliable, but it would be great if it tried something simpler
like

js24 -e 'print("hello, world!")'

and made the package FTBFS if that didn't work - that would avoid dependent
packages like gjs being built, but actually being unusable, on sparc64.

Regards,
S



With libmozjs-24-bin, libmozjs-24-bin-dbg and libmozjs-24-0-dbg:
> smcv@notker ~ % gdb js24
> ...
> (gdb) run
> Starting program: /usr/bin/js24 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
> [New Thread 0x800101889910 (LWP 250203)]
> [New Thread 0x800102089910 (LWP 250204)]
> 
> Thread 1 "js24" received signal SIGSEGV, Segmentation fault.
> js::ObjectImpl::setFlag (this=this@entry=0x102306040, cx=cx@entry=0x53e610, 
> flag_=flag_@entry=8, 
> generateShape=generateShape@entry=js::ObjectImpl::GENERATE_SHAPE)
> at ./js/src/vm/Shape.cpp:1116
> 1116  ./js/src/vm/Shape.cpp: No such file or directory.
> (gdb) set pagination off
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x800102089910 (LWP 250204)):
> #0  0x8001001365a4 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib/sparc64-linux-gnu/libpthread.so.0
> #1  0x80010047e5d8 in PR_WaitCondVar () from 
> /usr/lib/sparc64-linux-gnu/libnspr4.so
> #2  0x002d9150 in js::SourceCompressorThread::threadLoop 
> (this=0x521940) at ./js/src/jsscript.cpp:1094
> #3  js::SourceCompressorThread::compressorThread (arg=0x521940) at 
> ./js/src/jsscript.cpp:965
> #4  0x800100484620 in ?? () from /usr/lib/sparc64-linux-gnu/libnspr4.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 2 (Thread 0x800101889910 (LWP 250203)):
> #0  0x8001001365a4 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib/sparc64-linux-gnu/libpthread.so.0
> #1  0x80010047e5d8 in PR_WaitCondVar () from 
> /usr/lib/sparc64-linux-gnu/libnspr4.so
> #2  0x0025d9a4 in js::GCHelperThread::threadLoop (this=0x521868) at 
> ./js/src/jsgc.cpp:2266
> #3  0x800100484620 in ?? () from /usr/lib/sparc64-linux-gnu/libnspr4.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 1 (Thread 0x800100030f60 (LWP 250200)):
> #0  js::ObjectImpl::setFlag (this=this@entry=0x102306040, 
> cx=cx@entry=0x53e610, flag_=flag_@entry=8, 
> generateShape=generateShape@entry=js::ObjectImpl::GENERATE_SHAPE) at 
> ./js/src/vm/Shape.cpp:1116
> #1  0x00276b94 in JSObject::setDelegate (cx=0x53e610, this= out>) at ./jsobjinlines.h:782
> #2  JSCompartment::getNewType (this=0x53efd0, cx=cx@entry=0x53e610, 
> clasp=clasp@entry=0x4f2e10 , proto_=..., 
> fun_=fun_@entry=0x0) at ./js/src/jsinfer.cpp:6073
> #3  0x00277020 in JSObject::getNewType (this=0x102306040, 
> cx=cx@entry=0x53e610, clasp=clasp@entry=0x4f2e10 , 
> fun=fun@entry=0x0) at ./js/src/jsinfer.cpp:6134
> #4  0x0029f938 in js::NewObjectWithClassProtoCommon (cx=0x53e610, 
> clasp=0x4f2e10 , protoArg=, 
> parentArg=0x800102305020, allocKind=, newKind= out>) at ./js/src/jsobj.cpp:1383
> #5  0x0029fbc4 in js::NewObjectWithClassProtoCommon 
> (cx=cx@entry=0x53e610, clasp=0x7feec60, protoArg=0x7feec70, 
> protoArg@entry=0x0, parentArg=0x170338  int, JS::Value*)>, 
> allocKind=allocKind@entry=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
> newKind=newKind@entry=js::SingletonObject) at ./js/src/jsobj.cpp:1343
> #6  0x002506b8 in js::NewObjectWithClassProto 
> (newKind=js::SingletonObject, allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
> parent=, proto=0x0, clasp=0x4f2e10 , 
> cx=0x53e610) at ./jsobjinlines.h:1493
> #7  js::NewFunction (newKind=js::SingletonObject, 
> allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, atom=..., parent=..., 
> flags=, nargs=0, native=0x170338  unsigned int, JS::Value*)>, funobjArg=..., cx=0x53e610) at 
> ./js/src/jsfun.cpp:1561
> #8  js::DefineFunction (cx=cx@entry=0x53e610, obj=..., id=..., 
> native=0x170338 , 
> nargs=, flags=0, flags@entry=512, 
> allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, newKind=js::GenericObject) at 
> ./js/src/jsfun.cpp:1688
> #9  0x001fc2a4 in JS_DefineFunctions (cx=cx@entry=0x53e610, 
> objArg=, fs=0x4e6aa8 ) at 
> ./js/src/jsapi.cpp:4902
> #10 0x001389f4 in js::DefinePropertiesAndBrand (fs=, 
> ps=0x0, obj_=, cx=0x5

Re: Bug#827815: ostree: FTBFS on sparc64: gjs: Segmentation fault

[Simon McVittie]

Control: reassign 827815 libmozjs-24-0 24.2.0-3
Control: affects 827815 gjs
Control: reassign 826858 ostree 2016.5-3
Control: affects 826858 - gjs

On Wed, 06 Jul 2016 at 20:58:08 +0100, Simon McVittie wrote:
> > This one is a segfault in gjs

Oops, wrong clone. #826858 is an unreproducible failure on i386 and
hppa, #827815 is the mozjs/gjs segfault.

S

Re: Bug#826858: ostree: FTBFS on sparc64: gjs: Segmentation fault

[Simon McVittie]

Control: reassign 826858 libmozjs-24-0 24.2.0-3
Control: affects 826858 gjs

On Thu, 09 Jun 2016 at 19:28:37 +0100, Simon McVittie wrote:
> On Thu, 09 Jun 2016 at 10:35:48 -0400, Aaron M. Ucko wrote:
> > - On sparc64 (not a release architecture either):
> > 
> >   ERROR: tests/test-pull-corruption.sh - too few tests run (expected 2, got 
> > 0)
> >   ERROR: tests/test-pull-corruption.sh - exited with status 1
> 
> This one is a segfault in gjs, a JavaScript environment using Mozilla
> code for the interpreter and GObject-Introspection for runtime libraries.
> OSTree uses it as a scripting language in some tests, to confirm that
> its language bindings work.
> 
> It seems likely that this one is a sparc64 bug in either libmozjs,
> gjs, GObject-Introspection, or possibly libffi (used by GObject).

I've tried gjs on notker.debian.net, and it looks as though it just
doesn't work at all on sparc64. The backtrace looks more like a mozjs24
rather than gjs issue.

Steps to reproduce:
* install gjs/unstable on sparc64
* run gjs-console

Expected result:
* a "gjs>" REPL prompt at which you can type JavaScript

Actual result:
* segmentation fault

Backtrace below.

Regards,
S

(gdb) set pagination off
(gdb) bt full
#0  js::ObjectImpl::setFlag (this=this@entry=0x107706040, cx=cx@entry=0x246e90, 
flag_=flag_@entry=8, 
generateShape=generateShape@entry=js::ObjectImpl::GENERATE_SHAPE) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/vm/Shape.cpp:1116
flag = js::BaseShape::DELEGATE
self = 
#1  0x8001028e2fb8 in JSObject::setDelegate (cx=0x246e90, this=) at ./jsobjinlines.h:782
No locals.
#2  JSCompartment::getNewType (this=0x247910, cx=cx@entry=0x246e90, 
clasp=clasp@entry=0x800102b1d300 , proto_=..., 
fun_=fun_@entry=0x0) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsinfer.cpp:6073
p = { 
const, js::HashSet, 
js::types::TypeObjectEntry, js::SystemAllocPolicy>::SetOps, 
js::SystemAllocPolicy>::Ptr> = {entry_ = }, keyHash = 
1476233512, mutationCount = {}}
proto = {> = 
{ >> = {}, }, ptr = {proto = 0x107706040}}
fun = {> = {}, ptr = 0x0}
markUnknown = 
type = {> = {}, 
ptr = 0x17}
enter = {suppressGC = {suppressGC_ = @0x800102b1d300}, freeOp = 
0x107706040, compartment = 0x1, oldActiveAnalysis = false}
#3  0x8001028e3448 in JSObject::getNewType (this=0x107706040, 
cx=cx@entry=0x246e90, clasp=clasp@entry=0x800102b1d300 
, fun=fun@entry=0x0) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsinfer.cpp:6134
No locals.
#4  0x80010290c024 in js::NewObjectWithClassProtoCommon (cx=0x246e90, 
clasp=0x800102b1d300 , protoArg=, 
parentArg=0x800107705020, allocKind=, newKind=) at /build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsobj.cpp:1383
cache = @0x228f18: {static MAX_OBJ_SIZE = 160, entries = {{clasp = 0x0, 
key = 0x0, kind = js::gc::FINALIZE_OBJECT0, nbytes = 0, templateObject = '\000' 
} }}
entry = -1
parent = {> = {}, ptr = 
0x800107705020}
proto = {> = {}, ptr = 
0x107706040}
type = 
obj = 
#5  0x80010290c2a0 in js::NewObjectWithClassProtoCommon 
(cx=cx@entry=0x246e90, clasp=0x7fee880, protoArg=0x7fee890, 
protoArg@entry=0x0, parentArg=0x8001027e14d4 , 
allocKind=allocKind@entry=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
newKind=newKind@entry=js::SingletonObject) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsobj.cpp:1343
No locals.
#6  0x8001028c19bc in js::NewObjectWithClassProto 
(newKind=js::SingletonObject, allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
parent=, proto=0x0, clasp=0x800102b1d300 
, cx=0x246e90) at ./jsobjinlines.h:1493
No locals.
#7  js::NewFunction (newKind=js::SingletonObject, 
allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, atom=..., parent=..., 
flags=, nargs=0, native=0x8001027e14d4 
, funobjArg=..., 
cx=0x246e90) at /build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsfun.cpp:1560
funobj = {> = {}, ptr = 0x0}
#8  js::DefineFunction (cx=cx@entry=0x246e90, obj=..., id=..., 
native=0x8001027e14d4 , 
nargs=, flags=0, flags@entry=512, 
allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, newKind=js::GenericObject) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsfun.cpp:1688
gop = 0x800102861a90 , JS::Handle, JS::MutableHandle)>
sop = 0x800102861a98 , JS::Handle, int, JS::MutableHandle)>
fun = {> = {}, ptr = 0x0}
funVal = {> = 
{ >> = 
{ >> = 
{ >> = {}, }, }, }, ptr = {data = {asBits = 0, 
debugView = {tag = 0, payload47 = 0}, s = {padding = 0, payload = {i32 = 0, u32 
= 0, why = JS_ELEMENTS_HOLE}}, asDouble = 0, asPtr = 0x0, asWord = 0, asUIntPtr 
= 0}}}
#9  0x80010286e238 in JS_DefineFunctions (cx=cx@entry=0x246e90, 
objArg=, fs=0x800102b0ec40 ) at 
/build/mozjs24-t3hfaL/mozjs24-24.2.0/js/src/jsapi.cpp:4902
  

Bug#709781: libglib2.0-0: g_date_time_new_from_timeval_utc() fails on sparc

[Simon McVittie]

Package: libglib2.0-0
Version: 2.36.1-2build1
Severity: important

While investigating a FTBFS of telepathy-glib on sparc
(), I tracked the
problem down to GDateTime creation failing.

On i386 and amd64, the attached test program outputs:

> ** Message: in: 1369481139.090801
> ** Message: GTimeVal iso : 2013-05-25T11:25:39.090801Z
> ** Message: GDateTime iso: 2013-05-25 11:25:39
> ** Message: out: 1369481139.090801

On sparc, it fails:

> ** Message: in: 1369481139.090801
> **
> ERROR:datetime.c:11:main: assertion failed: (dt != NULL)
> Aborted

(The original test in telepathy-glib used "the time now" and so was
non-deterministic, but this test uses a hard-coded GTimeVal so
it should be deterministic.)

Breaking on the internal function g_date_time_from_instant (which requires
libglib2.0-0-dbg) yields this on amd64:

> g_date_time_from_instant (tz=tz@entry=0x602040, instant=63505164339090801)

(and repeating the "instant" calculation with arbitrary-precision arithmetic
in Python produces the same thing) but on sparc, instant appears to be
mis-computed for some reason:

> g_date_time_from_instant (tz=0xd71c, instant=137439021280)

This is causing telepathy-glib to FTBFS with a test failure. The GDateTime
tests in GLib also failed on sparc, but for some reason the failure is
ignored (I'm not sure whether that's deliberate or accidental).

I'll set this particular telepathy-glib test to be skipped on sparc for now.

Tested on the porterbox smetana.debian.org; the package versions below are
from there.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: sparc

Kernel: Linux 2.6.32-5-sparc64-smp (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libglib2.0-0 depends on:
ii  libc6  2.17-3
ii  libffi63.0.13-4
ii  libpcre3   1:8.31-2
ii  libselinux12.1.13-2
ii  multiarch-support  2.13-38
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.36.1-2build1
ii  shared-mime-info  1.0-1+b1

libglib2.0-0 suggests no packages.

-- no debconf information
/* gcc `pkg-config --cflags --libs glib-2.0` datetime.c */

#include 

int
main (int argc, char **argv)
{
	GTimeVal tv = { 1369481139L, 90801L };
	GDateTime *dt;
	
	g_message ("in: %ld.%06ld", tv.tv_sec, tv.tv_usec);
	dt = g_date_time_new_from_timeval_utc (&tv);
	g_assert (dt != NULL);
	/* yes I know this leaks memory */
	g_message ("GTimeVal iso : %s", g_time_val_to_iso8601 (&tv));
	g_message ("GDateTime iso: %s", g_date_time_format (dt, "%Y-%m-%d %H:%M:%S"));
	if (!g_date_time_to_timeval (dt, &tv))
		g_message ("out of range for a timeval apparently");
	else
		g_message ("out: %ld.%06ld", tv.tv_sec, tv.tv_usec);
	return 0;
}