[OE-core] [OE-Core][PATCH] systemd: Upgrade 243.2 -> 243.4-latest

Alexander Kanavin alex.kanavin at gmail.com
Mon Feb 3 20:51:09 UTC 2020


Since move to 243 latest needs further work, how about moving straight to 244?

Alex

> On 3 Feb 2020, at 21.26, Alex Kiernan <alex.kiernan at gmail.com> wrote:
> 
>> On Mon, Feb 3, 2020 at 7:55 PM Alex Kiernan <alex.kiernan at gmail.com> wrote:
>> 
>> Hi Richard
>> 
>>> On Mon, Feb 3, 2020 at 2:13 PM Alex Kiernan <alex.kiernan at gmail.com> wrote:
>>> 
>>> On Mon, Feb 3, 2020 at 10:26 AM Richard Purdie
>>> <richard.purdie at linuxfoundation.org> wrote:
>>>> 
>>>>> On Mon, 2020-01-27 at 23:13 +0000, Alex Kiernan wrote:
>>>>> Update to latest on the 243 stable branch. This includes (amongst other
>>>>> fixes) seccomp filter changes which fix failures with glibc 2.31, e.g.
>>>>> 
>>>>>  systemd-journald[543]: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at src/basic/time-util.c:55, function now(). Aborting.
>>>>> 
>>>>> Rebase 0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch
>>>>> 
>>>>> Drop 0001-unit-file.c-consider-symlink-on-filesystems-like-NFS.patch,
>>>>> fixed in 5c0224c7bf3c ("Handle d_type == DT_UNKNOWN correctly").
>>>>> 
>>>>> Drop 0001-seccomp-more-comprehensive-protection-against-libsec.patch,
>>>>> fixed in 70e8c1978a9a ("seccomp: real syscall numbers are >= 0").
>>>> 
>>>> Unfortunately something in this causes:
>>>> 
>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/109/builds/412
>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/413
>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/1545
>>>> 
>>> 
>>> That's disappointing...
>>> 
>> 
>> I'm failing to reproduce this - am I right in thinking the error I
>> should be looking for is this one:
>> 
>> [ 3.997360] ide-cd: hdc: tray open
>> [ 3.999321] print_req_error: I/O error, dev hdc, sector 8388592 flags 80700
>> 
>> or some variation on it?
>> 
>> I've got testimage running across a number of the images I think are
>> the ones that are being run and I can't get any of them to fail.
>> 
> 
> Scratch that... it looks like one of the local changes is necessary to
> cause this - I'd foolishly reused an external source tree rather than
> just letting devtool deal with it.
> 
> -- 
> Alex Kiernan
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


More information about the Openembedded-core mailing list