Openembedded Devel Discussions
 help / color / mirror / Atom feed
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-----




  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