On 07/10/2013 07:45 PM, Martin Jansa wrote:
On Wed, Jul 10, 2013 at 06:39:20PM +0100, Paul Eggleton wrote:
Hi Mike,
On Wednesday 10 July 2013 15:05:23 Mike Looijmans wrote:
I added a buildserver that also exports its "sstate-cache" directory, so
that other build machines can grab their stuff from it. This works fine,
but I have one problem. Some packages are meant to be dependent on the
system that built it. I want to enforce that each build machine creates
its own package, and does not grab it from the sstate-cache of the
central server.
For example,
$ cat recipes-core/meta/distro-feed-configs.bbappend
PRINC="1"
DISTRO_HOST_NAME ?= "${@os.uname()[1]}"
DISTRO_FEED_NAME ?= "feed"
DISTRO_FEED_PREFIX = "topic"
DISTRO_FEED_URI =
"http://${DISTRO_HOST_NAME}/${DISTRO_FEED_NAME}/${MACHINE}";
The purpose being that the host name of the machien that built the image
ends up in the opkg config files. This works just fine.
Now that we have a central server, all images on all build hosts grab
the package from the sstate-cache server, resulting in the feed pointing
to the central server instead of the private one, which is not what I
wanted to happen.
After reading the documentation, I added the following line to the recipe:
PACKAGE_ARCHS[vardeps] = "DISTRO_FEED_URI"
This did not have the desired effect. The package is still retrieved
from the cache, and not rebuilt locally. Even if I clean and force a
rebuild of the distro-feed-configs package, the package that ends up in
the image is still the one from the central server.
What am I missing here?
I think distro-feed-configs (from meta-oe, not OE-Core) is for package
installation on the target, and has nothing to do with shared state.
I'm not sure if it's entirely appropriate, but you could take a similar
approach to the one we use for preventing native sstate packages from mixing
across different distributions (mostly to sidestep host glibc version
dependency problems) - set SSTATE_EXTRAPATH to some value for the recipes you
don't want to share and then the packages will go into a subdirectory named
with that value; you could then delete these automatically from the server.
I would try to add
DISTRO_HOST_NAME[vardepvalue] = "${DISTRO_HOST_NAME}"
that way each builder should create own sstate archive.
I forgot to give my final feedback on this, it would be impolite to ask
for advise and don't report back on whether it was useful, so here goes:
I've been using that setting for a while now and it does exactly what I
wanted it to do. Every build machine creates its own feed configuration,
while the big buildserver creates about everything else. The shared
state cache is a big time saver for us.
Thanks!
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u
verzocht de afzender hierover direct te informeren en het e-mail bericht met de
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht,
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.
The contents of this message, as well as any enclosures, are addressed
personally to, and thus solely intended for the addressee. They may contain
information regarding a third party. A recipient who is neither the addressee,
nor empowered to receive this message on behalf of the addressee, is kindly
requested to immediately inform the sender of receipt, and to destroy the
message and the enclosures. Any use of the contents of this message and/or the
enclosures by any other person than the addressee or person who is empowered to
receive this message, is illegal towards the sender and/or the aforementioned
third party. TOPIC Embedded Systems is not liable for any damage as a result
of the use and/or acceptance of this message and as well as any enclosures.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
