Date   

Re: How to get mysqy/mariadb to start on powerup.

slopez@...
 

Hi, all!
I'm having the same issue. I'm dummy with yocto, How I can create the bbappend file?
I added the file mariadb_%.bbappend in my layer folder/recipes-dbs/mysql and add the line:
SYSTEMD_AUTO_ENABLE_${PN}-server ?= "enable"
But nothings occurred, What I'm doing wrong?
Regads,


Mongodb 4.0.6 compilation failed with openssl 1 1.1a or openssl 1 1.1pre9 recipe.

amaya jindal
 


Hi All, 
we have rocko version of yocto project. So we have added the support of mongodb 4.0.6 from updated yocto codename. Now we need to add openssl 1.1.1 along with the above mongodb version but I am getting compilation issues. Can anyone help or guide me on that. 
Sent from my Huawei phone


Mongodb 4.0.6 compilation failed with openssl 1 1.1a

amaya jindal
 



Hi All, 
we have rocko version of yocto project. So we have added the support of mongodb 4.0.6 from updated yocto codename. Now we need to add openssl 1.1.1 along with the above mongodb version but I am getting compilation issues. Can anyone help or guide me on that. 
Sent from my Huawei phone
Sent from my Huawei phone


Re: Autotools bitbake recepie unexpected parameters

Mikael Falkvidd
 

Thanks Ross.

The reason I tried to pass --prefix to ./configure was that the install part was trying to install files at the host instead of the target. I thought passing the prefix parameter would make the install go to the target dir.

I'll try your suggestion to patch the Makefile instead. Hopefully that will result in a PR I can submit to the upstream repository.

Best regards
Mikael

Den mån 20 apr. 2020 kl 16:00 skrev Ross Burton <ross@...>:

On Mon, 20 Apr 2020 at 14:43, Mikael Falkvidd via
lists.yoctoproject.org <yocto=mjo.se@...> wrote:
> EXTRA_OECONF = "--prefix=${D}/usr/local"

This patch should be relative to the target, so /usr/local.

The entire point of the autotools class is to call the autotools with
common arguments, which is why it is passing more options.  Note how
you're setting ***EXTRA***_OECONF.

> 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?

Why would you want to remove the carefully constructed set of
arguments and replace them with just your one option?  Your build
would break, I don't see you passing --target or --host for example
would be fatal.

I'm not sure why you feel the need to install to /usr/local/ instead
of /usr.  Anyway, the real problem is that libfec isn't using
automake, just autoconf.  Thus, it's 'make install' is fundamentally
broken:

install: all
  mkdir -p @libdir@
  ...

At no point does it try to install into a 'destdir' for staging
without writing directly to your build machine's /usr.  You'll need to
patch the Makefile to respect a DESTDIR, something like this:

  mkdir -p $(DESTDIR)@libdir@

This sort of problem does suggest that the repository is dead.

Ross


Re: Autotools bitbake recepie unexpected parameters

Ross Burton <ross@...>
 

On Mon, 20 Apr 2020 at 14:43, Mikael Falkvidd via
lists.yoctoproject.org <yocto=mjo.se@...> wrote:
EXTRA_OECONF = "--prefix=${D}/usr/local"
This patch should be relative to the target, so /usr/local.

The entire point of the autotools class is to call the autotools with
common arguments, which is why it is passing more options. Note how
you're setting ***EXTRA***_OECONF.

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?
Why would you want to remove the carefully constructed set of
arguments and replace them with just your one option? Your build
would break, I don't see you passing --target or --host for example
would be fatal.

I'm not sure why you feel the need to install to /usr/local/ instead
of /usr. Anyway, the real problem is that libfec isn't using
automake, just autoconf. Thus, it's 'make install' is fundamentally
broken:

install: all
mkdir -p @libdir@
...

At no point does it try to install into a 'destdir' for staging
without writing directly to your build machine's /usr. You'll need to
patch the Makefile to respect a DESTDIR, something like this:

mkdir -p $(DESTDIR)@libdir@

This sort of problem does suggest that the repository is dead.

Ross


Re: Autotools bitbake recepie unexpected parameters

Konrad Weihmann <kweihmann@...>
 

Hi Mikeal,

To me it seems like the makefile has no support for DESTDIR builtin - which is the mechanism poky relies on.
I've seen this projects offers a cmake file as well, maybe you have more luck with that, if not you have to patch the makefile.in, so it will understand DESTDIR, which default to none and prefixes every path in the makefile on installing.
I'm not sure about the --prefix hack - I would rather go for doing it correctly in the makefile.

Regards
Konrad

On 20.04.20 15:43, Mikael Falkvidd via lists.yoctoproject.org wrote:
Hi.
I am trying to add a bitbake recipe for https://github.com/quiet/libfec
This is my libfec/libfec_1.0.bb <http://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 <http://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 <http://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


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@... 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@...>
---
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@... 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 <kweihmann@...>
 

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@... 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 <kweihmann@...>
 

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@... <mailto: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:
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@...>
---
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

8201 - 8220 of 57387