Created attachment 303427 [details] svn diff of simplified ebuild I'm new to this, so any suggestions I propose will definitely need to be checked by someone in-the-know. Looking through bug 278831, it seems that several attempts to avoid user-interaction were attempted, and when a solution was found, the failed attempts weren't reverted. If the attached patch (lsof-prefix-changes-v4.84.patch) is okay, can it be committed and tested? Provided that the cleaner ebuild is acceptable (and works!), the second attached patch (lsof-prefix-changes-to-gx86.patch) might be enough to merge these changes back into mainline Gentoo. Please can this be reviewed too?
Created attachment 303429 [details, diff] Proposed patch
(In reply to comment #1) > Created attachment 303429 [details, diff] [details, diff] > Proposed patch Hate to ask for another patch submission, but don't bother with old versions, only look at the very latest.
Created attachment 303431 [details, diff] Proposed patch (In reply to comment #2) > Hate to ask for another patch submission, but don't bother with old versions, > only look at the very latest. No problem. :) Thanks for the tip.
base-system: I've reviewed the proposed patch for lsof-4.85-r2. LGTM.
Comment on attachment 303431 [details, diff] Proposed patch the patch doesn't make sense. we run Configure with -n which means Customize won't be run. ignoring that, patches don't go in src_unpack ... that's what src_prepare for. if AIX has such a broken `ar`, why don't just `export AR=...` in the profile ?
Created attachment 308521 [details, diff] Updated patch Actually I've been unable to build lsof on AIX since lsof-4.76, and even 4.84 has compiler errors still. But indeed lsof-4.85 does work again on AIX (5.3 at least), without any extra patch.
Comment on attachment 308521 [details, diff] Updated patch for target(), please indent the cases at the same level: case ${CTARGET} in *pattern*) ... esac what's with the -Wl,-bnolibpath flag ?
Created attachment 308751 [details, diff] Updated patch > what's with the -Wl,-bnolibpath flag ? AIX ld adds -L arguments to the runpath, and -bnolibpath avoids that. Actually it is triggered by the QA notice about insecure RUNPATH's (./lib).
(In reply to comment #8) isn't that something you should be adding to the profile then ? i can't see adding this to every ebuild that has -L to local $S paths being a solution.
Created attachment 309911 [details, diff] diff for gx86, containing aixgcc patch as reported upstream (In reply to comment #9) There's no point in having -bnolibpath in general env, as build systems (libtool and others) usually take care of this - even lsof does, but not for gcc yet. Using ${PN}-4.85 for the patchfile in the ebuild is because it applies to lsof-4.86 too. I've reported this aixgcc patch to lsof-maintainer <abe at purdue dot edu> right now (at 2012-04-24 14:03 +0200).
(In reply to comment #10) > I've reported this aixgcc patch to lsof-maintainer <abe at purdue dot edu> > right now (at 2012-04-24 14:03 +0200). Hmm, upstream stopped AIX support with lsof-4.86 (just FreeBSD, Linux, Mac OS/X and Solaris still), and won't accept patches for other platforms at all any more. What to do now?
(In reply to comment #11) can't say i'm keen on maintaining large patches for targets upstream doesn't care about ... maybe if you want to shovel it all into a patch that lsof would download and apply when ${CTARGET} == *aix*, i wouldn't care.
(In reply to comment #12) Basically agreed. However, right now I won't call the patch "large" yet... Still usual for prefix: When a minor platform's patch breaks, comment it out - when I find time to, I'll update and reconsider creating a patch repo. Also, I won't mind to apply it conditionally - as it would be with downloading. However, downloading with $PV would need to update that tarball upon revbump too.
ping apart from AIX issue, is there something that blocks merging patch into lsof ebuild?
Commit message: Update to EAPI=4 and merge some random prefix changes http://sources.gentoo.org/sys-process/lsof/lsof-4.87-r1.ebuild?rev=1.1
can you guys rebase onto 4.89-r1 so we can see what's left ?
It works on Prefix of linux arches. I lost access to aix systems, so cannot test it for ppc-aix.
Until I can recheck if comment#11 still applies: Can we please keep 4.85 in tree for ~ppc-aix only?
4.85 isn't in the tree anymore, and prefix has their own overlay already, so seems like stuffing an old version for one prefix system makes more sense to do in the prefix overlay ?
Yup, no problem, we'll keep 4.85
It's not in the overlay anymore! \o/ (since 2017: https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=99734bd4c071093834c45dba78d3c109598273f9).
