Re: Use gen-libm-test.py to generate ulps table for manual

[Carlos O'Donell <carlos at redhat dot com>]

On 08/13/2018 04:29 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> It is a question of interest really. Fedora has the technical ability
>> to deliver a bootstrap that happens routinely, but I don't see the
>> motivation to do so.
> 
> Sorry, this sounds … very unconvincing.

Could you clarify what you were not convinced about? The technical ability
or lack of motivation?
 
> This is a capability that deteriorates very quickly if you do not
> continuously exercise it.

Agreed. How does adding python prevent you from continuously exercising
the bootstrap? Do you argue that it makes the whole build cycle too long?

> We can't even do periodic (say weekly) mass rebuilds in Fedora, and we
> know that there are uses for that, such as generating accurate markup
> (be it annobin or CET) based on the latest toolchain fixes.

Either we can't do it technically (not true, we can).

Or we aren't sufficiently motivated to do it (the real case).

I don't know why Andreas wants the core bootstrap small.

I don't understand Andreas' motivation.

If glibc upstream can't understand the reasons why downstream want a
minimal bootstrap then we can't ourselves support the position either.

You appear to argue that it would be nice if downstream Fedora had a
minimal bootstrap (without python) to test:

* Annobin (binary annotation work we are doing).

* Intel CET (ABI flag day changes for *context() routines).

That would be really nice, but the reality is that we don't value that
and so we haven't invested in it. Why should glibc upstream value it?

Using python in upstream glibc makes it easier to maintain, and the only
downside is the bootstrap issue. The solution *today* is to not build the
subsystems in glibc that need python (manual, benchtests) during bootstrap.

If more things require python then we may need a minimal python for
the bootstrap. Investing in that is a good idea only if you value what
we have just discussed as a bootstrap.

Other more useful bootstraps are IMO something like "Build all C++ programs
with the latest C++ compiler changes, but do it in a side tag" which would
allow the Fedora toolchain team to test C++ changes. These kinds of CI-esque
workflows don't need a minimal python or a minimal bootstrap since the C++
applications you are building will likely already require much of the distro
to be present.

>>> Andreas' setup is very good for detecting certain types of build
>>> issues, and I wouldn't want to lose that.
>>
>> I assume you are arguing that a full bootstrap would take much longer
>> than the set of packages Andreas identifies. Please make such assertions
>> clear.
> 
> It's also much more brittle because as the Fedora experience shows, it
> is very difficult to keep even the core of the distribution in a
> permanently buildable state.  So it's not purely about speed.

Agreed. This still doesn't convince me that you have a compelling enough
use case for minimal bootstraps that upstream glibc must not adopt python
as a bootstrap requirement (which it isn't yet).

To convince myself that the real solution is a python3-minimal solution I
started with the python3 in Fedora Rawhide, and with maybe 5 minutes of
spec file hacking I had a Python3 which built (in a clean rawhide mock
chroot) *without* all the dependencies enabled. It appears to work for 
simple bootstrap things. Tests are still running, but languages tests
are mostly passing (one _haslib failure).

Is there a technical problem with needing python3-minimal? It seems like
such a package would solve all sorts of early bootstrap issues with needing
python?

-- 
Cheers,
Carlos.

[1] http://fedora-bootstrap.fedorainfracloud.org/