Caught in the nightly build in x86 and amd64. Log: 2019-01-13T15:34:40.8676624Z 2019-01-13T15:34:40.8678317Z >>> Installing (5 of 25) sys-libs/readline-8.0::gentoo 2019-01-13T15:34:42.3649724Z [sys-libs/readline-7.0_p5] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:42.3666488Z * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior 2019-01-13T15:34:42.3666763Z * is known to be triggered by things such as failed variable assignments 2019-01-13T15:34:42.3666950Z * (bug #190128) or bad substitution errors (bug #200313). Normally, before 2019-01-13T15:34:42.3667092Z * exiting, bash should have displayed an error message above. If bash did 2019-01-13T15:34:42.3667538Z * not produce an error message above, it's possible that the ebuild has 2019-01-13T15:34:42.3667696Z * called `exit` when it should have called `die` instead. This behavior 2019-01-13T15:34:42.3667843Z * may also be triggered by a corrupt bash binary or a hardware problem 2019-01-13T15:34:42.3667972Z * such as memory or cpu malfunction. If the problem is not reproducible or 2019-01-13T15:34:42.3668119Z * it appears to occur randomly, then it is likely to be triggered by a 2019-01-13T15:34:42.3668266Z * hardware problem. If you suspect a hardware problem then you should try 2019-01-13T15:34:42.3668393Z * some basic hardware diagnostics such as memtest. Please do not report 2019-01-13T15:34:42.3668541Z * this as a bug unless it is consistently reproducible and you are sure 2019-01-13T15:34:42.3668694Z * that your bash binary and hardware are functioning properly. 2019-01-13T15:34:42.3719150Z [sys-libs/readline-7.0_p5] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:42.3734800Z * The ebuild phase 'die_hooks' has exited unexpectedly. This type of 2019-01-13T15:34:42.3735018Z * behavior is known to be triggered by things such as failed variable 2019-01-13T15:34:42.3735168Z * assignments (bug #190128) or bad substitution errors (bug #200313). 2019-01-13T15:34:42.3735309Z * Normally, before exiting, bash should have displayed an error message 2019-01-13T15:34:42.3735684Z * above. If bash did not produce an error message above, it's possible 2019-01-13T15:34:42.3735811Z * that the ebuild has called `exit` when it should have called `die` 2019-01-13T15:34:42.3735952Z * instead. This behavior may also be triggered by a corrupt bash binary or 2019-01-13T15:34:42.3736112Z * a hardware problem such as memory or cpu malfunction. If the problem is 2019-01-13T15:34:42.3736451Z * not reproducible or it appears to occur randomly, then it is likely to 2019-01-13T15:34:42.3736577Z * be triggered by a hardware problem. If you suspect a hardware problem 2019-01-13T15:34:42.3736717Z * then you should try some basic hardware diagnostics such as memtest. 2019-01-13T15:34:42.3736853Z * Please do not report this as a bug unless it is consistently 2019-01-13T15:34:42.3736991Z * reproducible and you are sure that your bash binary and hardware are 2019-01-13T15:34:42.3737097Z * functioning properly. 2019-01-13T15:34:42.3738822Z !!! FAILED postrm: 1 2019-01-13T15:34:42.3750121Z * The 'postrm' phase of the 'sys-libs/readline-7.0_p5' package has failed 2019-01-13T15:34:42.3750335Z * with exit value 1. 2019-01-13T15:34:42.3750425Z * 2019-01-13T15:34:42.3750542Z * The problem occurred while executing the ebuild file named 2019-01-13T15:34:42.3751136Z * 'readline-7.0_p5.ebuild' located in the '/tmp/gentoo/var/db/pkg/sys- 2019-01-13T15:34:42.3751458Z * libs/readline-7.0_p5' directory. If necessary, manually remove the 2019-01-13T15:34:42.3751612Z * environment.bz2 file and/or the ebuild file located in that directory. 2019-01-13T15:34:42.3751735Z * 2019-01-13T15:34:42.3751972Z * Removal of the environment.bz2 file is preferred since it may allow the 2019-01-13T15:34:42.3752103Z * removal phases to execute successfully. The ebuild will be sourced and 2019-01-13T15:34:42.3752635Z * the eclasses from the current ebuild repository will be used when 2019-01-13T15:34:42.3752785Z * necessary. Removal of the ebuild file will cause the pkg_prerm() and 2019-01-13T15:34:42.3752920Z * pkg_postrm() removal phases to be skipped entirely. 2019-01-13T15:34:42.3830487Z sh: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.0393237Z [sys-libs/readline-8.0] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.0405860Z * The ebuild phase 'postinst' has exited unexpectedly. This type of 2019-01-13T15:34:43.0406441Z * behavior is known to be triggered by things such as failed variable 2019-01-13T15:34:43.0406850Z * assignments (bug #190128) or bad substitution errors (bug #200313). 2019-01-13T15:34:43.0407069Z * Normally, before exiting, bash should have displayed an error message 2019-01-13T15:34:43.0407804Z * above. If bash did not produce an error message above, it's possible 2019-01-13T15:34:43.0407988Z * that the ebuild has called `exit` when it should have called `die` 2019-01-13T15:34:43.0408128Z * instead. This behavior may also be triggered by a corrupt bash binary or 2019-01-13T15:34:43.0408268Z * a hardware problem such as memory or cpu malfunction. If the problem is 2019-01-13T15:34:43.0408405Z * not reproducible or it appears to occur randomly, then it is likely to 2019-01-13T15:34:43.0408540Z * be triggered by a hardware problem. If you suspect a hardware problem 2019-01-13T15:34:43.0408682Z * then you should try some basic hardware diagnostics such as memtest. 2019-01-13T15:34:43.0408812Z * Please do not report this as a bug unless it is consistently 2019-01-13T15:34:43.0408942Z * reproducible and you are sure that your bash binary and hardware are 2019-01-13T15:34:43.0409043Z * functioning properly. 2019-01-13T15:34:43.0460867Z [sys-libs/readline-8.0] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.0476779Z * The ebuild phase 'die_hooks' has exited unexpectedly. This type of 2019-01-13T15:34:43.0477375Z * behavior is known to be triggered by things such as failed variable 2019-01-13T15:34:43.0477760Z * assignments (bug #190128) or bad substitution errors (bug #200313). 2019-01-13T15:34:43.0477985Z * Normally, before exiting, bash should have displayed an error message 2019-01-13T15:34:43.0478592Z * above. If bash did not produce an error message above, it's possible 2019-01-13T15:34:43.0479042Z * that the ebuild has called `exit` when it should have called `die` 2019-01-13T15:34:43.0479209Z * instead. This behavior may also be triggered by a corrupt bash binary or 2019-01-13T15:34:43.0479352Z * a hardware problem such as memory or cpu malfunction. If the problem is 2019-01-13T15:34:43.0479510Z * not reproducible or it appears to occur randomly, then it is likely to 2019-01-13T15:34:43.0479668Z * be triggered by a hardware problem. If you suspect a hardware problem 2019-01-13T15:34:43.0479804Z * then you should try some basic hardware diagnostics such as memtest. 2019-01-13T15:34:43.0479958Z * Please do not report this as a bug unless it is consistently 2019-01-13T15:34:43.0480114Z * reproducible and you are sure that your bash binary and hardware are 2019-01-13T15:34:43.0480251Z * functioning properly. 2019-01-13T15:34:43.0484975Z * FAILED postinst: 1 2019-01-13T15:34:43.0567982Z sh: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.2187055Z [sys-libs/readline-8.0] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.2203218Z * The ebuild phase 'other' has exited unexpectedly. This type of behavior 2019-01-13T15:34:43.2204108Z * is known to be triggered by things such as failed variable assignments 2019-01-13T15:34:43.2204591Z * (bug #190128) or bad substitution errors (bug #200313). Normally, before 2019-01-13T15:34:43.2204803Z * exiting, bash should have displayed an error message above. If bash did 2019-01-13T15:34:43.2205455Z * not produce an error message above, it's possible that the ebuild has 2019-01-13T15:34:43.2205685Z * called `exit` when it should have called `die` instead. This behavior 2019-01-13T15:34:43.2205841Z * may also be triggered by a corrupt bash binary or a hardware problem 2019-01-13T15:34:43.2206011Z * such as memory or cpu malfunction. If the problem is not reproducible or 2019-01-13T15:34:43.2206182Z * it appears to occur randomly, then it is likely to be triggered by a 2019-01-13T15:34:43.2206333Z * hardware problem. If you suspect a hardware problem then you should try 2019-01-13T15:34:43.2206469Z * some basic hardware diagnostics such as memtest. Please do not report 2019-01-13T15:34:43.2206626Z * this as a bug unless it is consistently reproducible and you are sure 2019-01-13T15:34:43.2206776Z * that your bash binary and hardware are functioning properly. 2019-01-13T15:34:43.2279429Z [sys-libs/readline-8.0] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.2332521Z [sys-libs/readline-8.0] bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory 2019-01-13T15:34:43.2348493Z * The ebuild phase 'die_hooks' has exited unexpectedly. This type of 2019-01-13T15:34:43.2349168Z * behavior is known to be triggered by things such as failed variable 2019-01-13T15:34:43.2349573Z * assignments (bug #190128) or bad substitution errors (bug #200313). 2019-01-13T15:34:43.2349775Z * Normally, before exiting, bash should have displayed an error message 2019-01-13T15:34:43.2350317Z * above. If bash did not produce an error message above, it's possible 2019-01-13T15:34:43.2350519Z * that the ebuild has called `exit` when it should have called `die` 2019-01-13T15:34:43.2350643Z * instead. This behavior may also be triggered by a corrupt bash binary or 2019-01-13T15:34:43.2350788Z * a hardware problem such as memory or cpu malfunction. If the problem is 2019-01-13T15:34:43.2350932Z * not reproducible or it appears to occur randomly, then it is likely to 2019-01-13T15:34:43.2351074Z * be triggered by a hardware problem. If you suspect a hardware problem 2019-01-13T15:34:43.2351195Z * then you should try some basic hardware diagnostics such as memtest. 2019-01-13T15:34:43.2351349Z * Please do not report this as a bug unless it is consistently 2019-01-13T15:34:43.2351685Z * reproducible and you are sure that your bash binary and hardware are 2019-01-13T15:34:43.2351812Z * functioning properly. 2019-01-13T15:34:43.2445091Z 2019-01-13T15:34:43.2446278Z >>> Failed to execute postinst for sys-libs/readline-8.0, Log file: You can find yourself in the build environment in that situation doing: docker pull awesomebytes/gentoo_prefix_latest_image_initial:429 docker run -it awesomebytes/gentoo_prefix_latest_image_initial /bin/bash The bootstrapped environment is at /tmp/gentoo. Reproducible: Always
sys-libs/readline-7.0_p5 gets bootstrapped in previous stages correctly. And apparently then, on stage 3, sys-libs/readline-8.0 was triggered which failed.
Full log of the bootstrap can be found at: https://dev.azure.com/12719821/e566c963-8f77-4f01-b7bc-ae2d91b1334f/_apis/build/builds/429/logs/8?$format=zip&api-version=5.0-preview (It's 4MB compressed, 64MB uncompressed, so it doesn't fit as an attachment).
Thanks! This coincides with https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6cda51b3a77d9240ace5302bb527e .
This might only happen once when the stage3 readline is upgraded from 7 to 8 after emerge --sync. Sam, does the CI still fails next time?
I re-triggered the CI after I wrote this bug report, need to wait 2h more to see if we get thru... but the CI started 2h after that commit, so I don't expect it to be fixed. CI is triggered at 00:00 every night in Sydney time, so 14:00 CET, the commit is from 12:18 CET.
(In reply to Sammy Pfeiffer from comment #5) > I re-triggered the CI after I wrote this bug report, need to wait 2h more to > see if we get thru... but the CI started 2h after that commit, so I don't > expect it to be fixed. > CI is triggered at 00:00 every night in Sydney time, so 14:00 CET, the > commit is from 12:18 CET. portage tree snapshot takes place daily. 2h might not be enough.
The CI failed with the same error, same log. (The build is at: https://dev.azure.com/12719821/12719821/_build/results?buildId=432 )
RAP is using mainline tree that's why this show up like this, I think. Bootstraps on fex powerpc-apple-darwin9 failed like this: emerge: there are no ebuilds to satisfy ">=sys-libs/readline-8.0:0=". (dependency required by "app-shells/bash-5.0::gentoo_prefix" [ebuild]) (dependency required by "@system" [argument]) In your case, I'm wondering if config-protect works appropriately in a cross-setting. Best to avoid this during bootstrap indeed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=801178136a0d22e286625a2854d38f024c1e741a commit 801178136a0d22e286625a2854d38f024c1e741a Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2019-01-14 10:51:39 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2019-01-14 10:51:39 +0000 sys-libs/readline: sync with gx86, bug #675372 Bug: https://bugs.gentoo.org/675372 Package-Manager: Portage-2.3.55-prefix, Repoman-2.3.12 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-libs/readline/Manifest | 1 + .../readline-8.0-darwin-shlib-versioning.patch | 40 ++++ sys-libs/readline/files/readline-8.0-headers.patch | 17 ++ sys-libs/readline/readline-8.0.ebuild | 214 +++++++++++++++++++++ 4 files changed, 272 insertions(+)
I cannot reproduce this bug now. I speculate that the next CI run will pass.
CI passed, issue resolved.
Thanks Sam and Fabian.
