[OE-core] [PATCH 00/21][RFC v3] systemd Integration

Saul Wold sgw at linux.intel.com
Fri Jan 11 17:45:13 UTC 2013


On 01/11/2013 07:12 AM, Radu Moisan wrote:
>
> On 01/10/2013 08:27 PM, Khem Raj wrote:
>> On Thu, Jan 10, 2013 at 12:02 AM, Radu Moisan <radu.moisan at intel.com>
>> wrote:
>>> On 01/09/2013 07:14 PM, Khem Raj wrote:
>>>> On Tue, Jan 8, 2013 at 4:24 AM, Radu Moisan <radu.moisan at intel.com>
>>>> wrote:
>>>>> As Ross suggested I've done the following changes to the previous set:
>>>>> * added two patches (the first two) that address multiple init systems
>>>>> support,\
>>>>> as in shifting from default hardcoded sysvinit to something more
>>>>> generic
>>>>> while
>>>>> the default values still remains on sysvinit
>>>>> * moved automatic setting of PREFERRED_PROVIDER_udev into
>>>>> default_providers.inc
>>>>> * removed ahavi-systemd since all it provided was service files; now
>>>>> service files
>>>>> are pulled in by avahi-daemon
>>>>> * also rebased on master
>>>>>
>>>> btw. there has been more merges into meta-systemd in meta-openembedded
>>>> since these patches were created I cant accertain
>>>> that you picked those too but please redo this series so the history
>>>> is a bit better for tracking purposes.
>>> I've tried to get in sync with meta-openembedded until they upgraded
>>> systemd
>>> to v196.
>> hmm that would also explain the -lrt problem that Saul is seeing but I
>> dont.
>>
>
> Not quite, the problem Soul is seeing is probably because he is using
> eglibc v2.17
> I'm running a world build right now (with eglibc v2.16) and I don't see
> those problems.
>

Radu, you I was testing with 2.17, and we need to prepare for the 2.17 
update occuring, if it occurs before systemd or after these fixes will 
be needed to happen.

>>   I tried to upgrade but something changed in the latest version and
>>> dbus-daemon didn't start anymore and because of that a few other
>>> services
>>> depending on it. I spent some time debugging it but eventually I
>>> decided we
>>> should go with the previous version and address the update after we
>>> merge.
>>> More details about this at
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1625
>> but we have to fix it I think weather you merge it or not since I
>> dont  expect
>> us to stay at 195 forever and especially when folks who use meta-systemd
>> are already using 196 we wont be able to discard meta-systemd.
>
> It's not a question of fixing it or not, rather of when will we fix it.
> My approach was to have a buildable version
> that is also stable at runtime and merge that into oe-core. The we will
> address systemd upgrade as a normal
> package upgrate, since package upgrade is routine task anyway and we do
> it for all packages.
As mentioned above, we will need the updated version of systemd & 
friends before we can update eglibc, we want both systemd and eglibc in 
for the M3 build.

> I also took a look over latest patches on meta-openembedded since
> systemd update, and there aren't that many changes that are relevant to
> oe-core. Any way I'll get back with a new separate branch for review
> (with systemd v196).
>
> Radu
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>




More information about the Openembedded-core mailing list