Re: [yocto] No GNU_HASH in the elf binary

2019-07-15 Thread Moritz Porst 

Hello

On 15.07.19 08:42, Madhu Krishnamurthy wrote:

Hello,
I am trying to package an already built binary executable called mlc
(memory latency checker) to yocto and I get this error.

ERROR: mem-tst-0.1 do_package: QA Issue: File
'/usr/local/flex_pkgs/diags/mlc' from mem was already stripped, this
will prevent future debugging! [already-stripped]
ERROR: mem-tst-0.1 do_package: Fatal QA errors found, failing task.
ERROR: mem-tst-0.1 do_package: Function failed: do_package

Your recipe is not called mlc but mem-tst-0.1

ERROR: Logfile of failure stored in:
/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/temp/log.do_package.27614
ERROR: Task
(/home/cluser/ac/z_cpu/poky/../meta-flex/meta-z/recipes-utils/mem/mem_tst_0.1.bb:do_package)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 458 tasks of which 457 didn't need to
be rerun and 1 failed.

I googled and found that I need to add this

*INSANE_SKIP_mlc = "ldflags"*
*INSANE_SKIP_mlc-dev = "ldflags"*


Thus the two lines above can't work. The preferred way to do this is to
use ${PN} variable which expands to the package name. Like this: >>
INSANE_SKIP_${PN} = "ldflags" <<

Best regards
Moritz


*INHIBIT_PACKAGE_DEBUG_SPLIT = "1"*
*INHIBIT_PACKAGE_STRIP = "1"*

But after adding that I still get this error.
*ERROR: mem-tst-0.1 do_package_qa: QA Issue: No GNU_HASH in the elf
binary:
'/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/packages-split/mem/usr/local/flex_pkgs/diags/mlc'
[ldflags]*
Appreciate any help.

Thanks and regards
Madhu

(more log details)
NOTE: Executing RunQueue Tasks
NOTE: mem-tst-0.1 do_package_qa: Direct dependencies are
['virtual:native:/home/cluser/ac/z_cpu/poky/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
'/home/cluser/ac/z_cpu/poky/meta/recipes-devtools/binutils/binutils-cross_2.29.bb:do_populate_sysroot']
NOTE: mem-tst-0.1 do_package_qa: Installed into sysroot: []
NOTE: mem-tst-0.1 do_package_qa: Skipping as already exists in
sysroot: ['pseudo-native', 'binutils-cross-x86_64',
'gnu-config-native', 'bison-native', 'flex-native',
'texinfo-dummy-native', 'autoconf-native', 'quilt-native',
'zlib-native', 'gettext-minimal-native', 'automake-native',
'xz-native', 'libtool-native', 'm4-native']
NOTE: mem-tst-0.1 do_package_qa: DO PACKAGE QA
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem
NOTE: mem-tst-0.1 do_package_qa: x86_64-poky-linux-objdump -p
/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/packages-split/mem/usr/local/flex_pkgs/diags/mlc
*ERROR: mem-tst-0.1 do_package_qa: QA Issue: No GNU_HASH in the elf
binary:
'/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/packages-split/mem/usr/local/flex_pkgs/diags/mlc'
[ldflags]*
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem-staticdev
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem-locale
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem-doc
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem-dbg
NOTE: mem-tst-0.1 do_package_qa: Checking Package: mem-dev
*ERROR: mem-tst-0.1 do_package_qa: QA run found fatal errors. Please
consider fixing them.*
*ERROR: mem-tst-0.1 do_package_qa: Function failed: do_package_qa*
*ERROR: Logfile of failure stored in:
/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/temp/log.do_package_qa.25300*
*ERROR: Task
(/home/cluser/ac/z_cpu/poky/../meta-flex/meta-z/recipes-utils/mem/mem_tst_0.1.bb:do_package_qa)
failed with exit code '1'*
NOTE: Tasks Summary: Attempted 461 tasks of which 460 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
/home/cluser/ac/z_cpu/poky/../meta-flex/meta-z/recipes-utils/mem/mem_tst_0.1.bb:do_package_qa



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Meta-Qt5] "Unknown Module: declarative" Error While Creating Toolchain

2019-07-15 Thread Onur Eser 
Hi Khem,
Thank you for your answer. I have built a toolchain as exactly as you said,
days ago.
But it was giving error Unknown Modules: widgets when I try to compile. Me
and my
BSP found that this is a know Qt layer issue that will not be solved til an
update is pushed to meta-qt5 layer.
Thank you anyway, I am trying to native compile over Debian.
Have a great week!
Onur

Khem Raj , 15 Tem 2019 Pzt, 03:55 tarihinde şunu yazdı:

> On Mon, Jul 8, 2019 at 10:59 PM Onur Eser  wrote:
> >
> > Hello All,
> >
> > I have talked to my BSP provider and they have solved the conflict files
> issue with an update. Now I am able to create and boot a Yocto Image with
> Meta-Qt5 recipes and 'dev_pkgs' in it. But still cannot create a toolchain.
> Nor with I guess it is trying to compile something before qtdeclarative,
> but these 'something' depends on qtdeclarative.
> >
> > My image is core image is Weston. I added the line 'inherit
> populate_sdk_qt5' to my core-image-weston.bb file. And tried both
> commands 'bitbake meta-toolchain-qt5' and 'bitbake -c populate_sdk
> core-image-weston'. The result is the same.
> >
> > I cut just the error part of my output:
> >
> > | cd qdeclarativefolderlistmodel/ && ( test -e Makefile ||
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/recipe-sysroot-native/usr/bin/qt5/qmake
> -o Makefile
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/git/tests/auto/declarative/qdeclarativefolderlistmodel/
> qdeclarativefolderlistmodel.pro ) && make -f Makefile
> > | Project ERROR: Unknown module(s) in QT: declarative widgets
> > | Makefile:88: recipe for target 'sub-qdeclarativecomponent-make_first'
> failed
> > | make[2]: *** [sub-qdeclarativecomponent-make_first] Error 3
> > | make[2]: *** Waiting for unfinished jobs
> > | Project ERROR: Unknown module(s) in QT: declarative
> > | Project ERROR: Unknown module(s) in QT: declarative
> > | Makefile:113: recipe for target 'sub-qdeclarativecontext-make_first'
> failed
> > | make[2]: *** [sub-qdeclarativecontext-make_first] Error 3
> > | Project ERROR: Unknown module(s) in QT: declarative
> > | Makefile:138: recipe for target 'sub-qdeclarativeengine-make_first'
> failed
> > | make[2]: *** [sub-qdeclarativeengine-make_first] Error 3
> > | Makefile:63: recipe for target 'sub-parserstress-make_first' failed
> > | make[2]: *** [sub-parserstress-make_first] Error 3
> > | make[2]: Entering directory
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
> > | make[2]: Nothing to be done for 'first'.
> > | make[2]: Leaving directory
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
> > | make[1]: Leaving directory
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual'
> > | Project ERROR: Unknown module(s) in QT: declarative
> > | Makefile:163: recipe for target 'sub-qdeclarativeerror-make_first'
> failed
> > | make[2]: *** [sub-qdeclarativeerror-make_first] Error 3
> > | Project ERROR: Unknown module(s) in QT: declarative
> > | Makefile:188: recipe for target
> 'sub-qdeclarativefolderlistmodel-make_first' failed
> > | make[2]: *** [sub-qdeclarativefolderlistmodel-make_first] Error 3
> > | make[2]: Leaving directory
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto/declarative'
> > | Makefile:45: recipe for target 'sub-declarative-make_first' failed
> > | make[1]: *** [sub-declarative-make_first] Error 2
> > | make[1]: Leaving directory
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto'
> > | Makefile:45: recipe for target 'sub-auto-make_first' failed
> > | make: *** [sub-auto-make_first] Error 2
> > | ERROR: oe_runmake failed
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_compile_ptest_base (log file is located at
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/temp/log.do_compile_ptest_base.29566)
> > ERROR: Task 
> > (/home/closx/poky/meta-qt5/recipes-qt/qt5/qtquick1_git.bb:do_compile_ptest_base)
> failed with exit code '1'
> >
> > What do you guys think the reason of this issue may be? Any solution
> offers?
> >
> > My full output:
> > https://paste.ee/p/PupWr#Epvqnw9FoasgQEBhIXqQ8hH7veMcRybX
> >
> > Another source issue again?
> > Have a lovely day!
>
> qtquick1 has been removed but I am guessting you are on an older
> release. Can you try adding DEPENDS += "qtdeclarative"  to qtquick1
> recipe and see if that helps ?
> secondly you can stop build ptest for this package since thats where
> its failing, that might be a workaround.

Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?

2019-07-15 Thread Maciej Pijanowski 

On 15.07.2019 08:45, Gabriele Zampieri wrote:
> Hi,
>
> as far as I know, there is no mechanism to add custom bootargs and/or
> bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch
> the upstream uboot to achieve this task.
I also haven't heard of any standardized way. It may depend on the
target hardware
and the BSP layer you are using. Apart from patching the U-Boot, there
also might
be boot.cmd script to modify or the config.txt in case of the RPI, for
example.
>
> Best regards,
> Gabriele
>
> Il giorno lun 8 lug 2019 alle ore 22:43 JH  > ha scritto:
>
> Hi,
>
> Which Yocto files and which statement can I add my own U-Boot bootargs
> and bootcmd?
>
> Thank you.
>
> - jupiter
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?

2019-07-15 Thread Gabriele Zampieri 
Yes, thanks Maciej for pointing that out! It may be a good starting point
for JH.

Gabriele

Il giorno lun 15 lug 2019 alle ore 10:29 Maciej Pijanowski <
maciej.pijanow...@3mdeb.com> ha scritto:

>
> On 15.07.2019 08:45, Gabriele Zampieri wrote:
>
> Hi,
>
> as far as I know, there is no mechanism to add custom bootargs and/or
> bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch the
> upstream uboot to achieve this task.
>
> I also haven't heard of any standardized way. It may depend on the target
> hardware
> and the BSP layer you are using. Apart from patching the U-Boot, there
> also might
> be boot.cmd script to modify or the config.txt in case of the RPI, for
> example.
>
>
> Best regards,
> Gabriele
>
> Il giorno lun 8 lug 2019 alle ore 22:43 JH  ha
> scritto:
>
>> Hi,
>>
>> Which Yocto files and which statement can I add my own U-Boot bootargs
>> and bootcmd?
>>
>> Thank you.
>>
>> - jupiter
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> --
> Maciej Pijanowski
> Embedded Systems Engineerhttps://3mdeb.com | @3mdeb_com
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] ref-manual: Remove documentation for the removed bluez5 distro feature

2019-07-15 Thread Adrian Bunk 
bluez4 was removed even from meta-oe 2 years ago,
which made made the bluez5 feature for selecting between
bluez4 and bluez5 mandatory for using the bluetooth feature.

The backfilled bluez5 feature has been removed,
including the bluetooth class that helped recipes
for selecting between bluez4/bluez5.
Recipes can replace ${BLUEZ} with bluez5.

Signed-off-by: Adrian Bunk 
---
 documentation/ref-manual/ref-classes.xml  | 17 -
 documentation/ref-manual/ref-features.xml | 21 -
 2 files changed, 38 deletions(-)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index ece47e757b..37619e382d 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -318,23 +318,6 @@
 
 
 
-
-bluetooth.bbclass
-
-
-The bluetooth class defines a variable that
-expands to the recipe (package) providing core
-bluetooth support on the platform.
-
-
-
-For details on how the class works, see the
-meta/classes/bluetooth.bbclass file in the Yocto
-Project
-Source Directory.
-
-
-
 
 buildhistory.bbclass
 
diff --git a/documentation/ref-manual/ref-features.xml 
b/documentation/ref-manual/ref-features.xml
index b057d2d040..44ba67cf50 100644
--- a/documentation/ref-manual/ref-features.xml
+++ b/documentation/ref-manual/ref-features.xml
@@ -154,27 +154,6 @@
 
 bluetooth: Include
 bluetooth support (integrated BT only).
-bluez5: Include
-BlueZ Version 5, which provides core Bluetooth layers and
-protocols support.
-
-The default value for the
-DISTRO FEATURES variable includes
-"bluetooth", which causes bluez5 to be backfilled in
-for bluetooth support.
-If you do not want bluez5 backfilled and would rather
-use bluez4, you need to use the
-DISTRO_FEATURES_BACKFILL_CONSIDERED
-variable as follows:
-
- DISTRO_FEATURES_BACKFILL_CONSIDERED = "bluez5"
-
-Setting this variable tells the OpenEmbedded build
-system that you have considered but ruled
-out using the bluez5 feature and that bluez4 will be
-used.
-
-
 cramfs: Include CramFS
 support.
 directfb:
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][yocto-docs] ref-system-requirements: add Debian 10 to supported distribution list

2019-07-15 Thread Ross Burton 
Debian 10 is a supported distribution now, so add it to the documentation.

Signed-off-by: Ross Burton 
---
 documentation/ref-manual/ref-system-requirements.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/ref-manual/ref-system-requirements.xml 
b/documentation/ref-manual/ref-system-requirements.xml
index 239dd84bbdd..51995309d4f 100644
--- a/documentation/ref-manual/ref-system-requirements.xml
+++ b/documentation/ref-manual/ref-system-requirements.xml
@@ -95,6 +95,7 @@
 CentOS 7.x
 Debian GNU/Linux 8.x (Jessie)
 Debian GNU/Linux 9.x 
(Stretch)
+Debian GNU/Linux 10.x 
(Buster)
 OpenSUSE 42.3
 
 
-- 
2.20.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't boot to initramfs

2019-07-15 Thread JH 
Hi Zoran,

On 7/12/19, Zoran Stojsavljevic  wrote:
> Moritz,
>
> Thank you very much for this reply. It makes it very clear... What is
> the current State of Affairs for the topic.
>
> Let us see if there will be the improvement to this topic. I'll
> document this on one of my private GitHubs. And archive this email.

Any chance to access your documents?

Thank you.

- jupiter
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?

2019-07-15 Thread JH 
Thanks Gabriele and Maciej, I use meta-freescale for imx6. The u-boot
argements seem defined in wks files such as imx-uboot-mxs.wks,
imx-uboot-bootpart.wks, not quite sure how to extend or overwrite it.
Sorry still learning the Yocto.

Thank you.

Kind regards,

- jh

On 7/15/19, Gabriele Zampieri  wrote:
> Yes, thanks Maciej for pointing that out! It may be a good starting point
> for JH.
>
> Gabriele
>
> Il giorno lun 15 lug 2019 alle ore 10:29 Maciej Pijanowski <
> maciej.pijanow...@3mdeb.com> ha scritto:
>
>>
>> On 15.07.2019 08:45, Gabriele Zampieri wrote:
>>
>> Hi,
>>
>> as far as I know, there is no mechanism to add custom bootargs and/or
>> bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch the
>> upstream uboot to achieve this task.
>>
>> I also haven't heard of any standardized way. It may depend on the target
>> hardware
>> and the BSP layer you are using. Apart from patching the U-Boot, there
>> also might
>> be boot.cmd script to modify or the config.txt in case of the RPI, for
>> example.
>>
>>
>> Best regards,
>> Gabriele
>>
>> Il giorno lun 8 lug 2019 alle ore 22:43 JH  ha
>> scritto:
>>
>>> Hi,
>>>
>>> Which Yocto files and which statement can I add my own U-Boot bootargs
>>> and bootcmd?
>>>
>>> Thank you.
>>>
>>> - jupiter
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> --
>> Maciej Pijanowski
>> Embedded Systems Engineerhttps://3mdeb.com | @3mdeb_com
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] keyutils: remove from meta-security

2019-07-15 Thread Armin Kuster 
now in meta-oe

Signed-off-by: Armin Kuster 
---
 .../files/fix_library_install_path.patch  | 28 --
 ...ror-report-by-adding-default-message.patch | 42 ---
 .../keyutils-test-fix-output-format.patch | 41 --
 recipes-security/keyutils/files/run-ptest |  3 --
 recipes-security/keyutils/keyutils_1.6.bb | 53 ---
 5 files changed, 167 deletions(-)
 delete mode 100644 
recipes-security/keyutils/files/fix_library_install_path.patch
 delete mode 100644 
recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
 delete mode 100644 
recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
 delete mode 100755 recipes-security/keyutils/files/run-ptest
 delete mode 100644 recipes-security/keyutils/keyutils_1.6.bb

diff --git a/recipes-security/keyutils/files/fix_library_install_path.patch 
b/recipes-security/keyutils/files/fix_library_install_path.patch
deleted file mode 100644
index 938fe2e..000
--- a/recipes-security/keyutils/files/fix_library_install_path.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From b0355cc205543ffd33752874295139d57c4fbc3e Mon Sep 17 00:00:00 2001
-From: Wenzong Fan 
-Date: Tue, 26 Sep 2017 07:59:51 +
-Subject: [PATCH] Subject: [PATCH] keyutils: use relative path for link
-
-The absolute path of the symlink will be invalid
-when populated in sysroot, so use relative path instead.
-
-Upstream-Status: Pending
-
-Signed-off-by: Jackie Huang 
-Signed-off-by: Wenzong Fan 
-{rebased for 1.6]
-Signed-off-by: Armin Kuster 
-
-Index: keyutils-1.6/Makefile
-===
 keyutils-1.6.orig/Makefile
-+++ keyutils-1.6/Makefile
-@@ -184,7 +184,7 @@ ifeq ($(NO_SOLIB),0)
-   $(INSTALL) -D $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME)
-   $(LNS) $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(SONAME)
-   mkdir -p $(DESTDIR)$(USRLIBDIR)
--  $(LNS) $(LIBDIR)/$(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
-+  $(LNS) $(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
-   sed \
-   -e 's,@VERSION\@,$(VERSION),g' \
-   -e 's,@prefix\@,$(PREFIX),g' \
diff --git 
a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
 
b/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
deleted file mode 100644
index acd91c0..000
--- 
a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-fix keyutils test error report
-
-Upstream-Status: Pending
-
-"Permission denied" may be the reason of EKEYEXPIRED and EKEYREVOKED.
-"Required key not available" may be the reason of EKEYREVOKED.
-EXPIRED and REVOKED are 2 status of kernel security keys features.
-But the userspace keyutils lib will output the error message, which may
-have several reasons.
-
-Signed-off-by: Han Chao 
-
-diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
-index bbca00a..739e9d0 100644
 a/tests/toolbox.inc.sh
-+++ b/tests/toolbox.inc.sh
-@@ -227,11 +227,12 @@ function expect_error ()
-   ;;
-   EKEYEXPIRED)
-   my_err="Key has expired"
--  alt_err="Unknown error 127"
-+  alt_err="Permission denied"
-   ;;
-   EKEYREVOKED)
-   my_err="Key has been revoked"
--  alt_err="Unknown error 128"
-+  alt_err="Permission denied"
-+  alt2_err="Required key not available"
-   ;;
-   EKEYREJECTED)
-   my_err="Key has been rejected"
-@@ -249,6 +250,9 @@ function expect_error ()
- elif [ "x$alt_err" != "x" ] && expr "$my_errmsg" : ".*: $alt_err" 
>&/dev/null
- then
-   :
-+elif [ "x$alt2_err" != "x" ] && expr "$my_errmsg" : ".*: $alt2_err" 
>&/dev/null
-+then
-+  :
- elif [ "x$old_err" != "x" ] && expr "$my_errmsg" : ".*: $old_err" 
>&/dev/null
- then
-   :
-
diff --git 
a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch 
b/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
deleted file mode 100644
index a4ffd50..000
--- a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-From 49b6321368e4bd3cd233d045cd09004ddd7968b2 Mon Sep 17 00:00:00 2001
-From: Jackie Huang 
-Date: Mon, 15 May 2017 14:52:00 +0800
-Subject: [PATCH] keyutils: fix output format
-
-keyutils ptest output format is incorrect, according to yocto
-Development Manual
-(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
-5.10.6. Testing Packages With ptestThe test generates output in the format 
used by Automake:
-: 
-where the result can be PASS, FAIL, or SKIP, and the testname can be any
-identifying string.
-So we should change the test result format to match yocto ptest rules.
-
-Upstream-Status: Inappropriate [OE ptest specific]
-
-Signed-off-by: Li Wang 
-Signed-off-by: Jackie Huang 

- tests/runtest.sh | 5 +
-

Re: [yocto] [Meta-Qt5] "Unknown Module: declarative" Error While Creating Toolchain

2019-07-15 Thread Khem Raj 
On Mon, Jul 15, 2019 at 1:06 AM Onur Eser  wrote:
>
> Hi Khem,
> Thank you for your answer. I have built a toolchain as exactly as you said, 
> days ago.
> But it was giving error Unknown Modules: widgets when I try to compile. Me 
> and my
> BSP found that this is a know Qt layer issue that will not be solved til an 
> update is pushed to meta-qt5 layer.

What is complete error here and which recipe is it coming from ?
it looks like that package needs QtWidgets

> Thank you anyway, I am trying to native compile over Debian.
> Have a great week!
> Onur
>
> Khem Raj , 15 Tem 2019 Pzt, 03:55 tarihinde şunu yazdı:
>>
>> On Mon, Jul 8, 2019 at 10:59 PM Onur Eser  wrote:
>> >
>> > Hello All,
>> >
>> > I have talked to my BSP provider and they have solved the conflict files 
>> > issue with an update. Now I am able to create and boot a Yocto Image with 
>> > Meta-Qt5 recipes and 'dev_pkgs' in it. But still cannot create a 
>> > toolchain. Nor with I guess it is trying to compile something before 
>> > qtdeclarative, but these 'something' depends on qtdeclarative.
>> >
>> > My image is core image is Weston. I added the line 'inherit 
>> > populate_sdk_qt5' to my core-image-weston.bb file. And tried both commands 
>> > 'bitbake meta-toolchain-qt5' and 'bitbake -c populate_sdk 
>> > core-image-weston'. The result is the same.
>> >
>> > I cut just the error part of my output:
>> >
>> > | cd qdeclarativefolderlistmodel/ && ( test -e Makefile || 
>> > /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/recipe-sysroot-native/usr/bin/qt5/qmake
>> >  -o Makefile 
>> > /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/git/tests/auto/declarative/qdeclarativefolderlistmodel/qdeclarativefolderlistmodel.pro
>> >  ) && make -f Makefile
>> > | Project ERROR: Unknown module(s) in QT: declarative widgets
>> > | Makefile:88: recipe for target 'sub-qdeclarativecomponent-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativecomponent-make_first] Error 3
>> > | make[2]: *** Waiting for unfinished jobs
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:113: recipe for target 'sub-qdeclarativecontext-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativecontext-make_first] Error 3
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:138: recipe for target 'sub-qdeclarativeengine-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativeengine-make_first] Error 3
>> > | Makefile:63: recipe for target 'sub-parserstress-make_first' failed
>> > | make[2]: *** [sub-parserstress-make_first] Error 3
>> > | make[2]: Entering directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
>> > | make[2]: Nothing to be done for 'first'.
>> > | make[2]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
>> > | make[1]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual'
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:163: recipe for target 'sub-qdeclarativeerror-make_first' failed
>> > | make[2]: *** [sub-qdeclarativeerror-make_first] Error 3
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:188: recipe for target 
>> > 'sub-qdeclarativefolderlistmodel-make_first' failed
>> > | make[2]: *** [sub-qdeclarativefolderlistmodel-make_first] Error 3
>> > | make[2]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto/declarative'
>> > | Makefile:45: recipe for target 'sub-declarative-make_first' failed
>> > | make[1]: *** [sub-declarative-make_first] Error 2
>> > | make[1]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto'
>> > | Makefile:45: recipe for target 'sub-auto-make_first' failed
>> > | make: *** [sub-auto-make_first] Error 2
>> > | ERROR: oe_runmake failed
>> > | WARNING: exit code 1 from a shell command.
>> > | ERROR: Function failed: do_compile_ptest_base (log file is located at 
>> > /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/temp/log.do_compile_ptest_base.29566)
>> > ERROR: Task 
>> > (/home/closx/poky/meta-qt5/recipes-qt/qt5/qtquick1_git.bb:do_compile_ptest_base)
>> >  failed with exit code '1'
>> >
>> > What do you guys think the reason of this issue may be? Any solution 
>> > offers?
>> >
>> > My full output:
>> > https://paste.ee/p/PupWr#Epvqnw9FoasgQEBhIXqQ8hH7veMcRybX
>> >
>> > Anothe

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2019-07-15 Thread sjolley.yp.pm 
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 303
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "2.8", "2.9', "2.99" and "Future", the more pressing/urgent
issues being in "2.8" and then "2.9".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][PATCH] gnupg: Enable native build support

2019-07-15 Thread Burton, Ross 
Merged.

Ross

On Tue, 2 Jul 2019 at 17:03, Joshua Watt  wrote:
>
> Adds support for building gnupg as a -native recipe.
>
> Signed-off-by: Joshua Watt 
> ---
>  recipes-support/gnupg/gnupg_1.4.7.bb | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/recipes-support/gnupg/gnupg_1.4.7.bb 
> b/recipes-support/gnupg/gnupg_1.4.7.bb
> index 85636ab..a7fbd11 100644
> --- a/recipes-support/gnupg/gnupg_1.4.7.bb
> +++ b/recipes-support/gnupg/gnupg_1.4.7.bb
> @@ -84,6 +84,7 @@ EXTRA_OECONF = "--disable-ldap \
> "
>
>  # Force gcc's traditional handling of inline to avoid issues with gcc 5
> +BUILD_CFLAGS += "-fgnu89-inline"
>  CFLAGS += "-fgnu89-inline"
>
>  do_install () {
> @@ -95,6 +96,8 @@ do_install () {
>
>  # split out gpgv from main package
>  RDEPENDS_${PN} = "gpgv"
> +RDEPENDS_${PN}_class-native = ""
> +
>  PACKAGES =+ "gpgv"
>  FILES_gpgv = "${bindir}/gpgv"
>
> @@ -104,3 +107,5 @@ FILES_${PN} = "${bindir}/* ${datadir}/${BPN} 
> ${libexecdir}/${BPN}/*"
>  PACKAGECONFIG ??= ""
>  PACKAGECONFIG[curl] = 
> "--with-libcurl=${STAGING_LIBDIR},--without-libcurl,curl"
>  PACKAGECONFIG[libusb] = 
> "--with-libusb=${STAGING_LIBDIR},--without-libusb,libusb-compat"
> +
> +BBCLASSEXTEND += "native"
> --
> 2.21.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't boot to initramfs

2019-07-15 Thread Zoran Stojsavljevic 
Hello Jupiter,

I actually continued this topic initiated by Moritz, to find out how
you and me and somebody else also can build the yocto build system
with bundled rescue kernel into the rootfs.

My target architecture I am playing with is armv7 A8 (BBB), since I am
experimenting with it.

I actually built the armv7 A8 (BBB) with the unbundled initramfs,
where the BSP actually ends up for the testing purposes. All this how
I did it is described here:
https://lists.yoctoproject.org/pipermail/yocto/2018-July/041696.html

Here is also latest local.conf for warrior (how I am buillding it):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf_full

I never built such a system with rescue initramfs, ending with/in
rootfs on mtd/flash, or SD card, YOCTO wise, so I actually continued
this topic to find out exactly the same what you asked me above.

You can go over this email thread, and try while building with what we
all put as collection of patchworks.

I have no time to do this, since I need very urgently to do some other
important for me stuff on BBB.

Zoran
___




On Mon, Jul 15, 2019 at 2:10 PM JH  wrote:
>
> Hi Zoran,
>
> On 7/12/19, Zoran Stojsavljevic  wrote:
> > Moritz,
> >
> > Thank you very much for this reply. It makes it very clear... What is
> > the current State of Affairs for the topic.
> >
> > Let us see if there will be the improvement to this topic. I'll
> > document this on one of my private GitHubs. And archive this email.
>
> Any chance to access your documents?
>
> Thank you.
>
> - jupiter
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] wic: error when using --rootfs-dir=${IMAGE_ROOTFS}/data

2019-07-15 Thread Belisko Marek 
Hi,

I have wks file with following content:

part ubootenv --ondisk=mmcblk --no-table --size 12
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
--label boot --active --align 1024 --size 16
part /root --source rootfs --ondisk mmcblk --fstype=ext4 --label rootA
--align 1024 --fixed-size 300 --exclude-path data/
part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --ondisk
"mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200

Basically I want to create extra data partition with content from
rootfs /data directory. When wic image is created I'm getting strange
errors like:

Couldn't get bitbake variable from
/home/marekbelisko/.build/tmp/sysroots/raspberrypi0-wifi/imgdata/${IMAGE_ROOTFS}/data.env.
 | File 
/home/marekbelisko/.build/tmp/sysroots/raspberrypi0-wifi/imgdata/${IMAGE_ROOTFS}/data.env
doesn't exist.

I found similar usage (for boot directory in poky):
scripts/lib/wic/canned-wks/efi-bootdisk.wks.in:2:part /boot --source
rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot --fstype=vfat --label boot
--active --align 1024 --use-uuid --overhead-factor 1.0

Am I doing something wrong here or any ideas? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic: error when using --rootfs-dir=${IMAGE_ROOTFS}/data

2019-07-15 Thread Mittal, Anuj 
On Tue, 2019-07-16 at 08:38 +0200, Belisko Marek wrote:
> I have wks file with following content:
> 
> part ubootenv --ondisk=mmcblk --no-table --size 12
> part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
> --label boot --active --align 1024 --size 16
> part /root --source rootfs --ondisk mmcblk --fstype=ext4 --label
> rootA
> --align 1024 --fixed-size 300 --exclude-path data/
> part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --ondisk
> "mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200
> 
> Basically I want to create extra data partition with content from
> rootfs /data directory. When wic image is created I'm getting strange
> errors like:
> 
> Couldn't get bitbake variable from
> /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> wifi/imgdata/${IMAGE_ROOTFS}/data.env.
>  | File /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> wifi/imgdata/${IMAGE_ROOTFS}/data.env
> doesn't exist.

If you haven't tried this already, renaming .wks to .wks.in might help.

Thanks,
Anuj
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?

2019-07-15 Thread Gabriele Zampieri 
Hi JH,

wks is the extension used by wic to generate different kind of flashable
(partitioned) images. I never used it, but looking around (
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#command-bootloader
) I see two relevant arguments:

   - *--append *
   - *--configfile*

Check them in the link above.

Here is an example for --append:
https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks#L22

Digging a bit deeper it seems that you cannot feed a custom config to uboot
via wic (and again, correct me if I'm wrong), but only for extlinux (see:
https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/wic/plugins/source/bootimg-partition.py#L110
)

I do not have time to replicate your environment, so I'm just giving you
suggestions.

Best regards,
Gabriele

Il giorno lun 15 lug 2019 alle ore 14:45 JH  ha
scritto:

> Thanks Gabriele and Maciej, I use meta-freescale for imx6. The u-boot
> argements seem defined in wks files such as imx-uboot-mxs.wks,
> imx-uboot-bootpart.wks, not quite sure how to extend or overwrite it.
> Sorry still learning the Yocto.
>
> Thank you.
>
> Kind regards,
>
> - jh
>
> On 7/15/19, Gabriele Zampieri  wrote:
> > Yes, thanks Maciej for pointing that out! It may be a good starting point
> > for JH.
> >
> > Gabriele
> >
> > Il giorno lun 15 lug 2019 alle ore 10:29 Maciej Pijanowski <
> > maciej.pijanow...@3mdeb.com> ha scritto:
> >
> >>
> >> On 15.07.2019 08:45, Gabriele Zampieri wrote:
> >>
> >> Hi,
> >>
> >> as far as I know, there is no mechanism to add custom bootargs and/or
> >> bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch
> the
> >> upstream uboot to achieve this task.
> >>
> >> I also haven't heard of any standardized way. It may depend on the
> target
> >> hardware
> >> and the BSP layer you are using. Apart from patching the U-Boot, there
> >> also might
> >> be boot.cmd script to modify or the config.txt in case of the RPI, for
> >> example.
> >>
> >>
> >> Best regards,
> >> Gabriele
> >>
> >> Il giorno lun 8 lug 2019 alle ore 22:43 JH  ha
> >> scritto:
> >>
> >>> Hi,
> >>>
> >>> Which Yocto files and which statement can I add my own U-Boot bootargs
> >>> and bootcmd?
> >>>
> >>> Thank you.
> >>>
> >>> - jupiter
> >>> --
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>>
> >>
> >> --
> >> Maciej Pijanowski
> >> Embedded Systems Engineerhttps://3mdeb.com | @3mdeb_com
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto