[OE-core] [PATCH 1/4] systemd: Remove items that made this machine (qemu) specific
Mark Hatle
mark.hatle at windriver.com
Sat Oct 20 16:14:53 UTC 2018
On 10/20/18 3:41 AM, Richard Purdie wrote:
> On Wed, 2018-10-17 at 12:43 -0400, Mark Hatle wrote:
>> Create a new systemd-conf recipe to contain the specific
>> system/machine
>> configuration items. This new package is now machine specific.
>>
>> Without doing this trying to create a single system with multiple
>> BSPs,
>> one of which was qemu based, would result in the systemd -and-
>> everything that
>> dependend upon systemd to have their hash changed. The hash changing
>> means
>> lots of rebuilds, but worse if it's a package based system each
>> different
>> machine ends with a new PR value and a newly generated package.
>>
>> Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
>> ---
>> meta/recipes-core/systemd/systemd-conf.bb | 51
>> +++++++++++++++++++
>> ...ange-the-default-device-timeout-to-2.patch | 35 -------------
>> meta/recipes-core/systemd/systemd_239.bb | 28 ++++------
>> 3 files changed, 60 insertions(+), 54 deletions(-)
>> create mode 100644 meta/recipes-core/systemd/systemd-conf.bb
>> delete mode 100644 meta/recipes-core/systemd/systemd/0001-core-
>> device.c-Change-the-default-device-timeout-to-2.patch
>
> Something in -next is causing:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/35/builds/92/steps/7/logs/step7c
>
> which is a systemd boot timeout.
>
> Note that I fixed up the selftest issue with the patch, I also added a
> maintainers entry for systemd-conf to avoid another problem so please
> use the patch in -next for any further revisions. We're going to need
> more investigation to merge this though...
I'll work on this hopefully this week, and try to figure out why it's failing.
I suspect the issue is the original purpose of the workaround. I suspect the
timeout is staying at the default.
In my limited testing, I didn't experience this -- but I'm not exactly sure what
the test configuration I should be using is to verify it.
--Mark
> Cheers,
>
> Richard
>
>
>
More information about the Openembedded-core
mailing list