All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.