Date   

Re: ERROR: could not relocate installing toolchain SDK

Sundeep KOKKONDA
 

Hello,

I am also facing the same issue with path size. Can you share the workaround what you are using for this issue?

In the scripts/relocate_sdk.py the file name comparison is like below:
if (len(new_dl_path) >= p_filesz):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (p_filesz - len(new_dl_path))
And, to fix the issue I made changes like below.
if (len(new_dl_path) >= 4096):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (4096 - len(new_dl_path))
and commented below code.
#if old_size != os.path.getsize(e):
        #print("New file size for %s is different. Looks like a relocation error!", e)
        #sys.exit(-1)
Do you have any clue regarding,
- Why the installation path is depending of elf headers i.e., Why installation error when the len(new_dl_path) is greater than p_filesz?
- Changing this comparison (len(new_dl_path) >= 4096) will impact the installed SDK?
 


Re: is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

Quoting Leon Woestenberg <leon@sidebranch.com>:

Hello Robert, Alexander,

On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day <rpjday@crashcourse.ca> wrote:


Quoting Alexander Kanavin <alex.kanavin@gmail.com>:

I think the best option at this point is qemu. Why does the 'friend' need
physical hardware? :)
he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.
No. There is a sweet middle ground called FPGAs. You buy a board, with an
IC on it, that is expensive as hell, empty like air, but fully
re-configurable with almost any RISC-V SoC you can think of.

For example the Rocket 64 bit RISC-V.
hmmm ... not even that expensive a board:

https://www.luffca.com/2021/09/linux-litex-rocket-arty/
https://www.xilinx.com/products/boards-and-kits/1-elhaap.html

rday


Re: is there a viable YP-friendly risc-v dev kit?

Leon Woestenberg
 

Hello Robert, Alexander,

On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day <rpjday@...> wrote:

Quoting Alexander Kanavin <alex.kanavin@...>:

> I think the best option at this point is qemu. Why does the 'friend' need
> physical hardware? :)

   he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.

No. There is a sweet middle ground called FPGAs. You buy a board, with an IC on it, that is expensive as hell, empty like air, but fully re-configurable with almost any RISC-V SoC you can think of.

For example the Rocket 64 bit RISC-V.

Regards, Leon

rday




--
-- 
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com


Re: is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

Quoting Alexander Kanavin <alex.kanavin@gmail.com>:

I think the best option at this point is qemu. Why does the 'friend' need
physical hardware? :)
he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.

rday


Re: is there a viable YP-friendly risc-v dev kit?

Alexander Kanavin
 

I think the best option at this point is qemu. Why does the 'friend' need physical hardware? :)

Alex


On Fri, 4 Feb 2022 at 22:48, Robert P. J. Day <rpjday@...> wrote:
friend asked me about the options for a risc-v dev kit that worked
with YP, and i'm aware of the meta-riscv layer, but wherever i looked,
it seems like risc-v dev kits have a very short life span, being either
put on hold or outright cancelled (beaglev, hifive unmatched, etc.)

are there, in fact, any reasonable risc-v dev boards out there?

rday





is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

friend asked me about the options for a risc-v dev kit that worked
with YP, and i'm aware of the meta-riscv layer, but wherever i looked,
it seems like risc-v dev kits have a very short life span, being either
put on hold or outright cancelled (beaglev, hifive unmatched, etc.)

are there, in fact, any reasonable risc-v dev boards out there?

rday


[meta-security][PATCH] suricata: update to 6.0.4

Armin Kuster
 

bump lexical-core to 0.6.8

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-ids/suricata/{libhtp_0.5.38.bb => libhtp_0.5.39.bb} | 2 +-
recipes-ids/suricata/{suricata_6.0.3.bb => suricata_6.0.4.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-ids/suricata/{libhtp_0.5.38.bb => libhtp_0.5.39.bb} (91%)
rename recipes-ids/suricata/{suricata_6.0.3.bb => suricata_6.0.4.bb} (98%)

diff --git a/recipes-ids/suricata/libhtp_0.5.38.bb b/recipes-ids/suricata/libhtp_0.5.39.bb
similarity index 91%
rename from recipes-ids/suricata/libhtp_0.5.38.bb
rename to recipes-ids/suricata/libhtp_0.5.39.bb
index 2a0c93c..80c9014 100644
--- a/recipes-ids/suricata/libhtp_0.5.38.bb
+++ b/recipes-ids/suricata/libhtp_0.5.39.bb
@@ -5,7 +5,7 @@ require suricata.inc
LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=596ab7963a1a0e5198e5a1c4aa621843"

SRC_URI = "git://github.com/OISF/libhtp.git;protocol=https;branch=0.5.x"
-SRCREV = "fca44158911a1642880ea5c774151a33ad33d906"
+SRCREV = "6b70803c45894da7a591b2305498335e6df4f9a3"

DEPENDS = "zlib"

diff --git a/recipes-ids/suricata/suricata_6.0.3.bb b/recipes-ids/suricata/suricata_6.0.4.bb
similarity index 98%
rename from recipes-ids/suricata/suricata_6.0.3.bb
rename to recipes-ids/suricata/suricata_6.0.4.bb
index ca9e03e..31244f3 100644
--- a/recipes-ids/suricata/suricata_6.0.3.bb
+++ b/recipes-ids/suricata/suricata_6.0.4.bb
@@ -5,7 +5,7 @@ require suricata.inc
LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=c70d8d3310941dcdfcd1e02800a1f548"

SRC_URI = "http://www.openinfosecfoundation.org/download/suricata-${PV}.tar.gz"
-SRC_URI[sha256sum] = "daf134bb2d7c980035e9ae60f7aaf313323a809340009f26e48110ccde81f602"
+SRC_URI[sha256sum] = "a8f197e33d1678689ebbf7bc1abe84934c465d22c504c47c2c7e9b74aa042d0d"

DEPENDS = "lz4 libhtp"

@@ -58,7 +58,7 @@ SRC_URI += " \
crate://crates.io/crc/1.8.1 \
crate://crates.io/rustc_version/0.2.3 \
crate://crates.io/phf/0.8.0 \
- crate://crates.io/lexical-core/0.6.7 \
+ crate://crates.io/lexical-core/0.6.8 \
crate://crates.io/time/0.1.44 \
crate://crates.io/quote/0.6.13 \
crate://crates.io/rand_core/0.5.1 \
--
2.25.1


Isafw.bbclass needs to sync up with

Darcy Watkins
 

Hi team,

 

I get this error…

 

ERROR: Task do_build in /home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-core/images/core-image-minimal.bb depends upon non-existent task do_populate_cve_db in /home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-core/meta/cve-update-db-native.bb

ERROR: Command execution failed: 1

 

This commit below is reference from ‘dunfell’ branch but I see the same issue in ‘master’ branch so I think it was back ported.

 

commit ee62d4540e6a2ad5d071209b7bef26b367719b42

Author: Ross Burton <ross@...>

Date:   Thu Sep 10 22:04:13 2020 +0100

 

    cve-update-db-native: use fetch task

    

    Instead of inventing a new task to fetch the CVE data, use the existing

    fetch task.

    

    (From OE-Core rev: 1ed53d5cfc2be40b2d57b5392ec4d30313209934)

    

    Signed-off-by: Ross Burton <ross.burton@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

    (cherry picked from commit f5f97d33a1703d75b9fd9760f2c7767081538e00)

    Signed-off-by: Steve Sakoman <steve@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

 

Below is from isafw.bbclass (approx. line #108 in ‘dunfell’) in meta-security

 

do_build[depends] += "cve-update-db-native:do_populate_cve_db ca-certificates-native:do_populate_sysroot"

 

I think it needs to be …

 

do_build[depends] += "cve-update-db-native:do_fetch ca-certificates-native:do_populate_sysroot"

 

I think this is as widespread in terms of backported branches, etc. as the original change went.  I am guessing that this doesn’t impact users that are NOT using the meta-security layer.

 

I have to admit I was a bit surprised by this, but on the other hand, it’s nice went I can suggest the fix rather than just belly ache over the issue.  😉

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Enrico Scholz
 

Alexander Kanavin <alex.kanavin@gmail.com> writes:

Would CANCEL be clearer to you than HALT?
mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.
Cancel is the same as abort: a request to immediately stop the operation
(or not even start it) without reaching the originally requested
outcome.
https://english.stackexchange.com/questions/535153/what-is-the-difference-between-cancel-and-abort

| Cancel implies the action is rescinded before it implements...
|
| Abort is an emergency procedure to interrupt...


Halt implies the operation is not going to continue
Really?

https://translate.google.com/?sl=en&tl=de&text=halt&op=translate says

| a suspension of movement or activity, typically a temporary one.

Examples in

https://dictionary.cambridge.org/de/worterbuch/englisch/halt

sound like there is a chance to continue after the "halt" (show the
permit, resolve the pay dispute).


When we want to continue this inclusion BS, then "halt" seems to be
offending to some people because it can mean

| ... having a physical disability.



Enrico


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Alexander Kanavin
 

On Fri, 4 Feb 2022 at 19:39, Enrico Scholz <enrico.scholz@...> wrote:
> Would CANCEL be clearer to you than HALT?

mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.

Cancel is the same as abort: a request to immediately stop the operation (or not even start it) without reaching the originally requested outcome.

Halt implies the operation is not going to continue (Alan Turing was as English as it gets, just to remind you).

I don't think any of this is remotely confusing.

Alex


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Enrico Scholz
 

Bryan Evenson <bevenson@melinkcorp.com> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN"
would become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
Would CANCEL be clearer to you than HALT?
mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.

I do not know how this can be described without using "abort" or some
extensively long terms.


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more
sense to you?
yes; it is much better. But should it be an "IGNORELIST" or an
"IGNORE*D*LIST"?



Enrico
[who is irritated how people and especially developer can waste their
(and other developers) time in trying to change something which was
completely fine before]


Re: wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Khem Raj
 

On Thu, Feb 3, 2022 at 11:20 PM Matthias Klein
<matthias.klein@optimeas.de> wrote:

Hello Khem,

this means you are choosing openSSL to provide TLS protocol implementation instead of gnuTLS
Please excuse that my question was so unspecific.
Does it make a functional difference from which library the TLS support comes from?
ideally it should not. It really should be that app is using right
port to talk to the one you choose.

Best regards,
Matthias


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Bryan Evenson
 

Enrico,

-----Original Message-----
From: openembedded-core@lists.openembedded.org <openembedded-
core@lists.openembedded.org> On Behalf Of Enrico Scholz via
lists.openembedded.org
Sent: Friday, February 4, 2022 9:16 AM
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Jon Mason <jdmason@kudzu.us>; Yocto-mailing-list
<yocto@lists.yoctoproject.org>; Patches and discussions about the oe-core
layer <openembedded-core@lists.openembedded.org>; OpenEmbedded
Devel List <openembedded-devel@lists.openembedded.org>
Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Alexander Kanavin <alex.kanavin@gmail.com> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN"
would
become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
I'm not taking a stand here, but just providing the context for where
the push for avoidance of 'abort' comes from:
https://inclusivenaming.org/word-lists/tier-1/

Keep in mind that for non-native english speakers none of these words
are emotionally charged; they're just terms.
Yes; these are terms. But it should be possible to understand the meaning of
these terms without using a special "inclusivenaming"
dictionary. Else, we could just use "A", "B" and "C" for the actions above and
explain these "terms" in some documentation later.
Would CANCEL be clearer to you than HALT?


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST ->
BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
I'd say the context should make it clear that they are lists
It is bad when a context is required to understand the meaning of a variable.

And where do you see a context when local.conf contains

| BB_HASHCONFIG_IGNORE_VARS = "true"
Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more sense to you?

Bryan



Enrico


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Enrico Scholz
 

Alexander Kanavin <alex.kanavin@gmail.com> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
I'm not taking a stand here, but just providing the context for where
the push for avoidance of 'abort' comes from:
https://inclusivenaming.org/word-lists/tier-1/

Keep in mind that for non-native english speakers none of these words
are emotionally charged; they're just terms.
Yes; these are terms. But it should be possible to understand the
meaning of these terms without using a special "inclusivenaming"
dictionary. Else, we could just use "A", "B" and "C" for the actions
above and explain these "terms" in some documentation later.


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
I'd say the context should make it clear that they are lists
It is bad when a context is required to understand the meaning of a
variable.

And where do you see a context when local.conf contains

| BB_HASHCONFIG_IGNORE_VARS = "true"



Enrico


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Alexander Kanavin
 

On Fri, 4 Feb 2022 at 14:21, Enrico Scholz via lists.openembedded.org <enrico.scholz=sigma-chemnitz.de@...> wrote:
"Jon Mason" <jdmason@...> writes:

> For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
> become "HALT, NO_NEW_TASKS and "WARN".

I am not an native english speaker, but for "HALT" I will have to think
twice whether it will pause the operation or abort it.  I would stay at
"ABORT" because it makes much more clear what happens.

I'm not taking a stand here, but just providing the context for where the push for avoidance of 'abort' comes from:

Keep in mind that for non-native english speakers none of these words are emotionally charged; they're just terms. Not so for native speakers.
 
> BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
> BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
> BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
> MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED

The new variable names sound like boolean flags, not like lists.

I'd say the context should make it clear that they are lists (e.g. either the initialization, or usage via iteration).

Alex


Re: [OE-core] Inclusive Language Proposal for YP/OE

Enrico Scholz
 

"Jon Mason" <jdmason@kudzu.us> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to think
twice whether it will pause the operation or abort it. I would stay at
"ABORT" because it makes much more clear what happens.


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.


SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
ditto; sounds like flags but not like lists


Enrico


[meta-lts-mixins][dunfell/go PATCH 2/2] go-1.16: update 1.16.10 -> 1.16.13

Alexander Kanavin
 

Remove unneeded go-binary-native recipe, as the 1.17 version of it
is used to bootstrap go instead.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
.../{go-1.16.10.inc => go-1.16.13.inc} | 6 +--
.../go-1.16/go-binary-native_1.16.10.bb | 46 -------------------
....16.10.bb => go-cross-canadian_1.16.13.bb} | 0
...o-cross_1.16.10.bb => go-cross_1.16.13.bb} | 0
...ssdk_1.16.10.bb => go-crosssdk_1.16.13.bb} | 0
...native_1.16.10.bb => go-native_1.16.13.bb} | 0
...ntime_1.16.10.bb => go-runtime_1.16.13.bb} | 0
.../go-1.16/{go_1.16.10.bb => go_1.16.13.bb} | 0
8 files changed, 2 insertions(+), 50 deletions(-)
rename recipes-devtools/go-1.16/{go-1.16.10.inc => go-1.16.13.inc} (82%)
delete mode 100644 recipes-devtools/go-1.16/go-binary-native_1.16.10.bb
rename recipes-devtools/go-1.16/{go-cross-canadian_1.16.10.bb => go-cross-canadian_1.16.13.bb} (100%)
rename recipes-devtools/go-1.16/{go-cross_1.16.10.bb => go-cross_1.16.13.bb} (100%)
rename recipes-devtools/go-1.16/{go-crosssdk_1.16.10.bb => go-crosssdk_1.16.13.bb} (100%)
rename recipes-devtools/go-1.16/{go-native_1.16.10.bb => go-native_1.16.13.bb} (100%)
rename recipes-devtools/go-1.16/{go-runtime_1.16.10.bb => go-runtime_1.16.13.bb} (100%)
rename recipes-devtools/go-1.16/{go_1.16.10.bb => go_1.16.13.bb} (100%)

diff --git a/recipes-devtools/go-1.16/go-1.16.10.inc b/recipes-devtools/go-1.16/go-1.16.13.inc
similarity index 82%
rename from recipes-devtools/go-1.16/go-1.16.10.inc
rename to recipes-devtools/go-1.16/go-1.16.13.inc
index 7549ffc..6d148f7 100644
--- a/recipes-devtools/go-1.16/go-1.16.10.inc
+++ b/recipes-devtools/go-1.16/go-1.16.13.inc
@@ -1,8 +1,6 @@
require go-common.inc

-GO_BASEVERSION = "1.16"
-PV = "1.16.10"
-FILESEXTRAPATHS:prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
+FILESEXTRAPATHS:prepend := "${FILE_DIRNAME}/go-1.16:"

LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"

@@ -17,7 +15,7 @@ SRC_URI += "\
file://0008-use-GOBUILDMODE-to-set-buildmode.patch \
file://0009-Revert-cmd-go-make-sure-CC-and-CXX-are-absolute.patch \
"
-SRC_URI[main.sha256sum] = "a905472011585e403d00d2a41de7ced29b8884309d73482a307f689fd0f320b5"
+SRC_URI[main.sha256sum] = "b0926654eaeb01ef43816638f42d7b1681f2d3f41b9559f07735522b7afad41a"

# Upstream don't believe it is a signifiant real world issue and will only
# fix in 1.17 onwards where we can drop this.
diff --git a/recipes-devtools/go-1.16/go-binary-native_1.16.10.bb b/recipes-devtools/go-1.16/go-binary-native_1.16.10.bb
deleted file mode 100644
index 4866c9f..0000000
--- a/recipes-devtools/go-1.16/go-binary-native_1.16.10.bb
+++ /dev/null
@@ -1,46 +0,0 @@
-# This recipe is for bootstrapping our go-cross from a prebuilt binary of Go from golang.org.
-
-SUMMARY = "Go programming language compiler (upstream binary for bootstrap)"
-HOMEPAGE = " http://golang.org/"
-LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
-
-PROVIDES = "go-native"
-
-SRC_URI = "https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE}"
-SRC_URI[go_linux_amd64.sha256sum] = "414cd18ce1d193769b9e97d2401ad718755ab47816e13b2a1cde203d263b55cf"
-SRC_URI[go_linux_arm64.sha256sum] = "bfe1d4b82626c742b4690a832ca59a21e3d702161556f3c0ed26dffb368927e9"
-
-UPSTREAM_CHECK_URI = "https://golang.org/dl/"
-UPSTREAM_CHECK_REGEX = "go(?P<pver>\d+(\.\d+)+)\.linux"
-
-S = "${WORKDIR}/go"
-
-inherit goarch native
-
-do_compile() {
- :
-}
-
-make_wrapper() {
- rm -f ${D}${bindir}/$1
- cat <<END >${D}${bindir}/$1
-#!/bin/bash
-here=\`dirname \$0\`
-export GOROOT="${GOROOT:-\`readlink -f \$here/../lib/go\`}"
-\$here/../lib/go/bin/$1 "\$@"
-END
- chmod +x ${D}${bindir}/$1
-}
-
-do_install() {
- find ${S} -depth -type d -name testdata -exec rm -rf {} +
-
- install -d ${D}${bindir} ${D}${libdir}/go
- cp --preserve=mode,timestamps -R ${S}/ ${D}${libdir}/
-
- for f in ${S}/bin/*
- do
- make_wrapper `basename $f`
- done
-}
diff --git a/recipes-devtools/go-1.16/go-cross-canadian_1.16.10.bb b/recipes-devtools/go-1.16/go-cross-canadian_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go-cross-canadian_1.16.10.bb
rename to recipes-devtools/go-1.16/go-cross-canadian_1.16.13.bb
diff --git a/recipes-devtools/go-1.16/go-cross_1.16.10.bb b/recipes-devtools/go-1.16/go-cross_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go-cross_1.16.10.bb
rename to recipes-devtools/go-1.16/go-cross_1.16.13.bb
diff --git a/recipes-devtools/go-1.16/go-crosssdk_1.16.10.bb b/recipes-devtools/go-1.16/go-crosssdk_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go-crosssdk_1.16.10.bb
rename to recipes-devtools/go-1.16/go-crosssdk_1.16.13.bb
diff --git a/recipes-devtools/go-1.16/go-native_1.16.10.bb b/recipes-devtools/go-1.16/go-native_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go-native_1.16.10.bb
rename to recipes-devtools/go-1.16/go-native_1.16.13.bb
diff --git a/recipes-devtools/go-1.16/go-runtime_1.16.10.bb b/recipes-devtools/go-1.16/go-runtime_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go-runtime_1.16.10.bb
rename to recipes-devtools/go-1.16/go-runtime_1.16.13.bb
diff --git a/recipes-devtools/go-1.16/go_1.16.10.bb b/recipes-devtools/go-1.16/go_1.16.13.bb
similarity index 100%
rename from recipes-devtools/go-1.16/go_1.16.10.bb
rename to recipes-devtools/go-1.16/go_1.16.13.bb
--
2.20.1


[meta-lts-mixins][dunfell/go PATCH 1/2] go: update 1.17.4 -> 1.17.6

Alexander Kanavin
 

(copy from external source:
git: https://git.yoctoproject.org/poky/
archive: 472a99447fe0f89bbdb959c1d9b7f67f8a122935
copy: meta/recipes-devtools/go --> recipes-devtools/go-1.17)

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
.../go-1.17/{go-1.17.4.inc => go-1.17.6.inc} | 4 +-
...not-write-linker-flags-into-buildids.patch | 41 +++++++++++++++++++
...ldgo.go-do-not-hardcode-host-compile.patch | 41 +++++++++++++++++++
...e_1.17.4.bb => go-binary-native_1.17.6.bb} | 4 +-
recipes-devtools/go-1.17/go-common.inc | 4 +-
..._1.17.4.bb => go-cross-canadian_1.17.6.bb} | 0
...{go-cross_1.17.4.bb => go-cross_1.17.6.bb} | 0
...osssdk_1.17.4.bb => go-crosssdk_1.17.6.bb} | 0
...o-native_1.17.4.bb => go-native_1.17.6.bb} | 0
recipes-devtools/go-1.17/go-runtime.inc | 8 +++-
...runtime_1.17.4.bb => go-runtime_1.17.6.bb} | 0
recipes-devtools/go-1.17/go-target.inc | 11 +++++
.../go-1.17/{go_1.17.4.bb => go_1.17.6.bb} | 0
13 files changed, 108 insertions(+), 5 deletions(-)
rename recipes-devtools/go-1.17/{go-1.17.4.inc => go-1.17.6.inc} (80%)
create mode 100644 recipes-devtools/go-1.17/go-1.17/0001-exec.go-do-not-write-linker-flags-into-buildids.patch
create mode 100644 recipes-devtools/go-1.17/go-1.17/0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch
rename recipes-devtools/go-1.17/{go-binary-native_1.17.4.bb => go-binary-native_1.17.6.bb} (83%)
rename recipes-devtools/go-1.17/{go-cross-canadian_1.17.4.bb => go-cross-canadian_1.17.6.bb} (100%)
rename recipes-devtools/go-1.17/{go-cross_1.17.4.bb => go-cross_1.17.6.bb} (100%)
rename recipes-devtools/go-1.17/{go-crosssdk_1.17.4.bb => go-crosssdk_1.17.6.bb} (100%)
rename recipes-devtools/go-1.17/{go-native_1.17.4.bb => go-native_1.17.6.bb} (100%)
rename recipes-devtools/go-1.17/{go-runtime_1.17.4.bb => go-runtime_1.17.6.bb} (100%)
rename recipes-devtools/go-1.17/{go_1.17.4.bb => go_1.17.6.bb} (100%)

diff --git a/recipes-devtools/go-1.17/go-1.17.4.inc b/recipes-devtools/go-1.17/go-1.17.6.inc
similarity index 80%
rename from recipes-devtools/go-1.17/go-1.17.4.inc
rename to recipes-devtools/go-1.17/go-1.17.6.inc
index 5c4423a..3ea23e0 100644
--- a/recipes-devtools/go-1.17/go-1.17.4.inc
+++ b/recipes-devtools/go-1.17/go-1.17.6.inc
@@ -14,8 +14,10 @@ SRC_URI += "\
file://0007-cmd-go-make-GOROOT-precious-by-default.patch \
file://0008-use-GOBUILDMODE-to-set-buildmode.patch \
file://0009-Revert-cmd-go-make-sure-CC-and-CXX-are-absolute.patch \
+ file://0001-exec.go-do-not-write-linker-flags-into-buildids.patch \
+ file://0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \
"
-SRC_URI[main.sha256sum] = "4bef3699381ef09e075628504187416565d710660fec65b057edf1ceb187fc4b"
+SRC_URI[main.sha256sum] = "4dc1bbf3ff61f0c1ff2b19355e6d88151a70126268a47c761477686ef94748c8"

# Upstream don't believe it is a signifiant real world issue and will only
# fix in 1.17 onwards where we can drop this.
diff --git a/recipes-devtools/go-1.17/go-1.17/0001-exec.go-do-not-write-linker-flags-into-buildids.patch b/recipes-devtools/go-1.17/go-1.17/0001-exec.go-do-not-write-linker-flags-into-buildids.patch
new file mode 100644
index 0000000..20b6636
--- /dev/null
+++ b/recipes-devtools/go-1.17/go-1.17/0001-exec.go-do-not-write-linker-flags-into-buildids.patch
@@ -0,0 +1,41 @@
+From bdd69b55387f80c8df18d0af5008bf5e1a66be6a Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Mon, 23 Nov 2020 19:22:04 +0000
+Subject: [PATCH] exec.go: do not write linker flags into buildids
+
+The flags can contain build-specific paths, breaking reproducibility.
+
+To make this acceptable to upstream, we probably need to trim the flags,
+removing those known to be buildhost-specific.
+
+Upstream-Status: Inappropriate [needs upstream discussion]
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ src/cmd/go/internal/work/exec.go | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
+index 696db23..727d40b 100644
+--- a/src/cmd/go/internal/work/exec.go
++++ b/src/cmd/go/internal/work/exec.go
+@@ -1136,7 +1136,7 @@ func (b *Builder) linkActionID(a *Action) cache.ActionID {
+ }
+
+ // Toolchain-dependent configuration, shared with b.linkSharedActionID.
+- b.printLinkerConfig(h, p)
++ //b.printLinkerConfig(h, p)
+
+ // Input files.
+ for _, a1 := range a.Deps {
+@@ -1418,7 +1418,7 @@ func (b *Builder) linkSharedActionID(a *Action) cache.ActionID {
+ fmt.Fprintf(h, "goos %s goarch %s\n", cfg.Goos, cfg.Goarch)
+
+ // Toolchain-dependent configuration, shared with b.linkActionID.
+- b.printLinkerConfig(h, nil)
++ //b.printLinkerConfig(h, nil)
+
+ // Input files.
+ for _, a1 := range a.Deps {
+--
+2.17.1
+
diff --git a/recipes-devtools/go-1.17/go-1.17/0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch b/recipes-devtools/go-1.17/go-1.17/0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch
new file mode 100644
index 0000000..257454a
--- /dev/null
+++ b/recipes-devtools/go-1.17/go-1.17/0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch
@@ -0,0 +1,41 @@
+From 2055a46b396e272616c0b2273903e02c3b49a2ff Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Tue, 10 Nov 2020 16:33:27 +0000
+Subject: [PATCH] src/cmd/dist/buildgo.go: do not hardcode host compilers into
+ target binaries
+
+These come from $CC/$CXX on the build host and are not useful on targets;
+additionally as they contain host specific paths, this helps reproducibility.
+
+Upstream-Status: Inappropriate [needs upstream discussion]
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ src/cmd/dist/buildgo.go | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/cmd/dist/buildgo.go b/src/cmd/dist/buildgo.go
+index caafc13..4eb1c96 100644
+--- a/src/cmd/dist/buildgo.go
++++ b/src/cmd/dist/buildgo.go
+@@ -34,8 +34,8 @@ func mkzdefaultcc(dir, file string) {
+ fmt.Fprintf(&buf, "package cfg\n")
+ fmt.Fprintln(&buf)
+ fmt.Fprintf(&buf, "const DefaultPkgConfig = `%s`\n", defaultpkgconfig)
+- buf.WriteString(defaultCCFunc("DefaultCC", defaultcc))
+- buf.WriteString(defaultCCFunc("DefaultCXX", defaultcxx))
++ buf.WriteString(defaultCCFunc("DefaultCC", map[string]string{"":"gcc"}))
++ buf.WriteString(defaultCCFunc("DefaultCXX", map[string]string{"":"g++"}))
+ writefile(buf.String(), file, writeSkipSame)
+ return
+ }
+@@ -46,8 +46,8 @@ func mkzdefaultcc(dir, file string) {
+ fmt.Fprintf(&buf, "package main\n")
+ fmt.Fprintln(&buf)
+ fmt.Fprintf(&buf, "const defaultPkgConfig = `%s`\n", defaultpkgconfig)
+- buf.WriteString(defaultCCFunc("defaultCC", defaultcc))
+- buf.WriteString(defaultCCFunc("defaultCXX", defaultcxx))
++ buf.WriteString(defaultCCFunc("defaultCC", map[string]string{"":"gcc"}))
++ buf.WriteString(defaultCCFunc("defaultCXX", map[string]string{"":"g++"}))
+ writefile(buf.String(), file, writeSkipSame)
+ }
+
diff --git a/recipes-devtools/go-1.17/go-binary-native_1.17.4.bb b/recipes-devtools/go-1.17/go-binary-native_1.17.6.bb
similarity index 83%
rename from recipes-devtools/go-1.17/go-binary-native_1.17.4.bb
rename to recipes-devtools/go-1.17/go-binary-native_1.17.6.bb
index 8d8142c..674f917 100644
--- a/recipes-devtools/go-1.17/go-binary-native_1.17.4.bb
+++ b/recipes-devtools/go-1.17/go-binary-native_1.17.6.bb
@@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
PROVIDES = "go-native"

SRC_URI = "https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE}"
-SRC_URI[go_linux_amd64.sha256sum] = "adab2483f644e2f8a10ae93122f0018cef525ca48d0b8764dae87cb5f4fd4206"
-SRC_URI[go_linux_arm64.sha256sum] = "617a46bd083e59877bb5680998571b3ddd4f6dcdaf9f8bf65ad4edc8f3eafb13"
+SRC_URI[go_linux_amd64.sha256sum] = "231654bbf2dab3d86c1619ce799e77b03d96f9b50770297c8f4dff8836fc8ca2"
+SRC_URI[go_linux_arm64.sha256sum] = "82c1a033cce9bc1b47073fd6285233133040f0378439f3c4659fe77cc534622a"

UPSTREAM_CHECK_URI = "https://golang.org/dl/"
UPSTREAM_CHECK_REGEX = "go(?P<pver>\d+(\.\d+)+)\.linux"
diff --git a/recipes-devtools/go-1.17/go-common.inc b/recipes-devtools/go-1.17/go-common.inc
index dfccebd..83f8db7 100644
--- a/recipes-devtools/go-1.17/go-common.inc
+++ b/recipes-devtools/go-1.17/go-common.inc
@@ -23,7 +23,7 @@ INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
SSTATE_SCAN_CMD = "true"

export GOROOT_OVERRIDE = "1"
-export GOTMPDIR ?= "${WORKDIR}/go-tmp"
+export GOTMPDIR ?= "${WORKDIR}/build-tmp"
GOTMPDIR[vardepvalue] = ""
export CGO_ENABLED = "1"

@@ -37,6 +37,8 @@ export GO386 ?= "${TARGET_GO386}"
export GOMIPS ?= "${TARGET_GOMIPS}"
export GOROOT_FINAL ?= "${libdir}/go"

+export GODEBUG = "gocachehash=1"
+
do_compile:prepend() {
BUILD_CC=${BUILD_CC}
}
diff --git a/recipes-devtools/go-1.17/go-cross-canadian_1.17.4.bb b/recipes-devtools/go-1.17/go-cross-canadian_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go-cross-canadian_1.17.4.bb
rename to recipes-devtools/go-1.17/go-cross-canadian_1.17.6.bb
diff --git a/recipes-devtools/go-1.17/go-cross_1.17.4.bb b/recipes-devtools/go-1.17/go-cross_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go-cross_1.17.4.bb
rename to recipes-devtools/go-1.17/go-cross_1.17.6.bb
diff --git a/recipes-devtools/go-1.17/go-crosssdk_1.17.4.bb b/recipes-devtools/go-1.17/go-crosssdk_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go-crosssdk_1.17.4.bb
rename to recipes-devtools/go-1.17/go-crosssdk_1.17.6.bb
diff --git a/recipes-devtools/go-1.17/go-native_1.17.4.bb b/recipes-devtools/go-1.17/go-native_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go-native_1.17.4.bb
rename to recipes-devtools/go-1.17/go-native_1.17.6.bb
diff --git a/recipes-devtools/go-1.17/go-runtime.inc b/recipes-devtools/go-1.17/go-runtime.inc
index 617e6b5..ccb86d4 100644
--- a/recipes-devtools/go-1.17/go-runtime.inc
+++ b/recipes-devtools/go-1.17/go-runtime.inc
@@ -2,10 +2,16 @@ DEPENDS = "virtual/${TUNE_PKGARCH}-go go-native"
DEPENDS:class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk"
PROVIDES = "virtual/${TARGET_PREFIX}go-runtime"

+DEBUG_PREFIX_MAP = "\
+ -fdebug-prefix-map=${STAGING_DIR_HOST}= \
+ -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
+"
+
export CGO_CFLAGS = "${CFLAGS}"
export CGO_CPPFLAGS = "${CPPFLAGS}"
export CGO_CXXFLAGS = "${CXXFLAGS}"
-export CGO_LDFLAGS = "${LDFLAGS}"
+# Filter out -fdebug-prefix-map options as they clash with the GO's build system
+export CGO_LDFLAGS = "${@ ' '.join(filter(lambda f: not f.startswith('-fdebug-prefix-map'), d.getVar('LDFLAGS').split())) }"
export GOCACHE = "${B}/.cache"

GO_EXTLDFLAGS ?= "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${LDFLAGS}"
diff --git a/recipes-devtools/go-1.17/go-runtime_1.17.4.bb b/recipes-devtools/go-1.17/go-runtime_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go-runtime_1.17.4.bb
rename to recipes-devtools/go-1.17/go-runtime_1.17.6.bb
diff --git a/recipes-devtools/go-1.17/go-target.inc b/recipes-devtools/go-1.17/go-target.inc
index 47b4411..b0d487a 100644
--- a/recipes-devtools/go-1.17/go-target.inc
+++ b/recipes-devtools/go-1.17/go-target.inc
@@ -1,6 +1,17 @@
DEPENDS = "virtual/${TUNE_PKGARCH}-go go-native"
DEPENDS:class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk go-native"

+DEBUG_PREFIX_MAP = "\
+ -fdebug-prefix-map=${STAGING_DIR_HOST}= \
+ -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
+"
+
+export CGO_CFLAGS = "${CFLAGS}"
+export CGO_CPPFLAGS = "${CPPFLAGS}"
+export CGO_CXXFLAGS = "${CXXFLAGS}"
+# Filter out -fdebug-prefix-map options as they clash with the GO's build system
+export CGO_LDFLAGS = "${@ ' '.join(filter(lambda f: not f.startswith('-fdebug-prefix-map'), d.getVar('LDFLAGS').split())) }"
+
export GOCACHE = "${B}/.cache"
GO_LDFLAGS = ""
GO_LDFLAGS:class-nativesdk = "-linkmode external"
diff --git a/recipes-devtools/go-1.17/go_1.17.4.bb b/recipes-devtools/go-1.17/go_1.17.6.bb
similarity index 100%
rename from recipes-devtools/go-1.17/go_1.17.4.bb
rename to recipes-devtools/go-1.17/go_1.17.6.bb
--
2.20.1


Re: wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Matthias Klein
 

Hello Khem,

this means you are choosing openSSL to provide TLS protocol implementation instead of gnuTLS
Please excuse that my question was so unspecific.
Does it make a functional difference from which library the TLS support comes from?

Best regards,
Matthias


Re: [Openembedded-architecture] Inclusive Language Proposal for YP/OE folllow-up

Tim Orling
 



On Thu, Feb 3, 2022 at 6:31 PM Jon Mason <jdmason@...> wrote:
This is a follow up to the Inclusive Language email I sent out on
January 24 (see
https://lore.kernel.org/yocto/CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@.../).
I'm adding a couple of additional mailing lists to this email that
were not on the original distribution, in case there are developers
for those areas which didn't see the original email.

I really appreciate the positive feedback received on this.  I've
updated the wiki with the suggested changes by Ross (acked by Randy)
and Mikko, and extrapolated that to be the following list:

CVE_CHECK_PN_WHITELIST ->
CVE_CHECK_SKIPRECIPE ->
CVE_CHECK_SKIP_RECIPE

CVE_CHECK_WHITELIST ->
CVE_CHECK_IGNORECVE ->
CVE_CHECK_IGNORE

INHERIT_BLACKLIST ->
INHERIT_RECIPESKIP ->
INHERIT_RECIPE_SKIP

SDK_LOCAL_CONF_BLACKLIST ->
ESDK_LOCALCONF_REMOVE ->
ESDK_LOCAL_CONF_REMOVE

If anyone wants to nack the changes above, please let me know (or
modify https://wiki.yoctoproject.org/wiki/Inclusive_language).
Similarly, I've added all of the proposed names to the "approved name"
column.

On the same wiki, I've changed the tables to now have a volunteer
developer column (from the "Assigned Developer" name) to make it more
clear that we need help in doing these tasks.  If there is anything
you are interested in, please feel free to put your name down there
and have at it.

This looks to be in good shape. Thank you to the reviewers for some excellent variable names.


Thanks,
Jon



1061 - 1080 of 57098