[OE-core] [PATCH 2/3] systemd: Upgrade to 206

Khem Raj raj.khem at gmail.com
Tue Aug 27 04:53:02 UTC 2013


On Aug 26, 2013, at 7:40 PM, Jonathan Liu <net147 at gmail.com> wrote:

> On 22 August 2013 14:31, Khem Raj <raj.khem at gmail.com> wrote:
>> Add new PACKAGE systemd-rpm-macros, this will hold
>> the macros which are interesting when rpm is used as
>> package management backend
>> 
>> Forward port uclibc only patches. Add a new patch
>> to stub out use of preadv/pwritev in testcases
>> 
>> Delete patches that have been merged upstream in systemd
>> 
>> Remove force export of GPERF variable in environment
>> this was causing AC_CHECK_TOOL to not populate GPERF
>> variable as expected
>> 
>> systemd needs kmod to be present on rootfs so add it
>> to RDEPENDS
>> 
>> some services substitute discovered kmod when the service
>> file is generated during boot, however the discovered kmod
>> is from native sysroot and it gets into the service file
>> with absolute path. So specify the target path of kmod using
>> KMOD variable so the unit files have correct pointer to kmod
>> on target
>> 
>> Add a patch to make sure that mknod capability is checked
>> before the service which excercise mknod, this patch is also
>> submitted to upstream systemd
>> 
>> Signed-off-by: Khem Raj <raj.khem at gmail.com>
> 
> Arch Linux had some issues with systemd 206 with regard to device
> nodes in /dev getting wrong permissions:
> https://bugs.archlinux.org/task/36259
> 
> I wonder if we need to add patches for that as well:
> http://cgit.freedesktop.org/systemd/systemd/patch/?id=15a722007dc1d8a9a11934b2ab528cf4d25b6c62
> http://cgit.freedesktop.org/systemd/systemd/patch/?id=a2aced4add1964f82cfd250f1fee8de9d974b507
> http://cgit.freedesktop.org/systemd/systemd/patch/?id=5c7951141fa9f33e1b97de97586cc16bce2776e0
> http://cgit.freedesktop.org/systemd/systemd/patch/?id=ec99834cb0e76a9e7096bd42249053712db9c32d

With the testing on 3.8 kernel at that time, I did not have see issues. However if we are able to have reproducers
we can cherry pick needed fixes at later stage. Lets see the breakage for our case first.

> 
> Regards,
> Jonathan




More information about the Openembedded-core mailing list