From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
Michael Halstead <mhalstead@linuxfoundation.org>
Cc: Khem Raj <raj.khem@gmail.com>,
Bruce Ashfield <bruce.ashfield@gmail.com>,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3
Date: Wed, 09 Jun 2021 12:37:36 +0100 [thread overview]
Message-ID: <ffe15158da239184a7eef20767652cda2b9f272a.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANNYZj9wKQv+YMgCN98R1fEiCaruFTiK_MHXt+aNPVLOYBBS2w@mail.gmail.com>
On Tue, 2021-06-08 at 20:15 +0200, Alexander Kanavin wrote:
> I can confirm that the previous kernel behaves correctly:
> utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
> [{tv_sec=1623176017, tv_nsec=6290007298941124608}, {tv_sec=1622966579, tv_nsec=17838646317425885184}], 0) = -1
> ENOSYS (Function not implemented)
> utimensat(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=1623176017,
> tv_nsec=0} /* 2021-06-08T18:13:37+0000 */, {tv_sec=1622966579, tv_nsec=0} /* 2021-06-06T08:02:59+0000 */], 0)
> = 0
>
> Does look like a botched backport of time64 syscalls to me.
>
> Alex
>
> On Tue, 8 Jun 2021 at 17:40, Michael Halstead <mhalstead@linuxfoundation.org> wrote:
> > I've rebooted centos8-ty-1 using the previous 4.18.0-240.15.1.el8_3.x86_64 kernel and kept it in the pool.
> > I've paused centos8-ty-2 so it won't interfere with builds and left it at the current 4.18.0-
> > 305.3.1.el8.x86_64 kernel for testing.
Thanks Michael and Alex. We can therefore pretty safely say that something was
broken between the 240 and 305 of the centos8 kernel for the 32 bit syscall
utimensat syscalls.
I did poke around https://github.com/kernelim/linux/tree/centos8 which does
have a kernel diff but it is huge and you have to clone the repo to get it.
git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat -C 40
shows they did add the syscalls in that kernel.
So this does look to be a RedHat issue. Not sure if we want to report it
to them? Can we run the autobuilders on the older kernel for now until
they hopefully fix it?
Cheers,
Richard
next prev parent reply other threads:[~2021-06-09 11:37 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 9:14 [PATCH 01/10] virglrenderer: explicitly depend on libgbm Alexander Kanavin
2021-06-04 9:14 ` [PATCH 02/10] elfutils: update 0.183 -> 0.185 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 03/10] libcap: update 2.49 -> 2.50 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3 Alexander Kanavin
2021-06-05 14:35 ` [OE-core] " Richard Purdie
[not found] ` <1685B658849E960A.4717@lists.openembedded.org>
2021-06-05 15:13 ` Richard Purdie
2021-06-05 15:32 ` Khem Raj
2021-06-05 16:09 ` Richard Purdie
2021-06-05 19:27 ` Alexander Kanavin
2021-06-05 23:10 ` Richard Purdie
2021-06-06 19:51 ` Alexander Kanavin
2021-06-06 21:51 ` Khem Raj
2021-06-06 22:06 ` Alexander Kanavin
2021-06-06 22:18 ` Khem Raj
2021-06-07 10:20 ` Alexander Kanavin
2021-06-07 15:10 ` Khem Raj
2021-06-07 16:40 ` Michael Halstead
2021-06-07 17:18 ` Khem Raj
2021-06-07 18:04 ` Alexander Kanavin
2021-06-08 15:40 ` Michael Halstead
2021-06-08 18:15 ` Alexander Kanavin
2021-06-09 11:37 ` Richard Purdie [this message]
2021-06-09 14:07 ` Alexander Kanavin
2021-06-11 21:56 ` Michael Halstead
2021-06-11 22:18 ` Alexander Kanavin
2021-06-11 23:29 ` Michael Halstead
2021-06-16 22:45 ` Richard Purdie
2021-09-29 1:11 ` Mittal, Anuj
2021-10-04 16:27 ` Michael Halstead
2021-10-04 18:28 ` Alexander Kanavin
2021-10-04 22:38 ` Michael Halstead
2021-06-04 9:14 ` [PATCH 05/10] perl: split perl-cross into its own recipe Alexander Kanavin
2021-06-07 5:29 ` [OE-core] " Jacob Kroon
2021-06-07 9:13 ` Richard Purdie
2021-06-04 9:14 ` [PATCH 06/10] perl-cross: 1.3.5 -> 1.3.6 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 07/10] perl: update 5.32.1 -> 5.34.0 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 08/10] libgcrypt: upgrade 1.9.2 -> 1.9.3 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 09/10] xf86-input-libinput: update 0.30.0 -> 1.0.1 Alexander Kanavin
2021-06-04 9:14 ` [PATCH 10/10] erofs-utils: correct upstream version check Alexander Kanavin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffe15158da239184a7eef20767652cda2b9f272a.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alex.kanavin@gmail.com \
--cc=bruce.ashfield@gmail.com \
--cc=mhalstead@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox