Re: [OE-core] [PATCH 2/2] weston: upgrade to 4.0.0
On 4/11/18 3:11 PM, Paul Eggleton wrote: Yes, this is a bit of a known bug although I didn't actually file one until now: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12674 Cheers, Paul On Wednesday, 11 April 2018 11:17:51 AM NZST Burton, Ross wrote: Ah presumably this is because the U-S is after the scissors. Denys, when you add it back, can you put it above the ---? Upstream-Status is a Yocto project invention that can confuse other communities when submitting the patches for those packages upstream and Sign-off-by is also in same bucket in many upstream packages. We need to be able to support patch headers that are git am'able upstream as well as to openembedded recipe created trees. One still has to delete these tags but if you forget its still is ok since they will be ignored with git am. Ross On 11 April 2018 at 00:16, Burton, Ross wrote: On 10 April 2018 at 20:06, Denys Dmytriyenko wrote: diff --git a/meta/recipes-graphics/wayland/weston/0001-make-error- portable.patch b/meta/recipes-graphics/wayland/weston/0001-make-error- portable.patch index 0671a45..6799254 100644 --- a/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch +++ b/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch @@ -1,26 +1,25 @@ -From c22e90365d89346258394833cbcad03ff32b2e27 Mon Sep 17 00:00:00 2001 +From ad1d2161c811cff25d1684c33611f300adb753bc Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 May 2015 20:56:00 -0700 -Subject: [PATCH weston] make error() portable +Subject: [PATCH] make error() portable error() is not posix but gnu extension so may not be available on all kind of systemsi e.g. musl. Signed-off-by: Khem Raj -Upstream-Status: Submitted Ah, I've seen this before and was wondering if it was a genuine mistake or devtool being bad. devtool refresh is doing A Bad Thing and for some reason dropping the Upstream-Status tag. Alex, can you see why this is? Denys, can you edit it back in? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5] rootfs-postcommands.bbclass: improve binary reproducibility
Conditionally support binary reproducibility of rootfs images. If REPRODUCIBLE_TIMESTAMP_ROOTFS is specified then: 1. set /etc/timestamp to a reproducible value 2. set /etc/version to a reproducible value 3. set /etc/gconf: set mtime in all %gconf.xml to reproducible values The reproducible value is taken from the variable REPRODUCIBLE_TIMESTAMP_ROOTFS. [YOCTO #11176] [YOCTO #12422] Signed-off-by: Juro Bystricky --- meta/classes/rootfs-postcommands.bbclass | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/meta/classes/rootfs-postcommands.bbclass b/meta/classes/rootfs-postcommands.bbclass index a4e627f..5522209 100644 --- a/meta/classes/rootfs-postcommands.bbclass +++ b/meta/classes/rootfs-postcommands.bbclass @@ -56,6 +56,7 @@ ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}" SORT_PASSWD_POSTPROCESS_COMMAND ??= " sort_passwd; " python () { d.appendVar('ROOTFS_POSTPROCESS_COMMAND', '${SORT_PASSWD_POSTPROCESS_COMMAND}') +d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 'rootfs_reproducible;') } systemd_create_users () { @@ -256,10 +257,17 @@ python write_image_manifest () { os.symlink(os.path.basename(manifest_name), manifest_link) } -# Can be use to create /etc/timestamp during image construction to give a reasonably +# Can be used to create /etc/timestamp during image construction to give a reasonably # sane default time setting rootfs_update_timestamp () { - date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp + if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then + # Convert UTC into %4Y%2m%2d%2H%2M%2S + sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S` + else + sformatted=`date -u +%4Y%2m%2d%2H%2M%2S` + fi + echo $sformatted > ${IMAGE_ROOTFS}/etc/timestamp + bbnote "rootfs_update_timestamp: set /etc/timestamp to $sformatted" } # Prevent X from being started @@ -328,3 +336,16 @@ python rootfs_log_check_recommends() { if 'unsatisfied recommendation for' in line: bb.warn('[log_check] %s: %s' % (d.getVar('PN'), line)) } + +# Perform any additional adjustments needed to make rootf binary reproducible +rootfs_reproducible () { + if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then + # Convert UTC into %4Y%2m%2d%2H%2M%2S + sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S` + echo $sformatted > ${IMAGE_ROOTFS}/etc/version + bbnote "rootfs_reproducible: set /etc/version to $sformatted" + + find ${IMAGE_ROOTFS}/etc/gconf -name '%gconf.xml' -print0 | xargs -0r \ + sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g' + fi +} -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
On 04/13/2018 11:29 PM, Bystricky, Juro wrote: Yes, I do get warnings, but in both cases (skipping the renaming and also if renamed with MLPREFIX): WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept hook 'update_gio_module_cache-nativesdk' failed, details in /data/master-master/poky/build-x86_64-mingw32-sdk-core-image-minimal/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk So skipping the renaming will at least give me a correctly named executable in the package. The correctly named executable is the renamed one, as it is then consistent with what is in every other nativesdk- package (Linux-hosted ones), so the intercept script can properly pick it up. It is not used anywhere else except there. Are you sure the postinst-intercepts can even work with Windows .exe executables? If I understand this correctly, you use a qemuwrapper attempting to run Windows executable, and I cannot imagine this would work. But maybe I am missing something here. This is tangential to how the executable should be called. Yes, the qemuwrapper is allowed to fail, that why it's a warning and not a hard failure. When building target images, the fallback to this failure is deferring the script to first boot. For SDKs we currently do nothing, which means package installation isn't really completed. If SDKs aren't able to function properly because of this, we can implement a similar deferral of some kind to the environment where those binaries can be executed natively without emulation. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu_2.11.1.bb: support mingw build
On Fri, Apr 13, 2018 at 11:11 AM, Juro Bystricky wrote: > The patch chardev-connect-socket-to-a-spawned-command.patch calls > "socketpair". This function is missing in mingw, so the patch > needs to be modified accordingly (by conditional compilation using > _WIN32 macro where appropriate), otherwise we end up with a broken > mingw build. > > While it is possible to simply remove the whole patch for mingw build > (via a .bbappend file in meta-mingw), it makes more sense to modify > the patch itself. > > Signed-off-by: Juro Bystricky Acked-by: Alistair Francis Alistair > --- > ...ardev-connect-socket-to-a-spawned-command.patch | 46 > +++--- > 1 file changed, 31 insertions(+), 15 deletions(-) > > diff --git > a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch > > b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch > index 32809d3..6e6bf95 100644 > --- > a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch > +++ > b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch > @@ -54,10 +54,11 @@ diff --git a/chardev/char-socket.c b/chardev/char-socket.c > index 53eda8ef00..f566107c35 100644 > --- a/chardev/char-socket.c > +++ b/chardev/char-socket.c > -@@ -852,6 +852,66 @@ static gboolean socket_reconnect_timeout(gpointer > opaque) > +@@ -852,6 +852,68 @@ static gboolean socket_reconnect_timeout(gpointer > opaque) > return false; > } > > ++#ifndef _WIN32 > +static void chardev_open_socket_cmd(Chardev *chr, > +const char *cmd, > +Error **errp) > @@ -117,42 +118,49 @@ index 53eda8ef00..f566107c35 100644 > +object_unref(OBJECT(sioc)); > +} > +} > ++#endif > + > static void qmp_chardev_open_socket(Chardev *chr, > ChardevBackend *backend, > bool *be_opened, > -@@ -859,6 +919,7 @@ static void qmp_chardev_open_socket(Chardev *chr, > +@@ -859,6 +921,9 @@ > { > SocketChardev *s = SOCKET_CHARDEV(chr); > ChardevSocket *sock = backend->u.socket.data; > ++#ifndef _WIN32 > +const char *cmd = sock->cmd; > ++#endif > bool do_nodelay = sock->has_nodelay ? sock->nodelay : false; > bool is_listen = sock->has_server ? sock->server : true; > bool is_telnet = sock->has_telnet ? sock->telnet : false; > -@@ -926,7 +987,12 @@ static void qmp_chardev_open_socket(Chardev *chr, > +@@ -925,7 +990,14 @@ > + } else if (reconnect > 0) { > s->reconnect_time = reconnect; > } > - > --if (s->reconnect_time) { > +- > ++#ifndef _WIN32 > +if (cmd) { > +chardev_open_socket_cmd(chr, cmd, errp); > + > +/* everything ready (or failed permanently) before we return */ > +*be_opened = true; > -+} else if (s->reconnect_time) { > ++} else > ++#endif > + if (s->reconnect_time) { > sioc = qio_channel_socket_new(); > tcp_chr_set_client_ioc_name(chr, sioc); > - qio_channel_socket_connect_async(sioc, s->addr, > -@@ -985,11 +1051,22 @@ static void qemu_chr_parse_socket(QemuOpts *opts, > ChardevBackend *backend, > +@@ -985,10 +1057,26 @@ > const char *host = qemu_opt_get(opts, "host"); > const char *port = qemu_opt_get(opts, "port"); > const char *tls_creds = qemu_opt_get(opts, "tls-creds"); > ++#ifndef _WIN32 > +const char *cmd = qemu_opt_get(opts, "cmd"); > ++#endif > SocketAddressLegacy *addr; > ChardevSocket *sock; > > backend->type = CHARDEV_BACKEND_KIND_SOCKET; > --if (!path) { > ++#ifndef _WIN32 > +if (cmd) { > +/* > + * Here we have to ensure that no options are set which are > incompatible with > @@ -163,24 +171,33 @@ index 53eda8ef00..f566107c35 100644 > +error_setg(errp, "chardev: socket: cmd does not support any > additional options"); > +return; > +} > -+} else if (!path) { > ++} else > ++#endif > + if (!path) { > if (!host) { > error_setg(errp, "chardev: socket: no host given"); > - return; > -@@ -1021,13 +1098,14 @@ static void qemu_chr_parse_socket(QemuOpts *opts, > ChardevBackend *backend, > +@@ -1021,13 +1109,24 @@ > sock->has_reconnect = true; > sock->reconnect = reconnect; > sock->tls_creds = g_strdup(tls_creds); > ++#ifndef _WIN32 > +sock->cmd = g_strdup(cmd); > ++#endif > > addr = g_new0(SocketAddressLegacy, 1); > --if (path) { > ++#ifndef _WIN32 > +if (path || cmd) { > ++#else > + if (path) { > ++#endif > UnixSocketAddress *q_unix; > addr->type = SOCKET_ADDRESS_LEGACY_KIND_UNIX; > q_unix = addr->u.q_unix.data = g_new0(UnixSocketAddress, 1); > --q_unix->path = g_strdup(path); > ++#ifndef _WIN32 > +q_unix->path = cmd ? g_strd
[OE-core] [PATCH resend] core-image-minimal-initramfs: use initramfs-framework for initialization
initramfs-framework is more modular and expandable. This change was proposed in commit 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e "core-image-minimal-initramfs: use initramfs-framework by default" but reverted due to the selftests runqemu.RunqemuTests.test_boot_machine_iso and runqemu.RunqemuTests.test_boot_deploy_hddimg failing. Since then, the kinks have been worked out, and missing functionality that had been missed (non-EFI installation module) has been added. Since the PACKAGE_INSTALL variable was getting so long with all these individual modules getting added, I also introduced a new INITRAMFS_SCRIPTS variable to the core-image-minimal-initramfs recipe. This variable makes the recipe look much cleaner, and also allows easier replacement or additions to the scripts. Fixes [YOCTO #10987]. Signed-off-by: California Sullivan --- Dicussion archives: * http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145808.html * http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146244.html * http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147077.html meta/recipes-core/images/core-image-minimal-initramfs.bb | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb b/meta/recipes-core/images/core-image-minimal-initramfs.bb index 5794a25952a..a9ba91bd310 100644 --- a/meta/recipes-core/images/core-image-minimal-initramfs.bb +++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb @@ -3,7 +3,15 @@ DESCRIPTION = "Small image capable of booting a device. The kernel includes \ the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \ first 'init' program more efficiently." -PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install initramfs-live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}" +INITRAMFS_SCRIPTS ?= "\ + initramfs-framework-base \ + initramfs-module-setup-live \ + initramfs-module-udev \ + initramfs-module-install \ + initramfs-module-install-efi \ + " + +PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} udev base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}" # Do not pollute the initrd image with rootfs features IMAGE_FEATURES = "" -- 2.14.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
Yes, I do get warnings, but in both cases (skipping the renaming and also if renamed with MLPREFIX): WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept hook 'update_gio_module_cache-nativesdk' failed, details in /data/master-master/poky/build-x86_64-mingw32-sdk-core-image-minimal/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk So skipping the renaming will at least give me a correctly named executable in the package. Are you sure the postinst-intercepts can even work with Windows .exe executables? If I understand this correctly, you use a qemuwrapper attempting to run Windows executable, and I cannot imagine this would work. But maybe I am missing something here. BTW, I cannot remedy this in the meta-mingw layer via a .bbppend, as the code that needs to be modified is in do_install_append, so it is not possible (or not easy) to use overrides. From: Alexander Kanavin [alexander.kana...@linux.intel.com] Sent: Friday, April 13, 2018 12:32 PM To: Bystricky, Juro; openembedded-core@lists.openembedded.org Cc: richard.pur...@linuxfoundation.org; jurobystri...@hotmail.com Subject: Re: [PATCH] glib-2.0/glib.inc: fix broken mingw build On 04/13/2018 05:43 PM, Bystricky, Juro wrote: >> I think the better approach is to accommodate the exe suffix when doing >> the move: > >> mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT} >> ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT} > > This was actually the first thing I tried. However, I ended up with > "nativesdk-gio-querymodules.exe" > in the mingw tarrball (in my case > poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz). > I am not sure what you expect postinst to do for Windows toolchains/SDKs, but > I would expect > "gio-querymodules.exe", as it used to be until recently. "nativesdk-gio-querymodules.exe" is totally fine. This utility is used in only one place: poky/scripts/postinst-intercepts/update_gio_module_cache, to generate the cache file of gio modules whenever the gio modules are installed or removed. That script is called by postinst_intercept mechanism, which is triggered via meta/classes/gio-module-cache.bbclass every time a package that inherits that class is installed. I am fairly sure that with the patch you sent it is not going to work for the nativesdk mingw case, as the script does prepend the MLPREFIX to the utility name (to call the correct version among many when multilib is in use). We would probably need to append the .exe suffix in there as well though. Please do try populate_sdk with nativesdk-glib-2.0 included into it and watch for any warnings about failed postinst_intercepts. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] kernel menuconfig broken?
On 2018-04-12 5:38 PM, Cal Sullivan wrote: If you're using a non-linux-yocto kernel you likely need to apply this patch to your kernel as well: https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-kernel/linux/linux-intel/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch (This is in all linux-yocto kernels, I'm only linking to meta-intel because I knew where it was off the top of my head) This was sent upstream but last I looked it didn't gain any traction. I think Bruce resent it recently but I can't be sure. Yes, and I'm sending it yet again! :D Bruce Thanks, Cal On 04/12/2018 01:28 PM, Andreas Müller wrote: On Mon, Apr 2, 2018 at 11:57 PM, Trevor Woerner wrote: On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote: When running bitbake -cmenuconfig virtual/kernel I get a flood of undefined reference errors. Am I alone here? Sadly, I think you might be. $ bitbake virtual/kernel -c menuconfig works fine for me. I assume you're doing this for something RaspberryPi-ish? Build Configuration: BB_VERSION = "1.37.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "opensuse-42.3" TARGET_SYS = "arm-oe-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO = "nodistro" DISTRO_VERSION = "nodistro.0" TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" TARGET_FPU = "hard" meta-raspberrypi = "master:63e53f919089027259a513dc2cd4b140789bf1a3" meta = "master:4cedddb83623c79980b354642dfeaf78218ca4b7" meta-oe meta-gnome meta-python meta-networking meta-multimedia = "master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe" meta-qt5 = "master:e60e849de1158c879bd2c150fe79b207cdac031a" meta-qt5-extra = "master:a0cf057b2f335e8d2be9180f20770773334ec209" meta-realtime = "master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e" meta-browser = "master:d1c902440cba26a9d1271cfb914633c68ee3791c" OK I found that I am not alone [1] and followed the suggestion to install ncurses-devel. Strange: it install ncurses-libs x86_64. Now I have back menuconfig but it looks horrible: All framing chars are displayed as '@'. If I remember correct there was such an issue long lime ago. However it is not beautiful but I can work with it. [1] https://github.com/crops/poky-container/issues/17 Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
On 04/13/2018 05:43 PM, Bystricky, Juro wrote: I think the better approach is to accommodate the exe suffix when doing the move: mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT} ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT} This was actually the first thing I tried. However, I ended up with "nativesdk-gio-querymodules.exe" in the mingw tarrball (in my case poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz). I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I would expect "gio-querymodules.exe", as it used to be until recently. "nativesdk-gio-querymodules.exe" is totally fine. This utility is used in only one place: poky/scripts/postinst-intercepts/update_gio_module_cache, to generate the cache file of gio modules whenever the gio modules are installed or removed. That script is called by postinst_intercept mechanism, which is triggered via meta/classes/gio-module-cache.bbclass every time a package that inherits that class is installed. I am fairly sure that with the patch you sent it is not going to work for the nativesdk mingw case, as the script does prepend the MLPREFIX to the utility name (to call the correct version among many when multilib is in use). We would probably need to append the .exe suffix in there as well though. Please do try populate_sdk with nativesdk-glib-2.0 included into it and watch for any warnings about failed postinst_intercepts. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu_2.11.1.bb: support mingw build
The patch chardev-connect-socket-to-a-spawned-command.patch calls "socketpair". This function is missing in mingw, so the patch needs to be modified accordingly (by conditional compilation using _WIN32 macro where appropriate), otherwise we end up with a broken mingw build. While it is possible to simply remove the whole patch for mingw build (via a .bbappend file in meta-mingw), it makes more sense to modify the patch itself. Signed-off-by: Juro Bystricky --- ...ardev-connect-socket-to-a-spawned-command.patch | 46 +++--- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch index 32809d3..6e6bf95 100644 --- a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch +++ b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch @@ -54,10 +54,11 @@ diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 53eda8ef00..f566107c35 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c -@@ -852,6 +852,66 @@ static gboolean socket_reconnect_timeout(gpointer opaque) +@@ -852,6 +852,68 @@ static gboolean socket_reconnect_timeout(gpointer opaque) return false; } ++#ifndef _WIN32 +static void chardev_open_socket_cmd(Chardev *chr, +const char *cmd, +Error **errp) @@ -117,42 +118,49 @@ index 53eda8ef00..f566107c35 100644 +object_unref(OBJECT(sioc)); +} +} ++#endif + static void qmp_chardev_open_socket(Chardev *chr, ChardevBackend *backend, bool *be_opened, -@@ -859,6 +919,7 @@ static void qmp_chardev_open_socket(Chardev *chr, +@@ -859,6 +921,9 @@ { SocketChardev *s = SOCKET_CHARDEV(chr); ChardevSocket *sock = backend->u.socket.data; ++#ifndef _WIN32 +const char *cmd = sock->cmd; ++#endif bool do_nodelay = sock->has_nodelay ? sock->nodelay : false; bool is_listen = sock->has_server ? sock->server : true; bool is_telnet = sock->has_telnet ? sock->telnet : false; -@@ -926,7 +987,12 @@ static void qmp_chardev_open_socket(Chardev *chr, +@@ -925,7 +990,14 @@ + } else if (reconnect > 0) { s->reconnect_time = reconnect; } - --if (s->reconnect_time) { +- ++#ifndef _WIN32 +if (cmd) { +chardev_open_socket_cmd(chr, cmd, errp); + +/* everything ready (or failed permanently) before we return */ +*be_opened = true; -+} else if (s->reconnect_time) { ++} else ++#endif + if (s->reconnect_time) { sioc = qio_channel_socket_new(); tcp_chr_set_client_ioc_name(chr, sioc); - qio_channel_socket_connect_async(sioc, s->addr, -@@ -985,11 +1051,22 @@ static void qemu_chr_parse_socket(QemuOpts *opts, ChardevBackend *backend, +@@ -985,10 +1057,26 @@ const char *host = qemu_opt_get(opts, "host"); const char *port = qemu_opt_get(opts, "port"); const char *tls_creds = qemu_opt_get(opts, "tls-creds"); ++#ifndef _WIN32 +const char *cmd = qemu_opt_get(opts, "cmd"); ++#endif SocketAddressLegacy *addr; ChardevSocket *sock; backend->type = CHARDEV_BACKEND_KIND_SOCKET; --if (!path) { ++#ifndef _WIN32 +if (cmd) { +/* + * Here we have to ensure that no options are set which are incompatible with @@ -163,24 +171,33 @@ index 53eda8ef00..f566107c35 100644 +error_setg(errp, "chardev: socket: cmd does not support any additional options"); +return; +} -+} else if (!path) { ++} else ++#endif + if (!path) { if (!host) { error_setg(errp, "chardev: socket: no host given"); - return; -@@ -1021,13 +1098,14 @@ static void qemu_chr_parse_socket(QemuOpts *opts, ChardevBackend *backend, +@@ -1021,13 +1109,24 @@ sock->has_reconnect = true; sock->reconnect = reconnect; sock->tls_creds = g_strdup(tls_creds); ++#ifndef _WIN32 +sock->cmd = g_strdup(cmd); ++#endif addr = g_new0(SocketAddressLegacy, 1); --if (path) { ++#ifndef _WIN32 +if (path || cmd) { ++#else + if (path) { ++#endif UnixSocketAddress *q_unix; addr->type = SOCKET_ADDRESS_LEGACY_KIND_UNIX; q_unix = addr->u.q_unix.data = g_new0(UnixSocketAddress, 1); --q_unix->path = g_strdup(path); ++#ifndef _WIN32 +q_unix->path = cmd ? g_strdup_printf("cmd:%s", cmd) : g_strdup(path); ++#else + q_unix->path = g_strdup(path); ++#endif } else { addr->type = SOCKET_ADDRESS_LEGACY_KIND_INET; addr->u.inet.data = g_new(InetSocketAddress, 1); @@ -223,4 +240,3 @@ index ae19dcd1ed..6de0f29bcd 100644 '*wait' : 'bool', -- 2.
Re: [OE-core] [PATCH] musl: Upgrade to latest
usual master stuff On Fri, Apr 13, 2018 at 9:18 AM, Burton, Ross wrote: > Is this a freeze break request for Sumo or an early submission for master? > > Ross > > On 13 April 2018 at 17:09, Khem Raj wrote: >> Changes are here >> >> https://git.musl-libc.org/cgit/musl/log/?qt=range&q=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0 >> >> Signed-off-by: Khem Raj >> --- >> meta/recipes-core/musl/musl_git.bb | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-core/musl/musl_git.bb >> b/meta/recipes-core/musl/musl_git.bb >> index 9f8c5126e8..42ba411f17 100644 >> --- a/meta/recipes-core/musl/musl_git.bb >> +++ b/meta/recipes-core/musl/musl_git.bb >> @@ -3,7 +3,7 @@ >> >> require musl.inc >> >> -SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04" >> +SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0" >> >> PV = "1.1.19+git${SRCPV}" >> >> -- >> 2.17.0 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] musl: Upgrade to latest
Is this a freeze break request for Sumo or an early submission for master? Ross On 13 April 2018 at 17:09, Khem Raj wrote: > Changes are here > > https://git.musl-libc.org/cgit/musl/log/?qt=range&q=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0 > > Signed-off-by: Khem Raj > --- > meta/recipes-core/musl/musl_git.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/musl/musl_git.bb > b/meta/recipes-core/musl/musl_git.bb > index 9f8c5126e8..42ba411f17 100644 > --- a/meta/recipes-core/musl/musl_git.bb > +++ b/meta/recipes-core/musl/musl_git.bb > @@ -3,7 +3,7 @@ > > require musl.inc > > -SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04" > +SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0" > > PV = "1.1.19+git${SRCPV}" > > -- > 2.17.0 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: Set and export TZ envvar to UTC
We just ran into an issue where tar failed to build on one server setup but built everywhere else just fine. It was running makeinfo to regenerate some docs files and makeinfo was too old for the host it was running on. There was no dependency on makeinfo-native as it was not meant to be regenerating the docs. It was being regenerated as a date from a timestamp used in the docs was different in Asian timezones than in the other timezones our builds were being tested in. I added an entry to https://wiki.yoctoproject.org/wiki/TipsAndTricks/ about how this was debugged. As such, lets default to setting and exporting TZ to 'UTC' as was already pioneered by the reproducibile builds work. This makes the builds deterministic. [YOCTO #12665] Signed-off-by: Richard Purdie --- meta/classes/reproducible_build_simple.bbclass | 1 - meta/conf/bitbake.conf | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/reproducible_build_simple.bbclass b/meta/classes/reproducible_build_simple.bbclass index dd11cd9..8a60dee 100644 --- a/meta/classes/reproducible_build_simple.bbclass +++ b/meta/classes/reproducible_build_simple.bbclass @@ -4,7 +4,6 @@ BUILD_REPRODUCIBLE_BINARIES = "1" export PYTHONHASHSEED = "0" export PERL_HASH_SEED = "0" -export TZ = 'UTC' export SOURCE_DATE_EPOCH ??= "1520598896" REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896" diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 60590e2..ec3207c 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -539,6 +539,7 @@ export MAKE = "make" EXTRA_OEMAKE = "" EXTRA_OECONF = "" export LC_ALL = "en_US.UTF-8" +export TZ = 'UTC' ## # Patch handling. -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] musl: Upgrade to latest
Changes are here https://git.musl-libc.org/cgit/musl/log/?qt=range&q=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0 Signed-off-by: Khem Raj --- meta/recipes-core/musl/musl_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index 9f8c5126e8..42ba411f17 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -3,7 +3,7 @@ require musl.inc -SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04" +SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0" PV = "1.1.19+git${SRCPV}" -- 2.17.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] yocto-uninative: Update to version 1.9 (fedora28 compatible)
This includes the libxcrypt change which allows uninative to work on fedora28. Signed-off-by: Richard Purdie --- meta/conf/distro/include/yocto-uninative.inc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/conf/distro/include/yocto-uninative.inc b/meta/conf/distro/include/yocto-uninative.inc index cd5fc0b..a8e82cb 100644 --- a/meta/conf/distro/include/yocto-uninative.inc +++ b/meta/conf/distro/include/yocto-uninative.inc @@ -8,6 +8,6 @@ UNINATIVE_MAXGLIBCVERSION = "2.27" -UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.8/"; -UNINATIVE_CHECKSUM[i686] ?= "427ce522ec97f65c75fd89587d90ef789e8cbca4a617abc4b5822abb01c2d0ae" -UNINATIVE_CHECKSUM[x86_64] ?= "de4947e98e09e1432d069311cc2093974ecb9138a714fd5466f73524de66a693" +UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.9/"; +UNINATIVE_CHECKSUM[i686] ?= "83a4f927da81d9889ef0cbe5c12cb782e21c6cc11e6155600b94ff0c99576dce" +UNINATIVE_CHECKSUM[x86_64] ?= "c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Hongzhi.Song > Sent: den 12 april 2018 05:38 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH v2] udev-extraconf: Add systemd-mount to > udev-extraconf/mount.sh > > This patch fixs the problem that block devices unable to be formatted > when > systemd and udev-extraconf recipes added to rootfs. > > If we add systemd and udev-extraconf recipes to rootfs: > VIRTUAL-RUNTIME_init_manager = "systemd" > DISTRO_FEATURES_append = " systemd" > DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" > KERNEL_FEATURES_append = " cfg/systemd.scc" > IMAGE_INSTALL_append = " udev-extraconf" > IMAGE_FSTYPES += "tar.bz2 ext4" > IMAGE_INSTALL_append = " e2fsprogs-mke2fs" > then systemd-udevd.service will invoke udev rules to automount block > devices > any probed under udevd's private namespace, this behavior results in > host space > can't format those devices. And host space can't find where the device > is used. > > Such as: > root@qemux86:~# mkfs.ext4 /dev/sda1 > mke2fs 1.43.8 (1-Jan-2018) > /dev/sda1 contains a ext4 file system > last mounted on Tue Apr 3 06:22:41 2018 > Proceed anyway? (y,N) y > /dev/sda1 is apparently in use by the system; will not make a > filesystem here! > > Command 'systemd-mount' recommended by systemd maintainer instead of > command > 'mount' will fix the problem brought with private namespace. Systemd- > mount > request the mount operation to be executed by PID 1, and hence host > space can > access the block devices. > > [YOCTO #12644] > > Signed-off-by: Hongzhi.Song > --- > meta/recipes-core/udev/udev-extraconf/mount.sh | 71 > ++ > 1 file changed, 60 insertions(+), 11 deletions(-) > > diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh > b/meta/recipes-core/udev/udev-extraconf/mount.sh > index d760328a09..4ba9f1dd99 100644 > --- a/meta/recipes-core/udev/udev-extraconf/mount.sh > +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh > @@ -4,10 +4,28 @@ > # > # Attempt to mount any added block devices and umount any removed > devices > > +BASE_INIT="`readlink "/sbin/init"`" > +INIT_SYSTEMD="/lib/systemd/systemd" In a system where ${base_libdir} != "lib", e.g, if usrmerge is in DISTRO_FEATURES, this may not match reality. You should replace all hardcoded paths with something like @base_libdir@ and then use sed to apply all the relevant bitbake path variables. > + > +if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then > + # systemd as init uses systemd-mount to mount block devices You should use tabs to indent this function to match the rest of this file. > +MOUNT="/usr/bin/systemd-mount" > +UMOUNT="/usr/bin/systemd-umount" > + > +if [ -x $MOUNT ] && [ -x $UMOUNT ]; > +then > +logger "Using systemd-mount to finish mount" > +else > +logger "Linux init is using systemd, so please install systemd-mount > to finish mount" > +exit 1 > +fi > +else > +MOUNT="/bin/mount" > +UMOUNT="/bin/umount" > +fi > > -MOUNT="/bin/mount" > PMOUNT="/usr/bin/pmount" > -UMOUNT="/bin/umount" > + > for line in `grep -h -v ^# /etc/udev/mount.blacklist > /etc/udev/mount.blacklist.d/*` > do > if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ]; > @@ -17,7 +35,35 @@ do > fi > done > > -automount() { > +automount_systemd() { > +name="`basename "$DEVNAME"`" > + > +! test -d "/run/media/$name" && mkdir -p "/run/media/$name" The above is better written as: [ -d "/run/media/$name" ] || mkdir -p "/run/media/$name" > + > +MOUNT="$MOUNT -o silent" > + > +# If filesystemtype is vfat, change the ownership group to 'disk', and > +# grant it with w/r/x permissions. > +case $ID_FS_TYPE in > +vfat|fat) > +MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print $3}' > /etc/group`" > +;; > +# TODO > +*) > +;; > +esac > + > +if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name" > +then > +#logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME > \"/run/media/$name\" failed!" > +rm_dir "/run/media/$name" > +else > +logger "mount.sh/automount" "Auto-mount of [/run/media/$name] > successful" > +touch "/tmp/.automount-$name" > +fi > +} > + > +automount() { > name="`basename "$DEVNAME"`" > > ! test -d "/run/media/$name" && mkdir -p "/run/media/$name" > @@ -26,7 +72,7 @@ automount() { > then > MOUNT="$MOUNT -o silent" > fi > - > + > # If filesystem type is vfat, change the ownership group to 'disk', and > # grant it with w/r/x permissions. > case $ID_FS_TYPE in > @@ -46,7 +92,7 @@ automount() { > logger "mount.sh/automount" "Auto-mount of [/run/media/$name] > successful" > touch "/tmp/.auto
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
> I think the better approach is to accommodate the exe suffix when doing > the move: > mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT} > ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT} This was actually the first thing I tried. However, I ended up with "nativesdk-gio-querymodules.exe" in the mingw tarrball (in my case poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz). I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I would expect "gio-querymodules.exe", as it used to be until recently. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemtap: don't build under musl
systemtap uses obstack.h and FTW_SKIP_SUBTREE, both of which are GNU extensions in glibc. Signed-off-by: Ross Burton --- meta/recipes-kernel/systemtap/systemtap_git.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc b/meta/recipes-kernel/systemtap/systemtap_git.inc index e1b7789aedc..e2f5204a020 100644 --- a/meta/recipes-kernel/systemtap/systemtap_git.inc +++ b/meta/recipes-kernel/systemtap/systemtap_git.inc @@ -26,6 +26,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \ " COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm|aarch64|microblazeel|mips).*-linux' +COMPATIBLE_HOST_libc-musl = 'null' S = "${WORKDIR}/git" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packagegroup-core-tools-profile: include systemtap on MIPS and aarch64
Modern systemtap builds fine for MIPS and aarch64, so don't exclude it from this packagegroup. Signed-off-by: Ross Burton --- meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb index 554f5298890..fa0e363d863 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb @@ -33,9 +33,7 @@ PERF_libc-musl = "" # systemtap needs elfutils which is not fully buildable on some arches/libcs SYSTEMTAP = "systemtap" SYSTEMTAP_libc-musl = "" -SYSTEMTAP_mipsarch = "" SYSTEMTAP_nios2 = "" -SYSTEMTAP_aarch64 = "" # lttng-ust uses sched_getcpu() which is not there on for some platforms. LTTNGUST = "lttng-ust" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: add scp to HOSTTOOLS_NONFATAL
The scp tool is used by the ssh fetcher. Signed-off-by: Jef Driesen --- meta/conf/bitbake.conf | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 60590e2..5cfd117 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -498,6 +498,9 @@ HOSTTOOLS_NONFATAL += "join nl size yes zcat" # Used by bzr fetcher HOSTTOOLS_NONFATAL += "bzr" +# Used by ssh fetcher +HOSTTOOLS_NONFATAL += "scp" + CCACHE ??= "" # ccache < 3.1.10 will create CCACHE_DIR on startup even if disabled, and # autogen sets HOME=/dev/null so in certain situations builds can fail. -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] oeqa/runtime/stap.py: add runtime test for systemtap
On 3 April 2018 at 16:25, Victor Kamensky wrote: > +@OETestID(1652) > +@skipIfNotFeature('tools-profile', > + 'Test requires tools-profile to be in IMAGE_FEATURES') > +@OETestDepends(['kernelmodule.KernelModuleTest.test_kernel_module']) > +def test_stap(self): Instead of skipIfNotFeature use OETestDepends(systemtap), as platforms which don't support systemtap can still have tools-profile enabled (such as musl systems). Then please add stap to the default cases in testimage.bbclass for the sdk images. Also shouldn't the test be looking at the output to check that 'hello world' was displayed? Otherwise stap might have done exit(0) but the script didn't actually run. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types: use pigz to create .gz files
On Wed, 2018-04-11 at 14:36 +0100, Burton, Ross wrote: > Wouldn't that introduce a fun circular dependency if pigz-native > needs > to be built? For the sstate code we could probably make it use pigz if present. We could also only depend on pigz-native for target, or encode the actual pigz-native dependencies. So there may be a few options if its worth the performance win. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 1/2] image.bbclass: add prohibited-paths QA test
On Fri, Apr 13, 2018 at 6:27 AM, Fabien Lahoudere wrote: > This patch doesn't seem to be applied. > Is there additional comments or something blocking? I see no reason for it not being applied. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] man-db: add groff to RDEPENDS
The following changes since commit 8dbf71b553b3fb3063ab5f61bb3454a6ab8e6c08: bitbake: bitbake-user-manual: Updated "Task Checksums and Setscene" section (2018-04-12 22:25:17 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/man-db-groff http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/man-db-groff Chen Qi (1): man-db: add groff to RDEPENDS meta/recipes-extended/man-db/man-db_2.8.1.bb | 1 + 1 file changed, 1 insertion(+) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] man-db: add groff to RDEPENDS
Add groff to RDEPENDS_${PN}, otherwise, the 'man' command cannot work correctly on target. Signed-off-by: Chen Qi --- meta/recipes-extended/man-db/man-db_2.8.1.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-extended/man-db/man-db_2.8.1.bb b/meta/recipes-extended/man-db/man-db_2.8.1.bb index 528903d..8328a67 100644 --- a/meta/recipes-extended/man-db/man-db_2.8.1.bb +++ b/meta/recipes-extended/man-db/man-db_2.8.1.bb @@ -25,6 +25,7 @@ FILES_${PN} += "${prefix}/lib/tmpfiles.d" FILES_${PN}-dev += "${libdir}/man-db/libman.so ${libdir}/${BPN}/libmandb.so" +RDEPENDS_${PN} += "groff" RRECOMMENDS_${PN} += "less" RPROVIDES_${PN} += " man" -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 1/2] image.bbclass: add prohibited-paths QA test
Hi This patch doesn't seem to be applied. Is there additional comments or something blocking? Thanks Fabien On Mon, 2017-11-27 at 19:28 +, Martyn Welch wrote: > Sometimes we wish to ensure that files or directories are not installed > somewhere that may prove detrimental to the operation of the system. For > example, this may be the case if files are placed in a directory that is > utilised as a mount point at run time, thus making them inaccessible once > when the mount point is being utilised. > > Implement the prohibited paths QA test, which enables such locations to be > specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation > allows for a colon separated list of paths to be provided. Shell style > wildcards can be used. > > Signed-off-by: Fabien Lahoudere > Signed-off-by: Martyn Welch > --- > Changes since v1: > - Correcting author and SOB. > > Changes since v2: > - Reimplemented as image rather than package level QA test. > - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better > reflect its use. > > Changes since v3: > - Rename variable to IMAGE_QA_PROHIBITED_PATHS. > - Use str.startswith(). > - Simplify if statement. > > Changes since v4: > - Move QA test to new class "image-insane.bbclass". > > meta/classes/image-insane.bbclass | 20 > meta/classes/image.bbclass| 1 + > 2 files changed, 21 insertions(+) > create mode 100644 meta/classes/image-insane.bbclass > > diff --git a/meta/classes/image-insane.bbclass > b/meta/classes/image-insane.bbclass > new file mode 100644 > index 000..29935cf > --- /dev/null > +++ b/meta/classes/image-insane.bbclass > @@ -0,0 +1,20 @@ > +python image_check_prohibited_paths () { > +import glob > +from oe.utils import ImageQAFailed > + > +rootfs = d.getVar('IMAGE_ROOTFS') > + > +path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "") > +if path != "": > +for p in path.split(':'): > +if not p.startswith('/'): > +raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must > be an absolute path" % > p, image_check_prohibited_paths) > + > +match = glob.glob("%s%s" % (rootfs, p)) > +if match: > +loc = ", ".join(item.replace(rootfs, '') for item in match) > +raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS > \"%s\": %s" % (p, > loc), image_check_prohibited_paths) > +} > + > +IMAGE_QA_COMMANDS += "image_check_prohibited_paths" > + > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass > index d93de02..8b45abb 100644 > --- a/meta/classes/image.bbclass > +++ b/meta/classes/image.bbclass > @@ -1,4 +1,5 @@ > inherit rootfs_${IMAGE_PKGTYPE} > +inherit image-insane > > # Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base > # in the non-Linux SDK_OS case, such as mingw32 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core