Summary: | app-benchmarks/stress-ng-0.05.12 : * ERROR: app-benchmarks/stress-ng-0.05.12::gentoo failed (compile phase): | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Brendan Horan <brendan> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | hardened, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
app-benchmarks:stress-ng-0.05.12:20160204-112646.log
emerge-history.txt environment emerge.info emerge log |
Description
Toralf Förster
2016-02-04 12:01:05 UTC
Created attachment 424598 [details]
app-benchmarks:stress-ng-0.05.12:20160204-112646.log
Created attachment 424600 [details]
emerge-history.txt
Created attachment 424602 [details]
environment
Let me take a look. Looks like something to do with apparmor ------------------------------------------------------------------------------ apparmor_parser -Q usr.bin.pulseaudio.eg -o apparmor-data.bin Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.) AppArmor parser error for usr.bin.pulseaudio.eg in usr.bin.pulseaudio.eg at line 2: Could not open 'tunables/global' ------------------------------------------------------------------------------ Created attachment 424632 [details]
emerge.info
I have been unable to reproduce this in my build testing environment.
I can't reproduce this yet. I see your merge setting "-DHAVE_APPARMOR", not sure where that comes from. Created attachment 424640 [details]
emerge log
attached my merge log
this is looking like an error triggered by the setup of the tinderbox given two advanced users cannot reproduce, and i added it just days ago on the back of my successful testrun I can reproduce this in another chroot image at the hardened server (amd64-gnome-unstable_20160121-220651) but not at the server itself - there it emerges fine. At my hardened desktop it emerges fine too. At another chroot image (amd64-selinux-unstable_20160204-170558) it emerges fine too. So I bet is is a USE-flag combination which triggers the issue. (In reply to Toralf Förster from comment #9) > I can reproduce this in another chroot image at the hardened server > (amd64-gnome-unstable_20160121-220651) but not at the server itself - there > it emerges fine. At my hardened desktop it emerges fine too. > At another chroot image (amd64-selinux-unstable_20160204-170558) it emerges > fine too. > > So I bet is is a USE-flag combination which triggers the issue. So is this really a bug then? If so I am a little confused as to what I need to do. (Maybe :ensure every use flag combo works with my package??) |