The glibc-2.29 has unnessessary python-any-r1 eclass inheritance, which seemingly copied from sys-libs/glibc-9999. Reproducible: Always
https://sourceware.org/ml/libc-announce/2019/msg00000.html """ Changes to build and runtime requirements: * Python 3.4 or later is required to build the GNU C Library. """
Thanks, Arfrever. Okay, now the bug is that glibc-2.29 breaks Prefix bootstrap.
Created attachment 572564 [details, diff] glibc-2.29-python-RAP-bootstrap.patch Dear Toolchain Team, I would like to commit the attached update to the new glibc-2.29 ebuild. It helps to build glibc without having python installed during the Prefix bootstrap. Please help me review it. If there are no objections I would like to commit it in 2 weeks. Benda
(In reply to Benda Xu from comment #3) > Created attachment 572564 [details, diff] [details, diff] > glibc-2.29-python-RAP-bootstrap.patch > > I would like to commit the attached update to the new glibc-2.29 ebuild. > > It helps to build glibc without having python installed during the Prefix > bootstrap. This is at least broken in that you are misassuming what 'default' does. 'default' calls a default implementation for given phase from package manager, NOT a function from any eclass (marked by EXPORT_FUNCTIONS in eclass). If not calling python-any-r1_pkg_setup is correct solution, then I suggest: pkg_setup() { [[ -z ${BOOTSTRAP_RAP} ]] && python-any-r1_pkg_setup } Beside this, there is no longer sys-libs/glibc-2.29-r1. There is sys-libs/glibc-2.29-r2. Any change should be also made in sys-libs/glibc-9999.
*** Bug 683172 has been marked as a duplicate of this bug. ***
Created attachment 572642 [details, diff] glibc-2.29-python-RAP-bootstrap-r1.patch Thanks Arfrever! I have updated the patch accordingly. Please review.
(In reply to Benda Xu from comment #6) > Created attachment 572642 [details, diff] [details, diff] > glibc-2.29-python-RAP-bootstrap-r1.patch > > Thanks Arfrever! > > I have updated the patch accordingly. Please review. Looks ok. Can you add a comment as well around that function why it's needed? Preferably linking to this bug.
(In reply to Benda Xu from comment #6) > Created attachment 572642 [details, diff] [details, diff] > glibc-2.29-python-RAP-bootstrap-r1.patch > > Thanks Arfrever! > > I have updated the patch accordingly. Please review. Obviously this assumes that glibc *can* be built without python (or using the host python). (Upstream is bent on assuming that python is available for glibc build. I'm not sure how much it is needed *yet* outside the testuite, but that may change.) I'm going to integrate the patch, with some additional comment, but please be aware that this is only a temporary workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f99af4631f3251f9e10cbd048ab8638e027fe1b2 commit f99af4631f3251f9e10cbd048ab8638e027fe1b2 Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2019-04-13 16:08:52 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2019-04-13 16:13:40 +0000 sys-libs/glibc: python pkg_setup fails during bootstrap. Glibc-2.29 introduces a new python dependency for building. However, during Prefix bootstrap, glibc has to be built before python. The dependency circle is broken by disabling pkg_setup() of python-any-r1.eclass. Bug: https://bugs.gentoo.org/682570 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Benda Xu <heroxbd@gentoo.org> Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/glibc-2.29-r2.ebuild | 4 ++++ sys-libs/glibc/glibc-9999.ebuild | 4 ++++ 2 files changed, 8 insertions(+)
I'm assuming that you have tested your fix, because obviously it will only work when portage dependency resolution is ignored.
(In reply to Andreas K. Hüttel from comment #8) > (In reply to Benda Xu from comment #6) > > Created attachment 572642 [details, diff] [details, diff] [details, diff] > > glibc-2.29-python-RAP-bootstrap-r1.patch > > > > Thanks Arfrever! > > > > I have updated the patch accordingly. Please review. > > Obviously this assumes that glibc *can* be built without python (or using > the host python). > > (Upstream is bent on assuming that python is available for glibc build. I'm > not sure how much it is needed *yet* outside the testuite, but that may > change.) > > I'm going to integrate the patch, with some additional comment, but please > be aware that this is only a temporary workaround. Thanks Andreas! At this stage python is available, only not tracked by portage.
