>>> Starting src_prepare * Removing bundled library third_party/bzip2 ... * Removing bundled library third_party/codesighs ... * Removing bundled library third_party/cros ... find: `third_party/cros': No such file or directory !!! ERROR in www-client/chromium-9999::gentoo: !!! In remove_bundled_lib at line 4106 !!! failed to remove bundled library third_party/cros Reproducible: Always
Can anyone else confirm this?
(In reply to comment #1) > Can anyone else confirm this? to compile, 2 lines need to be commented out: #remove_bundled_lib "third_party/cros" #remove_bundled_lib "third_party/py"
I had the same issue. In my overlay, I just ewarn rather than dying.
Now, I meet the same issue after bug #333013 fixing.
I can confirm this on two different machines.
Created attachment 243353 [details, diff] Fix error when trying to remove missing bundled lib
See proposed patch (http://bugs.gentoo.org/attachment.cgi?id=243353) to fix the problem. Now, I meet the issue described in bug #331343.
Of course, as said by fkhp, remove_bundled_lib "third_party/cros" and third_party/py has to be removed too since they seems useless. The patch is to make remove_bundled_lib() function failure_proof when some third_party subdirectories are removed or renamed.
(In reply to comment #6) > Created an attachment (id=243353) [details] > Fix error when trying to remove missing bundled lib > Nitpick: if you want to treat this as non-fatal, there really is no need to explicitly check for a missing directory; just change the "|| die ..." after the find call to "|| ewarn ...". However, I'm guessing our friendly maintainer wants it to die to generate bug reports when the list changes.
(In reply to comment #9) > Nitpick: if you want to treat this as non-fatal, there really is no > need to explicitly check for a missing directory; just change the "|| die ..." > after the find call to "|| ewarn ...". Yeah... seems to be the best option. Thanks! > However, I'm guessing our friendly maintainer wants it to die to generate bug > reports when the list changes. Right, but in case of the 9999 ebuild it turned out to be the wrong choice that prevented you from testing the bleeding-edge code. Now that this thing is removed (sorry it took so long), enjoy your 9999 builds!
