During the stage2 process, catalyst executes catalyst/targets/stage2/stage2-chroot.sh script, then the chroot scripts executes portage/scripts/bootstrap.sh. However, bootstrap.sh emerges virtual/libc package, expected behavior is, emerging system libc, like glibc Output: (attached @catalyst-stg2) I was asked in #gentoo irc @ 15:30 EEST +-1h, eroen's -workaround- idea is uncommenting line 338, the result is: (attached @workaround) This case very experimantal but if gentoo autobuild stage3 tarballs are created by [0], abi/linkage problems may occur because stage1 binaries compiled with seeds image. In stage3 view, libc, toolchains are not firstly re-emerged. it seems like passing stage2 process, emerging system libc in stage3 process (emerge -e @system). [0] http://git.overlays.gentoo.org/gitweb/?p=proj/releng.git;a=blob;f=scripts/stage_build.sh;h=0dd89a9b049104ff5fd5610df55f287f53c8c461;hb=HEAD Thanks, Burak Reproducible: Always
Created attachment 377768 [details] catalyst-stg2
Created attachment 377770 [details] workaround
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b73bd14850491738363f3c8e60519b22d6ece063 commit b73bd14850491738363f3c8e60519b22d6ece063 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-03-29 07:03:02 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-03-29 17:44:39 +0000 scripts/bootstrap.sh: Emerge the actual libc The python program creates a set of bash variable assignments like myGCC="sys-devel/gcc"; which are used to make a list of packages to be rebuilt during catalyst's stage 2. The toolchain, including libc, is supposed to be rebuilt in this stage, but 'portage.settings.packages' contains 'virtual/libc' and not a provider, so it generates: myLIBC="virtual/libc"; This results in catalyst not rebuilding the libc itself but instead reemerging virtual/libc. Commit b9e8ca9b4aa1 (Make sure we rebuild actual libc and not the virtual package.) tried to fix this, but obviously missed the mark as any testing would have shown. The solution is to have the python program expand the virtual itself. Fixes: b9e8ca9b4aa1 (Make sure we rebuild actual libc and not the virtual package.) Closes: https://bugs.gentoo.org/511694 Signed-off-by: Matt Turner <mattst88@gentoo.org> scripts/bootstrap.sh | 3 +++ 1 file changed, 3 insertions(+)
