Folks,
I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.?
Jon.
Jon Masters jcm@redhat.com writes:
Folks,
I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.?
Couldn't one write a python script based around yum to generate this dependency list? Obviously you need to seed the list of known packages (filesystem, basesystem, bash, etc) but you could easily create a list of dependencies from the yum repos, no?
Jon.
-derek
On Sat, 2011-06-04 at 09:54 -0400, Derek Atkins wrote:
Jon Masters jcm@redhat.com writes:
Folks,
I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.?
Couldn't one write a python script based around yum to generate this dependency list? Obviously you need to seed the list of known packages (filesystem, basesystem, bash, etc) but you could easily create a list of dependencies from the yum repos, no?
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.
Jon.
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
pass it a pile of packages, and it produces the needed graphviz dot files, from which production of a .ps is trivial
-- Russ herrold
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?).
pass it a pile of packages, and it produces the needed graphviz dot files, from which production of a .ps is trivial
I did this for some of the F13 packages and got quite a nice PDF. I wanted to run this against all of the Seneca built packages but the Panda I have root on stalled installing rpm-devel and I need to do some other stuff now. But next week, I'll do some graphs for the current packages (for interest) and some graphs based on current F15 arches. I think the best thing to do is to take the minimal build root package set for doing these, then we can discuss/cull out things not needed for bootstrapping hardfp on F15. At least, I think this is useful.
Jon.
On Sat, 2011-06-04 at 18:09 -0400, Jon Masters wrote:
pass it a pile of packages, and it produces the needed graphviz dot files, from which production of a .ps is trivial
I did this for some of the F13 packages and got quite a nice PDF. I wanted to run this against all of the Seneca built packages but the Panda I have root on stalled installing rpm-devel and I need to do some other stuff now. But next week, I'll do some graphs for the current packages (for interest) and some graphs based on current F15 arches.
Chris, that's cdot-panda-7-3 that stalled doing the install. Maybe it'll finish eventually, but anyway I'll mirror down the bits I need to do this properly and run it here. Reminds me that I need to poke at rigging up automated mirroring of the Seneca Koji bits over here anyway.
Jon.
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters jcm@redhat.com wrote:
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?).
When I've asked about build ordering in the past I've got the response 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).
- 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.
Peter
On Saturday, June 04, 2011 06:07:05 PM Peter Robinson wrote:
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters jcm@redhat.com wrote:
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?).
When we 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 response 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.
Dennis
On Sun, 2011-06-05 at 00:07 +0100, Peter Robinson wrote:
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters jcm@redhat.com wrote:
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?).
When I've asked about build ordering in the past I've got the response 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.
Well, my question is motivated by two things:
1). We need to solve these problems for Fedora ARM. We might decide to do a mass rebuild in the future if there's another new ABI at some point in the future, and we need a generic way to do this for F-15.
2). I look at what Debian are doing with multi-arch and bootstrapping and a little part of me feels embarrassed (caveat: it's not something we're as concerned about, which is why we haven't done this). I do think there's a lot of cool ideas out there we can learn from other distros.
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:
<snip>
Let's start documenting these. I'm a little tied up this weekend, but I assume you'll be on IRC on Monday? I'd like to at least brainstorm and dump out what we know before mid-week, so we've a chance to collate useful data together for Friday's first v7hl hackathon.
Jon.
On Sun, 2011-06-05 at 00:07 +0100, Peter Robinson wrote:
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters jcm@redhat.com wrote:
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?).
When I've asked about build ordering in the past I've got the response 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).
The problem I see with importing all the noarch packages en masse without other filtering is that there are SRPMs that produce both arch-specific and noarch RPMs, and you'll end up with just the noarch pieces imported, possibly mismatched with the arch-specific pieces. We've seen this through the F13 cycle using the build-previous/koji-shadow tools.
- 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.
The challenge with fedpkg/git is that, as far as I can see, it's not obvious which commit corresponds to a particular NVR; you'd probably have to switch to a particular branch and walk backward through the commits until you find the right ENVR in the spec file.
On the other hand, it's fairly straightforward to grab the right SRPM from the koji package archive as build-previous/koji-shadow do; we're using the same approach in styrene.
-Chris
On Sun, Jun 5, 2011 at 1:54 AM, Chris Tyler chris@tylers.info wrote:
On Sun, 2011-06-05 at 00:07 +0100, Peter Robinson wrote:
On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters jcm@redhat.com wrote:
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?).
When I've asked about build ordering in the past I've got the response 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).
The problem I see with importing all the noarch packages en masse without other filtering is that there are SRPMs that produce both arch-specific and noarch RPMs, and you'll end up with just the noarch pieces imported, possibly mismatched with the arch-specific pieces. We've seen this through the F13 cycle using the build-previous/koji-shadow tools.
- 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.
The challenge with fedpkg/git is that, as far as I can see, it's not obvious which commit corresponds to a particular NVR; you'd probably have to switch to a particular branch and walk backward through the commits until you find the right ENVR in the spec file.
It must be stored in the database somewhere as you can get it from the source parameter so I would assume/hope its just a matter of extracting the appropriate value from a DB somewhere, it could probably be done with the python bindings if I only knew python better :-)
Peter
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3108070
On Sun, 5 Jun 2011, Peter Robinson wrote:
When I've asked about build ordering in the past I've got the response 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.
It is not required to build order, as you'll be doing it all a couple times on progressive 'fruit' passes, from successive boot-strapping passes, to make sure self-hosting exists. That said, getting gcc, glibc, rpm python and the kernel, and the minimal parts needed to boostrap into an install image are the first order of business, and will avoid the need for re-submissions and wasted attempts [knowing BR's permts computation of an efficient , rather than 'random walk' build sequencing]
Then add decoration of needed developer tools; then add end leaf nodes to taste, solving intermediate build requirements as well then
-- Russ herrold
On Sat, 4 Jun 2011, Jon Masters wrote:
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.
This information (BuildRequire-ments) is in the SRPMs and may be queried out reasonably directly with a loop construct. The skript monkey pseudocode looks like this:
foreach i in rpm -qp --qf '%{name}:%{SOURCERPM}\n' \ (binary-package) { # # use ls and grep to ID the particular SRPM to furhter # query the SRPM # SRPM-package = `echo "${i}" | awk -F":" {'print $2'}` foreach j in rpm -qp --requires \ (SRPM-package) { # # aggregate I and J data to taste --- lately I've been # stuffing it into a mysql backend # } } #
************************************************************
which yields for the first case (here against the RPM database, rather than against the package directly):
[herrold@bronson ~]$ rpm -q --qf '%{name}:%{SOURCERPM}\n' rpm rpm:rpm-4.4.2.3-22.el5.src.rpm
[herrold@bronson alpine]$ rpm -qp --requires \ alpine-0.999-2.src.rpm /usr/sbin/sendmail gettext inews krb5-devel ncurses-devel openldap-devel openssl-devel pam-devel passwd sendmail rpmlib(CompressedFileNames) <= 3.0.4-1 [herrold@bronson alpine]$
************************************
simply inventorying the binaries in a minimal build chroot, and tracking them back to their owners tells you the bootstrap minimum; do the tracing with 'rpm -qf (binary) '
-- Russ herrold
On Sun, 2011-06-05 at 09:46 -0400, R P Herrold wrote:
On Sat, 4 Jun 2011, Jon Masters wrote:
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.
This information (BuildRequire-ments) is in the SRPMs and may be queried out reasonably directly with a loop construct. The skript monkey pseudocode looks like this:
foreach i in rpm -qp --qf '%{name}:%{SOURCERPM}\n' \ (binary-package) { # # use ls and grep to ID the particular SRPM to furhter # query the SRPM # SRPM-package = `echo "${i}" | awk -F":" {'print $2'}` foreach j in rpm -qp --requires \ (SRPM-package) { # # aggregate I and J data to taste --- lately I've been # stuffing it into a mysql backend # } } #
which yields for the first case (here against the RPM database, rather than against the package directly):
[herrold@bronson ~]$ rpm -q --qf '%{name}:%{SOURCERPM}\n' rpm rpm:rpm-4.4.2.3-22.el5.src.rpm
[herrold@bronson alpine]$ rpm -qp --requires \ alpine-0.999-2.src.rpm /usr/sbin/sendmail gettext inews krb5-devel ncurses-devel openldap-devel openssl-devel pam-devel passwd sendmail rpmlib(CompressedFileNames) <= 3.0.4-1 [herrold@bronson alpine]$
simply inventorying the binaries in a minimal build chroot, and tracking them back to their owners tells you the bootstrap minimum; do the tracing with 'rpm -qf (binary) '
-- Russ herrold
Right -- but the next question is, what can you build with that "minimal build chroot"? The answer well under half -- closer to 1/3 -- of the Fedora package collection. So the question becomes, what is the minimum seed set needed to produce the entire package collection? And where are there circular dependencies?
-Chris
On Sun, 5 Jun 2011, Chris Tyler wrote:
Right -- but the next question is, what can you build with that "minimal build chroot"? The answer well under half -- closer to 1/3 -- of the Fedora package collection. So the question becomes, what is the minimum seed set needed to produce the entire package collection? And where are there circular dependencies?
I think a better question is to ask: what is needed in distribution design first -- what 'target' is desired? Server, developer's workstation, end user's media device, whatever
Simply saying 'everything in another's design' _may_ be a later goal, but cannot be the first goal, or else one will end up blocked on some obsolete package that no-one uses, and not attain much of anything
I say this having been involved in splitting out a server oriented subset rebuild of the RHEL 6 sources, this spring. If we had implemented 'firstboot' we would have carried in huge GUI and sound tool and library dependeciess that are simply not in scope
Circular build dependencies are not really a big deal -- one codes around them to break the circularlty, to bootstrap into an intitial solve, then re-build from that partial solve, into the full set -- see, eg, in Java space:
[herrold@bronson alpine]$ yum list *nodep* Available Packages ant-nodeps.i386
... similarly on the RHEL 6 sources, there was a non-self-hosting circular dependency on valgrinnd and the OpenMPI drivers
They happen, they get worked around .. no big deal
-- Russ herrold
On Sat, Jun 4, 2011 at 7:25 AM, Jon Masters jcm@redhat.com wrote:
Folks,
I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.?
At the moment there isn't much but I know the Seneca are currently working on a tool to do this. Maybe they can come and discuss it on the list (hint hint!).
Peter
On Sat, 2011-06-04 at 23:07 +0100, Peter Robinson wrote:
On Sat, Jun 4, 2011 at 7:25 AM, Jon Masters jcm@redhat.com wrote:
Folks,
I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon?
Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.?
At the moment there isn't much but I know the Seneca are currently working on a tool to do this. Maybe they can come and discuss it on the list (hint hint!).
I mentioned styrene already, and they're going to :) I'm just impatient (joke), or rather, keen that we all share what we do have/know so that we can build up a variety of useful data ahead of Friday's hackathon. One of the guys here (DJ) who did a minimally bootable F15 hardfp image already (but only containing a small number of cross-built packages and a static dev) has some things that will be posted on the list soon too to help. Anyone else who has any useful bootstrap data, please share.
Jon.
On Sat, 2011-06-04 at 18:16 -0400, Jon Masters wrote:
On Sat, 2011-06-04 at 23:07 +0100, Peter Robinson wrote:
At the moment there isn't much but I know the Seneca are currently working on a tool to do this. Maybe they can come and discuss it on the list (hint hint!).
I mentioned styrene already, and they're going to :)
I pulled the arm git repo and looked at styrene briefly. It seems to process Koji build data and output various metrics, including build dependencies, though I can't see any graphing support in there yet.
To test out the visual part, I copied ps-20110525-dist-f13-@build.db to ps.db and ran the ./httpserv ./ps-visual scripts
Then, I could select e.g. glibc-2.12-1.src.rpm and it would tell me the BuildRequires, what provided them, and where to get that source. I'll ping Jon and Chris on Monday and try to figure out what's in there.
Jon.
-
Chris Tyler -
Dennis Gilmore -
Derek Atkins -
Jon Masters -
Peter Robinson -
R P Herrold