Koen Kooi wrote: > Op 30 aug. 2011, om 09:55 heeft Paul Eggleton het volgende geschreven: >> >> * Have a closer link to the actual package building on the backend >> (BitBake), so anyone can see when the last set of packages were built or >> if there is a build currently in progress. > > The problem is that narcissus knows nothing about bitbake, it's just a > fancy way of 'opkg update ; opkg install foo'.
Yes, and I'm not necessarily suggesting a deviation from that. I figured assuming that continues to be the model, it might still be nice to get some more visibility into the actual build process, but no control over it from the web interface. > If we continue with that > model, we have the following to work with: > > 1) /etc/angstrom-version: > > root@beagleboard:~# cat /etc/angstrom-version > Angstrom v2011.08-core (Core edition) > Built from branch: master > Revision: 4816116d9c08c82e38dc5d95a170e2904bfe3786 [1] > Target system: arm-angstrom-linux-gnueabi BTW will this revision information be expanded for the OE-core model of multiple metadata repos? Might be ugly but it seems to me the single revision isn't as useful as it was previously. > Now, suppose we break with the 'opkg update ; opkg install foo' model and > start leveraging sstate we can have a 'toplevel' thing that manages both > narcissus options (read: package checkboxes) and autobuilder config (read: > list of recipes to build): > > 1) have an autobuilder build the machine x packages set daily and store > info (success, revisions, etc) into a shared db > 2) make narcissus pull info from that db when presenting the options. > > As more hardware becomes available we could even have narcissus add the > build to a workqueue for the autobuilder directly. This needs to be > considered carefully, since the plain 'opkg install' method is already > eating a big chunk of IO. The Oregon instance of narcissus is already > using an SSD for the workdir since a spinning disk was too slow for the > workload. Have a look at the last 30 days: > > http://narcissus.angstrom-distribution.org/graph.php?timeframe=30 > > or the past year for beagleboard: > > http://narcissus.angstrom-distribution.org/graph.php?timeframe=365&machine=beagleboard > > The images aren't small either: > > 20110830 06:07:51 akita 95M > 20110830 07:12:51 beagleboard 30M > 20110830 07:40:10 beagleboard 692M > 20110830 07:41:26 beagleboard 8.6M > 20110830 07:44:43 dm355-leopard 31M > 20110830 07:49:13 beagleboard 35M > 20110830 07:52:26 beagleboard 30M > 20110830 07:58:57 beagleboard 322M > 20110830 07:59:54 omap3evm 456M > 20110830 08:15:41 at91sam9263ek 32M > 20110830 08:32:13 h2200 93M > 20110830 08:51:20 beagleboard 13M > 20110830 08:56:02 beagleboard 258M > 20110830 09:02:20 beagleboard 48M > > With all this info being known and the fact that narcissus will run > parallel to echo for the time being, what design should we choose? Well, one thing to consider as well is that it's very likely at some point in the near future that we will be writing a BitBake web-UI within the Yocto Project, and although it has not been designed yet I would expect that to be along similar lines to the "hob" GTK2+-based UI, at least in terms of the options it allows the user to change. The question is though, in a distro like Angstrom where you've specified quite a lot of policy (preferred versions, features, etc.) that you wouldn't necessarily want to allow the user to configure, does a UI at the BitBake level make sense? Cheers, Paul ----- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
