Do the COPR environments either support faccessat2 or fail with ENOSYS?
I've been told that we put in a workaround in glibc for the bogus EPERM error from systemd-nspawn specifically to support COPR:
https://bugzilla.redhat.com/show_bug.cgi?id=1869030
And we really need to remove that workaround again because EPERM is an ambiguous error code and applies to situations where we *do not* want to perform the fallback implementation (because it cannot perform permission checks accurately).
Thanks, Florian
Hello Florian, I must confess that this is a too system-level topic for me to comprehend, but I read the BZ 1869030 you linked and I think your question boils down to this?
In summary:
- We need to check with COPR admins to see if their systemd-nspawn is new enough to drop the patch.
At this moment, Copr builders are F32 instances spawned from our snapshot, that was created Sep 18 2020, and therefore contain package versions from that date. We have systemd-container installed in 245.7-1 version but on that system 245.8-2 is available. We can update the snapshot for you, if necessary. In case even newer version is required, please let me know where to get it.
I hope I am not misunderstanding the question completely.
Jakub
On Tue, Oct 20, 2020 at 4:02 PM Florian Weimer fweimer@redhat.com wrote:
Do the COPR environments either support faccessat2 or fail with ENOSYS?
I've been told that we put in a workaround in glibc for the bogus EPERM error from systemd-nspawn specifically to support COPR:
https://bugzilla.redhat.com/show_bug.cgi?id=1869030
And we really need to remove that workaround again because EPERM is an ambiguous error code and applies to situations where we *do not* want to perform the fallback implementation (because it cannot perform permission checks accurately).
Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.o...
* Jakub Kadlcik:
Hello Florian, I must confess that this is a too system-level topic for me to comprehend, but I read the BZ 1869030 you linked and I think your question boils down to this?
In summary:
- We need to check with COPR admins to see if their systemd-nspawn is new enough to drop the patch.
At this moment, Copr builders are F32 instances spawned from our snapshot, that was created Sep 18 2020, and therefore contain package versions from that date. We have systemd-container installed in 245.7-1 version but on that system 245.8-2 is available. We can update the snapshot for you, if necessary. In case even newer version is required, please let me know where to get it.
I hope I am not misunderstanding the question completely.
Sorry for being unclear. I'm glad you could figure out what we needed; the information you provided was very helpful:
Upstream systemd 245.8 lists the faccessat2 commit here:
I don't think this is in 245.7, so you would have to upgrade. Could you do that, please, and tell us afterwards, so that we can proceed to remove the kludge from glibc?
Thanks, Florian
copr-devel@lists.stg.fedorahosted.org