TSC meeting minutes 20100204

TSC meeting minutes 20100204

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TSC Meeting 20100204

Attendees: Chris, Graeme, Koen

Looking back a the past month the naming and shaming campaign for bad
commit messages seems to work well. People also seem to be able to solve
problems themselves instead of moving everything to the TSC.

The TSC also discussed where variable defaults should be and Chris is
going to start a wiki to form an idea on the scope of the cleanup and
gauge interest in a 'kernel janitors' type of project for it.

The TSC is also wondering what our userbase wants OE to be like and what
to focus on, but we need to find the right tools to ask such questions
first, the website vote method is just too passive.

On overriding default variables the TSC is very clear: we should try to
make it impossible to do things like PACKAGES = "of". An idea would be
to move the PACKAGES =+ -dbg, -dev, doc to e.g. package.bbclass. More
thought on this is needed.

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.

The consensus in the TSC is that DISTROs are in charge of enabling
packaged-staging or not, but keeping the non-packaged-staging working
well is not a priority.

End of meeting

Postscript: Richard mentions that keeping non-packaged staging working
will be a major pain, so DISTRO maintainers should aim to enable it so
OE can move forward.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLbpmlMkyGM64RGpERAtgXAJ9q7s562EhMwdNRbfBcu2R+1dVwywCfdPEl
rgF/e2PDzsBkUj0Kf12y/wE=
=kLei
-----END PGP SIGNATURE-----

Re: TSC meeting minutes 20100204

[Frans Meulenbroeks]

2010/2/7 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> TSC Meeting 20100204
>
> Attendees: Chris, Graeme, Koen
>
> Looking back a the past month the naming and shaming campaign for bad
> commit messages seems to work well. People also seem to be able to solve
> problems themselves instead of moving everything to the TSC.
>
> The TSC also discussed where variable defaults should be and Chris is
> going to start a wiki to form an idea on the scope of the cleanup and
> gauge interest in a 'kernel janitors' type of project for it.
>
> The TSC is also wondering what our userbase wants OE to be like and what
> to focus on, but we need to find the right tools to ask such questions
> first, the website vote method is just too passive.
>
> On overriding default variables the TSC is very clear: we should try to
> make it impossible to do things like PACKAGES = "of". An idea would be
> to move the PACKAGES =+ -dbg, -dev, doc to e.g. package.bbclass. More
> thought on this is needed.
>
> 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.

FM
>
> The consensus in the TSC is that DISTROs are in charge of enabling
> packaged-staging or not, but keeping the non-packaged-staging working
> well is not a priority.
>
> End of meeting
>
> Postscript: Richard mentions that keeping non-packaged staging working
> will be a major pain, so DISTRO maintainers should aim to enable it so
> OE can move forward.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFLbpmlMkyGM64RGpERAtgXAJ9q7s562EhMwdNRbfBcu2R+1dVwywCfdPEl
> rgF/e2PDzsBkUj0Kf12y/wE=
> =kLei
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: TSC meeting minutes 20100204

[Koen Kooi]

-----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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLbu2PMkyGM64RGpERAu7mAJ9PqpwZImQhwqfIV0FMHfPWSi1FIwCeNmaw
PpNKyeulG1H+/qhtOa3ilI0=
=Y9hf
-----END PGP SIGNATURE-----

Re: TSC meeting minutes 20100204

[Frans Meulenbroeks]

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?

Frans

Re: TSC meeting minutes 20100204

[Koen Kooi]

-----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-----

Re: TSC meeting minutes 20100204

[C Michael Sundius]

> >> 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,
>
I, too, am still a little unclear  regarding how the new style staging
works. Are you saying that we are able now to simply remove the do_stage()
function and bitbake will somehow just know which files are intended to be
staged from the install.. what if a [say header] file that was not
previously "installed" is required by a dependent recipe?

> 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 :)


further, if Franz simply builds just one recipe (say "B") that depends on
another recipe ("A"), B might not make use of all the files staged by A,
whereas a 3 recipe may use some other files... so that method of testing is
not sufficient.... I *think* that is what Koen was saying in his most recent
reply.. right?

Still, is there some documentation on exactly how you are supposed to do the
"new-style" staging and how it works...

thanks mike

Re: TSC meeting minutes 20100204

[Graeme Gregory]

On Mon, Feb 08, 2010 at 09:27:34AM -0800, C Michael Sundius wrote:
> I, too, am still a little unclear  regarding how the new style staging
> works. Are you saying that we are able now to simply remove the do_stage()
> function and bitbake will somehow just know which files are intended to be
> staged from the install.. what if a [say header] file that was not
> previously "installed" is required by a dependent recipe?
> 
Your do_install should already be doing everything to make sure all needed
headers are installed. Otherwise builds on your target device wont work.

This change means that package-dev packages and staging should effetively
be identical to build against. If there is a missing header library or
anything else then improve the do_install()

Graeme

Re: TSC meeting minutes 20100204

[C Michael Sundius]

On Mon, Feb 8, 2010 at 9:40 AM, Graeme Gregory <dp@xora.org.uk> wrote:

> On Mon, Feb 08, 2010 at 09:27:34AM -0800, C Michael Sundius wrote:
> > I, too, am still a little unclear  regarding how the new style staging
> > works. Are you saying that we are able now to simply remove the
> do_stage()
> > function and bitbake will somehow just know which files are intended to
> be
> > staged from the install.. what if a [say header] file that was not
> > previously "installed" is required by a dependent recipe?
> >
> Your do_install should already be doing everything to make sure all needed
> headers are installed. Otherwise builds on your target device wont work.
>
> This change means that package-dev packages and staging should effetively
> be identical to build against. If there is a missing header library or
> anything else then improve the do_install()
>
> Graeme
>
> OK, yea, that makes sense.. thank you.

mike