From: Stefan Agner <stefan@agner.ch>
To: Khem Raj <raj.khem@gmail.com>
Cc: luka.pivk@gmail.com,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Lock external repository in custom FSTYPE
Date: Fri, 02 Nov 2018 09:16:07 +0100 [thread overview]
Message-ID: <7025584cb992c6cbbe238164adf8e614@agner.ch> (raw)
In-Reply-To: <e9cebc10a1d7b45d6cddfa83cbb5419f@agner.ch>
On 01.11.2018 23:27, Stefan Agner wrote:
> On 29.10.2018 14:01, Khem Raj wrote:
>> On Mon, Oct 29, 2018 at 5:31 AM Stefan Agner <stefan@agner.ch> wrote:
>>>
>>> Hi,
>>>
>>> We use meta-updater, which has a custom FSTYPE to build a OSTree
>>> repository. We share that repository across multiple bitbake executions.
>>> The underlying OSTree tools lock the OSTree repository before trying to
>>> interact, and if it fails ("error: Locking repo exclusive failed:
>>> Resource temporarily unavailable") then the complete build fails (see
>>> also https://github.com/advancedtelematic/meta-updater/issues/412).
>>>
>>> Now I'd rather prefer that two bitbake tasks would serialize the access
>>> to the OSTree repository. Is there a mechanism in bitbake to lock (and
>>> wait) for the repository to be not in use?
>>>
>>> We tried using bb.utils.lockfile, but the task is written in shell. Also
>>> inline Python would not work since locking/unlocking need to be done
>>> within one Python script as far as I understand.
>>>
>>
>> perhaps you could use lockfiles something like
>>
>> do_foo[lockfiles] = ...
>
> Wasn't aware of the lockfiles varflag, also seems not to appear in any
> documentation. Reading lib/bb/build.py suggests that it really is
I take that back:
https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#variable-flags
--
Stefan
> locking the complete task, exactly what we need.
>
> Added the lockfiles varflag to the do_image_ostree task in
> image_types_ostree.bbclass:
> do_image_ostree[lockfiles] += "${OSTREE_REPO}/ostree.lock"
>
> And run two builds, the OSTree lock issues seem to be gone. Thanks Khem!
>
> --
> Stefan
>
>>
>>> --
>>> Stefan
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
prev parent reply other threads:[~2018-11-02 8:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 12:31 Lock external repository in custom FSTYPE Stefan Agner
2018-10-29 13:01 ` Khem Raj
2018-11-01 22:27 ` Stefan Agner
2018-11-02 8:16 ` Stefan Agner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7025584cb992c6cbbe238164adf8e614@agner.ch \
--to=stefan@agner.ch \
--cc=luka.pivk@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox