Pull Request assignment

Submitter: @257
Areas affected: ebuilds
Packages affected: sys-auth/sssd

sys-auth/sssd: @gentoo/base-system, @salahcoronya, @gentoo/proxy-maint

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

Please submit this without a revbump so we can actually review the changes. We can perform the revbump when we merge.

done!

i'm realising maybe chgrps and chmods are not needed. i'm tesing the runtime as we speak...

i'm realising maybe chgrps and chmods are not needed. i'm tesing the runtime as we speak...

Yeah, I was writing a review comment about that. I think the upstream Makefile will take care of that.

i'm realising maybe chgrps and chmods are not needed. i'm tesing the runtime as we speak...

Yeah, I was writing a review comment about that. I think the upstream Makefile will take care of that.

dropped them for now regardless ofthe tests i'm doing here, we can always add them later.

On my test boxes, an extra preservation step isn't needed - portage copies the xattrs from the staging are with the file. Is your /var/tmp/portage on a filesystem that doesn't support xattrs, possibly a network one (like NFS/SMB)?

On my test boxes, an extra preservation step isn't needed - portage copies the xattrs from the staging are with the file. Is your /var/tmp/portage on a filesystem that doesn't support xattrs, possibly a network one (like NFS/SMB)?

Portage does support copying xattrs if ${PORTAGE_TMPDIR} supports them. However, this is not strictly required for all Gentoo systems, and was mainly added to support PaX markings.

Applying the caps via fcaps.eclass in pkg_postinst is the right move here and will ensure consistent results.

On my test boxes, an extra preservation step isn't needed - portage copies the xattrs from the staging are with the file. Is your /var/tmp/portage on a filesystem that doesn't support xattrs, possibly a network one (like NFS/SMB)?

hmm, good point, here is my setup:

🦸 root@osif:sys-auth/sssd findmnt /var/tmp/portage
TARGET           SOURCE FSTYPE OPTIONS
/var/tmp/portage tmpfs  tmpfs  rw,nosuid,nodev,noatime,size=174010304k,uid=11482,gid=11482,inode64,huge=within_size

and we build these images using mkosi, unprivileged.

and kernel seems to be fine:

🦸 root@osif:sys-auth/sssd zgrep CONFIG_TMPFS_XATTR /proc/config.gz
CONFIG_TMPFS_XATTR=y

Perhaps your mkosi build process does not install sys-libs/libcap before sys-auth/sssd gets built? That would cause the setcap binary to be missing and the upstream Makefile would not apply the caps.

Perhaps your mkosi build process does not install sys-libs/libcap before sys-auth/sssd gets built? That would cause the setcap binary to be missing and the upstream Makefile would not apply the caps.

Nevermind, I see it is listed in both BDEPEND and DEPEND.

Perhaps your mkosi build process does not install sys-libs/libcap before sys-auth/sssd gets built? That would cause the setcap binary to be missing and the upstream Makefile would not apply the caps.

good call but i don't think so, here are the logs

Perhaps your mkosi build process does not install sys-libs/libcap before sys-auth/sssd gets built? That would cause the setcap binary to be missing and the upstream Makefile would not apply the caps.

good call but i don't think so, here are the logs

you're right actually, that libcap is going into --root=; i.e. /buildroot.

i see sys-libs/libcap declared in DEPEND, does it need to go into BDEPEND?

i see sys-libs/libcap declared in DEPEND, does it need to go into BDEPEND?

never mind, it is declared in BDEPENDS! so i don't know :)

hmm, sys-libs/libcap is merged into the /, that is the root tree (an updated stage3) where we invoke emerge with --root=/buildroot.
in fact we can artificially make mkosi drop us into a shell there and we have:

‣ "emerge --noreplace --verbose --quiet-fail=n --root=/buildroot @encs1" returned non-zero exit code 1.
‣ Sandbox command: mkosi-sandbox --bind /proc /proc --unsetenv TMPDIR --setenv SYSTEMD_OFFLINE 1 --bind
...
osif / # which setcap
/usr/bin/setcap

LGTM

for the record, caps and group ownerships are lost because of id/gid mapping in non-root builds, as mentioned here.

systemd-nsresourced.service(8) seems to be upstream's solution; we're testing atm.

however, that requires at least systemd-260 with USE=bpf and BTF (CONFIG_DEBUG_INFO_BTF=y).

i expect systemd-260 to take a year to stabalise so indeed LGTM.

Pull request CI report

Report generated at: 2026-03-24 18:22 UTC
Newest commit scanned: 5fb99d4
Status: ❌ broken

New issues caused by PR:
https://qa-reports.gentoo.org/output/gentoo-ci/b7e6c4f/output.html#media-libs/opencv
https://qa-reports.gentoo.org/output/gentoo-ci/b7e6c4f/output.html#sys-apps/util-linux

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/b7e6c4f/output.html

hmm, i don't see what checks failed; i think i don't have the permissions to view those(?)

hmm, i don't see what checks failed; i think i don't have the permissions to view those(?)

Ignore that, the bot is blaming you for unrelated changes.