Date   

Re: Mising init and systemd binary files

 

On Sat, 30 Nov 2019, at 11:28, JH wrote:
Hi,

I built a Yocto image, but could not find /init, usually it should be
a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In
/lib/systemd directory, it only contains a subdirectory system, all
other systemd binaries are missing, many system commands in /sbin are
also missing. What could I get wrong here to miss out all systemd
files?
Are you using an existing image recipe or writing your own? If it's your own, do you have packagegroup-core-boot included?

Thanks,

--
Paul Barker


Mising init and systemd binary files

JH
 

Hi,

I built a Yocto image, but could not find /init, usually it should be
a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In
/lib/systemd directory, it only contains a subdirectory system, all
other systemd binaries are missing, many system commands in /sbin are
also missing. What could I get wrong here to miss out all systemd
files?

Thank you.

Kind regards,

- jh


Re: How does metadata include in an image recipe work?

Morne
 

but when I run bitbake ex-image2, it only built ex-image2 image, it did not built images defined in ex-image1.bb.
See this previous answer on the mailing list to a similar question:

https://www.yoctoproject.org/pipermail/yocto/2018-August/042220.html

- Morné


Add package to rootfs

JH
 

Hi,

I built a Yocto image in a file app-image.rootfs.tar.gz, I also built
a kernel initramfs to bundle the rootfs, but that kernel rootfs is
different to my app-image.rootfs.tar.gz, how to define IMAGE_ROOTFS to
have my kernel rootfs point to the same rootfs packaged to
app-image.rootfs.tar.gz?

Thank you.

Kind regards,

- jh


How does metadata include in an image recipe work?

JH
 

Hi,

I have two images recipes, one is included in another image recipe:

$ ls recipes-core/images

ex-image1.bb ex-image2.bb

$ cat recipes-core/images/ex-image2.bb

include ex-image1.bb
......

My understanding that the metadata "include" is to include all image
files defined in the included recipe as well, but when I run bitbake
ex-image2, it only built ex-image2 image, it did not built images
defined in ex-image1.bb.

What could I be missing here? How could I build an image to include
all image files included in another image.bb?

Thank you.

Kind regards,

- jh


[matchbox-wm][PATCH] keys: Avoid freeing Wm_config member pointer in keys_load_config().

Simon Haggett
 

If the Wm_config instance contains a non-NULL pointer in its kbd_conf_file
member, then (in a build that does not use gconf) keys_load_config() will
assign that pointer to a local conf_path variable. However, keys_load_config()
later calls free() on this conf_path variable (since it may instead have been
assigned a malloc'd buffer). This can therefore leave Wm_config::kbd_conf_file
as a dangling pointer. Furthermore, if the user has specified the -kbdconfig
argument when starting matchbox-window-manager then this pointer comes from argv
and so the call to free() can lead to a segmentation fault.

This patch fixes the issue by using strdup() to make a copy of the string
pointed to by the Wm_config::kbd_conf_file member pointer. This matches the
approach used when conf_path is required to take the value of a string literal,
and ensures that free() can safely be called on conf_path.

Signed-off-by: Simon Haggett <simon.haggett@gmail.com>
---
src/keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/keys.c b/src/keys.c
index bc83bd4..ca77f81 100644
--- a/src/keys.c
+++ b/src/keys.c
@@ -326,7 +326,7 @@ keys_load_config(Wm *w)
};

if (w->config->kbd_conf_file != NULL)
- conf_path = w->config->kbd_conf_file;
+ conf_path = strdup(w->config->kbd_conf_file);

if (conf_path == NULL && getenv("HOME"))
{
--
2.17.1


Copy initramfs to rootfs

Sinisa <sgujic@...>
 

Hello everyone,

I started to build kernel with initramfs, and so far all that works
great. I got my new shiny zImage-initramfs--4.1.14..xxx.bin. I can
boot it over tftp, its does exactly what i want.

Problem im facing is, how do i put this new zImage instead of
originally built zImage in final rootfs archive (tar.gz).

To clarify, upon a "bitbake create-my-fancy-image" i got in
tmp/deploy/images two zImage files, one without initramfs and one with
initramfs. When i inspect my rootfs.tar.gz /boot folder, i have zImage
inisde (symlink and DTB also).

I would like to replace somehow this zImage with initramfs version.
How do i do that?

Documentations talks only about this IMAGE_BUNDLE that is going to
merge kernel with initramfs, but i cant find any obvious way to get
this into rootfs, to replace somehow original zImage.

The best idea i have so far (that does not work) is to do something like this:

initramfs_postprocess() {
# NOTE: pseudo code
rm ${IMAGE_ROOTFS}/boot/zImage-custom*
unlink ${IMAGE_ROOTFS}/boot/zImage
# Im not sure how do i reference file from tmp/deploy/images, which
is my question number 2
cp zImage-initramfs-* to ${WORKDIR}/boot/zImage
}

ROOTFS_POSTPROCESS_COMMAND += "initramfs_postprocess; "

This above looks very dirty to me, but its best "idea" i have atm.

So, in my local.conf i have:
INITRAMFS_IMAGE_BUNDLE = "1" # means fuse kernel + initramfs

And in my main image recipe i have:
INITRAMFS_IMAGE = "initramfs-custom" #name of the recipe that provides
some custom /init
INITRAMFS_FSTYPES = "cpio.gz" # make a compressed cpio out of initramfs

One thing to note, im trying to avoid doing this with wks and creating
a special /boot partition. This is not something im really targeting,
i know its possible, but i want to have my kernel inside rootfs.tar.gz
in /boot from single image recipe due the various reasons.

Any suggestion is much appreciated.

Regards,
Sinisa


Re: [meta-mingw][PATCH] gettext: adapt for version 0.20

Alexander Kanavin
 

On Fri, 29 Nov 2019 at 16:24, Joshua Watt <jpewhacker@...> wrote:
On Thu, Nov 28, 2019 at 11:47 AM Alexander Kanavin
<alex.kanavin@...> wrote:
>
> Drop backported patch (new gettext includes the updates).
>
> Drop version from the .bbappend (hopefully no version-specific
> tweaks will be needed going forward).

I've applied this to master-next, we can pull up master once the
oe-core patch lands. I'm assuming this will break the current master
AB builds if it's applied to master without the oe-core patch?

It probably will, yes (I didn't test, but it drops a patch that's apparently needed in 0.19).

Alex

 
>
> Signed-off-by: Alexander Kanavin <alex.kanavin@...>
> ---
>  .../fix-gl_cv_prog_as_underscore-test.patch   | 67 -------------------
>  ...ext_0.19.%.bbappend => gettext_%.bbappend} |  1 -
>  2 files changed, 68 deletions(-)
>  delete mode 100644 recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
>  rename recipes-core/gettext/{gettext_0.19.%.bbappend => gettext_%.bbappend} (87%)
>
> diff --git a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch b/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
> deleted file mode 100644
> index 636789f..0000000
> --- a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
> +++ /dev/null
> @@ -1,67 +0,0 @@
> -Backport gnulib fix for mingw into gettext's included version of gnulib
> -
> -http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=68b6adebef05670a312fb92b05e7bd089d2ed43a
> -
> -Upstream-Status: Backport
> -Signed-off-by: Nathan Rossi <nathan@...>
> -
> ---- a/gettext-runtime/gnulib-m4/asm-underscore.m4
> -+++ b/gettext-runtime/gnulib-m4/asm-underscore.m4
> -@@ -27,11 +27,11 @@
> - #endif
> - int foo(void) { return 0; }
> - EOF
> -      # Look for the assembly language name in the .s file.
> -      AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
> --     if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
> -+     if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
> -        gl_cv_prog_as_underscore=yes
> -      else
> -        gl_cv_prog_as_underscore=no
> -      fi
> -      rm -f conftest*
> ---- a/gettext-runtime/configure
> -+++ b/gettext-runtime/configure
> -@@ -24601,11 +24601,11 @@
> -   { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> -   (eval $ac_try) 2>&5
> -   ac_status=$?
> -   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> -   test $ac_status = 0; }; } >/dev/null 2>&1
> --     if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
> -+     if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
> -        gl_cv_prog_as_underscore=yes
> -      else
> -        gl_cv_prog_as_underscore=no
> -      fi
> -      rm -f conftest*
> ---- a/gettext-tools/gnulib-m4/asm-underscore.m4
> -+++ b/gettext-tools/gnulib-m4/asm-underscore.m4
> -@@ -27,11 +27,11 @@
> - #endif
> - int foo(void) { return 0; }
> - EOF
> -      # Look for the assembly language name in the .s file.
> -      AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
> --     if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
> -+     if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
> -        gl_cv_prog_as_underscore=yes
> -      else
> -        gl_cv_prog_as_underscore=no
> -      fi
> -      rm -f conftest*
> ---- a/gettext-tools/configure
> -+++ b/gettext-tools/configure
> -@@ -32284,11 +32284,11 @@
> -   { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> -   (eval $ac_try) 2>&5
> -   ac_status=$?
> -   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> -   test $ac_status = 0; }; } >/dev/null 2>&1
> --     if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
> -+     if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
> -        gl_cv_prog_as_underscore=yes
> -      else
> -        gl_cv_prog_as_underscore=no
> -      fi
> -      rm -f conftest*
> diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend b/recipes-core/gettext/gettext_%.bbappend
> similarity index 87%
> rename from recipes-core/gettext/gettext_0.19.%.bbappend
> rename to recipes-core/gettext/gettext_%.bbappend
> index 21749f3..d518698 100644
> --- a/recipes-core/gettext/gettext_0.19.%.bbappend
> +++ b/recipes-core/gettext/gettext_%.bbappend
> @@ -2,7 +2,6 @@ EXTRA_OECONF_append_mingw32 = " --enable-static"
>
>  FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
>  SRC_URI_append_mingw32 = " \
> -               file://fix-gl_cv_prog_as_underscore-test.patch \
>                 "
>
>  FILES_libgettextlib_mingw32 = "${bindir}/libgettextlib-*.dll"
> --
> 2.17.1
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#47462): https://lists.yoctoproject.org/g/yocto/message/47462
> Mute This Topic: https://lists.yoctoproject.org/mt/64260047/3616693
> Group Owner: yocto+owner@...
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [JPEWhacker@...]
> -=-=-=-=-=-=-=-=-=-=-=-


Re: [patchtest][PATCH 1/2] patchtest: Fix printing of exception tracebacks

 

On Fri, 15 Nov 2019, at 13:23, Paul Barker wrote:
The addError() handler is called outside of an actual exception handler
so sys.exc_info() doesn't actually return an exception. This means that
traceback.print_exc() doesn't know what to print. Instead we need to use
traceback.print_exception() with the err object we've been given.

Signed-off-by: Paul Barker <paul@betafive.co.uk>
---
patchtest | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/patchtest b/patchtest
index 592f73e..59b19f5 100755
--- a/patchtest
+++ b/patchtest
@@ -101,8 +101,7 @@ def getResult(patch, mergepatch):

def addError(self, test, err):
self.test_error = True
- (ty, va, trace) = err
- logger.error(traceback.print_exc())
+ logger.error(traceback.print_exception(*err))

def addFailure(self, test, err):
self.test_failure = True
--
2.17.1

Ping on this and the following patch.

--
Paul Barker


Re: [patchtest-oe][PATCH] test_patch_upstream_status: Be explicit about case sensitivity

 

On Fri, 15 Nov 2019, at 13:09, Paul Barker wrote:
The case sensitivity of the checks for the "Upstream-Status" label
should match so that failure messages make sense. The checks in the
parse_upstream_status module are case sensitive and so the initial regex
check should also be made case sensitive.

A quick note about case sensitivity is added to the advice given if
"Upstream-Status" is not found.

Signed-off-by: Paul Barker <paul@betafive.co.uk>
---
tests/test_patch_upstream_status.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test_patch_upstream_status.py
b/tests/test_patch_upstream_status.py
index a477dfb..ecccc58 100644
--- a/tests/test_patch_upstream_status.py
+++ b/tests/test_patch_upstream_status.py
@@ -23,7 +23,7 @@ import os

class PatchUpstreamStatus(base.Base):

- upstream_status_regex = re.compile("(?<=\+)Upstream.Status", re.IGNORECASE)
+ upstream_status_regex = re.compile("(?<=\+)Upstream.Status")

@classmethod
def setUpClassLocal(cls):
@@ -47,7 +47,7 @@ class PatchUpstreamStatus(base.Base):
payload = newpatch.__str__()
if not self.upstream_status_regex.search(payload):
self.fail('Added patch file is missing Upstream-Status
in the header',
- 'Add Upstream-Status: <Valid status> to the
header of %s' % newpatch.path,
+ 'Add Upstream-Status: <Valid status> (case
sensitive) to the header of %s' % newpatch.path,
data=[('Standard format',
self.standard_format), ('Valid status', self.valid_status)])
for line in payload.splitlines():
if self.patchmetadata_regex.match(line):
--
2.17.1

Ping.

--
Paul Barker


Re: [meta-mingw][PATCH] gettext: adapt for version 0.20

Joshua Watt
 

On Thu, Nov 28, 2019 at 11:47 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:

Drop backported patch (new gettext includes the updates).

Drop version from the .bbappend (hopefully no version-specific
tweaks will be needed going forward).
I've applied this to master-next, we can pull up master once the
oe-core patch lands. I'm assuming this will break the current master
AB builds if it's applied to master without the oe-core patch?


Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
.../fix-gl_cv_prog_as_underscore-test.patch | 67 -------------------
...ext_0.19.%.bbappend => gettext_%.bbappend} | 1 -
2 files changed, 68 deletions(-)
delete mode 100644 recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
rename recipes-core/gettext/{gettext_0.19.%.bbappend => gettext_%.bbappend} (87%)

diff --git a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch b/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
deleted file mode 100644
index 636789f..0000000
--- a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-Backport gnulib fix for mingw into gettext's included version of gnulib
-
-http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=68b6adebef05670a312fb92b05e7bd089d2ed43a
-
-Upstream-Status: Backport
-Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
-
---- a/gettext-runtime/gnulib-m4/asm-underscore.m4
-+++ b/gettext-runtime/gnulib-m4/asm-underscore.m4
-@@ -27,11 +27,11 @@
- #endif
- int foo(void) { return 0; }
- EOF
- # Look for the assembly language name in the .s file.
- AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-runtime/configure
-+++ b/gettext-runtime/configure
-@@ -24601,11 +24601,11 @@
- { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; } >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-tools/gnulib-m4/asm-underscore.m4
-+++ b/gettext-tools/gnulib-m4/asm-underscore.m4
-@@ -27,11 +27,11 @@
- #endif
- int foo(void) { return 0; }
- EOF
- # Look for the assembly language name in the .s file.
- AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-tools/configure
-+++ b/gettext-tools/configure
-@@ -32284,11 +32284,11 @@
- { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; } >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend b/recipes-core/gettext/gettext_%.bbappend
similarity index 87%
rename from recipes-core/gettext/gettext_0.19.%.bbappend
rename to recipes-core/gettext/gettext_%.bbappend
index 21749f3..d518698 100644
--- a/recipes-core/gettext/gettext_0.19.%.bbappend
+++ b/recipes-core/gettext/gettext_%.bbappend
@@ -2,7 +2,6 @@ EXTRA_OECONF_append_mingw32 = " --enable-static"

FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
SRC_URI_append_mingw32 = " \
- file://fix-gl_cv_prog_as_underscore-test.patch \
"

FILES_libgettextlib_mingw32 = "${bindir}/libgettextlib-*.dll"
--
2.17.1

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

View/Reply Online (#47462): https://lists.yoctoproject.org/g/yocto/message/47462
Mute This Topic: https://lists.yoctoproject.org/mt/64260047/3616693
Group Owner: yocto+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [JPEWhacker@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: Private: Re: [yocto] source.list for apt tool in yocto image for raspberry pi #yocto #raspberrypi #debian #apt

Josef Holzmayr <holzmayr@...>
 

On Fri, Nov 29, 2019 at 04:29:59AM -0800, keyurthumar0402@gmail.com wrote:
On Fri, Nov 29, 2019 at 04:23 AM, Josef Holzmayr wrote:


use it like a debian, and think it should behave like a debian, then you
Hey thank you for the reply.

I don't want to use any runtime package manager. But some packages i am not able to add in image. Like *linux-gpib* driver for NI GPIB-USB-HS. How would i do that ?
You have to write recipes, then. Please see: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

(And keep the threads on-list please.)

Greetz

--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Re: source.list for apt tool in yocto image for raspberry pi #yocto #raspberrypi #debian #apt

Josef Holzmayr <holzmayr@...>
 

On Fri, Nov 29, 2019 at 03:56:41AM -0800, keyurthumar0402@gmail.com wrote:

There is a lot of things confused in here, it seems.

I Have built yocto image for raspberry pi.
Ok. Congratulations!

It is debian based and...
You mean, you set packege PACKAGE_CLASSES ?= "package_deb"?

...apt is already installed.
...which in the end is juut a binary.

What should i write in source.list ? As I don' t have my personal repository please suggest some standard repository.
There is none. The standard practise is to build the image with all the
things you need, and not use runtime package management. If you want to
use it like a debian, and think it should behave like a debian, then you
probably should just run debian.

Yocto builds a custom distribution, therefore no "official" packages
exist.

Greetz.

--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


source.list for apt tool in yocto image for raspberry pi #yocto #raspberrypi #debian #apt

keyurthumar0402@...
 

I Have built yocto image for raspberry pi. It is debian based and apt is already installed. What should i write in source.list ? As I don' t have my personal repository please suggest some standard repository.


Re: Private: Re: [yocto] Which layer is best for tpm2 stack

Maciej Pijanowski
 


On 29.11.2019 11:01, Diego Santa Cruz via Lists.Yoctoproject.Org wrote:

Dear all,

 

I got the feedback below by private email (was meant to be sent to the m-l), so I think I’ll go with meta-tmp2 from meta-secure-core for now.

 

But I may switch to meta-tpm from meta-security in the future as it seems to have more tpm2 related recipes (I’m on thud for now and the tpm2-tools in thud branch of meta-security is too old).

 

Any other feedback from the community?

I'm currently using meta-tpm from meta-security for tpm2-tools.
My reasoning was that this one will likely be the one to go in the long run since it's hosted on the poky git (?).

 

Thanks,

 

Diego

 

--
Diego Santa Cruz, PhD
Technology Architect
T +41 21 341 15 50
diego.santacruz@... | Subscribe to our Newlsetter

spinetix.com

 

From: Dan O'Donovan via Lists.Yoctoproject.Org <dan=emutex.com@...>
Sent: 28 November 2019 12:00
To: Diego Santa Cruz <Diego.SantaCruz@...>
Subject: Private: Re: [yocto] Which layer is best for tpm2 stack

 

On Wed, Nov 27, 2019 at 02:56 PM, Diego Santa Cruz wrote:

Hello,

 

I need to use a TPM2 software stack for my project (tpm2-tools, tpm2-abrmd, tpm2-tss, etc.), where I am already using Yocto, meta-intel, meta-oe, meta-networking, etc.

 

I see there are at least the following three layers that carry the necessary TPM2 bits, with varying recipe versions.

 

My current objective is to use the TPM2 as a security chip from our software (in the future we may extend its use to root fs encryption keys and the like). Are there any recommendations as to which of these layers would be more appropriate, is better maintained, etc.?

I've personally used the meta-tpm2 layer in meta-secure-core repo with good success on both Intel and ARM platforms with Infineon TPM chips.  In particular, I used the cryptfs-tpm2 and secure-core initramfs recipes from that layer for managing root fs encryption.  IIRC, this layer seemed to offer the best support for what we needed regarding TPM2 on Yocto 'Sumo' at the time.

I haven't really looked at the other layers recently so I can't give a comparison with those.  However, I did notice a significant amount of activity via the mailing list related to TPM2 support for the meta-security repo in recent weeks, so that's probably worth a look too.

 

 

BTW, the meta-tpm layer in meta-security repo is not listed in the OpenEmbedded Layer index, although meta-security itself and some of the other layers in that repo are listed. Is that because of a name clash with the ones under the meta-secure-core repo, which also carries layers named meta-tpm and meta-integrity?

 

Thanks,

 

Diego

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 


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

View/Reply Online (#47463): https://lists.yoctoproject.org/g/yocto/message/47463
Mute This Topic: https://lists.yoctoproject.org/mt/64331549/3616795
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [maciej.pijanowski@...]
-=-=-=-=-=-=-=-=-=-=-=-
-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: F1401D2E1CCB19EF
https://3mdeb.com | @3mdeb_com


Re: Private: Re: [yocto] Which layer is best for tpm2 stack

Diego Santa Cruz
 

Dear all,

 

I got the feedback below by private email (was meant to be sent to the m-l), so I think I’ll go with meta-tmp2 from meta-secure-core for now.

 

But I may switch to meta-tpm from meta-security in the future as it seems to have more tpm2 related recipes (I’m on thud for now and the tpm2-tools in thud branch of meta-security is too old).

 

Any other feedback from the community?

 

Thanks,

 

Diego

 

--
Diego Santa Cruz, PhD
Technology Architect
T +41 21 341 15 50
diego.santacruz@... | Subscribe to our Newlsetter

spinetix.com

 

From: Dan O'Donovan via Lists.Yoctoproject.Org <dan=emutex.com@...>
Sent: 28 November 2019 12:00
To: Diego Santa Cruz <Diego.SantaCruz@...>
Subject: Private: Re: [yocto] Which layer is best for tpm2 stack

 

On Wed, Nov 27, 2019 at 02:56 PM, Diego Santa Cruz wrote:

Hello,

 

I need to use a TPM2 software stack for my project (tpm2-tools, tpm2-abrmd, tpm2-tss, etc.), where I am already using Yocto, meta-intel, meta-oe, meta-networking, etc.

 

I see there are at least the following three layers that carry the necessary TPM2 bits, with varying recipe versions.

 

My current objective is to use the TPM2 as a security chip from our software (in the future we may extend its use to root fs encryption keys and the like). Are there any recommendations as to which of these layers would be more appropriate, is better maintained, etc.?

I've personally used the meta-tpm2 layer in meta-secure-core repo with good success on both Intel and ARM platforms with Infineon TPM chips.  In particular, I used the cryptfs-tpm2 and secure-core initramfs recipes from that layer for managing root fs encryption.  IIRC, this layer seemed to offer the best support for what we needed regarding TPM2 on Yocto 'Sumo' at the time.

I haven't really looked at the other layers recently so I can't give a comparison with those.  However, I did notice a significant amount of activity via the mailing list related to TPM2 support for the meta-security repo in recent weeks, so that's probably worth a look too.

 

 

BTW, the meta-tpm layer in meta-security repo is not listed in the OpenEmbedded Layer index, although meta-security itself and some of the other layers in that repo are listed. Is that because of a name clash with the ones under the meta-secure-core repo, which also carries layers named meta-tpm and meta-integrity?

 

Thanks,

 

Diego

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 


[meta-mingw][PATCH] gettext: adapt for version 0.20

Alexander Kanavin
 

Drop backported patch (new gettext includes the updates).

Drop version from the .bbappend (hopefully no version-specific
tweaks will be needed going forward).

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
.../fix-gl_cv_prog_as_underscore-test.patch | 67 -------------------
...ext_0.19.%.bbappend => gettext_%.bbappend} | 1 -
2 files changed, 68 deletions(-)
delete mode 100644 recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
rename recipes-core/gettext/{gettext_0.19.%.bbappend => gettext_%.bbappend} (87%)

diff --git a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch b/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
deleted file mode 100644
index 636789f..0000000
--- a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-Backport gnulib fix for mingw into gettext's included version of gnulib
-
-http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=68b6adebef05670a312fb92b05e7bd089d2ed43a
-
-Upstream-Status: Backport
-Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
-
---- a/gettext-runtime/gnulib-m4/asm-underscore.m4
-+++ b/gettext-runtime/gnulib-m4/asm-underscore.m4
-@@ -27,11 +27,11 @@
- #endif
- int foo(void) { return 0; }
- EOF
- # Look for the assembly language name in the .s file.
- AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-runtime/configure
-+++ b/gettext-runtime/configure
-@@ -24601,11 +24601,11 @@
- { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; } >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-tools/gnulib-m4/asm-underscore.m4
-+++ b/gettext-tools/gnulib-m4/asm-underscore.m4
-@@ -27,11 +27,11 @@
- #endif
- int foo(void) { return 0; }
- EOF
- # Look for the assembly language name in the .s file.
- AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
---- a/gettext-tools/configure
-+++ b/gettext-tools/configure
-@@ -32284,11 +32284,11 @@
- { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
- test $ac_status = 0; }; } >/dev/null 2>&1
-- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then
-+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then
- gl_cv_prog_as_underscore=yes
- else
- gl_cv_prog_as_underscore=no
- fi
- rm -f conftest*
diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend b/recipes-core/gettext/gettext_%.bbappend
similarity index 87%
rename from recipes-core/gettext/gettext_0.19.%.bbappend
rename to recipes-core/gettext/gettext_%.bbappend
index 21749f3..d518698 100644
--- a/recipes-core/gettext/gettext_0.19.%.bbappend
+++ b/recipes-core/gettext/gettext_%.bbappend
@@ -2,7 +2,6 @@ EXTRA_OECONF_append_mingw32 = " --enable-static"

FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
SRC_URI_append_mingw32 = " \
- file://fix-gl_cv_prog_as_underscore-test.patch \
"

FILES_libgettextlib_mingw32 = "${bindir}/libgettextlib-*.dll"
--
2.17.1


Re: Architecture of .wic approach; image of images

Leon Woestenberg
 


On Thu, Nov 28, 2019 at 10:01 AM Josef Holzmayr <holzmayr@...> wrote:
On Thu, Nov 28, 2019 at 09:37:12AM +0100, Leon Woestenberg wrote:

> The .wic image type however, builds an image from *images* rather than
> packages.

Thats *almost* correct. It builds an image from a *artifacts*.

My finding is: ...only if *artifacts* (also) includes a rootfs.

The image class dependency on rootfs seems very hardcoded. I cannot create a recipe that works without *creating* a rootfs.
(even though I have no rootfs other than the initramfs image which is already there, as an *artifact*).

inherit image

IMAGE_FSTYPES = "wic"
DEPENDS += "my-initramfs"

IMAGE_FEATURES = ""
IMAGE_INSTALL = ""

# This image does not generate its own root filesystem
# I have tried to exclude it, but it's hardcoded even in buildhistory.
#do_rootfs[noexec] = "1"
#do_image[noexec] = "1"
#do_image_wic[noexec] = "1"
#do_rootfs_wicenv[noexec] = "1"


WKS_FILE = "my-disk-image.wks"
my-disk-image.wks:
part /boot --source bootimg-efi
--sourceparams="loader=grub-efi,initrd=my-initramfs.cpio.gz" --ondisk
sda --label msdos --active --align 1024 --use-uuid
bootloader --ptable gpt --timeout=1



Re: Yocto Image Build for NXP i.MX8M

Aj Cit
 

Hello,

I'm getting the following error when I have tried to simulate the image on QEMU

adminuser@verathon:~/poky/build$ runqemu qemux86
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - ERROR - /home/adminuser/poky/build/tmp/deploy/images/qemux86 not a directory valid DEPLOY_DIR_IMAGE
ls: cannot access '/home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf': No such file or directory
runqemu - ERROR - Command 'ls -t /home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf' returned non-zero exit status 2.
runqemu - INFO - Cleaning up


any help would be appreciated.

tnQ

On Thu, Nov 28, 2019 at 5:33 PM Aj Cit via Lists.Yoctoproject.Org <aj.ci.01.239=gmail.com@...> wrote:

Dear Josef,

I've managed to run build command to generate OS image for the target, which is core-image-sato by executing the following command:

     $ bitbake core-image-sato
Can I know how to proceed further?

I'm getting the following response from the Ubuntu 18.04.1 LTS

Loading cache: 100% |#########################################################################################################| Time: 0:00:00
Loaded 1264 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.40.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "2.6.2"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "HEAD:e7f0177ef3b6e06b8bc1722fca0241fef08a1530"

Initialising tasks: 100% |#########################################################################################################| Time: 0:00:02
Checking sstate mirror object availability: 100% |######################################################################################| Time: 0:05:55
Sstate summary: Wanted 1402 Found 329 Missed 2146 Current 708 (23% match, 49% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: sudo-1.8.23-r0 do_fetch: Failed to fetch URL http://ftp.sudo.ws/sudo/dist/sudo-1.8.23.tar.gz, attempting MIRRORS if available
NOTE: Tasks Summary: Attempted 5774 tasks of which 2941 didn't need to be rerun and all succeeded.

Summary: There was 1 WARNING message shown.
adminuser@verathon:~/poky/build$ ls
bitbake-cookerdaemon.log  cache  conf  downloads  sstate-cache  tmp
adminuser@verathon:~/poky/build$ runqemu qemux86
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - ERROR - /home/adminuser/poky/build/tmp/deploy/images/qemux86 not a directory valid DEPLOY_DIR_IMAGE
ls: cannot access '/home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf': No such file or directory
runqemu - ERROR - Command 'ls -t /home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf' returned non-zero exit status 2.
runqemu - INFO - Cleaning up
adminuser@verathon:~/poky/build$


Thanks,

Ajith

On Thu, Nov 28, 2019 at 2:34 PM Josef Holzmayr <holzmayr@...> wrote:
On Thu, Nov 28, 2019 at 02:29:08PM +0530, Aj Cit wrote:
> Hi Josef,
>
> Is there specific steps to be followed to build an image for iMX8M?

You need at least a board support (BSP) layer. As I have no clue about
your board, I can only guess that it will probably something freescale
related, mabye https://git.yoctoproject.org/cgit.cgi/meta-freescale/

But first and absolutely foremost:
1) watch the introductory videos
2) consult the documentation of your board vendor.

Greetz

>
> Tnx
> Ajith
>
> On Thu, Nov 28, 2019 at 2:23 PM Josef Holzmayr <
> holzmayr@...> wrote:
>
> > On Thu, Nov 28, 2019 at 02:02:29PM +0530, Aj Cit wrote:
> > > I've followed the instruction from the yocto project:
> > >
> > https://www.yoctoproject.org/docs/3.0/brief-yoctoprojectqs/brief-yoctoprojectqs.html
> >
> > This can not be exactly true, as this guide certainly does not include
> > anything related to the imx8. So you are either still building for qemu
> > (as it defaults to), or using seomthing additional that you're not
> > mentioning.
> >
> > >
> > >
> > > till the bitbake command. However, I'm getting the following error:
> > > ERROR:  OE-core's config sanity checker detected a potential
> > > misconfiguration.
> > >     Either fix the cause of this error or at your own risk disable the
> > > checker (see sanity.conf).
> > >     Following is the list of potential problems / advisories:
> > >
> > >     Do not use Bitbake as root.
> >
> > Here is your answer: do not run botbake as the root user :)
> >
> > In a nutshell, I recommend watching at least the first couple of videos
> > here:
> > https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj
> >
> > Greetz
> > >
> > >
> > > On Thu, Nov 28, 2019 at 12:29 PM Aj Cit <aj.ci.01.239@...> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm trying to build a Yocto image for NXP i.MX8M (4 core 64-bit A53s).
> > I
> > > > am getting some error when I execute the bitmake command.
> > > >
> > > > I'd appreciate if you could guide me with next steps. Any Guide or url
> > > > will be helpful.
> > > >
> > > > Thanks
> > > > Ajith
> > > >
> >
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > Links: You receive all messages sent to this group.
> > >
> > > View/Reply Online (#47444):
> > https://lists.yoctoproject.org/g/yocto/message/47444
> > > Mute This Topic: https://lists.yoctoproject.org/mt/63894854/3618269
> > > Group Owner: yocto+owner@...
> > > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [
> > holzmayr@...]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> >
> >
> > --
> > ———————————————
> > Josef Holzmayr
> > Software Developer Embedded Systems
> >
> > Tel: +49 8444 9204-48
> > Fax: +49 8444 9204-50
> >
> > R-S-I Elektrotechnik GmbH & Co. KG
> > Woelkestrasse 11
> > D-85301 Schweitenkirchen
> > www.rsi-elektrotechnik.de
> > ———————————————
> > Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
> > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> > Ust-IdNr: DE 128592548
> >
> > _____________________________________________________________
> > Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
> > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> > USt-IdNr.: DE 128592548
> >
> >

--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

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

View/Reply Online (#47455): https://lists.yoctoproject.org/g/yocto/message/47455
Mute This Topic: https://lists.yoctoproject.org/mt/63894854/3738872
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [aj.ci.01.239@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: Architecture of .wic approach; image of images

Leon Woestenberg
 

On Thu, Nov 28, 2019 at 1:52 PM Josef Holzmayr
<holzmayr@rsi-elektrotechnik.de> wrote:

On Thu, Nov 28, 2019 at 01:32:56PM +0100, Leon Woestenberg wrote:
- Does Yocto support building multiple images from one configuration?
Of course it does. If you have set DISTRO and MACHINE, you can
bitbake core-image-minimal
bitbake core-image-x11
bitbake ... whatever image.

Thats exactly the point of the MACHINE / DISTRO / IMAGE seperation.
Yes, up to there everything is clean and nice.
And I understand I can build multiple images. I have used this feature
since 2006.

My point is, that we do not support images of images correctly. Or, I
do not understand how it works.

If I have an initramfs image, my next step is to build a disk image
that has the initramfs.cpio.gz, but without generating a new rootfs.

How would I do that?

7981 - 8000 of 55458