On Sat, Feb 5, 2022 at 4:05 AM Electronic Consult
<electronicconsult1@...> wrote:

Hello all,

Apologies if this is the incorrect group to post to, I haven't posted previously.

I'm working with an Atmel/ Microchip SAMA5D4 Xplained board & a resistive touchscreen. I'm using a GUI framework that has issues dealing with evdev & tslib so looks like I need to find a screen calibration method for libinput, which the GUI framework favours.

Since you are using tslib, the ts_calibrate utility would be the
obvious choice. Include the tslib_calibrate package in your image. You
might also find the tslib_tests package useful.

Steve

Can anyone please suggest a solution for this? I've taken a look at a recipe for xinput-calibrator & it seems like a possible solution. However my build isn't running a desktop GUI so not sure if this is a proper fit.

I'd appreciate if anyone could point me in the right direction.

Many thanks,

Owen

prelink has been dropped from oe-core [1], so the bbappend can no longer be
applied.

[1] https://git.openembedded.org/openembedded-core/commit/?id=23c0be78106f1d1e2bb9c724174a1bb8c56c2469

Signed-off-by: Tim Orling <tim.orling@...>
---
recipes-devtools/prelink/prelink_git.bbappend | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 recipes-devtools/prelink/prelink_git.bbappend

diff --git a/recipes-devtools/prelink/prelink_git.bbappend b/recipes-devtools/prelink/prelink_git.bbappend
deleted file mode 100644
index 74e22b3..0000000
--- a/recipes-devtools/prelink/prelink_git.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-selinux', '', d)}
--
2.25.1

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?

Quoting Leon Woestenberg <leon@...>:

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.

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

--

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.

rday

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

bump lexical-core to 0.6.8

Signed-off-by: Armin Kuster <akuster808@...>
---
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

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

Bryan Evenson <bevenson@...> 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]

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

Enrico,

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

"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

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