[fedora-arm] Koji status update

[Dennis Gilmore]

El Thu, 17 Nov 2011 21:48:06 -0500
Jon Masters <jcm at redhat.com> escribió:
> On Thu, 2011-11-17 at 15:03 -0800, Brendan Conoboy wrote:
> > On 11/17/2011 11:04 AM, Chris Tyler wrote:
> > > I agree with going with what we've currently got package-wise. But
> > > saying "we should start building today" or "get Koji
> > > running...tomorrow" is missing the point.
> 
> :) I'm not so sure. I think the goal should be to get to rawhide as
> quickly as possible because it makes all of these problems go away -
> no rebuilding retrospectively, not being treated quite so much as a
> secondary, and so on (then we push for primary). Given that that is
> our general ambition, we should work backward and try to get to that
> point as quickly as we can without being too hackish in our approach.

I agree this is the goal. we get there quickest by building the things
we can today while we resolve the harder issues at the same time.
 
> > > We're ready to go the moment we have finished these tasks:
> > > - the gcc/glibc issues are resolved
> 
> Let's split these in two:
> 
> 1). gcc. Having seen some of the discussion here with Jakub, etc. it's
> clear that the Fedora maintainers aren't going to accept this latest
> volatile bitfields patch unless it's in the upstream 4.6 branch (it is
> in trunk right now). So there are two upstreams to work with - Fedora,
> and GCC. We can try to pursue this, but it is not a quick fix (we're
> looking at several weeks to turn it around). At the same time, this
> stuff is resolved in rawhide (and I think F16). It would be more
> expedient to block updates to gcc being pulled in automatically (which
> won't happen at this stage anyway) and either in parallel fix this or
> undertake to keep a separate gcc. Really, by the time we release F15
> we'll have only 5 months of time when there would be updates anyway.
> 
> 2). glibc. Seems there's a backport that could perhaps be upstreamed,
> and a Java fix that we will need. Again, I favor parallelization. We
> build now and try to find a solution that involves either getting this
> into upstream Fedora 15 PA or finding an alternative. I don't see a
> reason not to build this now though.
> 
> > > - we've pruned the package sets back to the same core
> 
> I think this is straightforward. We include in the repos only the
> build requirements to build a buildroot and start with that. Do some
> closure tests on that set and make sure the same packages exist for
> v5 and v7. I suspect someone could turn that around tomorrow.

there is no need to do any pruning of either package set. after some
further examiniation of the code koji doesnt enforce the strict
matching nvrs in external repos that it does in the repos for packages
built in koji. so what this means is that as long as we are pretty
close we are good to go. at the end we will have a matching package set
on both arches because koji is really good at enforcing that.  so what
we need is to have a mirror of stage4 hfp at
http://australia.proximity.on.ca/fedora-arm/15/armhfp/

we need to get koji updated to the scratch builds i did today. there is
an issue that cropped up that im working on getting a propper fix
upstream in koji, but that will not make any of the build we do today
invalid.  we are close enough in package set that we will not be
getting wild soname differences between the two. thats the main reason
we need them close enough.

ive got koji setup to build things correctly in dist-f15 what we need
now is
1) update koji everywhere to correctly deal with hard and soft float.
2) repo for armhfp
3) generate a newRepo for dist-f15-build
4) start building.

anything that has a different nvr between hfp and sfp we should take
the higher nvr. if the arm fix is already in fedora git we should just
build that package from git. we should not build anything that has the
0.arm etc in it in koji we should build from git the fixed version.
lets build everything in koji we have already built in stage4 and moji.
at the end of doing the builds we will have a extremly solid
foundation. gcc/glibc can get fixed while we build everything else.


> > > - every change/patch in those package sets has been upstreamed
> 
> I was thinking that way, but now I think that is a parallel activity.
> I am all for getting stuff upstreamed, and it will be especially
> important in the coming months, but I think that doesn't need to gate
> the initial build. Packages can keep an armX suffix in the initial
> build, then for the few dozen (after cutting down the initial build
> set) that need to be upstreamed, there will be a higher NVR from
> upstream soon anyway that can be rebuilt for both arches with the
> upstream version.

parallelise everything we can submitting the builds and filling koji is
really only going to take one person. as soon as we have most
everything built we can start on rawhide. i suspect we will have a mass
rebuild for f17 early in the new year. we want to be ready for that.

> IOW I think the initial build should proceed now, but that we should
> not begin building updates or pulling further bits from upstream
> until we have gotten the rest of these deltas resolved. Since the
> upstream version will bump once they're fixed, NVRs are preserved,
> everything will work. The only critical thing is that we didn't bump
> the R in a non-forward thinking fashion, which is why the use of
> the .armX.
> 
> > > - the hub and builders have been successfully set up and tested
> > > with patched koji/rpm/yum etc.
> 
> I think that should be fairly straightforward now. Dennis has patches
> that he has tested in a staging Koji setup so they ought to be
> working.
patches have been tested we are good to go.

> > > Work on all these pieces is proceeding in parallel (assuming that
> > > someone's on the gcc/glibc piece (who?)). We're not blocking on
> > > any one piece, but we have to finish these four before hitting
> > > 'Go'.
> 
> Respectfully, I disagree that we need to block on all of them. I think
> we can begin building, and in parallel upstream whatever can be
> upstreamed, ensuring that for the one or two possible exceptions we
> have a plan for F16/F17 along the lines of "in gcc trunk", etc.

i agree this is not a blocker
 
> > The final patch for gcc, for instance, may never make it into F15.
> > Even the armv7hl spec file changes we pushed upstream are only
> > in .fc16 koji builds at this point.  If these changes are in FC16
> > or rawhide but not F15, isn't that good enough?  Why not build
> > packages in parallel too?
> 
> Well, Chris is naturally going to be concerned about building updates,
> and there is a sense of more correctness in blocking, however I think:
> 
> 1). We need to resolve a few more things before building updates, but
> we buy time to do that and win now by building sooner while we handle
> that.
> 
> 2). We are past the time when we should aim for the most complete F15
> release. F13 was a wonderful example of a quality ARM release that the
> Seneca team (in particular here) should be proud of. BUT there is an
> opportunity here to leave all of these problems in the dust if we can
> just bring F15 to a good enough close and get to rawhide soon.
> 
> I know, I sound pushy. I don't mean to. I'm not calling for the rocket
> to be launched for a manned flight before it's ready, I'm saying F15
> is the test rocket that's going to get us to the moon landing in F17.

f15 release will never be as polished as it could be thats ok. its a
big stepping stone to rawhide and f17, we really have already
completed so much and done some amazing work but its just a big step.
lets not focus on it and not see the whole staircase. f17 should be
the most polished complete release we have had and will help us get a
much wider audience in fedora and outside of it. at least until f18
when we get to shoot for even bigger things.

Dennis