Summary: | sys-apps/sandbox-1.6-r2: src_test fails when sandbox not already installed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Piro <robert.piro> |
Component: | [OLD] Core system | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The build-log
The environment file testsuite.log |
Description
Robert Piro
2010-02-28 14:22:59 UTC
You need to attach this... /var/tmp/portage/sys-apps/sandbox-1.6-r2/temp/build.log as told by the error message (which you have stripped of all important parts when pasting here) (And when it fails on tests then you need to do USE="-test" FEATURES="-test", not to mess with RESTRICT. (In reply to comment #2) > (And when it fails on tests then you need to do USE="-test" FEATURES="-test", > not to mess with RESTRICT. > The FEATURES="-test" command did the trick. However, I consider this bug not as resolved, as it is not clear why it happened. As soon as I have glibc recompiled, I shall recompile sandbox again and I shall post the build log. It would be good, if there would be fields in the bug-report form that encourage to post all that stuff. Where do I report this request to? Anyway. Thank you for your quick answer. (In reply to comment #3) > It would be good, if there would be fields in the bug-report form that > encourage to post all that stuff. Where do I report this request to? Well, please read the *entire* message that you get on failed emerge. It does encourage you to post that stuff and even point to exact locations of the files in question. You have just snipped it, as already noted. Sure, the failing test are not resolved :) I have read the entire message. In many cases build-logs are not included and I presumed (wrongly) that someone would have immediately a clue. Nevertheless, there are no fields in the bug report where build-logs and other lengthy system messages are orderly entered and stored.
Back to the important stuff. I had to uninstall sandbox before getting the error-message again.
> (In reply to comment #3)
> > It would be good, if there would be fields in the bug-report form that
> > encourage to post all that stuff. Where do I report this request to?
>
> Well, please read the *entire* message that you get on failed emerge. It does
> encourage you to post that stuff and even point to exact locations of the files
> in question. You have just snipped it, as already noted.
>
> Sure, the failing test are not resolved :)
>
Created attachment 221877 [details]
The build-log
Created attachment 221879 [details]
The environment file
So it mentions something about makedir. There is enough space... no reason to fail makedir. # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 155737320 141426648 14310672 91% / udev 10240 152 10088 2% /dev shm 512616 0 512616 0% /dev/shm (In reply to comment #6) > Created an attachment (id=221877) [details] > The build-log > (In reply to comment #5) > I have read the entire message. In many cases build-logs are not included and I > presumed (wrongly) that someone would have immediately a clue. Nevertheless, > there are no fields in the bug report where build-logs and other lengthy system > messages are orderly entered and stored. What stops you from creating attachments after creating the bug? And your build.log clearly talks about tests/testsuite.log, so please attach that one too > What stops you from creating attachments after creating the bug? Flooding the bug-report and digging up files from deep in my var directory. As a constructive suggestion, in case of a bug, a "bug" directory should be created where all messages are orderly stored. At the moment messages are stored in obscure places, so that developers can bash users if they file a bug report, for being dumb in one or the other way. Especially the hidden allegation: You haven't even read the bug report: > And your build.log clearly talks about tests/testsuite.log, so please attach > that one too No it does not! It sais Please send `tests/testsuite.log' and all information you think might help: To: <sandbox@gentoo.org> Subject: [sandbox 1.6] testsuite: 8 11 failed I am clearly not sending any message to sandbox@gentoo.org. On the contrary: It merely states * If you need support, post the output of 'emerge --info =sys-apps/sandbox-1.6-r2', * the complete build log and the output of 'emerge -pqv =sys-apps/sandbox-1.6-r2'. So you kindly ask me to additionally send the testsuite.log. Here it comes. Created attachment 223411 [details]
testsuite.log
your removal of sandbox is what is screwing things up. no bug has ever said you should remove this package. install sandbox w/FEATURES=-test and then it should work fine the second time. (In reply to comment #12) > your removal of sandbox is what is screwing things up. no bug has ever said > you should remove this package. install sandbox w/FEATURES=-test and then it > should work fine the second time Thank you for your comment. The test-suite did not report any sandbox features missing. How do you infer your opinion? (In reply to comment #13) > (In reply to comment #12) > > your removal of sandbox is what is screwing things up. no bug has ever said > > you should remove this package. install sandbox w/FEATURES=-test and then it > > should work fine the second time > > Thank you for your comment. The test-suite did not report any sandbox features > missing. How do you infer your opinion? > I correct myself. The test-suite did report sandbox features missing, but said, it would ignore it. One error was: PASS: mkdir("root/aksdfjasdfjaskdfjasdfla", 777) = -1 (wanted -1); errno = 13 [Permission denied] (wanted 0 [Success]) ../../sandbox-1.6/tests/mkdir.at:3: exit code was 1, expected 0 11. mkdir.at:3: 11. mkdir/3 (mkdir.at:3): FAILED (mkdir.at:3) In this case, the permission was denied. I wonder where "root/aksdfjasdfjaskdfjasdfla" is to be located; hopefully not in my "root"-home directory. (I always name temporary directories like asdjfkasdjkfdjfk ;) But you might be right: Self-reference is a point that is commonly overlooked. If the reason is, that sandbox needs to be installed to install sandbox then this is a circular reference and should not occur. I am afraid that turning off tests, is against the spirit for what these tests are. why do you think the bug is still open ? it'll be fixed at some point, but removing sandbox from your system is still an error on your part. (In reply to comment #15) > why do you think the bug is still open ? it'll be fixed at some point, but > removing sandbox from your system is still an error on your part. > Because it has not been fixed. Your suggestion, installing sandbox with FEATURES=-test is a makeshift, not a solution. I have the feeling, that you are very concerned with, whose error this bug is. Gentoo has a very messed up package tree --- and not only sometimes and not only on amd64 architecture. It is fair to blame people, if gentoo's dependency tree would be in order, but on the contrary, it forces users to manually delete system-packages to get their system back on track. I have been using gentoo for a long time now and I am a devoted user, but at some point enough is enough. This testing business brings up even more errors and those people responsible for testing, dismiss a failed test by trying to put the blame on the bearer of the bad news, instead of setting things right. no one said that was a solution. i gave you a simple workaround so you could continue on your way and not be blocked in general, and so you could give feedback that the hypothesis was correct. i dont think you ever actually said what the result was, you just made an obvious point that no one was contesting. further, you're the one closing the bug here, not i. i'm leaving it open so that when i get around to it, it can be fixed properly. so unless you have something useful to contribute, take your complaining elsewhere and wait for the bug to be fixed properly. (In reply to comment #17) > why do you think the bug is still open ? it'll be fixed at some point, Oh I took it that you will deal with it at a later point. I hought that this is what LATER stands for: > LATER The bug will be dealt with at a later date. > i dont think you ever actually said what the result was, I quote Comment #3: > The FEATURES="-test" command did the trick. Which was acknowledged in Comment #4 > Sure, the failing test are not resolved :) > so unless you have something useful to contribute, take your complaining elsewhere and wait for the bug to be fixed properly. I have to contribute something useful and this is how bugs are dealt with: Take your blaming elsewhere and get professional! some people may want to use LATER, but i'm not inclined to as it's a synonymous with "i'm going to ignore it forever" read the comments again. you screwed up your system when you removed sandbox. that is a simple fact. i never "blamed" you for anything else. sandbox-2.3 passes tests even if sandbox isnt installed, or if and older sandbox (like 1.6) is installed. no plans on fixing older versions as we'll just stabilize a newer one. |