Summary: | app-arch/libarchive-3.2.1-r2 fails to build on OS X due to lack of enabled ACL support | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Stuart Shelton <srcshelton> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | np-hardass, srcshelton |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | OS X | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | libarchive-3.2.1-r3.patch |
Description
Stuart Shelton
2016-07-03 16:16:35 UTC
I've already fixed this, didn't I? Recently or some time back? ;) I'm pretty sure I updated my repo this morning - but I'll double check once the lz4 test-suite has completed... Looks like https://github.com/libarchive/libarchive/issues/730 might be to blame. Can you confirm whether cherry-picking https://github.com/libarchive/libarchive/commit/3e66829717c8fde611b2b611497f08a46da40ce7.patch to your /etc/portage/patches fixes this issue? (see https://wiki.gentoo.org/wiki//etc/portage/patches) That patch might work, if it does, I'll put it instead of my ebuild tweak. (In reply to Fabian Groffen from comment #4) > That patch might work, if it does, I'll put it instead of my ebuild tweak. If it does, I'll revbump to -r3 :) Please check it out and let me know. (In reply to Stuart Shelton from comment #2) > Recently or some time back? ;) > > I'm pretty sure I updated my repo this morning - but I'll double check once > the lz4 test-suite has completed... I fixed the wrong ebuild :( (In reply to NP-Hardass from comment #5) > (In reply to Fabian Groffen from comment #4) > > That patch might work, if it does, I'll put it instead of my ebuild tweak. > > If it does, I'll revbump to -r3 :) Please check it out and let me know. I also need elibtoolize for Solaris, can I revbump to -r3 myself? Created attachment 439722 [details, diff] libarchive-3.2.1-r3.patch (In reply to Fabian Groffen from comment #6) > (In reply to Stuart Shelton from comment #2) > > Recently or some time back? ;) > > > > I'm pretty sure I updated my repo this morning - but I'll double check once > > the lz4 test-suite has completed... > > I fixed the wrong ebuild :( > > > (In reply to NP-Hardass from comment #5) > > (In reply to Fabian Groffen from comment #4) > > > That patch might work, if it does, I'll put it instead of my ebuild tweak. > > > > If it does, I'll revbump to -r3 :) Please check it out and let me know. > > I also need elibtoolize for Solaris, can I revbump to -r3 myself? If this looks fine to you, sure, feel free to revbump using that and tack on an ACK/sign-off from me. If not, I'd prefer that you post a patch/diff to have looked over first. This is what you need for Solaris. --- a/app-arch/libarchive/libarchive-3.2.1-r2.ebuild +++ b/app-arch/libarchive/libarchive-3.2.1-r2.ebuild @@ -3,7 +3,7 @@ # $Id$ EAPI=6 -inherit autotools eutils multilib-minimal toolchain-funcs +inherit autotools eutils multilib-minimal toolchain-funcs libtool DESCRIPTION="BSD tar command" HOMEPAGE="http://www.libarchive.org/" @@ -38,6 +38,11 @@ DEPEND="${RDEPEND} PATCHES=( "${FILESDIR}/${P}-fix-tests-gnu99.patch" ) +src_prepare() { + default + elibtoolize # for Solaris sol2_ld linker fix +} + multilib_src_configure() { export ac_cv_header_ext2fs_ext2_fs_h=$(usex e2fsprogs) #354923 (In reply to Fabian Groffen from comment #8) > This is what you need for Solaris. > > --- a/app-arch/libarchive/libarchive-3.2.1-r2.ebuild > +++ b/app-arch/libarchive/libarchive-3.2.1-r2.ebuild > @@ -3,7 +3,7 @@ > # $Id$ > > EAPI=6 > -inherit autotools eutils multilib-minimal toolchain-funcs > +inherit autotools eutils multilib-minimal toolchain-funcs libtool > > DESCRIPTION="BSD tar command" > HOMEPAGE="http://www.libarchive.org/" > @@ -38,6 +38,11 @@ DEPEND="${RDEPEND} > > PATCHES=( "${FILESDIR}/${P}-fix-tests-gnu99.patch" ) > > +src_prepare() { > + default > + elibtoolize # for Solaris sol2_ld linker fix > +} > + > multilib_src_configure() { > export ac_cv_header_ext2fs_ext2_fs_h=$(usex e2fsprogs) #354923 eautoreconf calls elibtoolize, so I think that would be a little more versatile, particularly if a user needs to patch the build system (or we add a patch that patches the build system in the future). I presume that satisfies your need for Solaris? The -r3 I posted does that plus cherry picked the upstream OSX ACL patch (still waiting on your confirmation that that patch resolves the build issue) Yes the patch fixes the problem. I don't want the autoconf dependency, neither wait for it. It's a matter of taste, but elibtoolize was created for exactly this reason. I don't buy your user argument, it means you'd want eapply_user to take care of it automagically, in which case elibtoolize would do the right thing (nothing, because eautoreconf leaves the .elibtoolized marker). Either way, it's not a big deal, as long as it's in, it works. (In reply to Fabian Groffen from comment #10) > Yes the patch fixes the problem. > > I don't want the autoconf dependency, neither wait for it. It's a matter of > taste, but elibtoolize was created for exactly this reason. > > I don't buy your user argument, it means you'd want eapply_user to take care > of it automagically, in which case elibtoolize would do the right thing > (nothing, because eautoreconf leaves the .elibtoolized marker). > > Either way, it's not a big deal, as long as it's in, it works. I figured since we had patches in 3.1.2 which required eautoreconf, there was no harm in keeping the autotools dep. I just would rather avoid removing and readding it with relative frequency. I have no problem dropping it, so long as we don't end up having to readd it 1 patch down the line. Fix is in -r3. Went with eautoreconf over raw elibtoolize (turns out I need eautoreconf for another patch anyway, so worked out) |