Re: Help testing full end-to-end xattr support in portage

On 07/03/14 06:43, Anthony G. Basile wrote:
> On 07/02/14 09:41, Luis Ressel wrote:
>> On Sat, 28 Jun 2014 07:47:26 -0400
>> "Anthony G. Basile" <[email protected]> wrote:
>>
>>> There are two advantages to paxctl over paxctl-ng from elfix: 1) It
>>> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
>>> It does try to convert or create a PT_PAX_FLAGS phdr by either
>>> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
>>>
>>> The advantage of paxctl-ng over paxctl is 1) it is designed to do
>>> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
>>> to not try to create/convert ELF phdr's.
>>>
>>> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
>>> would no longer be needed and paxctl-ng can be reduced to just doing
>>> XATTR_PAX markings.
>>>
>>> One step at a time ;)
>>
>> Okay, that sounds reasonable. And as paxctl is a small program, it
>> doesn't hurt to have it around on XATTR_PAX-only systems even though
>> it's not needed.
>>
>> But there's still an issue. According to [1], 15 packages still depend
>> on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
>> pax markings at one point right in the middle of the build process and
>> therefore can't use the pax eclass, at least not in a simple way. This
>> doesn't work on systems like mine which don't respect PT_PAX flags.
>>
>> I'm currently working on a patch for sbcl (there are selinux-related
>> issues as well), but please have a look at the other ebuilds.
>>
>> [1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P
>> 'paxctl(?!-ng)'|cut -d: -f1
>>
>>
>> Regards,
>> Luis Ressel
>>
>
> Yep open a tracker bug for packages that invoke paxctl directly, and
> attach that to the main tracker bug, bug #427888.
>

Actually I'll do it.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197