**** BEGIN LOGGING AT Mon Mar 19 03:00:02 2018 Mar 19 07:04:51 New news from stackoverflow: Building keras and tensor flow on yocto Mar 19 08:52:06 hello, what is the proper way of having a production kernel and a testing kernel (with additional debug features) in the same BSP? Do I need two different machine descriptions or is there some other way to have alternative kernels for a single machine description? Mar 19 08:56:36 In the qemu recipe there is a list of dependencies and they are all build, apart from libsdl. How can I figure out why libsdl is not build? Mar 19 08:58:43 Han: look at the bottom of your local.conf, probably it is set as ASSUME_PROVIDED Mar 19 09:04:48 LetoThe2nd, amazing: ASSUME_PROVIDED += "libsdl-native" Mar 19 09:17:32 Does anybody know what is the right way to disable a systemd service at distro build time? For some reason xserver-nodm.service gets started automatically at boot but I'd like to build a distro where is doesn't start by default. Mar 19 09:18:05 So I am not talking about systemd itself but rather a service running using systemd. Mar 19 09:19:51 muppe: here you go: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-SYSTEMD_AUTO_ENABLE Mar 19 09:21:44 LetoThe2nd: Thanks. I actually bumped into that variable before but thought that you have to enable it to make it autostart. Apparently the logic is the other way around. Thank you! Mar 19 09:22:18 muppe: have fun Mar 19 09:22:23 :D Mar 19 09:33:56 eduardas_m: Maybe look at this http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/kernel-devicetree.bbclass?id=5b4aab6b40cf21471442e21abc8051b38985de84 ? Mar 19 09:57:15 nayfe: thank you, that is pretty much what I need except I do not want to ship an alternate kernel besides the default one (i.e. two kernels in /boot), but replace the default one entirely (1 kernel in /boot) Mar 19 10:05:18 eduardas_m> I'm not using it, but i think you can define 2 images (prod/dev) with two differents kernel with that patch. The only problem is that kernel recipe should not provide legacy virtual/kernel. Mar 19 10:06:28 I'm trying to use eSDK "Updater" feature Mar 19 10:06:38 unfortunately I do experience some issues: Mar 19 10:06:45 https://lists.yoctoproject.org/pipermail/yocto/2017-September/038036.html Mar 19 10:06:47 Point 2. Mar 19 10:07:32 I'm using 2.4, but the problem is the same Mar 19 12:29:04 Has the maintainer for meta-nodejs abandoned the project? https://github.com/imyller/meta-nodejs Anyone knows? Mar 19 12:31:18 sveinse: it is kinda obsolete as there is now considerable mainline support for nodejs Mar 19 12:31:53 LetoThe2nd: Where can I find it? Mar 19 12:32:36 sveinse: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/npm.bbclass Mar 19 12:49:19 LetoThe2nd: This seems like npm for recipes, but I could not find npm or nodejs in poky. Perhaps I need to search closer Mar 19 12:50:07 sveinse: you asked for it, here it is: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs/nodejs_8.9.4.bb?h=master Mar 19 12:56:12 LetoThe2nd: thanks. No LTS version it seems Mar 19 13:03:23 i am not entirely sure the concept of an LTS version of nodejs is semantically coherent Mar 19 13:04:48 https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ Mar 19 13:22:53 seebs: I'm not sure how that is related to LTS, but then again, I'm no js dev. I've just been requested to provide a LTS version of nodejs in our yocto image Mar 19 13:24:57 sveinse: just grab that recipe and nail it to the version you want in your layer. Mar 19 13:25:57 LetoThe2nd: ah, ok, so that works. good. In the meta-nodejs there were some slight differences between the recipes and version. Mar 19 13:26:22 sveinse: so it *should* work Mar 19 13:28:35 thanks Mar 19 13:32:06 tinfoil.py's parse_recipe and parse_recipes don't refer to the same kind of parsing right... ? Mar 19 13:34:35 I think parse_recipes asks the remote bitbake process to parse recipes (what exactly?) and parse_recipe does more thourogh parse and returns the data with their internal env. Mar 19 13:43:00 Hi Guys. Do you have an ideea how to specify machine specific qemuboot variables ? I want to have something like: QB_DTB_qemuarm ="first.dtb" and then for another machine QB_DTB_qemux86="" Mar 19 13:54:07 ggtk: exactly what you wrote should work Mar 19 14:08:08 rburton: is my layer.conf the correct place for this variables to be set ? Mar 19 14:19:15 https://wiki.samba.org/index.php/CVE-2018-1057 <-- i am in awe Mar 19 14:43:40 seebs: That is.... impressive. Mar 19 14:53:44 Is there some examples in how to use npm.bbclass anywhere? I have fetched a repo with a package.json file in it. Mar 19 14:55:12 I searched the mega manual and found a few lines about it, but nothing which I could make use of Mar 19 15:09:11 E.g. is it a requirement that the npm package must be originate from npmjs.org? Mar 19 15:09:34 ref "Note Mar 19 15:09:36 Currently, recipes inheriting this class must use the npm:// fetcher to have dependencies fetched and packaged automatically." Mar 19 15:09:43 ernstp: parse_recipes parses the recipes specified by BBFILES, i..e what a bitbake -p does. This is the up front parse of all the recipes to generate the runqueue and dependency and provider information. parse_recipe does a full parse of a specific recipe to return the datastore Mar 19 15:30:08 kergoth: hello, man. Can you tell me why did you need the PSEUDO_UNLOAD setting in some of the external_toolchain_cross wrappers? Mar 19 15:30:47 fancer: that's my mistake, it belongs in meta-sourcery, not meta-external-toolchain, i'll see about moving it over today Mar 19 15:31:28 fancer: i made some progress with the cross-canadian recipe the other day, not sure where you're at, but i'll link you to what i have in case it's of any use Mar 19 15:31:29 Ahh, ok. I was just curious. I already removed them from your layer clone. Mar 19 15:31:33 * kergoth nods Mar 19 15:32:50 This might sound like a stupid question, but what purpose serves the devtool? I've been using yocto for 3 years and haven't had the need for it Mar 19 15:32:57 ther'es a lockfile created by the other toolchain, in /tmp, that includes $USER/$LOGNAME. if two users try to write that file both with 'root' instead of their real usernames, it explodes :) Mar 19 15:33:05 sveinse: i use it pretty much every day Mar 19 15:33:23 modify -x alone is useful to quickly dive into the source tree, make changes, then generate patches and update the recipe with the changes Mar 19 15:33:46 I am on it now. I altered your layer "a bit" so it would work better with crosstool-NG. Particularly I unpinned glibc-mtrace, glibc-scripts, glibc-locale. The last one now generates the locales as if ordinary glibc. Mar 19 15:34:21 And some other things. Mar 19 15:34:53 kergoth: right, because your normal use case is modifying existing 3rd party sources? Mar 19 15:34:56 cool, sounds worthwhile. whenever it's ready for submission you can send to the yocto@ ml with [external-toolchain] in the subject line. i'll update the readme Mar 19 15:35:12 I don't think I've broken any compatibility with your toolchain, so If you got github , I can share the .... Mar 19 15:35:21 Ahh you already answered. Mar 19 15:35:24 sveinse: less in active development, more often to fix build failures, but fairly often, yeah Mar 19 15:35:39 fancer: github works too if you want to link me to the branch, either way Mar 19 15:36:09 kergoth: I'd better create some temporary public repo, so you could pull in the changes from there. Mar 19 15:36:16 I hate patchwork!.( Mar 19 15:36:20 i'll probably put up a github mirror at some point Mar 19 15:36:22 yeah, agreed Mar 19 15:36:33 I got it enough in kerneldev. Mar 19 15:36:40 i wish we'd use a proper code review system at the least, if we're not going to stick with github, at least put up a Reviewboard instance or something, but.. Mar 19 15:36:43 * kergoth shrugs Mar 19 15:38:01 kergoth: that might be why I haven't understood the need for it: I'm mostly developing recipe and sources in lockstep. Probably the same reason why doing source-in-meta repos is harder Mar 19 15:38:27 kergoth: Alright, I've got to finish the canadians. I'll send you the link with repo later. Mar 19 15:38:31 ah, yeah, probably don't need devtool much for that Mar 19 15:38:40 recipetool is a bit more generlaly useful Mar 19 15:39:48 yes, for the normal use case where the software is coming from an independent SW release, I'd agree Mar 19 15:39:58 fancer: cool, good luck with it. https://gist.github.com/kergoth/4e48194685c7156a6706951cbfa2baee is where i left mine the other day, though i'm sure you've made more progress than i since. ended up needing to apply https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/commit/?h=external-cross-canadian&id=52de7a284a88cde41adf3bda1e4edd739ed225e9 as well, since i had + in my SDK_VERSION/DISTRO_VERSION, so it ended up in SDKPATH Mar 19 15:40:37 The reason for asking is there devtool seems to be having some featureset related to npm handling, which I need to dissect. And for that I need to set up devtool Mar 19 15:40:56 ah, interesting Mar 19 15:41:16 isn't much setup involved, really, it creates its own workspace on an as needed basis Mar 19 15:41:59 I'm getting impression that devtool is doing something: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM Mar 19 15:43:00 making shrinkwrap and lockdown files apprarently Mar 19 15:44:59 ggtk: layer.conf? no. Mar 19 15:48:17 I build a SDK, how can I know if it is an extensible SDK or not? Mar 19 15:58:48 sveinse: if you did -c populate_sdk its not, if you did populate_sdk_ext it is Mar 19 16:00:18 rburton: right, I have a meta-toolchain-sp which inherits populate_sdk, then it isn't I suppose. Thanks. Mar 19 16:03:13 I will attempt replacing inherit populate_sdk with inherit populate_sdk_ext Mar 19 17:50:47 Hi, I added another meta-layer where I am trying to add to oeqa, i have a /lib/oeqa/controllers path. If I include this layer, do_testimage fails complaining that it cant find module oeqa.core because its looking in my layer and not seeing a oeqa/core. pretty sure this is whats happening because if I dont include this layer in the bb file, its runs fine. think i am missing something, any ideas? Mar 19 17:51:25 If I print the sys.path right before the ImportError, core/meta/lib is there, which is where it should be getting oeqa.core.utils from.. Mar 19 18:01:49 * armpit shoot, forgot about swat Mar 19 18:06:55 New news from stackoverflow: Kernel panic - not syncing: Requested init /linuxrc failed (error -2) Mar 19 18:33:40 kergoth: Question about nativesdk-s and cross-canadian thing. Can I just try to run bitbake gcc-external-cross-canadian without actual SDK build process exectution? Mar 19 18:34:02 yep, you can always do that. all it'll do is create the binary packages, but you can then examine them if you want to do so Mar 19 18:34:12 can also examine pkgdata with oe-pkgdata-util Mar 19 18:34:32 It seems like my system lost nativesdk binutils? Mar 19 18:34:32 No such file or directory: 'x86_64-tpsdk-linux-strip' Mar 19 18:34:57 How come? Should I always excplicitly set such the dependencies? Mar 19 18:35:20 you'll need to create binutils-external-cross-canadian to go with gcc, and ship both the prefixed and unprefixed binaries from that (gcc looks in its libexec area to find the binutils to run them, iirc) Mar 19 18:36:44 Symbolic links shall be enough for it, I guess. Mar 19 18:37:01 New news from stackoverflow: Bitbake Server does not start on Windows Subsystem for Linux Mar 19 18:38:07 should do for now, yeah Mar 19 18:38:41 This thing can't help: cross_canadian_bindirlinks Mar 19 18:38:41 It is looking for TARGET_PREFIXed bits Mar 19 18:38:48 .( Mar 19 18:40:52 i wouldn't recommend including gcc-cross-canadian.inc, but if you're going to do it, yeah, you'll need to resolve that, either by using anonymous python to alter the function, or you could override TARGET_PREFIX just for that task, i.e. TARGET_PREFIX_task-install = "${EXTERNAL_TARGET_SYS}-" or whatever Mar 19 18:41:04 No, I;m not Mar 19 18:41:11 this method is in the bbclass Mar 19 18:41:29 ah Mar 19 18:41:58 I isn't the task. Mar 19 18:42:03 I's just a shel method Mar 19 18:42:32 it's called from cross-canadians do_install'es within recepies. Mar 19 18:43:04 I'll just copy-alter-past it.) Mar 19 18:47:17 kergoth: btw, why would I need to ship the unprefixed binaries? Mar 19 19:04:37 Still the error : No such file or directory: 'x86_64-tpsdk-linux-strip' Mar 19 19:05:22 has nothing common with the package installation. Just some dependencies isn't sutosfied Mar 19 19:05:53 I am just surprised it hasn't done so automatically. Mar 19 19:09:10 Is there any progress with solving issue number 2 from: Mar 19 19:09:10 https://lists.yoctoproject.org/pipermail/yocto/2017-September/038036.html Mar 19 19:09:19 I do experience similar issue on 2.4. Mar 19 19:19:47 Ahh, Unknown ABI used in --with-abi=32 Mar 19 19:21:06 mine mistake though.) Mar 19 19:24:30 ah, found a problem, currently the bits that extract files from the external toolchain assume that it should be copied to the path listed in FILES, not the path it found it (i.e. after FILES_MIRRORS is applied). i.e. if i list ${libexecdir}/gcc, it puts it in /usr/libexec/, which isn't where it looks for it, rather than /libexec/ which is where it found it. doing it this way makes sense for some use cases, but not this one. will have to add a variable Mar 19 19:24:30 to control this behavior, or add an explicit source:dest syntax Mar 19 19:27:04 Sorry, I don't get it. Mar 19 19:27:23 At this moment, all the necessary bits are found and installed. Mar 19 19:27:58 the classic targets worked just find. Mar 19 22:10:41 fancer: https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/log/?h=external-cross-canadian has functioning binutils and gcc cross-canadian recipes. added the gcc to TOOLCHAIN_HOST_TASK and confirmed it'll successfully compile and run hello, world if —sysroot= and —no-sysroot-suffix are included, which is the case when using $CC as defined in environment-setup. might be worth comparing/contrasting to your implementation. currently only Mar 19 22:10:41 tested with the sourcery toolchain Mar 19 22:12:15 now to rip out a few meta-sourcery remnants Mar 19 23:12:30 holy hell does packagegroup-cross-canadian suck in everything but the kitchen sink. seriously? Mar 19 23:13:43 :) Mar 19 23:14:37 oh, no, it's the sdk host packagegroup doing it. yikes Mar 19 23:16:00 gpgme, unfs2, dnf.. Mar 19 23:26:16 * armpit hopes Windows 10 is not included Mar 19 23:42:35 Hi, I keep getting a warning every time I build about this post install script in sysvinit Mar 19 23:42:37 core/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb Mar 19 23:43:18 Since this script needs to run on target, how would I disable this during build time? Mar 20 01:19:44 what warning do you see **** ENDING LOGGING AT Tue Mar 20 03:00:06 2018