| Summary: | =media-libs/libmtp-1.0.4: fails with sandbox violations (gnustep, java) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sergey Ilinykh <rion4ik> |
| Component: | [OLD] Library | Assignee: | Kenneth Prugh (RETIRED) <ken69267> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | david+gentoo.org, fabian.kislat, m27315, sound |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Patch that should fix sandbox violations libmtp-1.1.0 (and potentially earlier versions) | ||
|
Description
Sergey Ilinykh
2011-01-10 11:56:02 UTC
OK, this is not related to GNUstep. See bug 351327. It's definately a problem in libmtp's end. *** Bug 351327 has been marked as a duplicate of this bug. *** FEATURES="-userpriv -sandbox" emerge libmtp Hmm I can't seem to reproduce this issue locally with sandbox and friends enabled. I had the same problem as in bug 351327 (the duplicate of this bug), and it turned out I had some cruft environment variables regarding Blackdown-java (I had it installed once, but switched to Sun-java years ago). Removing /etc/env.d/20java solved my problem. I guess it was a leftover from the old java-config. It had only Blackdown entries, nothing Sun. @Rene - Based on your tip, I was able to fix my problem too. Apparently, my java config was pretty corrupted too. Unfortunately, removing the one file did not help, even after rebooting. Here's what I did: # rm -rf /etc/env.d/20java # grep -Ri blackdown /etc (to find all references to blackdown) # (manually edited all files and removed blackdown)... # vi /etc/java-config-2/build/jdk.conf # vi /etc/profile.csh # vi /etc/portage/package.license # vi /etc/csh.env # vi /etc/profile.env # vi /etc/ld.so.conf # eselect java-vm list # (ensured that a valid vm was used for system-vm) # cd /usr/lib/jvm/ # (manually removed all references to bogus Java VM's, which were breaking eselect java-vm list). # unlink java-gcj # unlink jre # unlink jre-1.4.2 # unlink jre-gcj # unlink java-1.4.2 # unlink java # unlink java-1.4.2-gcj # unlink jre-1.4.2-gcj # unlink java-1.4.2-gcj-1.4.2.0 # rm -rf /opt/java-1.4.2-gcj-1.4.2.0 (deleted old cruft) # mv /etc/alternatives/ /root/alternatives.bk # (don't know what this did, but it had lots of bogus links, so I chunked it) # reboot Take this with a huge grain of salt. There's no telling what havoc I have wreaked upon my system. So, use at your own risk, but at least I can compile libmtp now! WooHoo! :D Please reopen if this persists in 1.0.6 still does funky stuff with other packages. 1.0.6 -> 1.10.0 fail. [...] checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 ACCESS DENIED mkdir: /opt/eagle-5.9.0 mkdir: cannot create directory `/opt/eagle-5.9.0': Permission denied ACCESS DENIED mkdir: /opt/eagle-5.9.0 mkdir: cannot create directory `/opt/eagle-5.9.0': Permission denied mkdir: cannot create directory `/opt/eagle-5.9.0/bin': No such file or directory checking for uint8_t in stdint.h... yes checking whether byte ordering is bigendian... no checking for le32toh in machine/endian.h... no checking for ntohl in arpa/inet.h... yes checking for swap32 in machine/endian.h... no checking for bswap_32 in byteswap.h... yes configure: creating ./config.status config.status: creating src/libmtp.h [...] eagle was installed some time in the past hasn't been in a long time. there was a leftover file in /etc/env.d. the root bug in the libmtp ebuild is not fixed as searching through bugzilla yields a few similar results with different packages. something in the build is still trying to do things in other directories. having a clean $ROOTPATH is just hiding the bug until another package gets unmerged and leaves something in $ROOTPATH which is coincidentally at the end. editing /etc/profile.env and removing the eagle component from the end of ROOTPATH fixed it adding anything to the end of ROOTPATH that is missing, causes the ebuild to fail, it's irrelevant what the actual directory is, just so long as it is at the end ROOTPATH does not occur anywhere in the libmtp tar.gz file Created attachment 278043 [details, diff]
Patch that should fix sandbox violations libmtp-1.1.0 (and potentially earlier versions)
I still observe the originally reported behaviour with libmtp-1.1.0 The reason for the problem is wrong quoting in lines 13697 and 13865 of the configure script, test ! -d "$ac_dir" && as_dir="$ac_dir"; as_fn_mkdir_p which will essentially create a random directory (wherever $as_dir points at the moment). I firmly believe that what the author wants to achieve is test ! -d "$ac_dir" && (as_dir="$ac_dir"; as_fn_mkdir_p) It can be fixed in the autoconf input files m4/stdint.h and m4/byteorder.h as suggested in the attached patch. |
