On Fri, Nov 8, 2024 at 3:47 PM Steve Sakoman <[email protected]> wrote: > > On Thu, Nov 7, 2024 at 11:16 PM Martin Jansa <[email protected]> wrote: > > > > Backporting > > https://git.yoctoproject.org/pseudo/commit/pseudolog.c?id=15b4f4ca25593f684e6517d0b809605b443d1953 > > fixes the issue or instead of adding another .patch file we can import > > most of the pseudo changes from master (as they might be needed in > > future anyway as people will be upgrading to more recent host > > distros). > > > > I've queued the backports in 12 commits here: > > https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/kirkstone-pseudo-sync-with-master > > and confirmed that pseudo-native builds again on host with gcc-14 > > (rebuilding the image now) > > If it passes your testing please submit the series and I can test on > the autobuilder too.
I've already built few images and sdk with these and haven't noticed any difference (other than it could be built with gcc-14 on host) or issue, so I've sent the series (which includes this commit as well). All builds were in ubuntu-24.10 container, but I believe that if there were some issues on older hosts, then it would be already discovered with new pseudo in scarthgap or master). Cheers, > > > scarthgap is missing the most recent one for python-3.13 on host > > "pseudo: Fix envp bug and add posix_spawn wrapper" > > I'll cherry-pick that to scarthgap. > > Thanks! > > Steve > > > On Fri, Nov 8, 2024 at 7:18 AM Martin Jansa via lists.openembedded.org > > <[email protected]> wrote: > > > > > > With this update it fails to build on hosts with gcc-14: > > > > > > | pseudolog.c: In function ?parse_timestamp?: > > > | pseudolog.c:329:13: error: implicit declaration of function > > > ?strptime?; did you mean ?strftime?? [-Wimplicit-function-declaration] > > > | 329 | s = strptime(string, timeformat, &stamp_tm); > > > | | ^~~~~~~~ > > > | | strftime > > > | pseudolog.c:329:11: error: assignment to ?char *? from ?int? makes > > > pointer from integer without a cast [-Wint-conversion] > > > | 329 | s = strptime(string, timeformat, &stamp_tm); > > > | | ^ > > > | pseudolog.c:337:19: error: assignment to ?char *? from ?int? makes > > > pointer from integer without a cast [-Wint-conversion] > > > | 337 | s = strptime(string, time_formats[i], > > > &stamp_tm); > > > | | ^ > > > | pseudolog.c: In function ?plog_trait?: > > > | pseudolog.c:377:34: warning: ?calloc? sizes specified with ?sizeof? > > > in the earlier argument and not in the later argument > > > [-Wcalloc-transposed-args] > > > | 377 | new_trait = calloc(sizeof(*new_trait), 1); > > > | | ^ > > > | pseudolog.c:377:34: note: earlier argument should specify number of > > > elements, later size of each element > > > | make: *** [Makefile:130: pseudolog.o] Error 1 > > > > > > It's not caused by this change itself (it just triggers pseudo-native > > > to be rebuilt and not reused from sstate) but can we update to even > > > newer SRCREV which fixes this? Will check if > > > https://git.yoctoproject.org/pseudo/commit/pseudolog.c?id=15b4f4ca25593f684e6517d0b809605b443d1953 > > > fixes all of them. > > > > > > > > > On Wed, Nov 6, 2024 at 7:13 PM Fabio Berton via lists.openembedded.org > > > <[email protected]> wrote: > > > > > > > > From: Richard Purdie <[email protected]> > > > > > > > > Update to pull in: > > > > > > > > pseudo.c: Avoid patch mismatch errors for NAMELESS file entries > > > > > > > > In rare cases we see failures, often in linux-libc-headers for > > > > things like: > > > > > > > > | INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include > > > > | abort()ing pseudo client by server request. See > > > > https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on > > > > this. > > > > > > > > Pseudo log: > > > > path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req > > > > '/XXX/linux-libc-headers/6.1-r0/image/usr'. > > > > Setup complete, sending SIGUSR1 to pid 3630890. > > > > > > > > Whilst this doesn't easily reproduce, the issue is that multiple > > > > different processes are > > > > likely working on the directory and the creation in pseudo might > > > > not match accesses > > > > made by other processes. > > > > > > > > Ultimately, the "NAMELESS FILE" is harmless and pseudo will > > > > reconcile things > > > > so rather than error out, we should ignore this case. > > > > > > > > Signed-off-by: Richard Purdie <[email protected]> > > > > Signed-off-by: Luca Ceresoli <[email protected]> > > > > Signed-off-by: Richard Purdie <[email protected]> > > > > (cherry picked from commit 4f30a1a74828e105cbe69677b3fbe5623f371543) > > > > Signed-off-by: Fabio Berton <[email protected]> > > > > --- > > > > meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb > > > > b/meta/recipes-devtools/pseudo/pseudo_git.bb > > > > index 4dd9156238..6b0cb598e2 100644 > > > > --- a/meta/recipes-devtools/pseudo/pseudo_git.bb > > > > +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb > > > > @@ -14,7 +14,7 @@ SRC_URI:append:class-nativesdk = " \ > > > > file://older-glibc-symbols.patch" > > > > SRC_URI[prebuilt.sha256sum] = > > > > "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" > > > > > > > > -SRCREV = "c9670c27ff67ab899007ce749254b16091577e55" > > > > +SRCREV = "cc1f6167cb5065daba1462056e2dce8ff72aa855" > > > > S = "${WORKDIR}/git" > > > > PV = "1.9.0+git${SRCPV}" > > > > > > > > -- > > > > 2.25.1 > > > > > > > > The information in this communication may contain confidential or > > > > legally privileged information. It is intended solely for the use of > > > > the individual or entity it addresses and others authorized to receive > > > > it. If you are not an intended recipient, you are hereby notified that > > > > any disclosure, copying, distribution or action in reliance on the > > > > contents of this information is strictly prohibited and may be > > > > unlawful. If you have received this communication by error, please > > > > notify us immediately by responding to this e-mail and then delete it > > > > from your system. Critical TechWorks is not liable for the proper and > > > > complete transmission of the information in this communication nor for > > > > any delay in its receipt > > > > > > > > This e-mail is environmentally friendly, just like Critical TechWorks, > > > > which lives in a paper-free atmosphere. Therefore, please consider the > > > > environment before printing it! > > > > > > > > > > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#206889): https://lists.openembedded.org/g/openembedded-core/message/206889 Mute This Topic: https://lists.openembedded.org/mt/109429860/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
