Created attachment 536774 [details, diff] Proposed ebuild patch for sys-apps/elfix The <attr/xattr.h> include in sys-apps/attr-2.4.48 stopped defining ENOATTR, causing compilation of paxctl-ng.c to fail. As a matter of fact, the entire include is now devoid of content, and instead includes <sys/xattr.h> instead, warning users to include <sys/xattr.h> directly instead of using the <attr/xattr.h> include. With that said, <attr/xattr.h> does not define ENOATTR either. Instead, it becomes necessary to also include <attr/attributes.h>. Proposed patch attached.
I meant that <sys/xattr.h> does not define ENOATTR either. Sorry for the confusion.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67bcfc713c045e2205f7fb3015566f213c623814 commit 67bcfc713c045e2205f7fb3015566f213c623814 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2018-06-22 13:37:06 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-06-22 13:37:25 +0000 sys-apps/attr: Revbump to also define ENOATTR in xattr.h shim file. Bug: https://bugs.gentoo.org/658744 Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-apps/attr/{attr-2.4.48-r1.ebuild => attr-2.4.48-r2.ebuild} | 0 sys-apps/attr/files/xattr-shim.h | 3 +++ 2 files changed, 3 insertions(+)
Please try =sys-apps/attr-2.4.48-r2 and report back your results.
I just tried sys-apps/attr-2.4.48-r2 from the portage tree's git master. Works fine now. Note: Seems the Manifest for sys-apps/attr needs updating, but I don't know if that's expected since I don't usually try ebuilds fresh off of the git tree.
this is a bug in elfix, but Lars already fixed it in git. just needs a new release. https://gitweb.gentoo.org/proj/elfix.git/commit/?id=98fe2e47609a1d1e0830aff457743d23d650f0b1
(In reply to SpanKY from comment #5) > this is a bug in elfix, but Lars already fixed it in git. just needs a new > release. > > https://gitweb.gentoo.org/proj/elfix.git/commit/ > ?id=98fe2e47609a1d1e0830aff457743d23d650f0b1 that link is broken.
Anthony, any chance we can get a new release rolled so this bug can be closed?
(In reply to Lars Wendler (Polynomial-C) from comment #7) > Anthony, any chance we can get a new release rolled so this bug can be > closed? I cut a new release just a few days ago to address a couple of problems. So yes, its ready for stabilization. See bug #684380
Actually it should be okay to close this since the fix is in upstream and just awaiting stabilization.
