The most recent change due to bug 531350 introduced breakage with pax kernels: When apulse is set, the binary is renamed and replaced by a wrapper script. The subsequent pax-mark then only marks the wrapper script instead of the binary which is false. BTW: When you are fixing this, perhaps you can also pass arguments through the wrapper script (IIRC, for some debugging situations, arguments are needed): exec i686-pc-linux-gnu-apulse skype-bin "$@"
Created attachment 391206 [details, diff] Marks skype binary instead of wrapper script with USE=apulse. Proposed but untested patch
(In reply to Martin Väth from comment #0) > The most recent change due to bug 531350 introduced breakage with pax > kernels: > > When apulse is set, the binary is renamed and replaced by a wrapper script. > The subsequent pax-mark then only marks the wrapper script instead of the > binary which is false. > > BTW: When you are fixing this, perhaps you can also pass arguments through > the wrapper script (IIRC, for some debugging situations, arguments are > needed): > > exec i686-pc-linux-gnu-apulse skype-bin "$@" Can you please test that Radek Pilar's patch? Thanks Amynka
(In reply to Amy Winston from comment #2) > Can you please test that Radek Pilar's patch? Yep, works (only tested with USE=apulse). Another possibility would have been to just exchange the order (first paxmark, then rename; since I considered this trivial, I did not suggest a patch in the first place), but I guess it is a matter of taste what is considered a less intrusive patch.
(In reply to Martin Väth from comment #3) > Another possibility would have been to just exchange the order (first > paxmark, then rename; [...] This won't work, as (in case of XATTR_PAX) the attributes won't survive copying from S to D.
Radek Pilar's patch added. Thanks for reporting bug. Amynka
(In reply to Martin Väth from comment #0) > exec i686-pc-linux-gnu-apulse skype-bin "$@" This one was missed, of course. That's what happens when you report two different issues in one bug.
(In reply to Ulrich Müller from comment #4) > This won't work, as (in case of XATTR_PAX) the attributes won't survive > copying from S to D. Yeah my bad: I thought that it is renamed in $D and didn't pay attention that it is already installed with newbin. One should think that it should work with FEATURES=xattr nevertheless, but the portage implementation of newbin uses "cp" [even without -p] instead of install-xattr then, anyway; maybe this should be reported as a portage bug? (This is not an attempt to justify my mistake: It is certainly better if things work also with FEATURES=-xattr (and perhaps even coreutils[-xattr]) if possible.) (In reply to Ulrich Müller from comment #6) > > exec i686-pc-linux-gnu-apulse skype-bin "$@" > > This one was missed, of course. That's what happens when you report two > different issues in one bug. I cannot really report a bug for this, since I do not remember the test case where it is needed (it is just from my memory that I needed arguments once in connection with some webcam problem, but this was many years ago, and my memory might be wrong).
(In reply to Martin Väth from comment #7) > One should think that it should work with FEATURES=xattr nevertheless, but > the portage implementation of newbin uses "cp" [even without -p] instead of > install-xattr then, anyway; maybe this should be reported as a portage bug? FEATURES=xattr affects merging from D to ROOT, not installing from S to D. I rather see it as a feature that "doins" etc. install the file with a well defined mode. (If special install functions that preserve attributes were needed, then maybe pax-utils.eclass would be the place for adding them. I doubt that there is much need for such a feature, though.)
(In reply to Ulrich Müller from comment #8) > FEATURES=xattr affects merging from D to ROOT, not installing from S to D. IIRC it also causes install-xattr to be used (or the corresponding python variant, depending on whether portage was emerged with USE=xattr or not). Maybe meanwhile, install-xattr is even put into the path unconditionally? > install the file with a well defined mode. mode != xattr, especially concerning pax markings. > I doubt that there is much need for such a feature, though. install-xattr was even only developed to provide this feature generically; it appears inconsistent to me that portage "forces" it for foreign build system (by putting the modified "install" into PATH) but does not use it for its own ebuild helpers: Thus, "install" inside of a Makefile is handled differently than "doins"