libadacl.c: In function safe_open: libadacl.c:179:18: error: PATH_MAX undeclared (first use in this function) 179 | char abs_cwd[PATH_MAX]; | ^~~~~~~~ libadacl.c:179:18: note: each undeclared identifier is reported only once for each function it appears in ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl-20200311-204810 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-gentoo-linux-musl-9.2.0 * [2] x86_64-gentoo-linux-musl-9.3.0 clang version 10.0.0 Target: x86_64-gentoo-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.7 [3] python3.6 [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.41.1 [2] rust-1.41.1 * The following VMs are available for generation-2: repository: ==> /var/db/repos/gentoo/metadata/timestamp.chk <== Mon, 16 Mar 2020 04:38:59 +0000 emerge -qpvO sys-apps/apply-default-acl [ebuild N ] sys-apps/apply-default-acl-0.4.2
Created attachment 620346 [details] emerge-info.txt
Created attachment 620348 [details] emerge-history.txt
Created attachment 620350 [details] environment
Created attachment 620352 [details] etc.portage.tbz2
Created attachment 620354 [details] logs.tbz2
Created attachment 620356 [details] sys-apps:apply-default-acl-0.4.2:20200316-052101.log
Created attachment 620358 [details] temp.tbz2
Created attachment 620700 [details, diff] 0001-src-libadacl.c-include-limits.h-for-PATH_MAX.patch Does this patch fix the issue? If so, I'll make a new release. PATH_MAX gets defined incidentally on glibc/linux by way of dirent.h, so I think I was just missing an #include <limits.h>.
(In reply to Michael Orlitzky from comment #8) > Created attachment 620700 [details, diff] [details, diff] > 0001-src-libadacl.c-include-limits.h-for-PATH_MAX.patch > > Does this patch fix the issue? If so, I'll make a new release. > > PATH_MAX gets defined incidentally on glibc/linux by way of dirent.h, so I > think I was just missing an #include <limits.h>. That sounds familiar to me. Seen elsewhere for the same issue.
The first attempt to tinderbox a musl image failed at all. I'll mass close therefore all filed bug reports of the last days related to this tinderbox image. Please feel free to re-open if you think that the bug is real in musl and not fixed by the musl overlay.
This was probably a real bug. I was missing a header that just happens to get included by another header on linux/glibc. I've already committed the fix (to include the header), which I believe is the right thing to do regardless. Can someone check if apply-default-acl builds against musl? If not, I'll make a new release. Otherwise I'll just wait and include the fix in the next version, whenever that is.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6076bef915626b716b5b7f8e832d28b043745f4e commit 6076bef915626b716b5b7f8e832d28b043745f4e Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-05-27 00:38:50 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-05-27 00:39:03 +0000 sys-apps/apply-default-acl: new version 0.4.3. This new version includes a pkg-config file, and some upstream fixes for bugs that were reported on Gentoo. Closes: https://bugs.gentoo.org/712844 Closes: https://bugs.gentoo.org/725536 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sys-apps/apply-default-acl/Manifest | 1 + .../apply-default-acl-0.4.3.ebuild | 26 ++++++++++++++++++++++ 2 files changed, 27 insertions(+)
