Description of problem: In bug 2183545 we got a request to add cockpit-ostree to RHEL 9/C9S. That needs to talk to rpm-ostree via a private bus connection (which is a rare case). rpm-ostree implements its D-Bus service with gdbus, while cockpit uses libsystemd's sd-bus client library. These two are currently incompatible with private bus connections. This was fixed 4 months ago in upstream glib in [1], and backported to the stable 2.74.7 in [2]. It has been released and tested in Fedora 37 [3] two months ago, and eaven earlier in Fedora 38, with no reported regressions. I also backported the fix to my copr [4] and validated that it works correctly with cockpit-ostree. As the RHEL/CentOS 9 glib version hasn't been updated in over a year (still at 2.68.4), I take it you don't regularly do that. Could you please backport the fix [1] instead? If there are conflicts on applying it, I'm happy to help with backporting and testing it, of course, and attaching the patch here -- but I'd first like to coordinate. Thank you! Version-Release number of selected component (if applicable): glib2 2.68.4-9 How reproducible: Always Steps to Reproduce: Run the cockpit-ostree tests (with the Python bridge, which will land soon). This isn't entirely trivial, but I'm happy to do that for you or walk you through it. Additional info: [1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3272 [2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3300 [3] https://bodhi.fedoraproject.org/updates/FEDORA-2023-1fcb3adca7 [4] https://copr.fedorainfracloud.org/coprs/martinpitt/test-fixes/build/5533842/
> If there are conflicts on applying it, There are not: git checkout 2.68.4 git cherry-pick 8f02681f6e2130c52f27c1edb4febb1443e97d94 works cleanly.
Sure.
Notes for myself, in case I have to re-do it: git clone https://gitlab.gnome.org/GNOME/glib cd glib git submodule update --init --recursive Build glib2 in podman run -it --name c9s -v ./glib/:/glib quay.io/centos/centos:stream9 dnf install 'dnf-command(builddep)' dnf builddep --enablerepo=crb glib2 meson b Prepare the rhel4edge VM with installing cockpit-bridge with pybridge: printf '[Service]\nEnvironment=LD_LIBRARY_PATH=/usr/local/lib64\n' > /etc/systemd/system/rpm-ostreed.service.d/override.conf Iterate with git clean -ffdx; git show 8f02681f6e2130c52f27c1edb4febb1443e97d94 | patch -p0 && podman exec -it c9s sh -ec 'cd /glib; rm -rf b; meson b; nice meson install -C b --destdir i' && rsync -rlvP --delete b/i/usr/local/lib64 c:/usr/local/ && ssh c systemctl stop rpm-ostreed && git reset --hard Initial coarse-grained bisect: * 2.74.4 fails, 2.47.7 works (as expected from https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3300); that's good, it means this is within glib2, and not also in the older libsystemd * 2.68.4 + cherry-pick 8f02681f6e213 fails (should be the same as in the build above, confirming that it was done correctly) * 2.70.5 + cherry-pick 8f02681f6e213 fails * 2.72.4 + cherry-pick 8f02681f6e213 fails * 2.73.3 + cherry-pick 8f02681f6e213 works * 2.73.0 + cherry-pick 8f02681f6e213 fails `git log 2.73.0..2.73.3 gio/gdbusauth.c` has just a handful commits, and there's a high chance that it's related to this bug: * 764f071909: fails * 3f532af65c: fails * e0a0749268: conflicty; but applies after 18886d43d2 and 7d7b52edbda3; however, it doesn't build, and that commit is obviously broken (probably a commit series in a PR which wasn't cleanly separated) * 32b226d1b1: with this additional commit it builds again, but fails 😢 So I started a git bisect between 2.73.0 and 2.73.3 which points to https://gitlab.gnome.org/GNOME/glib/-/commit/3f532af65c9. That is correct in the sense that building 3f532af65c9 works and 3f532af65c9^ fails. But I already tried to cherry-pick that commit above. So again, like the original commit, it seems to be necessary but not sufficient. So I'll dig some more.
Got it: It needs all five of these: https://gitlab.gnome.org/GNOME/glib/-/commit/764f071909df gdbusauth: empty DATA does not need a trailing space https://gitlab.gnome.org/GNOME/glib/-/commit/a7d2e727eefc GDBusServer: If no initial response for EXTERNAL, send a challenge https://gitlab.gnome.org/GNOME/glib/-/commit/b51e3ab09e39 GDBusServer: Accept empty authorization identity for EXTERNAL mechanism https://gitlab.gnome.org/GNOME/glib/-/commit/3f532af65c98 gdbusauth: Represent empty data block as DATA\r\n, with no space https://gitlab.gnome.org/GNOME/glib/-/commit/8f02681f6e21 gdbus: Never buffer reads during server authentication (The last one was the one you already backported). These cherry-pick and build cleanly on top of 2.68.4, and fix sd-bus talking to rpm-ostree. Are these acceptable? Thanks!
(In reply to Martin Pitt from comment #7) > Are these acceptable? Yes. I'll try a new build.