**** BEGIN LOGGING AT Thu May 24 03:00:03 2018 May 24 08:02:23 has anybody tried to use git (pre)mirrors as a fallback with AUTOREV when working offline? I'm occasionally working from home and don't have access to our company repositories but would still like to work work on our build system. May 24 08:04:32 seems that AUTOREV triggers a ls-remote to get a branch->ref mapping before doing any work at all and this seems (at least on morty) to bypass all mirror configurations May 24 08:20:07 lindblandro: by design as it can't tell if the mirror is up to date May 24 08:25:05 yeah I realize that, but in this scenario it'd be me that has to worry about that, and I'm more interested in just getting the HEAD of the mirrors so that the build doesn't explode right at the beginning. apart from developing May 24 08:25:24 this could be used to facilitate offline builds in our ci May 24 08:37:07 hello, when I install toybox into image instead of coreutils or busybox, shouldn't there be appropriate symlinks created in my rootfs for base utilities? They used to be created when I was using busybox, but they are not being created for toybox May 24 08:37:32 I am currently on Sumo May 24 08:37:56 New news from stackoverflow: Can't install db berkeley in my yocto project May 24 08:38:11 not sure if necessary, but I set VIRTUAL-RUNTIME_base-utils = "toybox" in my local.conf May 24 09:00:41 how do I make toybox provide a /bin/sh in Yocto Sumo? May 24 09:01:04 just having toybox installed into image is not enough, no symlink gets created May 24 09:02:09 I get this during boot: sulogin: failed to execute /bin/sh: No such file or directory May 24 09:07:58 New news from stackoverflow: I can not install db berkeley in my yocto project May 24 09:09:21 paulbarker: hello, how do I use your toybox recipe in meta-oe to provide /bin/sh and base utilities on my rootfs? apparently just adding toybox to my image recipe is not enough May 24 09:10:18 eduardas_m: It's been a looooooong while since I looked at that. Let me see if I can link you to an old version of our distro that used it May 24 09:13:00 Take a look around this old version of meta-oryx from Dec 2016: https://gitlab.com/oryx/meta-oryx/blob/dcab84d0b87082463375b598401bb801b9ee9271. There's some bbappends in there for busybox and toybox which may be helpful. I'd expect you'd need to update a few things to work with more recent Yocto releases though May 24 09:13:19 paulbarker: the toybox .ipk package contains just /bin/toybox and /etc/toybox.links... However, the symlinks described in toybox.links never get created in my rootfs May 24 09:14:39 paulbarker: thank you... I am currently in the process of moving my BSP to Sumo May 24 09:15:06 eduardas_m: The links should be handled by update-alternatives May 24 09:15:26 It gets set up by this bit of python: http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/toybox/toybox_0.7.5.bb#n55 May 24 09:16:15 Also may be worth updating the recipe to toybox v0.7.6. I've not had time to do that myself but could help review the patch May 24 09:23:13 paulbarker: does update-alternatives stop creating links for a specific recipe on first failure? according to my log /usr/bin/cal exists and is not a link May 24 09:24:23 this was supposed to be linked to /bin/toybox May 24 09:25:17 hello May 24 09:25:35 eduardos_m: That might be the issue. It could easily have got out-of-date with what's created as a link in busybox and what isn't May 24 09:27:06 following instructions here: https://www.yoctoproject.org/docs/2.5/brief-yoctoprojectqs/brief-yoctoprojectqs.html i ended with this error: May 24 09:27:26 fatal: reference is not a tree: fddbe854c9db058d5a05830d3bcdd4233d95ee2e May 24 09:27:50 in pseudo-native May 24 09:28:15 is something wrong in the git repos? May 24 09:46:22 cornel: hard to guess what you are doing May 24 09:50:14 Is there a way in which I can specify a version of a given dependency? something like DEPENDS = "lib-0.0.1"? May 24 09:54:52 droman: DEPENDS = "lib (>= 1.2)" May 24 10:02:46 no, this won't work May 24 10:03:11 it works in RDEPENDS_${PN}, but not in build time dependencies May 24 10:11:04 Right, it didn't worked, for now I'm using PREFERRED_VERSION_name in the configuration of the layer, but it will be better to be able to specify it inside the recipe that actually requires a special version May 24 10:13:55 mckoan: no need to guess. as said, i'm following instructions from that QSG. the error i get at bitbake core-image-sato May 24 10:15:26 so basically is git fetch git checkout, bitbake May 24 10:32:09 paulbarker: I have fixed the /usr/bin/cal issue by removing the util-linux package, however I have another problem... I am trying to use toybox for base utilities on an image that has systemd and the systemd recipe has kmod as a hard dependency May 24 10:32:23 thus I get a warning update-alternatives: modinfo has multiple providers with the same priority May 24 10:32:40 and an actual failure of update-alternatives in the log May 24 10:32:42 eduardas_m: It's untested with systemd May 24 10:32:52 mv: cannot move '/sbin/modinfo' to '/bin/modinfo': Permission denied May 24 10:33:36 here /bin/modinfo is toybox stuff and /sbin/modinfo is kmod stuff May 24 10:33:38 My intention was to support an entirely permissive-licensed userspace (a la Android) so never tested with systemd May 24 10:36:28 paulbarker: as far as I understand since systemd is LGPLv2 and not v3, it does not require the device to be open for installation of software by the user. Please correct me if I am wrong. May 24 10:36:41 IANAL May 24 10:36:54 because I often hear about people using systemd for embedded May 24 10:37:45 that's policy for you to decide May 24 10:40:25 paulbarker: completely permissive userspace would actually be preferable, but have you ever looked at whether you actually lose in terms of boot time reduction when using busybox/toybox vs systemd? May 24 10:41:59 because one of my main motivations for using systemd was reducing boot times, but since I never really bothered maintaining a sysvinit or busybox version of my images, I can not tell whether there were any real gains at all May 24 10:44:14 cornel: there was a discussion around this: https://lists.yoctoproject.org/pipermail/poky/2018-May/011338.html May 24 11:12:37 paulbarker: I have also noticed that although toybox uses menuconfig, one can not run a bitbake toybox -c menuconfig since in the recipe it does not inherit cml1 (which is valid for busybox recipe) May 24 11:15:59 thank you anujm May 24 12:44:05 Hey, I'm working with a qmake based recipe. I've created an install.extra line in my .pro that reads target.extra = ln -sf /opt/$${TARGET}/bin/$${TARGET} $${IMAGE_ROOTFS}/usr/bin/b2qt May 24 12:44:20 I'm trying to create a symlink at install that links to a binary in /opt May 24 12:44:49 Is this the right way to do it? May 24 12:52:30 is there a recipe for a permissively licenced POSIX shell in OE/Yocto ? May 24 12:53:03 I wish to remove bash from my images because of GPLv3 May 24 12:53:24 is there a way to check local.conf for errors? May 24 12:57:19 how can i tell yocto to not verify a recipe? May 24 13:03:14 cornel: rename it, for example .bb -> .bb_defunct May 24 13:12:13 Hi. I'm having an issue with shared sstate-cache and a kernel module when externalsrc is used to build the kernel. Basically, CI builds the image without using externalsrc so it generates a kernel version like linux-4.14+git23342. When the sstate-cache is exposed and used by local devs as SSTATE_MIRROR their build breaks at do_rootfs with: error: C May 24 13:12:14 an't install kernel-module-galcore-6.2.2.p0-r0@: no package provides kernel-4.14+g233323. That's because they use externalsrc for the kernel and their version is +g999 always. Any idea on how to solve this? The module is nothing special, it's built externalli and the reicpe just inherits module. May 24 13:22:46 Does do_install_append () work in qmake5 recipes? I cant get it to do anything May 24 13:26:13 stoke_: you might want to inspect run.do_install from workdir/temp of your recipe May 24 13:26:30 stoke_: as that is the actual script that is run as the install task May 24 13:29:58 kanavin: Thanks, I'll take a look. May 24 13:38:58 New news from stackoverflow: linux yocto kernel driver development easy way May 24 13:46:36 ok, so looking at run.do_install. do_install() only runs qmake5_base_do_install which runs off and does its own thing as I setup in the .pro of my program. Nothing from do_install_append makes it in. May 24 13:50:46 stoke_: share your recipe May 24 13:54:24 kanavin: Here you go https://pastebin.com/9bfxs4br May 24 13:55:29 I added the "D" varible in myself but none of it seems to be running anyway. May 24 14:00:26 stoke_: qmake base classes do not export their task functions :( May 24 14:00:37 stoke_: look for instance at autotools.bbclass for what that means May 24 14:02:42 stoke_: should be a one liner fix here https://github.com/meta-qt5/meta-qt5/blob/master/classes/qmake5_base.bbclass May 24 14:03:03 stoke_: I have no idea how anyone not noticed this until now, doing custom stuff in install appends is not uncommon May 24 14:06:03 how do I generate SPDX information for my image? May 24 14:07:08 eduardas_m: there's an SPDX bbclass and a section in the manual May 24 14:07:59 neverpanic: I looked into it, but it says Task do_spdx does not exist for target May 24 14:08:10 do I have to inherit it in image recipe? May 24 14:08:53 this is when running bitbake -c do_spdx May 24 14:09:04 New news from stackoverflow: Makefile error when trying to build core-image-minimal with custom DTB May 24 14:09:21 You probably need INHERIT += "spdx" in your local.conf May 24 14:09:28 (Or distro.conf, etc.) May 24 14:11:02 neverpanic: I did that in my image recipe and now I get an error do_spdx: SPDX: Could not set up required directories: [Errno 13] Permission denied: '/home/yocto' May 24 14:12:22 eduardas_m: I guess you'll have to read the spdx.bbclass code and figure out why it tries to create this directory May 24 14:16:23 kanavin: Interesting, presumably I would need to export the do_install function in the qt bbclass May 24 14:17:34 I've been trying to add an extra step to the .pro makefile for qmake5. Qt advises you do this by setting target.extra to the commands you want to run May 24 14:18:21 Unfortunately, qmake spits errors when I do this as it tries to create a symlink in my /usr/bin rather than the install sysroot May 24 14:19:03 setting $${bindir} does nothing as it's seemingly not set in the context that qmake runs here May 24 14:19:12 stoke_: that is not specific to yocto ;) May 24 14:29:02 neverpanic: it appears the reason is because SPDX_MANIFEST_DIR = "/home/yocto/fossology_scans" is defined in meta/conf/licenses.conf... I probably need to override it in my local.conf? May 24 14:30:13 AFAIR, spdx.bbclass needs a fossology installation, so this probably depends on your fossology installation May 24 14:31:23 neverpanic: honestly, I was not even aware fossology is a thing. thank you May 24 14:33:19 That's where my knowledge ends, though -- we reimplemented SPDX generation as an extension of archiver.bbclass and based on scancode-toolkit for our use case May 24 14:33:37 kanavin: No i didn't think so :P I'm just trying to figure out how qmake can install the binary to opt correctly but not my extra commands. Must be missing something May 24 14:43:31 neverpanic: setting SPDX_MANIFEST_DIR = "/home/eduardas/BUILD_4/licenses/" in local.conf does not override SPDX_MANIFEST_DIR in meta/conf/licenses.conf Perhaps you have an idea of what I am doing wrong? May 24 14:46:12 eduardas_m: Seems like a bug to me, meta/conf/licenses.conf should set SPDX_MANIFEST_DIR using ?= or ??= May 24 15:49:51 Is there a way to use devtool to modify a class cleanly? May 24 15:50:51 I want to modify the qt5_base.bbclass to export the do_install function so I can run some commands after the install the make does May 24 15:51:21 you can't modify a class at all, devtool or otherwise, at least not directly. you can add a new class that alters its stuff, and make sure its inherited after it everywhere the originaln is inherited, or you can override the class entirely in a layer listed earlier in BBLAYERS May 24 15:51:30 rburton: would you pick the uboot 2018.05 update patch I posted? Seems AUH failed as expected May 24 15:52:04 rburton: the qemu-x86 fix is now in mainline, so I can also backport it once the update is in May 24 15:52:30 yeah its in mut already May 24 15:53:28 Thanks May 24 16:15:31 Okay, more qmake weirdness for you all. I've manged to get qmake to create the symlink I wanted by adding the following to my project file https://pastebin.com/cV7JBT9W May 24 16:16:06 qt5_base_do_install() does some processing of the project to create a makefile with a working path. May 24 16:16:10 so far everything makes sense May 24 16:16:51 However, when I run these extra commands using devtool build, bitbake complains about a QA issue about files being installed but not packaged May 24 16:17:27 But the file it's complaining about is included in FILES in my recipe May 24 16:18:21 I'm not sure what exactly i'm breaking when I do this May 24 17:09:44 New news from stackoverflow: Bitbake: "The metadata is not deterministic and this needs to be fixed" May 24 19:00:19 Hello, I have questions regarding NodeJS and NPM packages. I'm following directives from this page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM but I don't understand if I should create a recipe or not for each NPM package that my NodeJS app is using May 24 19:27:57 RP: I wonder if we shouldn't make pathlib and/or pathlib.Path available the way we do 'os' and 'd' eventually, to avoid the n ested os..path.foo(os.path.bar()) crap all over May 24 19:28:13 https://realpython.com/python-pathlib/ May 24 19:56:47 kergoth: worth thinking about... May 24 19:57:21 obviously pretty low priority, but a would be nice item May 24 21:10:41 Hello - I just upgraded my build from rocko to sumo, and I'm now getting an error on build, where it can't seem to find locale-base-en-us. May 24 21:40:38 New news from stackoverflow: how to enable the spi to connect mcp251x with yocto? May 24 21:57:17 I am using meta-raspberrypi. **** ENDING LOGGING AT Fri May 25 03:00:03 2018