From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E607FC433F5 for ; Mon, 4 Oct 2021 22:38:37 +0000 (UTC) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by mx.groups.io with SMTP id smtpd.web10.17709.1633387116370205598 for ; Mon, 04 Oct 2021 15:38:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linuxfoundation.org header.s=google header.b=UVCQPRTx; spf=pass (domain: linuxfoundation.org, ip: 209.85.167.48, mailfrom: mhalstead@linuxfoundation.org) Received: by mail-lf1-f48.google.com with SMTP id e15so78029835lfr.10 for ; Mon, 04 Oct 2021 15:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NIw+SiurjElhWkB7YY9GxdhvUJ5EU3aYK5OddzJFDHs=; b=UVCQPRTxFe764jQee9gK4Y+L38FIGOwJ65wke2D4InBVgGk0HZe9ssA/YYsHIN7MLn zWcvO3Dt8mTnZv5d1ae67MSDH6p5F1M9zUyAmPYFl5yg6Nup5F818fdfhxrI6uOzdeg3 oKyHETGNo695KbEsoUZRs0C8lW92kryhhMrgY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NIw+SiurjElhWkB7YY9GxdhvUJ5EU3aYK5OddzJFDHs=; b=ll1EGwn8UqzBfZByR7c/jsts0nAbf/SKoDxVMKusb5ux3SlvxCR2NJp7EqIyGfQzeS JeCplXH1gWTQgQdpjm/IH5W7CNg6MDaT6H4sarW/dzt1HAFDtj9gJrWn0h1f7A+FYdtI 6a3NEP+nP1nfqOGOtEvDHSxUk5Gd5wnecGP91hCcGIdtYEBOCCMCqHQl5p3xmUU+dW8G b//JBMUfLDzPqA/0oEzNKmnUNqvaQGaaUCTTshQP8VaBVSmSsApkhrEFrp/lVO95R6Xi Dv0/iy/pxvPQTy/Z2vLRDLvaPLjY7AUNypSsm4kiFvwlYWHbW9ph8p1QzmEUzR09ZHrV PjnQ== X-Gm-Message-State: AOAM531utkB5asQGDW/CBAxKZgeoDOY+atnf22vFcXawOkTqAPKYdeMo HIRAAL/kR0chzxKexpnDmddc1TX6SzSiXaqhO2R0DA== X-Google-Smtp-Source: ABdhPJxDOL7W+rAv8QWcLq6+0JrCkDdJvYLEfXxy2VJKCezJkdCQP9juY5MdnG7nfCsgxkq8INNEAc4+dRiBZnHBJEA= X-Received: by 2002:a2e:b608:: with SMTP id r8mr18334065ljn.248.1633387114074; Mon, 04 Oct 2021 15:38:34 -0700 (PDT) MIME-Version: 1.0 References: <20210604091458.1381144-1-alex.kanavin@gmail.com> <20210604091458.1381144-4-alex.kanavin@gmail.com> <1685B658849E960A.4717@lists.openembedded.org> <50a73766-dc52-0600-a6cd-7ab422030782@gmail.com> <7e56d093ba6c1390cec71ef3a362abe84ce735bb.camel@linuxfoundation.org> <2ac70a7b01743192ae4ec42b2b1eee18becde25d.camel@linuxfoundation.org> <1c55d1aca45e746034b791b2f1712e8f335b502c.camel@linuxfoundation.org> In-Reply-To: From: Michael Halstead Date: Mon, 4 Oct 2021 15:38:22 -0700 Message-ID: Subject: Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3 To: Alexander Kanavin Cc: Anuj Mittal , "richard.purdie@linuxfoundation.org" , "openembedded-core@lists.openembedded.org" Content-Type: multipart/alternative; boundary="000000000000b7277305cd8e9215" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 04 Oct 2021 22:38:37 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/156633 --000000000000b7277305cd8e9215 Content-Type: text/plain; charset="UTF-8" I'll go ahead and switch to CentOS8-Stream once the current a-full is complete. If there is a need to follow RHEL8 exactly we can add a Rocky Linux worker in the future. On Mon, Oct 4, 2021 at 11:28 AM Alexander Kanavin wrote: > 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 >> 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 >>> > > 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 >>> > #include >>> > #include >>> > #include >>> > #include >>> > #include >>> > >>> > 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, ×[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 >> > -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer --000000000000b7277305cd8e9215 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll go ahead and switch to CentOS8-Stream once t= he current a-full is complete. If there=C2=A0is a need to follow RHEL8 exac= tly we can add a=C2=A0Rocky Linux worker in the=C2=A0future.=C2=A0


On Mon, Oct 4, 2021 at 11:28 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
<= div>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 Halstea= d <mh= alstead@linuxfoundation.org> wrote:
This error was fixed upstream= =C2=A0https://bugzilla.redhat.com/show_bug.cgi?id=3D1975562 ke= rnel 4.18.0-325.x which has landed in CentOS8 Stream on centos8-ty-2 but no= t plain CentOS8 where the newest kernel is still at=C2=A04.18.0-305.x.
=
I'll reboot into the older=C2=A04.18.0-240.15 kernel aga= in on centos8-ty-1 as a fix for now.=C2=A0

On Tue, Sep 28, 2021 at 6:1= 2 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.yoctoproje= ct.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://autobui= lder.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:<= br> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/a= ssimp-
> > 4.1/assimp-config.cmake",
> > [{tv_sec=3D1622966723, tv_nsec=3D6319439026193432576},
> > {tv_sec=3D1622966579, tv_nsec=3D17840053692309438464}], 0) =3D -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=3D1623002886, tv_nsec=3D6369724778172907520},
> > {tv_sec=3D1623002886, tv_nsec=3D17839174083007217664}], 0) =3D 0<= br> > >
> > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 sh= ould
> > be returning ENOSYS in that case
> > probably?
>
> I hacked up a quick test bit of code (which makes assumptions=C2=A0 > 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 {
> =C2=A0=C2=A0=C2=A0 long long=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0tv_sec;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* seconds */ > =C2=A0=C2=A0=C2=A0 long long=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0tv_nsec;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* nanoseconds */
> };
>
> int main() {
> =C2=A0 int fd =3D open("foo", O_RDWR | O_CREAT, 0644);
> =C2=A0 write(fd, "foo", 3);
> =C2=A0 struct timespec64 times[2] =3D {};
> =C2=A0 times[0].tv_sec =3D 1622966723;
> =C2=A0 times[0].tv_nsec =3D 631943;
> =C2=A0 times[1].tv_sec =3D 1622966579;
> =C2=A0 times[1].tv_nsec =3D 178400;
> =C2=A0 int rc =3D syscall(SYS_utimensat_time64, fd, NULL, &times[0= ], 0);
> =C2=A0 printf("rc=3D%d\n", rc);
> =C2=A0 close(fd);
> =C2=A0 return rc;
> }
>
> built with "gcc -m32 test-syscall.c -o test" and run with &q= uot;strace
> ./test".
> This works on all the systems I tried it in. As does:
>
>
> =C2=A0 times[0].tv_sec =3D 1;
> =C2=A0 times[0].tv_nsec =3D 2;
> =C2=A0 times[1].tv_sec =3D 3;
> =C2=A0 times[1].tv_nsec =3D 4;
>
> however if you set (and ignore the compiler warning):
>
> =C2=A0 times[0].tv_sec =3D 1622966723;
> =C2=A0 times[0].tv_nsec =3D 6319439026193432576;
> =C2=A0 times[1].tv_sec =3D 1622966579;
> =C2=A0 times[1].tv_nsec =3D 17840053692309438464;
>
> then you see EINVAL on the centos system but not on my ubuntu one. It<= br> > will
> do that until you reduce the values of tv_nsec right now. So it seems<= br> > most=C2=A0
> 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=C2=A0
> 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
>
>
>
>
>
>
>
>


-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
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<= br> Unsubscribe: https://lists.openembedded.org/= g/openembedded-core/unsub [mhalstead@linuxfoundation.org]
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-



--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


--
Michael Halstead
Linux Foun= dation / Yocto Project
Systems Operations Engineer
--000000000000b7277305cd8e9215--