Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin <alex.kanavin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4717 bytes --]

Since the original centos 8 is going away (support-wise) in less than 3
months, should we just convert all workers to stream and move on?

Alex

On Mon, 4 Oct 2021 at 18:27, Michael Halstead <mhalstead@linuxfoundation.org>
wrote:

> This error was fixed upstream
> https://bugzilla.redhat.com/show_bug.cgi?id=1975562 kernel 4.18.0-325.x
> which has landed in CentOS8 Stream on centos8-ty-2 but not plain CentOS8
> where the newest kernel is still at 4.18.0-305.x.
>
> I'll reboot into the older 4.18.0-240.15 kernel again on centos8-ty-1 as a
> fix for now.
>
> On Tue, Sep 28, 2021 at 6:12 PM Anuj Mittal <anuj.mittal@intel.com> wrote:
>
>> Did we find out the reason why this was happening? I have started
>> getting this error on Centos-8 while building hardknott.
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045
>>
>> Thanks,
>>
>> Anuj
>>
>> On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
>> > On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
>> > > On Sun, 6 Jun 2021 at 01:10, Richard Purdie
>> > > <richard.purdie@linuxfoundation.org> wrote:
>> > > > I tried again with the autobuilder, still fails:
>> > > >
>> > > >
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
>> > > >
>> > > > so whatever it is, it is still "live".
>> > > >
>> > >
>> > >
>> > > I did some digging. The issue happens when:
>> > > - host is centos8
>> > > - SDKMACHINE is i686 (e.g. cmake is 32 bit)
>> > >
>> > > Then there's a failing syscall attempting to set file times:
>> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
>> > > 4.1/assimp-config.cmake",
>> > > [{tv_sec=1622966723, tv_nsec=6319439026193432576},
>> > > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
>> > > EINVAL (Invalid argument)
>> > >
>> > > On latest Fedora, there's no issue:
>> > > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
>> > > 4.1/assimp-config.cmake",
>> > > [{tv_sec=1623002886, tv_nsec=6369724778172907520},
>> > > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
>> > >
>> > > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
>> > > be returning ENOSYS in that case
>> > > probably?
>> >
>> > I hacked up a quick test bit of code (which makes assumptions
>> > about 32 bit):
>> >
>> > #include <unistd.h>
>> > #include <sys/syscall.h>
>> > #include <sys/types.h>
>> > #include <sys/stat.h>
>> > #include <fcntl.h>
>> > #include <stdio.h>
>> >
>> > struct timespec64 {
>> >     long long           tv_sec;                 /* seconds */
>> >     long long           tv_nsec;                /* nanoseconds */
>> > };
>> >
>> > int main() {
>> >   int fd = open("foo", O_RDWR | O_CREAT, 0644);
>> >   write(fd, "foo", 3);
>> >   struct timespec64 times[2] = {};
>> >   times[0].tv_sec = 1622966723;
>> >   times[0].tv_nsec = 631943;
>> >   times[1].tv_sec = 1622966579;
>> >   times[1].tv_nsec = 178400;
>> >   int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
>> >   printf("rc=%d\n", rc);
>> >   close(fd);
>> >   return rc;
>> > }
>> >
>> > built with "gcc -m32 test-syscall.c -o test" and run with "strace
>> > ./test".
>> > This works on all the systems I tried it in. As does:
>> >
>> >
>> >   times[0].tv_sec = 1;
>> >   times[0].tv_nsec = 2;
>> >   times[1].tv_sec = 3;
>> >   times[1].tv_nsec = 4;
>> >
>> > however if you set (and ignore the compiler warning):
>> >
>> >   times[0].tv_sec = 1622966723;
>> >   times[0].tv_nsec = 6319439026193432576;
>> >   times[1].tv_sec = 1622966579;
>> >   times[1].tv_nsec = 17840053692309438464;
>> >
>> > then you see EINVAL on the centos system but not on my ubuntu one. It
>> > will
>> > do that until you reduce the values of tv_nsec right now. So it seems
>> > most
>> > systems accept large tv_nsec values but the Centos one does not.
>> >
>> > I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
>> > be
>> > a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
>> > long.
>> >
>> > Michael: Hopefully that gives you something to raise with them?
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#156435):
>> https://lists.openembedded.org/g/openembedded-core/message/156435
>> Mute This Topic: https://lists.openembedded.org/mt/83304703/1003190
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
>> mhalstead@linuxfoundation.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>

[-- Attachment #2: Type: text/html, Size: 7202 bytes --]