[yocto] [meta-cgl][PATCH] resource-agents: Fix build error with autoconf-2.73.

2023-08-28 Thread leimaohui 
From: Lei Maohui 

resource-agents is built failed after poky upgraded autoconf to 2.73.

Signed-off-by: Lei Maohui 
---
 .../resource-agents/autoconf-2.73.patch   | 30 +++
 .../resource-agents_4.5.0.bb  |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/autoconf-2.73.patch

diff --git 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/autoconf-2.73.patch
 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/autoconf-2.73.patch
new file mode 100644
index 000..af188d2
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents/autoconf-2.73.patch
@@ -0,0 +1,30 @@
+From 749d10d4c61a84d8ba506f178daededac8062c3f Mon Sep 17 00:00:00 2001
+From: Lei Maohui 
+Date: Wed, 16 Aug 2023 02:43:08 +
+Subject: [PATCH] autoconf-2.7:
+
+To fix build error with autoconf-2.7:
+
+| configure: error: in 
'/home/aarch64-test/tmp/work/aarch64-ubinux-linux/resource-agents/4.5.0-r0/build':
+| configure: error: C preprocessor "aarch64-ubinux-linux-gcc -E 
--sysroot=/home/aarch64-test/tmp/work/aarch64-ubinux-linux/resource-agents/4.5.0-r0/recipe-sysroot
   -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=format-security" fails sanity check
+
+Upstream-Status: Inappropriate
+Signed-off-by: Lei Maohui 
+---
+ configure.ac | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index d682ad780..8a525 100644
+--- a/configure.ac
 b/configure.ac
+@@ -883,7 +883,6 @@ else
+   -Wno-strict-aliasing
+   -Wpointer-arith
+   -Wstrict-prototypes
+-  -Wunsigned-char
+   -Wwrite-strings"
+
+ # Additional warnings it might be nice to enable one day
+--
+2.34.1
diff --git 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
index 764a1d2..357669a 100644
--- 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
+++ 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"git://github.com/ClusterLabs/resource-agents;branch=main;protocol=htt
file://fix-install-sh-not-found.patch \
file://0001-ldirectord.service.in-use-run-instead-of-var-run.patch \

file://0001-ldirectord.service.in-set-correct-path-of-rm-command.patch \
+   file://autoconf-2.73.patch \
   "
 
 SRCREV = "fee181320547365d7f8c88cca2b32801412b933d" 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60910): https://lists.yoctoproject.org/g/yocto/message/60910
Mute This Topic: https://lists.yoctoproject.org/mt/101025050/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] M+ & H bugs with Milestone Movements WW34

2023-08-28 Thread Stephen Jolley 
All,

YP M+ or high bugs which moved to a new milestone in WW34 are listed below:
Priority Bug ID Short Description Changer Owner Was Became
High 15199  AB-INT:
qemu-pcc failures randy.macl...@windriver.com
richard.pur...@linuxfoundation.org 0.0.0 4.3 M3
Medium+ 15195 
Dunfell:
Grub CVE-2020-27749 fix randy.macl...@windriver.com st...@sakoman.com 0.0.0
3.1.28

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60909): https://lists.yoctoproject.org/g/yocto/message/60909
Mute This Topic: https://lists.yoctoproject.org/mt/101023704/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW34!

2023-08-28 Thread Stephen Jolley 
All,

The below were the owners of enhancements or bugs closed during the last
week!
Who Count
richard.pur...@linuxfoundation.org 1
Grand Total 1

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60908): https://lists.yoctoproject.org/g/yocto/message/60908
Mute This Topic: https://lists.yoctoproject.org/mt/101023689/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 4.3

2023-08-28 Thread Stephen Jolley 
All,

Below is the list of top 28 bug owners as of the end of WW34 who have open
medium or higher bugs and enhancements against YP 4.3. There are 42
possible work days left until the final release candidates for YP 4.3 needs
to be released.
Who Count
michael.opdenac...@bootlin.com 34
ross.bur...@arm.com 33
richard.pur...@linuxfoundation.org 28
randy.macl...@windriver.com 23
david.re...@windriver.com 23
bruce.ashfi...@gmail.com 22
jpewhac...@gmail.com 11
pa...@zhukoff.net 6
sakib.sa...@windriver.com 5
pi...@pidge.org 5
yash.shi...@windriver.com 4
tim.orl...@konsulko.com 3
alexis.loth...@bootlin.com 3
sundeep.kokko...@windriver.com 2
jon.ma...@arm.com 2
alexandre.bell...@bootlin.com 2
yoann.con...@smile.fr 1
tvgamb...@gmail.com 1
thr...@amazon.de 1
thomas.per...@bootlin.com 1
pokyli...@reliableembeddedsystems.com 1
p.lob...@welotec.com 1
martin.ja...@gmail.com 1
mark.asselst...@windriver.com 1
louis.ran...@syslinbit.com 1
jens.ge...@desy.de 1
fathi.bou...@linaro.org 1
alejan...@enedino.org 1
Grand Total 218

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60907): https://lists.yoctoproject.org/g/yocto/message/60907
Mute This Topic: https://lists.yoctoproject.org/mt/101023663/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2023-08-28 Thread Stephen Jolley 
All,

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:
https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 419
unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “4.3”, “4.4”, "4.99" and "Future", the more
pressing/urgent issues being in "4.3" and then “4.4”.

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60906): https://lists.yoctoproject.org/g/yocto/message/60906
Mute This Topic: https://lists.yoctoproject.org/mt/101023615/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] Trial merge of v6.1.49 for linux-yocto

2023-08-28 Thread Kevin Hao 
Hi Bruce,

This is a trial merge of the stable kernel v6.1.49 for the following branches 
in the linux-yocto.
  a529ab771859  v6.1/standard/base
  481318b54b8d  v6.1/standard/preempt-rt/base
  630049034e2a  v6.1/standard/ti-sdk-6.1/ti-j7xxx
  2d0db8d36197  v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx
  503548e0d84d  v6.1/standard/nxp-sdk-6.1/nxp-soc
  79465708b981  v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc
  fe7aa9723588  v6.1/standard/cn-sdkv5.15/octeon
  845278dd366a  v6.1/standard/preempt-rt/cn-sdkv5.15/octeon
  052d78eed372  v6.1/standard/bcm-2xxx-rpi
  3281a716ae97  v6.1/standard/preempt-rt/bcm-2xxx-rpi
  517f99ede33a  v6.1/standard/nxp-sdk-5.15/nxp-s32g
  1705546590e0  v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
  b915040649da  v6.1/standard/intel-sdk-6.1/intel-socfpga
  e4e865eff795  v6.1/standard/preempt-rt/intel-sdk-6.1/intel-socfpga
  0affe5cf1f45  v6.1/standard/x86
  d701ab28327a  v6.1/standard/preempt-rt/x86
  fc80426fbfc5  v6.1/standard/sdkv6.1/xlnx-soc
  fe36ecf2db6d  v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc

This is a pretty simple stable release without any merge conflict.
All the branches have passed my build test. I have pushed all these branches to:
https://github.com/haokexin/linux

You can use this as a reference for the linux-yocto stable kernel bump.

Thanks,
Kevin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13022): 
https://lists.yoctoproject.org/g/linux-yocto/message/13022
Mute This Topic: https://lists.yoctoproject.org/mt/101023278/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-virtualization] nerdctl broken in kirkstone

2023-08-28 Thread Marek Belisko 
On Thu, Aug 24, 2023 at 4:05 PM Khem Raj  wrote:

> does it work if you add do_compile[network] = "1"
>
Nope it is not. It turns out that the fetch phase is not correct. When I do
bitbake nerdctl -e | grep SRC_URI I got only:

 SRC_URI="git://
github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"

and not other SRC_URI's added in src_uri.inc file. It's mystery to me why
this include is not working

>
> On Wed, Aug 23, 2023 at 11:14 PM Belisko Marek 
> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> > > On 24 Aug 2023, at 02:23, Khem Raj  wrote:
> > >
> > > which task is failing ?
> > do_compile
> > >
> > >> On Wed, Aug 23, 2023 at 2:31 PM Marek Belisko <
> marek.beli...@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm trying to add nerdctl to an image using kirkstone release for
> meta-virtualization.
> > >> I've added bbappend with following fix:
> > >>
> > >> SRC_URI = "git://
> github.com/containerd/nerdctl.git;name=nerdcli;branch=main;protocol=https"
> > >>
> > >> (branch name in original recipe is master but main is required)
> > >>
> > >> but then anyways it fails with:
> > >>
> > >> rsync: [sender] change_dir
> "/data/projects/test/build/tmp/work/cortexa53-crypto-poky-linux/nerdctl/v0.18.0-r0/nerdctl-v0.18.0/src/import/vendor.fetch/
> github.com/Masterminds/semver/v3" failed: No such file or directory (2)
> > >> | rsync error: some files/attrs were not transferred (see previous
> errors) (code 23) at main.c(1327) [sender=3.2.5]
> > >>
> > >> And in ${BP} I cannot see any of those vendor stuff which should be
> present. Is there some fix for that already pending or it's known issue?
> > >>
> > >> Thanks and BR,
> > >>
> > >> marek
> > >>
> > >> --
> > >> as simple and primitive as possible
> > >> -
> > >> Marek Belisko - OPEN-NANDRA
> > >> Freelance Developer
> > >>
> > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > >> Tel: +421 915 052 184
> > >> skype: marekwhite
> > >> twitter: #opennandra
> > >> web: http://open-nandra.com
> > >>
> > >> 
> > >>
>


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60905): https://lists.yoctoproject.org/g/yocto/message/60905
Mute This Topic: https://lists.yoctoproject.org/mt/100924569/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-darwin][PATCH] clang: remove runtime dependency to perl

2023-08-28 Thread Etienne Cordonnier via lists.yoctoproject.org 
From: Etienne Cordonnier 

Commit https://github.com/kraj/meta-clang/commit/68ec449f97ffa58d in meta-clang 
adds a dependency to perl,
however at the moment perl does not cross-compile for darwin (the build tries 
to use readelf which does not
exist on darwin, instead of using objdump).

This dependency is needed only for optional runtime tools, so just remove it at 
the moment.

Signed-off-by: Etienne Cordonnier 
---
 recipes-devtools/clang/clang_%.bbappend | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/recipes-devtools/clang/clang_%.bbappend 
b/recipes-devtools/clang/clang_%.bbappend
index 25a9bf7..ce2a3b3 100644
--- a/recipes-devtools/clang/clang_%.bbappend
+++ b/recipes-devtools/clang/clang_%.bbappend
@@ -8,6 +8,20 @@ PACKAGECONFIG:remove:class-nativesdk:darwin21 = "shared-libs"
 DEPENDS:remove:class-nativesdk = "clang-crosssdk-${SDK_ARCH}"
 DEPENDS:append:class-nativesdk = " clang-crosssdk-${SDK_SYS}"
 
+# perl tries to call readelf, which does not exist on darwin (it would need
+# to call objdump instead but the detection logic does not work for some 
reason)
+RDEPENDS:${PN}:remove:class-nativesdk:darwin21 = " \
+perl-module-digest-md5 \
+perl-module-file-basename \
+perl-module-file-copy \
+perl-module-file-find \
+perl-module-file-path \
+perl-module-findbin \
+perl-module-hash-util \
+perl-module-sys-hostname \
+perl-module-term-ansicolor \
+"
+
 COMPILER_RT:class-nativesdk:toolchain-clang:runtime-llvm:darwin21 = ""
 LIBCPLUSPLUS:class-nativesdk:toolchain-clang:darwin21 = " -stdlib=libstdc++"
 
-- 
2.36.1.vfs.0.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60904): https://lists.yoctoproject.org/g/yocto/message/60904
Mute This Topic: https://lists.yoctoproject.org/mt/101013335/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] bitbake controlling memory use

2023-08-28 Thread Martin Hundeb?ll 
On Sat, 2023-01-14 at 23:33 +0100, Ferry Toth wrote:
> Hi,
> 
> Op 10-01-2023 om 10:24 schreef Ferry Toth:
> > Hi,
> > 
> > On 10-01-2023 02:57, Randy MacLeod wrote:
> > > Add Zheng.
> > > Switch to Trevor's gmail since he might still be interested in
> > > this.
> > > 
> > > On 2023-01-09 05:49, Ferry Toth via lists.yoctoproject.org wrote:
> > > > Hi
> > > > 
> > > > On 09-01-2023 11:39, Alexander Kanavin wrote:
> > > > > On Sun, 8 Jan 2023 at 23:13, Ferry Toth 
> > > > > wrote:
> > > > > 
> > > > > > Now it works I'm not sure what to do. Richard marked the
> > > > > > original 
> > > > > > patch
> > > > > > as WIP. Maybe it's not appropriate for including into poky?
> > > > > > If so I
> > > > > > wouldn't mind carrying it in meta-intel-edison.
> > > > > > 
> > > > > > Or may be with a little work (from me) and a run on the CI
> > > > > > servers we
> > > > > > could make it go in?
> > > > > I'd rather teach make/ninja upstream to watch memory
> > > > > consumption
> > > > > and/or host pressure directly (e.g. similar to how it handles
> > > > > -l). And
> > > > > offer any resulting patches to upstream first.
> > > 
> As there is already a clone of ninja available with jobserver support
> available I added another patch to update to that version and make an
> intercept to actually pass the named pipe to ninja.
> 
> Find it here: https://github.com/htot/poky/commits/kirkstone
> 
> This makes both make and ninja threads running from a shared thread 
> pool. As cmake relies on ninja recipies are covered as well.
> 
> I guess this takes care of the majority of recipes.
> 
> In my case this new patch shaves no more then 1 minutes from my image
> build time (1h46) as the recipes built using ninja are not consuming 
> that much memory (like nodejs). I hope others will benefit more.
> 
> Todo: location of the pipe as mentioned by Richard

Hi Ferry et al.,

I've reworked the patches (once again...) into a global class that sets
up the jobserver configuration:
https://lore.kernel.org/openembedded-core/20230828124834.376779-1-mar...@geanix.com/T/#t

Since it's "just" a class, it can be carried in custom meta layers.
Also, it supports an external jobserver, which can be handy when
building multiple yocto confifgurations on i.e. a CI server...

// Martin

> > > Zheng and I *started* on that for make over the Xmas holiday.
> > > See the (poorly formatted) thread:
> > >   Add support for limiting CPU pressure, contrib, 2022/12/20
> > > in:
> > > https://lists.gnu.org/archive/html/bug-make/2022-12/threads.html
> > > 
> > > There were mixed reviews upstream with the maintainer, Paul
> > > Smith,
> > > seeming to prefer that we investigate the job server approach and
> > > the 
> > > current
> > > load averaging. I'll happily try to find time to play with
> > > Ferry's 
> > > job server work.
> > > 
> > The work is actually Richard's. I only fixed what broke over time.
> > > I've been thinking about the various workflows and as Richard
> > > said, 
> > > it seems
> > > that for many people who only do one build at a time, the job
> > > server 
> > > and maybe
> > > a little linker restraint, would be all that's needed. For
> > > activities 
> > > such
> > > as YP AB, we could teach the main job server to also look at 
> > > /proc/pressure
> > > as a way to limit the pool size we could make a meta-jobserver
> > > for 
> > > those who don't
> > > want/need to worry about non-compile tasks such as tests and
> > > build 
> > > clean-up.
> > > 
> > > 
> > > Note that cargo has the notion of a job server:
> > >    https://github.com/rust-lang/cargo/issues/1744
> > >    https://github.com/rust-lang/cargo/pull/4110
> > > 
> > > 
> > > and ninja has an open issue:
> > >    https://github.com/ninja-build/ninja/issues/1139
> > > and an initial implementation:
> > >    https://github.com/stefanb2/ninja/tree/topic-jobserver-fifo
> > > 
> > > What other build tools are in need of regulation and/or job
> > > server 
> > > patches?
> > > 
> > What I read, gcc has already -flto=jobserver.
> > 
> > Other (single threaded CPU intensive) might just be started from 
> > jobclient?
> > 
> > > ../Randy
> > > 
> > > 
> > > > > 
> > > > > Alex
> > > > 
> > > > Yeah, I'd rather teach the kernel to consider thrashing when 
> > > > scheduling jobs. As is now any user process can slow down any
> > > > other 
> > > > users process and even the kernel itself to a standstill.
> > > > 
> > > > But kernel developers consider those issues "orthogonal" (i.e.
> > > > they 
> > > > don't want to make the scheduler aware of io).
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60903): https://lists.yoctoproject.org/g/yocto/message/60903
Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]

[yocto] [meta-darwin][PATCH 2/2] gcc: re-add zstd dependency

2023-08-28 Thread Etienne Cordonnier via lists.yoctoproject.org 
From: Etienne Cordonnier 

The zstd cross-compile build for darwin was fixed in f786ea1379a64fbbd,
thus there is no need to remove this dependency any more.

Signed-off-by: Etienne Cordonnier 
---
 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend | 5 -
 1 file changed, 5 deletions(-)

diff --git a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend 
b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
index 43ae2b5..192ee0d 100644
--- a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
+++ b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
@@ -12,8 +12,3 @@ EXTRA_OECONF:remove:darwinsdk = "--enable-clocale=generic"
 
 # Remove -rpath-link and -rpath
 LDFLAGS:darwinsdk = "${BUILDSDK_LDFLAGS}"
-
-# zstd uses uname to determine the compiler's target and makes the assumption 
that the host OS is the target,
-# so it does not support Darwin as a cross-compiler target.
-# zstd is not really needed as a dependency of gcc, and zstd would need to be 
fixed to compile for Darwin
-DEPENDS:remove = "nativesdk-zstd"
-- 
2.36.1.vfs.0.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60902): https://lists.yoctoproject.org/g/yocto/message/60902
Mute This Topic: https://lists.yoctoproject.org/mt/101006549/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-darwin][PATCH 1/2] gcc: rebase patches on top of gcc 11.4

2023-08-28 Thread Etienne Cordonnier via lists.yoctoproject.org 
From: Etienne Cordonnier 

poky kirkstone 4.0.12 updates gcc from 11.3 to 11.4, thus
the patches need to be rebased.

- The changes of 0001-libstdcxx-Rename-null-terminated-to-avoid-collision.patch
  are in 11.4 so it can be removed.
- upstream introduced DARWIN_MIN_LIB_VERSION instead of the hard-coded 10.4, so 
assign
  this variable the value 12.3
- use include path of gcc 11.4.0

Signed-off-by: Etienne Cordonnier 
---
 .../clang/0037-Fixes_for_Darwin_SDKs.patch|  4 +-
 ...e-null-terminated-to-avoid-collision.patch | 81 ---
 ...00-change-macosx-version-min-to-12.3.patch | 29 +++
 recipes-devtools/gcc/gcc-source_%.bbappend|  1 -
 4 files changed, 11 insertions(+), 104 deletions(-)
 delete mode 100644 
recipes-devtools/gcc/files/0001-libstdcxx-Rename-null-terminated-to-avoid-collision.patch

diff --git a/recipes-devtools/clang/clang/0037-Fixes_for_Darwin_SDKs.patch 
b/recipes-devtools/clang/clang/0037-Fixes_for_Darwin_SDKs.patch
index 024894b..c6db8d9 100644
--- a/recipes-devtools/clang/clang/0037-Fixes_for_Darwin_SDKs.patch
+++ b/recipes-devtools/clang/clang/0037-Fixes_for_Darwin_SDKs.patch
@@ -22,13 +22,13 @@ index f7da3f187814..0656f5cbad69 100644
 -"4.2.1",
 -"i686-apple-darwin10",
 -arch == llvm::Triple::x86_64 
? "x86_64" : "");
-+"11.3.0",
++"11.4.0",
 +"x86_64#SDK_VENDOR#-darwin21",
 +"");
IsBaseFound |= AddGnuCPlusPlusIncludePaths(DriverArgs, CC1Args, 
UsrIncludeCxx,
 -"4.0.0", "i686-apple-darwin8",
 - "");
-+"11.3.0", "", "");
++"11.4.0", "", "");
 +  {
 +  const char *S = ::getenv("YOCTO_SDKPATH");
 +  if (S && (S[0] != '\0')) {
diff --git 
a/recipes-devtools/gcc/files/0001-libstdcxx-Rename-null-terminated-to-avoid-collision.patch
 
b/recipes-devtools/gcc/files/0001-libstdcxx-Rename-null-terminated-to-avoid-collision.patch
deleted file mode 100644
index ff7b912..000
--- 
a/recipes-devtools/gcc/files/0001-libstdcxx-Rename-null-terminated-to-avoid-collision.patch
+++ /dev/null
@@ -1,81 +0,0 @@
-From d1201dbf55a11d391030914985ba6b443e59baa5 Mon Sep 17 00:00:00 2001
-From: Mark Mentovai 
-Date: Mon, 13 Jun 2022 16:40:19 +0100
-Subject: [PATCH] libstdc++: Rename __null_terminated to avoid collision with
- Apple SDK
-
-The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
-contain this definition in :
-
-863  #define __null_terminated
-
-This collides with the use of __null_terminated in libstdc++'s
-experimental fs_path.h.
-
-As libstdc++'s use of this token is entirely internal to fs_path.h, the
-simplest workaround, renaming it, is most appropriate. Here, it's
-renamed to __nul_terminated, referencing the NUL ('\0') value that is
-used to terminate the strings in the context in which this tag structure
-is used.
-
-libstdc++-v3/ChangeLog:
-
-   * include/experimental/bits/fs_path.h (__detail::__null_terminated):
-   Rename to __nul_terminated to avoid colliding with a macro in
-   Apple's SDK.
-
-Signed-off-by: Mark Mentovai 
-(cherry picked from commit 254e88b3d7e8abcc236be3451609834371cf4d5d)

- libstdc++-v3/include/experimental/bits/fs_path.h | 12 ++--
- 1 file changed, 6 insertions(+), 6 deletions(-)
-
-diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h 
b/libstdc++-v3/include/experimental/bits/fs_path.h
-index b0825ba76e803..19d246100cb5a 100644
 a/libstdc++-v3/include/experimental/bits/fs_path.h
-+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
-@@ -140,10 +140,10 @@ namespace __detail
- inline _Source
- _S_range_begin(_Source __begin) { return __begin; }
- 
--  struct __null_terminated { };
-+  struct __nul_terminated { };
- 
-   template
--inline __null_terminated
-+inline __nul_terminated
- _S_range_end(_Source) { return {}; }
- 
-   template
-@@ -459,11 +459,11 @@ namespace __detail
-   struct _Cvt;
- 
- static string_type
--_S_convert(value_type* __src, __detail::__null_terminated)
-+_S_convert(value_type* __src, __detail::__nul_terminated)
- { return string_type(__src); }
- 
- static string_type
--_S_convert(const value_type* __src, __detail::__null_terminated)
-+_S_convert(const value_type* __src, __detail::__nul_terminated)
- { return string_type(__src); }
- 
- template
-@@ -477,7 +477,7 @@ namespace __detail
- 
- template
-   static string_type
--  _S_convert(_InputIterator __src, __detail::__null_terminated)
-+  _S_convert(_InputIterator __src,

Re: [yocto] "Replicating a Build Offline" not working as expected when Git data is removed

2023-08-28 Thread Stephan M 
Am Mo., 28. Aug. 2023 um 10:25 Uhr schrieb Alexander Kanavin
:

> It's well possible no one knows the definite answer, and the best
> advice is what I said: don't touch the downloads at all. In any case,
> if the documentation is not accurate, patches to make it accurate
> would be appreciated.

I certainly do not know the answer, as I'm just a beginner with Yocto
and I try to follow the documentation to get things done.

It may be a bug in the documentation, but it may as well be a bug in
the implementation. It is certainly a desirable feature not having to
keep the Git and other SCM directories in the downloads directory and
to retain only the tarballs because of disk space. I assume that it
has worked in the past, otherwise it wouldn't be documented.

If it is a documentation bug, it would have further further
consequences. If it is not possible to rely on the tarballs only for
an offline build then the functionality to generate the tarballs via
the BB_GENERATE_MIRROR_TARBALLS variable is probably useless.

I filed a bug for this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15202

Stephan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60900): https://lists.yoctoproject.org/g/yocto/message/60900
Mute This Topic: https://lists.yoctoproject.org/mt/100952497/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] "Replicating a Build Offline" not working as expected when Git data is removed

2023-08-28 Thread Alexander Kanavin 
On Mon, 28 Aug 2023 at 08:16, Stephan Mühlstrasser
 wrote:
> > The documentation isn’t perfect. Sometimes it becomes outdated and no one 
> > notices, or it may be inaccurate to begin with. Personally I would never 
> > tamper with content of downloads and preserve it exactly as it is. Doesn’t 
> > have to be git lfs, plain artifact storage options work too.
>
> If it doesn't work as documented, could someone elaborate what is
> currently necessary to replicate a build offline? Is it possible to
> reproduce a build only with the tarballs or is it actually necessary
> to keep the cloned Git repositories in the download directory as well?

It's well possible no one knows the definite answer, and the best
advice is what I said: don't touch the downloads at all. In any case,
if the documentation is not accurate, patches to make it accurate
would be appreciated.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60899): https://lists.yoctoproject.org/g/yocto/message/60899
Mute This Topic: https://lists.yoctoproject.org/mt/100952497/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] "Replicating a Build Offline" not working as expected when Git data is removed

2023-08-28 Thread Stephan M 
Am Fr., 25. Aug. 2023 um 11:28 Uhr schrieb Alexander Kanavin
:
>
> The documentation isn’t perfect. Sometimes it becomes outdated and no one 
> notices, or it may be inaccurate to begin with. Personally I would never 
> tamper with content of downloads and preserve it exactly as it is. Doesn’t 
> have to be git lfs, plain artifact storage options work too.

If it doesn't work as documented, could someone elaborate what is
currently necessary to replicate a build offline? Is it possible to
reproduce a build only with the tarballs or is it actually necessary
to keep the cloned Git repositories in the download directory as well?

Thanks
Stephan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60898): https://lists.yoctoproject.org/g/yocto/message/60898
Mute This Topic: https://lists.yoctoproject.org/mt/100952497/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-