From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: TSC meeting minutes 20100204
Date: Mon, 08 Feb 2010 14:39:45 +0100 [thread overview]
Message-ID: <hkp46v$tv8$1@ger.gmane.org> (raw)
In-Reply-To: <ac9c93b11002080525l4399ea54h23d387c8ce2f9024@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08-02-10 14:25, Frans Meulenbroeks wrote:
> 2010/2/7 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07-02-10 17:21, Frans Meulenbroeks wrote:
>>
>>> The last two items discussed were new-style staging and packaged
>>> staging. The TSC would like to *strongly* encourage people to move their
>>> recipes to new style staging. If you are using packaged-staging with a
>>> big TMPDIR (e.g. a few machines with big images built) legacy staging
>>> will easily take more than 15 minutes per recipe because it scans
>>> through the complete staging looking for changes.
>>>
>>>> Maybe I missed a thing, but can someone provide a pointer to how a
>>>> good recipe with new style staging should look like?
>>>> I'll happily modify the recipes I touch regularly, but don't exactly
>>>> know what to do.
>>
>> New-style staging means it has no do_stage method defined anymore (and
>> not getting one thru things like autotools_stage.bbclass as well).
>> It will re-use the output of do_install() to populate staging and run QA
>> checks on.
>>
>> You can check it building it and and looking for messages like "Legacy
>> staging enabled", which would tell you it's still using the old, slow
>> method.
>>
>> regards,
>>
>> Koen
>
> Did a quick grep, there are still some 1400+ recipes that have a
> do_stage. Now some of them are older versions (e.g. there are 6
> xorg-lib/pixman recipes).
> I'm more than happy to do my part of the cleaning but....
> Almost most of the packages are things I don't know too much about.
> What I can do (with packaged staging) remove do_stage, build, build a
> package that depends on it and if that builds commit my work. Is that
> considered to be good enough?
You can compare the contents of the packaged-staging packages to see
differences between then. That's what I do as a first check. Building
something against it is the second check :)
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFLcBQhMkyGM64RGpERAot+AJ0fcQaGsHWHk107ChvoVnSO2saQ3wCeMZ/O
/jHZMEcEaVKXoqMRPa/Jg0U=
=V1gH
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-02-08 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-07 10:44 TSC meeting minutes 20100204 Koen Kooi
2010-02-07 16:21 ` Frans Meulenbroeks
2010-02-07 16:42 ` Koen Kooi
2010-02-08 13:25 ` Frans Meulenbroeks
2010-02-08 13:39 ` Koen Kooi [this message]
2010-02-08 17:27 ` C Michael Sundius
2010-02-08 17:40 ` Graeme Gregory
2010-02-08 17:47 ` C Michael Sundius
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='hkp46v$tv8$1@ger.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
/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