Date   

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

Alexander Kanavin <alex.kanavin@...> 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@...> 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@...> 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@...>
---
.../{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@...>
---
.../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@...>
+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@...>
+---
+ 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@...>
+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@...>
+---
+ 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




Inclusive Language Proposal for YP/OE folllow-up

Jon Mason
 

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@mail.gmail.com/).
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.

Thanks,
Jon


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

Khem Raj
 

On Thu, Feb 3, 2022 at 9:14 AM Matthias Klein
<matthias.klein@...> wrote:

Hello together,

I can "fix" the bug by switching from gnutls to openssl:

PACKAGECONFIG:remove = "gnutls"
PACKAGECONFIG:append = " openssl"

Can anyone explain this?
What exactly does the change to openssl mean?
this means you are choosing openSSL to provide TLS protocol
implementation instead of gnuTLS


Many greetings,
Matthias



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

Matthias Klein
 

Hello together,

I can "fix" the bug by switching from gnutls to openssl:

PACKAGECONFIG:remove = "gnutls"
PACKAGECONFIG:append = " openssl"

Can anyone explain this?
What exactly does the change to openssl mean?

Many greetings,
Matthias


Minutes: Yocto Project Weekly Triage Meeting 2/3/2022

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alejandro, Alexandre, Andrei, Armin, Bruce, Daiane, Michael, Pavel, Randy, Richard, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Armin/Bruce/Trevor/Saul to move Old Milestone bugs to M3 or later


Notes:

- ~50% of AB workers have been switched to SSDs. Failure rate appears lower, but still TBD

Medium+ 3.5 Unassigned Enhancements/Bugs: 76 (Last week 76)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last week 39)

AB Bugs: 73 (Last week 76)


Re: IGC build issue with devtoolset-8 (GNU 8.3.1)

Monsees, Steven C (US)
 

 

Is there a CPP conflict due to :

 

./tmp/work/corei7-64-poky-linux/intel-graphics-compiler/1.0.11-r0/git/inc/common/UFO/portable_compiler.h

 

Is this a name space issue ?

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, February 3, 2022 8:33 AM
To: yocto@...
Subject: Re: [yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Anybody ?

 

It appears to be a CPP issue in the IGC code… but not sure why.

The “__syscall_slong_t” definition appears to be getting resolved out correctly when I replace the array with individual variables of the same type (and the IGC is working)…

 

I’d feel more comfortable patching the IGC, but am still trying to fully understand the root cause…

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

Note:

 

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

 

#elif defined(__GNUC__)

#   include <libgen.h>

#   include <sys/stat.h> <<<---Line #47

#endif

 

sys/stat.h:

 

#include <bits/types.h>         /* For __mode_t and __dev_t.  */

 

#include <bits/stat.h>

 

 

bits/stat.h:    __syscall_slong_t __unused[3];

 

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

 

                #if defined __x86_64__ && defined __ILP32__

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SQUAD_TYPE

                #else

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SLONGWORD_TYPE

 

                #if __WORDSIZE == 32

                                bits/types.h:# define __SQUAD_TYPE                     __quad_t

                #elif __WORDSIZE == 64

                                bits/types.h:# define __SQUAD_TYPE                     long int

 

bits/types.h:

 

#define __SLONGWORD_TYPE   long int

 

 

From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@...
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)

 

 

I am building zeus with basic OpenCL support for centos 7.x, and using GNU 8.3.1 compiler and see the following Error when IGC is built, I see the same error when building with GNU 5.3.1…

 

Is this a known issue, is a patch available ?

Any ideas why I might be seeing this ?

 

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|             

 

I am using bitbake –k, and everything else builds correctly, and no other components references this…

 

If I modify the header like so:

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

IGC builds clean, and test show it appears to working correctly…

 

I really shouldn’t be modifying the header, and would like to know what the real issue issue is…

 

Thanks,

Steve


Re: IGC build issue with devtoolset-8 (GNU 8.3.1)

Monsees, Steven C (US)
 

 

Anybody ?

 

It appears to be a CPP issue in the IGC code… but not sure why.

The “__syscall_slong_t” definition appears to be getting resolved out correctly when I replace the array with individual variables of the same type (and the IGC is working)…

 

I’d feel more comfortable patching the IGC, but am still trying to fully understand the root cause…

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

Note:

 

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

 

#elif defined(__GNUC__)

#   include <libgen.h>

#   include <sys/stat.h> <<<---Line #47

#endif

 

sys/stat.h:

 

#include <bits/types.h>         /* For __mode_t and __dev_t.  */

 

#include <bits/stat.h>

 

 

bits/stat.h:    __syscall_slong_t __unused[3];

 

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

 

                #if defined __x86_64__ && defined __ILP32__

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SQUAD_TYPE

                #else

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SLONGWORD_TYPE

 

                #if __WORDSIZE == 32

                                bits/types.h:# define __SQUAD_TYPE                     __quad_t

                #elif __WORDSIZE == 64

                                bits/types.h:# define __SQUAD_TYPE                     long int

 

bits/types.h:

 

#define __SLONGWORD_TYPE   long int

 

 

From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@...
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)

 

 

I am building zeus with basic OpenCL support for centos 7.x, and using GNU 8.3.1 compiler and see the following Error when IGC is built, I see the same error when building with GNU 5.3.1…

 

Is this a known issue, is a patch available ?

Any ideas why I might be seeing this ?

 

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|             

 

I am using bitbake –k, and everything else builds correctly, and no other components references this…

 

If I modify the header like so:

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

IGC builds clean, and test show it appears to working correctly…

 

I really shouldn’t be modifying the header, and would like to know what the real issue issue is…

 

Thanks,

Steve


Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.

Alexander Kanavin
 

Thanks Michael!
Adrian, the branches are now available:


so I'm ready to take any patches you would like to have there, pls send them via this mailing list. Otherwise I'll get the branches updated to latest component versions.

Alex


On Thu, 3 Feb 2022 at 00:50, Michael Halstead <mhalstead@...> wrote:
Thank you for the ping. These branches are ready for you.

On Tue, Feb 1, 2022 at 6:23 AM Alexander Kanavin <alex.kanavin@...> wrote:
On Thu, 27 Jan 2022 at 21:06, Denys Dmytriyenko <denis@...> wrote:
On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote:
> A question specifically to Denys, how can I actually get this into the
> mixin repo, and have commit rights to the branch? We've tested this quite
> well in private, and there are further enhancements coming up.

Michael,

Would it be possible to create 2 additional branches in the meta-lts-mixins
repository at https://git.yoctoproject.org/meta-lts-mixins/ called
"dunfell/go" and also "dunfell/docker" and give Alex push rights to them?

Please let us know, thanks a lot!

Ping, please :)

Alex


--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Re: Building of warrior branch fails when building with Ubuntu 20.04 LTS #linux #qemu #yocto

Sourabh Hegde
 

Hello Bernd,

I am facing same issue. Did the patch worked for you? I tried to apply the patch and still have the same issue.

Thanks in advance


Re: Build error:undefined reference to `stime' on Yocto Warrior

Sourabh Hegde
 

Hello,

I applied the patch https://patchwork.openembedded.org/patch/172282/ like below:

Downloaded patch file from above link and deleted below part from patch file:

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index f451017f6d..ad4ff52892 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -27,6 +27,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
            file://0008-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
            file://0009-Fix-webkitgtk-builds.patch \
            file://0010-configure-Add-pkg-config-handling-for-libgcrypt.patch \
+           file://0011-linux-user-remove-host-stime-syscall.patch \
            file://CVE-2019-15890.patch \
            file://CVE-2019-12068.patch \
            file://CVE-2020-1711.patch \

Because,my /meta/recipes-devtools/qemu/qemu.inc file already has other patches under the anme "0011".

Then I copied the patch file to "poky/meta/recipes-devtools/qemu/qemu/" And appended SRC_URI of "qemu-native.inc" with "file://0015-linux-user-remove-host-stime-syscall.patch \".

After doing bitbake -c cleansstate <image> and bitbake <image> I still get below errors which is related to "x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'" and some warnings related to utime and stime.

i have attached complete log file for reference.

Can anyone please let me know if patch has been correctly applied and how to resolve this issue?

Thanks in advance.

Your help will be much appreciated.


Re: Private: Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake

Nicolas Jeker
 

Re-adding the list.

On Wed, 2022-02-02 at 11:51 -0800, Sourabh Hegde wrote:
Hi @Nicolas,
Hi Sourabh

Thanks for the detailed answer.

I followed your steps to fix ssh "config" file and now it's working
fine.
Glad to hear it works now.

Regarding my build environment: I am using Docker Desktop for Windows
so i am starting container from Docker Desktop GUI, not from Windows
powershell. So I was confused how to pass "-v
$SSH_AUTH_SOCK:/ssh.socket \".  I hope it's making sense here. Please
do let me know if I am doing anything wrong here so that I don't face
similar issues in future.
I see, I never used Docker Desktop for Windows, so I can't give you
advice about that specifically. If the ssh connection works correctly
with the configuration you created, you shouldn't need to forward the
ssh agent.

Thanks in advance.


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

Matthias Klein
 

Hello,

another addition to the problem:
The problem does not seem to be directly related to the custom kernel or the one yocto, as I can recreate the problem in a second yocto.

The yocto is for the qemuarm "virt" machine. I have the complete sources for it here: https://github.com/matthiasklein/meta-yocto-coffee-qemuarm

Is it possible that it is somehow related to 32 bit ARM?

# uname -a
Linux qemuarm 5.15.16-yocto-standard #1 SMP PREEMPT Tue Jan 25 14:32:58 UTC 2022 armv7l GNU/Linux

# wget -4 https://speed.hetzner.de/100MB.bin
--2022-02-03 09:18:37-- https://speed.hetzner.de/100MB.bin
SSL_INIT
Resolving speed.hetzner.de... 88.198.248.254
Connecting to speed.hetzner.de|88.198.248.254|:443... connected.
The certificate has not yet been activated

# wget --version
GNU Wget 1.21.2 built on linux-gnueabi.

-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls
+ntlm +opie -psl +ssl/gnutls

Wgetrc:
/etc/wgetrc (system)
Locale:
/usr/share/locale
Compile:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DHAVE_CONFIG_H
-DSYSTEM_WGETRC="/etc/wgetrc" -DLOCALEDIR="/usr/share/locale" -I.
-I../../wget-1.21.2/src -I../lib -I../../wget-1.21.2/lib -DNDEBUG
-O2 -pipe -g -feliminate-unused-debug-types
Link:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DNDEBUG -O2
-pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -lpcre
-lnettle -lgnutls -lz ftp-opie.o gnutls.o http-ntlm.o
../lib/libgnu.a -lunistring

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@...>.
Please send bug reports and questions to <bug-wget@...>.

Best regards,
Matthias

1321 - 1340 of 57347