On Saturday, June 04, 2011 06:07:05 PM Peter Robinson wrote:
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters <jcm(a)redhat.com>
> On Sat, 2011-06-04 at 16:40 -0400, R P Herrold wrote:
>> On Sat, 4 Jun 2011, Jon Masters wrote:
>> > Oh, it can all be done :) I'm just curious what exists already.
>> > Perhaps Dennis can help fill in some gaps here. Also, I know of at
>> > least one script already I've pinged someone else about.
>> umm -- in rpm-devel package, rpmgraph has been present for a
>> long, long time
> Thanks for the pointer. I actually didn't know about rpmgraph. I
> probably should have, and now I do :) This gives the kind of data I am
> looking for as a good starting point. I'd like to take all of the F15
> packages and prepare some graphs to look at/discuss before Friday. In a
> perfect world, we'd have dependency data on packages so we can exclude
> non-bootstrap bits (functionality we don't need for bootstrap), but that
> data isn't available, so we'll have to cull the graph a little manually.
> One of the outcomes I would like to see from the ARM v7 bootstrap is
> better documentation on new arch bringup for Fedora, since this is
> unlikely the last time it'll happen in general. Graphing and determining
> necessary orderings for rebuilding the universe is part of it. I'm also
> curious what the mass-rebuild rel-eng efforts use to do ordering (not
> quite the same problem but they must use something for this, Dennis?).
do mass rebuilds for fedora there is no ordering, we make sure that
the thing we are rebuilding for is built then we go a-z
When I've asked about build ordering in the past I've got the
in that there isn't any (not answering for dennis here) and they
basically build the core required bits and then set off the mass
rebuild. The scripts they've used in the past are in the host-eng trac
git so that should give you some more details.
I'm also interested in some other central tools and scripts that would
make it easier for secondary arches. It seems they all have useful
tools that aren't generally available. Some ideas I've had or seen
other secondary arches use are:
- I've seen the PPC guys produce some cool graphs of the difference
between release X and their arch.
- A script to import noarch packages into the secondary koji instance
would useful. At the moment you end up downloading all the packages of
a particular spec (assuming you know its completely noarch), importing
and tagging them. To have something like "blah --importnoarch dist-XX
NVR" as well as to do all noarch for a particular tag (possibly
something to shadow import too).
this should be simple to write
- A way to build an NVR for a tag on secondary. At the moment there
doesn't seem to be any easy way to do this. You can clone the
package's git and use fedpkg. Post git you can get the git url from
koji. Even a couple of commands that you can chain would be useful.
Something like "koji buildurl tag NVR" to return the git:// which you
can then feed to something else. It saves a lot of time of either
unnecessarily cloning 1000s of package repos or trolling through koji
to work it out.
as should this,
Ill try write some scripts for these this week.