DevHeads.net

Base Runtime prototype build and numerous FTBFS issues

Hi!

during the Tuesday's Modularity WG meeting I was talking about the status
of the Base Runtime prototype build and the package build failures we
encountered during our latest attempt. The meeting log is here:

<a href="https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-11-29-15.00.log.html" title="https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-11-29-15.00.log.html">https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016...</a>

In short: To bootstrap the Modularity infra (yeah, it's still not done)
we took a (fairly large) set of packages directly from Fedora 25 RC3
and put them all in one, self-hosting module, currently misleadingly
labeled as base-runtime. The next step was to rebuild this set using
only the packages in it, preferrably twice, to prove it works, produces
the same, reproducible builds (or as close as we can get) and to save us
from sudden, unexpected breakage later when we need to touch components
deep in the [build] dependency chain.

(Since this is a common question: No, the final Base Runtime module,
or the Generational Core stack it is part of, won't be self-hosting and
we won't be shipping the entire set we're currently working with under
that name.)

We attempted to rebuild 2943 SRPMs and encountered 152 failures.
The reasons vary and include undiscovered conditional build dependencies,
undeclared build or runtime dependencies in combination with recent
buildroot and other package dependency chains changes, packages no
longer being compatible with their updated dependencies, random hangs
or non-deterministic, randomly failing test suites, to name a few.

Some but not all of those affect, and can be reproduced in, the traditional
Fedora release, too, and fixing these issues is not only crucial for the
upcoming modular Fedora 26 Server but will benefit the standard Fedora
release as well.

We'll be working on resolving these failures during the upcoming few weeks
-- via FTBFS bug reports or immediate fixes in the most trivial cases.
We'll use the following tracker bug for this purpose:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1400162" title="https://bugzilla.redhat.com/show_bug.cgi?id=1400162">https://bugzilla.redhat.com/show_bug.cgi?id=1400162</a>

For the curious, the logs are here:
<a href="https://psabata.fedorapeople.org/f25rc3-failures/" title="https://psabata.fedorapeople.org/f25rc3-failures/">https://psabata.fedorapeople.org/f25rc3-failures/</a>

And the modulemd input for this build is here:
<a href="http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/base-runtime.yaml?id=d2485512c7916304e73fabc5db422798eb2be1d5" title="http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/base-runtime.yaml?id=d2485512c7916304e73fabc5db422798eb2be1d5">http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/bas...</a>

If you maintain some of these FTBFS'd packages, feel free to fix them
even before we get to you! :) Just, please, let us know if you do.

Finally, some quick test instructions: Make sure your package builds
in F25 and Rawhide. If it does, check whether it also builds in mock
using this configuration file: <a href="https://paste.fedoraproject.org/494173/" title="https://paste.fedoraproject.org/494173/">https://paste.fedoraproject.org/494173/</a>
If it works there as well, chances are it's fine.

Thank you in advance,
P

Comments

Re: Base Runtime prototype build and numerous FTBFS issues

By Igor Gnatenko at 12/01/2016 - 06:06

On Wed, Nov 30, 2016 at 4:36 PM, Petr Ĺ abata < ... at redhat dot com> wrote:

Re: Base Runtime prototype build and numerous FTBFS issues

By Stephen Gallagher at 12/01/2016 - 08:17

On 12/01/2016 06:06 AM, Igor Gnatenko wrote:
As noted in the quote above, this is part of the bootstrapping set. In order to
get off the ground, we need to be able to build modules in the module
infrastructure. This means we need to be able to build the tools that build the
packages in the modules (and in turn, the tools to build those tools and so on).
The 2943 SRPMs in this first pass comprises the full, recursive set of packages
necessary to self-host the Base Runtime set of 162 SRPMs.

Given the relatively small number of failures, it's not really worth the effort
(right now) to try to figure out why certain packages are getting pulled in.
Yes, this set is far larger than we would prefer, but since this is a
bootstrapping effort that will hopefully not need to happen again, there's no
strong reason to dig deeply into it except to satisfy curiosity.