date:20190502

Re: [yocto] Multiple ubifs partition

2019-05-02 Thread Ulrich Ölmann

Hi Gabriele,

On Thu, May 02 2019 at 13:25 +0200, Gabriele Zampieri  
wrote:
> ok, I guess I miss-understand how that class works. I thought that I
> had to add the customization on my own image recipe.
> So the correct way is to write a 'customization recipe' and install
> via IMAGE_INSTALL? Can you provide an example?

use your custom image recipe as before to just produce your root-
filesystem which results in a (compressed) tar-file in ${DEPLOY_DIR_
IMAGE}. It will be referenced from the genimage recipe without any file
extension via GENIMAGE_ROOTFS_IMAGE. Now your UBI-recipe (e.g. 'your-
customized-ubi.bb') could look like

inherit genimage
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI += "file://genimage.config"

# to not confuse the flashable UBI-image ('ubi')
# with the UBI-filesystems ('ubifs') it contains
GENIMAGE_IMAGE_SUFFIX = "ubi"

# the name of the root-filesystem genimage should use
GENIMAGE_ROOTFS_IMAGE = "your-customized-rootfs"

with the accompanying 'genimage.config' for example as follows

#
# Manufacturer ID: 0x2c, Chip ID: 0xda
# -> Micron MT29F2G08ABAEAWP
# 256 MiB, SLC
#
flash nand {
pebsize = 131072
lebsize = 126976
numpebs = 2044
minimum-io-unit-size = 2048
sub-page-size = 2048
}

image @IMAGE@ {
flashtype = "nand"
ubi {
}

partition rootfs {
image = rootfs.ubifs
size = 64MiB
}

partition opt {
image = opt.ubifs
size = 32MiB
}

partition data {
image = data.ubifs
autoresize = true
}
}

image rootfs.ubifs {
flashtype = "nand"
ubifs {
extraargs = "-x lzo"
max-size = 64MiB
}
mountpoint = "/"
}

image opt.ubifs {
flashtype = "nand"
ubifs {
extraargs = "-x lzo"
max-size = 32MiB
}
mountpoint = "/opt"
}

image data.ubifs {
flashtype = "nand"
ubifs {
extraargs = "-x lzo"
max-size = 192MiB
}
mountpoint = "/data"
}

In a UBI-image almost all UBI-volumes need to have a fixed size and only
one is allowed to use the autoresize mechanism which blows it up to use
the remaining space when it is UBI-attached for the first time. Distinct
from that is the UBI-filesystem's max-size parameter which prescribes
the maximum size of an UBI-volume that shall be addressable by this
filesystem. This means that if you would re-use 'data.ubifs' in a volume
that has been autoresized to e.g. 1024MiB the filesystem would not be
able to make use of it.

I neither tested the recipe nor the genimage.config, so please give some
feedback.

Best regards
Ulrich


> Thanks,
> Gabriele
>
> Il giorno mer 24 apr 2019 alle ore 15:15 Ulrich Ölmann <
> u.oelm...@pengutronix.de> ha scritto:
>
>> Hi Gabriele,
>>
>> On Wed, Apr 24 2019 at 14:06 +0200, Gabriele Zampieri <
>> gabbla.mal...@gmail.com> wrote:
>> > I'm now testing genimage via meta-ptx in my Yocto workflow, but I found a
>> > problem: I cannot set a SRC_URI in my custom image recipe (that inherit
>> > from core-image which in turn inherit from image) because do_fetch and
>> > do_unpack tasks have noexec set to 1. If I specify the SRC_URI with my
>> > genimage.config, bitbake exits, complaining about LIC_FILE_CHECKSUM (that
>> > is correctly specified). If I hack image.bbclass and comment out
>> >
>> > #do_fetch[noexec] = "1"
>> >
>> >
>> > #do_unpack[noexec] = "1"
>> >
>> > The process start correctly. Is there a way to avoid touching
>> image.bbclass
>> > and install my configuration from the image recipe?
>> >
>> > Thanks,
>> > Gabriele
>>
>> you need one or more recipe(s) that construct(s) your filesystem(s) and
>> a separate one that makes a flashable image out of that (see the
>> introductory documentation in 'genimage.bbclass'). In the former you
>> inherit 'core-image' and only in the latter which inherits 'genimage'
>> you have to set the SRC_URI to point to your 'genimage.config'.
>>
>> Best regards
>> Ulrich
>>
>>
>> > Il giorno mer 13 mar 2019 alle ore 16:14 Gabriele Zampieri <
>> > gabbla.mal...@gmail.com> ha scritto:
>> >
>> >> Hi all,
>> >>
>> >> thank you very much for the suggestion, I will check genimage and test
>> it.
>> >>
>> >> Gabriele
>> >>
>> >> Il giorno gio 7 mar 2019 alle ore 16:23 Ulrich Ölmann <
>> >> u.oelm...@pengutronix.de> ha scritto:
>> >>
>> >>> Hi there,
>> >>>
>> >>> On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten <
>> >>> carsten.stelli...@goerlitz.com> wrote:
>> >>> > Have you seen https://github.com/pengutronix/genimage?
>> >>>
>> >>> you can find it included within
>> https://github.com/pengutronix/meta-ptx
>> >>> with an accompanying

[yocto] Yocto concept and support for dual version firmware upgrad and boot

2019-05-02 Thread JH

Hi,

Are there any Yocto recipes to support dual version control for
firmware image upgrade and boot?

The scenario is to make 2 partitions, one partition to install a work
version of image, say v1.0, another partition to install a development
version of image, say v1.1, the boot process should pick up the
highest the version v1.1 first, if it fails to boot, it retreats back
to boot old version v1.0.

Appreciate any tips or reference for that implementation in Yocto.

Thank you.

Kind regards,

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

[yocto] [meta-security][PATCH 2/2] apparmor: fix fragment for 5.0 kernel

2019-05-02 Thread Armin Kuster

Signed-off-by: Armin Kuster 
---
 recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg | 6 --
 1 file changed, 6 deletions(-)

diff --git a/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg 
b/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg
index b5f9bb2..ae6cdcd 100644
--- a/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg
+++ b/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg
@@ -1,15 +1,9 @@
 CONFIG_AUDIT=y
-# CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
-CONFIG_SECURITY_NETWORK=y
-# CONFIG_SECURITY_NETWORK_XFRM is not set
 CONFIG_SECURITY_PATH=y
-# CONFIG_SECURITY_SELINUX is not set
 CONFIG_SECURITY_APPARMOR=y
 CONFIG_SECURITY_APPARMOR_HASH=y
 CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
-# CONFIG_SECURITY_APPARMOR_DEBUG is not set
 CONFIG_INTEGRITY_AUDIT=y
 CONFIG_DEFAULT_SECURITY_APPARMOR=y
-# CONFIG_DEFAULT_SECURITY_DAC is not set
 CONFIG_DEFAULT_SECURITY="apparmor"
 CONFIG_AUDIT_GENERIC=y
-- 
2.17.1

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

[yocto] [meta-security][PATCH 1/2] libseccomp: update to 2.4.1

2019-05-02 Thread Armin Kuster

bug fix release.

Signed-off-by: Armin Kuster 
---
 .../libseccomp/{libseccomp_2.4.0.bb => libseccomp_2.4.1.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename recipes-security/libseccomp/{libseccomp_2.4.0.bb => 
libseccomp_2.4.1.bb} (96%)

diff --git a/recipes-security/libseccomp/libseccomp_2.4.0.bb 
b/recipes-security/libseccomp/libseccomp_2.4.1.bb
similarity index 96%
rename from recipes-security/libseccomp/libseccomp_2.4.0.bb
rename to recipes-security/libseccomp/libseccomp_2.4.1.bb
index 41ffd62..dba1be5 100644
--- a/recipes-security/libseccomp/libseccomp_2.4.0.bb
+++ b/recipes-security/libseccomp/libseccomp_2.4.1.bb
@@ -4,7 +4,7 @@ SECTION = "security"
 LICENSE = "LGPL-2.1"
 LIC_FILES_CHKSUM = 
"file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"
 
-SRCREV = "4d64011741375bb1a4ba7d71905ca37b97885083"
+SRCREV = "fb43972ea1aab24f2a70193fb7445c2674f594e3"
 
 SRC_URI = "git://github.com/seccomp/libseccomp.git;branch=release-2.4 \
file://run-ptest \
-- 
2.17.1

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

[yocto] [meta-cgl][PATCH 3/3] packagegroup-cgl-middleware: remove openais

2019-05-02 Thread Armin Kuster

Signed-off-by: Armin Kuster 
---
 meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb 
b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
index cd97fec..6ec68c4 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
@@ -43,7 +43,6 @@ RDEPENDS_packagegroup-cgl-middleware = "\
 vlan \
 corosync \
  ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "iscsi-initiator-utils", 
"",d)} \
-openais \
 openipmi \
 openhpi \
 pacemaker \
-- 
2.7.4

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

[yocto] [meta-cgl][PATCH 2/3] openais: remove as corosync 2.x replaces functionality

2019-05-02 Thread Armin Kuster

corosync 2.x can replace corosync 1.x + openais.

openais is no longer maintainted and shutdown.
https://github.com/corosync/openais/commit/f2bc4445a7c4ba5d17a218af855dc19d55ed2803

Signed-off-by: Armin Kuster 
---
 .../openais/files/build-cleanup-configure-ac.patch | 41 -
 .../openais/files/fix-lcrso-linkage.patch  | 21 -
 .../openais/files/openais-fix-bash.patch   | 10 
 .../files/openais-fix-corosync-not-quit.patch  | 53 --
 .../openais/files/openais-fix-init-script.patch| 42 -
 .../files/openais-fix-resource-cleanup-entry.patch | 37 ---
 .../openais-saTmrTimerReschedule-test-error.patch  | 50 
 .../recipes-cgl/openais/files/openais.service  | 14 --
 .../recipes-cgl/openais/openais_1.1.4.bb   | 35 --
 9 files changed, 303 deletions(-)
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/build-cleanup-configure-ac.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/fix-lcrso-linkage.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-bash.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-init-script.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-fix-resource-cleanup-entry.patch
 delete mode 100644 
meta-cgl-common/recipes-cgl/openais/files/openais-saTmrTimerReschedule-test-error.patch
 delete mode 100644 meta-cgl-common/recipes-cgl/openais/files/openais.service
 delete mode 100644 meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb

diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/build-cleanup-configure-ac.patch 
b/meta-cgl-common/recipes-cgl/openais/files/build-cleanup-configure-ac.patch
deleted file mode 100644
index 48284ad..000
--- a/meta-cgl-common/recipes-cgl/openais/files/build-cleanup-configure-ac.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-diff -Naur a/configure.ac b/configure.ac
 a/configure.ac 2014-07-15 16:23:11.852805276 +0200
-+++ b/configure.ac 2014-07-15 16:36:00.483752038 +0200
-@@ -48,6 +48,7 @@
- AC_PROG_LN_S
- AC_PROG_MAKE_SET
- AC_PROG_RANLIB
-+AC_PROG_SED
- AC_CHECK_PROGS([GROFF], [groff])
- 
- # Checks for libraries.
-@@ -66,7 +67,7 @@
- AC_CHECK_HEADERS([arpa/inet.h fcntl.h limits.h netdb.h netinet/in.h stdint.h \
- stdlib.h string.h sys/ioctl.h sys/param.h sys/socket.h \
- sys/time.h syslog.h unistd.h sys/types.h getopt.h malloc.h \
--sys/sockio.h])
-+  sys/sockio.h utmpx.h ifaddrs.h stddef.h sys/file.h])
- 
- # Checks for typedefs, structures, and compiler characteristics.
- AC_C_CONST
-@@ -78,7 +79,6 @@
- AC_TYPE_INT8_T
- AC_TYPE_SIZE_T
- AC_TYPE_SSIZE_T
--AC_HEADER_TIME
- AC_TYPE_UINT16_T
- AC_TYPE_UINT32_T
- AC_TYPE_UINT64_T
-@@ -88,11 +88,11 @@
- # Checks for library functions.
- AC_FUNC_CLOSEDIR_VOID
- AC_FUNC_ERROR_AT_LINE
--AC_REPLACE_FNMATCH
- AC_FUNC_FORK
- AC_PROG_GCC_TRADITIONAL
- AC_FUNC_MALLOC
- AC_FUNC_MEMCMP
-+AC_FUNC_MMAP
- AC_FUNC_REALLOC
- AC_FUNC_SELECT_ARGTYPES
- AC_TYPE_SIGNAL
diff --git a/meta-cgl-common/recipes-cgl/openais/files/fix-lcrso-linkage.patch 
b/meta-cgl-common/recipes-cgl/openais/files/fix-lcrso-linkage.patch
deleted file mode 100644
index 9acfc20..000
--- a/meta-cgl-common/recipes-cgl/openais/files/fix-lcrso-linkage.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Index: openais-1.1.2/services/Makefile.am
-===
 openais-1.1.2.orig/services/Makefile.am2010-03-22 23:00:09.0 
+0300
-+++ openais-1.1.2/services/Makefile.am 2010-03-22 22:59:51.0 +0300
-@@ -78,13 +78,13 @@
- 
- else
- service_amf.lcrso: $(AMF_OBJECTS)
--  $(CC) $(CFLAGS) -shared -Wl,-soname=$@ $^ -o $@
-+  $(CC) $(CFLAGS) $(LDFLAGS) -shared -Wl,-soname=$@ $^ -o $@
- 
- service_%.lcrso: %.o
--  $(CC) $(CFLAGS) -shared -Wl,-soname=$@ $^ -o $@
-+  $(CC) $(CFLAGS) $(LDFLAGS) -shared -Wl,-soname=$@ $^ -o $@
- 
- %.lcrso: %.o
--  $(CC) $(CFLAGS) -shared -Wl,-soname=$@ $^ -o $@
-+  $(CC) $(CFLAGS) $(LDFLAGS) -shared -Wl,-soname=$@ $^ -o $@
- endif
- 
- %.o: %.c
diff --git a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-bash.patch 
b/meta-cgl-common/recipes-cgl/openais/files/openais-fix-bash.patch
deleted file mode 100644
index ede77e8..000
--- a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-bash.patch
+++ /dev/null
@@ -1,10 +0,0 @@
-Index: openais-1.1.3/init/generic.in
-===
 openais-1.1.3.orig/init/generic.in
-+++ openais-1.1.3/init/generic.in
-@@ -1,4 +1,4 @@
--#!/bin/bash
-+#!/bin/sh
- 
- # Authors:
- #  Andrew Beekhof 
diff --git 
a/meta-cgl-common/recipes-cgl/openais/files/openais-fix-corosync-not-quit.patch

[yocto] [meta-cgl][PATCH 1/3] cluster: fix SRC_URI and depends

2019-05-02 Thread Armin Kuster

corosync 1.x have removed from meta-cgl, and use corosync under meta-networking.

corosync 2.x can replace corosync 1.x + openais (in meta-cgl),
so remove depend on openais

Signed-off-by: Armin Kuster 
---
 meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb 
b/meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb
index 1c6e353..34076d3 100644
--- a/meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb
+++ b/meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Red Hat Cluster"
 SECTION = "libs"
 HOMEPAGE = "https://fedorahosted.org/cluster/wiki/HomePage;
 
-SRC_URI = "https://fedorahosted.org/releases/c/l/cluster/${BP}.tar.xz \
+SRC_URI = "https://releases.pagure.org/linux-cluster/cluster/${BP}.tar.xz \
file://0001-Fix-the-kernel-source-patch.patch"
 
 
@@ -15,7 +15,7 @@ LIC_FILES_CHKSUM = 
"file://doc/README.licence;md5=ee8ae43af5ea09f12ca7f7a649764c
 
 PR = "r1"
 
-DEPENDS = "corosync dbus openldap openais libxml2 ncurses perl zlib"
+DEPENDS = "corosync dbus openldap libxml2 ncurses perl zlib"
 
 FILES_${PN} += "/lib/udev/rules.d/51-dlm.rules \
 ${localstatedir}/run "
-- 
2.7.4

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

Re: [yocto] Dependencies with third party binaries

2019-05-02 Thread simon . zeni

Yes, the image will be deployed on the CI to build our software. I 
managed to just drop the files at some place, but it requires user input 
to install the compiler.


Simon

On 03.05.2019 01:19, Burton, Ross wrote:

Do you mean you want to build packages to run icc on the target?

On Thu, 2 May 2019 at 23:46,  wrote:


The layer that comes with the Intel system studio only contains the
runtime libraries, not the compiler itself.

Simon

On 03.05.2019 00:15, Burton, Ross wrote:
> Why don't you use the layer that comes with the Intel compiler?
>
> Ross
>
> On Thu, 2 May 2019 at 23:15,  wrote:
>>
>> Hi,
>>
>> I'm currently working on repackaging the 2016 Intel compiler and I am
>> stuck at the dependency resolution.
>>
>> I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs
>> from the parallel-studio-xe [2] archive and extracts the content of
>> the
>> RPMs to get the binaries. I already have the RPMs extracted from the
>> tarball and stored in a git repo. Not the ideal solution, but good
>> enough for now.
>>
>> The `bitbake` command for the recipe is passing after disabling a
>> couple
>> of QA errors (too much for my taste), but the recipe for the
>> `core-image` fails at the dependency
>> resolution. From what I understand, all of the binaries inside of the
>> `FILES_${PN}` are checked, and one (or more) fails at the dependency
>> check with the following message :
>>
>> ```
>> Error:
>>   Problem: conflicting requests
>>- nothing provides ld-linux-k1om.so.2()(64bit) needed by
>> icc-2016+1-r0.corei7_64
>> ```
>>
>> This shared library seems to be Intel related but I cannot find it in
>> all of the RPMs contained in the initial tarball. It is also not
>> needed
>> to run the compiler, I was able to execute the `icc` and `icpc` (the
>> c++
>> compiler) binaries from the devshell.
>>
>> I know this is wrong and against every yocto principles, but is there
>> a
>> way to skip the dependenciey resolution for a specific recipe ? Or is
>> there a recipe made by Intel that I missed ?
>> I'm also open to any suggestions on how to tackle this task.
>>
>> Here's my recipe so far :
>>
>> ```
>> LICENSE = "CLOSED"
>> LIC_FILES_CHKSUM = ""
>>
>> DEPENDS += "libarchive-native"
>>
>> SRC_URI = # omitted
>>
>> PV = "2016-1"
>> SRCREV = "${AUTOREV}"
>>
>> S = "${WORKDIR}/git"
>>
>> extract_rpms() {
>> for rpm_file in ${S}/$1; do
>> bsdtar -xf ${rpm_file} -C $2
>> done
>> }
>>
>> # Skip the unwanted steps
>> do_configure[noexec] = "1"
>> do_compile[noexec] = "1"
>>
>> do_install () {
>> extract_rpms 'intel-icc*.rpm' ${D}
>> extract_rpms 'intel-comp*.rpm' ${D}
>> extract_rpms 'intel-ccomp*.rpm' ${D}
>> extract_rpms 'intel-openmp*.rpm' ${D}
>> }
>>
>> do_package_qa[noexec] = "1"
>>
>> ALLOW_EMPTY_${PN} = "1"
>>
>> FILES_SOLIBSDEV = ""
>> FILES_${PN} += "/opt/intel/*"
>>
>> INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev
>> file-rdeps
>> build-deps"
>>
>> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>> INHIBIT_PACKAGE_STRIP = "1"
>>
>> ```
>>
>> Thanks,
>>
>> Simon Zeni
>>
>> [1]:
>> 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
>> [2]:
>> 
http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz
>> --
>> ___
>> 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] Dependencies with third party binaries

2019-05-02 Thread Burton, Ross

Why don't you use the layer that comes with the Intel compiler?

Ross

On Thu, 2 May 2019 at 23:15,  wrote:
>
> Hi,
>
> I'm currently working on repackaging the 2016 Intel compiler and I am
> stuck at the dependency resolution.
>
> I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs
> from the parallel-studio-xe [2] archive and extracts the content of the
> RPMs to get the binaries. I already have the RPMs extracted from the
> tarball and stored in a git repo. Not the ideal solution, but good
> enough for now.
>
> The `bitbake` command for the recipe is passing after disabling a couple
> of QA errors (too much for my taste), but the recipe for the
> `core-image` fails at the dependency
> resolution. From what I understand, all of the binaries inside of the
> `FILES_${PN}` are checked, and one (or more) fails at the dependency
> check with the following message :
>
> ```
> Error:
>   Problem: conflicting requests
>- nothing provides ld-linux-k1om.so.2()(64bit) needed by
> icc-2016+1-r0.corei7_64
> ```
>
> This shared library seems to be Intel related but I cannot find it in
> all of the RPMs contained in the initial tarball. It is also not needed
> to run the compiler, I was able to execute the `icc` and `icpc` (the c++
> compiler) binaries from the devshell.
>
> I know this is wrong and against every yocto principles, but is there a
> way to skip the dependenciey resolution for a specific recipe ? Or is
> there a recipe made by Intel that I missed ?
> I'm also open to any suggestions on how to tackle this task.
>
> Here's my recipe so far :
>
> ```
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> DEPENDS += "libarchive-native"
>
> SRC_URI = # omitted
>
> PV = "2016-1"
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
>
> extract_rpms() {
> for rpm_file in ${S}/$1; do
> bsdtar -xf ${rpm_file} -C $2
> done
> }
>
> # Skip the unwanted steps
> do_configure[noexec] = "1"
> do_compile[noexec] = "1"
>
> do_install () {
> extract_rpms 'intel-icc*.rpm' ${D}
> extract_rpms 'intel-comp*.rpm' ${D}
> extract_rpms 'intel-ccomp*.rpm' ${D}
> extract_rpms 'intel-openmp*.rpm' ${D}
> }
>
> do_package_qa[noexec] = "1"
>
> ALLOW_EMPTY_${PN} = "1"
>
> FILES_SOLIBSDEV = ""
> FILES_${PN} += "/opt/intel/*"
>
> INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev file-rdeps
> build-deps"
>
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> INHIBIT_PACKAGE_STRIP = "1"
>
> ```
>
> Thanks,
>
> Simon Zeni
>
> [1]:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
> [2]:
> http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz
> --
> ___
> 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] Dependencies with third party binaries

2019-05-02 Thread simon . zeni


Hi,

I'm currently working on repackaging the 2016 Intel compiler and I am 
stuck at the dependency resolution.


I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs 
from the parallel-studio-xe [2] archive and extracts the content of the 
RPMs to get the binaries. I already have the RPMs extracted from the 
tarball and stored in a git repo. Not the ideal solution, but good 
enough for now.


The `bitbake` command for the recipe is passing after disabling a couple 
of QA errors (too much for my taste), but the recipe for the 
`core-image` fails at the dependency
resolution. From what I understand, all of the binaries inside of the 
`FILES_${PN}` are checked, and one (or more) fails at the dependency 
check with the following message :


```
Error:
 Problem: conflicting requests
  - nothing provides ld-linux-k1om.so.2()(64bit) needed by 
icc-2016+1-r0.corei7_64

```

This shared library seems to be Intel related but I cannot find it in 
all of the RPMs contained in the initial tarball. It is also not needed 
to run the compiler, I was able to execute the `icc` and `icpc` (the c++ 
compiler) binaries from the devshell.


I know this is wrong and against every yocto principles, but is there a 
way to skip the dependenciey resolution for a specific recipe ? Or is 
there a recipe made by Intel that I missed ?

I'm also open to any suggestions on how to tackle this task.

Here's my recipe so far :

```
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

DEPENDS += "libarchive-native"

SRC_URI = # omitted

PV = "2016-1"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

extract_rpms() {
for rpm_file in ${S}/$1; do
bsdtar -xf ${rpm_file} -C $2
done
}

# Skip the unwanted steps
do_configure[noexec] = "1"
do_compile[noexec] = "1"

do_install () {
extract_rpms 'intel-icc*.rpm' ${D}
extract_rpms 'intel-comp*.rpm' ${D}
extract_rpms 'intel-ccomp*.rpm' ${D}
extract_rpms 'intel-openmp*.rpm' ${D}
}

do_package_qa[noexec] = "1"

ALLOW_EMPTY_${PN} = "1"

FILES_SOLIBSDEV = ""
FILES_${PN} += "/opt/intel/*"

INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev file-rdeps 
build-deps"


INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"

```

Thanks,

Simon Zeni

[1]: 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
[2]: 
http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz

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

Re: [yocto] Yocto Project @ ELC NA 2019

2019-05-02 Thread Rudolf J Streif


Hi Andrea,

Great. I can bring some wooden blocks to prop up the rear-end. People 
could sit in it and spin the wheels.


:rjs

On 5/2/19 2:39 PM, Volosincu, Andreea S wrote:

Hi Rudi,

That's awesome! I will check with LF events to see if there are any issues with 
showing that or restrictions with how people engage with it during the show.
Definitely in favor of showing the whole gokart.

Thanks!
Andreea

-Original Message-
From: Rudolf J Streif [mailto:rudolf.str...@ibeeto.com]
Sent: Thursday, May 2, 2019 2:36 PM
To: Volosincu, Andreea S ; Nicolas Dechesne 

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

Hi Andrea,

I was intending to bring the whole gokart. It's more fun to see the speedometer 
go up when you push down on the pedal and the regen to kick in when letting go 
etc. Everybody has seen hundreds of instrument cluster demos (at least when you 
work for the automotive industry). It might be a crowd catcher too (at least 
that's what I figured when I was at CES this year; a booth with a vehicle had 
many spectators :).

Please see early picture (without cluster) attached.

:rjs

On 5/2/19 2:17 PM, Volosincu, Andreea S wrote:

Hi Rudi,

That sounds super interesting. We do have a 6'x6' exhibit booth on the show 
floor, and a DevDay on Tuesday, August 20.

Are you planning to show just the instrument cluster, or the whole gokart? If 
the gokart, I would just need to check with LF and see if we are allowed to 
have that on the show floor. It's certainly a new thing we haven't tried or had 
before.

Thanks!
Andreea

-Original Message-
From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org]
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif ; Volosincu, Andreea S

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

hi Rudolf,

+Andreea (Yocto Advocacy)

we are definitely planning to be at ELC, with a similar setup as with past ELC 
: booth, demo, DevDay and BoF, well, at least !

cheers
nico

On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif  wrote:

I apologize if I missed any communication on this mailing list but
what are the plans for a presence of YP at ELC NA in August in San
Diego this year?

Unfortunately, I missed the deadline for submitting a speaking
proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC.
However, if YP is planning on a presence at ELC I'd be happy to
support it as I, conveniently, live in San Diego. If there is a YP
exhibition I might be able to bring my little hobby project, an
electric gokart with YP-based instrument cluster (it's a full-size
kart with 13 kW AC motor and a LiFePo battery pack producing up to 25
kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] Yocto Project @ ELC NA 2019

2019-05-02 Thread Volosincu, Andreea S

Hi Rudi,

That's awesome! I will check with LF events to see if there are any issues with 
showing that or restrictions with how people engage with it during the show. 
Definitely in favor of showing the whole gokart.

Thanks!
Andreea

-Original Message-
From: Rudolf J Streif [mailto:rudolf.str...@ibeeto.com] 
Sent: Thursday, May 2, 2019 2:36 PM
To: Volosincu, Andreea S ; Nicolas Dechesne 

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

Hi Andrea,

I was intending to bring the whole gokart. It's more fun to see the speedometer 
go up when you push down on the pedal and the regen to kick in when letting go 
etc. Everybody has seen hundreds of instrument cluster demos (at least when you 
work for the automotive industry). It might be a crowd catcher too (at least 
that's what I figured when I was at CES this year; a booth with a vehicle had 
many spectators :).

Please see early picture (without cluster) attached.

:rjs

On 5/2/19 2:17 PM, Volosincu, Andreea S wrote:
> Hi Rudi,
>
> That sounds super interesting. We do have a 6'x6' exhibit booth on the show 
> floor, and a DevDay on Tuesday, August 20.
>
> Are you planning to show just the instrument cluster, or the whole gokart? If 
> the gokart, I would just need to check with LF and see if we are allowed to 
> have that on the show floor. It's certainly a new thing we haven't tried or 
> had before.
>
> Thanks!
> Andreea
>
> -Original Message-
> From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org]
> Sent: Thursday, May 2, 2019 1:17 PM
> To: Rudolf J Streif ; Volosincu, Andreea S 
> 
> Cc: Yocto list discussion 
> Subject: Re: [yocto] Yocto Project @ ELC NA 2019
>
> hi Rudolf,
>
> +Andreea (Yocto Advocacy)
>
> we are definitely planning to be at ELC, with a similar setup as with past 
> ELC : booth, demo, DevDay and BoF, well, at least !
>
> cheers
> nico
>
> On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif  
> wrote:
>> I apologize if I missed any communication on this mailing list but 
>> what are the plans for a presence of YP at ELC NA in August in San 
>> Diego this year?
>>
>> Unfortunately, I missed the deadline for submitting a speaking 
>> proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC.
>> However, if YP is planning on a presence at ELC I'd be happy to 
>> support it as I, conveniently, live in San Diego. If there is a YP 
>> exhibition I might be able to bring my little hobby project, an 
>> electric gokart with YP-based instrument cluster (it's a full-size 
>> kart with 13 kW AC motor and a LiFePo battery pack producing up to 25 
>> kW peak power output going up to
>> 45 mph (electronically limited)).
>>
>> Cheers,
>> Rudi
>>
>> --
>> -
>> Rudolf J Streif
>> CEO/CTO ibeeto
>> +1.855.442.3396 x700
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] Yocto Project @ ELC NA 2019

2019-05-02 Thread Volosincu, Andreea S

Hi Rudi,

That sounds super interesting. We do have a 6'x6' exhibit booth on the show 
floor, and a DevDay on Tuesday, August 20.

Are you planning to show just the instrument cluster, or the whole gokart? If 
the gokart, I would just need to check with LF and see if we are allowed to 
have that on the show floor. It's certainly a new thing we haven't tried or had 
before.

Thanks!
Andreea

-Original Message-
From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org] 
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif ; Volosincu, Andreea S 

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

hi Rudolf,

+Andreea (Yocto Advocacy)

we are definitely planning to be at ELC, with a similar setup as with past ELC 
: booth, demo, DevDay and BoF, well, at least !

cheers
nico

On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif  wrote:
>
> I apologize if I missed any communication on this mailing list but 
> what are the plans for a presence of YP at ELC NA in August in San 
> Diego this year?
>
> Unfortunately, I missed the deadline for submitting a speaking 
> proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. 
> However, if YP is planning on a presence at ELC I'd be happy to 
> support it as I, conveniently, live in San Diego. If there is a YP 
> exhibition I might be able to bring my little hobby project, an 
> electric gokart with YP-based instrument cluster (it's a full-size 
> kart with 13 kW AC motor and a LiFePo battery pack producing up to 25 
> kW peak power output going up to
> 45 mph (electronically limited)).
>
> Cheers,
> Rudi
>
> --
> -
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3396 x700
>
> --
> ___
> 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] Yocto Project @ ELC NA 2019

2019-05-02 Thread Nicolas Dechesne

hi Rudolf,

+Andreea (Yocto Advocacy)

we are definitely planning to be at ELC, with a similar setup as with
past ELC : booth, demo, DevDay and BoF, well, at least !

cheers
nico

On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif  wrote:
>
> I apologize if I missed any communication on this mailing list but what
> are the plans for a presence of YP at ELC NA in August in San Diego this
> year?
>
> Unfortunately, I missed the deadline for submitting a speaking proposal
> ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However,
> if YP is planning on a presence at ELC I'd be happy to support it as I,
> conveniently, live in San Diego. If there is a YP exhibition I might be
> able to bring my little hobby project, an electric gokart with YP-based
> instrument cluster (it's a full-size kart with 13 kW AC motor and a
> LiFePo battery pack producing up to 25 kW peak power output going up to
> 45 mph (electronically limited)).
>
> Cheers,
> Rudi
>
> --
> -
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3396 x700
>
> --
> ___
> 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] System service

2019-05-02 Thread Lukasz Zemla

On Thursday, May 02, 2019 8:15 PM, Henrik Lindblom wrote:
>>> FILES_${PN} += "${systemd_unitdir}"
>
> This line is redundant, AFAIK, since systemd.bbclass will handle 
> packaging for you, assuming you install the service files that you 
> advertise in SYSTEMD_SERVICE_${PN}. However, as I'm writing this from 
> memory, I recommend you skim through the class definition and check 
> for further details there.

I confirm - this line is not required (at least at Yocto 2.6).

Best regards,
Lukasz Zemla
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: System service

2019-05-02 Thread Lukasz Zemla

On Thursday, May 02, 2019 8:15 PM, Henrik Lindblom wrote:
>>> FILES_${PN} += "${systemd_unitdir}"
>
> This line is redundant, AFAIK, since systemd.bbclass will handle
> packaging for you, assuming you install the service files that you
> advertise in SYSTEMD_SERVICE_${PN}. However, as I'm writing this from
> memory, I recommend you skim through the class definition and check
> for further details there.

I confirm - this line is not required (at least at Yocto 2.6).

Best regards,
Lukasz Zemla

***
The information in this email is confidential and intended solely for the 
individual or entity to whom it is addressed.  If you have received this email 
in error please notify the sender by return e-mail, delete this email, and 
refrain from any disclosure or action based on the information.
***
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread Robert P. J. Day

On Thu, 2 May 2019, Scott Rifenbark wrote:

> Great, thanks!
>
> On Thu, May 2, 2019 at 11:21 AM akuster  wrote:
>
>   On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>   > As meta-intel is no longer a container layer, use meta-xilinx as
>   > an example instead.
>
>   I thought "meta-virtualization" was a container layer?

  as a followup, i would think that "meta-openembedded" is the
canonical example of a container layer, no?

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread Robert P. J. Day



  much snipping ...

On Thu, 2 May 2019, Scott Rifenbark wrote:

> On Thu, May 2, 2019 at 10:21 AM akuster  wrote:
>
>
>   On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>   > As meta-intel is no longer a container layer, use meta-xilinx as
>   > an example instead.
>
>   I thought "meta-virtualization" was a container layer?

  uh, i'm looking at meta-virtualization right now:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/

and that looks like a regular BSP layer, not a container layer. am i
misunderstanding some fundamental point here?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] Yocto Project @ ELC NA 2019

2019-05-02 Thread Rudolf J Streif

I apologize if I missed any communication on this mailing list but what 
are the plans for a presence of YP at ELC NA in August in San Diego this 
year?


Unfortunately, I missed the deadline for submitting a speaking proposal 
("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However, 
if YP is planning on a presence at ELC I'd be happy to support it as I, 
conveniently, live in San Diego. If there is a YP exhibition I might be 
able to bring my little hobby project, an electric gokart with YP-based 
instrument cluster (it's a full-size kart with 13 kW AC motor and a 
LiFePo battery pack producing up to 25 kW peak power output going up to 
45 mph (electronically limited)).


Cheers,
Rudi

--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread Scott Rifenbark

Great, thanks!

On Thu, May 2, 2019 at 11:21 AM akuster  wrote:

>
>
> On 5/2/19 10:45 AM, Scott Rifenbark wrote:
>
> The term "Container Layer" was put in the ref-manual by me to describe a
> "meta-*" layer that had other "meta-*" layers (see
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
> and the term "Container Layer").  Maybe this was never a good term?  I
> don't know.  Nobody has said anything about that term for many releases.
>
> The problem Robert points out needs to be fixed in the BSP manual as
> "meta-intel" is not longer qualifying by my definition.  I can fix that.
>
> Is "Container Layer" ok as I have defined it?
>
> in those terms above, yes its fine.
>
> thanks for clarifying.
>
> Armin
>
>
> Thanks,
> Scott
>
> On Thu, May 2, 2019 at 10:21 AM akuster  wrote:
>
>>
>>
>> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>> > As meta-intel is no longer a container layer, use meta-xilinx as
>> > an example instead.
>>
>> I thought "meta-virtualization" was a container layer?
>>
>> IMHO, a BSP should only deal with getting a MACHINE booted.
>>
>> - armin
>> >
>> > Signed-off-by: Robert P. J. Day 
>> >
>> > ---
>> >
>> > diff --git a/documentation/bsp-guide/bsp.xml
>> b/documentation/bsp-guide/bsp.xml
>> > index 0bb0b68ab..a53ff6bce 100644
>> > --- a/documentation/bsp-guide/bsp.xml
>> > +++ b/documentation/bsp-guide/bsp.xml
>> > @@ -146,18 +146,15 @@
>> >
>> >  
>> >  Some layers function as a layer to hold other BSP layers.
>> > -These layers are knows as
>> > +These layers are known as
>> >  "> url='_DOCS_REF_URL;#term-container-layer'>container layers".
>> >  An example of this type of layer is the
>> > -meta-intel layer.
>> > -This layer contains BSP layers for the Intel-core2-32
>> > -Intel Common Core
>> > -(Intel-core2-32) and the Intel-corei7-64
>> > -Intel Common Core
>> > -(Intel-corei7-64).
>> > -the meta-intel layer also contains
>> > -the common/ directory, which contains
>> > -common content across those layers.
>> > +meta-xilinx layer.
>> > +This container layer contains some basic top-level information,
>> > +as well as three actual Xilinx-related BSP layers,
>> > +meta-xilinx-bsp,
>> > +meta-xilinx-contrib, and
>> > +meta-xilinx-standalone.
>> >  
>> >
>> >  
>> >
>>
>> --
>> ___
>> 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] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread akuster



On 5/2/19 10:45 AM, Scott Rifenbark wrote:
> The term "Container Layer" was put in the ref-manual by me to describe
> a "meta-*" layer that had other "meta-*" layers (see
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
> and the term "Container Layer").  Maybe this was never a good term?  I
> don't know.  Nobody has said anything about that term for many releases. 
>
> The problem Robert points out needs to be fixed in the BSP manual as
> "meta-intel" is not longer qualifying by my definition.  I can fix that. 
>
> Is "Container Layer" ok as I have defined it?
in those terms above, yes its fine.

thanks for clarifying.

Armin
>
> Thanks,
> Scott
>
> On Thu, May 2, 2019 at 10:21 AM akuster  > wrote:
>
>
>
> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> > As meta-intel is no longer a container layer, use meta-xilinx as
> > an example instead.
>
> I thought "meta-virtualization" was a container layer?
>
> IMHO, a BSP should only deal with getting a MACHINE booted.
>
> - armin
> >
> > Signed-off-by: Robert P. J. Day  >
> >
> > ---
> >
> > diff --git a/documentation/bsp-guide/bsp.xml
> b/documentation/bsp-guide/bsp.xml
> > index 0bb0b68ab..a53ff6bce 100644
> > --- a/documentation/bsp-guide/bsp.xml
> > +++ b/documentation/bsp-guide/bsp.xml
> > @@ -146,18 +146,15 @@
> >
> >      
> >          Some layers function as a layer to hold other BSP layers.
> > -        These layers are knows as
> > +        These layers are known as
> >          " url='_DOCS_REF_URL;#term-container-layer'>container
> layers".
> >          An example of this type of layer is the
> > -        meta-intel layer.
> > -        This layer contains BSP layers for the Intel-core2-32
> > -        Intel Common Core
> > -        (Intel-core2-32) and the Intel-corei7-64
> > -        Intel Common Core
> > -        (Intel-corei7-64).
> > -        the meta-intel layer also contains
> > -        the common/ directory, which contains
> > -        common content across those layers.
> > +        meta-xilinx layer.
> > +        This container layer contains some basic top-level
> information,
> > +        as well as three actual Xilinx-related BSP layers,
> > +        meta-xilinx-bsp,
> > +        meta-xilinx-contrib, and
> > +        meta-xilinx-standalone.
> >      
> >
> >      
> >
>
> -- 
> ___
> 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] System service

2019-05-02 Thread Henrik Lindblom

> Looks like it's dropping the service in ${sysconfdir}/init.d which
> resolves to /etc/init.d. I'm not sure that systemd won't look into
> init.d for services.

It doesn't.

> The standard place to put them is ${D}/${systemd_system_unitdir},
> which resolves to /lib/systemd/system.

Systemd's unit search path is documented in

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

but the ones I've personally used most are /usr/lib/systemd/user and
/etc/systemd/system. These are a personal preference more than
anything else.

>> do_install_append() {
>>   install -d ${D}${sysconfdir}/init.d/
>>   install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
>> }

do_install() seems to be installing only non-systemd ofono shell
script in.

>> FILES_${PN} += "${systemd_unitdir}"

This line is redundant, AFAIK, since systemd.bbclass will handle
packaging for you, assuming you install the service files that you
advertise in SYSTEMD_SERVICE_${PN}. However, as I'm writing this from
memory, I recommend you skim through the class definition and check
for further details there.

Cheers,
Henrik

On Thu, May 2, 2019 at 8:28 PM Timothy Froehlich 
wrote:

> Looks like it's dropping the service in ${sysconfdir}/init.d which
> resolves to /etc/init.d. I'm not sure that systemd won't look into init.d
> for services. The standard place to put them
> is ${D}/${systemd_system_unitdir}, which resolves to /lib/systemd/system.
>
> Also, check the "SYSTEMD_AUTO_ENABLE_pn-ofono" variable for that recipe.
> The systemd class sets it to "enable" by default, but something else could
> be overriding it and setting it to "disable".  Alternatively, confirm that
> the service isn't actually starting up and failing. It may be that you're
> restarting it once the system is fully booted and everything ofono needs is
> now ready.
>
> On Thu, May 2, 2019 at 7:55 AM JH  wrote:
>
>> Hi,
>>
>> The official ofono.inc recipe defines SYSTEMD_SERVICE_${PN} =
>> "ofono.service", but when I built the image, the system service does
>> not start ofono daemon automatically, I have to run the ofono daemon
>> manually. What I could be missing here? Here is the ofono recipes,
>> sorry if I need to ask ofono mailing list.
>>
>> $ cat ofono.inc
>> HOMEPAGE = "http://www.ofono.org;
>> SUMMARY  = "open source telephony"
>> DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
>> oFono supports speaking to telephony devices through specific drivers,
>> or with generic AT commands."
>> LICENSE  = "GPLv2"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
>>
>>
>> file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"
>>
>> inherit autotools pkgconfig update-rc.d systemd bluetooth
>> gobject-introspection-data
>>
>> DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info"
>>
>> INITSCRIPT_NAME = "ofono"
>> INITSCRIPT_PARAMS = "defaults 22"
>>
>> PACKAGECONFIG ??= "\
>> ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
>> ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)}
>> \
>> "
>> PACKAGECONFIG[systemd] =
>> "--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
>> PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"
>>
>> EXTRA_OECONF += "--enable-test"
>>
>> SYSTEMD_SERVICE_${PN} = "ofono.service"
>>
>> do_install_append() {
>>   install -d ${D}${sysconfdir}/init.d/
>>   install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
>> }
>>
>> PACKAGES =+ "${PN}-tests"
>>
>> RDEPENDS_${PN} += "dbus"
>> RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"
>>
>> FILES_${PN} += "${systemd_unitdir}"
>> FILES_${PN}-tests = "${libdir}/${BPN}/test"
>> RDEPENDS_${PN}-tests = "python3 python3-dbus"
>> RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
>> 'True', 'python3-pygobject', '', d)}"
>>
>> Thank you.
>>
>> - jupiter
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
> --
> Tim Froehlich
> Embedded Linux Engineer
> tfroehl...@archsys.io
> 215-218-8955
> --
> ___
> 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] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread Scott Rifenbark

The term "Container Layer" was put in the ref-manual by me to describe a
"meta-*" layer that had other "meta-*" layers (see
https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
and the term "Container Layer").  Maybe this was never a good term?  I
don't know.  Nobody has said anything about that term for many releases.

The problem Robert points out needs to be fixed in the BSP manual as
"meta-intel" is not longer qualifying by my definition.  I can fix that.

Is "Container Layer" ok as I have defined it?

Thanks,
Scott

On Thu, May 2, 2019 at 10:21 AM akuster  wrote:

>
>
> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> > As meta-intel is no longer a container layer, use meta-xilinx as
> > an example instead.
>
> I thought "meta-virtualization" was a container layer?
>
> IMHO, a BSP should only deal with getting a MACHINE booted.
>
> - armin
> >
> > Signed-off-by: Robert P. J. Day 
> >
> > ---
> >
> > diff --git a/documentation/bsp-guide/bsp.xml
> b/documentation/bsp-guide/bsp.xml
> > index 0bb0b68ab..a53ff6bce 100644
> > --- a/documentation/bsp-guide/bsp.xml
> > +++ b/documentation/bsp-guide/bsp.xml
> > @@ -146,18 +146,15 @@
> >
> >  
> >  Some layers function as a layer to hold other BSP layers.
> > -These layers are knows as
> > +These layers are known as
> >  " url='_DOCS_REF_URL;#term-container-layer'>container layers".
> >  An example of this type of layer is the
> > -meta-intel layer.
> > -This layer contains BSP layers for the Intel-core2-32
> > -Intel Common Core
> > -(Intel-core2-32) and the Intel-corei7-64
> > -Intel Common Core
> > -(Intel-corei7-64).
> > -the meta-intel layer also contains
> > -the common/ directory, which contains
> > -common content across those layers.
> > +meta-xilinx layer.
> > +This container layer contains some basic top-level information,
> > +as well as three actual Xilinx-related BSP layers,
> > +meta-xilinx-bsp,
> > +meta-xilinx-contrib, and
> > +meta-xilinx-standalone.
> >  
> >
> >  
> >
>
> --
> ___
> 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] mailman not found

2019-05-02 Thread akuster



On 5/2/19 5:43 AM, Searles, Dan wrote:
>
> I got this response to my recent email:
>
>  
>
> Your message to mail...@yoctoproject.org couldn't be delivered.
>

What mailing list did you send it to originally ?

- armin
>
> mailman wasn't found at yoctoproject.org.
>
>  
>
>

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

Re: [yocto] System service

2019-05-02 Thread Timothy Froehlich

Looks like it's dropping the service in ${sysconfdir}/init.d which resolves
to /etc/init.d. I'm not sure that systemd won't look into init.d for
services. The standard place to put them is ${D}/${systemd_system_unitdir},
which resolves to /lib/systemd/system.

Also, check the "SYSTEMD_AUTO_ENABLE_pn-ofono" variable for that recipe.
The systemd class sets it to "enable" by default, but something else could
be overriding it and setting it to "disable".  Alternatively, confirm that
the service isn't actually starting up and failing. It may be that you're
restarting it once the system is fully booted and everything ofono needs is
now ready.

On Thu, May 2, 2019 at 7:55 AM JH  wrote:

> Hi,
>
> The official ofono.inc recipe defines SYSTEMD_SERVICE_${PN} =
> "ofono.service", but when I built the image, the system service does
> not start ofono daemon automatically, I have to run the ofono daemon
> manually. What I could be missing here? Here is the ofono recipes,
> sorry if I need to ask ofono mailing list.
>
> $ cat ofono.inc
> HOMEPAGE = "http://www.ofono.org;
> SUMMARY  = "open source telephony"
> DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
> oFono supports speaking to telephony devices through specific drivers,
> or with generic AT commands."
> LICENSE  = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
>
>
> file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"
>
> inherit autotools pkgconfig update-rc.d systemd bluetooth
> gobject-introspection-data
>
> DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info"
>
> INITSCRIPT_NAME = "ofono"
> INITSCRIPT_PARAMS = "defaults 22"
>
> PACKAGECONFIG ??= "\
> ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
> "
> PACKAGECONFIG[systemd] =
> "--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
> PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"
>
> EXTRA_OECONF += "--enable-test"
>
> SYSTEMD_SERVICE_${PN} = "ofono.service"
>
> do_install_append() {
>   install -d ${D}${sysconfdir}/init.d/
>   install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
> }
>
> PACKAGES =+ "${PN}-tests"
>
> RDEPENDS_${PN} += "dbus"
> RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"
>
> FILES_${PN} += "${systemd_unitdir}"
> FILES_${PN}-tests = "${libdir}/${BPN}/test"
> RDEPENDS_${PN}-tests = "python3 python3-dbus"
> RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
> 'True', 'python3-pygobject', '', d)}"
>
> Thank you.
>
> - jupiter
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

2019-05-02 Thread akuster




On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> As meta-intel is no longer a container layer, use meta-xilinx as
> an example instead.

I thought "meta-virtualization" was a container layer?

IMHO, a BSP should only deal with getting a MACHINE booted.

- armin
>
> Signed-off-by: Robert P. J. Day 
>
> ---
>
> diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
> index 0bb0b68ab..a53ff6bce 100644
> --- a/documentation/bsp-guide/bsp.xml
> +++ b/documentation/bsp-guide/bsp.xml
> @@ -146,18 +146,15 @@
>
>  
>  Some layers function as a layer to hold other BSP layers.
> -These layers are knows as
> +These layers are known as
>  "container 
> layers".
>  An example of this type of layer is the
> -meta-intel layer.
> -This layer contains BSP layers for the Intel-core2-32
> -Intel Common Core
> -(Intel-core2-32) and the Intel-corei7-64
> -Intel Common Core
> -(Intel-corei7-64).
> -the meta-intel layer also contains
> -the common/ directory, which contains
> -common content across those layers.
> +meta-xilinx layer.
> +This container layer contains some basic top-level information,
> +as well as three actual Xilinx-related BSP layers,
> +meta-xilinx-bsp,
> +meta-xilinx-contrib, and
> +meta-xilinx-standalone.
>  
>
>  
>

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

[yocto] mailman not found

2019-05-02 Thread Searles, Dan

I got this response to my recent email:

Your message to mail...@yoctoproject.org couldn't be delivered.
mailman wasn't found at yoctoproject.org.

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

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

2019-05-02 Thread Robert P. J. Day

On Thu, 25 Apr 2019, Richard Purdie wrote:

> On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote:

... snip ...

> >   ASSUME_PROVIDED += "cmake-native"
>
> This is a bad idea as we patch cmake iirc.

... snip ...
>
> You would also have to do:
>
> HOSTTOOLS += "cmake"
>
> to allow cmake to be visible from the host system. Its a host
> contamination protection mechanisn that has been there since pyro.

  just to summarize, if one wanted to (perhaps injudiciously) take
advantage of host tools, that requires:

1) ASSUME_PROVIDED to specify the native package that no longer needs
   to be built, and

2) HOSTTOOLS to identify the binary (or binaries) that can be picked
   up from the host

  i can see an obvious example here:

https://patchwork.openembedded.org/patch/140375/

but if this is the case, then it seems that the YP reference manual
should be clarified to explain the association between these
variables. for example, the current ref manual reads:

  ASSUME_PROVIDED

  Lists recipe names (PN values) BitBake does not attempt to build.
  Instead, BitBake assumes these recipes have already been built.

  In OpenEmbedded-Core, ASSUME_PROVIDED mostly specifies native
  tools that should not be built. An example is git-native, which when
  specified, allows for the Git binary from the host to be used rather
  than building git-native.

reading that, a reader would not realize the necessity(?) of setting
HOSTTOOLS, yes?

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[linux-yocto] Partition storage

2019-05-02 Thread JH

Hi,

I need to partition the Flash storage to use dual versions of firmware
/ image, can it be defined in recipe?

Thank you.

Kind regards,

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

[yocto] System service

2019-05-02 Thread JH

Hi,

The official ofono.inc recipe defines SYSTEMD_SERVICE_${PN} =
"ofono.service", but when I built the image, the system service does
not start ofono daemon automatically, I have to run the ofono daemon
manually. What I could be missing here? Here is the ofono recipes,
sorry if I need to ask ofono mailing list.

$ cat ofono.inc
HOMEPAGE = "http://www.ofono.org;
SUMMARY  = "open source telephony"
DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
oFono supports speaking to telephony devices through specific drivers,
or with generic AT commands."
LICENSE  = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \

file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"

inherit autotools pkgconfig update-rc.d systemd bluetooth
gobject-introspection-data

DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info"

INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"

PACKAGECONFIG ??= "\
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
"
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"

EXTRA_OECONF += "--enable-test"

SYSTEMD_SERVICE_${PN} = "ofono.service"

do_install_append() {
  install -d ${D}${sysconfdir}/init.d/
  install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
}

PACKAGES =+ "${PN}-tests"

RDEPENDS_${PN} += "dbus"
RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"

FILES_${PN} += "${systemd_unitdir}"
FILES_${PN}-tests = "${libdir}/${BPN}/test"
RDEPENDS_${PN}-tests = "python3 python3-dbus"
RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
'True', 'python3-pygobject', '', d)}"

Thank you.

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

[yocto] Newcomer bugs

2019-05-02 Thread Richard Purdie

Apologies for cross posting but I wanted a wider audience to see this.

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, if there are people interested in helping mentor newcomers and
help develop newcomer suited bugs, please talk to me about it as we
could definitely do with help there. 

Other roles where we could do with particular help are toaster
development, website improvements/maintenance, QA framework
documentation/development + testcases and our CI testing along with the
usual other things but these are not really suited to newcomers.

Cheers,

Richard

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

[yocto] "meta-intel" layer bad example of a "container layer"

2019-05-02 Thread Robert P. J. Day


  catching up with all the YP stuff i've missed over the last while
and, in the BSP guide in the layers section:

https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers

one reads:

"Some layers function as a layer to hold other BSP layers. These
layers are knows as "container layers". An example of this type of
layer is the meta-intel layer. This layer contains BSP layers for the
Intel-core2-32 Intel® Common Core (Intel-core2-32) and the
Intel-corei7-64 Intel® Common Core (Intel-corei7-64). the meta-intel
layer also contains the common/ directory, which contains common
content across those layers. "

  pretty sure meta-intel has been a regular BSP layer for a while now,
so another example should be used. off the top of my head, i'd suggest
meta-xilinx:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/

unless anyone has strong objections, i can send in a patch.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple ubifs partition

2019-05-02 Thread Gabriele Zampieri

Hi Ulrich,

ok, I guess I miss-understand how that class works. I thought that I had to
add the customization on my own image recipe.
So the correct way is to write a 'customization recipe' and install via
IMAGE_INSTALL? Can you provide an example?

Thanks,
Gabriele

Il giorno mer 24 apr 2019 alle ore 15:15 Ulrich Ölmann <
u.oelm...@pengutronix.de> ha scritto:

> Hi Gabriele,
>
> On Wed, Apr 24 2019 at 14:06 +0200, Gabriele Zampieri <
> gabbla.mal...@gmail.com> wrote:
> > I'm now testing genimage via meta-ptx in my Yocto workflow, but I found a
> > problem: I cannot set a SRC_URI in my custom image recipe (that inherit
> > from core-image which in turn inherit from image) because do_fetch and
> > do_unpack tasks have noexec set to 1. If I specify the SRC_URI with my
> > genimage.config, bitbake exits, complaining about LIC_FILE_CHECKSUM (that
> > is correctly specified). If I hack image.bbclass and comment out
> >
> > #do_fetch[noexec] = "1"
> >
> >
> > #do_unpack[noexec] = "1"
> >
> > The process start correctly. Is there a way to avoid touching
> image.bbclass
> > and install my configuration from the image recipe?
> >
> > Thanks,
> > Gabriele
>
> you need one or more recipe(s) that construct(s) your filesystem(s) and
> a separate one that makes a flashable image out of that (see the
> introductory documentation in 'genimage.bbclass'). In the former you
> inherit 'core-image' and only in the latter which inherits 'genimage'
> you have to set the SRC_URI to point to your 'genimage.config'.
>
> Best regards
> Ulrich
>
>
> > Il giorno mer 13 mar 2019 alle ore 16:14 Gabriele Zampieri <
> > gabbla.mal...@gmail.com> ha scritto:
> >
> >> Hi all,
> >>
> >> thank you very much for the suggestion, I will check genimage and test
> it.
> >>
> >> Gabriele
> >>
> >> Il giorno gio 7 mar 2019 alle ore 16:23 Ulrich Ölmann <
> >> u.oelm...@pengutronix.de> ha scritto:
> >>
> >>> Hi there,
> >>>
> >>> On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten <
> >>> carsten.stelli...@goerlitz.com> wrote:
> >>> > Have you seen https://github.com/pengutronix/genimage?
> >>>
> >>> you can find it included within
> https://github.com/pengutronix/meta-ptx
> >>> with an accompanying genimage.bbclass.
> >>>
> >>> Best regards
> >>> Ulrich
> >>>
> >>> > Regards,
> >>> >
> >>> > Carsten
> >>> >
> >>> > Von: yocto-boun...@yoctoproject.org [mailto:
> >>> yocto-boun...@yoctoproject.org] Im Auftrag von Gabriele Zampieri
> >>> > Gesendet: Montag, 4. März 2019 12:17
> >>> > An: yocto@yoctoproject.org
> >>> > Betreff: [yocto] Multiple ubifs partition
> >>> >
> >>> > Hi all,
> >>> >
> >>> > I'm trying to build a distribution that has multiple partitions. The
> >>> desiderata is something like:
> >>> >
> >>> > - rootfs.ubifs mounted on /
> >>> > - data.ubifs mounted on /data
> >>> > - opt.ubifs mounted on /opt
> >>> >
> >>> > I was wondering if there is a standard way to achieve the goal. I see
> >>> that there is a tool called wic, but it does not seems to support
> ubifs. I
> >>> could post process the tarball image and doing stuff with my scripts,
> but
> >>> I'd prefer doing this in a single bitbake run. Can you suggest
> something?
> >>> >
> >>> > Thanks,
> >>> > Gabriele
> >>>
> >>>
> >>> --
> >>> Pengutronix e.K.   | Ulrich Ölmann
>|
> >>> Industrial Linux Solutions |
> http://www.pengutronix.de/
> >>> |
> >>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>   |
> >>> Amtsgericht Hildesheim, HRA 2686   | Fax:
>  +49-5121-206917- |
> >>>
> >>
>
>
> --
> Pengutronix e.K.   | Ulrich Ölmann   |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Custom eSDK build fails

2019-05-02 Thread Priyanshu Sharma

Hi,

I've a custom Yocto layer and use that as TEMPLATECONF for building. My
custom layer also contains the image recipe based on pulsar-image (from
meta-ivi).

I'm using Yocto 2.5. The extensible sdk build fails at do_populate_sdk_ext
task for my image recipe.

$ bitbake  -f -c populate_sdk_ext
Error -
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'///sdk-ext/image//opt//2.5.1/conf/local.conf.bak'
->
'///sdk-ext/image//opt//2.5.1/conf/local.conf'

If I check the path, <>/sdk-ext/image//opt//2.5.1 , this directory
is getting created but getting deleted afterwards.
And  the one left after build fails is -
<>/sdk-ext/image//opt//layers

Is there any configuration to be modified/added for my custom image?

Warm regards,
Priyanshu Sharma
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-05-02 Thread Teemu K

On Thu, Mar 28, 2019 at 6:36 AM Teemu K  wrote:
>
> On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
> >
> > On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:
> > >
> > >
> > >
> > > On 3/13/19 9:50 PM, Teemu K wrote:
> > >
> > > Hi,
> > >
> > > I noticed that when trying to build sdk on thud it fails on latest
> > > version. Actually it broke somewhere between commits:
> > >
> > > 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
> > > 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
> > >
> > > I'm using it with meta-freescale - layer to build image to iMX8.
> > >
> > > I'm using command 'populate_sdk' and it works fine on older version,
> > > but newer version it fails with error:
> > >
> > > Can you provide the steps to reproduce?
> > bitbake my-image-name -c populate_sdk
> >
> > >
> > > ==
> > > The following packages have unmet dependencies:
> > >  target-sdk-provides-dummy : Conflicts: coreutils
> > > E: Unable to correct problems, you have held broken packages.
> > >
> > >
> > > There is a change sitting in stable/thud-next:
> > >
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next=af5cf78b275ab5226354337d25d8dc1c41a08904
> > >
> > > which might be related. Can you try that branch?
> > >
> > > git://git.yoctoproject.org/poky-contrib  stable/thud-next
> > That did not solve the problem. I have coreutils in my image and it
> > kept conflicting. When I removed coreutils from my image it solved
> > that problem, but there were some problems with perl etc. From the
> > working version all those are missing from
> > target-sdk-provices-dummy.bb and my original image works just fine.
> I see that thud-branch has gotten even more 'fixes' for this sdk thing
> in last week, but the actual problem still stays. If image-recipe uses
> coreutils - recipe sdk build fails there because
> target-sdk-provides-dummy.bb has it listed. And if I remove that then
> it fails on next package.In my case it's bash-dev.
>
> Does those changes need something different how sdk is build or how to
> build sdk with those changes? I'm not sure why they are listed there
> in the first place if it overrides the actual package and does not
> provide 'dummy' if/when needed.
>
> To create sdk I use this command: bitbake  -c populate_sdk
>
> -Teemu

I updated to latest thud and this is still an issue. Isn't anyone else
building sdk or what I'm doing wrong?

I use command: bitbake  -c populate_sdk to generate sdk.

With unedited poky - meta layer it stops at error:

--
The following packages have unmet dependencies:
 target-sdk-provides-dummy : Conflicts: coreutils
--

If I remove that from poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb

The next error is:
--
The following packages have unmet dependencies:
 apt-dev : Depends: apt (= 1.2.24-r0) but it is not going to be installed
   Recommends: bash-dev
--

If I remove that from file mentioned before the next error is about
perl-dev. If I remove that it ends up on this error:

--

The following packages have unmet dependencies:
 target-sdk-provides-dummy-dev : Depends: target-sdk-provides-dummy (=
1.0-r0) but it is not going to be installed
--

For testing purposes I removed everything from that file except bash
and after that the sdk generated just fine.

I don't know enough about yocto/poky so what is the use of this
target-sdk-provides-dummy thingie and why things are added there that
keep breaking the sdk generation or do I need to generate sdk now
someway differently? Atm. I'm either stuck on that older thud -
version or I have to manually edit this
target-sdk-provides-dummy-dev.bb - file.

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

Re: [yocto] Multiple ubifs partition

[yocto] Yocto concept and support for dual version firmware upgrad and boot

[yocto] [meta-security][PATCH 2/2] apparmor: fix fragment for 5.0 kernel

[yocto] [meta-security][PATCH 1/2] libseccomp: update to 2.4.1

[yocto] [meta-cgl][PATCH 3/3] packagegroup-cgl-middleware: remove openais

[yocto] [meta-cgl][PATCH 2/3] openais: remove as corosync 2.x replaces functionality

[yocto] [meta-cgl][PATCH 1/3] cluster: fix SRC_URI and depends

Re: [yocto] Dependencies with third party binaries

Re: [yocto] Dependencies with third party binaries

[yocto] Dependencies with third party binaries

Re: [yocto] Yocto Project @ ELC NA 2019

Re: [yocto] Yocto Project @ ELC NA 2019

Re: [yocto] Yocto Project @ ELC NA 2019

Re: [yocto] Yocto Project @ ELC NA 2019

Re: [yocto] System service

Re: [yocto] [EXTERNAL] Re: System service

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[yocto] Yocto Project @ ELC NA 2019

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Re: [yocto] System service

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Re: [yocto] mailman not found

Re: [yocto] System service

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[yocto] mailman not found

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[linux-yocto] Partition storage

[yocto] System service

[yocto] Newcomer bugs

[yocto] "meta-intel" layer bad example of a "container layer"

Re: [yocto] Multiple ubifs partition

[yocto] Custom eSDK build fails

Re: [yocto] SDK build fails at latest thud

35 matches

Site Navigation

Mail list logo

Footer information