Re: [yocto] Debug-files in SDK
On Mon, Sep 23, 2019 at 12:27 PM Ross Burton wrote: > > On 23/09/2019 10:19, Teemu K wrote: > > One question is that is there a way to make package that would contain > > only dpg-pkgs and src-pkgs? Ie. it'd be like 'debug-addition' for SDK? > > I know how to install those things to target, but how to get them to a > > package (or in separate directory) to host. > > This is where you'd use an Extensible SDK instead of a traditional SDK, > where you can install packages into the sysroot after installation. Okay, I'll have to investigate that more. Last time(quite awhile back) I tried the eSDK generation it ended in error if I'm not mistaken. Thanks! -Teemu -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-dpdk][PATCH] [RFC] dpdk: Remove v17
From: He Zhe openvswith used not to be able to work with dpdk v18. That's one of the reasons why we keep v17. Now that openvswitch in meta-virtulization has been upgraded to v2.11, officially claimed support of dpdk18, we can drop dpdk v17. Signed-off-by: He Zhe --- ...dk-16.07-dpdk-fix-for-parellel-make-issue.patch | 40 -- ...disable-warning-for-packed-member-pointer.patch | 48 -- recipes-extended/dpdk/dpdk_17.11.6.bb | 19 - 3 files changed, 107 deletions(-) delete mode 100644 recipes-extended/dpdk/dpdk/dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch delete mode 100644 recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch delete mode 100644 recipes-extended/dpdk/dpdk_17.11.6.bb diff --git a/recipes-extended/dpdk/dpdk/dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch b/recipes-extended/dpdk/dpdk/dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch deleted file mode 100644 index 55f0c15..000 --- a/recipes-extended/dpdk/dpdk/dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch +++ /dev/null @@ -1,40 +0,0 @@ -From 4a86048d44cae812b227b857772aeeb839502706 Mon Sep 17 00:00:00 2001 -From: Rahul Kumar Gupta -Date: Fri, 2 Sep 2016 15:48:52 +0800 -Subject: [PATCH] dpdk: fix for parellel make issue - -To make sure that the path of libraries should be correct and -libraries will be build before, And available at the time of -linking example apps. - -Signed-off-by: Rahul Kumar Gupta - - examples/Makefile | 1 + - examples/ethtool/ethtool-app/Makefile | 1 + - 2 files changed, 2 insertions(+) - -diff --git a/examples/Makefile b/examples/Makefile -index 17ecf7f64cda..2a8e805b85a7 100644 a/examples/Makefile -+++ b/examples/Makefile -@@ -41,6 +41,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += bbdev_app - DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += bond - DIRS-y += cmdline - DIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += distributor -+DEPDIRS-y += examples/ethtool/lib - DIRS-y += ethtool - DIRS-y += exception_path - DIRS-$(CONFIG_RTE_LIBRTE_EFD) += server_node_efd -diff --git a/examples/ethtool/ethtool-app/Makefile b/examples/ethtool/ethtool-app/Makefile -index 4cd9efdd574b..d3c709ab2fef 100644 a/examples/ethtool/ethtool-app/Makefile -+++ b/examples/ethtool/ethtool-app/Makefile -@@ -19,6 +19,7 @@ SRCS-y := main.c ethapp.c - CFLAGS += -O3 -D_GNU_SOURCE -pthread -I$(SRCDIR)/../lib - CFLAGS += $(WERROR_FLAGS) - -+LDLIBS += -L$(ETHTOOL_LIB_PATH)/ - LDLIBS += -L$(subst ethtool-app,lib,$(RTE_OUTPUT))/lib - LDLIBS += -lrte_ethtool - diff --git a/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch b/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch deleted file mode 100644 index 70a8dec..000 --- a/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch +++ /dev/null @@ -1,48 +0,0 @@ -From a385972c3675dd2b4792ab5b3cf7a536e6f9846c Mon Sep 17 00:00:00 2001 -From: Reshma Pattan -Date: Thu, 2 May 2019 10:33:34 +0100 -Subject: [PATCH] mk: disable warning for packed member pointer -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -gcc 9 on Fedora 30 gives an error -"taking address of packed member may result in an -unaligned pointer value" warnings. - -For clang builds this warning is already disabled, -so disable "-Waddress-of-packed-member" for gcc builds -also. - -Snippet of build error: -lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’: -lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: -taking address of packed member of ‘struct rte_mem_config’ may result -in an unaligned pointer value [-Werror=address-of-packed-member] - 768 | cur_msl = &mcfg->memsegs[msl_idx]; - |^~~ - -Signed-off-by: Reshma Pattan -Tested-by: David Marchand -Upstream-Status: Backport -Signed-off-by: He Zhe - mk/toolchain/gcc/rte.vars.mk | 3 +++ - 1 file changed, 3 insertions(+) - -diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk -index d8b99fa..b852fcf 100644 a/mk/toolchain/gcc/rte.vars.mk -+++ b/mk/toolchain/gcc/rte.vars.mk -@@ -87,5 +87,8 @@ WERROR_FLAGS += -Wimplicit-fallthrough=2 - WERROR_FLAGS += -Wno-format-truncation - endif - -+# disable packed member unalign warnings -+WERROR_FLAGS += -Wno-address-of-packed-member -+ - export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF - export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS --- -2.7.4 - diff --git a/recipes-extended/dpdk/dpdk_17.11.6.bb b/recipes-extended/dpdk/dpdk_17.11.6.bb deleted file mode 100644 index 01bacd6..000 --- a/recipes-extended/dpdk/dpdk_17.11.6.bb +++ /dev/null @@ -1,19 +0,0 @@ -include dpdk.inc - -STABLE = "-stable" -BRANCH = "17.11" -SRCREV = "63d5c53b845d8360c0106374ce76eef9b5478c60" - -LICENSE = "LGPLv2 & GPLv2" -LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=751419260aa954499f7abaabaa882bbe\
Re: [yocto] [layerindex-web] PR / PE in layer index
Hi Pranay On Tuesday, 24 September 2019 10:00:46 AM NZST Pranay Mankad wrote: > Thank you for supporting the recipesExtended view over the last couple of > days. Here’s a small patch that includes values from two more variables from > the Bitbake cooker – PR and PE. > > I read through Paul’s explanation of why PE made sense but not PR, and > thinking about it, the PR in layerindexs’ case shows if the untouched recipe > had a revision associated with or not. Source metadata is important for > information, and hence I’m submitting a change with the same. I suppose so yes. Out of interest I did a search of OE-Core and there were more recipes than I would have guessed that set PR, so it could perhaps be useful. I'm not sure I'd bother adding it to the UI yet though (and you haven't, that's fine.) > Here’s the patch (this is my first time submitting one, hopefully it’s the > right way to do it): So unfortunately no, you need to send it as an actual patch and not just pasted into an email - git-format-patch / git-send-email are the most effective ways to do that (though it assumes you are able to send email directly from your linux system). Here's some info: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded (Of course you'd need to change mailing lists / prefixes in the examples, and some of the metadata requirements don't apply, but the basics are the same.) One other thing - you're editing the initial migration (layerindex/migrations/ 0001_initial.py) - that's not right. You need to undo the change to 0001_initial.py and then generate a new migration using the following command: ./manage.py createmigrations layerindex That will give you a new migration in layerindex/migrations/. You can then apply that migration to the database in the normal way: ./manage.py migrate layerindex Of course if your database already has those new fields the latter will fail, in this instance you could simply add --fake since the result would have been the same. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] gitlab-ci helper scripts for OpenEmbedded builds
Hi all, We released our scripts to help in setting up continuous integration of a yocto-based project using Gitlab-CI. You'll find the repository at https://github.com/BladeGroup/gitlab-oe Although we're using this in production, it still has a couple of rough edges and may need tuning for different usages. We'd love to hear how well it fits (or doesn't fit ;) with other use cases, and will gladly consider evolutions to make it more generally usable. Best regards, -- Yann Dirson Blade / Shadow -- http://shadow.tech -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed
All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 280 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “2.8”, “2.9’, "2.99" and "Future", the more pressing/urgent issues being in "2.8" and then “2.9”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, *Stephen K. Jolley* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*:(208) 244-4460 * *Email*: *stephen.k.jol...@intel.com * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 14/15] openssh: add CAVS tests for FIPS validation
Please include the commit from fedora for these files.
Also, I like how the cavs were packaged. An additional test should be added to
the ptest if the cavs are installed.
--Mark
On 9/22/19 9:57 AM, Hongxu Jia wrote:
> Refer the latest Fedora to add cavs test binary for the aes-ctr [1]
> and SSH KDF CAVS test driver [2]
>
> [1]
> http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch
> [2]
> http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.7p1-kdf-cavs.patch
>
> Signed-off-by: Hongxu Jia
> ---
> .../openssh/openssh-6.6p1-ctr-cavstest.patch | 289 +
> .../openssh/openssh/openssh-6.7p1-kdf-cavs.patch | 654
> +
> recipes-connectivity/openssh/openssh_fips.inc | 9 +
> 3 files changed, 952 insertions(+)
> create mode 100644
> recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
> create mode 100644
> recipes-connectivity/openssh/openssh/openssh-6.7p1-kdf-cavs.patch
>
> diff --git
> a/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
> b/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
> new file mode 100644
> index 000..038efa0
> --- /dev/null
> +++ b/recipes-connectivity/openssh/openssh/openssh-6.6p1-ctr-cavstest.patch
> @@ -0,0 +1,289 @@
> +From a94a3d95439018dc7d276ec72de91af369ea413e Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia
> +Date: Sun, 22 Sep 2019 21:32:18 +0800
> +Subject: [PATCH 1/2] add CAVS test driver for the aes-ctr ciphers
> +
> +Original submission to Fedora, see:
> +
> https://lists.fedoraproject.org/pipermail/scm-commits/2012-January/715044.html
> +
> +this version download from:
> +
> http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-6.6p1-ctr-cavstest.patch
> + (as of commit 991b66246f5151884b63c6d1232610a4569642a5)
> +
> +Makefile.in slightly modified for integration
> +
> +This is the makefile.in change for the normal configuration.
> +
> +Signed-off-by: Mark Hatle
> +
> +Upstream-Status: Inappropriate [oe specific]
> +Signed-off-by: Hongxu Jia
> +---
> + Makefile.in| 7 +-
> + ctr-cavstest.c | 215
> +
> + 2 files changed, 221 insertions(+), 1 deletion(-)
> + create mode 100644 ctr-cavstest.c
> +
> +diff --git a/Makefile.in b/Makefile.in
> +index ddd1804..cb34681 100644
> +--- a/Makefile.in
> b/Makefile.in
> +@@ -23,6 +23,7 @@ SSH_PROGRAM=@bindir@/ssh
> + ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
> + SFTP_SERVER=$(libexecdir)/sftp-server
> + SSH_KEYSIGN=$(libexecdir)/ssh-keysign
> ++CTR_CAVSTEST=$(libexecdir)/ctr-cavstest
> + SSH_PKCS11_HELPER=$(libexecdir)/ssh-pkcs11-helper
> + PRIVSEP_PATH=@PRIVSEP_PATH@
> + SSH_PRIVSEP_USER=@SSH_PRIVSEP_USER@
> +@@ -60,7 +61,7 @@ EXEEXT=@EXEEXT@
> + MANFMT=@MANFMT@
> + MKDIR_P=@MKDIR_P@
> +
> +-TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT)
> ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-pkcs11-helper$(EXEEXT)
> ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) sftp$(EXEEXT)
> ++TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT)
> ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-pkcs11-helper$(EXEEXT)
> ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) sftp$(EXEEXT)
> ctr-cavstest$(EXEEXT)
> +
> + XMSS_OBJS=\
> + ssh-xmss.o \
> +@@ -193,6 +194,9 @@ ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a
> ssh-keysign.o readconf.o uidswap.o c
> + ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o
> ssh-pkcs11.o
> + $(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh
> -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
> +
> ++ctr-cavstest$(EXEEXT): $(LIBCOMPAT) libssh.a ctr-cavstest.o
> ++$(LD) -o $@ ctr-cavstest.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh
> -lfipscheck $(LIBS)
> ++
> + ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o
> + $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh
> -lfipscheck $(LIBS)
> +
> +@@ -343,6 +347,7 @@ install-files:
> + $(INSTALL) -m 0755 $(STRIP_OPT) ssh-keyscan$(EXEEXT)
> $(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
> + $(INSTALL) -m 0755 $(STRIP_OPT) sshd$(EXEEXT)
> $(DESTDIR)$(sbindir)/sshd$(EXEEXT)
> + $(INSTALL) -m 4711 $(STRIP_OPT) ssh-keysign$(EXEEXT)
> $(DESTDIR)$(SSH_KEYSIGN)$(EXEEXT)
> ++$(INSTALL) -m 0755 $(STRIP_OPT) ctr-cavstest$(EXEEXT)
> $(DESTDIR)$(libexecdir)/ctr-cavstest$(EXEEXT)
> + $(INSTALL) -m 0755 $(STRIP_OPT) ssh-pkcs11-helper$(EXEEXT)
> $(DESTDIR)$(SSH_PKCS11_HELPER)$(EXEEXT)
> + $(INSTALL) -m 0755 $(STRIP_OPT) sftp$(EXEEXT)
> $(DESTDIR)$(bindir)/sftp$(EXEEXT)
> + $(INSTALL) -m 0755 $(STRIP_OPT) sftp-server$(EXEEXT)
> $(DESTDIR)$(SFTP_SERVER)$(EXEEXT)
> +diff --git a/ctr-cavstest.c b/ctr-cavstest.c
> +new file mode 100644
> +index 000..0d4776b
> +--- /dev/null
> b/ctr-cavstest.c
> +@@ -0,0 +1,215 @@
> ++/*
> ++ *
> ++ * invocation (all of the following are equal):
> ++ * .
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
On 23/09/2019 15:26, Jean-Baptiste MARIE wrote: Indeed wayland is enabled in my distro features, so my question is more: is there any reason to remove x11 from package config when "wayland" is enabled as a distro feature (but maybe it is no longer a question to be addressed ot yocto community)? As Ross mentioned, there can both be built. That's a question for the maintainers of your BSP, they did that for a reason. Plain oe-core will enable both if the DISTRO has both x11 and wayland enabled. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
On Mon, 23 Sep 2019 at 17:26, Jean-Baptiste MARIE
wrote:
> Ok, got it thanks.
>
> Indeed wayland is enabled in my distro features, so my question is more:
> is there any reason to remove x11 from package config when "wayland" is
> enabled as a distro feature (but maybe it is no longer a question to be
> addressed ot yocto community)? As Ross mentioned, there can both be built.
>
No generic reason that I can think of. The meta-freescale maintainers
probably didn't add it just for the fun of it ... but you'll have to
ask them (or try removing the PACKAGECONFIG modifications -- maybe the
reasons become obvious when something breaks horribly).
Jussi
>
>
> On Mon, Sep 23, 2019 at 3:42 PM Jussi Kukkonen wrote:
>
>>
>> On Mon, 23 Sep 2019 at 15:48, Jean-Baptiste MARIE <
>> jbaptiste.ma...@gmail.com> wrote:
>>
>>> PACKAGECONFIG_remove_imxgpu2d = " \
>>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>>> "
>>>
>>
>> What Ross said: If wayland is in distro features this will remove the x11
>> packageconfig which means disabling the X11 backend for Gdk and removing
>> the X11-related API from libgdk3.so (and not installing the gdk-x11-3.0.pc
>> file which was the immediate reason for your build failure).
>>
>> Jussi
>>
>>
>>>
>>> CFLAGS_append_imxgpu2d = " \
>>> -DLINUX \
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
>>> -DEGL_API_WL', '', d)} \
>>> "
>>>
>>> - meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk
>>> recipe with the .bbappend as shown below:
>>>
>>> DEPENDS_append_imxgpu2d = " virtual/egl"
>>>
>>> PACKAGECONFIG_remove_imxgpu2d = " \
>>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>>> "
>>>
>>> I do not see any reason why gdk-x11-3.0 would not be built
>>>
>>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 9/15] openssh: port sshd_check_keys from oe-core
Please include the oe-core commit that this version was taken from. It'll be
easier to uprev, if needed, if we need to.
--Mark
On 9/22/19 9:57 AM, Hongxu Jia wrote:
> Signed-off-by: Hongxu Jia
> ---
> .../openssh/openssh/sshd_check_keys| 78
> ++
> 1 file changed, 78 insertions(+)
> create mode 100644 recipes-connectivity/openssh/openssh/sshd_check_keys
>
> diff --git a/recipes-connectivity/openssh/openssh/sshd_check_keys
> b/recipes-connectivity/openssh/openssh/sshd_check_keys
> new file mode 100644
> index 000..1931dc7
> --- /dev/null
> +++ b/recipes-connectivity/openssh/openssh/sshd_check_keys
> @@ -0,0 +1,78 @@
> +#! /bin/sh
> +
> +generate_key() {
> +local FILE=$1
> +local TYPE=$2
> +local DIR="$(dirname "$FILE")"
> +
> +mkdir -p "$DIR"
> +ssh-keygen -q -f "${FILE}.tmp" -N '' -t $TYPE
> +
> +# Atomically rename file public key
> +mv -f "${FILE}.tmp.pub" "${FILE}.pub"
> +
> +# This sync does double duty: Ensuring that the data in the temporary
> +# private key file is on disk before the rename, and ensuring that the
> +# public key rename is completed before the private key rename, since we
> +# switch on the existence of the private key to trigger key generation.
> +# This does mean it is possible for the public key to exist, but be
> garbage
> +# but this is OK because in that case the private key won't exist and the
> +# keys will be regenerated.
> +#
> +# In the event that sync understands arguments that limit what it tries
> to
> +# fsync(), we provided them. If it does not, it will simply call sync()
> +# which is just as well
> +sync "${FILE}.pub" "$DIR" "${FILE}.tmp"
> +
> +mv "${FILE}.tmp" "$FILE"
> +
> +# sync to ensure the atomic rename is committed
> +sync "$DIR"
> +}
> +
> +# /etc/default/ssh may set SYSCONFDIR and SSHD_OPTS
> +if test -f /etc/default/ssh; then
> +. /etc/default/ssh
> +fi
> +
> +[ -z "$SYSCONFDIR" ] && SYSCONFDIR=/etc/ssh
> +mkdir -p $SYSCONFDIR
> +
> +# parse sshd options
> +set -- ${SSHD_OPTS} --
> +sshd_config=/etc/ssh/sshd_config
> +while true ; do
> +case "$1" in
> +-f*) if [ "$1" = "-f" ] ; then
> +sshd_config="$2"
> +shift
> +else
> +sshd_config="${1#-f}"
> +fi
> +shift
> +;;
> +--) shift; break;;
> +*) shift;;
> +esac
> +done
> +
> +HOST_KEYS=$(sed -n 's/^[ \t]*HostKey[ \t]\+\(.*\)/\1/p' "${sshd_config}")
> +[ -z "${HOST_KEYS}" ] && HOST_KEYS="$SYSCONFDIR/ssh_host_rsa_key
> $SYSCONFDIR/ssh_host_ecdsa_key $SYSCONFDIR/ssh_host_ed25519_key"
> +
> +for key in ${HOST_KEYS} ; do
> +[ -f $key ] && continue
> +case $key in
> +*_rsa_key)
> +echo " generating ssh RSA host key..."
> +generate_key $key rsa
> +;;
> +*_ecdsa_key)
> +echo " generating ssh ECDSA host key..."
> +generate_key $key ecdsa
> +;;
> +*_ed25519_key)
> +echo " generating ssh ED25519 host key..."
> +generate_key $key ed25519
> +;;
> +esac
> +done
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 5/15] openssh: add generation of HMAC checksums in pkg_postinst
Same comment here as in the fipscheck about the post install stuff.
--Mark
On 9/22/19 9:56 AM, Hongxu Jia wrote:
> Refer
> https://src.fedoraproject.org/rpms/openssh/c/d93958db19129e0f4615865eab22fb36e1f4fb8a
>
> Signed-off-by: Hongxu Jia
> ---
> recipes-connectivity/openssh/openssh_fips.inc | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/recipes-connectivity/openssh/openssh_fips.inc
> b/recipes-connectivity/openssh/openssh_fips.inc
> index 99a3482..df84c39 100644
> --- a/recipes-connectivity/openssh/openssh_fips.inc
> +++ b/recipes-connectivity/openssh/openssh_fips.inc
> @@ -6,3 +6,29 @@ DEPENDS += " \
> SRC_URI += " \
> file://0001-openssh-8.0p1-fips.patch \
> "
> +
> +do_install_append() {
> +install -d ${D}${libdir}/fipscheck
> +}
> +
> +inherit qemu
> +
> +pkg_postinst_append_${PN}-ssh () {
> +if [ -n "$D" ]; then
> +${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
> +-d $D${libdir}/fipscheck $D${bindir}/ssh.${BPN}
> +else
> +${bindir}/fipshmac -d ${libdir}/fipscheck ${bindir}/ssh.${BPN}
> +fi
> +}
> +
> +pkg_postinst_append_${PN}-sshd () {
> +if [ -n "$D" ]; then
> +${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
> +-d $D${libdir}/fipscheck $D${sbindir}/sshd
> +else
> +${bindir}/fipshmac -d ${libdir}/fipscheck ${sbindir}/sshd
> +fi
> +}
> +
> +FILES_${PN} += "${libdir}/fipscheck"
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 4/15] fipscheck: enable fipscheck on target
On 9/22/19 9:56 AM, Hongxu Jia wrote:
> Refer Fedora/RedHat's way
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/dracut
>
> Signed-off-by: Hongxu Jia
> ---
> recipes-connectivity/openssh/fipscheck_1.5.0.bb | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> index 0a06bd3..23a4123 100644
> --- a/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> +++ b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> @@ -28,6 +28,10 @@ EXTRA_OEMAKE += " \
> -I${STAGING_LIBDIR_NATIVE}/ssl/fips-2.0/include \
> "
> do_install_append() {
> +# Is't the fedora way to enable fipscheck
> +install -d ${D}${sysconfdir}
> +touch ${D}${sysconfdir}/system-fips
> +
After researching the system-fips, I'm wondering if it would be better to enable
this in the image recipe as part of an 'IMAGE_CLASSES'. Basically if FIPS-140-2
is enabled, then we can touch the file as a post image generation activity.
The alternative would be to create an initscript that would check for 'fips=1'
on the kernel command line and then create that file (or remove it?) as well.
I'm not sure which is the better strategy. (For read-only devices the image
thing is better.. since /etc/ is otherwise read-only.)
--Mark
> install -d ${D}${libdir}/fipscheck
> }
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 3/15] fipscheck: add generation of the checksums in pkg_postinst
On 9/22/19 9:56 AM, Hongxu Jia wrote:
> Refer https://pagure.io/fipscheck/c/489bc3ab3f73707e12b6c2644d80af5ff6fbbf70
>
> Signed-off-by: Hongxu Jia
> ---
> recipes-connectivity/openssh/fipscheck_1.5.0.bb | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> index 68051d2..0a06bd3 100644
> --- a/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> +++ b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> @@ -27,4 +27,22 @@ EXTRA_OECONF += " \
> EXTRA_OEMAKE += " \
> -I${STAGING_LIBDIR_NATIVE}/ssl/fips-2.0/include \
> "
> +do_install_append() {
> +install -d ${D}${libdir}/fipscheck
> +}
>
> +inherit qemu
> +
> +pkg_postinst_${PN} () {
> +if [ -n "$D" ]; then
> +${@qemu_run_binary(d, '$D', '${bindir}/fipshmac')} \
> +-d $D${libdir}/fipscheck $D${bindir}/fipscheck
> $D${libdir}/libfipscheck.so.1.2.1 && \
> +ln -s libfipscheck.so.1.2.1.hmac
> $D${libdir}/fipscheck/libfipscheck.so.1.hmac
> +else
> +${bindir}/fipshmac -d ${libdir}/fipscheck ${bindir}/fipscheck \
> +${libdir}/libfipscheck.so.1.2.1 && \
> +ln -s libfipscheck.so.1.2.1.hmac
> ${libdir}/fipscheck/libfipscheck.so.1.hmac
> +fi
> +}
The way this works has changed a bit since I really knew it. I was looking in
the manpages.bbclass and they have the following:
> if ${@bb.utils.contains('PACKAGECONFIG', 'manpages', 'true', 'false',
> d)}; then
> if test -n "$D"; then
> if ${@bb.utils.contains('MACHINE_FEATURES',
> 'qemu-usermode', 'true','false', d)}; then
> sed "s:\(\s\)/:\1$D/:g"
> $D${sysconfdir}/man_db.conf | ${@qemu_run_binary(d, '$D', '${bindir}/mandb')}
> -C - -u -q $D${mandir}
> mkdir -p $D${localstatedir}/cache/man
> mv $D${mandir}/index.db
> $D${localstatedir}/cache/man
> else
> $INTERCEPT_DIR/postinst_intercept
> delay_to_first_boot ${PKG} mlprefix=${MLPREFIX}
> fi
> else
> mandb -q
> fi
> fi
That is checking for the presence of the MACHINE_FEATURE. I'm not sure I like
that in this case though since it makes these recipes machine specific.
But I do think we need the delay until first boot part.
Jason, I know you've been working on first boot things for a while, any opinion?
--Mark
> +
> +FILES_${PN} += "${libdir}/fipscheck"
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
Ok, got it thanks.
Indeed wayland is enabled in my distro features, so my question is more: is
there any reason to remove x11 from package config when "wayland" is
enabled as a distro feature (but maybe it is no longer a question to be
addressed ot yocto community)? As Ross mentioned, there can both be built.
On Mon, Sep 23, 2019 at 3:42 PM Jussi Kukkonen wrote:
>
> On Mon, 23 Sep 2019 at 15:48, Jean-Baptiste MARIE <
> jbaptiste.ma...@gmail.com> wrote:
>
>> PACKAGECONFIG_remove_imxgpu2d = " \
>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>> "
>>
>
> What Ross said: If wayland is in distro features this will remove the x11
> packageconfig which means disabling the X11 backend for Gdk and removing
> the X11-related API from libgdk3.so (and not installing the gdk-x11-3.0.pc
> file which was the immediate reason for your build failure).
>
> Jussi
>
>
>>
>> CFLAGS_append_imxgpu2d = " \
>> -DLINUX \
>> ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
>> -DEGL_API_WL', '', d)} \
>> "
>>
>> - meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk recipe
>> with the .bbappend as shown below:
>>
>> DEPENDS_append_imxgpu2d = " virtual/egl"
>>
>> PACKAGECONFIG_remove_imxgpu2d = " \
>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>> "
>>
>> I do not see any reason why gdk-x11-3.0 would not be built
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-openssl102-fips][PATCH 2/15] openssh_8.%.bbappend: support fips 140-2
On 9/22/19 9:56 AM, Hongxu Jia wrote: > Signed-off-by: Hongxu Jia > --- > .../openssh/openssh/0001-openssh-8.0p1-fips.patch | 528 > + > recipes-connectivity/openssh/openssh_8.%.bbappend | 4 + > recipes-connectivity/openssh/openssh_fips.inc | 8 + > 3 files changed, 540 insertions(+) > create mode 100644 > recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch > create mode 100644 recipes-connectivity/openssh/openssh_8.%.bbappend > create mode 100644 recipes-connectivity/openssh/openssh_fips.inc > > diff --git > a/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch > b/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch > new file mode 100644 > index 000..fd0a411 > --- /dev/null > +++ b/recipes-connectivity/openssh/openssh/0001-openssh-8.0p1-fips.patch > @@ -0,0 +1,528 @@ > +From 255e5dcdec36df7222f69b253dfc05be63927ed2 Mon Sep 17 00:00:00 2001 > +From: Hongxu Jia > +Date: Fri, 20 Sep 2019 17:59:00 +0800 > +Subject: [PATCH] openssh 8.0p1 fips > + > +Port openssh-7.7p1-fips.patch from Fedora > +https://src.fedoraproject.org/rpms/openssh.git Can you include the commit id of the Fedora version where you pulled the patch from? This will make it easier to update in the future. --Mark > +Upstream-Status: Inappropriate [oe specific] > + > +Signed-off-by: Hongxu Jia > +--- > + Makefile.in | 14 +++--- > + cipher-ctr.c | 3 ++- > + clientloop.c | 3 ++- > + dh.c | 40 > + dh.h | 1 + > + kex.c| 5 - > + kexgexc.c| 5 + > + myproposal.h | 40 > + readconf.c | 17 + > + sandbox-seccomp-filter.c | 3 +++ > + servconf.c | 19 ++- > + ssh-keygen.c | 6 ++ > + ssh.c| 16 > + sshconnect2.c| 11 --- > + sshd.c | 19 +++ > + sshkey.c | 4 > + 16 files changed, 176 insertions(+), 30 deletions(-) > + > +diff --git a/Makefile.in b/Makefile.in > +index 6f001bb..ddd1804 100644 > +--- a/Makefile.in > b/Makefile.in > +@@ -170,31 +170,31 @@ libssh.a: $(LIBSSH_OBJS) > + $(RANLIB) $@ > + > + ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS) > +-$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) > $(LIBS) $(GSSLIBS) > ++$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck > $(SSHLIBS) $(LIBS) $(GSSLIBS) > + > + sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) > +-$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) > $(LIBS) $(GSSLIBS) $(K5LIBS) > ++$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck > $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS) > + > + scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o > + $(LD) -o $@ scp.o progressmeter.o $(LDFLAGS) -lssh -lopenbsd-compat > $(LIBS) > + > + ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o > +-$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) > ++$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck > $(LIBS) > + > + ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o > +-$(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh > -lopenbsd-compat $(LIBS) > ++$(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh > -lopenbsd-compat -lfipscheck $(LIBS) > + > + ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o > +-$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) > ++$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat -lfipscheck > $(LIBS) > + > + ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keysign.o readconf.o > uidswap.o compat.o > +-$(LD) -o $@ ssh-keysign.o readconf.o uidswap.o $(LDFLAGS) -lssh > -lopenbsd-compat $(LIBS) > ++$(LD) -o $@ ssh-keysign.o readconf.o uidswap.o $(LDFLAGS) -lssh > -lopenbsd-compat -lfipscheck $(LIBS) > + > + ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o > ssh-pkcs11.o > + $(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh > -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS) > + > + ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o > +-$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh > $(LIBS) > ++$(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh > -lfipscheck $(LIBS) > + > + sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o > sftp-server.o sftp-server-main.o > + $(LD) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) > -lssh -lopenbsd-compat $(LIBS) > +diff --git a/cipher-ctr.c b/cipher-ctr.c > +index 32771f2..74fac3b 100644 > +--- a/cipher-ctr.c > b/cipher-ctr.c > +@@ -138,7 +138,8 @@ evp_aes_
Re: [yocto] [meta-openssl102-fips][PATCH 1/15] fipscheck: add 1.5.0
Please include the commit id of the Fedora version that was included. It will
help us review changes in the future.
On 9/22/19 9:56 AM, Hongxu Jia wrote:
> Port it from fedora:
> https://src.fedoraproject.org/rpms/fipscheck
>
> It is required by openssh fips.
>
> Signed-off-by: Hongxu Jia
> ---
> .../0001-compat-fip-with-openssl-1.0.2.patch | 34
> ++
> recipes-connectivity/openssh/fipscheck_1.5.0.bb| 30 +++
> templates/feature/openssl-fips/template.conf | 2 +-
> 3 files changed, 65 insertions(+), 1 deletion(-)
> create mode 100644
> recipes-connectivity/openssh/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
> create mode 100644 recipes-connectivity/openssh/fipscheck_1.5.0.bb
>
> diff --git
> a/recipes-connectivity/openssh/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
>
> b/recipes-connectivity/openssh/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
> new file mode 100644
> index 000..22e5a62
> --- /dev/null
> +++
> b/recipes-connectivity/openssh/fipscheck/0001-compat-fip-with-openssl-1.0.2.patch
> @@ -0,0 +1,34 @@
> +From 3147ae2a63f10f9bbdd0a617b450ff8b9868e60f Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia
> +Date: Fri, 20 Sep 2019 17:51:09 +0800
> +Subject: [PATCH] compat fip with openssl 1.0.2
> +
> +In /usr/lib64/ssl/fips-2.0/include/openssl/opensslv.h
> +...
> +define OPENSSL_VERSION_NUMBER 0x1010L
> +...
> +Since fips include file compat with openssl 1.1.0, do not include it
> +in Yocto
> +
> +Upstream-Status: Inappropriate [oe specific]
> +
> +Signed-off-by: Hongxu Jia
> +---
> + src/filehmac.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/src/filehmac.c b/src/filehmac.c
> +index a8eef00..0b36cec 100644
> +--- a/src/filehmac.c
> b/src/filehmac.c
> +@@ -41,7 +41,6 @@
> + #include
> +
> + #if defined(WITH_OPENSSL)
> +-#include
> + #include
> + #include
> + #elif defined(WITH_NSS)
> +--
> +2.7.4
> +
> diff --git a/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> new file mode 100644
> index 000..68051d2
> --- /dev/null
> +++ b/recipes-connectivity/openssh/fipscheck_1.5.0.bb
> @@ -0,0 +1,30 @@
> +SUMMARY = "A library for integrity verification of FIPS validated modules"
> +DESCRIPTION = "FIPSCheck is a library for integrity verification of FIPS
> validated \
> +modules. The package also provides helper binaries for creation and \
> +verification of the HMAC-SHA256 checksum files."
> +HOMEPAGE = "https://pagure.io/fipscheck";
> +SECTION = "libs/network"
> +
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=35f2904ce138ac5fa63e7cedf96bbedf"
> +
> +SRC_URI = "https://releases.pagure.org/fipscheck/${BPN}-${PV}.tar.bz2 \
> + file://0001-compat-fip-with-openssl-1.0.2.patch \
> +"
> +SRC_URI[md5sum] = "86e756a7d2aa15f3f91033fb3eced99b"
> +SRC_URI[sha256sum] =
> "7ba38100ced187f44b12dd52c8c74db8f366a2a8b9da819bd3e7c6ea17f469d5"
> +
> +DEPENDS = " \
> +openssl \
> +openssl-fips \
> +"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF += " \
> +--disable-static \
> +"
> +EXTRA_OEMAKE += " \
> +-I${STAGING_LIBDIR_NATIVE}/ssl/fips-2.0/include \
> +"
> +
> diff --git a/templates/feature/openssl-fips/template.conf
> b/templates/feature/openssl-fips/template.conf
> index 6da678c..9a551c3 100644
> --- a/templates/feature/openssl-fips/template.conf
> +++ b/templates/feature/openssl-fips/template.conf
> @@ -8,4 +8,4 @@ OPENSSL_FIPS_PREBUILT ??= ""
>
> PNWHITELIST_meta-openssl-one-zero-two-fips += 'openssl-fips'
> PNWHITELIST_meta-openssl-one-zero-two-fips += 'openssl-fips-example'
> -
> +PNWHITELIST_meta-openssl-one-zero-two-fips += 'fipscheck'
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-anaconda][PATCH 1/1] initramfs-module-setup-live: call udev settle before umounting /run/media/*
Merged
//Hongxu
On 9/23/19 2:41 PM, Ovidiu Panait wrote:
This fixes a race conditition which leaves devices mounted, causing the
following anaconda installation failure:
File "/usr/lib64/python3.5/site-packages/gi/overrides/BlockDev.py", line 963,
in wrapped
raise transform[1](msg)
File "/usr/lib64/python3.5/site-packages/blivet/devices/lvm.py", line 913, in
_teardown
blockdev.lvm.lvdeactivate(self.vg.name, self._name)
File "/usr/lib64/python3.5/site-packages/blivet/threads.py", line 53, in
run_with_lock
return m(*args, **kwargs)
File "/usr/lib64/python3.5/site-packages/blivet/devices/storage.py", line 431,
in teardown
self._teardown(recursive=recursive)
File "/usr/lib64/python3.5/site-packages/blivet/threads.py", line 53, in
run_with_lock
return m(*args, **kwargs)
File "/usr/lib64/python3.5/site-packages/blivet/devices/lvm.py", line 1933, in
teardown
return DMDevice.teardown(self, recursive)
gi.overrides.BlockDev.LVMError: Process reported exit code 5: Logical volume
wrll_intel-x86-64/root contains a filesystem in use.
Signed-off-by: Ovidiu Panait
---
recipes-installer/initrdscripts/files/umountfs | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-installer/initrdscripts/files/umountfs
b/recipes-installer/initrdscripts/files/umountfs
index f01adea..4792110 100644
--- a/recipes-installer/initrdscripts/files/umountfs
+++ b/recipes-installer/initrdscripts/files/umountfs
@@ -3,6 +3,9 @@ umountfs_enabled() {
}
umountfs_run() {
+# Make sure /run/media is fully populated
+udevadm settle
+
# Umount other media for anaconda
for dir in `awk '/\/dev.* \/run\/media/{print $2}' /proc/mounts`; do
umount $dir
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
On Mon, 23 Sep 2019 at 15:48, Jean-Baptiste MARIE
wrote:
> PACKAGECONFIG_remove_imxgpu2d = " \
> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
> "
>
What Ross said: If wayland is in distro features this will remove the x11
packageconfig which means disabling the X11 backend for Gdk and removing
the X11-related API from libgdk3.so (and not installing the gdk-x11-3.0.pc
file which was the immediate reason for your build failure).
Jussi
>
> CFLAGS_append_imxgpu2d = " \
> -DLINUX \
> ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
> -DEGL_API_WL', '', d)} \
> "
>
> - meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk recipe
> with the .bbappend as shown below:
>
> DEPENDS_append_imxgpu2d = " virtual/egl"
>
> PACKAGECONFIG_remove_imxgpu2d = " \
> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
> "
>
> I do not see any reason why gdk-x11-3.0 would not be built
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
On 23/09/2019 13:48, Jean-Baptiste MARIE wrote:
PACKAGECONFIG_remove_imxgpu2d = " \
${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
"
I do not see any reason why gdk-x11-3.0 would not be built
So if Wayland is enabled, then it disables X11. Do you have Wayland
enabled? I wonder why the BSP does this: you can build both just fine.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure
Hello,
Thanks for your answer. It seems "x11" is enabled as a distro feature
during my build.
I am using the following layers:
- meta-freescale (branch rocko): that meta overloads gtk recipe as shown
below:
PACKAGECONFIG_remove_imxgpu2d = " \
${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
"
CFLAGS_append_imxgpu2d = " \
-DLINUX \
${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
-DEGL_API_WL', '', d)} \
"
- meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk recipe
with the .bbappend as shown below:
DEPENDS_append_imxgpu2d = " virtual/egl"
PACKAGECONFIG_remove_imxgpu2d = " \
${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
"
I do not see any reason why gdk-x11-3.0 would not be built
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debug-files in SDK
On 23/09/2019 10:19, Teemu K wrote: One question is that is there a way to make package that would contain only dpg-pkgs and src-pkgs? Ie. it'd be like 'debug-addition' for SDK? I know how to install those things to target, but how to get them to a package (or in separate directory) to host. This is where you'd use an Extensible SDK instead of a traditional SDK, where you can install packages into the sysroot after installation. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debug-files in SDK
On Thu, Sep 12, 2019 at 1:52 PM Ross Burton wrote:
>
> On 12/09/2019 11:13, Teemu K wrote:
> > Hi,
> >
> > I'm not entirely sure if this is bug or feature.
> >
> > I've created sdk to my image with populate_sdk - command. I noticed
> > that in the SDK the x86_64 - directory is 384MB and that contains all
> > the toolchains etc., but the target side
> > (cortexa9hf-neon-poky-linux-gnueabi) is 5.7GB. Majority of it is in
> > .debug - directories.
> >
> > What causes the confusion here is that I haven't enabled debug-symbols
> > in my local.conf and I don't have any other debug stuff enabled there
> > either. Are those the debug-symbols that can be used to debug software
> > on target with GDB for example? I thought that debug symbol
> > information needs to be separately enabled.
> >
> > If they are not, then can I get rid of them somehow?
>
> SDKIMAGE_FEATURES ??= "dev-pkgs dbg-pkgs src-pkgs
> ${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 'doc-pkgs',
> '', d)}"
>
> SDKs by default contain debug symbols, and yes they can be used with gdb
> to debug on target.
>
> If you don't want them in the SDK, remove dbg-pkgs (and src-pkgs whilst
> you're there) from SDKIMAGE_FEATURES.
This is exactly what I was looking for. Thanks for that.
One question is that is there a way to make package that would contain
only dpg-pkgs and src-pkgs? Ie. it'd be like 'debug-addition' for SDK?
I know how to install those things to target, but how to get them to a
package (or in separate directory) to host.
-Teemu Keskinarkaus
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M3.rc1)
>-Original Message- >From: richard.pur...@linuxfoundation.org >Sent: Monday, 23 September, 2019 3:46 PM >To: Jain, Sangeeta ; yocto@yoctoproject.org; >Tummalapalli, Vineela >Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv >; Yeoh, Ee Peng ; Chan, >Aaron Chun Yew ; Ang, Chin Huat >; akuster...@gmail.com; sjolley.yp...@gmail.com >Subject: Re: QA notification for completed autobuilder build (yocto-2.8_M3.rc1) > >On Mon, 2019-09-23 at 07:37 +, Jain, Sangeeta wrote: >> Hi Richard, >> >> LSB support was expected to be removed from build 'yocto-2.8_M3.rc1' >> onwards, but link on AB still points to LSB images. >> The images present inside >> https://autobuilder.yocto.io/pub/releases/yocto- >2.8_M3.rc1/machines/genericx86-64-lsb/ >> are built with systemd as init manager. >> >> Can you please confirm if these are altcfg images and the link name >> needs to updated? > >Well spotted! > >I can confirm these are altcfg images which have systemd as the init manager. > >For backwards compatibility the autobuilder target names didn't change but the >configuration they're built with did. I hadn't realised this would be visible >in the >release so we may need to think about that for >M4 but they are altcfg images. > Thanks for confirmation. We will include them in test coverage. >[Added Vineela to cc:] > >Cheers, > >Richard Thanks, Sangeeta -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M3.rc1)
On Mon, 2019-09-23 at 07:37 +, Jain, Sangeeta wrote: > Hi Richard, > > LSB support was expected to be removed from build 'yocto-2.8_M3.rc1' > onwards, but link on AB still points to LSB images. > The images present inside > https://autobuilder.yocto.io/pub/releases/yocto-2.8_M3.rc1/machines/genericx86-64-lsb/ > are built with systemd as init manager. > > Can you please confirm if these are altcfg images and the link name > needs to updated? Well spotted! I can confirm these are altcfg images which have systemd as the init manager. For backwards compatibility the autobuilder target names didn't change but the configuration they're built with did. I hadn't realised this would be visible in the release so we may need to think about that for M4 but they are altcfg images. [Added Vineela to cc:] Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M3.rc1)
Hi Richard, LSB support was expected to be removed from build 'yocto-2.8_M3.rc1' onwards, but link on AB still points to LSB images. The images present inside https://autobuilder.yocto.io/pub/releases/yocto-2.8_M3.rc1/machines/genericx86-64-lsb/ are built with systemd as init manager. Can you please confirm if these are altcfg images and the link name needs to updated? Thanks, Sangeeta Jain >-Original Message- >From: Jain, Sangeeta >Sent: Monday, 23 September, 2019 11:09 AM >To: pokybu...@ubuntu1804-ty-1.yocto.io; yocto@yoctoproject.org >Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv >; Yeoh, Ee Peng ; Chan, >Aaron Chun Yew ; Ang, Chin Huat >; richard.pur...@linuxfoundation.org; >akuster...@gmail.com; sjolley.yp...@gmail.com; Tummalapalli, Vineela > >Subject: RE: QA notification for completed autobuilder build (yocto-2.8_M3.rc1) > >Hello All, > >Intel and WR YP QA is planning for QA execution for YP build yocto-2.8_M3.rc1. >We are planning to execute following tests for this cycle: > >OEQA-manual tests for following module: >1. OE-Core >2. BSP-hw >3. BSP-Qemu > >Runtime auto test for following platforms: >1. MinnowTurbot 32-bit >2. Coffee Lake >3. NUC 7 >4. NUC 6 >5. Edgerouter >6. MPC8315e-rdb >7. Beaglebone > >ETA for completion is next Thursday, September 26. > >Thanks & Regards, >Sangeeta Jain > >>-Original Message- >>From: pokybu...@ubuntu1804-ty-1.yocto.io >>[mailto:pokybuild@ubuntu1804-ty- 1.yocto.io] >>Sent: Friday, September 20, 2019 1:01 PM >>To: yocto@yoctoproject.org >>Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv >>; Yeoh, Ee Peng ; >>Chan, Aaron Chun Yew ; Ang, Chin Huat >>; richard.pur...@linuxfoundation.org; >>akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta >> >>Subject: QA notification for completed autobuilder build >>(yocto-2.8_M3.rc1) >> >> >>A build flagged for QA (yocto-2.8_M3.rc1) was completed on the >>autobuilder and is available at: >> >> >>https://autobuilder.yocto.io/pub/releases/yocto-2.8_M3.rc1 >> >> >>Build hash information: >> >>bitbake: 797354d285f6d624d9adb52bab65823572da0e39 >>meta-gplv2: 1e2480e50f34e55bdfd5e06f98441e03a3752d5a >>meta-intel: 655dfaec95196b9c0e15d34f490e4a51a7d501e3 >>meta-mingw: 9df4e115ab9a7ab23f81fdbcc62b2a0269d6377f >>oecore: 95ad5626296380358c8a502a3e04879dab653d78 >>poky: 81f9e815d36848761a9dfa94b00ad998bb39a4a6 >> >> >> >>This is an automated message from the Yocto Project Autobuilder >>Git: git://git.yoctoproject.org/yocto-autobuilder2 >>Email: richard.pur...@linuxfoundation.org >> >> >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
