Date   

[meta-selinux] MAINTAINERS: Remove myself.

flihp@...
 

I have been inactive for an extended period.

Signed-off-by: Philip Tricca <flihp@...>
---
MAINTAINERS | 5 -----
1 file changed, 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36c451f..3166b32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24,11 +24,6 @@ F: conf
F: classes
F: recipes-*
=20
-M: Philip Tricca <flihp@...>
-F: conf
-F: classes
-F: recipes-*
-
COMMON
M: Yi Zhao <yi.zhao@...>
F: conf
--=20
2.20.1


Observed issue regarding hostapd

rohit jadhav
 

Hi
can you please help out with following issue
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.

Thanks and regards
rohit


#yocto cmake configurations #yocto

Monsees, Steven C (US)
 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve


[meta-raspberrypi] Booting a Raspberry Pi 4 using PXE

Manuel Wagesreither
 

Hello all!

Since a certain eeprom version, the Raspberry Pi 4 can directly boot from network. Has anyone experience on this?

I already managed to to have the Raspi to load the kernel and all the device tree stuff over network. I then exported `build/tmp/work/raspberrypi4_64-poky-linux/bora-image/1.0-r0/rootfs/` as via nfs and changed the linux kernel commandline so it would use this share as nfsroot. At boot many failing services get reported and and the boot progress stops somewhere along the way. It tells me the system is in emergency mode and asks me for the root password for maintenance. I have an empty root password. When I press Control-D to continue, the same prompt reappears. Same when I simply press enter.

Has onyone any input for me? I guess I'll need to monitor what gets written to the serial port.

Regards,
Manuel


[meta-mingw] [PATCH 2/2] nativesdk-mingw-w64-winpthreads: Implement __udivmoddi4

Khem Raj
 

Fixes build with gcc 11+

Signed-off-by: Khem Raj <raj.khem@...>
---
.../0001-winpthreads-Add-__udivmoddi4.patch | 52 +++++++++++++++++++
.../nativesdk-mingw-w64-winpthreads_8.0.0.bb | 2 +
2 files changed, 54 insertions(+)
create mode 100644 recipes-devtools/mingw-w64/files/0001-winpthreads-Add-__udivmoddi4.patch

diff --git a/recipes-devtools/mingw-w64/files/0001-winpthreads-Add-__udivmoddi4.patch b/recipes-devtools/mingw-w64/files/0001-winpthreads-Add-__udivmoddi4.patch
new file mode 100644
index 0000000..3eb298e
--- /dev/null
+++ b/recipes-devtools/mingw-w64/files/0001-winpthreads-Add-__udivmoddi4.patch
@@ -0,0 +1,52 @@
+From 3b0af7327446ae179dc93b6a6ab1074251d348d0 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Fri, 30 Apr 2021 16:50:36 -0700
+Subject: [PATCH] winpthreads: Add __udivmoddi4
+
+Newer GCC ( 11.1.0+ ) is generating calls to __udivmoddi4 on i686
+architecture, therefore provide an implementation to avoid undefined
+references
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ .../winpthreads/src/libgcc/dll_math.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c b/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
+index aeec068..d170967 100644
+--- a/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
++++ b/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
+@@ -121,6 +121,7 @@ u_quad_t __udivdi3(u_quad_t a, u_quad_t b);
+ u_quad_t __umoddi3(u_quad_t a, u_quad_t b);
+ int __ucmpdi2(u_quad_t a, u_quad_t b);
+ quad_t __divmoddi4(quad_t a, quad_t b, quad_t *rem);
++u_quad_t __udivmoddi4(u_quad_t a, u_quad_t b, u_quad_t *rem);
+
+ #endif /* !_LIBKERN_QUAD_H_ */
+
+@@ -573,7 +574,20 @@ __divmoddi4(a, b, rem)
+ return (negq ? -uq : uq);
+ }
+
++/*
++ * Divide two unsigned quads.
++ * This function is new in GCC 7.
++ */
++u_quad_t
++__udivmoddi4(a, b, rem)
++ u_quad_t a, b, *rem;
++{
++ u_quad_t q = __udivdi3(a, b);
++ if (rem)
++ *rem = a - b * q;
++ return q;
++}
++
+ #else
+ static int __attribute__((unused)) dummy;
+ #endif /*deined (_X86_) && !defined (__x86_64__)*/
+-
+--
+2.31.1
+
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb
index e694e5b..814268d 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb
@@ -2,6 +2,8 @@ DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"

require mingw-w64.inc

+SRC_URI += "file://0001-winpthreads-Add-__udivmoddi4.patch;striplevel=3"
+
S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-libraries/winpthreads"
B = "${WORKDIR}/build-${TARGET_SYS}"

--
2.31.1


[meta-mingw] [PATCH 1/2] mingw-w64-runtime,mingw-w64-winpthreads: Upgrade to 8.0.0

Khem Raj
 

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-devtools/mingw-w64/mingw-w64.inc | 2 +-
...64-headers_7.0.0.bb => nativesdk-mingw-w64-headers_8.0.0.bb} | 0
...64-runtime_7.0.0.bb => nativesdk-mingw-w64-runtime_8.0.0.bb} | 0
...hreads_7.0.0.bb => nativesdk-mingw-w64-winpthreads_8.0.0.bb} | 0
4 files changed, 1 insertion(+), 1 deletion(-)
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-headers_7.0.0.bb => nativesdk-mingw-w64-headers_8.0.0.bb} (100%)
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-runtime_7.0.0.bb => nativesdk-mingw-w64-runtime_8.0.0.bb} (100%)
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-winpthreads_7.0.0.bb => nativesdk-mingw-w64-winpthreads_8.0.0.bb} (100%)

diff --git a/recipes-devtools/mingw-w64/mingw-w64.inc b/recipes-devtools/mingw-w64/mingw-w64.inc
index a435dea..d40d4a5 100644
--- a/recipes-devtools/mingw-w64/mingw-w64.inc
+++ b/recipes-devtools/mingw-w64/mingw-w64.inc
@@ -5,7 +5,7 @@ COMPATIBLE_HOST = ".*-mingw.*"

SRC_URI = "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"

-SRC_URI[sha256sum] = "aa20dfff3596f08a7f427aab74315a6cb80c2b086b4a107ed35af02f9496b628"
+SRC_URI[sha256sum] = "44c740ea6ab3924bc3aa169bad11ad3c5766c5c8459e3126d44eabb8735a5762"

UPSTREAM_CHECK_URI = "http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/"
UPSTREAM_CHECK_REGEX = "mingw-w64-v(?P<pver>(\d+[\.\-_]*)+)\.tar"
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_8.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_8.0.0.bb
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_8.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_8.0.0.bb
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_8.0.0.bb
--
2.31.1


devtool modify fails

Kent Dorfman <kent.dorfman766@...>
 

To my way of thinking, a

$ devtool modify linux

should NEVER fail if it is preceded by

$ bitbake -c do_cleanall linux

The intended staging of the kernel into the workspace fails, saying
that it cannot find miscellaneous and adhoc .scc files that no longer
exist after several variants of kernel config modifications.

fails on do_kernel_metadata...

| ERROR. input file "cfg/xilinx_intc.scc" does not exist

How to fix???


Re: any compelling reason to use SDK rather than eSDK?

Quentin Schulz
 

Hi,

On Fri, Apr 30, 2021 at 05:49:29AM -0400, Robert P. J. Day wrote:

colleague wants to get into working with SDKs, and as i'm just
diving into the intricacies of that myself, i'm not sure how to
answser the question: "is there any reason to use the regular SDK as
opposed to the extensible SDK?"

superficially, it would seem that the eSDK has nothing but benefits,
It's very big and probably include your proprietary SW header and
libraries at the very least... or third party prebuilt
binaries/libraries you're not supposed to share outside of your product.

This is useful if you're doing active development internally and you
don't upgrade your Yocto layers too often. This means non-Yocto verse
people could work on the main SW stack without caring about Yocto at
all.

so other than perhaps needing more resources, is there any reason to
use the regular SDK and forego the benefits of eSDK?
Normal SDK is just a toolchain, very practical if a third party vendor
requires you to send them something so they can build a blob that works
on your machine. And usually, you don't want to send anything that is
remotely critical to your business, IP wise.

I have barely used SDK, so to be taken with a grain of salt as usual.

Cheers,
Quentin


[meta-gplv2][PATCH] gnutls: add possibility to build with cryptodev support

Federico Pellegrin
 

Add possibility, via PACKAGECONFIG variable, to enable cryptodev
(hardware crypto acceleration) for gnutls in a very similar way
as it is already present for openssl.

Signed-off-by: Federico Pellegrin <fede@...>
---
meta/recipes-support/gnutls/gnutls_3.7.1.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/gnutls/gnutls_3.7.1.bb b/meta/recipes-support/gnutls/gnutls_3.7.1.bb
index 350d0a018bd..6674542a77d 100644
--- a/meta/recipes-support/gnutls/gnutls_3.7.1.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.7.1.bb
@@ -36,6 +36,7 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
PACKAGECONFIG[libtasn1] = "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
+PACKAGECONFIG[cryptodev-linux] = "--enable-cryptodev,,cryptodev-linux,cryptodev-module"

EXTRA_OECONF = " \
--enable-doc \
--
2.26.3


Re: [PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now

Ross Burton <ross@...>
 

On Thu, 29 Apr 2021 at 22:40, akuster808 <akuster808@...> wrote:
When we actually release, yes.
So do you plan on doing the dot releases too?
The plan is that today-ish we roll the 3.3 release for hardknott and
also tag point releases on the stable branches too.

Ross


any compelling reason to use SDK rather than eSDK?

Robert P. J. Day
 

colleague wants to get into working with SDKs, and as i'm just
diving into the intricacies of that myself, i'm not sure how to
answser the question: "is there any reason to use the regular SDK as
opposed to the extensible SDK?"

superficially, it would seem that the eSDK has nothing but benefits,
so other than perhaps needing more resources, is there any reason to
use the regular SDK and forego the benefits of eSDK?

rday


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Khem Raj
 

On Thu, Apr 29, 2021 at 3:32 PM Martin Jansa <martin.jansa@...> wrote:

On Thu, Apr 29, 2021 at 06:05:30PM -0400, Randy MacLeod wrote:
Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch, So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.
That could open up a can of worms as who will fix the QA test failures?
Hi Armin,

The community will fix bugs on HEAD just like before.
It's a tag indicating where the branch was at GA time.
There's no obligation for he maintainer do do anything in addition
to what they were doing if we didn't have a tag.

I guess that could be made clear in the README if needed.
To be honest I don't see much value of these tags for layers not
included in the QA testing with oe-core release.

I believe we agreed on promoting latest revisions in the branches for
selected release.

And I think the process for stable branches works reasonably well in the
layers I usually use and only very rarely new regression is introduced
in stable branch so from my experience the latest revision is always better
than GA tag (or any tag for various point releases).

Why should anyone use yocto-3.3 tag of meta-oe if the harknott branch
has few more fixes and tip of hardknott branch was tested exactly the
same as the yocto-3.3 tag?

TLDR: Why should some low traffic layer have these tags which might point to
exactly the same commit for multiple release (when all of them
still parse, build and work correctly). Many layers don't feel the need
to create a separate branch for each release when the same master works
fine for last 3 Yocto releases. And I feel the pain when e.g. with
meta-ros the last 4 branches (dunfell, gatesgarth, hardknott, master)
are 99% identical, so whatever ROS update I merge to one of them gets
distributed across all of them and only rarely with some small
modification added only in some of them. Adding a yocto-3.3 tag there
won't make that commit any better than a tip of hardknott and it might
be actually a lot worse than tip of hardknott.
I think its perhaps also that distros have mechanisms to lock layers at a given
revision whatever tooling they use ( git submod, android repo,
combotools something else)
so distro manifest at that point acts as pseudo tag and seems better
downstream way
to create a uniform tested view of that distro. Something similar is
needed for poky distro perhaps a layer manifest
which tells about revisions of tested layers with poky version X if we
desire to have more layers tested along with what it supports as of
now.
oe-core supports nodistro and its self-sufficient.


Regards,


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Martin Jansa
 

On Thu, Apr 29, 2021 at 06:05:30PM -0400, Randy MacLeod wrote:
Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch, So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.
That could open up a can of worms as who will fix the QA test failures?
Hi Armin,

The community will fix bugs on HEAD just like before.
It's a tag indicating where the branch was at GA time.
There's no obligation for he maintainer do do anything in addition
to what they were doing if we didn't have a tag.

I guess that could be made clear in the README if needed.
To be honest I don't see much value of these tags for layers not
included in the QA testing with oe-core release.

I believe we agreed on promoting latest revisions in the branches for
selected release.

And I think the process for stable branches works reasonably well in the
layers I usually use and only very rarely new regression is introduced
in stable branch so from my experience the latest revision is always better
than GA tag (or any tag for various point releases).

Why should anyone use yocto-3.3 tag of meta-oe if the harknott branch
has few more fixes and tip of hardknott branch was tested exactly the
same as the yocto-3.3 tag?

TLDR: Why should some low traffic layer have these tags which might point to
exactly the same commit for multiple release (when all of them
still parse, build and work correctly). Many layers don't feel the need
to create a separate branch for each release when the same master works
fine for last 3 Yocto releases. And I feel the pain when e.g. with
meta-ros the last 4 branches (dunfell, gatesgarth, hardknott, master)
are 99% identical, so whatever ROS update I merge to one of them gets
distributed across all of them and only rarely with some small
modification added only in some of them. Adding a yocto-3.3 tag there
won't make that commit any better than a tip of hardknott and it might
be actually a lot worse than tip of hardknott.

Regards,


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Armin Kuster
 

On 4/29/21 12:37 PM, Randy MacLeod wrote:
On 2021-04-27 1:06 p.m., Khem Raj wrote:
On Tue, Apr 27, 2021 at 9:48 AM Randy MacLeod
<randy.macleod@...> wrote:
Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch,  So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.

How about:

https://git.openembedded.org/meta-openembedded/commit/?id=71b546ed8595b14d29efc1e8b951f8c845ad10c4
The implication here is that the Yocto Project has run QA if this is in
response to Khem's statement above, Or am I miss interpreting your
recommendation?


Now regarding meta-security, I would not use a "yocto" named tag.   I am
not  a fan of an upstream Project telling me to use their tagging
scheme. If I do that, then I need to be open to WindRriver, MontaVista,
Petalinux, Mentor, Enea, Arm and  etc tags.  Those Companies send me
patches.  Does RedHat tell the kernel.org to use their tags? No, its the
other way around.

If I would tag meta-security, I would have to write up the meaning of it
and possible a policy/process around it so if a new maintainer came
along they could  continue that process or do something else. This is a
hard sell as I am not seeing the benefit to this layer in adopting a
tagging scheme.

- Armin


../Randy


Are there any concerns about attempting to do this for yocto-3.3
and later?

Should we make it a requirement for yocto compliance?
Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Randy MacLeod
 

On 2021-04-29 5:22 p.m., akuster808 wrote:
On 4/27/21 10:06 AM, Khem Raj wrote:
On Tue, Apr 27, 2021 at 9:48 AM Randy MacLeod
<randy.macleod@...> wrote:
Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch, So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.
That could open up a can of worms as who will fix the QA test failures?
Hi Armin,

The community will fix bugs on HEAD just like before.
It's a tag indicating where the branch was at GA time.
There's no obligation for he maintainer do do anything in addition
to what they were doing if we didn't have a tag.

I guess that could be made clear in the README if needed.

../Randy

-armin


Are there any concerns about attempting to do this for yocto-3.3
and later?

Should we make it a requirement for yocto compliance?
Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Re: [PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now

Armin Kuster
 

On 4/29/21 2:25 PM, Ross Burton wrote:
On Thu, 29 Apr 2021 at 20:35, Randy MacLeod <randy.macleod@...> wrote:
It doesn't have a yocto-3.3 tag yet...
Could you add one?
When we actually release, yes.
So do you plan on doing the dot releases too?

-armin
Ross



Re: [PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now

Ross Burton <ross@...>
 

On Thu, 29 Apr 2021 at 20:35, Randy MacLeod <randy.macleod@...> wrote:
It doesn't have a yocto-3.3 tag yet...
Could you add one?
When we actually release, yes.

Ross


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Armin Kuster
 

On 4/27/21 10:06 AM, Khem Raj wrote:
On Tue, Apr 27, 2021 at 9:48 AM Randy MacLeod
<randy.macleod@...> wrote:
Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch, So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.
That could open up a can of worms as who will fix the QA test failures?

-armin



Are there any concerns about attempting to do this for yocto-3.3
and later?

Should we make it a requirement for yocto compliance?
Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux


Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Randy MacLeod
 

On 2021-04-27 1:06 p.m., Khem Raj wrote:
On Tue, Apr 27, 2021 at 9:48 AM Randy MacLeod
<randy.macleod@...> wrote:
Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
I think this could be a good thing, although it does put the burden on
release maintainers. mostly they
test against the tip of the release branch, So if yocto project
testing is including these layers for wider
testing and can then recommend a validated commit then perhaps this
could be made viable.

How about:

https://git.openembedded.org/meta-openembedded/commit/?id=71b546ed8595b14d29efc1e8b951f8c845ad10c4

../Randy


Are there any concerns about attempting to do this for yocto-3.3
and later?

Should we make it a requirement for yocto compliance?
Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Re: [PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now

Randy MacLeod
 

On 2021-04-28 11:09 a.m., Ross Burton wrote:
Signed-off-by: Ross Burton <ross.burton@...>
---
schedulers.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/schedulers.py b/schedulers.py
index 8b166e0..93b8f34 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -206,7 +206,7 @@ def parent_scheduler(target):
'branch': 'hardknott',
'branch_poky': 'hardknott',
'branch_bitbake': '1.50',
- 'branch_meta-arm': 'master',
+ 'branch_meta-arm': 'hardknott',
It doesn't have a yocto-3.3 tag yet...
Could you add one?

../Randy

'branch_meta-gplv2': 'hardknott',
'branch_meta-intel': 'hardknott',
'branch_meta-mingw': 'hardknott',

--
# Randy MacLeod
# Wind River Linux

4481 - 4500 of 57789