Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: Gortmaker, Paul
> Sent: Friday, December 1, 2023 11:14
> To: Liu, Yongxin
> Cc: Bruce Ashfield ; linux-
> yo...@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> of CPUs
>
> [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> On 30/11/2023 (Thu 21:43) Liu, Yongxin wrote:
>
> > > -Original Message-
> > > From: Gortmaker, Paul
> > > Sent: Friday, December 1, 2023 10:27
> > > To: Liu, Yongxin
> > > Cc: Bruce Ashfield ; linux-
> > > yo...@lists.yoctoproject.org
> > > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > number of CPUs
> > >
> > > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > > of CPUs] On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > >
> > > > > -Original Message-
> > > > > From: linux-yocto@lists.yoctoproject.org > > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > > lists.yoctoproject.org
> > > > > Sent: Friday, December 1, 2023 03:08
> > > > > To: Bruce Ashfield
> > > > > Cc: linux-yocto@lists.yoctoproject.org
> > > > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > > number of CPUs
> > > > >
> > > > > From: Paul Gortmaker
> > > > >
> > > > > The x86-64 BSP isn't quite the same as the "more specific" BSP
> > > > > like a Beaglebone Black or the (now deleted) Edgerouter. Where
> > > > > we have exact hardware specifics for boards like those, the
> > > > > x86-64 BSP is more of a "generic" thing used as the baseline
> > > > > across an endless sea
> > > of boards.
> > > > >
> > > > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > > > ("bsp/intel-x86: change the supported maximum number of CPUs to
> > > > > 512 in 64- bit bsp")
> > > > >
> > > > > It is great that a handful of people out there are using Yocto
> > > > > on these huge server machines, but that doesn't reflect 99% of
> > > > > the rest of us who continue to lean towards the original
> > > > > "embedded theme" of
> > > Yocto.
> > > > >
> > > > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > > > some can be mitigated by booting with "nr_cpus=4" (or whatever
> > > > > the core count
> > > > > is) but I guarantee largely nobody out there is doing that.
> > > > >
> > > > > Let those users with the crazy CPU count own that config
> > > > > customization locally. The default is 64 which still seems way
> > > > > too large IMHO, but at least we are moving in the right direction.
> > > >
> > > >
> > > > This intel-x86-64 BSP is a generic one used from mobile to server.
> > > >
> > > > Customers need to customize not only the CPU number config but
> > > > also other configs, like, removing unused drivers or adding debug
> options.
> > > > From this point of view, there is no difference between 64 or 512.
> >
> > I changed 64 to 512. Because we have server machines with more than 64
> CPU.
> > I want the BSP support those machines by default.
>
> But you still miss the point. It doesn't matter what you or any company
> "want" in this case. Like it or not, it is a shared resource and so the
> defaults have to be what is good for Yocto project and not for *you*
>
> >
> > >
> > > So you've basically argued my case for me. If changes are
> > > inevitable, then why do we change the default?
> > >
> > > > But it changes the "rule" that intel-x86-64 works for all
> > > > supported
> > > platforms.
> > > > We need to do extra work for servers with large CPU number.
> > >
> > > No. There is no "rule" in Yocto like that. That is nonsense
> > > because there is no way Yocto can commit to "support" all the crazy
> > > different
> > > x86-64 variants out there.
> >
> >
> > I think this "bsp/intel-x86" is used only by Wind River.
> > So bsp/intel-x86 should work for all supported machines claimed by Wind
> River.
>
> No. That is where you are dead wrong. Wind River does not own Yocto.
> Think for a minute. A new Yocto user comes along and sees "intel-x86"
> and because that name is so generic -- thinks "I'll build that for my old
> PC."
I have a question why we need bsp/intel-x86, because Yocto already has
bsp/intel-common and bsp/common-pc?
>
> > If we need to do some local change to support some machine. That's not
> good.
> > Because people usually build image with default configs and then
> complain something doesn't work.
>
> Again, it is NOT the problem of the Yocto project what isn't good for YOU.
> If you need EDAC and NUMA and 500+ CPU support, then make a proper BSP
> with those settings and submit it as "bsp/mega-server-2000" or whatever.
Then I think we should revise bsp/intel-x86, because it has enabled many
uncommon features by
intel-x86.scc:include features/intel-idxd/intel-idxd.scc
intel-x86.scc:include features/intel-uncore-frequency/intel-uncore-frequency.scc
intel-x86.scc:include features/intel-dptf/intel-dptf.scc
intel-x86.scc:include
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
[RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs] On
30/11/2023 (Thu 21:43) Liu, Yongxin wrote:
> > -Original Message-
> > From: Gortmaker, Paul
> > Sent: Friday, December 1, 2023 10:27
> > To: Liu, Yongxin
> > Cc: Bruce Ashfield ; linux-
> > yo...@lists.yoctoproject.org
> > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > of CPUs
> >
> > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> > On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> >
> > > > -Original Message-
> > > > From: linux-yocto@lists.yoctoproject.org > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > lists.yoctoproject.org
> > > > Sent: Friday, December 1, 2023 03:08
> > > > To: Bruce Ashfield
> > > > Cc: linux-yocto@lists.yoctoproject.org
> > > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > number of CPUs
> > > >
> > > > From: Paul Gortmaker
> > > >
> > > > The x86-64 BSP isn't quite the same as the "more specific" BSP like
> > > > a Beaglebone Black or the (now deleted) Edgerouter. Where we have
> > > > exact hardware specifics for boards like those, the x86-64 BSP is
> > > > more of a "generic" thing used as the baseline across an endless sea
> > of boards.
> > > >
> > > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > > ("bsp/intel-x86: change the supported maximum number of CPUs to 512
> > > > in 64- bit bsp")
> > > >
> > > > It is great that a handful of people out there are using Yocto on
> > > > these huge server machines, but that doesn't reflect 99% of the rest
> > > > of us who continue to lean towards the original "embedded theme" of
> > Yocto.
> > > >
> > > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > > some can be mitigated by booting with "nr_cpus=4" (or whatever the
> > > > core count
> > > > is) but I guarantee largely nobody out there is doing that.
> > > >
> > > > Let those users with the crazy CPU count own that config
> > > > customization locally. The default is 64 which still seems way too
> > > > large IMHO, but at least we are moving in the right direction.
> > >
> > >
> > > This intel-x86-64 BSP is a generic one used from mobile to server.
> > >
> > > Customers need to customize not only the CPU number config but also
> > > other configs, like, removing unused drivers or adding debug options.
> > > From this point of view, there is no difference between 64 or 512.
>
> I changed 64 to 512. Because we have server machines with more than 64 CPU.
> I want the BSP support those machines by default.
But you still miss the point. It doesn't matter what you or any company
"want" in this case. Like it or not, it is a shared resource and so the
defaults have to be what is good for Yocto project and not for *you*
>
> >
> > So you've basically argued my case for me. If changes are inevitable,
> > then why do we change the default?
> >
> > > But it changes the "rule" that intel-x86-64 works for all supported
> > platforms.
> > > We need to do extra work for servers with large CPU number.
> >
> > No. There is no "rule" in Yocto like that. That is nonsense because
> > there is no way Yocto can commit to "support" all the crazy different
> > x86-64 variants out there.
>
>
> I think this "bsp/intel-x86" is used only by Wind River.
> So bsp/intel-x86 should work for all supported machines claimed by Wind River.
No. That is where you are dead wrong. Wind River does not own Yocto.
Think for a minute. A new Yocto user comes along and sees "intel-x86"
and because that name is so generic -- thinks "I'll build that for my old PC."
> If we need to do some local change to support some machine. That's not good.
> Because people usually build image with default configs and then complain
> something doesn't work.
Again, it is NOT the problem of the Yocto project what isn't good for YOU.
If you need EDAC and NUMA and 500+ CPU support, then make a proper BSP
with those settings and submit it as "bsp/mega-server-2000" or whatever.
Don't just be using intel-x86 as a dumping ground for whatever random
setting you need today. That isn't fair to all the other Yocto users
out there who might not even know who Wind River is.
Paul.
--
>
>
> Thanks,
> Yongxin
>
>
> > If a re-seller/integrator wants to take Yocto and tune it for platform XYZ
> > because there is customer demand and claim it is then "supported" by them,
> > then fine. But then to expect the Yocto project to own that? No.
>
>
> >
> > Paul.
> > --
> >
> > >
> > > Thanks,
> > > Yongxin
> > >
> > > >
> > > > Signed-off-by: Paul Gortmaker
> > > > ---
> > > > bsp/intel-x86/intel-x86-64.cfg | 3 ---
> > > > 1 file changed, 3 deletions(-)
> > > >
> > > > diff --git a/bsp/intel-x86/intel-x86-64.cfg
> > > > b/bsp/intel-x86/intel-x86- 64.cfg index 58b0fed637e8..da9bc7b57eca
> > > > 100644
> > > > --- a/bsp/intel-x86/intel-x86-64.cfg
> > > > +++
Re: [yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw
On Thu, Nov 30, 2023 at 6:38 PM Kang Wenlin
wrote:
>
> On 12/1/2023 00:54, Khem Raj wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
> >
> > On Thu, Nov 30, 2023 at 12:31 AM wenlin.k...@windriver.com via
> > lists.yoctoproject.org
> > wrote:
> >> From: Wenlin Kang
> >>
> >> Steps to reproduce
> >>1) add layer meta-mingw
> >>2) add line in local.conf
> >> SDKMACHINE = "x86_64-mingw32"
> >>3) bitbake nativesdk-libxcrypt
> >>
> >> Fixed:
> >> 1. .symver error
> >>| {standard input}: Assembler messages:
> >>| {standard input}:4: Error: unknown pseudo-op: `.symver'
> >>
> >> 2. pedantic error
> >>| ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';'
> outside of a function [-Werror=pedantic]
> >>| 316 | SYMVER_crypt_gensalt_rn;
> >>| |
> >>
> >> 3. conversion error
> >>| ../git/lib/util-get-random-bytes.c: In function
> '_crypt_get_random_bytes':
> >>| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from
> 'size_t' {aka 'long long unsigned int'} to 'unsigned int' may change value
> [-Werror=conversion]
> >>| 140 | ssize_t nread = read (fd, buf, buflen);
> >>
> >> Signed-off-by: Wenlin Kang
> >> ---
> >> .../0001-Fix-for-compilation-on-Windows.patch | 37 +++
> >> ...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
> >> recipes-core/libxcrypt/libxcrypt_%.bbappend | 7 +++
> >> 3 files changed, 91 insertions(+)
> >> create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >> create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >> create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
> >>
> >> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >> new file mode 100644
> >> index 000..5760ee0
> >> --- /dev/null
> >> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> >> @@ -0,0 +1,37 @@
> >> +From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
> >> +From: Brecht Sanders
> >> +Date: Fri, 3 Feb 2023 08:44:49 +0100
> >> +Subject: [PATCH] Fix for compilation on Windows
> >> +
> >> +This fix allows the library to build on Windows (at least with
> MinGW-w64).
> >> +
> >> +`.symver` is only supported for ELF format but Windows uses COFF/PE.
> >> +
> >> +Workaround dummy define of `symver_set()`
> >> +
> >> +Upstream-Status: Backport [
> https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624
> ]
> >> +
> >> +Signed-off-by: Wenlin Kang
> >> +---
> >> + lib/crypt-port.h | 5 +
> >> + 1 file changed, 5 insertions(+)
> >> +
> >> +diff --git a/lib/crypt-port.h b/lib/crypt-port.h
> >> +index f06ca24..a707939 100644
> >> +--- a/lib/crypt-port.h
> >> b/lib/crypt-port.h
> >> +@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t
> d_size, const void *src);
> >> + __asm__(".globl _" extstr); \
> >> + __asm__(".set _" extstr ", _" #intname)
> >> +
> >> ++#elif defined _WIN32
> >> ++
> >> ++/* .symver is only supported for ELF format, Windows uses COFF/PE */
> >> ++# define symver_set(extstr, intname, version, mode)
> >> ++
> >> + #elif defined __GNUC__ && __GNUC__ >= 3
> >> +
> >> + # define _strong_alias(name, aliasname) \
> >> +--
> >> +2.34.1
> >> +
> >> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >> new file mode 100644
> >> index 000..3846f76
> >> --- /dev/null
> >> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> >> @@ -0,0 +1,47 @@
> >> +From ff99091eb8a6b9e6edc567f6d2552183fbaacec3 Mon Sep 17 00:00:00 2001
> >> +From: Wenlin Kang
> >> +Date: Mon, 6 Nov 2023 14:43:28 +0800
> >> +Subject: [PATCH] lib/util-get-random-bytes.c: fixed conversion error
> with
> >> + mingw
> >> +
> >> +With x86_64-w64-mingw32-gcc. get below error:
> >> +| ../git/lib/util-get-random-bytes.c: In function
> '_crypt_get_random_bytes':
> >> +| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from
> 'size_t' {aka 'long long unsigned int'} to 'unsigned int' may change value
> [-Werror=conversion]
> >> +| 140 | ssize_t nread = read (fd, buf, buflen);
> >> +| | ^~
> >> +
> >> +In util-get-random-bytes.c, has get_random_bytes(void *buf, size_t
> buflen),
> >> +but in mingw-w64-mingw-w64/mingw-w64-headers/crt/io.h, read() has
> "unsigned int"
> >> +read(int _FileHandle,void *_DstBuf,unsigned int _MaxCharCount),
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: Gortmaker, Paul
> Sent: Friday, December 1, 2023 10:27
> To: Liu, Yongxin
> Cc: Bruce Ashfield ; linux-
> yo...@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> of CPUs
>
> [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
>
> > > -Original Message-
> > > From: linux-yocto@lists.yoctoproject.org > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > lists.yoctoproject.org
> > > Sent: Friday, December 1, 2023 03:08
> > > To: Bruce Ashfield
> > > Cc: linux-yocto@lists.yoctoproject.org
> > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > number of CPUs
> > >
> > > From: Paul Gortmaker
> > >
> > > The x86-64 BSP isn't quite the same as the "more specific" BSP like
> > > a Beaglebone Black or the (now deleted) Edgerouter. Where we have
> > > exact hardware specifics for boards like those, the x86-64 BSP is
> > > more of a "generic" thing used as the baseline across an endless sea
> of boards.
> > >
> > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > ("bsp/intel-x86: change the supported maximum number of CPUs to 512
> > > in 64- bit bsp")
> > >
> > > It is great that a handful of people out there are using Yocto on
> > > these huge server machines, but that doesn't reflect 99% of the rest
> > > of us who continue to lean towards the original "embedded theme" of
> Yocto.
> > >
> > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > some can be mitigated by booting with "nr_cpus=4" (or whatever the
> > > core count
> > > is) but I guarantee largely nobody out there is doing that.
> > >
> > > Let those users with the crazy CPU count own that config
> > > customization locally. The default is 64 which still seems way too
> > > large IMHO, but at least we are moving in the right direction.
> >
> >
> > This intel-x86-64 BSP is a generic one used from mobile to server.
> >
> > Customers need to customize not only the CPU number config but also
> > other configs, like, removing unused drivers or adding debug options.
> > From this point of view, there is no difference between 64 or 512.
I changed 64 to 512. Because we have server machines with more than 64 CPU.
I want the BSP support those machines by default.
>
> So you've basically argued my case for me. If changes are inevitable,
> then why do we change the default?
>
> > But it changes the "rule" that intel-x86-64 works for all supported
> platforms.
> > We need to do extra work for servers with large CPU number.
>
> No. There is no "rule" in Yocto like that. That is nonsense because
> there is no way Yocto can commit to "support" all the crazy different
> x86-64 variants out there.
I think this "bsp/intel-x86" is used only by Wind River.
So bsp/intel-x86 should work for all supported machines claimed by Wind River.
If we need to do some local change to support some machine. That's not good.
Because people usually build image with default configs and then complain
something doesn't work.
Thanks,
Yongxin
> If a re-seller/integrator wants to take Yocto and tune it for platform XYZ
> because there is customer demand and claim it is then "supported" by them,
> then fine. But then to expect the Yocto project to own that? No.
>
> Paul.
> --
>
> >
> > Thanks,
> > Yongxin
> >
> > >
> > > Signed-off-by: Paul Gortmaker
> > > ---
> > > bsp/intel-x86/intel-x86-64.cfg | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/bsp/intel-x86/intel-x86-64.cfg
> > > b/bsp/intel-x86/intel-x86- 64.cfg index 58b0fed637e8..da9bc7b57eca
> > > 100644
> > > --- a/bsp/intel-x86/intel-x86-64.cfg
> > > +++ b/bsp/intel-x86/intel-x86-64.cfg
> > > @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
> > >
> > > # x86 CPU resource control support
> > > CONFIG_X86_CPU_RESCTRL=y
> > > -
> > > -# Processor type and features
> > > -CONFIG_NR_CPUS=512
> > > --
> > > 2.40.0
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13345):
https://lists.yoctoproject.org/g/linux-yocto/message/13345
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw
On 12/1/2023 00:54, Khem Raj wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Thu, Nov 30, 2023 at 12:31 AM wenlin.k...@windriver.com via
lists.yoctoproject.org
wrote:
From: Wenlin Kang
Steps to reproduce
1) add layer meta-mingw
2) add line in local.conf
SDKMACHINE = "x86_64-mingw32"
3) bitbake nativesdk-libxcrypt
Fixed:
1. .symver error
| {standard input}: Assembler messages:
| {standard input}:4: Error: unknown pseudo-op: `.symver'
2. pedantic error
| ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';' outside
of a function [-Werror=pedantic]
| 316 | SYMVER_crypt_gensalt_rn;
| |
3. conversion error
| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t'
{aka 'long long unsigned int'} to 'unsigned int' may change value
[-Werror=conversion]
| 140 | ssize_t nread = read (fd, buf, buflen);
Signed-off-by: Wenlin Kang
---
.../0001-Fix-for-compilation-on-Windows.patch | 37 +++
...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
recipes-core/libxcrypt/libxcrypt_%.bbappend | 7 +++
3 files changed, 91 insertions(+)
create mode 100644
recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
create mode 100644
recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
diff --git
a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
new file mode 100644
index 000..5760ee0
--- /dev/null
+++ b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
@@ -0,0 +1,37 @@
+From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
+From: Brecht Sanders
+Date: Fri, 3 Feb 2023 08:44:49 +0100
+Subject: [PATCH] Fix for compilation on Windows
+
+This fix allows the library to build on Windows (at least with MinGW-w64).
+
+`.symver` is only supported for ELF format but Windows uses COFF/PE.
+
+Workaround dummy define of `symver_set()`
+
+Upstream-Status: Backport
[https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624]
+
+Signed-off-by: Wenlin Kang
+---
+ lib/crypt-port.h | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/lib/crypt-port.h b/lib/crypt-port.h
+index f06ca24..a707939 100644
+--- a/lib/crypt-port.h
b/lib/crypt-port.h
+@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t d_size,
const void *src);
+ __asm__(".globl _" extstr); \
+ __asm__(".set _" extstr ", _" #intname)
+
++#elif defined _WIN32
++
++/* .symver is only supported for ELF format, Windows uses COFF/PE */
++# define symver_set(extstr, intname, version, mode)
++
+ #elif defined __GNUC__ && __GNUC__ >= 3
+
+ # define _strong_alias(name, aliasname) \
+--
+2.34.1
+
diff --git
a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
new file mode 100644
index 000..3846f76
--- /dev/null
+++
b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
@@ -0,0 +1,47 @@
+From ff99091eb8a6b9e6edc567f6d2552183fbaacec3 Mon Sep 17 00:00:00 2001
+From: Wenlin Kang
+Date: Mon, 6 Nov 2023 14:43:28 +0800
+Subject: [PATCH] lib/util-get-random-bytes.c: fixed conversion error with
+ mingw
+
+With x86_64-w64-mingw32-gcc. get below error:
+| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
+| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t'
{aka 'long long unsigned int'} to 'unsigned int' may change value
[-Werror=conversion]
+| 140 | ssize_t nread = read (fd, buf, buflen);
+| | ^~
+
+In util-get-random-bytes.c, has get_random_bytes(void *buf, size_t buflen),
+but in mingw-w64-mingw-w64/mingw-w64-headers/crt/io.h, read() has "unsigned
int"
+read(int _FileHandle,void *_DstBuf,unsigned int _MaxCharCount), and has:
+ #ifdef _WIN64
+ __MINGW_EXTENSION typedef unsigned __int64 size_t;
+ #else
+ typedef unsigned int size_t;
+ #endif /* _WIN64 */
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenlin Kang
+---
+ lib/util-get-random-bytes.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/lib/util-get-random-bytes.c b/lib/util-get-random-bytes.c
+index 79816db..68cd378 100644
+--- a/lib/util-get-random-bytes.c
b/lib/util-get-random-bytes.c
+@@ -137,7 +137,11 @@ get_random_bytes(void *buf, size_t buflen)
+ dev_urandom_doesnt_work = true;
+ else
+ {
Re: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
[RE: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone] On 30/11/2023 (Thu 19:29) Liu, Yongxin wrote: > > -Original Message- > > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via > > lists.yoctoproject.org > > Sent: Friday, December 1, 2023 03:08 > > To: Bruce Ashfield > > Cc: linux-yocto@lists.yoctoproject.org > > Subject: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on > > everyone > > > > From: Paul Gortmaker > > > > Similar to the argument of why we shouldn't force NUMA on everyone, the > > 9 chip registered ECC RAM type stuff also tends to be found mostly on > > larger server type stuff and less so on embedded targets. > > > > We already have a skeleton EDAC feature, so move the features over there. > > One could argue that we might want to separate into arch specific config > > fragments, but to me - that seems overkill at this point in time. > > > > Signed-off-by: Paul Gortmaker > > --- > > bsp/intel-x86/intel-x86-64.cfg | 13 - > > features/edac/edac.cfg | 8 > > 2 files changed, 8 insertions(+), 13 deletions(-) > > > > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86- > > 64.cfg index f31711e73181..58b0fed637e8 100644 > > --- a/bsp/intel-x86/intel-x86-64.cfg > > +++ b/bsp/intel-x86/intel-x86-64.cfg > > @@ -3,19 +3,6 @@ > > # General setup > > # > > > > -# EDAC > > -CONFIG_EDAC=y > > -CONFIG_EDAC_DEBUG=y > > -CONFIG_EDAC_SBRIDGE=m > > -CONFIG_ACPI_APEI=y > > -CONFIG_ACPI_APEI_EINJ=m > > -CONFIG_ACPI_APEI_GHES=y > > -CONFIG_EDAC_PND2=m > > -CONFIG_EDAC_SKX=m > > -CONFIG_EDAC_I10NM=m > > -CONFIG_EDAC_IGEN6=m > > - > > - > > # ISH > > CONFIG_INTEL_ISH_HID=m > > > > diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index > > 9b3d3fc59eae..4f75d2f825ee 100644 > > --- a/features/edac/edac.cfg > > +++ b/features/edac/edac.cfg > > @@ -15,3 +15,11 @@ > > CONFIG_RAS=y > > CONFIG_EDAC=y > > CONFIG_EDAC_DEBUG=y > > +CONFIG_EDAC_SBRIDGE=m > > +CONFIG_ACPI_APEI=y > > +CONFIG_ACPI_APEI_EINJ=m > > +CONFIG_ACPI_APEI_GHES=y > > +CONFIG_EDAC_PND2=m > > +CONFIG_EDAC_SKX=m > > +CONFIG_EDAC_I10NM=m > > Other arch/bsp may include edac.scc. They clearly don't want EDAC drivers for > x86 platform. > And since CONFIG_EDAC_I10NM depends on X86_64, won't it cause warnings when > doing kernel_configcheck for other arch? Did you read the 0/5 or the commit log? I explicitly said we do this in master and then as we have the cushion of time, we see if there is demand for making an arch separation. At this point in time, my experience tells me we don't need it. Paul. -- > > > Thanks, > Yongxin > > > > +CONFIG_EDAC_IGEN6=m > > -- > > 2.40.0 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13344): https://lists.yoctoproject.org/g/linux-yocto/message/13344 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
[RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs] On
30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > -Original Message-
> > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > lists.yoctoproject.org
> > Sent: Friday, December 1, 2023 03:08
> > To: Bruce Ashfield
> > Cc: linux-yocto@lists.yoctoproject.org
> > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of
> > CPUs
> >
> > From: Paul Gortmaker
> >
> > The x86-64 BSP isn't quite the same as the "more specific" BSP like a
> > Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
> > hardware specifics for boards like those, the x86-64 BSP is more of a
> > "generic" thing used as the baseline across an endless sea of boards.
> >
> > To that end, this is somewhat a revert of commit bd77e1f904f6
> > ("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-
> > bit bsp")
> >
> > It is great that a handful of people out there are using Yocto on these
> > huge server machines, but that doesn't reflect 99% of the rest of us who
> > continue to lean towards the original "embedded theme" of Yocto.
> >
> > That means a whole bunch of extra per-CPU jumping through hoops; some can
> > be mitigated by booting with "nr_cpus=4" (or whatever the core count
> > is) but I guarantee largely nobody out there is doing that.
> >
> > Let those users with the crazy CPU count own that config customization
> > locally. The default is 64 which still seems way too large IMHO, but at
> > least we are moving in the right direction.
>
>
> This intel-x86-64 BSP is a generic one used from mobile to server.
>
> Customers need to customize not only the CPU number config but also other
> configs,
> like, removing unused drivers or adding debug options.
> From this point of view, there is no difference between 64 or 512.
So you've basically argued my case for me. If changes are inevitable,
then why do we change the default?
> But it changes the "rule" that intel-x86-64 works for all supported platforms.
> We need to do extra work for servers with large CPU number.
No. There is no "rule" in Yocto like that. That is nonsense because
there is no way Yocto can commit to "support" all the crazy different
x86-64 variants out there.
If a re-seller/integrator wants to take Yocto and tune it for platform
XYZ because there is customer demand and claim it is then "supported" by
them, then fine. But then to expect the Yocto project to own that? No.
Paul.
--
>
> Thanks,
> Yongxin
>
> >
> > Signed-off-by: Paul Gortmaker
> > ---
> > bsp/intel-x86/intel-x86-64.cfg | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-
> > 64.cfg index 58b0fed637e8..da9bc7b57eca 100644
> > --- a/bsp/intel-x86/intel-x86-64.cfg
> > +++ b/bsp/intel-x86/intel-x86-64.cfg
> > @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
> >
> > # x86 CPU resource control support
> > CONFIG_X86_CPU_RESCTRL=y
> > -
> > -# Processor type and features
> > -CONFIG_NR_CPUS=512
> > --
> > 2.40.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13343):
https://lists.yoctoproject.org/g/linux-yocto/message/13343
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw][PATCH] mingw-libgnurx: fix file conflicting of dev package
1. Both of glibc and mingw-libgnurx's dev package provides
/usr/include/regex.h, and mingw-libgnurx-dev depends on
glibc-dev. So install mingw-libgnurx-dev failed
root@x86-64:~# rpm -qlp libc6-dev-2.37-r1.0.x86_64.rpm | grep regex.h
/usr/include/regex.h
root@x86-64:~# rpm -qlp libgnurx-dev-2.5.1-r0.0.x86_64.rpm |grep regex.h
/usr/include/regex.h
root@x86-64:~# rpm-ostree install mingw-libgnurx-dev
rpm-ostree install: error: Checkout libgnurx-dev-2.5.1-r0.8.x86_64:
Hardlinking
0e/39f3fcd99b0db7455336559927b51bb413067abd030785662c3ff9aefa4c22.file to
regex.h: File exists
Move /usr/include/regex.h of mingw-libgnurx-dev to
/usr/include/mingw-libgnurx/regex.h
2. Due to autotool is used, drop
0001-Honor-DESTDIR-variable-during-install.patch
to modify Makefile.in
Signed-off-by: Hongxu Jia
---
...onor-DESTDIR-variable-during-install.patch | 39 ---
.../0002-Add-autotool-files.patch | 2 +-
.../mingw-libgnurx/mingw-libgnurx_2.5.1.bb| 1 -
3 files changed, 1 insertion(+), 41 deletions(-)
delete mode 100644
recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
diff --git
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
deleted file mode 100644
index ea8d9ed..000
---
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From a9b7e07a8ba9c390d9774daae769748a09d409ce Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Sat, 1 May 2021 14:41:21 -0700
-Subject: [PATCH] Honor DESTDIR variable during install
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj
- Makefile.in | 14 +++---
- 1 file changed, 7 insertions(+), 7 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index 6397bf1..8395d2f 100644
a/Makefile.in
-+++ b/Makefile.in
-@@ -78,16 +78,16 @@ gnurx.lib: libgnurx-$(DLLVERSION).dll
- install: install-dll @install_dev@
-
- install-dll:
-- mkdir -p ${bindir}
-- cp -p $(BINDIST_FILES) ${bindir}
-+ mkdir -p $(DESTDIR)${bindir}
-+ cp -p $(BINDIST_FILES) $(DESTDIR)${bindir}
-
- install-dev:
-- mkdir -p ${includedir} ${libdir}
-- cp -p ${srcdir}/regex.h ${includedir}
-- cp -p $(DEVDIST_FILES) ${libdir}
-+ mkdir -p ${includedir} $(DESTDIR)${libdir}
-+ cp -p ${srcdir}/regex.h $(DESTDIR)${includedir}
-+ cp -p $(DEVDIST_FILES) $(DESTDIR)${libdir}
- for s in 3 7; do \
--mkdir -p ${mandir}/man$$s; \
--gzip -c ${srcdir}/regex.$$s > ${mandir}/man$$s/regex.$$s.gz; \
-+mkdir -p $(DESTDIR)${mandir}/man$$s; \
-+gzip -c ${srcdir}/regex.$$s >
$(DESTDIR)${mandir}/man$$s/regex.$$s.gz; \
- done
-
- dist: bindist devdist srcdist
diff --git
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
index 1365f24..0194a06 100644
---
a/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
+++
b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
@@ -22,7 +22,7 @@ index 000..be0a797
+lib_LTLIBRARIES = libgnurx.la
+
+libgnurx_la_SOURCES = regex.c
-+libgnurx_la_includedir = $(includedir)
++libgnurx_la_includedir = $(includedir)/mingw-libgnurx
+libgnurx_la_include_HEADERS = regex.h
+libgnurx_la_CFLAGS = -I$(top_srcdir)
+libgnurx_la_LDFLAGS = -no-undefined -version-info 0:0:0 -export-dynamic
diff --git a/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
b/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
index 4547298..436660e 100644
--- a/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
+++ b/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
@@ -4,7 +4,6 @@ LICENSE = "LGPL-2.1-only"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=bbb461211a33b134d42ed5ee802b37ff"
SRC_URI =
"http://download.sourceforge.net/mingw/Other/UserContributed/regex/mingw-regex-${PV}/mingw-libgnurx-${PV}-src.tar.gz
\
- file://0001-Honor-DESTDIR-variable-during-install.patch \
file://0002-Add-autotool-files.patch \
"
SRC_URI[sha256sum] =
"7147b7f806ec3d007843b38e19f42a5b7c65894a57ffc297a76b0dcd5f675d76"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61783): https://lists.yoctoproject.org/g/yocto/message/61783
Mute This Topic: https://lists.yoctoproject.org/mt/102907503/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: linux-yocto@lists.yoctoproject.org yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> lists.yoctoproject.org
> Sent: Friday, December 1, 2023 03:08
> To: Bruce Ashfield
> Cc: linux-yocto@lists.yoctoproject.org
> Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of
> CPUs
>
> From: Paul Gortmaker
>
> The x86-64 BSP isn't quite the same as the "more specific" BSP like a
> Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
> hardware specifics for boards like those, the x86-64 BSP is more of a
> "generic" thing used as the baseline across an endless sea of boards.
>
> To that end, this is somewhat a revert of commit bd77e1f904f6
> ("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-
> bit bsp")
>
> It is great that a handful of people out there are using Yocto on these
> huge server machines, but that doesn't reflect 99% of the rest of us who
> continue to lean towards the original "embedded theme" of Yocto.
>
> That means a whole bunch of extra per-CPU jumping through hoops; some can
> be mitigated by booting with "nr_cpus=4" (or whatever the core count
> is) but I guarantee largely nobody out there is doing that.
>
> Let those users with the crazy CPU count own that config customization
> locally. The default is 64 which still seems way too large IMHO, but at
> least we are moving in the right direction.
This intel-x86-64 BSP is a generic one used from mobile to server.
Customers need to customize not only the CPU number config but also other
configs,
like, removing unused drivers or adding debug options.
>From this point of view, there is no difference between 64 or 512.
But it changes the "rule" that intel-x86-64 works for all supported platforms.
We need to do extra work for servers with large CPU number.
Thanks,
Yongxin
>
> Signed-off-by: Paul Gortmaker
> ---
> bsp/intel-x86/intel-x86-64.cfg | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-
> 64.cfg index 58b0fed637e8..da9bc7b57eca 100644
> --- a/bsp/intel-x86/intel-x86-64.cfg
> +++ b/bsp/intel-x86/intel-x86-64.cfg
> @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
>
> # x86 CPU resource control support
> CONFIG_X86_CPU_RESCTRL=y
> -
> -# Processor type and features
> -CONFIG_NR_CPUS=512
> --
> 2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13342):
https://lists.yoctoproject.org/g/linux-yocto/message/13342
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
> -Original Message- > From: linux-yocto@lists.yoctoproject.org yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via > lists.yoctoproject.org > Sent: Friday, December 1, 2023 03:08 > To: Bruce Ashfield > Cc: linux-yocto@lists.yoctoproject.org > Subject: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on > everyone > > From: Paul Gortmaker > > Similar to the argument of why we shouldn't force NUMA on everyone, the > 9 chip registered ECC RAM type stuff also tends to be found mostly on > larger server type stuff and less so on embedded targets. > > We already have a skeleton EDAC feature, so move the features over there. > One could argue that we might want to separate into arch specific config > fragments, but to me - that seems overkill at this point in time. > > Signed-off-by: Paul Gortmaker > --- > bsp/intel-x86/intel-x86-64.cfg | 13 - > features/edac/edac.cfg | 8 > 2 files changed, 8 insertions(+), 13 deletions(-) > > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86- > 64.cfg index f31711e73181..58b0fed637e8 100644 > --- a/bsp/intel-x86/intel-x86-64.cfg > +++ b/bsp/intel-x86/intel-x86-64.cfg > @@ -3,19 +3,6 @@ > # General setup > # > > -# EDAC > -CONFIG_EDAC=y > -CONFIG_EDAC_DEBUG=y > -CONFIG_EDAC_SBRIDGE=m > -CONFIG_ACPI_APEI=y > -CONFIG_ACPI_APEI_EINJ=m > -CONFIG_ACPI_APEI_GHES=y > -CONFIG_EDAC_PND2=m > -CONFIG_EDAC_SKX=m > -CONFIG_EDAC_I10NM=m > -CONFIG_EDAC_IGEN6=m > - > - > # ISH > CONFIG_INTEL_ISH_HID=m > > diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index > 9b3d3fc59eae..4f75d2f825ee 100644 > --- a/features/edac/edac.cfg > +++ b/features/edac/edac.cfg > @@ -15,3 +15,11 @@ > CONFIG_RAS=y > CONFIG_EDAC=y > CONFIG_EDAC_DEBUG=y > +CONFIG_EDAC_SBRIDGE=m > +CONFIG_ACPI_APEI=y > +CONFIG_ACPI_APEI_EINJ=m > +CONFIG_ACPI_APEI_GHES=y > +CONFIG_EDAC_PND2=m > +CONFIG_EDAC_SKX=m > +CONFIG_EDAC_I10NM=m Other arch/bsp may include edac.scc. They clearly don't want EDAC drivers for x86 platform. And since CONFIG_EDAC_I10NM depends on X86_64, won't it cause warnings when doing kernel_configcheck for other arch? Thanks, Yongxin > +CONFIG_EDAC_IGEN6=m > -- > 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13341): https://lists.yoctoproject.org/g/linux-yocto/message/13341 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] The postinstall intercept hook 'update_mime_database' failed
Hi,
I have taken over a imx8mm project that is based on kirkstone. I don't
think it is an official release and some layers are not even a
kirkstone release. The project has a reference build but currently it
is not possible to build from scratch. I have been fixing some issues
on the way to try and build a complete build from scratch but now I
have encountered an issue when creating the rootfs that I am
struggling with. The issues that I am getting is
ERROR: fsl-image-gui-1.0-r0 do_rootfs: The postinstall intercept hook
'update_mime_database' failed, details in
/workspace/mender-imx8mm/builds/tmp/work/imx8mm_var_dart-fslc-linux/fsl-image-gui/1.0-r0/temp/log.do_rootfs
ERROR: Logfile of failure stored in:
/workspace/mender-imx8mm/builds/tmp/work/imx8mm_var_dart-fslc-linux/fsl-image-gui/1.0-r0/temp/log.do_rootfs.335539
ERROR: Task
(/workspace/mender-imx8mm/sources/meta-variscite-sdk/recipes-fsl/images/fsl-image-gui.bb:do_rootfs)
failed with exit code '1'
checking the log file
NOTE: Running intercept scripts:
NOTE: > Executing update_mime_database intercept ...
NOTE: Exit code 1. Output:
Updating MIME database... this may take a while.
Directory
'/workspace/mender-imx8mm/builds/tmp/work/imx8mm_var_dart-fslc-linux/fsl-image-gui/1.0-r0/rootfs/packages'
does not exist!
In poky/meta/classes/mime.bbclass there is a comment that seems to
refer to this issue
# $D${MIMEDIR}/packages belong to package shared-mime-info-data,
# packages like libfm-mime depend on shared-mime-info-data.
# after shared-mime-info-data uninstalled, $D${MIMEDIR}/packages
# is removed, but update-mime-database need this dir to update
# database, workaround to create one and remove it later
if [ ! -d $D${MIMEDIR}/packages ]; then
mkdir -p $D${MIMEDIR}/packages
update-mime-database $D${MIMEDIR}
rmdir --ignore-fail-on-non-empty $D${MIMEDIR}/packages
else
update-mime-database $D${MIMEDIR}
fi
This is not called so no packages directory doesn't exist and the
intercept script failed. I can adjust the script
poky/scripts/postinst-intercepts/update_mime_database
echo "Updating MIME database... this may take a while."
update-mime-database $D${mimedir}
By adding a similar logic I will get forward but with my build but
that doesn't seem like the right solution. Also I just get some other
issue related to a second intercept script update_desktop_database so
to me it seems more like something is not correctly set up in the
build. I am trying to understand how these intercept scripts are
configured and why they are not working for my build. Any pointers on
how to move forward would be much appreciated.
BR
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61782): https://lists.yoctoproject.org/g/yocto/message/61782
Mute This Topic: https://lists.yoctoproject.org/mt/102901287/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 5/5] BSP: remove from all - latencytop feature inclusion
From: Paul Gortmaker Consider this 5+ year old commit commit bcbc7bbc4fb967d8d4ae6333f71b73491a80b94e Author: Alexander Kanavin Date: Thu Mar 1 16:00:41 2018 +0200 latencytop: remove recipe Last commit and release were in 2009; website is down; it's a dead project. (From OE-Core rev: 36aae56e7f86a4d5ce93e4528e7dcc42f60c705e) Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Given that, it seems sensible to drop it from default inclusion across the BSPs. I've left the feature itself, so anyone who still cares can easily manually add it still. Signed-off-by: Paul Gortmaker --- bsp/amd-x86/amd-x86-64.scc | 1 - bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc| 1 - bsp/common-pc/common-pc-preempt-rt.scc | 1 - bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc | 1 - bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc | 1 - bsp/intel-common/intel-developer-drivers.scc | 1 - bsp/intel-x86/intel-x86.scc | 1 - bsp/minnow/minnow-preempt-rt.scc | 1 - bsp/minnow/minnow-standard.scc | 1 - bsp/mti-malta32/mti-malta32.scc | 1 - bsp/mti-malta64/mti-malta64-be-developer.scc | 1 - bsp/qemu-ppc32/qemu-ppc32.scc| 1 - bsp/qemu-ppc64/qemu-ppc64-standard.scc | 3 --- bsp/qemumicroblaze/qemumicroblazeeb-standard.scc | 1 - bsp/qemumicroblaze/qemumicroblazeel-standard.scc | 1 - bsp/xilinx/zynq-standard.scc | 1 - 16 files changed, 18 deletions(-) diff --git a/bsp/amd-x86/amd-x86-64.scc b/bsp/amd-x86/amd-x86-64.scc index 8080eadcb462..87f23b51db70 100644 --- a/bsp/amd-x86/amd-x86-64.scc +++ b/bsp/amd-x86/amd-x86-64.scc @@ -9,7 +9,6 @@ include cfg/efi-ext.scc include cfg/virtio.scc include cfg/boot-live.scc include cfg/usb-mass-storage.scc -include features/latencytop/latencytop.scc include features/profiling/profiling.scc include features/netfilter/netfilter.scc diff --git a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc index 42b9c6917593..8c654b99736f 100755 --- a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc +++ b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc @@ -3,7 +3,6 @@ kconf hardware bcm-2xxx-rpi.cfg include cfg/usb-mass-storage.scc include features/profiling/profiling.scc -include features/latencytop/latencytop.scc include features/hostapd/hostapd.scc include features/mac80211/mac80211.scc diff --git a/bsp/common-pc/common-pc-preempt-rt.scc b/bsp/common-pc/common-pc-preempt-rt.scc index cdba3bd014cc..7044022de9b9 100644 --- a/bsp/common-pc/common-pc-preempt-rt.scc +++ b/bsp/common-pc/common-pc-preempt-rt.scc @@ -12,6 +12,5 @@ include bsp/common-pc/common-pc.scc # default policy for preempt-rt kernels include cfg/boot-live.scc include cfg/usb-mass-storage.scc -include features/latencytop/latencytop.scc include features/profiling/profiling.scc include cfg/virtio.scc diff --git a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc index 4f8bcf253f21..231d56542b7e 100644 --- a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc +++ b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-preempt-rt.scc @@ -9,5 +9,4 @@ include ktypes/preempt-rt/preempt-rt.scc include fsl-mpc8315e-rdb.scc # default policy for preempt-rt kernels -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc index 0f00d23ed784..fa797badf622 100644 --- a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc +++ b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb-standard.scc @@ -10,5 +10,4 @@ branch fsl-mpc8315e-rdb include fsl-mpc8315e-rdb.scc # default policy for standard kernels -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/intel-common/intel-developer-drivers.scc b/bsp/intel-common/intel-developer-drivers.scc index 5bb73e3e1da2..090d05ed7d72 100644 --- a/bsp/intel-common/intel-developer-drivers.scc +++ b/bsp/intel-common/intel-developer-drivers.scc @@ -1,4 +1,3 @@ # SPDX-License-Identifier: MIT # Additional features for developer bsps -include features/latencytop/latencytop.scc include features/profiling/profiling.scc diff --git a/bsp/intel-x86/intel-x86.scc b/bsp/intel-x86/intel-x86.scc index a747961fdbd1..7825075d5dcc 100644 --- a/bsp/intel-x86/intel-x86.scc +++ b/bsp/intel-x86/intel-x86.scc @@ -29,7 +29,6 @@ include features/usb/uhci-hcd.scc include features/usb/ehci-hcd.scc include features/usb/xhci-hcd.scc include features/hostapd/hostapd.scc -include features/latencytop/latencytop.scc include features/uio/uio.scc include features/spi/spi.scc include features/mtd/mtd.scc diff --git a/bsp/minnow/minnow-preempt-rt.scc b/bsp/minnow/minnow-preempt-rt.scc index
[linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
From: Paul Gortmaker Similar to the argument of why we shouldn't force NUMA on everyone, the 9 chip registered ECC RAM type stuff also tends to be found mostly on larger server type stuff and less so on embedded targets. We already have a skeleton EDAC feature, so move the features over there. One could argue that we might want to separate into arch specific config fragments, but to me - that seems overkill at this point in time. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 13 - features/edac/edac.cfg | 8 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index f31711e73181..58b0fed637e8 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -3,19 +3,6 @@ # General setup # -# EDAC -CONFIG_EDAC=y -CONFIG_EDAC_DEBUG=y -CONFIG_EDAC_SBRIDGE=m -CONFIG_ACPI_APEI=y -CONFIG_ACPI_APEI_EINJ=m -CONFIG_ACPI_APEI_GHES=y -CONFIG_EDAC_PND2=m -CONFIG_EDAC_SKX=m -CONFIG_EDAC_I10NM=m -CONFIG_EDAC_IGEN6=m - - # ISH CONFIG_INTEL_ISH_HID=m diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index 9b3d3fc59eae..4f75d2f825ee 100644 --- a/features/edac/edac.cfg +++ b/features/edac/edac.cfg @@ -15,3 +15,11 @@ CONFIG_RAS=y CONFIG_EDAC=y CONFIG_EDAC_DEBUG=y +CONFIG_EDAC_SBRIDGE=m +CONFIG_ACPI_APEI=y +CONFIG_ACPI_APEI_EINJ=m +CONFIG_ACPI_APEI_GHES=y +CONFIG_EDAC_PND2=m +CONFIG_EDAC_SKX=m +CONFIG_EDAC_I10NM=m +CONFIG_EDAC_IGEN6=m -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13338): https://lists.yoctoproject.org/g/linux-yocto/message/13338 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/5] x86-64: separate out the NUMA features to our existing NUMA scc/cfg
From: Paul Gortmaker A user reported getting NUMA warnings like the ones reported here: https://www.suse.com/support/kb/doc/?id=21040 "Fail to get numa node for CPU:0 bus:0 dev:0 fn:1" ...and repeated for every core on the platform. Distracting. When I asked if it was a crazy big server system with multiple CPU sockets and localized RAM near each socket - the answer was "no". Turns out they didn't choose NUMA support - rather we did it for them. Yocto has been and still remains more "embedded leaning". That is not to say we can't support NUMA. We just shouldn't be enabling it by default in the base x86-64 config fragment that everyone uses. Move the two NUMA settings that were not in our existing numa.cfg feature out of the BSP and into the feature. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 7 --- features/numa/numa.cfg | 2 ++ 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index a8de30cae983..f31711e73181 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -2,13 +2,6 @@ # # General setup # -CONFIG_NUMA_BALANCING=y -CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y - -# -# ACPI NUMA -# -CONFIG_X86_64_ACPI_NUMA=y # EDAC CONFIG_EDAC=y diff --git a/features/numa/numa.cfg b/features/numa/numa.cfg index cc550c4c3c96..e925f90ea148 100644 --- a/features/numa/numa.cfg +++ b/features/numa/numa.cfg @@ -1,5 +1,7 @@ # SPDX-License-Identifier: MIT CONFIG_NUMA=y +CONFIG_NUMA_BALANCING=y +CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_NODES_SHIFT=6 -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13337): https://lists.yoctoproject.org/g/linux-yocto/message/13337 Mute This Topic: https://lists.yoctoproject.org/mt/102900652/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 0/5] kernel-cache: config cleanups
From: Paul Gortmaker Bruce, Here are a few things that have bugged me and finally added up to make a series possibly worthwhile. We've been forcing NUMA and EDAC and 512 CPU support on everyone: even people building for a point-of-sale terminal using an intel Atom. Doesn't make sense. Let those "big iron" server folks opt-in as they see fit using our features support. I didn't touch x86-32 in regards to the above changes, because I consider that "legacy EOL" -- which generally means "leave alone". Also, latencytop has "expired" years ago, so we catch up accordingly. Target branch is master so we have time to see if anyone complains. I don't see a lot of value in backporting to already released branches. Further details are in the commit logs. Thanks, Paul. -- Paul Gortmaker (5): x86-64: consolidate crypto options x86-64: separate out the NUMA features to our existing NUMA scc/cfg x86-64: don't force EDAC support on everyone x86-64: use the defaults for number of CPUs BSP: remove from all - latencytop feature inclusion bsp/amd-x86/amd-x86-64.scc| 1 - bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.scc | 1 - bsp/common-pc/common-pc-preempt-rt.scc| 1 - .../fsl-mpc8315e-rdb-preempt-rt.scc | 1 - .../fsl-mpc8315e-rdb-standard.scc | 1 - bsp/intel-common/intel-developer-drivers.scc | 1 - bsp/intel-x86/intel-x86-64.cfg| 31 +++ bsp/intel-x86/intel-x86.scc | 1 - bsp/minnow/minnow-preempt-rt.scc | 1 - bsp/minnow/minnow-standard.scc| 1 - bsp/mti-malta32/mti-malta32.scc | 1 - bsp/mti-malta64/mti-malta64-be-developer.scc | 1 - bsp/qemu-ppc32/qemu-ppc32.scc | 1 - bsp/qemu-ppc64/qemu-ppc64-standard.scc| 3 -- .../qemumicroblazeeb-standard.scc | 1 - .../qemumicroblazeel-standard.scc | 1 - bsp/xilinx/zynq-standard.scc | 1 - features/edac/edac.cfg| 8 + features/numa/numa.cfg| 2 ++ 19 files changed, 14 insertions(+), 45 deletions(-) -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13335): https://lists.yoctoproject.org/g/linux-yocto/message/13335 Mute This Topic: https://lists.yoctoproject.org/mt/102900650/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/5] x86-64: consolidate crypto options
From: Paul Gortmaker No functional change - just makes further reorganizations and refactoring more easy to review/parse. Signed-off-by: Paul Gortmaker --- bsp/intel-x86/intel-x86-64.cfg | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg index 682d5f9d125f..a8de30cae983 100644 --- a/bsp/intel-x86/intel-x86-64.cfg +++ b/bsp/intel-x86/intel-x86-64.cfg @@ -9,10 +9,6 @@ CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y # ACPI NUMA # CONFIG_X86_64_ACPI_NUMA=y -CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m -CONFIG_CRYPTO_SHA1_SSSE3=m -CONFIG_CRYPTO_SHA256_SSSE3=m -CONFIG_CRYPTO_SHA512_SSSE3=m # EDAC CONFIG_EDAC=y @@ -38,6 +34,10 @@ CONFIG_PCI_IOV=y CONFIG_CRYPTO=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_HMAC=y +CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m +CONFIG_CRYPTO_SHA1_SSSE3=m +CONFIG_CRYPTO_SHA256_SSSE3=m +CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_AES_NI_INTEL=m # For different QAT devices -- 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13336): https://lists.yoctoproject.org/g/linux-yocto/message/13336 Mute This Topic: https://lists.yoctoproject.org/mt/102900651/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
From: Paul Gortmaker
The x86-64 BSP isn't quite the same as the "more specific" BSP like a
Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
hardware specifics for boards like those, the x86-64 BSP is more of a
"generic" thing used as the baseline across an endless sea of boards.
To that end, this is somewhat a revert of commit bd77e1f904f6
("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-bit
bsp")
It is great that a handful of people out there are using Yocto on these
huge server machines, but that doesn't reflect 99% of the rest of us who
continue to lean towards the original "embedded theme" of Yocto.
That means a whole bunch of extra per-CPU jumping through hoops; some
can be mitigated by booting with "nr_cpus=4" (or whatever the core count
is) but I guarantee largely nobody out there is doing that.
Let those users with the crazy CPU count own that config customization
locally. The default is 64 which still seems way too large IMHO, but
at least we are moving in the right direction.
Signed-off-by: Paul Gortmaker
---
bsp/intel-x86/intel-x86-64.cfg | 3 ---
1 file changed, 3 deletions(-)
diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg
index 58b0fed637e8..da9bc7b57eca 100644
--- a/bsp/intel-x86/intel-x86-64.cfg
+++ b/bsp/intel-x86/intel-x86-64.cfg
@@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
# x86 CPU resource control support
CONFIG_X86_CPU_RESCTRL=y
-
-# Processor type and features
-CONFIG_NR_CPUS=512
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13339):
https://lists.yoctoproject.org/g/linux-yocto/message/13339
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] help: gobject-introspection build error #raspberrypi
Hi all, I am at a loss as to why my build is failing. I am building core-image-minimal (for the Raspberry Pi 4) in the Poky Docker container and every time the build for gobject-introspection fails with the following error(s): FAILED: gir/GLib-2.0.gir /workdir/poky/build/tmp/work/cortexa72-poky-linux/gobject-introspection/1.78.1/recipe-sysroot/usr/include/glib-2.0/glib/gutils.h:378: syntax error, unexpected INTEGER, expecting identifier in ' if ((__builtin_expect (__extensio. A full log file for this can be found at https://pastebin.com/iuavxeJs If anyone knows why this may be happening - or even where to start looking - I would be very thankful! Many thanks, George --- George Peppard (he/they) Undergraduate, MEng Computer Science Electronics and Computer Science University of Southampton PGP: DC54 E1A7 336D CA37 DD35 CC89 8EA6 B970 558D 5F59 at the Ubuntu keyserver ( https://keyserver.ubuntu.com/ ) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61781): https://lists.yoctoproject.org/g/yocto/message/61781 Mute This Topic: https://lists.yoctoproject.org/mt/102898680/21656 Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw
On Thu, Nov 30, 2023 at 12:31 AM wenlin.k...@windriver.com via
lists.yoctoproject.org
wrote:
>
> From: Wenlin Kang
>
> Steps to reproduce
> 1) add layer meta-mingw
> 2) add line in local.conf
> SDKMACHINE = "x86_64-mingw32"
> 3) bitbake nativesdk-libxcrypt
>
> Fixed:
> 1. .symver error
> | {standard input}: Assembler messages:
> | {standard input}:4: Error: unknown pseudo-op: `.symver'
>
> 2. pedantic error
> | ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';' outside
> of a function [-Werror=pedantic]
> | 316 | SYMVER_crypt_gensalt_rn;
> | |
>
> 3. conversion error
> | ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
> | ../git/lib/util-get-random-bytes.c:140:42: error: conversion from
> 'size_t' {aka 'long long unsigned int'} to 'unsigned int' may change value
> [-Werror=conversion]
> | 140 | ssize_t nread = read (fd, buf, buflen);
>
> Signed-off-by: Wenlin Kang
> ---
> .../0001-Fix-for-compilation-on-Windows.patch | 37 +++
> ...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
> recipes-core/libxcrypt/libxcrypt_%.bbappend | 7 +++
> 3 files changed, 91 insertions(+)
> create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> create mode 100644
> recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
>
> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> new file mode 100644
> index 000..5760ee0
> --- /dev/null
> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
> @@ -0,0 +1,37 @@
> +From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
> +From: Brecht Sanders
> +Date: Fri, 3 Feb 2023 08:44:49 +0100
> +Subject: [PATCH] Fix for compilation on Windows
> +
> +This fix allows the library to build on Windows (at least with MinGW-w64).
> +
> +`.symver` is only supported for ELF format but Windows uses COFF/PE.
> +
> +Workaround dummy define of `symver_set()`
> +
> +Upstream-Status: Backport
> [https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624]
> +
> +Signed-off-by: Wenlin Kang
> +---
> + lib/crypt-port.h | 5 +
> + 1 file changed, 5 insertions(+)
> +
> +diff --git a/lib/crypt-port.h b/lib/crypt-port.h
> +index f06ca24..a707939 100644
> +--- a/lib/crypt-port.h
> b/lib/crypt-port.h
> +@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t
> d_size, const void *src);
> + __asm__(".globl _" extstr); \
> + __asm__(".set _" extstr ", _" #intname)
> +
> ++#elif defined _WIN32
> ++
> ++/* .symver is only supported for ELF format, Windows uses COFF/PE */
> ++# define symver_set(extstr, intname, version, mode)
> ++
> + #elif defined __GNUC__ && __GNUC__ >= 3
> +
> + # define _strong_alias(name, aliasname) \
> +--
> +2.34.1
> +
> diff --git
> a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
>
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> new file mode 100644
> index 000..3846f76
> --- /dev/null
> +++
> b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
> @@ -0,0 +1,47 @@
> +From ff99091eb8a6b9e6edc567f6d2552183fbaacec3 Mon Sep 17 00:00:00 2001
> +From: Wenlin Kang
> +Date: Mon, 6 Nov 2023 14:43:28 +0800
> +Subject: [PATCH] lib/util-get-random-bytes.c: fixed conversion error with
> + mingw
> +
> +With x86_64-w64-mingw32-gcc. get below error:
> +| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
> +| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t'
> {aka 'long long unsigned int'} to 'unsigned int' may change value
> [-Werror=conversion]
> +| 140 | ssize_t nread = read (fd, buf, buflen);
> +| | ^~
> +
> +In util-get-random-bytes.c, has get_random_bytes(void *buf, size_t buflen),
> +but in mingw-w64-mingw-w64/mingw-w64-headers/crt/io.h, read() has "unsigned
> int"
> +read(int _FileHandle,void *_DstBuf,unsigned int _MaxCharCount), and has:
> + #ifdef _WIN64
> + __MINGW_EXTENSION typedef unsigned __int64 size_t;
> + #else
> + typedef unsigned int size_t;
> + #endif /* _WIN64 */
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Wenlin Kang
> +---
> + lib/util-get-random-bytes.c | 4
> + 1 file changed, 4 insertions(+)
> +
> +diff --git a/lib/util-get-random-bytes.c b/lib/util-get-random-bytes.c
> +index 79816db..68cd378 100644
> +--- a/lib/util-get-random-bytes.c
> b/lib/util-get-random-bytes.c
> +@@ -137,7 +137,11 @@ get_random_bytes(void *buf, size_t buflen)
> +
[yocto] [yocto-autobuilder-helper] scripts/run-toaster-tests.py: run via pytest and fix environment setup
Signed-off-by: Alexander Lussier-Cullen --- scripts/run-toaster-tests | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/scripts/run-toaster-tests b/scripts/run-toaster-tests index 516965e..08528c7 100755 --- a/scripts/run-toaster-tests +++ b/scripts/run-toaster-tests @@ -16,13 +16,18 @@ pokydir=$(realpath "$2") cd $builddir bitbake -e > bbenv -export SSTATE_DIR=$(grep '^SSTATE_DIR=' bbenv | cut -d "=" -f2-) -export DL_DIR=$(grep '^DL_DIR=' bbenv | cut -d "=" -f2-) +export SSTATE_DIR=$(grep '^SSTATE_DIR=' bbenv | cut -d "=" -f2- | sed -e 's/^"//' -e 's/"$//') +export DL_DIR=$(grep '^DL_DIR=' bbenv | cut -d "=" -f2- | sed -e 's/^"//' -e 's/"$//') export TOASTER_DJANGO_TMPDIR=$builddir +export TOASTER_DIR=$builddir mkdir -p toaster_logs + python3 -m venv venv --without-pip --system-site-packages source venv/bin/activate -python3 -m pip install tox +python3 -m pip install -r $pokydir/bitbake/toaster-requirements.txt -r $pokydir/bitbake/lib/toaster/tests/toaster-tests-requirements.txt +# reactivate venv to make sure packages are all properly initialized +deactivate && source venv/bin/activate + +pytest -c $pokydir/bitbake/lib/toaster/pytest.ini $pokydir/bitbake/lib/toaster/tests/ -tox -c $pokydir/bitbake/lib/toaster/tox.ini -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61779): https://lists.yoctoproject.org/g/yocto/message/61779 Mute This Topic: https://lists.yoctoproject.org/mt/102893736/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SBOM in Yocto Zeus
I'm afraid you do have to update your yocto to something where spdx is supported. That's why we constantly urge everyone to stay close to upstream yocto, and have a process where that happens regularly, otherwise you will not be able to fulfil business requirements for your products in the longer term. Alex On Thu, 30 Nov 2023 at 12:40, Poornesh G ( India - Bangalore ) wrote: > > Greetings ! > > We have used yocto zeus for one of our medical application with i.MX6UL SoC . > This is initiated couple of years back , at that time "Zeus" was the latest > hence we went through yocto zeus . > Now we are having a requirement of SBOM with spdx format. I got to know that > zeus will not support this. Since most of the developmental work has > completed we could not able to upgrade the yocto as of now. Are there any > alternatives available in yocto zeus for creating SBOM. > Can anyone suggest me possible ways/procedures using which I can able to > create SBOM with spdx format . > > Thanks in advance. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61778): https://lists.yoctoproject.org/g/yocto/message/61778 Mute This Topic: https://lists.yoctoproject.org/mt/102891851/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] SBOM in Yocto Zeus
Greetings ! We have used yocto zeus for one of our medical application with i.MX6UL SoC . This is initiated couple of years back , at that time "Zeus" was the latest hence we went through yocto zeus . Now we are having a requirement of SBOM with spdx format. I got to know that zeus will not support this. Since most of the developmental work has completed we could not able to upgrade the yocto as of now. Are there any alternatives available in yocto zeus for creating SBOM. Can anyone suggest me possible ways/procedures using which I can able to create SBOM with spdx format . Thanks in advance. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61777): https://lists.yoctoproject.org/g/yocto/message/61777 Mute This Topic: https://lists.yoctoproject.org/mt/102891851/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.1.rc1)
Hi All, QA for yocto-4.3.1.rc1 is completed. This is the full report for this release: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Jing Hui > -Original Message- > From: yocto@lists.yoctoproject.org On Behalf > Of Pokybuild User > Sent: Saturday, November 25, 2023 8:59 AM > To: yocto@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [yocto] QA notification for completed autobuilder build (yocto- > 4.3.1.rc1) > > > A build flagged for QA (yocto-4.3.1.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-4.3.1.rc1 > > > Build URL: > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6242 > > Build hash information: > > bitbake: 936fcec41efacc4ce988c81882a9ae6403702bea > meta-agl: 22ea97e52898c7ee3e32e0c683166c9071e37adf > meta-arm: db658a77af7e15cdb8e4d9231bef8c48c5d327fb > meta-aws: ac6f26f5707c51091ead00b26bffd3fa899dab71 > meta-intel: 52ce86a7f5f1ed751d80bc5e1d6b76db1c5b84c8 > meta-mingw: 49617a253e09baabbf0355bc736122e9549c8ab2 > meta-openembedded: 991e6852a53e0fcd40af8f0386d7f46bb318015e > meta-virtualization: a215d8320edee0a317a6511e7e2efa5bba867486 > oecore: cce77e8e79c860f4ef0ac4a86b9375bf87507360 > poky: bf9f2f6f60387b3a7cd570919cef6c4570edcb82 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61776): https://lists.yoctoproject.org/g/yocto/message/61776 Mute This Topic: https://lists.yoctoproject.org/mt/102790429/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [yocto-kernel-cache yocto-6.1][PATCH] microchip-polarfire-soc: Updated BSP configuration
From: "Saravanan.K.S" Added CONFIG_RISCV_SBI_V01 to enable CONFIG_SERIAL_EARLYCON_RISCV_SBI Removed deprecated config CONFIG_GPIO_SYSFS Removed unused configuration CONFIG_RPMSG_MIV Signed-off-by: Saravanan.K.S --- bsp/microchip-polarfire-soc/microchip-polarfire-soc.cfg | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bsp/microchip-polarfire-soc/microchip-polarfire-soc.cfg b/bsp/microchip-polarfire-soc/microchip-polarfire-soc.cfg index 9e5c1800..64e271c3 100644 --- a/bsp/microchip-polarfire-soc/microchip-polarfire-soc.cfg +++ b/bsp/microchip-polarfire-soc/microchip-polarfire-soc.cfg @@ -35,6 +35,7 @@ CONFIG_MICREL_PHY=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_RISCV_SBI_V01=y CONFIG_SERIAL_EARLYCON_RISCV_SBI=y CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_POLARFIRE_SOC=y @@ -46,7 +47,6 @@ CONFIG_SPI_MICROCHIP_CORE=y CONFIG_SPI_MICROCHIP_CORE_QSPI=y CONFIG_SPI_SPIDEV=y CONFIG_GPIOLIB=y -CONFIG_GPIO_SYSFS=y CONFIG_GPIO_POLARFIRE_SOC=y CONFIG_PMBUS=y CONFIG_POWER_RESET=y @@ -86,7 +86,6 @@ CONFIG_REMOTEPROC_CDEV=y CONFIG_MIV_REMOTEPROC=y CONFIG_RPMSG_CHAR=y CONFIG_RPMSG_CTRL=y -CONFIG_RPMSG_MIV=y CONFIG_RPMSG_TTY=y CONFIG_RPMSG_VIRTIO=y CONFIG_POLARFIRE_SOC_SYS_CTRL=y -- 2.35.5 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13334): https://lists.yoctoproject.org/g/linux-yocto/message/13334 Mute This Topic: https://lists.yoctoproject.org/mt/102891600/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw][kirkstone][PATCH] libxcrypt: fixed some build error for nativesdk with mingw
From: Wenlin Kang
Steps to reproduce
1) add layer meta-mingw
2) add line in local.conf
SDKMACHINE = "x86_64-mingw32"
3) bitbake nativesdk-libxcrypt
Fixed:
1. .symver error
| {standard input}: Assembler messages:
| {standard input}:4: Error: unknown pseudo-op: `.symver'
2. pedantic error
| ../git/lib/crypt.c:316:24: error: ISO C does not allow extra ';' outside of
a function [-Werror=pedantic]
| 316 | SYMVER_crypt_gensalt_rn;
| |
3. conversion error
| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t'
{aka 'long long unsigned int'} to 'unsigned int' may change value
[-Werror=conversion]
| 140 | ssize_t nread = read (fd, buf, buflen);
Signed-off-by: Wenlin Kang
---
.../0001-Fix-for-compilation-on-Windows.patch | 37 +++
...dom-bytes.c-fixed-conversion-error-w.patch | 47 +++
recipes-core/libxcrypt/libxcrypt_%.bbappend | 7 +++
3 files changed, 91 insertions(+)
create mode 100644
recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
create mode 100644
recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
create mode 100644 recipes-core/libxcrypt/libxcrypt_%.bbappend
diff --git
a/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
new file mode 100644
index 000..5760ee0
--- /dev/null
+++ b/recipes-core/libxcrypt/libxcrypt/0001-Fix-for-compilation-on-Windows.patch
@@ -0,0 +1,37 @@
+From a507b628a5a5d4e4f1cf0f0a9a72967470ee7624 Mon Sep 17 00:00:00 2001
+From: Brecht Sanders
+Date: Fri, 3 Feb 2023 08:44:49 +0100
+Subject: [PATCH] Fix for compilation on Windows
+
+This fix allows the library to build on Windows (at least with MinGW-w64).
+
+`.symver` is only supported for ELF format but Windows uses COFF/PE.
+
+Workaround dummy define of `symver_set()`
+
+Upstream-Status: Backport
[https://github.com/besser82/libxcrypt/commit/a507b628a5a5d4e4f1cf0f0a9a72967470ee7624]
+
+Signed-off-by: Wenlin Kang
+---
+ lib/crypt-port.h | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/lib/crypt-port.h b/lib/crypt-port.h
+index f06ca24..a707939 100644
+--- a/lib/crypt-port.h
b/lib/crypt-port.h
+@@ -201,6 +201,11 @@ extern size_t strcpy_or_abort (void *dst, size_t d_size,
const void *src);
+ __asm__(".globl _" extstr); \
+ __asm__(".set _" extstr ", _" #intname)
+
++#elif defined _WIN32
++
++/* .symver is only supported for ELF format, Windows uses COFF/PE */
++# define symver_set(extstr, intname, version, mode)
++
+ #elif defined __GNUC__ && __GNUC__ >= 3
+
+ # define _strong_alias(name, aliasname) \
+--
+2.34.1
+
diff --git
a/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
new file mode 100644
index 000..3846f76
--- /dev/null
+++
b/recipes-core/libxcrypt/libxcrypt/0001-lib-util-get-random-bytes.c-fixed-conversion-error-w.patch
@@ -0,0 +1,47 @@
+From ff99091eb8a6b9e6edc567f6d2552183fbaacec3 Mon Sep 17 00:00:00 2001
+From: Wenlin Kang
+Date: Mon, 6 Nov 2023 14:43:28 +0800
+Subject: [PATCH] lib/util-get-random-bytes.c: fixed conversion error with
+ mingw
+
+With x86_64-w64-mingw32-gcc. get below error:
+| ../git/lib/util-get-random-bytes.c: In function '_crypt_get_random_bytes':
+| ../git/lib/util-get-random-bytes.c:140:42: error: conversion from 'size_t'
{aka 'long long unsigned int'} to 'unsigned int' may change value
[-Werror=conversion]
+| 140 | ssize_t nread = read (fd, buf, buflen);
+| | ^~
+
+In util-get-random-bytes.c, has get_random_bytes(void *buf, size_t buflen),
+but in mingw-w64-mingw-w64/mingw-w64-headers/crt/io.h, read() has "unsigned
int"
+read(int _FileHandle,void *_DstBuf,unsigned int _MaxCharCount), and has:
+ #ifdef _WIN64
+ __MINGW_EXTENSION typedef unsigned __int64 size_t;
+ #else
+ typedef unsigned int size_t;
+ #endif /* _WIN64 */
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenlin Kang
+---
+ lib/util-get-random-bytes.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/lib/util-get-random-bytes.c b/lib/util-get-random-bytes.c
+index 79816db..68cd378 100644
+--- a/lib/util-get-random-bytes.c
b/lib/util-get-random-bytes.c
+@@ -137,7 +137,11 @@ get_random_bytes(void *buf, size_t buflen)
+ dev_urandom_doesnt_work = true;
+ else
+ {
++#ifdef _WIN64
++ ssize_t nread = read (fd, buf, (unsigned int)buflen);
++#else
+ ssize_t nread = read (fd, buf, buflen);
++#endif
+ if (nread < 0 || (size_t)nread < buflen)
+ dev_urandom_doesnt_work = true;
+
+--
+2.25.1
+
diff --git
