Summary: | sys-apps/coreutils-8.7 fails tests du/long-from-unreadable, dd/skip-seek-past-dev, test-mkdirat | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Theo Chatzimichos (RETIRED) <tampakrap> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | binki, brant, creffett, kanelxake, nikoli, rhill |
Priority: | High | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
build.log for 8.9 |
Description
Theo Chatzimichos (RETIRED)
2010-11-26 18:28:22 UTC
Created attachment 255517 [details]
build.log
the first two should have been skipped because you're running as non-root SpanKY: What makes you think those tests should be skipped? I didn't see anything permissions related where an error occurred nor did I see anything that seemed to depend on being root in what I read of the long-from-unreadable test. Besides, neither of userpriv nor usersandbox were being used. Other tests were skipped because the user was root. The mkdirat test is the same as other mkdirats originating with gnulib. I reported that issue earlier today as bug 346929. That's an issue related to sandbox and may be a regression since it appeared mkdirat was made to work in sandbox with bug 297026. I just built today with FEATURES="-sandbox -usersandbox" and otherwise unchanged and tests passed, so the other issues seem sandbox related and not privilege related since the use of sandbox was the only variable I changed. *** Bug 349089 has been marked as a duplicate of this bug. *** I do not know about the mkdirat, but I think (and think I have seen before) that something in how sandbox rewrites and resolves paths may trigger problems with long paths. The mkdirat problem I have to, maybe related to that other supposedly fixed bug about the *at functions and file descriptors that may have some problems left? And they still apperes with 8.8 here. My preliminary tests seems to suggest that it is the adding of "pwd" (as done while resolving the path in reference to root directory) that tips the scale towards a "too long filename". Here on my computer when I try the commands outside of portage, then rm "path" works, but rm `pwd`"path" gives too long filename ()the same error as with sandbox). With 8.9 only the mkdirat test fails for me. Created attachment 258940 [details]
build.log for 8.9
confirmed, i'm attaching build.log for the record :)
(In reply to comment #9) > Created an attachment (id=258940) [details] > build.log for 8.9 > > confirmed, i'm attaching build.log for the record :) > FAIL: du/long-from-unreadable (exit: 1) Did you really check your log? Remember coreutils runs tests in two stages, first is coreutils tests, the second is gnulib tests, and all the failing tests except mkdirat belongs in coreutils testsuite. This is why you have in the end of your log: ====================================== 1 of 215 tests failed (14 tests were not run) See gnulib-tests/test-suite.log Please report to bug-coreutils@gnu.org ====================================== but a bit longer up you got: ====================================== 3 of 355 tests failed (87 tests were not run) See tests/test-suite.log Please report to bug-coreutils@gnu.org ====================================== Also if you had run thie with userprivs coreutils would not have skipped "rm/deep-2" which fails for the same reason. This fails mostly just because coreutils testsuite evaluates the commands/functions after how much they should be able to handle, look close at the dir structure and you will see that the directory they try to remove is about "x/x/x/x/x/x/x", but the testsuite only passes "x/x" to rm depending on how long path it thinks rm can handle. And if sandbox then forces rm to get "/y/y/x/x/ when the testsuite evaluated for some reason that rm could only handle a max path of "x/x" you may see why this breaks. So how can we fix this? Either we get the testsuite to recongize that the possible path is shorter than it thinks, or sandbox has to only evaluate if rm may remove "/y/y/x/x" and then pass "x/x" instead of "/y/y/x/x". You can try this yourself. cd into the testdir, and look inside the log of a failing test. You will find something like "rm could not remove x/x: path too long", and run it but as "rm `pwd`/x/x" and you will get the same error. remove `pwd` and rm will work fine. i'm going to dupe to a newer one because a bit more triaging has been done there *** This bug has been marked as a duplicate of bug 413621 *** |