Public TSC / OE Workgroup meeting today

Public TSC / OE Workgroup meeting today

[Paul Eggleton]

Hi all,

There will be a public OpenEmbedded TSC/workgroup meeting today - there 
wouldn't normally be one scheduled but there was quite a lot of discussion 
last time (which is a good thing!). If you're interested in discussing long-
term technical efforts around the OpenEmbedded project please join us on 
irc.freenode.net in channel #oe at 
17:00 GMT (9am PST, 11am CST, 12 EST, 18:00 CET) today.

Topics we covered last meeting:

* Qt 4 / 5 recipes in OE-Core
* Rising bug count in Bugzilla and what we can do about it
* (briefly) Patch review/merging process
* Absentee layer maintainers

Issues we didn't get to last time (that weren't resolved on the mailing list):
- janitorial day/week?
- "bitbake world" failures scrub
- initrdscripts/init-live needs work
- lava evaluation
- website and other infrastructure issues
- next release

New issues for discussion are also welcome.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] Public TSC / OE Workgroup meeting today

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

On Tue, Jan 14, 2014 at 10:08:35AM +0000, Paul Eggleton wrote:
> Hi all,
> 
> There will be a public OpenEmbedded TSC/workgroup meeting today - there 
> wouldn't normally be one scheduled but there was quite a lot of discussion 
> last time (which is a good thing!). If you're interested in discussing long-
> term technical efforts around the OpenEmbedded project please join us on 
> irc.freenode.net in channel #oe at 
> 17:00 GMT (9am PST, 11am CST, 12 EST, 18:00 CET) today.
> 
> Topics we covered last meeting:
> 
> * Qt 4 / 5 recipes in OE-Core
> * Rising bug count in Bugzilla and what we can do about it
> * (briefly) Patch review/merging process
> * Absentee layer maintainers
> 
> Issues we didn't get to last time (that weren't resolved on the mailing list):
> - janitorial day/week?
> - "bitbake world" failures scrub
> - initrdscripts/init-live needs work
> - lava evaluation
> - website and other infrastructure issues
> - next release
> 
> New issues for discussion are also welcome.

Not sure if it's worth new item on agenda, but maybe we should move
meta/classes/image-prelink.bbclass functionality to package.bbclass,
maybe we have more cases like this where image build is changing files
which are provided by normal packages (such cases are lost after
upgrading on device with packagemanager).

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] Public TSC / OE Workgroup meeting today

[Phil Blundell]

On Tue, 2014-01-14 at 13:13 +0100, Martin Jansa wrote:
> Not sure if it's worth new item on agenda, but maybe we should move
> meta/classes/image-prelink.bbclass functionality to package.bbclass,
> maybe we have more cases like this where image build is changing files
> which are provided by normal packages (such cases are lost after
> upgrading on device with packagemanager).

How would that work?  I'm not sure that it's possible (in the general
case) to prelink in any sensible way prior to rootfs construction.  The
same applies to image-mklibs.bbclass.

p.

Re: [oe] Public TSC / OE Workgroup meeting today

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On Tue, Jan 14, 2014 at 12:55:28PM +0000, Phil Blundell wrote:
> On Tue, 2014-01-14 at 13:13 +0100, Martin Jansa wrote:
> > Not sure if it's worth new item on agenda, but maybe we should move
> > meta/classes/image-prelink.bbclass functionality to package.bbclass,
> > maybe we have more cases like this where image build is changing files
> > which are provided by normal packages (such cases are lost after
> > upgrading on device with packagemanager).
> 
> How would that work?  I'm not sure that it's possible (in the general
> case) to prelink in any sensible way prior to rootfs construction.  The
> same applies to image-mklibs.bbclass.

Hmm, you're right.

The reason why I was thinking about this, is that someone reported to me
that libc-dbg doesn't work after prelink changed libc headers in
do_rootfs (external toolchain).

IIRC there was some discussion about issues caused by prelink changing headers,
I'll try to find it in archives, sorry for noise.
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] Public TSC / OE Workgroup meeting today

[Mark Hatle]

On 1/14/14, 6:13 AM, Martin Jansa wrote:
> On Tue, Jan 14, 2014 at 10:08:35AM +0000, Paul Eggleton wrote:
>> Hi all,
>>
>> There will be a public OpenEmbedded TSC/workgroup meeting today - there
>> wouldn't normally be one scheduled but there was quite a lot of discussion
>> last time (which is a good thing!). If you're interested in discussing long-
>> term technical efforts around the OpenEmbedded project please join us on
>> irc.freenode.net in channel #oe at
>> 17:00 GMT (9am PST, 11am CST, 12 EST, 18:00 CET) today.
>>
>> Topics we covered last meeting:
>>
>> * Qt 4 / 5 recipes in OE-Core
>> * Rising bug count in Bugzilla and what we can do about it
>> * (briefly) Patch review/merging process
>> * Absentee layer maintainers
>>
>> Issues we didn't get to last time (that weren't resolved on the mailing list):
>> - janitorial day/week?
>> - "bitbake world" failures scrub
>> - initrdscripts/init-live needs work
>> - lava evaluation
>> - website and other infrastructure issues
>> - next release
>>
>> New issues for discussion are also welcome.
>
> Not sure if it's worth new item on agenda, but maybe we should move
> meta/classes/image-prelink.bbclass functionality to package.bbclass,
> maybe we have more cases like this where image build is changing files
> which are provided by normal packages (such cases are lost after
> upgrading on device with packagemanager).

We can discuss this, but prelink has to run on the filesystem image -- it can't 
run prior to packaging as the files installed into the image affect the results 
of the prelinking.

For the prelink case, on target updates should be triggering the prelink system 
after the update.  This is the responsibility of the field-upgrade software -- 
whatever is deployed on the device itself.

(Also when using the prelinker, on many devices it makes sense to strip the 
un-prelink information for space savings.  This won't prevent prelink from being 
run a second time -- it just prevents validation of the original not-prelinked 
binary.)

--Mark

> Cheers,
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>