From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [oe] Public TSC / OE Workgroup meeting today
Date: Tue, 14 Jan 2014 09:54:45 -0600 [thread overview]
Message-ID: <52D55DC5.1030509@windriver.com> (raw)
In-Reply-To: <20140114121347.GB3717@jama>
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
>
prev parent reply other threads:[~2014-01-14 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 10:08 Public TSC / OE Workgroup meeting today Paul Eggleton
2014-01-14 12:13 ` [oe] " Martin Jansa
2014-01-14 12:55 ` Phil Blundell
2014-01-14 13:33 ` Martin Jansa
2014-01-14 15:54 ` Mark Hatle [this message]
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=52D55DC5.1030509@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@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