Extras Rebuild?

Toshio Kuratomi toshio at tiki-lounge.com
Sun May 22 01:42:40 UTC 2005


On Sat, May 21, 2005 at 07:36:44PM +0200, Michael Schwendt wrote:
> On Sat, 21 May 2005 09:30:37 -0700, Toshio Kuratomi wrote:
> 
> > Any news on when a mass rebuild of Extras packages might be expected?  I've
> > just installed a new machine and found that some of the packages are
> > straight imports from the FC3 tree (on x86_64).  Sooner is better than later
> > so people can start looking at why these things are failing.
> 
> We need better organisation than arbitrary mass rebuilds. By now we should
> be pretty much complete with regard to every package having an owner with
> CVS access (except for a very few individuals, who are missing, and one or
> two, who can't sign up yet).
> 
Right.  But we have a bunch of broken packages in the devel repository that
need dealing with some way before FC4 is released.  And we have a bunch of
packages in unknown state because they haven't been rebuilt since FC3.

> For the last rebuild of ~400 packages on April 7th, the situation was
> different. Pre-Extras, builds for specific archs, packagers waiting for
> CVS access, FC4Test releases being out already, GCC 4 rebuilds happening
> in Rawhide after the wait for the compiler being considered good enough;
> many factors resulted in the Extras Development repository being
> out-of-sync with either CVS or with the Extras-for-FC3 repository.
> 
The major problem in my mind being that previous rebuilds didn't result in
bugzilla bugs being filed.  The packages that are currently out of sync,
imported to the devel tree but not rebuilt, etc aren't all being tracked so
it takes effort for a non-maintainer (or maintainer of many (too many?)
packages to figure out what stll needs fixing.

With the new buildsys and policies this will be easier to assess in FC5.
But right now it's a hodgepodge and we need to sort it out someway before
FE packages can be released.

> Nowadays, we need a roadmap. A schedule according to which packagers
> prepare their Extras packages, so when FC4 is released, FE4 is available,
> too, and doesn't make us look bad.
> 
To prevent FE4 from looking bad, we need to be sure nonworking packages in
the devel repository don't go into the FE4 repository.  Things that haven't
been rebuilt, that are not building on all platforms, are known to crash on
one of the supported architectures, etc have to remain in devel.  This can
be achieved either through package maintainers or through community members.
If it's community members who are merging fixes, then something that would
help me, as a community member, to figure out which packages that I care
about are in need of work, would be a complete record of what packages have
failed rebuild.  This info isn't in bugzilla.  It isn't in the build logs.
It *is* in the repository but isn't easy to extract:
  Is the package available on all architectures and has been rebuilt at a
  sufficiently recent date that all its buildrequirements had been updated
  to a final enough version.

> Bill Nottingham some days ago posted a list of Extras packages to
> maintainers-list, which need a rebuild, because of version mismatches on
> the three archs we build for. We should assume that package maintainers
> have noticed that list.
> 
But it wasn't.  Or maintainers don't all have enough time to work on them.
We need to have these filed in bugzilla and become a dependency of the
FE4Tracker bug so the community can take a look at these problems.

My problem with the way FE4 stands is that we haven't recorded the status of
our packages.  So where do we currently stand?  Which packages from Bill's
list are still a problem?  Which packages pulled down from the yum 
repository will work and which will not?  Which packages have been
compiled against a sufficiently new version of FC4 and which have been built
with older versions that A) will evoke bugs when run on FC4 or B) won't
rebuild against FC4.

> In addition to that, the FE4Target tracker contains a list of broken
> packages, which failed to rebuild for FC4 or which fail due to serious
> defects. These are issues a mass rebuild is unlikely to fix. As some of us
> have attached patches to some of the bugs, how long do we wait for a
> reaction from the package owner?
> 
Email the owner.  Try to get one other person to review the change.
Eventually merge yourself.  We need to evolve some policy here.  To be
useful for FC4, though, we need to come up with something sane quickly
as we need to merge those fixes and test them.
  
Side note: Although I've been browsing the FETracker bugs to find things to
fix, it strikes me as the wrong way to address FE (as we have it setup.)  If
individual maintainers are responsible for bringing the packages to
readiness, then the packages will make it into the FE4 repository when
they're ready rather than the FE4 repository will be released when the FE4
packages are ready.  This is in contrast to the FC4 Trackers which, in
theory, describe all the changes that must occur before FC4 can ship.

For Extras in its present incarnation, it makes more sense to have
per-package trackers.  If a package has remaining issues, it doesn't
make it into the FEx repository.


> Package owners can decide better whether to rebuild a package or whether
> to apply upstream updates first. Either we do have package maintainers or
> we don't.
> 
All issues should be tracked in bugzilla.  Then the maintainer can mark them
as UPSTREAM if they'll be done on an update rather than fixed locally.

Among other things, this means build failures should go in bugzilla (perhaps
the buildsystem can do this just as it emails out failures.  The problem is
a bit harder than email as we probably want to update older build failures
rather than create new ones and close out old ones when the build succeeds.
Perhaps an approach such as having a buildsystem bugzilla account be the
submitter or a BUILDFAIL keyword.)  The bugzilla tickets can be used to
track the current status of a package.

> Concerning GCC4, is there a specific release of the gcc package, after
> which all packages in Extras should have been rebuilt [in order to
> benefit from compiler fixes]?
> 
I also wish I knew the answer to this.  More than compiler fixes, though, we
also have to make sure the extras packages utilize the latest versions of
the toolchain as a whole.  Otherwise bugs can occur in FE that stem from FC
updates.

One way to resolve this would be to not push things into the FE4 repository
until an FC4 repository (for the buildsystem) was available.  Mantainers
that want their packages in FC4 need to make a request to the buildsystem
after this is available.  (In some future incarnation, the buildsystem could
queue FCn+1 requests and start building when the FCn+1 repository opened.)

> > PS: Thought for FC5 -- Could we have automated rebuilds for Extras after
> > each test release?  For community members to contribute to fixing packages we
> > need to be able to generate lists of packages which are failing.  Since
> > development means people are using eats-my-babies rawhide it would make more
> > sense to have the development packages be auto-built so breakage can be
> > discovered in the development stage.
> 
> We seriously need to develop a feeling for the dependencies of each of our
> packages. As soon as the next Fedora Core Development starts and the FC-4
> branch has been created, rebuilds from within FE "devel" could be
> requested by the package maintainers.
> 
> Same as above here. We do need a roadmap and a development model. If
> somebody depends on packages, which have not been rebuilt, does he wait or
> does he request rebuilds himself or by contacting the package owner first?
> Unattended mass rebuilding all (!) of Extras would give a false impression
> of what is maintained and what is not. 

I think automated rebuilds help the community see problems.  An automated
rebuild can lead to a build failure which can lead to a commnity member
sending patches which leads to the realization that a particular maintainer is
overworked.  An overworked maintainer that doesn't request rebuilds and
doesn't request help will lead to a package that silently disappears from
the FE repository in future versions of FC.

OTOH, there are definitely better ways to achieve this than automated
reuilding so I'll drop my suggestion to do it for FC5 if we can put together
a better mechanism.

> E.g. after the April 7th rebuild,
> some packagers did version upgrades almost immediately. The point of
> rebuilding the old package versions was what? Community contributors
> spending time on fixing broken rebuild attempts for a FC test release is
> wasted time if the package owner just waits and applies an upstream update
> a few weeks later.
> 
Very true.  We need to track a packages status and future direction.
Bugzilla.

> I consider mass rebuilds a bottom-up "brute force" approach to try fixing
> something where no top-down approach is available. More helpful in my
> opinion would be, at least, to try coming up with a roadmap for Fedora
> Extras and then find out where we encounter any difficulties.
> 
I agree.

Do we have a top-down approach tha will allow us to get FE4 out
when FC4 hits the streets or do we have nothing better than the brute force
approach at this point?

I agree with your assessment (pretty much your entire message) of where we
want to be.  My question is can we get there in time for FC4 or do we need a
stop gap for FC4 and something that is designed to work well for FC5-devel?

-Toshio




More information about the fedora-extras-list mailing list