**** BEGIN LOGGING AT Mon Nov 19 03:00:00 2018 Nov 19 03:36:59 cslcm: what do you need from that layers ? nodejs is now in meta-oe Nov 19 03:42:58 New news from stackoverflow: How to know who is included a particular recipe in yocto Nov 19 07:29:17 cslcm: meta-nodejs is kinda outdated anyways, i'd support massive breakage on newer revisions. Nov 19 10:35:18 hi Nov 19 10:37:19 are rootfs image creation tools (i.e. `mkfs.ubifs`) expected to be provided by the build host system or by yocto? Nov 19 10:37:47 T_UNIX: they are provided by the build Nov 19 10:39:11 that's weird then... I'm facing `run.do_image_tar.1067: mkfs.ubifs: not found` using `crops/yocto:ubuntu-16.04-base` docker image to build Nov 19 10:41:42 T_UNIX: can't comment on crops Nov 19 10:42:22 T_UNIX: or maybe your imagetype is not properly set up, if you are using something custom Nov 19 10:42:52 but i'm certain we are building ubi images here too, and that mkfs for ubi is not available in the host Nov 19 10:44:12 LetoThe2nd: that's a good start then :) Nov 19 10:46:23 thanks! Nov 19 10:46:48 T_UNIX: do you have mtd-utils-ubifs ? Nov 19 10:53:22 I do. But, I guess, never mind. There seems to be some kind of inconsistency weirdness. `IMAGE_FSTYPES` is set to `tar.gz`, yet `do_image_tar` executes `mkfs.ubifs` on its first line O.o Nov 19 10:53:54 T_UNIX: sounds like somebody hacked up your image creating. thats the one to blame Nov 19 10:57:23 yeah. Probably pebcak :-D Nov 19 12:24:17 Hi guys. How choose a required kernel version to build? e.g. I use own layer, which depends on meta-toradex-nxp layer. That 'meta-toradex-nxp' layer provides multiple kernels, like: meta-toradex-nxp/recipes-kernel/linux/linux-toradex-3.14.52/4.1/4.1.15/4.4 and so on.. When I compile my image, it creates a kernel with version 4.1.44... I don't understand, how the Yocto know which version t compile? Nov 19 12:29:55 kuzulis: if nothing specific is set, then its the highest version of all recipes that provide virtual/kernel and are marked as compatible with your given machine. Nov 19 12:30:35 kuzulis: typical places for such things to be set is the .conf file of the machine. Nov 19 12:38:23 Hi I'm trying to add some extra config to uboot/config.txt, using the following in the local.conf: RPI_EXTRA_CONFIG = "dtparam=audio=on \n dtparam=i2s=on". The problem is that it seems to have no effect at all... Nov 19 12:40:14 la_croix_: because the u-boot build process does not know anything about your bitbake/recipe settings. Nov 19 12:40:44 la_croix_: here's a pretty detailed rundown: https://stackoverflow.com/questions/47047209/how-to-change-the-config-of-u-boot-in-yocto/47062520#47062520 Nov 19 12:41:05 LetoThe2nd Great, thank you Nov 19 12:41:12 la_croix_: sepcifically, the EDIT / ADDEDNDUM part. Nov 19 12:41:49 LetoThe2nd So, is this wrong? https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html Nov 19 12:43:35 la_croix_: no idea. it looks pretty hackish, and is certainly layer specifc. Nov 19 12:45:49 LetoThe2nd Fair enough, thanks :) Nov 19 12:45:57 la_croix_: https://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/tree/recipes-bsp/bootfiles/rpi-config_git.bb Nov 19 12:46:20 la_croix_: this is something that relates to the gpu thing, not to u-boot. i seriously suggest avoiding it. Nov 19 12:46:40 LetoThe2nd Ok, I'll do that. Thanks :) Nov 19 12:51:09 LetoThe2nd: Hmm.. ok. thanks. Nov 19 12:51:44 LetoThe2nd: But, can I set another custom kernel version ? Nov 19 12:52:07 LetoThe2nd: e.g. pull a latest from the repo ? Nov 19 12:52:13 kuzulis: sure, why not? Nov 19 12:52:27 LetoThe2nd: how I can do it tnen? :) Nov 19 12:52:40 kuzulis: just modify the recipe accordingly, respectively create your own based on those that are already there. Nov 19 12:54:15 LetoThe2nd: so, just in my layer try to 'override' a kernel recipe with own *.bbappend, where puth to the SRC path a desired kernel version (e.g. from GIT?) Nov 19 12:54:48 LetoThe2nd: s/puth/put Nov 19 12:54:56 kuzulis: if you look at this for example, you can pretty much easily see where SRCREV is set: http://git.toradex.com/cgit/meta-toradex-nxp.git/tree/recipes-kernel/linux/linux-toradex_4.9-1.0.x.bb Nov 19 12:55:12 kuzulis: so in your append, just override that line Nov 19 12:57:29 LetoThe2nd: So, as I understand, there are a two ways to pull a newest Kernel version: 1) it is just clone a fresh 'toradex' layer (e.g. master), 2) it is just override required recipe with my recipe? Nov 19 12:58:39 not "create a fresh toradex layer". you should do all your work in your custom layer anyways. so, if oyu need bigger modifications than juser one or two variables, then you should copy over the starting point you want into your own layer and then modify it according to your needs. Nov 19 12:59:08 if you need to just tweak SRCREV, then put an append into your layer and, well, tweak SRCREV Nov 19 13:00:01 LetoThe2nd: ok, many thanks Nov 19 13:53:04 LetoThe2nd: I found the culprit. I appended another `DISTROOVERRIDES` variable (`STORAGEMEDIUM`). That mysterically lead to inclusion of ubifs rootfs code. Even though the `IMAGE_FSTYPES` variable says `.tar.gz` Nov 19 13:53:34 does one need to remove and rebuild everything if one modifies DISTROOVERRIDES? Nov 19 13:55:10 T_UNIX: no idea, i can jsut tell you it sounds nasty. Nov 19 13:55:55 sure. But since it takes a few hours to rebuild everything, I was wondering whether it's inevitable. Nov 19 13:57:22 no idea, sorry. i've never had to use one of those OVERRIDE things so far. to me its got the feeling of "JUST MAKE IT WORK NOW I DON'T CARE ABOUT BREAKAGE LATER"... and now you seem to have reached that "later" Nov 19 14:00:35 I use OVERRIDEs to leverage bibakes FILES search path mechanism in context of multiple image/product/hw combinations. Nov 19 14:01:04 https://www.youtube.com/watch?v=IhKQl1zGihc @ 0:22 Nov 19 14:05:01 if i have a svn://blah SRC_URI, is the SRCREV the revision number to grab? Nov 19 14:06:21 yates: probably the revision number Nov 19 14:06:50 yates: https://www.yoctoproject.org/docs/2.4.1/bitbake-user-manual/bitbake-user-manual.html#svn-fetcher Nov 19 14:08:04 LetoThe2nd: thank you! Nov 19 14:08:48 yates: have fun. Nov 19 15:15:24 LetoThe2nd Hi, do you remember that custom module thing that you helped me with? I've discovered that it works, but only if I ssh in and run 'modprobe my_loder'. Do you know how I would get it to load on boot? conf.local contains both IMAGE_INSTALL_append = " my_loader " and KERNEL-MODULE-AUTOLOAD-append = " my_loader ", but neither of them are doing it... Nov 19 15:15:40 why doesn't "export" work inside of a do_compile()? isn't it bash? Nov 19 15:16:17 la_croix_: KERNEL-MODULE-AUTOLOAD-append is wrong Nov 19 15:17:20 la_croix_: the variable is called KERNEL_MODULE_AUTOLOAD and -append isn't anything, you need underscore Nov 19 15:18:31 nm. my mistake Nov 19 15:18:35 it does work Nov 19 15:19:08 and the package name probably doesn't match with the actual module filename, so you need to specifi it as described in docs Nov 19 15:20:30 JaMa Oops, so fix that, and remove IMAGE_INSTALL_APPEND? Nov 19 15:36:03 what directory does do_compile put you in when it is invoked? in terms of ${S}, etc.? Nov 19 15:36:17 is it simply ${S}? Nov 19 15:36:57 yates: i'g guess {B} Nov 19 15:37:03 ${B} Nov 19 15:40:02 LetoThe2nd: in that document on svn repos you referred me to earlier, does the "module=" translate to a variable in the build environment? i need to cd inside my do_compile() to ${B}/${MODULE} Nov 19 15:40:34 yates: no idea, sorry. i'd have to try, tinker and findout myself Nov 19 15:40:45 ok, np Nov 19 15:40:52 you can always do ls, pwd, whatever in do_compile, and abort with exit 1 Nov 19 15:41:09 right Nov 19 15:41:10 so you'd directly see your debug output instead of having to go through the log file stuff Nov 19 15:41:42 i know the directory, but i'd rather not hardcode it in, in case i change my module= Nov 19 15:42:45 yates: bitbake -e your recipe, and see if the module thing translates somewhere. if not, do it the other way round: define a variable and use that for module= and your do_compile Nov 19 15:43:02 yates: then pass it as a variable Nov 19 15:43:29 RP: i think the core question is if the module= setting from the svn fetcher already ends up in a variable Nov 19 15:43:37 yates: SVNMODULEDIR = "xxx" and use ${SVNMODULEDIR} in both SRC_URI and do_compile Nov 19 15:44:06 LetoThe2nd: right, I'm suggesting to use it as a variable in SRC_URI Nov 19 15:44:08 makes sense Nov 19 15:44:09 exactly, just what i said (without picking names, though) Nov 19 15:44:35 LetoThe2nd: right, I think we overlapped, sorry :) Nov 19 15:45:04 RP: i'm always happy to technically overlap with you. makes me feel less stupid :-) Nov 19 15:45:12 :) Nov 19 15:45:14 New news from stackoverflow: How to clean populate_sdk in yocto Nov 19 15:45:27 LetoThe2nd: you're definitely not stupid Nov 19 15:45:41 i have yet to achieve "technical overlap with RP"-dom... Nov 19 15:45:47 ooooooh *sighs* Nov 19 15:57:23 @khem the version of node in meta-oe is out of date, unfortunately Nov 19 16:24:48 yocto downloads the source controlled files into a recipe-name-based location. what if my source control files provide a number of different recipes? it is redundant to download the source controlled files for each recipe. is there an alternative? Nov 19 16:25:49 no, tht's not correct. downloads go to DL_DIR regardless of recipe nme Nov 19 16:25:54 it's not isolated by recipe at all Nov 19 16:26:20 and it's not re-downloaded if it was completed once, even if the do_fetch task re-runs Nov 19 16:29:28 i'm seeing my files at /tmp/work/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/server-6300/1.0-rc0-r0/tags/production-server-1.0-rc0, and server-6300 is my recipe base_name and tags/production-server-1.0-rc0 is my module string Nov 19 16:29:48 is that a symlink? Nov 19 16:30:17 (remove one of those tmp/work/ above) Nov 19 16:32:15 or did i somehow screw up the recipe? Nov 19 16:32:20 https://paste.fedoraproject.org/paste/vfWJpeUvJ0Pnbbe~qJgsAw Nov 19 16:32:25 (so far) Nov 19 16:34:01 kergoth: ^^^^^ Nov 19 16:34:44 fiels are downloaded in do_fetch from upstream into DL_DIR (see your local.conf), then they're "unpacked" from DL_DIR to WORKDIR in do_unpack, then patched in do_patch Nov 19 16:34:56 in the case of files which don't need extracting (i.e. not a tarball, zip, etc), it's just copied Nov 19 16:35:49 ah. Nov 19 16:35:53 ok, thanks Nov 19 16:38:39 huh, https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#new-recipe-fetching-code mentions the behavior, but doesn't explicitly call out what unpack does if it isn't extracting anything, and the description of do_unpack is pretty weak at all, specifically covering S but not WORKDIR Nov 19 16:38:44 should probably improve the docs on that Nov 19 16:44:37 i have another issue: at the beginning of my do_compile task my pwd is /tmp/work///vers-r0/ Nov 19 16:45:30 yet my files are at /tmp/work///vers-r0/ Nov 19 16:46:04 i could cd, of course. but is there a reason yocto is expecting the build to be done in the original pwd? Nov 19 16:48:27 yates: It's the default starting directory when building (${B}). You can change it if you have a different "build" directory Nov 19 16:49:15 change what? B? S? the current working directory? Nov 19 16:49:31 i could get it to work, but what's the "right" way to do it? Nov 19 16:49:47 yates: I think the "right" thing to do is change B Nov 19 16:50:31 ok, thanks Nov 19 16:51:18 yates: However, by default B = ${S}, so if you aren't doing an "out-of-tree" build, it might be easier to set S and let B get picked up from it Nov 19 16:53:23 is there a variable at do_compile() time that shows the directory the unpacker unpacked to? Nov 19 16:54:04 yes, set S Nov 19 16:54:36 Thats what "S" is for... it defaults to a commonly correct answer, but is frequently overridden (e.g. for recipes that use a git fetcher that doesn't follow the normal rule). Nov 19 16:54:53 yates: You see a lot of S = "${WORKDIR}/git" for that reason Nov 19 16:54:59 this *is* mentioned in the link ijust pasted, fyi Nov 19 16:55:22 ok Nov 19 17:15:07 is there an emacs mode for .bb files? Nov 19 17:22:52 do_compile() success! Nov 19 17:23:07 \/ Nov 19 17:27:35 thanks for all the direction/pointers/help Nov 19 17:35:50 this has been valuable: https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Nov 19 18:19:20 why am I getting these from master: Nov 19 18:19:29 WARNING: core-image-base-1.0-r0 do_rootfs: locale-base-en-us.postinst returned 1, marking as unpacked only, configuration required on target. Nov 19 18:19:50 ERROR: core-image-base-1.0-r0 do_rootfs: Postinstall scriptlets of ['locale-base-en-gb', 'locale-base-en-us'] have failed. If the intention is to defer them to first boot, Nov 19 18:20:01 then please place them into pkg_postinst_ontarget_${PN} (). Nov 19 18:21:19 this is oe-core master in distroless/no-distro config. I can't seem to find any misconfiguration in local.conf... Nov 19 18:22:31 Hello, trying to build linux-intel-rt on thud, and keep runnning into the dreaded: Unsupported relocation type: R_X86_64_PLT32 (4) error, which usually is resolved by downgrading binutils to 2.30 versus 2.31. Should I just bbappend all the binutils recipes or does someone know of a better solution off hand. Nov 19 18:42:09 why am i getting this warning: https://paste.fedoraproject.org/paste/4aaKEQXZRsoVvXDqM9DvrQ Nov 19 18:43:19 or more to the point, why is my key getting overridden/replaced? Nov 19 18:51:19 yates: Not sure... would need to see the recipe Nov 19 19:10:48 yates: you defined FILES_server-6300 when you should be setting or appending to FILES_${PN} instead Nov 19 19:11:17 expansion of variable references in variable names occurs at a specific point in the parsing process, from bitbake's perspective they're two entirely different variable names until it's expanded Nov 19 19:11:26 at which one the latter replaces the former, as described in the message Nov 19 19:11:53 if we expanded it immediately, it'd cause problems with use of variables that aren't yet defined at hte time that line is parsed Nov 19 19:14:50 that's deep Nov 19 19:17:18 i actually had already changed it to FILE_${PN} before i read this and noticed it worked, and was mildly bewildered. Nov 19 19:23:49 do the path/files specified in FILES have to be in the corresponding paths in ${D}? Nov 19 19:26:01 if have a FILES_${PN} = "${bindir}/myfile", does that have to have previously been installed into ${D}/${bindir}/myfile? or can it be in ${D}/myfile? Nov 19 19:28:58 yes. Nov 19 19:29:01 works Nov 19 19:29:04 do_package works now Nov 19 19:54:56 yay! Nov 19 19:55:24 i did a "smart install server-6300" on my target device - works! Nov 19 19:55:28 excellent! Nov 19 19:55:57 i'm starting to like this project.. Nov 19 19:56:33 it's powerful Nov 19 19:59:14 with the old smart package manager, can you specify multiple package feed uris so that it will try one after the other? Nov 19 19:59:18 like dnf/yum? Nov 19 19:59:42 PACKAGE_FEED_URIS = "http://172.16.1.32 file://thumbdrive/repo" Nov 19 20:00:04 tias you say? Nov 19 20:16:09 yates: that should work yes Nov 19 20:16:34 denix: I don't see any postinstall scripts for those packages - have you enabled anything in your configuration that might have added some? Nov 19 20:17:38 bluelightning: YOCTO #13028 Nov 19 20:18:13 oh right, yes Nov 19 20:20:06 looks like it was never adapted :/ Nov 19 21:23:58 is there recipe for version 3.0.2 of wxWidgets? i see 2.9.5 but we need 3.0.2 Nov 19 21:34:52 What layers does the AUH scan? Nov 19 21:40:41 JPEW: are you talking to me? Nov 19 21:40:57 yates: Not specfically Nov 19 21:41:14 what is AUH? Nov 19 21:41:20 JPEW: AUH is primarily for layers that poky uses Nov 19 21:41:31 other layers havent yet adopted it Nov 19 21:41:35 yates: AUH = Auto Upgrade Helper Nov 19 22:10:58 i've updated my package feed uris like this: PACKAGE_FEED_URIS = "http://172.16.1.32 file://run/media/sda1" Nov 19 22:11:43 i did a cp -r tmp/deploy/rpm /thumbdriveroot Nov 19 22:12:28 then i booted the target without enabling the wifi, and inserted the thumdrive, which gets mounted at /run/media/sda1 Nov 19 22:12:47 i can "smart update" just fine - it appears to run and update the cache Nov 19 22:13:28 but when i "smart install server-6300", it tries to pull it over the network and fails, never attempting from the thumbdrive: Nov 19 22:13:47 https://paste.fedoraproject.org/paste/PhbjrMqXlV1Ly8r7-P-Vsg Nov 19 22:14:48 JPEW: ask nicely and it can be extended to scan others layers. maybe don't ask for meta-oe first :) Nov 19 22:15:22 why isn't it pulling from the thumbdrive? Nov 19 22:15:36 JPEW: i think the yocto-hosted auh can easily be told to do other layers, or alternatively the source is open so anyone can host their own Nov 19 22:16:04 rburton_: Sure, I was looking more at meta-mingw for the mingw-w64 headers/libraries... but it looks like devtool doens't handle nativesdks in a completely automated manner yet Nov 19 22:16:19 shame Nov 19 22:16:25 filed a bug for that? Nov 19 22:16:38 rburton_: Sure Nov 19 22:34:01 should it be file:///run/media/sda1 instead of file://run/media/sda1? Nov 19 22:38:56 rburton_: its ok to include meta-oe layers but I will ignore them for the mails which send updates and fixes Nov 19 22:39:46 but it would be good to have an account of pending package updates for meta-oe I agree Nov 19 22:40:37 yates: do file URIs work with smart ? **** ENDING LOGGING AT Tue Nov 20 02:59:58 2018