Op 30 aug. 2011, om 11:39 heeft Paul Eggleton het volgende geschreven:
> 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.
The angstrom-version recipe does this:
do_install() {
install -d ${D}${sysconfdir}
echo "Angstrom ${DISTRO_VERSION} (Core edition)" >
${D}${sysconfdir}/angstrom-version
echo "Built from branch: ${METADATA_BRANCH}" >>
${D}${sysconfdir}/angstrom-version
echo "Revision: ${METADATA_REVISION}" >> ${D}${sysconfdir}/angstrom-version
echo "Target system: ${TARGET_SYS}" >> ${D}${sysconfdir}/angstrom-version
echo "NAME=Angstrom" > ${D}${sysconfdir}/os-release
echo "ID=angstrom" >> ${D}${sysconfdir}/os-release
echo "PRETTY_NAME=The Ångström Distribution" >> ${D}${sysconfdir}/os-release
echo "ANSI_COLOR=1;35" >> ${D}${sysconfdir}/os-release
install -d ${D}${bindir}
install -m 0755 ${WORKDIR}/lsb_release ${D}${bindir}/
}
So if METADATA_* becomes more usefull, angstrom-version becomes more usefull :)
Slightly off-topic: maybe we should try to standardize /etc/<distro>-release in
the OE-core universe, like systemd is standardizing /etc/os-release.
>> 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?
>From what I've seem 'hob' hides pretty much everything as well so a web
>version of it would be suitable as a narcissus replacement. I will postulate
>that people using 'hob' or narcissus aren't distro developers and just want to
>get a rootfs with their set of features. The feedback I get about narcisuss'
>simple mode is that it has too many choices already :)
regards,
Koen
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
