Date   

Autotools bitbake recepie unexpected parameters

Mikael Falkvidd
 

Hi.

I am trying to add a bitbake recipe for https://github.com/quiet/libfec

This is my libfec/libfec_1.0.bb:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
EXTRA_OECONF = "--prefix=${D}/usr/local"

SRCREV = "9750ca0a6d0a786b506e44692776b541f90daa91"
SRC_URI = "git://github.com/quiet/libfec.git"
S = "${WORKDIR}/git"

inherit autotools


When I bake it (bitbake -c clean libfec && bitbake libfec -v), I get the following error:
ERROR: Function failed: do_install (log file is located at /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/temp/log.do_install.14765)
ERROR: Logfile of failure stored in: /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/temp/log.do_install.14765
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Executing shell function do_install
| + cd /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/build
| + do_install
| + autotools_do_install
| + oe_runmake DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
| + oe_runmake_call DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
| + bbnote make -j 8 DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
| + echo NOTE: make -j 8 DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
| NOTE: make -j 8 DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
| + make -j 8 DESTDIR=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image install
|
| mkdir -p /usr/lib
|
| install -m 644 -p libfec.so libfec.a /usr/lib
|
| install: cannot create regular file '/usr/lib/libfec.so': Permission denied

This seems to be due to configure getting lots of parameters that I have not actively specified (bindir, sbindir, libexecdir, ...):

autoreconf: configure.in: not using Automake
autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

+ cd /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/build
+ [ -e /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure ]
+ oe_runconf
+ cfgscript=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure
+ [ -x /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure ]

+ bbnote Running /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure  --build=x86_64-linux             --host=arm-oe-linux-gnueabi
          --target=arm-oe-linux-gnueabi                   --prefix=/usr                   --exec_prefix=/usr              --bindir=/usr/bin               --sbindir=/usr/sbin             --libexecdir=/usr/lib/libfec            --datadir=/usr/share            --sysconfdir=/etc               --sharedstatedir=/com                   --localstatedir=/var            --libdir=/usr/lib               --includedir=/usr/include               --oldincludedir=/usr/include            --infodir=/usr/share/info               --mandir=/usr/share/man                 --disable-silent-rules                  --disable-dependency-tracking                   --with-libtool-sysroot=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/sysroots/zynq-soft-nanosdr-mb-v2 --prefix=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image/usr/local
+ echo NOTE: Running /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure  --build=x86_64-linux                 --host=arm-oe-linux-gnueabi
            --target=arm-oe-linux-gnueabi                   --prefix=/usr                   --exec_prefix=/usr              --bindir=/usr/bin               --sbindir=/usr/sbin             --libexecdir=/usr/lib/libfec            --datadir=/usr/share            --sysconfdir=/etc               --sharedstatedir=/com                   --localstatedir=/var            --libdir=/usr/lib               --includedir=/usr/include               --oldincludedir=/usr/include            --infodir=/usr/share/info               --mandir=/usr/share/man                 --disable-silent-rules                  --disable-dependency-tracking                   --with-libtool-sysroot=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/sysroots/zynq-soft-nanosdr-mb-v2 --prefix=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image/usr/local
NOTE: Running /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure  --build=x86_64-linux                --host=arm-oe-linux-gnueabi
          --target=arm-oe-linux-gnueabi                   --prefix=/usr                   --exec_prefix=/usr              --bindir=/usr/bin               --sbindir=/usr/sbin             --libexecdir=/usr/lib/libfec            --datadir=/usr/share            --sysconfdir=/etc               --sharedstatedir=/com                   --localstatedir=/var            --libdir=/usr/lib               --includedir=/usr/include               --oldincludedir=/usr/include            --infodir=/usr/share/info               --mandir=/usr/share/man                 --disable-silent-rules                  --disable-dependency-tracking                   --with-libtool-sysroot=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/sysroots/zynq-soft-nanosdr-mb-v2 --prefix=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image/usr/local
+ set +e
+ /home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/git/configure --build=x86_64-linux --host=arm-oe-linux-gnueabi --target=arm-oe-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/libfec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/sysroots/zynq-soft-nanosdr-mb-v2 --prefix=/home/atlas/git/z7000-sdr-gomspace/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libfec/1.0-r0/image/usr/local


I think I need to find why these parameters are passed, and make sure they are not passed so ./configure can fall back to just using --prefix.
Could anyone give me any hints on how to troubleshoot this?

Best regards
Mikael


Re: how to establish a link between source code and s specific execuable #yocto

csimmonds
 

On 20/04/2020 08:17, zhangyifan46@huawei.com wrote:
Hello,
I have a question about the question, how to establish a link between
source code and s specific execuable.
Let me explain this.
For example ,  the output of a project has many excutables,like lzma,xz,
etc. Then i'd like to know what code(.c files) produces xz, what code
produces lzma. I know log.do_compile can provide clue about it(like gcc
-o xz xxx.c , but it is indirective and also confusing). Dose yocto
provide users with a clearer way for the link?
Also, I am not sure if objdump shows all the headers of the execuable.
thanks 

If you have compiled the executables with debug info then you can use
'objdump --dwarf' and look for the DW_AT_name and DW_AT_comp_dir
records. They will give you the full path to each source file at the
time of compilation





--
Chris Simmonds, trainer and consultant at 2net
http://www.2net.co.uk
Author of "Mastering Embedded Linux Programming"


how to establish a link between source code and s specific execuable #yocto

zhangyifan46@...
 

Hello,
I have a question about the question, how to establish a link between source code and s specific execuable.
Let me explain this.
For example ,  the output of a project has many excutables,like lzma,xz, etc. Then i'd like to know what code(.c files) produces xz, what code produces lzma. I know log.do_compile can provide clue about it(like gcc -o xz xxx.c , but it is indirective and also confusing). Dose yocto provide users with a clearer way for the link?
Also, I am not sure if objdump shows all the headers of the execuable.
thanks 


[meta-security][PATCH] samhain: dnmalloc hash fix for aarch64 and mips64

Haseeb Ashraf
 

fix runtime error:
samhain[4069]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH
Killed

The proper fix is not to disable dnmalloc. This change is in
continuation of samhain-mips64-aarch64-dnmalloc-hash-fix.patch
which requires CONFIG_ARCH_AARCH64 or CONFIG_ARCH_MIPS64 to be
defined for the corresponding architecture

Signed-off-by: Haseeb Ashraf <Haseeb_Ashraf@mentor.com>
---
recipes-ids/samhain/samhain.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index 0a5e432..b867bbc 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -67,6 +67,9 @@ PACKAGECONFIG[acl] = " --enable-posix-acl , --disable-posix-acl, acl"
PACKAGECONFIG[audit] = "ac_cv_header_auparse_h=yes,ac_cv_header_auparse_h=no,audit"
PACKAGECONFIG[ps] = "--with-ps-path=${base_bindir}/ps,,,procps"

+EXTRA_OEMAKE_append_aarch64 = " CPPFLAGS+=-DCONFIG_ARCH_AARCH64=1"
+EXTRA_OEMAKE_append_mips64 = " CPPFLAGS+=-DCONFIG_ARCH_MIPS64=1"
+
do_unpack_samhain() {
cd ${WORKDIR}
tar -xzvf samhain-${PV}.tar.gz
@@ -118,7 +121,6 @@ do_configure () {
--enable-network=${SAMHAIN_MODE} \
--with-pid-file=${localstatedir}/run/samhain.pid \
--with-data-file=${localstatedir}/lib/samhain/samhain_file \
- --disable-dnmalloc \
${EXTRA_OECONF}
}

--
2.17.1


U-Boot for IMX8mq_var_dart #yocto

Amrun Nisha.R
 

Hi,

I want to run the uboot as a separate image. So I have followed the steps from the link: http://variwiki.com/index.php?title=Yocto_Customizing_the_Linux_kernel . After cloning the u boot project, I have done the make command but the make was failed. I have to know, is that cloning is correct or not? Could someone help on this one?


Proper configuration for Systemd service to be restarted on failure

JH
 

Hi,

I built Yocto systemd Linux running on a device 7 / 24, it is hard to
access the device, so my application services are running by bash
script in loop sleep 1 minute, the service and scripts worked fine, I
don't want the application service stopped for any reasons, I searched
on Internet, there are many different examples for configuring service
file to restart it on failure, but most statements are conflicted,
what is the best way to let systemd restart my application services
when the scripts stops for Yocto systemd OS?

[Unit]
After=multi-user.target

[Service]
Type=simple
RemainAfterExit=no
Restart=always
RestartSec=120s
ExecStart=/data/bin/apploop60seconds.sh

[Install]
WantedBy=multi-user.target

Thank you.

Kind regards,

- jh

------------------------------
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs


Re: Building zeek 3.1.1 in Sumo

Philip Balister
 

I'd add sed-native to DEPENDS rather than depend on one on the build
machine.

On 4/18/20 5:14 PM, gary@missionsecure.com wrote:
Placing the following line in the recipe seems to have fixed the problem:

OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH"

That value was set to only by the cmake class, so it only searched in the recipe build directories.




Re: Building zeek 3.1.1 in Sumo

Gary Huband
 

Placing the following line in the recipe seems to have fixed the problem:

OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH"

That value was set to only by the cmake class, so it only searched in the recipe build directories.


Re: Building zeek 3.1.1 in Sumo

Konrad Weihmann
 

I would say a `DEPENDS += "sed"` in the recipe should fix things - btw sumo is kind of ancient already, ever considered updating to a newer version of poky?

On 18.04.20 18:57, gary@missionsecure.com wrote:
I'm trying to create a recipe in Sumo for zeek (zeek.org) which uses cmake.  I'm getting a sed not found error:
Initialising tasks: 100% |#######################################################################################################################################################| Time: 0:00:01
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: zeek-3.1.1-r0 do_configure: Function failed: do_configure (log file is located at /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/temp/log.do_configure.18009)
ERROR: Logfile of failure stored in: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/temp/log.do_configure.18009
Log data follows:
| DEBUG: Executing shell function do_configure
| -- The C compiler identification is GNU 7.3.0
| -- The CXX compiler identification is GNU 7.3.0
| -- Check for working C compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
| -- Check for working C compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -- works
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Check for working CXX compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
| -- Check for working CXX compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -- works
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - done
| -- Detecting CXX compile features
| -- Detecting CXX compile features - done
| CMake Error at CMakeLists.txt:170 (message):
|   Could not find required dependency: sed
I tracked this down to the cmake find_program(), here's the lines in CMakeLists.txt:
########################################################################
## Dependency Configuration
include(FindRequiredPackage)
# Check cache value first to avoid displaying "Found sed" messages everytime
if (NOT SED_EXE)
    find_program(SED_EXE sed)
    if (NOT SED_EXE)
        message(FATAL_ERROR "Could not find required dependency: sed")
    else ()
        message(STATUS "Found sed: ${SED_EXE}")
    endif ()
endif ()
Any ideas how to fix this?


Building zeek 3.1.1 in Sumo

Gary Huband
 

I'm trying to create a recipe in Sumo for zeek (zeek.org) which uses cmake.  I'm getting a sed not found error:

Initialising tasks: 100% |#######################################################################################################################################################| Time: 0:00:01
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: zeek-3.1.1-r0 do_configure: Function failed: do_configure (log file is located at /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/temp/log.do_configure.18009)
ERROR: Logfile of failure stored in: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/temp/log.do_configure.18009
Log data follows:
| DEBUG: Executing shell function do_configure
| -- The C compiler identification is GNU 7.3.0
| -- The CXX compiler identification is GNU 7.3.0
| -- Check for working C compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
| -- Check for working C compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -- works
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Check for working CXX compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
| -- Check for working CXX compiler: /opt/PHYTEC_BSPs19/yocto_imx7/build-msi1/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/zeek/3.1.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -- works
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - done
| -- Detecting CXX compile features
| -- Detecting CXX compile features - done
| CMake Error at CMakeLists.txt:170 (message):
|   Could not find required dependency: sed

I tracked this down to the cmake find_program(), here's the lines in CMakeLists.txt:

########################################################################
## Dependency Configuration
 
include(FindRequiredPackage)
 
# Check cache value first to avoid displaying "Found sed" messages everytime
if (NOT SED_EXE)
    find_program(SED_EXE sed)
    if (NOT SED_EXE)
        message(FATAL_ERROR "Could not find required dependency: sed")
    else ()
        message(STATUS "Found sed: ${SED_EXE}")
    endif ()
endif ()

Any ideas how to fix this?


Re: bootsrap

Konrad Weihmann
 

On 18.04.20 16:16, Rakesh Kumar wrote:
Hi all,
Can anyone give me any guidance in creating recipe for any application which is having bootstrap.Here i am installing my application in /var directory and this application is having bootstrap that needs to execute after creating rootfs.Here is the steps which i am following.
do_install() {
        install -m 0755 -d  ${D}/var/
        cp -rf ${S}/  ${D}/var
}
do_install_append() {
 cd  ${D}/var/my_app/
 ./bootstrap
}
::DISCLAIMER::
------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
------------------------------------------------------------------------


bootsrap

Rakesh Kumar
 

Hi all,


Can anyone give me any guidance in creating recipe for any application which is having bootstrap.Here i am installing my application in /var directory and this application is having bootstrap that needs to execute after creating rootfs.Here is the steps which i am following.


do_install() {
        install -m 0755 -d  ${D}/var/

        cp -rf ${S}/  ${D}/var
}

do_install_append() {

 cd  ${D}/var/my_app/
 ./bootstrap

}
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


Re: FYI: Why people are using #hashtags in yocto email subjects. #hashtags

Randy MacLeod
 

On 2020-04-17 4:09 a.m., Nicolas Dechesne wrote:
On Thu, Apr 16, 2020 at 9:36 PM Denys Dmytriyenko <denis@denix.org <mailto:denis@denix.org>> wrote:
I doubt people that actually send emails to the list use #hashtags.
But the new list server provides this posting feature for anyone to
address
the list and requests poster to add #hashtags - very annoying, indeed:
https://lists.yoctoproject.org/g/yocto/post
there is that. And looking at the history on the server, most of the existing tags came from the web. But a hashtag is created automatically when using '#' in the email subject. that's how #define was created:
https://lists.yoctoproject.org/g/yocto/message/48686
and this email created #hashtags ;-)
I haven't found a way to disable it.. from what I can see we can
1. force every message to have at least one hashtag...
2. bounce message with a new hashtag in $subject
3. remove new hashtag when used in $subject
I don't think we need to change anything.
I found it annoying at first because I didn't know about the
archive tagging feature.
I think we will need to do some tests to see what #3 does.. But in any case, I don't think we can prevent users from creating hashtags from the web..
Is that causing any issues with patches workflow?
I am not aware of any workflow problems.

../Randy
--
Denys
On Thu, Apr 16, 2020 at 03:18:34PM -0400, Randy MacLeod wrote:
> FYI:
>
> I don't know if I missed the memo/tweet about the email archive
feature
> but I just noticed that the new archive site will index emails
> by hashtag:
>
> https://lists.yoctoproject.org/g/yocto
>
> https://lists.yoctoproject.org/g/yocto/hashtags
>
> I thought it was an annoying new behaviour coming from Twitter users
> but now I understand why there are hashtags on my lawn^Hsubject
lines.
>
> ;-)
>
> --
> # Randy MacLeod
> # Wind River Linux

>

--
# Randy MacLeod
# Wind River Linux


[meta-openssl102][PATCH] conf/layer.conf: Set layer compatible with dunfell

Fabio Berton
 

Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index c7dcd8a..30ef9c9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two =3D "5"
=20
LAYERVERSION_meta-openssl-one-zero-two =3D "1"
=20
-LAYERSERIES_COMPAT_meta-openssl-one-zero-two =3D "thud warrior zeus"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two =3D "thud warrior zeus dunf=
ell"
=20
LAYERDEPENDS_meta-openssl-one-zero-two =3D " \
core \
--=20
2.26.1


Re: FYI: Why people are using #hashtags in yocto email subjects. #hashtags

Nicolas Dechesne
 



On Thu, Apr 16, 2020 at 9:36 PM Denys Dmytriyenko <denis@...> wrote:
I doubt people that actually send emails to the list use #hashtags.

But the new list server provides this posting feature for anyone to address
the list and requests poster to add #hashtags - very annoying, indeed:

https://lists.yoctoproject.org/g/yocto/post

there is that. And looking at the history on the server, most of the existing tags came from the web. But a hashtag is created automatically when using '#' in the email subject. that's how #define was created:

and this email created #hashtags ;-)

I haven't found a way to disable it.. from what I can see we can
1. force every message to have at least one hashtag...
2. bounce message with a new hashtag in $subject
3. remove new hashtag when used in $subject

I think we will need to do some tests to see what #3 does.. But in any case, I don't think we can prevent users from creating hashtags from the web..

Is that causing any issues with patches workflow?



--
Denys


On Thu, Apr 16, 2020 at 03:18:34PM -0400, Randy MacLeod wrote:
> FYI:
>
> I don't know if I missed the memo/tweet about the email archive feature
> but I just noticed that the new archive site will index emails
> by hashtag:
>
>    https://lists.yoctoproject.org/g/yocto
>
>    https://lists.yoctoproject.org/g/yocto/hashtags
>
> I thought it was an annoying new behaviour coming from Twitter users
> but now I understand why there are hashtags on my lawn^Hsubject lines.
>
> ;-)
>
> --
> # Randy MacLeod
> # Wind River Linux

>



Re: Guidance Downgrading Python2 in Zeus #python

MikeB
 

Thank you all.  The new layer did the trick for me also.

Regards, Mike

On Wed, Apr 15, 2020 at 12:33 PM McKay, Sean <sean.mckay@...> wrote:

FYI, we’re doing the same internally (vendor supplied FIPS supported openssl 1.0.2), and the layer Armin suggests worked for us on zeus with minimal additional tweaking.

 

Good luck!

-Sean

 

From: yocto@... <yocto@...> On Behalf Of akuster
Sent: Wednesday, April 15, 2020 9:23 AM
To: MikeB <mabnhdev@...>; yocto@...
Subject: Re: [yocto] Guidance Downgrading Python2 in Zeus #python

 

 

On 4/15/20 9:16 AM, MikeB wrote:

I'm working on a set of platforms that have a FIPs certified OpenSSL.  We are at version 1.0.2l.

I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).

We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).

I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).

I know how to downgrade simple recipes, but python is far from simple.

Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?


Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/

- armin


Thanks, Mike

 

 


[meta-cgl][PATCH] initramfs-cgl-boot: Use common MIT license

Jeremy Puhlman
 

From: Jeremy Puhlman <jpuhlman@mvista.com>

Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
---
.../recipes-core/initrdscripts/initramfs-cgl-boot_1.0.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boo=
t_1.0.bb b/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_=
1.0.bb
index 1a2dd1d..8b1768a 100644
--- a/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_1.0.b=
b
+++ b/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_1.0.b=
b
@@ -1,8 +1,7 @@
SUMMARY =3D "Support for having multipath iSCSI devices as root file sys=
tem"
LICENSE =3D "MIT"
-LIC_FILES_CHKSUM =3D "file://../COPYING.MIT;md5=3D838c366f69b72c5df05c96=
dff79b35f2"
+LIC_FILES_CHKSUM =3D "file://${COREBASE}/meta/COPYING.MIT;md5=3D3da9cfbc=
b788c80a0384361b4de20420"
SRC_URI =3D "file://init-boot.sh \
- file://COPYING.MIT \
"
=20
do_install() {
--=20
2.20.1


Re: FYI: Why people are using #hashtags in yocto email subjects. #hashtags

Denys Dmytriyenko
 

I doubt people that actually send emails to the list use #hashtags.

But the new list server provides this posting feature for anyone to address
the list and requests poster to add #hashtags - very annoying, indeed:

https://lists.yoctoproject.org/g/yocto/post

--
Denys

On Thu, Apr 16, 2020 at 03:18:34PM -0400, Randy MacLeod wrote:
FYI:

I don't know if I missed the memo/tweet about the email archive feature
but I just noticed that the new archive site will index emails
by hashtag:

https://lists.yoctoproject.org/g/yocto

https://lists.yoctoproject.org/g/yocto/hashtags

I thought it was an annoying new behaviour coming from Twitter users
but now I understand why there are hashtags on my lawn^Hsubject lines.

;-)

--
# Randy MacLeod
# Wind River Linux


FYI: Why people are using #hashtags in yocto email subjects. #hashtags

Randy MacLeod
 

FYI:

I don't know if I missed the memo/tweet about the email archive feature
but I just noticed that the new archive site will index emails
by hashtag:

https://lists.yoctoproject.org/g/yocto

https://lists.yoctoproject.org/g/yocto/hashtags

I thought it was an annoying new behaviour coming from Twitter users
but now I understand why there are hashtags on my lawn^Hsubject lines.

;-)

--
# Randy MacLeod
# Wind River Linux


Re: Building gutenprint recipe

Randy MacLeod
 

On 2018-07-07 6:02 a.m., Timm wrote:
There was a gutenprint recipe back in OE-Classic:
https://layers.openembedded.org/layerindex/oe-classic/recipe/12076/
But currently there is no gutenprint available for Yocto.
Timm,

Did you ever get the gutenprint recipe to work?
Are you able to add it to meta-oe or share
what you have done so far here?

../Randy
I tried to build my own recipe. But I got stuck at the stage where the
build process wants to call some generated binaries:
    | ./extract-strings `cat xml-stamp | sed -e
's;^;../../../gutenprint-5.2.11/src/xml/;'` > xmli18n-tmp.h.tmp
    | /lib/ld-linux-armhf.so.3: No such file or directory
So, I introduced a "native" recipe, which just compiles the
"extract-strings" for me:
----------------------------------------------------------------------------------------------------------
SECTION = "libs"
require gutenprint_${PV}.bb
DEPENDS = "gettext-native"
inherit native autotools
EXTRA_OECONG = "\
        --disable-libgutenprintui2 \
            --disable-samples \
        --without-gimp2 \
        --without-doc \
        --disable-nls \
        --disable-nls-macos \
        --without-foomatic \
        --without-foomatic3 \
        --disable-escputil \
        --disable-test \
        --disable-testpattern \
        --without-cups \
               "
do_compile() {
    oe_runmake -C src/xml/ extract-strings
}
-----------------------------------------------------------------------------------------------------------------
The next step is quite unclear for me? How can I tell the build system
not to generate the extract-strings again and use the native instead?
As reference I used the build scripts from openwrt and buildroot. But
I'm not able to translate this build steps to Yocto.
https://github.com/FranciscoBorges/openwrt-printing-packages/blob/master/net/gutenprint/Makefile
https://github.com/buildroot/buildroot/blob/master/package/gutenprint/gutenprint.mk

--
# Randy MacLeod
# Wind River Linux

4721 - 4740 of 53901