| Summary: | app-i18n/fbterm: fix /usr/bin/fbterm file-caps loss | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Casper Ti. Vector <CasperVector> |
| Component: | [OLD] Unspecified | Assignee: | CJK Team <cjk> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | PATCH |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Use fcaps.eclass(5) instead of running setcap(8) directly | ||
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=95a831d738dae3bfb016f4ac2f1e2cb0eeee70b1 Thank you for reporting! |
Created attachment 417566 [details, diff] Use fcaps.eclass(5) instead of running setcap(8) directly Current ebuild directly uses setcap(8) to set up file capability of /usr/bin/fbterm in the src_install() phase, which unfortunately gets lost in later phases. Attached is a patch that use fcaps.eclass(5) instead. On my machine, after the patch is applied, the capability is corrected. P.S. * The `use filecaps || fperms u+s /usr/bin/fbterm' line was added in the hope of keeping maximum backward consistency, but I am still not sure whether this is necessary. * A search in the Portage tree indicates that app-i18n/fbterm is the only ebuild that has the same kind of problem; app-admin/collectd has a commented line that wants to use setcap(8) directly.