bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hurd-amd64] ibus test failures


From: Diego Nieto Cid
Subject: Re: [hurd-amd64] ibus test failures
Date: Mon, 30 Dec 2024 00:35:00 +0000

On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +0000, a ecrit:
> >     (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a 
> > credentials
> >     struct of 84 bytes but got 88 bytes of data
> > 
> > which I traced to the GIO function g_unix_credentials_message_deserialize 
> > (which
> > can be seen here[1]).
> > [1] 
> > https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
> > 
> > It seems to be some structure size issue on amd64 (i386 tests don't fail) 
> > regarding
> > SCM_CREDS implementation.
> 
> See the error test, it's about G_CREDENTIALS_NATIVE_SIZE, see its
> definition:
> 
> #define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct cmsgcred))
> 
> And the definition of struct cmsgcred in bits/socket.h
> 
> I guess on amd64 the struct size somehow gets rounded up to 88 bytes,
> but I don't see why.
> Possibly it's the position of cmcred_groups that gets aligned, but I
> don't see why. At least the sender and the receiver don't seem to agree
> on the shape of struct cmsgcred.

I'll try to investigate. It's indeed weird that the sizes don't match as
both sender (test?) and receiver (ibus-daemon?) run on the same machine
and are compiled with the same headers :/

> 
> > Two patches to the test runner needs to be applied for hurd-amd64[2]:
> > 
> >   * add t64 suffix to libgtk-3-0 directory where the query immodules binary 
> > is found
> 
> It's not just on hurd-amd64, it's on all Debian ports. I'm not sure gtk
> maintainers are really aware that the directory changed, better discuss
> with the Debian maintainer about that.

Ok, I created a MR on salsa to initiate the discussion.

> 
> >   * replace `&> file` redirection to the more standard `> file 2>&1` 
> > understood by dash
> 
> It's not "on GNU Hurd sh points to dash", but on all Debian systems. And
> that should be forwarded to upstream.
>

I opened an issue at ibus upstream on GitHub.


Thanks,
Diego



reply via email to

[Prev in Thread] Current Thread [Next in Thread]