I've had a few conversations with stakeholders involved in Fedora 15
work, both on IRC, by email, and on the phone. I would like to make a
proposal for our plan of action in the short term.
ARMv7 bootstrap stage4
We will continue to build ARMv7 packages in the bootstrap effort. We
will use GA packages as we have done. Those packages that fail to build
with the GA sources will be built using updated sources. KDE and other
stacks on a case-by-case basis will be granted a special exception, and
all of the packages can be pulled from updates. We want to be close to
GA, but we don't want to be unreasonable either. This should resolve
most of the issues around FTBFS and updates issues.
We will hold a review session tomorrow (Thursday September 22) on IRC
that will be announced as a VFAD. At that time, we will review the
release criteria for primary arch and the conventions of secondaries
(for example "don't care about desktop use") with respect to the current
list of failing packages. We will decide what we need to do to complete
the bootstrap in mock of ARMv7, so that we can move on to Koji.
TARGET: October 14th or sooner for remaining packages/ready for Koji.
ARMv5 F15 bootstrap
Chris Tyler and the team at Seneca are going to throw dozens of builders
at building the world of F15 v5 packages, using a similar approach to
that done for v7 bootstrap. They only need to do the mock stage4, and
will leverage all of the fixes and other work done so far. It is
expected that they will be ready with a v5 build mid-October. We'll all
pitch in and help, of course. We'll create an F14 based rootfs that can
be used for that "stage4"-like build effort on builders not doing v7.
TARGET: October 14th or sooner for the set of v5 packages.
We will pull both sets of (matching) v7 and v5 packages into a Koji
instance hosted at Seneca. A mass rebuild with both sets of builders
will be initiated by October 21st with a goal of being complete prior to
Fedora 16 GA. We will work together to make sure Koji is ready to do
this by establishing a test v5/v7 instance as soon as possible.
TARGET: October 21st or sooner for mass rebuild.
I believe our goal should be to have an F15 alpha soon after F16 is
released on or around Nov. 1. If we pull off the above, we should be
able to get an alpha done before mid-November and then begin to turn our
attention to getting F16 on track with a unified Koji, etc. We can also
revisit koji-shadow tracking of rawhide, and so on.
We will monitor the Koji situation. If there are going to be unforeseen
delays in this approach, we will fall back to separate Koji instances
for v5 and v7. The official Seneca instance running v5 will be the
official Fedora 15 ARM release. A separate instance will be established
for v7 builds and we will make a test release for v7. We will then seek
to integrate fully for F16 from the outset. We need to be mindful that
Fedora 16 is to hit GA on November 1 (likely slipping a week though). We
should not delay so much that we continue to be behind at that time.
It is clear that we need some more process in place around the Fedora
ARM effort. Thus far, it has been loosely organized on IRC, email, and
in occasional calls between Chris and myself. I propose we soon
establish weekly phone calls on my dialin (details to follow). At that
time we will itemize what the outstanding tasks are, and determine the
best course of action for the current release, next release, longer term
goals around primary architecture integration, and overall process. It
is important that everyone have a voice, and this is a fairer model.
Thanks for reading.
So maybe Andrew can tell us what we really need to have for Java?
Sent from my phone - message formatted and/or shortened accordingly.
From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= [henrik(a)henriknordstrom.net]
Received: Friday, 23 Sep 2011, 12:39
To: Jon Masters [jcm(a)redhat.com]
CC: Andrew Haley [aph(a)redhat.com]; arm [arm(a)lists.fedoraproject.org]
Subject: Re: [fedora-arm] LLVM
fre 2011-09-23 klockan 11:36 -0400 skrev Jon Masters:
> Hey aph,
> Copying Fedora ARM public mailing list. See also #fedora-arm on Freenode
> if you'd like to swing by and talk about Java packages :)
> I need some advice. We're 13 packages shy of a minimal package set for
> F15 (if we exclude things like Firefox and Open^WLibreOffice for now).
> Here are the ones we're looking to build now:
> * busybox
> * docbook2X
> * gtkmm24
> * icu
> * java-1.5.0-gcj
> * java-1.6.0-openjdk
> * llvm
> * pax
> * perl-XML-LibXML
> * pki-core
> * sinjdoc
> * uuid
> * xerces-c
Still unsolved are
java, both variants
sinjdoc (needs java)
gtkmm24 (FTBFS, awaiting maintainer response)
llvm (needs ocaml)
Copying Fedora ARM public mailing list. See also #fedora-arm on Freenode
if you'd like to swing by and talk about Java packages :)
I need some advice. We're 13 packages shy of a minimal package set for
F15 (if we exclude things like Firefox and Open^WLibreOffice for now).
Here are the ones we're looking to build now:
LLVM is there because I'm (perhaps naively) thinking this might be
required to get Shark working, if you're thinking that will work. If
we're just going to go with Zero for now, we don't need LLVM, right? Can
you perhaps let us know what you think you will need for Java? We're
happy to leave building of the Java bits to you if you'd like to poke,
but if we can avoid having to build LLVM in the short term, great :)
P.S. Fedora ARM folks: meet Andrew, he's a Java guru :)
I'd propose that we get together online tomorrow starting at 1600 UTC
(1200 EDT) to triage the list of packages which are still unbuilt for
F15 armv7hl, deciding which ones must be built, and which ones we're
willing to say won't build in this pass. By doing this, we'll more
clearly define the goal and finish line for the mock/pre-koji build. I
realize that this is short notice and may not be a good time for
everyone, but if whoever is available can meet to get the ball rolling,
we'll propose the results to the list for discussion and finalization.
When: Sep 22 2011, 1600 UTC (1200 EDT)
Background for those who haven't seen the discussion on IRC. There is a
ongoing debate if the F15 effort should initially target to build F15 GA
(original release) or F15 with current updates.
Here is my views.
In the stage4 distribution bootstrap we are seeing an annoyingly high
rate of FTBFS issues where the issue is already fixed by an update, or
in f16/rawhide. The resolution to these is that we pull in the updated
srpms as needed while making sure needed changes gets into the f15
branch in git (if not already) for future updates.
The question now is if we at this stage simply should pull in all the
updates from F15, instead of continuing trying to build as close to GA
The procssing time for building the packages is not really an issue. The
available computing power by far outweights the available resources
looking into build issues.
I am of the opinion that the current updates should be imported.
This should reduce the number of FTBFS issues and also get rid of most
chain rebuilds needed while resolving build issues by importing updates.
It may also cause some new ones, but my guess is far less than it
Trying to get the distribution built as close to a certain date is to me
a much saner startingpoint to then start rolling forward from with
updates than the current mix of GA and random fully updated packages of
much later date, and would more closely resemble the build environment
in mainline (which is always with current updates plus perhaps some
overrides, the number of current packages actually compiled to the GA
set is small)
Also, I see a risk in that we later down the road of F15 starts subtly
breaking things because updates do not get built at all in the order
intended. There is updates in F15 which need careful ordering to build
correctly, but this information is ofent not recorded in BuildRequires
and is therefore lost in the current process, resulting in undefined
outcome when later rolling forward with the rest of the updates. And no,
recording it in BuildRequires is not the right solution to this problem
for several reasons. But that is a topic for a separate mail is someone
Also, in a general quality point of view, I see only benefits in having
as many updates as possible rolled into the release as early as
possible, and that the release which will eventually happen is as up to
date as possible minimizing security issues and other bugs.
Please note that the stage4 distribution bootstrap is unique in the
sense that it's all a scratch build without locked package release,
which means that during stage4 we can easily shake out any mishaps from
build order without having to bump package releases.
Some of the issues I worry about have already been seen where packages
have needed to be rebuilt because of other packages being updated, but
can't really tell if that's due to the updates or due to the general
state of things in stage3&4 which haven't always been the prettiest. But
that's also one of the purposes of having the stage4 step to enable
issues to get sorted out with less pain. Once we move over to koji
things will become more strict and shaking out issues takes longer time.