Date   

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


Variables qualifying for be placed in conf/local.conf

keydi <krzysztof.dudziak@...>
 

Hi,
From all variables which qualify to be set/modified in conf/local.conf, among others those documented
in conf/local.conf template, are any to be set /modified only in conf/local.conf?

There is one YP document (maybe Reference Manual, maybe some other) with one chapter
listing variables for conf/local.conf. For me it's however unclear if that list addresses question asked here too.
Me was not lucky to had got answer over there.

Regards
k.d.


Yocto Autobuilder: Latency Monitor and AB-INT -- Minutes from: Apr 29, 2021

Randy MacLeod
 

Attendees: Richard, Randy

To Do:
======

Data Collection: (Sakib)
------------------------

1. run iostat if it exists:
iostat -y -z -x 5 1
-y Omit first report with statistics since system boot, if
displaying multiple records at given interval.
-x Display extended statistics.
-z Tell iostat to omit output for any devices for which there
was no activity during the sample period.
5 1: monitor for 5 seconds, run 1 time.

2. use filenames that show what host, the data came from.
Currently we have:
- testresults/pkgman-deb-non-deb/2021-04-28--02-31/host_stats_0_top.txt
- testresults/beaglebone/2021-04-28--01-08/host_stats_2.txt

3. We add the tail of the cooker log but we need to know which
cooker log this softlink comes from so add that as a header
and to be paranoid as a trailer in case the softlink changes while
the collection is underway.

4. Collect the logs produced on error.

5. If the tail of the cooker logs isn't sufficient,
match the start/complete logs and report all tasks that
are not complete:


General topics
--------------

We talked about the job server for make-based recipes. Trevor is going
to look at that and if it goes well, perhaps also look at doing something similar for ninja (or samarai) builds.


Just as we can do co-operative load/compile management for make/ninja builds, we may have to co-ordinate I/O intensive activities.
RP mentioned that there's some task-based process limiting that
is done in the fetcher code. We suspect that the bottleneck is
around writes to sstate-cache and other write operations but we
need either proof from logging or to make a change and wait days
or weeks to see if the error rate has improved. The first option
is preferred.


Why is qemu start-up still slow?
Saul added code to use the Qemu Machine Protocol (QMP) so that
we can monitor/query Qemu. He had a bug where the process seemed
to have started because it's pid (file?) was available but the socket
for communicating with qemu was not yet bound. Adding a loop and some
short sleeps fixes the bug but it's odd that even with things running
from tmpfs, the start-up is slow.
- is there a logging flag or code for monitoring the start-up that we
can use?
- if not, can/should we patch qemu
- do we need to also copy the kernel that qemu is loading into tmpfs?

- Alex was (is?) going to instrument the initial copy into tmpfs
to record how log that takes from beginning to end and perhaps with
additional detail from the middle-end (compiler joke!).

It would be good if Saul can use QMP to help us understand what
is making qemuppc slow or hang on startup.


--
# Randy MacLeod
# Wind River Linux


Re: Hardknott: grub immediately reboots

Tony Battersby
 

On 4/28/21 11:25 PM, Mittal, Anuj wrote:

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of
Tony Battersby
Sent: Tuesday, April 27, 2021 03:07 AM
To: yocto@...
Subject: [yocto] Hardknott: grub immediately reboots

After upgrading from Dunfell (YP 3.1) to Hardknott (YP 3.3), our firmware was
unable to boot.  Our target hardware is x86-64 booting in legacy BIOS mode using
grub on a variety of motherboards and CPUs.  The grub menu would never show up;
instead it would reboot immediately, leading to an endless reboot loop.

I have two different workarounds.  Create a bbappend file for grub, and do one of the
following two things:

1) Add the following line:

CFLAGS_remove = "-O2"
I think we should probably remove this. That's what Fedora also seems to be doing so Os is used.

https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros#_19

and what grub configure expects:

https://git.savannah.gnu.org/cgit/grub.git/tree/configure.ac#n41

Thanks,

Anuj
I have opened a Yocto bug here:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14367

Tony


Re: Hardknott: grub immediately reboots

Anuj Mittal
 

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of
Tony Battersby
Sent: Tuesday, April 27, 2021 03:07 AM
To: yocto@...
Subject: [yocto] Hardknott: grub immediately reboots

After upgrading from Dunfell (YP 3.1) to Hardknott (YP 3.3), our firmware was
unable to boot.  Our target hardware is x86-64 booting in legacy BIOS mode using
grub on a variety of motherboards and CPUs.  The grub menu would never show up;
instead it would reboot immediately, leading to an endless reboot loop.

I have two different workarounds.  Create a bbappend file for grub, and do one of the
following two things:

1) Add the following line:

CFLAGS_remove = "-O2"
I think we should probably remove this. That's what Fedora also seems to be doing so Os is used.

https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros#_19

and what grub configure expects:

https://git.savannah.gnu.org/cgit/grub.git/tree/configure.ac#n41

Thanks,

Anuj


Re: #yocto opencl #yocto

Anuj Mittal
 

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of
Khem Raj
Sent: Thursday, April 29, 2021 10:07 AM
To: steven.monsees@...; yocto@...
Subject: Re: [yocto] #yocto opencl



On 4/28/21 10:30 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
Can someone tell me is this supported under Yocto in any way?

meta-beignet/recipes-opencl at ross * rossburton/meta-beignet * GitHub
<https://github.com/rossburton/meta-beignet/tree/ross/recipes-opencl>

Any docs, or updates ?

Wanted to know if this would work under Zeus, with meta-clang ?

Looking to build opencl shared library support...
meta-intel has it see
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/dynamic-layers/clang-
layer/recipes-opencl/opencl-clang?h=zeus
Yes, please see the compute-runtime recipe that builds NEO driver instead for later platforms. More details on the project site:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj


Re: #yocto opencl #yocto

Khem Raj
 

On 4/28/21 10:30 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Can someone tell me is this supported under Yocto in any way?
meta-beignet/recipes-opencl at ross · rossburton/meta-beignet · GitHub <https://github.com/rossburton/meta-beignet/tree/ross/recipes-opencl>
Any docs, or updates ?
Wanted to know if this would work under Zeus, with meta-clang ?
Looking to build opencl shared library support…
meta-intel has it see
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/dynamic-layers/clang-layer/recipes-opencl/opencl-clang?h=zeus

Thanks,
Steve


Re: [meta-security] [dunfell] [PATCH 0/3] Backport several IMA fixes to LTS dunfell

Armin Kuster
 

merged.

thanks

On 4/18/21 11:41 PM, liu.ming50@... wrote:
From: Ming Liu <ming.liu@...>

Ming Liu (3):
ima-evm-keys: add file-checksums to IMA_EVM_X509
meta: drop IMA_POLICY from policy recipes
initramfs-framework-ima: introduce IMA_FORCE

.../initrdscripts/initramfs-framework-ima.bb | 5 +++++
.../initrdscripts/initramfs-framework-ima/ima | 9 +++++++--
.../recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb | 1 +
.../ima-policy-appraise-all_1.0.bb | 9 ++-------
.../ima_policy_hashed/ima-policy-hashed_1.0.bb | 9 ++-------
.../ima_policy_simple/ima-policy-simple_1.0.bb | 9 ++-------
6 files changed, 19 insertions(+), 23 deletions(-)


Grub embedded config not useful

jbouchard@...
 

When I am looking at the grub embedded configuration I not fully sure I understand how this patch, https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c981ebba29001b8684e9805515576c2350a4e22b. In most case the search.file ($cmdpath) will only not find anything since cmdpath will contains something like this, (hd0,gpt1)/EFI/BOOT.

Thanks


#yocto opencl #yocto

Monsees, Steven C (US)
 

 

Can someone tell me is this supported under Yocto in any way?

 

meta-beignet/recipes-opencl at ross · rossburton/meta-beignet · GitHub

 

Any docs, or updates ?

 

Wanted to know if this would work under Zeus, with meta-clang ?

Looking to build opencl shared library support…

 

Thanks,

Steve


Re: [meta-mingw] [PATCH] mingw-w64: Check for __builtin_ia32_rdtsc

Khem Raj
 

ping^1

On Tue, Apr 13, 2021 at 7:01 PM Khem Raj <raj.khem@...> wrote:

Signed-off-by: Khem Raj <raj.khem@...>
---
...rincs-Check-for-__builtin_ia32_rdtsc.patch | 33 +++++++++++++++++++
.../nativesdk-mingw-w64-runtime_7.0.0.bb | 2 ++
2 files changed, 35 insertions(+)
create mode 100644 recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch

diff --git a/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch b/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch
new file mode 100644
index 0000000..ce4ba81
--- /dev/null
+++ b/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch
@@ -0,0 +1,33 @@
+From 346de7591f58015d111f4d4f3b001382c04d5557 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 13 Apr 2021 18:44:25 -0700
+Subject: [PATCH] intrincs: Check for __builtin_ia32_rdtsc
+
+on modern gcc ( >=4.6 ) __rdtsc function is implemented using
+special builtin function called __builtin_ia32_rdtsc, its actually
+a define in gcc, so __has_builtin check fails for __rdtsc even
+though it is defined to imply __builtin_ia32_rdtsc(), therefore
+check for existence of __builtin_ia32_rdtsc as well
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ mingw-w64-crt/intrincs/rdtsc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/rdtsc.c
+index bf9c03b..df04711 100644
+--- a/mingw-w64-crt/intrincs/rdtsc.c
++++ b/mingw-w64-crt/intrincs/rdtsc.c
+@@ -11,7 +11,7 @@
+ #define __has_builtin(x) 0
+ #endif
+
+-#if !__has_builtin(__rdtsc)
++#if !__has_builtin(__rdtsc) && !__has_builtin(__builtin_ia32_rdtsc)
+ unsigned __int64 __rdtsc(void)
+ {
+ #ifdef _WIN64
+--
+2.31.1
+
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
index 9f79ffe..0368841 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
@@ -2,6 +2,8 @@ DESCRIPTION = "Runtime libraries from MinGW-w64 project"

require mingw-w64.inc

+SRC_URI += "file://0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch;striplevel=2"
+
S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-crt"
B = "${WORKDIR}/build-${TARGET_SYS}"

--
2.31.1


[PATCH yocto-autobuilder2 2/2] meta-arm doesn't use meta-kernel anymore

Ross Burton <ross@...>
 

Signed-off-by: Ross Burton <ross.burton@...>
---
config.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/config.py b/config.py
index a723e3f..520de47 100644
--- a/config.py
+++ b/config.py
@@ -10,14 +10,14 @@ buildertorepos =3D {
"a-quick": ["poky", "meta-intel", "oecore", "bitbake",
"meta-mingw", "meta-gplv2"],
"a-full": ["poky", "meta-intel", "oecore", "bitbake",
- "meta-mingw", "meta-gplv2", "meta-arm", "meta-kernel"],
+ "meta-mingw", "meta-gplv2", "meta-arm"],
"non-gpl3": ["poky", "meta-gplv2"],
"meta-mingw": ["poky", "meta-mingw"],
"qa-extras": ["poky", "meta-mingw"],
"meta-oe": ["poky", "meta-openembedded"],
"meta-virt": ["poky", "meta-openembedded", "meta-virtualization"],
"meta-intel": ["poky", "meta-intel"],
- "meta-arm": ["poky", "meta-arm", "meta-kernel"],
+ "meta-arm": ["poky", "meta-arm"],
"meta-agl-core": ["poky", "meta-agl"],
"meta-aws": ["poky", "meta-aws", "meta-openembedded"],
"qemuarm-oecore": ["oecore", "bitbake"],
@@ -54,7 +54,6 @@ repos =3D {
"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"],
"meta-openembedded": ["git://git.openembedded.org/meta-openembedded"=
, "master"],
"meta-virtualization": ["git://git.yoctoproject.org/meta-virtualizat=
ion", "master"],
- "meta-kernel": ["https://gitlab.com/openembedded/community/meta-kern=
el.git", "master"],
"yocto-docs": ["git://git.yoctoproject.org/yocto-docs", "master"]
}
=20
--=20
2.25.1


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

Ross Burton <ross@...>
 

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',
'branch_meta-gplv2': 'hardknott',
'branch_meta-intel': 'hardknott',
'branch_meta-mingw': 'hardknott',
--=20
2.25.1


Re: Bitbake build failures?

Ross Burton <ross@...>
 

Because your networking is broken in some way and you cannot fetch
from downloads.yoctoproject.org.

Outside of bitbake, try:

wget http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz

Ross

On Tue, 27 Apr 2021 at 23:01, jchludzinski via lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:

When I trying using bitbake to build openembedded Linux kernel, it dies with these download failures:

NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b (will check PREMIRRORS first)
WARNING: Failed to fetch URL http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/jski/poky/scripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/bin:/home/jski/poky/bitbake/bin:/home/jski/poky/build/tmp/hosttools"; export HOME="/home/jski"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jski/poky/build/downloads/uninative/5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz' --progress=dot -v failed with exit code 4, output:
--2021-04-27 01:49:09-- http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... failed: Connection timed out.
wget: unable to resolve host address ‘downloads.yoctoproject.org’

WARNING: Disabling uninative as unable to fetch uninative tarball: Fetcher failure for URL: 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b'. Unable to fetch URL from any source.
WARNING: To build your own uninative loader, please bitbake uninative-tarball and set UNINATIVE_TARBALL appropriately.

Why do I ALWAYS get these download failures?



5341 - 5360 of 58636