**** BEGIN LOGGING AT Mon Oct 14 02:59:57 2019 Oct 14 04:55:18 I am trying to add wifi-support to my distro by adding DISTRO_FEATURES += "wifi". When I try to bitbake it tells me that it is missing distro feature "x11". Is x11 really required for wifi support? Oct 14 04:57:06 it's not, no Oct 14 05:06:41 Any idea what could be causing that requirement? Could it be something else in my specific setup? Oct 14 06:21:38 iceaway: well, find out which file triggers the missing distro feature warrning Oct 14 06:21:59 it should be mentioned right with the message itself, in fact Oct 14 06:24:39 hello. why is resolved still disabled in systemd? afaik it can be compiled since 240 Oct 14 06:36:24 ak77: i you want it, it should always be possible to activate it for your usecase Oct 14 06:52:33 good morning Oct 14 07:10:36 good morning to all Oct 14 07:24:53 good morning Oct 14 09:15:56 I'd like to create a release file in the rootfs as last step before generating a yocto image. maybe, `/etc/os-release`. This file would contain the git hash and/or git tag which was used to build. what is the recommended way to do that? Oct 14 09:18:31 ricardocrudo:/etc/os-release gets automatically created from the information that your DISTRO is supposed to set. Oct 14 09:19:55 ricardocrudo: recommended is probably something like https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image-buildinfo.bbclass or being inspired by that. Oct 14 10:24:00 Hi, Is there quick solution for "no current session" after devshell -c ? Oct 14 10:43:48 New news from stackoverflow: Yocto esdk cannot find header file and static lib Oct 14 11:41:47 Hi, i've created a recipe for "ulogd2" since there was none. How can I contribute it to the community for others which might find it useful? Oct 14 11:43:31 kautschuk: giving it only a very quick superficial look, maybe submitting it to meta-openembedded, the meta-networking layer? Oct 14 11:44:32 thx. I figured that would be the right layer, but how exactly to i submit a patch? Oct 14 11:45:46 kautschuk: generally like this: 1) you pull the desired upstream 2) switch to a local branch 3) commit your changes, with s-o-b 4) git format-patch the changes 5) git send-email Oct 14 11:46:17 ok perfect. thx. Oct 14 11:46:32 kautschuk: I think this could be helpful: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Oct 14 11:46:35 kautschuk: this approach holds true for most git based projects these days :) Oct 14 11:46:39 qschulz: ++ Oct 14 11:47:23 again: thx for helping a newbie Oct 14 11:47:42 kautschuk: np, have fun Oct 14 12:16:07 Hi there, I've been working on SPDX identifier this weekend, I'm wondering if Makefiles shall too have a SPDX id ? Oct 14 12:23:09 hello.Is there migration instructions fot yocto layers?. The nxp imx6ull documentation and myirtech's layer references the meta-fsl-arm layer which is depricated. I am getting lots of errors (base_contains not defined, no qt recipe) Oct 14 12:28:28 kayterina: for the yocto project maintained things (basically poky and whatever it includes) there is https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration Oct 14 12:28:38 kayterina: for all other layers, as their maintainers. Oct 14 12:30:42 I see. Oct 14 12:38:07 the migration guide should cover stuff like base_contains being deleted Oct 14 12:38:18 but yes harass the maintainers is the first step Oct 14 12:39:05 rburton: we should not encourage harassment. Oct 14 12:39:26 all we do are "friendly and extremely polite reminders"! Oct 14 12:42:10 yes, that Oct 14 12:50:12 hello folks Oct 14 12:50:47 why is it that oe-run-native uses the sysroot-destdir of a native recipe, instead of the image/ directory? Oct 14 12:51:28 isn't the sysroot-destdir supposed to only contain dependencies for other recipes that depend on that native package? when executing the recipe's binary, I would think that image/{bin,usr/bin} is the correct folder to use? Oct 14 12:51:43 well image is only populated during do_install Oct 14 12:52:26 yeah. that's what I think aswell Oct 14 12:52:49 so that is the most "pure" directly when it comes to mirroring a recipe's target structure. Oct 14 12:53:03 would you want to force do_install to run every time you wanted to run a binary? Oct 14 12:53:45 rburton, hm, but the way it is now, that it uses STAGING_DIR_NATIVE, it needs to ensure that do_install runs aswell, in order to use up to date binaries, I think? Oct 14 12:53:50 no Oct 14 12:54:05 oe-find-native-sysroot uses STAGING_DIR_NATIVE, which is $WORKDIR/recipe-sysroot-native Oct 14 12:54:17 so its just a matter of populating the sysroot Oct 14 12:54:21 which is all from sstate Oct 14 12:54:25 even with a clean tmp Oct 14 12:54:33 ah, it's supposed to use a recipe's build tool sysroot-native folder Oct 14 12:55:08 I was confused. I thought it's supposed to be used for -native recipes Oct 14 12:56:02 tbh it might not even work, as nothing elses uses oe-run-native Oct 14 12:57:01 so if i want to execute the "file" utility, then I cannot use "oe-run-native file-native file", but I have to manually go into file-native's image directly and run it from there Oct 14 12:57:29 because file-native's recipe-sysroot-native of course doesn't contain the file binary, but only the file binary's build dependencies Oct 14 12:57:44 right, the tool predates the recipe-specific-sysroot functionality Oct 14 12:57:50 so potentially was ported, badly Oct 14 12:59:15 oe-run-native bmap-tools-native bmaptool --help Oct 14 12:59:16 Running bitbake -e bmap-tools-native Oct 14 12:59:17 usage: bmaptool [-h] [--version] [-q] [-d] {create,copy} ... Oct 14 12:59:17 works fine Oct 14 12:59:23 rburton, if I disable the packaging functionality for my mingw target (which seems sane), then I think after building all my recipes, at the end I should iterate over all the image/ directories and take out the results from there Oct 14 12:59:47 ah right, it requires addto_recipe_sysroot, whcih adds *itself* to the sysroot Oct 14 12:59:59 rburton, ah, I see! Oct 14 13:00:00 litb: i'd keep packaging on Oct 14 13:00:08 no point reimplementing it Oct 14 13:01:02 for final app deploy you can have a little class to drop the static binary or whatever into deploydir Oct 14 13:01:32 rburton, all that stuff with package splitting seem not to be useful for windows, where everythign will at the end be put into a single installer (MSI or similar) anyway Oct 14 13:01:55 does it hurt to keep it enabled? Oct 14 13:03:24 rburton, I think it could be useful to at the end generate an SDK with a gcc-cross-canadian that has host linux with target linux Oct 14 13:03:47 i suppose that the SDK scripts take -staticdev and -dev packages Oct 14 13:04:22 correct, SDKs are just special images Oct 14 13:04:26 w Oct 14 13:04:27 :w Oct 14 13:04:31 rburton, some INSANE checks will need to be disabled. staticdev for instance will complain about .dll.a import libraries being in -dev Oct 14 13:04:36 ETERM/EVIM Oct 14 13:05:28 rburton, I think i will keep it enabled, but with my own FILES and PACKAGES. thanks for the heads up Oct 14 13:08:07 remember to share your layer when you make it work :) Oct 14 13:08:19 hopefully we can suck it into meta-mingw and oe-core Oct 14 13:09:26 rburton, i will need to recreate it at home, because this is closed source :p Oct 14 13:09:39 booo, tell your employer to open it Oct 14 13:09:45 but maybe it's worth the effort Oct 14 13:10:16 absolutely, if you can ship the bulk of it into core and meta-mingw then your maintenence disappears. when oe-core breaks mingw we fix it... Oct 14 13:10:32 keeping patches around is a hassle, so I have good chances to convince them Oct 14 13:41:39 RP: why does qemu-helper-native do addtask addto_remove_sysroot? Oct 14 13:42:33 i guess its to add the built binary to the recipe-sysroot-native automatically Oct 14 13:43:26 why not just explicitly call that instead of doing something special Oct 14 13:51:37 rburton: explicitly call it from where? Oct 14 13:51:50 rburton: you mean recipe, not remove, right? Oct 14 13:52:03 erm, yes Oct 14 13:52:45 well runqemu does bitbake qemu-helper-native directly, that could easily add -caddto_recipe_sysroot Oct 14 13:53:34 that and systemtap are two recipes that override how that task works Oct 14 13:59:24 rburton: is it causing a problem? Oct 14 13:59:30 rburton: I'm sure we did this for a reason... Oct 14 13:59:34 no just curious Oct 14 14:00:07 rburton: It may have been user expectation - that recipe is useless without it? Oct 14 14:00:17 systemtap was 373ea52b896c85655f8883ee7608a4c038c9f120 Oct 14 14:00:44 of course oe-run-native could throw in a bitbake -caddto_recipe_sysroot for you Oct 14 14:01:15 rburton: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0637c5ab2579e03d5e503211b0b9d7e3c11e9af1 Oct 14 14:01:26 right was looking at that Oct 14 14:01:36 so yes, runqemu could just invoke the right task directly Oct 14 14:02:08 rburton: I think there may have been oeqa implications too Oct 14 14:03:17 rburton: Faced with "fix all the call sites" or add the dependency, which would you do? Oct 14 14:03:29 well how many calls sites is 'all' Oct 14 14:03:36 rburton: well, we didn't know :/ Oct 14 14:03:54 rburton: RSS did break a previously working workflow, this made it compatible Oct 14 14:04:08 rburton: so I can see why we'd have done it Oct 14 14:04:13 right, but i suspect the number of call sites is ~3 so maybe we can clean it up Oct 14 14:04:13 sure there are other ways Oct 14 14:04:21 anyway just noticed it Oct 14 14:05:59 rburton: -next is clean, should that merge? Oct 14 14:06:06 will look Oct 14 14:11:37 kanavin: top marks on the selftest for the license work Oct 14 14:27:05 perhaps the order of ${PN}-staticdev and ${PN}-dev in PACKAGES should be reversed? Oct 14 14:27:47 because in -staticdev, files only have suffix "*.a", but in -dev, files have a suffix that's user-configurable through SOLIBS. for example, for me it's ".dll.a" Oct 14 14:28:26 what is a .dll.a file? Oct 14 14:29:06 rburton, importlib in mingw. Apparently mingw uses .dll.a as importlib, while windows linkers use .lib as import lib (aswell as for static libs) Oct 14 14:29:15 fun Oct 14 14:29:20 so I'm setting SOLIBS = ".a" and SOLIBSDEV = ".dll.a" Oct 14 14:29:37 if i were you i'd just override FILES_${PN}-staticdev globally Oct 14 14:29:42 however the ordering of -staticdev and -dev makes this not work. i suspect I can easily change that order in my distribution config though. Oct 14 14:30:08 bonus points for a patch to add a variable like SOLIBS so the machine can just fiddle those Oct 14 14:30:33 ah I see. from the comment to this line in bitbake.conf, it seems that they also had an ordering problem of the two: SOLIBSDEV_darwin = ".dylibbroken" Oct 14 14:31:12 right Oct 14 14:33:44 kanavin: does glib really need the full py3 for the test suite? Oct 14 14:34:58 RP: something happened to sysprof in buildhistory Oct 14 14:35:02 packages/core2-64-poky-linux/sysprof/sysprof-dbg: PKGSIZE changed from 1889968 to 0 (-100%) Oct 14 14:35:33 rburton: from -next? Oct 14 14:35:36 yes Oct 14 14:35:40 looking at the buildhistory Oct 14 14:35:46 rburton: well spotted Oct 14 15:22:33 rburton_, kanavin: Its because we now disable libsysprof due to a hard polkit dependency Oct 14 15:22:39 which disables sysprof Oct 14 15:34:30 quick question! Oct 14 15:34:42 this is how SELECTED_OPTIMIZATION is defined: SELECTED_OPTIMIZATION = "${@d.getVar(oe.utils.vartrue('DEBUG_BUILD', 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}" Oct 14 15:35:06 why doesn't bitbake figure out that SELECTED_OPTIMIZATION depends on all those three other variables? Oct 14 15:35:14 next line is SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION DEBUG_BUILD" Oct 14 15:35:32 bitbake doesn't track "oe.utils.vartrue", so it doesn't know args 2 and 3 are variable names Oct 14 15:35:37 that's part of oe, not bitbake Oct 14 15:35:50 it recognizes getVar, etc Oct 14 15:36:21 er, all the args are variable names, not just 2 and 3, but you get the point Oct 14 15:40:11 ah I see. Oct 14 15:42:33 we track variable usage by parsing python code into an ast and basically doing naive static analysis, but python is a dynamic language, attempting to track what the names are is often non-trivial Oct 14 16:12:46 RP: sysprof without polkit just ships some metadata for stuff that isn\t installed and a small static library Oct 14 16:12:52 not worth having in oe-core Oct 14 16:13:14 RP: https://pastebin.com/zKiyme6n Oct 14 16:13:35 eg the dbus files are for a daemon that isn't installed Oct 14 16:19:23 rburton_: right, we need polkit to make it useful Oct 14 16:19:50 tbh i'm happy enough with adding polkit to oe-core, as systemd can use it too Oct 14 16:20:27 alternatively we can just rip sysprof out... Oct 14 16:20:45 heh, bitbake -e | bat -l BitBake -> syntax highlighted -e Oct 14 16:20:48 (OT) Oct 14 16:20:56 oh nice bat does bitbake Oct 14 16:21:13 bat supports textmate/sublime syntax/themes Oct 14 16:21:16 so you can install wahtever Oct 14 16:21:57 i heavily use bat+fd-find+ripgrep+fzf nowadays, with a bunch of aliases. i have cat=bat when stdout is a tty at the moment Oct 14 17:15:26 I need to modify the cmake toolchain file created by cmake.bbclass "after do_patch before do_configure". I suspect the best way is to INHERIT a class of my own, and check with bb.data.inherits_class for the presence of this class Oct 14 17:16:35 and do that checking using an event handler. I believe there's a PreFinalize handler for such purposes. and in the handler, delete the do_generate_toolchain_file, replacing it by my own Oct 14 17:17:39 that sounds cleaner than trying to shadow the cmake.class using a same-named class in my layer. I hear that's frowned-upon Oct 14 17:19:56 agreed, i've done that sort of hacking before. it's not pretty, but better for your maintainance than copy+modify, that's a pain to track every time you update your upstream layers Oct 14 18:15:10 New news from stackoverflow: Can't compile qemu with yocto Oct 14 19:17:36 Hello guys, i'm very knew to yocto and want to build a raspberry pi image. i get this "WARNING: Your host glibc verson (2.30) is newer than that in uninative (2.29). Disabling uninative so that sstate is not corrupted." Warning. i found somebody who said that i should use warrior, but i'm already on the warrior branch on every git repo (poky, oe, raspi-bsp). after a few hours of searching trough the internet i'm a bit frustrated... i hope Oct 14 19:17:36 somebody of you can help me Oct 14 19:19:11 ruru4143: actually its only a warning thats telling you the included uninative blob is not used. probably its not a problem at all. Oct 14 19:20:57 LetoThe2nd: okey, thank you Oct 14 19:44:39 ruru4143: replied on stack overflow already Oct 14 19:45:16 if you get that either you found another breakage, or you're not running tip of warrior branch Oct 14 19:48:19 ruru4143: if you're definitely on tip or warrior then file a bug please **** ENDING LOGGING AT Tue Oct 15 02:59:57 2019