This may have to do with portage-2.2_rc24, as I just upgraded it today, but on the other hand this confdir3 error has been reported with other versions of coreutils. emerge log and emerge --info are attached. Reproducible: Always
Created attachment 184583 [details] output for emerge coreutils
Created attachment 184585 [details] emerge --info
Could be a sandbox issue. The same had been reported with coreutils-5.0 in bug #21766 tough I'm not sure this is a real duplicate as that bug is over six years old.
I have no clue what that is, but rm'ing /var/tmp/portage/sys-apps/coreutils and rerunning the emerge "fixed" it for me.
Wilbur can you please verify that the "fix" Alex suggested works for you as well?
I just tried that, and it did work. Although I'm puzzled -- I would assume that one of the first things that the emerge process would do is to clear out any workfiles in /var/tmp/portage that are sitting there from a previously aborted emerge, no?
(In reply to comment #6) > Although I'm puzzled -- I would assume that one of the first things that the > emerge process would do is to clear out any workfiles in /var/tmp/portage that > are sitting there from a previously aborted emerge, no? That's what it was trying to do when the unexpected "OSError: [Errno 36] File name too long" exception happened.
(In reply to comment #7) I see, sort of. I'm not a programmer by any means (at least not for the past 25 years), but I don't see why that situation should show up in an emerge process. The package is being emerged, so there's not reason to keep the files from the old aborted process around. So it would seem to me that the algorithm should be like this: IF "/var/tmp/portage/aborted_package" exists, THEN "rm -rf /var/tmp/portage/aborted_package" I fully understand that it could be that I'm just being a moron here. :-)
(In reply to comment #8) > IF "/var/tmp/portage/aborted_package" exists, THEN "rm -rf > /var/tmp/portage/aborted_package" It was doing something equivalent to that when the exception occurred. The shutil.rmtree() function is what failed, and that function is like a python version of rm -rf. This is the first time that I've seen the shutil.rmtree() fail like this. I think I'll fix it to call rm -rf instead.
iirc, `rm -rf` with a full path will fail as well you might want to chdir($PORTAGE_TMPDIR/$CATEGORY) and then do the removal on $PF
since ive fixed sandbox, you might want an easy way to reproduce this ... sandbox has getcwd-gnulib_tst.c in its tests subdir. if you run `make check`, the build system will generate the binary for you. edit that and go down to where the comment is "Leaving behind such a deep directory is not polite". if you put an exit() before that comment, the deep confdir tree will be left behind.
(In reply to comment #10) > iirc, `rm -rf` with a full path will fail as well I was able to reproduce it like this: for x in {1..1000} ; do mkdir confdir3 ; cd confdir3 ; done For me, rm worked when shutil.rmtree() failed. I've removed the relevant shutil.rmtree() call in svn r13071.
This is fixed in 2.2_rc25 which is in package.mask. I'll close this bug when it's also released in 2.1.6.8.
This is released in 2.1.6.8.
