Since move to 243 latest needs further work, how about moving straight to 244?
Alex > On 3 Feb 2020, at 21.26, Alex Kiernan <[email protected]> wrote: > >> On Mon, Feb 3, 2020 at 7:55 PM Alex Kiernan <[email protected]> wrote: >> >> Hi Richard >> >>> On Mon, Feb 3, 2020 at 2:13 PM Alex Kiernan <[email protected]> wrote: >>> >>> On Mon, Feb 3, 2020 at 10:26 AM Richard Purdie >>> <[email protected]> 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
