**** BEGIN LOGGING AT Tue Mar 20 03:00:07 2018 Mar 20 06:15:58 Hi. I have some issue with devtool and I would need some advice. Mar 20 06:17:50 hanthings: ask away Mar 20 06:18:14 when using devtool it seems that the local files are moved to oe-local-files dir, and if the recipe tries to install these files from workdir there are not found anymore. Why devtool is moving these files away compared with bitbake which keeps these files in workdir. is there any workaround to this? Mar 20 06:19:20 seems that the files are moved after unpack task and before patch task (devtool:_extract_sources) Mar 20 06:32:38 hmm Mar 20 06:33:53 how are you installing them in recipe ? Mar 20 06:37:59 there should be symlinks in top of srctree pointing back into oe-local-files Mar 20 06:38:04 do you see them Mar 20 06:53:43 hello, yesterday i tried for hours to get core-image-minimal-initramfs to boot (qemu/i586) but had no luck. cannot mount rootfs. someone has a useful hint for me? Mar 20 07:05:09 khem, in the recipe I do install them by `install ... ${workdir}/file ${D}path/file Mar 20 07:05:17 khem, in the recipe I do install them by `install ... ${workdir}/file ${D}path/file` Mar 20 07:05:33 khem, I don't see any symlinks Mar 20 07:05:59 khem, there are not part of srctree Mar 20 07:06:10 khem, there are just local files Mar 20 07:20:46 it should be ${WORKDIR} and are you on master? Mar 20 07:27:35 khem, I'm on rocko Mar 20 07:37:17 khem, ? Mar 20 07:39:14 sysdef: standard core-image-minimal-initramfs on qemux86? just on poky head? Mar 20 07:41:03 hanthings: I would suggest to try it on master and see if it behaves differently Mar 20 07:43:07 khem, it's not feasible for me to try on master :). in order to try it I probably need to fix/adapt other stuff as well Mar 20 07:43:08 LetoThe2nd: yes. tried "root=/dev/ram0" and "root=" but no luck. i can boot tinycorelinux rootfs (cpio and cpio.gz) with the kernel so i guess it's not a kernel option Mar 20 07:47:17 sysdef: no, i don't think so too. anything additional i need to know so i can try an reproduce it? addional layers in use or such? Mar 20 07:48:12 sysdef: and, i guess core-image-minimal work fine? Mar 20 07:49:01 core-image-minimal boots up fine, yes.i think i'll reset all my changes from yesterday to have a clean setup again Mar 20 07:49:43 ok, i yank out a build too. lets see. Mar 20 07:53:29 LetoThe2nd: https://pastebin.com/raw/fQxKjatW Mar 20 07:56:23 sysdef: you're mixing IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL, as well as cramming everything into local.conf is not a good idea too.. but yet thats not the source of your issue, me thinks. Mar 20 08:39:41 New news from stackoverflow: How to know install in build image package in yocto? Mar 20 09:35:33 LetoThe2nd: the result from a fresh install: http://sysdef.de/gallery/photos/yocto/2018-03-20_10-28-38.png Mar 20 09:44:19 sysdef: i'm seeing the exact same. yet, after the "waiting for removable media" it counts down 30 seconds, and the drops into busybox. so my understanding is that the initramfs is preconfigured to skip to some other root later, which it doesn't find. but the shell it drops to comes from the initramfs and seems to be functional. Mar 20 09:45:50 so i just have to find the timeout counter and set it to 3 sec? ^^ Mar 20 09:46:12 or not use it at all if you want to stay in the initramfs. Mar 20 09:46:50 to use what at all? Mar 20 09:47:52 i mean: what is "it" and how can i avoid using "it" Mar 20 09:47:58 well, i don't know what you want. why did you even choose an initramfs in the first place? Mar 20 09:48:57 and there, /init is the setup script, pretty verbose about what the initramfs is meant to do. disabling the timeout should be easy. Mar 20 09:49:07 i wanna use initramfs to have a clean systam at any boot. no need for persistent data so initramfs or even .iso would be perfect Mar 20 09:49:22 hm. Mar 20 09:49:53 https://git.yoctoproject.org/cgit.cgi/poky/plain/scripts/lib/wic/plugins/source/isoimage-isohybrid.py Mar 20 09:50:01 sound like this is what you actually want Mar 20 09:50:36 initramfs is kinda special in some ways, and given the usual embedded/container usecase not needed very often. hence, its working, but not very polished. Mar 20 09:51:30 usually we go for kernel+initrd, which behaves way more similar to a classic system. Mar 20 09:51:58 plus, you might want IMAGE_FEATURE rootfs-read-only Mar 20 09:52:18 my use case is a qemu image that runs an openvpn client on windows Mar 20 09:52:28 kergoth: cool. Thanks, man! Funny to see, I did half of the things u did in the cross-canadians support. I'll merge it with my changes and try it out. Mar 20 09:54:41 LetoThe2nd: i have no idea what to do with that script. i heard "yocto" the first time, yesterday Mar 20 09:54:56 sysdef: i'd augment core-image-minimal with waht you need, have it create a readonly rootfs in ext* or something, and then use that as initrd. this is basically even the rumqemu hello world case. Mar 20 09:55:18 sysdef: just don't use initramfs here. it will give you headaches but no gain. Mar 20 09:56:10 k, i'll give it a try ... Mar 20 10:00:52 hi Mar 20 10:04:33 sysdef: plus, try to keep tinkering in local.conf at a total minimum. pour stuff into an own image, that makes stuff way more reproductible. a simple example is the recipe for core-image-minimal-dev: it just adds something to core-image-minimal. copy it and beat it into shape for your needs :) Mar 20 10:06:16 I was wondering: How do I extend a recipe `MY_IMAGE.bb` as a new recipe `MY_EXTENDED_IMAGE.bb`, so that any `MY_IMAGE.bbappend` are applied? Mar 20 10:06:37 On builds extensible SDKs with bitbake -c populate_sdk_ext imagename . What happens if I build multiple images? And can I have multiple machines in the same SDK? Apparently populate_sdk_ext cannot be a target of its own Mar 20 10:06:53 T_UNIX: thats not how appends work. Mar 20 10:06:53 afaii `inherit` is supposed to be used w/ `.bbclass` only Mar 20 10:07:31 T_UNIX: exactly. inherit is for classes, bbappends are name-matching the recipe file name. Mar 20 10:07:58 T_UNIX: if you want recipes to share stuff, pull it out into an .inc file that all users pull it. Mar 20 10:08:02 *in, even. Mar 20 10:10:55 How do I control which packages gets included in extensible SDKs? Mar 20 10:11:23 I'm getting failure on do_sdk_depends as brcm-firmware and linux-firmware provide the same file Mar 20 10:11:35 TOOLCHAIN_TARGET_TASK ? Mar 20 10:12:05 nayfe: Where do you define that? Mar 20 10:13:01 Because in the old SDK scheme, I had a meta-toolchain-sp.bb which inherit populate_sdk and then sets TOOLCHAIN_TARGET_TASK, but this is apparently not working for sdk_ext Mar 20 10:14:34 I.e. on SDKs I used to run bitbake meta-toolchain-sp to generate the SDK, with with the extensible scheme one does bitbake -c populate_sdk_ext image, and this is where I fall off Mar 20 10:17:30 Hi, i use fsl yocto project given by KARO(https://www.karo-electronics.com/1646.html?&L=1) to build an embedded linux system for the KARO TX6S-8035 target. The build work fine. I use the freescale mfgtool to download images into the board. when the kernel start, i have the following error message: "Kernel panic - not syncing: Requested init /linuxrc failed (error -2)" . How can i fix this? Mar 20 10:29:37 LetoThe2nd: skipped: 'rootfs-read-only' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password dbg-pkgs... the same with read-only-rootfs. not in that list Mar 20 10:30:50 oh, wait, it's working... Mar 20 10:31:42 read-only-rootfs instead of rootfs-read-only. my file save to the server just crashed :s Mar 20 10:36:51 sveinse: did you look at https://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#sdk-installing-additional-items-into-the-extensible-sdk ? Mar 20 10:42:54 nayfe: yes, but I don't have any ext SDK to begin with, so I don't have devtool to play with yet Mar 20 10:44:32 LetoThe2nd: i can boot, rootfs is read-only but the size "exploded" from ~10MB to 143MB Mar 20 10:45:28 There's probably something fundamental I'm not getting hold of here Mar 20 10:47:14 Devtool I'd not dependant to eSDK Mar 20 10:47:45 -I'd+is Mar 20 11:12:11 sysdef: have a look into the tmp/deploy/$YOURPACKAGEMANAGER/qemux86 directory and check what is eating the space. Mar 20 11:12:18 bbl, lünch! Mar 20 11:34:47 LetoThe2nd: änjoi jur fuddah. Mar 20 11:39:58 Any reasons why glibc-locale should fail building (installed-vs-shipped) on vanilly poky, rocko and qmeu86-64? Mar 20 12:08:56 sysdef: did so. found enlightenment already? Mar 20 12:15:48 I had DISTRO_FEATURES += " pam x11 opengl" in my local.conf. When I removed this, everything built fine Mar 20 12:19:02 LetoThe2nd: the problem is that I have a common base image, which is extended for various products via `.bbappend`. Then there shall be a `-dev` distribution that simply extends that base image w/ some packages and settings. Mar 20 12:19:46 currently I use `require`, but by doing so the `.bbappend` are - obviously - irgnored Mar 20 12:19:56 T_UNIX: well, maybe you need to rethink that structure then? Mar 20 12:21:41 I guess I'll have to. It would have been the way with the smallest replication of code and truely layer-style :-/ Mar 20 12:22:24 in our experience, the common-base-image thing just doesnt work. Mar 20 12:22:56 afair poky uses the same style `include core-image` for the derivative images, doesn't it? Mar 20 12:23:19 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass Mar 20 12:23:36 its a class, not a base image. totally different concept. Mar 20 12:24:34 because if you look at it, it doesn't define a set that makes up the base image, as you call it. it just offers the infrastructure. Mar 20 12:25:33 `IMAGE_INSTALL ?= ...` Mar 20 12:26:46 line 70 Mar 20 12:27:21 i know what you mean, but thats just the stuff needed to actually being able to boot. its a subtle line to hit, we have been exactly there too. Mar 20 12:28:13 what totally did backfire is the attempt to define a "base image that we can extend in all of our products.". it worked for exactly the first product. Mar 20 12:28:16 LetoThe2nd: the initramfs thing is using busybox (ash) instead of the full gnutools (core-utils, bash) Mar 20 12:28:54 sysdef: then find out what pulls that in. i did a build of core-image-minimal over lunch, and it is 10M Mar 20 12:29:15 o_O Mar 20 12:29:48 sysdef: so something in the stuff you added in the paste you showed me probably pulls in a lot of dependencies. Mar 20 12:31:38 hm... currently we use different MACHINEs and conditional `.bbappend` (that are included, depending on `MACHINE`), which significantly reduces the maintenance and copy/pasta. Mar 20 12:32:07 LetoThe2nd: but thanks for the insight. I'll rethink the current structure :) Mar 20 12:32:29 sysdef: and for the reason what that did not bite you in the initramfs version: it cleans out IMAGE_INSTALL and probably did actually not include some stuff you thought it has. Mar 20 12:32:52 T_UNIX: i'm not saying that our findings apply everywhere, just sharing what we ran into. good luck. Mar 20 12:37:25 LetoThe2nd: i disabled everything and it's 11MB now. how do i install packages? that runs in an error: PACKAGE_INSTALL += " ntp" Mar 20 12:38:25 sysdef: for tinkering, do CORE_IMAGE_EXTRA_INSTALL += " ... " in local.conf Mar 20 12:38:40 sysdef: and as fast as possible, pour that into your own image. Mar 20 12:40:11 i do my config in ~/poky/meta/recipes-core/images/mb-v2-qemu.bb now. maybe i should search for a setup-howto ... Mar 20 12:40:29 New news from stackoverflow: External xilinx PCie driver with Yocto Mar 20 12:40:48 sysdef: ok, thats not too bad already. move it into your own layer and you're all set. :) Mar 20 12:41:04 LetoThe2nd: well, since there's apparently no way to inherit (including `.bbappend`) the direction would be a dead end anyway. Mar 20 12:41:26 i think the yocto-layer script is still included, if not, then look at devtool. we've had some churn there. Mar 20 12:41:42 i have no idea what a layer is ... *shrug* Mar 20 12:41:46 sysdef: and in your image, it is IMAGE_INSTALL += " ... " Mar 20 12:43:25 sysdef: in short: RTFM :-P in long: a layer is a collection of recipes, that can be mixed-and-matched. you usually create a layer of your own that holds all your recipes, so you do not have to pollute the poky tree you cloned, and therefore can move back and forth. Mar 20 12:43:52 play around with http://layers.openembedded.org/layerindex/branch/master/layers/ a bit to get the feeling. Mar 20 12:45:51 also see https://wiki.yoctoproject.org/wiki/images/1/1d/Ypdd-2017.02-ELC-Portland.pdf Mar 20 12:46:12 and if all else fails: https://www.buildingiot.de/veranstaltung-6616-erste-schritte-mit-dem-yocto-project.html?id=6616 Mar 20 12:46:46 oh, and a new one: https://www.yoctoproject.org/docs/what-i-wish-id-known/ Mar 20 12:49:44 ERROR: Nothing RPROVIDES 'ntp' (but /home/admin/poky/meta/recipes-core/images/mb-v2-qemu.bb RDEPENDS on or otherwise requires it) Mar 20 12:50:02 that's what i get when i use IMAGE_INSTALL += " ... " Mar 20 12:51:13 sysdef: http://layers.openembedded.org/layerindex/recipe/2299/ Mar 20 12:52:04 sysdef: so, clone http://git.openembedded.org/meta-openembedded next to poky, and add meta-openembedded/meta-networking to your conf/bblayers.conf Mar 20 12:52:16 I tried using devtool modify core-image-minimal to get my own working copy of it, but unfortunately that doesn't work. "The core-image-minimal recipe is an image, and therefore is not supported by this tool." :( Mar 20 12:54:45 sysdef: and make sure the branches of poky and meta-openembedded match :) Mar 20 12:57:02 yocto is something like a framework for openembedded? Mar 20 12:57:38 sysdef: btw: you get that when using IMAGE_INSTALL, because IMAGE_INSTALL has a meaning. PACKAGE_INSTALL just has no meaning, hence it has no effect (and no errors) Mar 20 12:58:28 sysdef: the yocto project is actually just an umbrella term for a couple of things. many people use it synonymously for "that openembedded thing" Mar 20 12:58:53 sysdef: technically, poky is a "reference distribution" built on openembedded technology. Mar 20 12:59:44 what i was searching for was something like an easy 'qemu_build_image -arch i386 -packages "openvpn,openssl,module-tun"' Mar 20 13:00:49 sysdef: openembedded is a lot of things, but most people do not associate "easy" with it. for a reason, actually. it brings both power and complexity. Mar 20 13:04:05 BBL Mar 20 13:04:16 now it's getting more and more complex and i'm not an embedded developer at all. i can try to get my software to run on that 3y/o tinycorelinux image but that doesn't fit any security claim Mar 20 13:07:37 Yeah, I can support that. We have a arm-based product and migrated from Ubuntu to yocto 3 years ago. Now, yocto is excellent at making an image which fits the needs exactly, so it's as lean as you want it. But is /is/ complex to maintain. Mar 20 13:08:41 Like now, I'm trying to embed a npm-based app of our own, and I expect to use the rest of the week to get it in. Yocto and npm are very different beasts and their ways of handling SW control is very different, so progress is slow Mar 20 13:09:36 That said, for embedded use, I'm not sure there is anything better. It gives you tremendous control, but with control comes complexity Mar 20 14:11:22 Hey, does anyone have a good method for calculating the minimal size for a block device partition so it can fit the kernel + rootfs generated by Yocto? Mar 20 14:12:29 add the sizes together? Mar 20 14:13:31 hi Mar 20 14:18:35 I'm trying to build npm-based package, and using the description in https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM, I run devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2". When I try to build the recipe, it fails with https://bpaste.net/show/18abd8b08c79 . This is with vanilla rocko poky, qemu86-64 Mar 20 14:20:03 What can I do? Mar 20 14:24:14 rburton: adding what sizes together? To give a bit more context: I'm basing my work on the vendor provided yocto set-up (variscite-fslc) to generate a double rootfs+kernel layout. Mar 20 14:25:18 Sadly the vendor requires me to provide the wanted space for my data partition iof making the rootfs partition as small as possible and the data partition as big as possible... Mar 20 14:28:55 Is npm.bbclass maintained? Mar 20 14:29:26 how do i select one of the possbily multiple DTBs provided for an image? Mar 20 14:34:30 I'm wondering if the devtool and npm isn't properly synced. Fixing the above manually in npm.bbclass, it fails once more as the package build output contains a symlink to workspace/sources/cute-files which makes bitbake stop on symlink error Mar 20 14:46:05 sysdef: well, the point is that you are actually creating a whole distribution Mar 20 14:48:00 sysdef: for a "i just want to"-usecase, it might be better to base off an existing distribution Mar 20 15:09:26 How does the mechanism for externalsrc with devtool work? The appends/.bbappend, because I suspect this is what's causing the packaging to fail Mar 20 15:10:15 seppe: image construction is typically based on making image big enough to hold what you want not the other way around, so this is some vendor crazy you need to work out yourself Mar 20 15:15:01 Well, he's not alone with this thinking. It's a pretty ordinary setup for embedded. Say you want to create a system with a dual redundant rootfs, one for the main function and one for recovery. You then need to determine the fraction between the partitions at build-time, since these things normally can't or won't be repartioned in the field later. Mar 20 15:17:56 s/build time/design time/ Mar 20 15:22:03 sveinse: externalsrc works with or without devtool, devtool just leverages it to point at an external source tree rather than the usual download/unpack/patch paradigm Mar 20 15:22:17 hello, I have trouble compiling the cpupower recipe for an i.MX6 SoM with Rocko for some reason: https://pastebin.com/jmARhWCj Mar 20 15:22:53 can it be that this tool is not even appropriate for my platform? Mar 20 15:23:53 kergoth: yeah, but for some reason npm recipes are playing havok with me in devtools. I used devtool to create the recipe, and it builds (after modding npm.bbclass), but fails to install due to a symlink into workspace/sources/ Mar 20 15:24:45 removing the devtools added .bbappend file which sets the external source, then my recipe wont fetch Mar 20 15:25:06 So I'm preplexed how the npm system is intended to work Mar 20 15:26:29 And for the record, I'm following the https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM and is using vanilla Rocko + meta-openembbeded (for nodejs) against qemux86-64 Mar 20 15:28:04 @eduardas_m msgfmt can be installed by running ./configure && make && make install in the gettext-tools directory under the gettext source root. Mar 20 15:30:17 sveinse: have you checked the git history on the class and contacted the folks that created it? worst case that'd be a viable option, presumably they'd have the answers Mar 20 15:35:07 kergoth: yeah, I probably need to take it on the mailing lists. My main problem is that I don't know if it is true bugs in poky or if it is my usage... Mar 20 15:35:59 yeah.. still worth asking about, though. it sounds like there may well be a bug relating to externalsrc+npm regardless, though, and even if it is in your usage, there's a good chance someone else has run into it too, so still worth discussing Mar 20 15:36:03 * kergoth shrugs Mar 20 15:37:00 in the devtool / workspace scheme of things, how is recipies moved into the main layers? Mar 20 15:37:46 because from what I understand, the recipes/ contains "normal" recipe code which can be copied anywhere, while the special workspace/externalsrc adoptions are made in appends/ Mar 20 15:38:07 devtool has a finish command to push the changes to the layer the recipe lives in, but iirc it doesn't move a newly created recipe made with 'create' into its location in the layer for you Mar 20 15:38:23 So in principle, removing the bbappends file in appends/ would make this recipe like any other recipe, right? Mar 20 15:39:04 yep. devtool has a reset command to do that for you as well Mar 20 15:39:38 good, thanks. Then I know that its the npm tools that is misbehaving and not my layer/recipe-handling Mar 20 15:41:59 oh, devtool reset removed the files :P Mar 20 15:44:17 Can I run devtool add and have it not setup externalsrc? Mar 20 15:46:12 i'm not sure. i don't see that devtool would add any real value without externalsrc, other than create, which is mostly independent of the other functions Mar 20 15:47:13 Then I can make my own foobar meta-layer to have it edited there as one would in a production setup Mar 20 15:47:57 I just need somewhere "normal" to build the recipe, since devtool does magic things with externalsrc Mar 20 15:48:24 that's what i'd do, bitbake-layers to create a layer for it, devtool create to get the recipe, put it in the layer, and build as usual, and only devtool modify & the rest if you need to muck with the sources, generate patches, etc, or if you want to avoid the fetch/unpack/patch process Mar 20 15:48:32 * kergoth shrugs Mar 20 15:48:48 admittedly not a devtool expert, and don't know much about external sdk or the like Mar 20 15:49:23 does the order within `OVERRIDES` imply priorities? Is it also applied to `FILESPATH`? Mar 20 15:50:15 T_UNIX: yes, and yes (though technicalli t's FILESOVERRIDES that's used for the latter) Mar 20 15:50:28 T_UNIX: the order is lowest priority to highest, later override former Mar 20 15:50:58 the intention is that more specific information always wins over less specific. machine beats arch, which beats no override, etc Mar 20 15:51:35 pinkSnake: I am using Ubuntu 16.04 and already have gettext installed... msgfmt is present on my development host Mar 20 15:51:41 kergoth: thanks :) Mar 20 15:51:55 np Mar 20 15:52:10 do I need to specifically alter `FILESOVERRIDES` or are changes to`OVERRIDES` sufficient? Mar 20 15:52:27 i don't recall, check bitbake.conf, it's what defines them Mar 20 15:53:13 bitbake.conf is also what includes machine .conf, distro .conf, local.conf, etc, and the order of those inclusions also mirrors the aforementioned priority, loosely.. unfortunately we have to parse local.conf before distro/machine since it's usually what defines them Mar 20 15:54:27 thanks for the insight :) Mar 20 15:57:29 fyi: it is not sufficient. one might use `DISTROOVERRIDES` to alter both though. Mar 20 15:59:13 kergoth: I was able to fetch and build the recipe outside devtool/workspace, and here I was able to build it proper. So this is truly a bug in npm.bbclass and not so much with externalsrc. npm is installing with symlinks which bitbake doesn't like of course. Thank you, this certainly got me longer along the path. Mar 20 16:02:57 ah, that's very good information. no problem Mar 20 16:03:42 kergoth: so if I somehow modify `FILESOVERRIDES` will it affect the `FILESPATH`s searched or just allow for `FILES_myfoo = ...` wihtin recipes? Mar 20 16:05:16 yes, FILESPATH is constructed based on an explicit base list of paths + filesextrapaths, then we check each path with the filesoverride appended, obeying priorities as you'd expect for an OVERRIDES variable Mar 20 16:05:56 see base.bbclass (FILESPATH =) and utils.bbclass (base_set_filespath function) Mar 20 16:10:05 sveinse: i just tried 'devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"' with qemux86-64 on master and it seems to complete successfully https://bpaste.net/show/33199e6d9379 Mar 20 16:10:42 tlwoerner: can you try it on rocko? Mar 20 16:11:06 sveinse: ok Mar 20 16:11:14 what version of node and npm do you have? Mar 20 16:11:43 and can you try to build the recipe? Mar 20 16:13:42 x86_64-linux/nodejs-native/8.9.4-r0/ Mar 20 16:14:43 Yeah, I have 8.4.0-r0 Mar 20 16:17:20 I have to run rocko, and 8.4.0 is the version which is bundled (and tested?) with rocko Mar 20 16:22:45 kergoth: I donot quite get the variable expansion here (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/utils.bbclass#n303). Does `getVar` return the values as provided by a overriden variable or just what's defined e.g. by `bitbake.conf`? Mar 20 16:23:37 getVar returns variables in expanded form, which includes resolving variable references (${}), running inline python (${@}), applying OVERRIDES, and applying _append/_remove operations Mar 20 16:23:49 unless you pass False or expand=False as the second argument Mar 20 16:24:00 in older releases, the default was unexpanded unless you passed True, though Mar 20 16:24:13 I.e. if I have `FILES_myoverride = 'foo'` and `FILESOVERRIDE = 'os:machine:myoverride'` does the `getVar` stmt return `foo` or `os...`? Mar 20 16:25:13 FILESOVERRIDES is only used to check paths on *disk* Mar 20 16:25:27 i.e. /path/to/the/recipe/recipename/arm instead of /path/to/the/recipe/recipename Mar 20 16:25:34 which is what FILESPATH is for Mar 20 16:25:44 only OVERRIDES apply to getVar Mar 20 16:27:31 in my example it would check `recipename/myoverride/` instead of `recipename/foo/`, right? Mar 20 16:28:21 yes. that FILES_myoverride doesn't make any sense, though, since FILESOVERRIDES doesn't apply to variable expansion, and FILES variables are per-package Mar 20 16:34:25 kergoth: right. I need some of that 'Feierabend' ;-P Mar 20 16:37:13 Hi, i use fsl yocto project given by KARO(https://www.karo-electronics.com/1646.html?&L=1) to build an embedded linux system for the KARO TX6S-8035 target. The build work fine. I use the freescale mfgtool to download images into the board. when the kernel start, i have the following error message: "Kernel panic - not syncing: Requested init /linuxrc failed (error -2)" . I use the default init system of yocto "systemVinit. Mar 20 16:38:19 Is there something in yocto to add in order to have "linuxrc" in the rootfs? Mar 20 16:52:10 kergoth: just tried your changes. For some reason my system can't find cross-sdk strip binutil when installing binutils-cross-canadian. Mar 20 16:52:19 I get error like: No such file or directory: 'x86_64-tpsdk-linux-strip' Mar 20 16:53:08 * my target - mipsel, host - x86_64, sdk-host - x86_64 Mar 20 16:53:40 How come you were able to build it successfully? Mar 20 16:57:34 If I inhibt strip process, of course binutils-cross-canadian-mipsel gets installed. I try to create the package directly by bitbake binutils-cross-canadian-mipsel. Mar 20 16:57:38 Do you do the same? Mar 20 16:59:08 Either the package must depend on the nativesdk versions of binutils, or it must get installed by default somehow... Mar 20 17:00:31 How do I proceed to request backporting a patch from master to the rocko branch? Because rocko is being fix and updated on, right? Mar 20 17:01:34 I found the master branch alreay contains a fix for the issues I'm having. This is why it is working for you tlwoerner. When I applied the patch to rocko, then everything resolves correctly. Mar 20 17:02:42 sveinse: okay, i was just getting around to the actual test Mar 20 17:02:43 which patch? Mar 20 17:03:05 tlwoerner: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/npm.bbclass?id=d38e1e2c2ea4646b34ea6282d3d7620df5b0374b Mar 20 17:06:38 I noticed something else: If I run -c cleanall on a npm recipe, it fails with checksum error on the npm sub modules. I have to use "devtool add npm://" to update the download cache. Then I can delete it with devtool reset and use it as a normal recipe Mar 20 17:07:23 kergoth: yeah, I guess I need to build nativesdk-packagegroup-sdk-host first, then try to build the cross-canadian packages. Although I am still surprised it doesn't determine the crosssdk tools dependency by default.( Mar 20 17:07:24 ...if I run -c cleanall on a npm recipe, it fails the next time I try to built it with checksum error... Mar 20 17:07:50 fancer: I'm working on a fix for that now Mar 20 17:08:07 Emm, you think it's our bug? Mar 20 17:08:14 this is the failure: https://bpaste.net/show/2c467044c98b Mar 20 17:11:20 fancer: just need to have binutils-external-cross in DEPENDS for everything, so strip is available in the recipe specific sysroot to be run by do_package. just have to make sure that dep isn't added for binutils-external-cross itself, to avoid recursion. i'll push a couple commits in a few Mar 20 17:11:33 iirc i was hitting an unrelated failure after fixing that, though, i need to check the status Mar 20 17:11:56 sveinse: hmm... i just tried with rocko and don't see an error https://bpaste.net/show/236a3f737fe9 Mar 20 17:11:57 the intent is this support should be functional and stable in meta-external-toolchain master for anyone to use regardless of toolchain Mar 20 17:12:49 Emm, I think we are talking about different things. Mar 20 17:12:50 tlwoerner: how can that be? Mar 20 17:13:21 i don't know :-S maybe check the git commits? Mar 20 17:13:35 certainly possible, yes. in exactly what context are you seeing the strip error? Mar 20 17:13:45 tlwoerner: with node 8.4.0-r0? Mar 20 17:13:55 i was seeing it in do_package for libgcc-external, as strip is required to be able to package Mar 20 17:14:02 kergoth: I see the strip error, when I try to do: bitbake binutils-cross-canadian-mipsel. Mar 20 17:14:12 but what task errored out? Mar 20 17:14:18 yes: tmp-glibc/work/x86_64-linux/nodejs-native/8.4.0-r0 Mar 20 17:14:25 ERROR: binutils-external-cross-canadian-mipsel-2.25.1-r0 do_package: Error executing a python function in exec_python_func() autogenerated: Mar 20 17:14:32 tlwoerner: what is the git hash for the poky repo? Mar 20 17:14:58 sveinse: oh... i'm not using poky, i use openembedded-core, bitbake, and meta-openembedded directly Mar 20 17:15:01 (nodistro) Mar 20 17:15:26 sveinse: check the build configuration in the paste Mar 20 17:15:28 kergoth: I suppose, it just can't find find the crosssdk version of binutils for stripping. Mar 20 17:16:19 yeah, exactly. we didn't build a crosssdk toolchain, we run the external tools, so instead we should be able to depend on the cross version Mar 20 17:16:27 aka binutils-external-cross, which is what i was just referring to Mar 20 17:16:30 tlwoerner: what is the url to the git repo I need to check out to get your "meta" repo? Mar 20 17:17:02 Emm, binutils-external-cross isn't crosssdk toolchain. Mar 20 17:17:09 doesn't need to be, it can still run it Mar 20 17:17:30 we're not building cross-canadian from source, so we don't need a crosssdk toolchain Mar 20 17:17:38 and cross recipes are installed in the native sysroot, which is in the PATH for every recipe Mar 20 17:17:55 sveinse: that is openembedded-core: git://git.openembedded.org/openembedded-core Mar 20 17:17:57 afk Mar 20 17:18:54 kergoth: No-no, we can't even use the binutils-cross to strip binutils itself. We need to use crosssdk toolchain for it, that's why bitbake failed to find x86_64-tpsdk-linux-strip. Mar 20 17:19:11 it runs it fine, i already fixed it locally Mar 20 17:19:13 as i said already Mar 20 17:19:31 the issue is external-toolchain.bbclass depends on it using do_package[depends], which doesn't add it to the recipe-specific-sysroot. adding it to DEPENDS instead fixes it Mar 20 17:21:21 tlwoerner: this is weird... npm.bbclass is identical. To the one in rocko which clearly does not work for me. And the patch in master could suggest that I'm not the only one Mar 20 17:23:13 sveinse: when our node person updates the app, i use a special "devel" image, scp the code to the running target platform, then run "npm install" there. i then collect up the stuff in ~/.npm and ~/ourapp and package it as a binary Mar 20 17:23:43 sveinse: iow, i haven't had much luck getting node stuff to work fully from the development host, only on the target Mar 20 17:24:23 tlwoerner: yeah, we have discussed the same. I'm not free to spend many days getting npm up and running Mar 20 17:25:39 Pity tough, because it won't take yocto any further in fixing the support for it Mar 20 17:27:28 kergoth: Did you fix the error I stated? do_package tries to package our cross-tools, which are going to run on SDK machine to produce binaries for target. It means do_package either need the crosssdk tool to strip our packaging binaries or we need to prevent it from stripping, right? Mar 20 17:27:46 Did you prevent it from stripping in your local tree? Mar 20 17:28:45 It also seems npm is dependent on devtool to download the modules to the download cache. If I wipe it with -c cleanall, then bitbake seems to be unable to fetch the modules without failing Mar 20 17:29:36 ok, I need to drop the yocto mailinglist a email about this Mar 20 17:30:21 kergoth: My thought was, that even though we don't really need the stripping, how come the bitbake system didn't determine, that our package is cross-canadian and it needs binutils-crosssdk for it. We inherited cross-canadian class, it should have declare such dependencies. Mar 20 17:30:39 sveinse: ok, hopefully someone has made more progress on it. there used to be meta-nodejs, but it appears to have been abandoned Mar 20 17:34:06 tlwoerner: I was told meta-nodejs was obsolete now that it has been included into the official repos Mar 20 17:34:16 here yesterday Mar 20 17:34:34 sveinse: ah, thanks for the info Mar 20 17:34:58 tlwoerner: But I don't know, I'm just the messenger Mar 20 17:38:45 tlwoerner: How has npm not been working for your project? I mean, since builds seems to be fine in your end Mar 20 17:40:23 sveinse: it's been about a month since i last tried it on the development host machine, our app has dozens (hundreds?) of node packages, some work, some fail. overall it's just easier to do it on the target Mar 20 17:40:35 in this case we're just doing one package, and this one happens to work Mar 20 17:41:27 tlwoerner: one package with dependencies, right? So the difference would only be which packages or the sheer number of them perhaps? Mar 20 17:42:00 lots of packages, with lots of dependencies... it's turtles all the way down! Mar 20 17:44:03 tlwoerner: yeah, my js guy has already frowned upon the lockdown and npm-shrinkwrap thing. He thinks this is far too detailed and specific, borderline paranoid. So the difference in thinking between npm and oe is apparent :D Mar 20 17:46:46 sveinse: because nothing ever went wrong with npm randomly installing versions from the internet Mar 20 17:47:49 rburton: no, never! But getting those devs to be aware of that is harder than I expected... Mar 20 17:52:38 The approach outlined above is very common thou: Run npm install on a (dev) system and snapshot the whole thing. Run tests and QA on that and binary distribute the whole thing. If internet breaks a package, then it's a dev problem, not a build problem. Mar 20 18:02:44 I think I'm misunderstanding how bitbake --runall works: I would have thought 'bitbake --runall package_qa core-image-minimal' would run do_package_qa on all recipes that are part of the image, but it doesn't Mar 20 18:10:15 fancer: it's a good question, it seems currently every cross-canadian recipe explicitly sets those DEPENDS itself, and cross-canadian does an INHIBIT_DEFAULT_DEPS Mar 20 18:10:21 fancer: potential area for improvement of the class Mar 20 18:10:55 fancer: if you're using my meta-external-toolchain branch, go ahead and update it. it builds now. i built an sdk for core-image-minimal, installed it, sourced environment-setup, ran eval $CC $CFLAGS $LDFLAGS hello.c -o hello and ran hello Mar 20 18:13:32 kergoth: Thanks man. I'll merge it with my changes right now. What type of SDK did you try? Mar 20 18:13:58 bitbake -c populate_sdk core-image-minimal, using the default TOOLCHAIN_HOST_TASK/TOOLCHAIN_TARGET_TASK for populate_sdk Mar 20 18:14:38 Ok Mar 20 18:17:04 ended up creating symlinks to align EXTERNAL_TARGET_SYS- with TARGET_PREFIX, since the binary names metaa-environment expects differ from what's in the external toolchain. easier to do that than muck with adjusting environment-setup only for the binaries which come from external Mar 20 18:27:19 fancer: did find an unrelated bug, nativesdk-qemu was failing to build for me, something about python2. could be related to my host, though. if you hit it, i have a workaround handy Mar 20 18:27:20 just as an fyi Mar 20 18:27:56 kergoth: thanks. I haven't for now. Mar 20 18:31:04 This weird: Mar 20 18:31:10 ERROR: Error for /media/windows/WORKSPACE/IT/T-platforms/SDK/src/yocto/meta-external-toolchain/recipes-external/binutils/binutils-external-cross-canadian.bb:do_package[depends], dependency virtual/mipsel-baikal-linux-binutils:do_populate_sysroot:do_populate_sysroot in ' virtual/fakeroot-native:do_populate_sysroot rpm-native:do_populate_sysroot file-native:do_populate_sysroot Mar 20 18:31:10 virtual/mipsel-baikal-linux-binutils:do_populate_sysroot:do_populate_sysroot' does not contain exactly one ':' character. Mar 20 18:31:53 fancer: my mistake, hold Mar 20 18:32:03 weird that it didn't fail here Mar 20 18:32:27 I could find where we got the second do_populate_sysroot...=) Mar 20 18:32:33 fixed, go ahead and update Mar 20 18:32:50 PACKAGE_DEPENDS is a list of recipes, but i left the :do_populate_sysroot there from when i was using do_package[depends] Mar 20 18:32:57 Ahh, It does so automatically Mar 20 18:32:59 yeah Mar 20 18:33:02 ok Mar 20 18:33:19 * kergoth wipes his build and rebuilds from scratch without sstate, to make sure nothing is cached Mar 20 18:41:48 New news from stackoverflow: Could not inherit file classes/pypi.bbclass with meta-raspberrypi Yocto Bitbake Mar 20 18:48:08 kergoth: ln: failed to create symbolic link ‘/mipsel-baikal-linux-ld.bfd’: File exists Mar 20 18:48:08 You shouldn't have discarded that check.) Mar 20 18:50:01 Since we got ld.bfd listed in binutils_binaries Mar 20 18:50:26 ah, that was unintentional Mar 20 18:50:31 not my day today Mar 20 18:50:48 no worries. Mar 20 18:51:01 Is there any problem with devtool add + ssh with some keys ? Mar 20 18:51:34 The simple ssh clone is working, but when I try to fetch the repo with devtool add it breaks Mar 20 18:51:55 (I mean ssh: connect to host port 22: Connection timed out) Mar 20 18:52:03 pushed the fix. i'll rebase and clean up the branch after we're done mucking with it and know it works, getting a bit cluttered Mar 20 18:52:58 Yep, if everything works for me, I'll push mu changes to public repo, so you could fetch them from there. Mar 20 18:53:06 btw Mar 20 18:53:12 kergoth: If you discard this line "INHIBIT_PACKAGE_STRIP = "1"" from mets-external-toolchain/classes/external-toolchain.bbclass, you'll end up with error I was talking about.) I suppose the cross-canadian tools should also have have the direct dependency from "virtual/${SDK_PREFIX}binutils-crosssdk", like you did for all external toolchains and "virtual/${SDK_PREFIX}binutils". Mar 20 18:53:16 export SSH_AGENT_PID= seems to be correct Mar 20 18:55:07 Thing is, I need the standard libraries being stripped, since my sysroot should be as small as possible. My target for just 16MB for U-boot, Kernel, rootfs compressed images. Mar 20 18:58:22 yeah, iirc it's assuming that it's already stripped and/or has debug files split out already, but that's not necessarily the case for all toolchains Mar 20 18:58:23 testing now Mar 20 18:58:45 Ok Mar 20 19:04:14 Dumn it binutils-crosssdk-* is so heavy... Mar 20 19:07:19 as we're packaging binaries we already know run on both this host and the host we're installing the sdk on, we should actually be able to use host tools rather than crosssdk tools Mar 20 19:07:33 Any hints on how to debug devtool ssh connections ? Mar 20 19:07:35 which means we can just run 'strip' and 'objcopy' from the build machine Mar 20 19:07:36 testing it now Mar 20 19:08:42 fancer: pushed that change, if you want to test it Mar 20 19:08:50 i have a new populate_sdk going, but it'll take a while Mar 20 19:11:54 New news from stackoverflow: Install SciPy issue under Yocto Mar 20 19:11:59 kergoth: Ok, just merged and started my build Mar 20 19:19:06 yep, it worked.) Although it started fetching binutils-crosssdk-* anyway when I had ran the populate_sdk task.) Mar 20 19:20:36 yeah.. depends on what you're including in the sdk. crosssdk still needs buliding to build the nativesdk stuff being included in the sdk. we could dep on it, but it's a bit unnecessary in this case, no point pulling in deps we don't need Mar 20 19:20:43 * kergoth shrugs Mar 20 19:21:04 ok Mar 20 19:22:17 Presumably since we know the build machine and sdk install machine are one and the same, we could hack nativesdk to use host tools as well and just exclude crosssdk entirely Mar 20 19:22:28 would have to be an opt-in behavior, of course, due to that assumption Mar 20 19:22:39 will give that some thought Mar 20 19:23:19 s/one and the same/compatible/ Mar 20 19:23:38 that said, the toolchain was probably built in such a way that its more binary compatible across linux hosts than anything oe builds itself Mar 20 19:23:48 so maybe best to keep the current behavior and only bypass it for external bits Mar 20 19:24:12 iirc sourcery toolchains are built on ancient linux hosts to avoid glibc versioning issues re: binary portability Mar 20 19:25:34 yeah, right. It must be optional somewhere. I would think fo to have something like meta/conf/sdk.conf and put there all the SDK-related variable default together with one you said, which prevents nativesdk being built. Mar 20 19:26:18 s/nativesdk/crosssdk Mar 20 19:27:43 would basically need to 1) remove the deps on the crosssdk bits, and 2) ensure that it runs the binaries with the correct prefixes, i.e. compare native vs nativesdk so the latter runs the same tools as the former Mar 20 19:28:01 so it runs 'gcc', not x86_64-oesdk-linux-gcc or whatever Mar 20 19:28:13 not a priority in my mind at hte moment, more an optimization to reduce build time Mar 20 19:29:01 i won't be able to put too much more time into this, mentor doesn't really need this feature much, but i think it's a good one to have in the layer to support the community, this isn't the first time someone has mentioned it. still, have to switch back to my other priority tasks soon. let me know how your builds go Mar 20 19:32:33 I see. I won't have time for this either. Need to get back to kernel/u-boot dev. Mar 20 19:32:39 Ok, I will Mar 20 19:35:42 It will take some time. I am doing the build on my laptop, which is old 'a bit'.) Mar 20 20:04:39 does anyone recall if there is a fix for qemu image in for "INIT: Id "hvc0" respawning too fast: disabled for 5 minutes" ? Mar 20 20:29:00 Does anyone knows jussi's handle here? Mar 20 21:07:09 Where is the most appropriate place to disable creation of the /etc/hostname file? Mar 20 23:24:54 aehs29: would be jku Mar 20 23:29:12 * armpit tests oe world builds with YP sstate mirror Mar 21 00:12:54 New news from stackoverflow: Yocto - Where is the most appropriate place to disable creation of /etc/hostname **** ENDING LOGGING AT Wed Mar 21 03:00:02 2018