Bug#1119120: mark dconf-cli Multi-Arch: foreign

[Helmut Grohne]

Package: dconf-cli
Version: 0.49.0-1
User: debian-cross at lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cross at lists.debian.org, smcv at debian.org, sune at debian.org
Control: affects -1 + src:gnome-kiosk

Hi,

I was trying to cross build gnome-kiosk and it failed running "dconf 
compile ...". This naturally leads to the question of whether dconf-cli 
should be marked Multi-Arch: foreign or not. As it deals with binary 
data, the answer is not entirely obvious.

TL;DR: Please mark dconf-cli Multi-Arch: foreign. The rest of this mail 
says why.

I raised this question on #debian-devel and Simon and Sune chimed in 
with more background:

| < helmut> would someone happen to know dconf-cli sufficiently well to understand whether it should be m-a:foreign?
| < helmut> a reading of the manual page indicates that it is endianess aware and suggests "yes"
| < smcv> helmut: dconf uses a slightly weird hybrid protocol for read-mostly configuration, where writes (assumed to be rare) go through D-Bus so a centralized service can impose locking/ordering, but reads (assumed to be very frequent) mmap the file
| < smcv> helmut: GVariant (underlying data type) is definitely endianness-sensitive and at least somewhat endianness-aware
| < helmut> smcv: I understand that as "no"
| < helmut> thank you.
| < svuorela> I was told that dconf on-disk format is supposed to be wire compatible with dbus.
| < smcv> helmut: the way to verify would be to write out a non-string property (ca/desrt/dconf-editor window-height is a convenient one, and I think is set automatically when running dconf-editor) and then use a wrong-endianness `dconf dump /` to read it back and check it looks sensible
| < smcv> helmut: dconf-editor:amd64, dconf-service:amd64 and dconf-cli:s390x
| < smcv> helmut: I think it *probably* can be M-A:foreign, because probably its designer did think of this and put an endianness indicator in the file header

I later performed this test in a sid-based debvm (to avoid interfering 
with my host kernel's binfmt stuff). As suggested, I installed 
dconf-editor:amd64, dconf-service:amd64, dconf-cli:s390x, 
openssh-server, qemu-user-binfmt and xauth. Rather than installing an X 
server, I opted for using ssh -X.  I could change the window-height as 
suggested by Simon, but I note that it resets back to its default value 
whenever I close the dconf-editor window. Running "dconf dump 
/ca/desrt/dconf-editor/" (which is an s390x binary running in qemu-user 
emulation via binfmt) readily works and prints the expected 
window-height (i.e. there is no endianess mixup going on here).

| < helmut> man dconf says it's always little endian
| < smcv> strictly speaking that says the output of `dconf compile` is always LE, and says nothing about the format of ~/.config/dconf/user
| < helmut> true. I take that dconf requires more expert knowledge that I have
| < helmut> s/that I have/than I have/
| < smcv> trying a BE dconf-cli on a LE machine is probably quicker than source code inspection~
| < smcv> I'm sure that it uses fixed integer-sizes, so if there is any problem at all, it would be with endianness
| < helmut> well that gives you one axis maybe, but it doesn't help with 32bit vs 64bit and also not with time32 vs time64 and not with exploring all other weird datatype differences that may be relevant
| < smcv> dconf uses GVariant which has no concept of "native machine sized int" or "native machine sized time_t", all types are fixed-size

As Simon points out, the sizes are all fixed, so this is not a source of 
architecture-specific behavior.

| < svuorela> is Allison stil around? Maybe that's also quicker than code inspection.
| < helmut> now that's promising. I'll look into trying that
| < smcv> and sizes encoded internally (string lengths, array lengths, etc) are always LE
| < helmut> mind if I quote you in a bug report?
| < smcv> the only thing that might vary between archs is the endianness of the "payload" data types
| < smcv> svuorela: yes and no. the type system is compatible with D-Bus' type system (it's slightly a superset but I think the superset part is intentionally not used for D-Bus compatibility) but the encoding of abstract types/values into bytes is cleverer/denser/more complicated than D-Bus' wire encoding
| < smcv> e.g. D-Bus string lengths are fixed uint32 in the message endianness, but GVariant string lengths are variable-length and always LE
| < smcv> helmut: fine to quote me on a bug report
| < svuorela> smcv: then maybe my memory is flawed from back in the kde4->5 early phases where the dconf author was at a KDE platform sprint. But that's also long long ago :)
| < smcv> dconf is definitely designed to be D-Bus-friendly, but its on-disk encoding is cleverer than D-Bus' because of reasons. (it was Allison's masters thesis iirc)

So given Simon's and Sune's background combined with my experiments, I 
think we can reasonably say that dconf's behavior does not depend on the 
architecture it is run as (i.e. it is sensible to mark it M-A:foreign).

Please add "Multi-Arch: foreign" to dconf-cli.

Helmut