| Summary: | museseq-0.6.2 sandbox access violation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Manfred Stienstra <manfred.stienstra> |
| Component: | Current packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dev-portage, sound |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
The compile process output
Ouput of the installation process |
||
|
Description
Manfred Stienstra
2004-02-27 14:46:24 UTC
hmm... works fine for me... It shouldn't be doing anything with DRI... Is the 0.6.0 ebuild working fine? museseq-0.6.0 gives the same access violation but just after the configure stage. This is what I find in my logs: Feb 29 12:57:57 [devfsd] error calling: "unlink" in "GLOBAL"_ It doesn't only give an access violation, but it screws up my whole DRI. This might be a sandbox problem and not a museseq problem. Can someone familiar with sandbox comment on this... I don't see where the dri access is coming from... chances are the program is trying to run an X related app and as such, wrongly tries to open the display Can you attatch the output of: 'ebuild --verbose --debug museseq-0.6.2 install' after doing the 'ebuild --verbose --debug museseq-0.6.2 compile' Created attachment 27278 [details]
The compile process output
The compiling seems to work, but it stuff borks up my DRI.
Created attachment 27280 [details]
Ouput of the installation process
The installation also works when done with ebuild.
what? That's weird... try emerging it again... I've tried it a few times. A normal emerge doesn't work because of the dri error. The ebuild compile, ebuild install routine works. Ebuild compile does break my dri, but ebuild install installs like it's suppost to. so if you do 'ebuild <ebuild> compile install qmerge' it works, but if you do 'emerge <ebuild>' it fails? That doesn't seem right to me, as it was my understanding that emerge did just that... The dri errors happen at the end of the compile process, and emerge fails on the errors, but when I do a ebuild install after it, it does install. ok... this is a big 'wtf' for me... portage guys: is there any reason why 'ebuild <blah> qmerge' would succeed but 'emerge <blah>' would have sandbox violations? I think I'm rambling too much, but let me explain it again. 1) emerge museseq: fails at the end of the compile process because of the above mentioned dri errors 2) ebuild compile: gives the same errors at the end of the compile When I do either of the two, I can do an ebuild install and that works. Ebuild notices that the program has already been compiled and just installs it. At the end om the compile process attachment you can see the dri errors. http://bugs.gentoo.org/attachment.cgi?id=27278&action=view oh ok, so you ARE still getting the sandbox violations at the end of compile... ok... I'll see what I can gather from that log... ok, this should be fixed now in portage... |
