fedora:36 peculiarities
andyholmes opened this issue · comments
In the case there is time/interest in bumping the CI image to fedora:36, it will require a patched GLib to address this issue. Long story short, is that glib-compile-resources will fail until GitHub updates their Docker/libseccomp deployment.
I have a copr setup here that carries such a build of GLib. It could be added to the Dockerfile like so:
FROM registry.fedoraproject.org/fedora:36
# See: https://github.com/andyholmes/copr/tree/main/glib2
RUN dnf install -y 'dnf-command(copr)' && \
dnf copr -y enable andyholmes/main
# Regular stuff here
Fedora 36 isn't even technically in Beta yet. (Been pushed off for two weeks and counting, so far, though it looks like the Big Board has been cleared so this Thursday's third try will probably succeed...)
Since this was patched a month ago I can't imagine it won't make it into the release. I'd be surprised if it's not in the Beta (or I'd expect to see it on the Big Board).
Point is, we can probably solve this by just doing nothing for a few weeks. My favorite kind of fix!
And, indeed, that patch has already been pushed as an update to Fedora 35, even. For Fedora 36+, BNocera dropped it in as a patch around the same time, but it's no longer there since that was four releases ago and the current packages are up to 2.72.0 already which includes the patch upstream.
The Dockerhub definition for fedora:36 was updated end of last week; if this isn't already fixed something's wrong.
Yeah, I'm not sure if they'll forward-port the EPERM patch again. Richard Hughsie had pushed that since he uses GitHub/Circle CI for fwupd, but I get the feeling Fedora doesn't want to carry that patch as it was causing timeouts in the GNOME GitLab CI's.
Sorry, after re-reading your comment I think I didn't explain very well.
Philip Withnall merged this patch late in the 2.70 cycle for seccomp deployments that return EPERM for close_range() rather than ENOSYS, which resulted in dangling file descriptors (causing many problems in GNOME's GitLab runners).
After it became clear this was breaking a lot of GitHub-based CI's, Richard Hughsie added this patch to the Fedora 35 GLib package, which effectively reverts Philip Withnall's upstream patch.
So far, Richard Hughsie's patch has not been applied to Fedora 36's GLib package though, thus bumping the CI image to fedora:36 will break it. I don't get the feeling Fedora plans on carrying Richard's patch again, like they did for Fedora 35.
Ah, OK, thanks. I guess I understand better now why it's needed. Well, no, I understand what it's needed for, but I don't at all understand WHY it's needed. Especially with all of the bugs on this being closed and everyone walking around acting as though this is fixed.
Do the Fedora devs know that they're currently working towards a release that will include tools that fail to run in container environments, in a way that those same tools on F35 (by virtue of that patch) and earlier DON'T? I find it hard to believe that this wouldn't be on the radar as a release blocker, but I can't even find any sign that it's being tracked anywhere (as an ongoing, rather than already-solved, problem, I mean).
Yeah, my understanding of this stuff is pretty limited. My read is that EPERM is supposed to be returned when you try to do some thing seccomp doesn't allow (ie. hard fail). ENOSYS is returned when syscall is not supported (ie. time to fallback to an older syscall).
So I think the fix merged into GLib makes it correctly handle those error codes, but some existing deployments like GitHub's are still returning EPERM when they should be returning ENOSYS. The practical difference is that GNOME can update their Docker/seccomp deployment on gitlab.gnome.org, while we on GitHub are stuck with a Docker/seccomp that is returning the wrong error code.
That's my read on the situation anyways :)
Looks like this made it in afterall, so I'll close this up :)