Re: [yocto] downgrade openssl libraryes

[Bas Mevissen via lists.yoctoproject.org]

On 2021-08-30 16:56, Ivan Riabtsov wrote:

I have phytec imx6ul board with a preinstalled os. On this os opessl
version is 1.0.2j i need to build nginx for this board, but i can't
build yocto same version as i have on board, so I grabbed a newer
version of yocto from phytec site, rolled back glibc and try to roll
back openssl. I do not want to flash the device, as I'm afraid to get
brick



Why are you afraid to brick the device? You can use mfgtool to reflash 
the device from scratch, including u-boot. It works with a special boot 
mode pin setting and uses an USB port. Depending on the board, one might 
need to buy or create a custom cable.


Bas.

пн, 30 авг. 2021 г. в 16:51, Alexander Kanavin 
:


openssl 1.0.2 went out of support at the end of 2019 and you should 
not be using it. What is the problem you need to solve?


Alex

On Mon, 30 Aug 2021 at 15:33, Ivan Riabtsov  
wrote:


hello i am trying to rollback openssl version from 1.1.1i to 1.0.2j.
Copied the recipe openssl_1.1.1i.bb to openssl_1.0.2j.bb, saved the
openssl_1.1.1i.bb version with the name openssl_1.1.1i.bb.backup

Отредактировал новый файл, вот разница в файлах:

diff -Nau ./openssl_1.1.1i.bb.backup ./openssl_1.0.2j.bb
--- ./openssl_1.1.1i.bb.backup 2021-08-27 14:46:07.085808702 +0300
+++ ./openssl_1.0.2j.bb 2021-08-27 16:12:14.216430734 +0300
@@ -7,23 +7,19 @@
 # "openssl" here actually means both OpenSSL and SSLeay licenses 
apply

 # (see meta/files/common-licenses/OpenSSL to which "openssl" is
SPDXLICENSEMAPped)
 LICENSE = "openssl"
-LIC_FILES_CHKSUM = 
"file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
+LIC_FILES_CHKSUM = 
"file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"


 DEPENDS = "hostperl-runtime-native"

 SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
-   file://0001-skip-test_symbol_presence.patch \
-   
file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch

\
-   file://afalg.patch \
-   file://reproducible.patch \
"

 SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"

-SRC_URI[sha256sum] =
"e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242"
+SRC_URI[sha256sum] =
"e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"

 inherit lib_package multilib_header multilib_script ptest
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
@@ -122,7 +118,7 @@
  # WARNING: do not set compiler/linker flags (-I/-D etc.) in
EXTRA_OECONF, as they will fully replace the
  # environment variables set by bitbake. Adjust the environment
variables instead.
  HASHBANGPERL="/usr/bin/env perl" PERL=perl
PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
- perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS}
--prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir}
$target
+ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS}
--prefix=$useprefix --openssldir=${libdir}/ssl-1.0 --libdir=${libdir}
$target
  perl ${B}/configdata.pm --dump
 }

@@ -134,30 +130,30 @@
  # Create SSL structure for packages such as ca-certificates which
  # contain hard-coded paths to /etc/ssl. Debian does the same.
  install -d ${D}${sysconfdir}/ssl
- mv ${D}${libdir}/ssl-1.1/certs \
-${D}${libdir}/ssl-1.1/private \
-${D}${libdir}/ssl-1.1/openssl.cnf \
+ mv ${D}${libdir}/ssl-1.0/certs \
+${D}${libdir}/ssl-1.0/private \
+${D}${libdir}/ssl-1.0/openssl.cnf \
 ${D}${sysconfdir}/ssl/

  # Although absolute symlinks would be OK for the target, they 
become

  # invalid if native or nativesdk are relocated from sstate.
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.1/certs
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.1/private
- ln -sf ${@oe.path.relative('${libdir}/ssl-1.1',
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.1/openssl.cnf
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.0/certs
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.0/private
+ ln -sf ${@oe.path.relative('${libdir}/ssl-1.0',
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.0/openssl.cnf
 }

 do_install_append_class-native () {
  create_wrapper ${D}${bindir}/openssl \
- OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
- SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
- SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
- OPENSSL_ENGINES=${libdir}/engines-1.1
+ OPENSSL_CONF=${libdir}/ssl-1.0/openssl.cnf \
+ SSL_CERT_DIR=${libdir}/ssl-1.0/certs \
+ SSL_CERT_FILE=${libdir}/ssl-1.0/cert.pem \
+ OPENSSL_ENGINES=${libdir}/engines-1.0
 }

 do_install_append_class-nativesdk () {
  mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
  install -m 644 ${WORKDIR}/environment.d-openssl.sh
${D}${SDKPATHNATIVE}/environment-setup.d/openssl.sh
- sed 's|/usr/lib

Re: [yocto] [meta-cgl][PATCH] ucarp: fix build error with gcc-10

[Bas Mevissen]

On 2020-09-23 11:36, ChenQi wrote:

On 09/23/2020 04:55 PM, Bas Mevissen wrote:

On 2020-09-23 09:56, Chen Qi wrote:

gcc-10 uses '-fno-common' by default, causing multiple definition
error. Use '-fcommon' to fix this problem.

Signed-off-by: Chen Qi 
---
 meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index d17baa0..87e5ada 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -37,6 +37,9 @@ SYSTEMD_AUTO_ENABLE = "disable"
 export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2
-t 2 -T 30 --passive-ftp --no-check-certificate"
 EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"

+# Fix build error with gcc-10
+CFLAGS_append = " -fcommon"
+


Why are you not patching the source to use "extern" where it is 
needed, like in pacemaker? How many errors does ucarp give?
Then it might also a patch that upstream will take, solving the issue 
forever in a proper way.




Could you please send out one?



I don't have a tree with this layer in front of me. I just reviewed your 
proposed fix by setting the compiler flag, while you demonstrated in the 
pacemaker patch that the issue is easily solved by adding some "exern"s 
where they need to be. So I wondered why you didn't do that for ucarp.



 # fix the perms for config.rpath
 do_configure_prepend() {
 chmod 755 ${S}/config.rpath






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50786): https://lists.yoctoproject.org/g/yocto/message/50786
Mute This Topic: https://lists.yoctoproject.org/mt/77030457/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-cgl][PATCH] ucarp: fix build error with gcc-10

[Bas Mevissen]

On 2020-09-23 09:56, Chen Qi wrote:

gcc-10 uses '-fno-common' by default, causing multiple definition
error. Use '-fcommon' to fix this problem.

Signed-off-by: Chen Qi 
---
 meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index d17baa0..87e5ada 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -37,6 +37,9 @@ SYSTEMD_AUTO_ENABLE = "disable"
 export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2
-t 2 -T 30 --passive-ftp --no-check-certificate"
 EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"

+# Fix build error with gcc-10
+CFLAGS_append = " -fcommon"
+


Why are you not patching the source to use "extern" where it is needed, 
like in pacemaker? How many errors does ucarp give?
Then it might also a patch that upstream will take, solving the issue 
forever in a proper way.



 # fix the perms for config.rpath
 do_configure_prepend() {
 chmod 755 ${S}/config.rpath





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50784): https://lists.yoctoproject.org/g/yocto/message/50784
Mute This Topic: https://lists.yoctoproject.org/mt/77030457/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] RFC: Changes to meta-kernel layer

[Bas Mevissen]

On 2020-09-17 10:43, Paul Barker wrote:


Hi folks,

After a bit of a break I'm looking again at the meta-kernel layer and 
I've got some changes planned. I'd like to get some feedback on these 
from anyone who has looked at or used the meta-kernel layer.


1) Change the name to meta-vanilla-kernel. This reflects the focus on 
providing a fast moving layer for vanilla kernel recipes, covering only 
what is available on kernel.org. Other common kernel recipes (e.g. 
Linaro or Android common kernels) will no longer be considered for 
acceptance into this layer. This clear focus should hopefully reduce 
some of the confusion about the goals of this layer.




I would suggest calling it something like meta-kernel.org then. Naming 
something "vanilla" might cause confusion as well.


2) The dunfell branch will no longer get new non-LTS kernel recipes. 
Providing non-LTS recipes on a stable branch has led to people 
depending on kernels which are now out of their support period - I'd 
like to drop the recipes for the 5.3.y and 5.6.y kernels but users are 
depending on them so I'll have to keep them. To avoid this 
proliferating, only LTS kernels and the bleeding edge mainline recipe 
will be updated on the stable branch from now on.


I would recommend maintaining a "kernel-stable" moving target recipe 
that tracks the latest stable version of kernel.org. This is of use for 
people needing a very recent kernel, while needing a stable environment 
for the rest of the system (so where master is no option).



3) Aggressively drop end-of-life kernels on the master branch.

Always good to keep the amount of kernels at an absolut minimum to limit 
the amount of testing and maintenance.


4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is 
created.



See 2); additionally the next-to-be-lts might be considered

5) Document the test coverage for meta-kernel. We don't test perf, 
lttng or any out-of-tree modules. This layer isn't meant to replace the 
linux-yocto recipes, the goals are different. If you're releasing 
products based on meta-kernel you obviously need to do your own testing 
on the components you're actually using.


6) Document the policy for kernel patches. Patches for the kernel will 
only be carried in this layer as a last resort. Kernel patches should 
be submitted upstream and go through the usual process for inclusion in 
the stable kernel releases.


7) Disable GitLab CI for this layer. It's costing me about £70 per 
month to run CI for this layer and I need to eliminate that expense. If 
anyone can sponsor this or host the CI service that would be welcome.


8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers to 
reduce the bus factor for the layer. I'll continue to be the primary 
maintainer for this layer but this will give some coverage if I'm 
unable to continue working on it.



And spreading the workload of course!


Thanks,

--

Paul Barker
Konsulko Group




Regards,

Bas.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50706): https://lists.yoctoproject.org/g/yocto/message/50706
Mute This Topic: https://lists.yoctoproject.org/mt/76905426/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] wvdial

[Bas Mevissen]

On 2020-09-17 10:02, Zoltan Kerenyi Nagy wrote:


Hi,

Here is the error now, all the files are there, it says that 
04_signed_request.diff is not there:


WARNING: wvstreams-4.6.1-r0 do_fetch: Failed to fetch URL 
file://04_signed_request.diff, attempting MIRRORS if available
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure: Unable to find 
file file://04_signed_request.diff anywhere. The paths that were 
searched were:

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
/home/kerenyiz/oe-core/build/downloads
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure for URL: 
'file://04_signed_request.diff'. Unable to fetch URL from any source.


It is the first local file on the list, so this hints that it is 
probably a file location issue and not a file naming one.



ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: 
/home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864
ERROR: Task 
(/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch) 
failed with exit code '1'


Here i sthe folder structure:

├── file


Here is your problem: this directory should be named "wvstreams"


│   ├── 0001-build-fix-parallel-make.patch
│   ├── 0001-Check-for-limits.h-during-configure.patch
│   ├── 0001-Forward-port-to-OpenSSL-1.1.x.patch
│   ├── 0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch
│   ├── 0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch
│   ├── 0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch
│   ├── 0004-wvcrash-Replace-use-of-basename-API.patch
│   ├── 0005-check-for-libexecinfo-during-configure.patch
│   ├── 04_signed_request.diff
│   ├── 05_gcc.diff
│   ├── 06_gcc-4.7.diff
│   ├── 07_buildflags.diff
│   ├── argp.patch
│   ├── gcc-6.patch
│   └── openssl-buildfix.patch
└── wvstreams_4.6.1.bb

And this is the recipie file:

HOMEPAGE = "http://alumnit.ca/wiki/index.php?page=WvStreams";
SUMMARY = "WvStreams is a network programming library in C++"

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = 
"file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"


DEPENDS = "zlib openssl (>= 0.9.8) dbus readline"
DEPENDS_append_libc-musl = " argp-standalone libexecinfo"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.gz \
file://04_signed_request.diff \
file://05_gcc.diff \
file://06_gcc-4.7.diff \
file://07_buildflags.diff \
file://gcc-6.patch \
file://argp.patch \
file://0001-Check-for-limits.h-during-configure.patch \
file://0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch \
file://0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch 
\

file://0004-wvcrash-Replace-use-of-basename-API.patch \
file://0005-check-for-libexecinfo-during-configure.patch \
file://0001-build-fix-parallel-make.patch \
file://0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch \
file://openssl-buildfix.patch \
file://0001-Forward-port-to-OpenSSL-1.1.x.patch \
"

SRC_URI[md5sum] = "2760dac31a43d

Re: [yocto] Busybox and scripts licensing

[Bas Mevissen]

On 05/02/2020 15:57, Ross Burton wrote:

On Wed, 5 Feb 2020 at 12:16,  wrote:

Let's assume we have busybox on our device (that's populated by default by 
Yocto). What license shall be chosen for package containing custom shell 
scripts?
I heard opinion, that all shell scripts running on Busybox shall be GPLv2(?).


That opinion is very wrong indeed.

If you write the scripts then you get to pick the license.

Ross



If and only if the "custom" scripts are not clearly derived from 
otherwise licensed work that is. Clearly here means that you generally 
can include snippets from examples or existing scripts.


I'm actually wondering how things would be if you include (bash: 
"source") an existing licensed work and use part (say some functions) of 
it. Complicating fact here is that a lot of scripts don't carry an 
explicit license.


--
Bas.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48325): https://lists.yoctoproject.org/g/yocto/message/48325
Mute This Topic: https://lists.yoctoproject.org/mt/70993889/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-