This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Propose requiring Python 3.4 or later for building glibc.
- From: Helmut Grohne <helmut at subdivi dot de>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: debian-glibc at lists dot debian dot org, GNU C Library <libc-alpha at sourceware dot org>, "Dmitry V. Levin" <ldv at altlinux dot org>, Allan McRae <allan at archlinux dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fweimer at redhat dot com>, "Andreas K. Huettel" <dilfridge at gentoo dot org>, Sergei Trofimovich <slyfox at gentoo dot org>, Khem Raj <raj dot khem at gmail dot com>, Andreas Schwab <schwab at suse dot de>, Adam Conrad <adconrad at ubuntu dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Daniel Schepler <schepler at debian dot org>
- Date: Mon, 22 Oct 2018 20:35:56 +0200
- Subject: Re: Propose requiring Python 3.4 or later for building glibc.
- References: <258837a9-50bf-d2b3-950a-c28e5b411e8f@redhat.com> <20181022095125.GA15764@aurel32.net> <20181022141525.GA16023@alf.mars> <a03ac492-f9b3-0366-9df2-322ae164f6b1@redhat.com>
On Mon, Oct 22, 2018 at 11:38:15AM -0400, Carlos O'Donell wrote:
> It is possible that the build *and* host require python 3.4.
>
> The reason being that when cross-testing glibc with the test-wrapper-env
> script the build system may execute a command on the host system to
> run python (which is usually implemented as a ssh to a target system
> with a shared mounted filesystem).
>
> There are at least several pretty-printing tests which use python, and
> require PExpect, and those run on the host during testing via the
> test-wrapper-env abstraction.
>
> I've started a new thread of discussion here, but in general my expectation
> has always been that host and build environments need the same set of tools.
>
> https://www.sourceware.org/ml/libc-alpha/2018-10/msg00395.html
I should have thought of testing indeed. In Debian, we tend to turn
testing off completely for a bootstrap and then rebuild the world (using
the bootstraped packages) with testing enabled. This is done, because it
removes a pile of dependencies and makes the problem a bit more
manageable. So as long as tests can be disabled (preferably without
changing the build result in terms of reproducible builds[1]), the cross
bootstrap won't be impacted.
In any case, requiring Python 3 for testing does not seem to be a new
thing. The dependency is already there and it is not causing problems
now. So from a cross bootstrap pov, I'm fine here.
Helmut
[1] We also use reproducible builds to validate cross buildt packages
against natively built (with tests enabled) ones.