**** BEGIN LOGGING AT Fri Nov 23 03:00:01 2018 **** BEGIN LOGGING AT Fri Nov 23 05:33:47 2018 Nov 23 06:43:10 how to add source subtree to the kernel recipe with .bbappend? Nov 23 08:29:13 Dvorkin: there is git submodule support: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-fetchers Nov 23 08:30:26 ernstp, thanks. I mean not from the git, but from the local folder Nov 23 08:31:41 Dvorkin: not sure what you mean.... Nov 23 08:33:39 ernstp, the additional source contains a lot of files and two patches to enable it. It is not ready to be included to some git so I'm having it in the local filesystem and I just need to copy it to kernel subfolder before kernel build. Nov 23 09:02:36 Dvorkin: if you're just developing I would recommend devtool modify kernel-recipe-name Nov 23 09:10:33 ernstp, thanks. I've thought about it Nov 23 09:34:56 is there a way to detect in a recipe if the kernel has CONFIG_SMP set? Nov 23 09:39:22 LetoThe2nd> maybe by reading .config in kernel staging dir? Nov 23 09:40:56 nayfe: feels dirty. Nov 23 09:42:03 indeed :) Nov 23 09:50:21 Hi, any GO recipe guru ? :) Nov 23 09:51:12 isn't that a paradox? Nov 23 09:51:44 I hate it! ;) Nov 23 09:52:50 I'm trying to create recipe for https://github.com/mongodb/mongo-tools. I manage to create it for one tool (ie mongoimport) but when I add a new GO_INSTALL, it overwrites build/bin/main as every tools folder are named "main" see https://pastebin.com/scdMmWbw . Nov 23 09:55:35 recipe here https://pastebin.com/Br7yb3cB Nov 23 09:56:43 Hi folks. How to avoid an issue with 'rfkill' utility? In my case it by default blocks the bluetooth iface each time after the system reboot. To unblock it, need to call: rfkill unblock bluetooth... How it can be solwed in Yocto context? Nov 23 09:57:49 kuzulis: maybe create a systemd/sysvinit service to kill it on system reboot? Nov 23 09:59:28 nayfe: Yes, maybe. But it is strange that Yocto has not a pre-defined 'recipe' for that. Nov 23 09:59:49 nayfe: Is it possible do not include the rfkill at all? Nov 23 10:00:22 well if you don't need the utility, then don't install it. Nov 23 10:02:17 LetoThe2nd: How I can 'don't install it'? Nov 23 10:02:30 are there any known race conditions in kernel external module recipes/bbclasses in sumo? Nov 23 10:02:42 kuzulis: well it certainly comes from some package. do not install that package Nov 23 10:03:19 kuzulis: oe-pkgdata-util is your freind here Nov 23 10:03:52 if you use systemd there is this line ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} Nov 23 10:04:50 nayfe: Does this means, that a WiFi recipe depends on RFkill recipe? Nov 23 10:05:21 Morning! Any folks know much about how the sstate cache works? Nov 23 10:05:58 nayfe: I need in 'wifi'.. Nov 23 10:06:35 kuzulis> it means systemd will compile with rfkill option, but rfkill is maybe from busybox Nov 23 10:07:25 busybox_cfg(bb.utils.contains('DISTRO_FEATURES', 'wifi', True, False, d), 'CONFIG_RFKILL', cnf, rem) in busybox recipe Nov 23 10:08:09 and same with bluetooth Nov 23 10:09:32 nayfe: I don't understand, what does this means: "(bb.utils.contains('DISTRO_FEATURES', 'wifi', True, False, d), 'CONFIG_RFKILL', cnf, rem)" ? Nov 23 10:10:07 Hi everyone, I am using meta-mingw to create SDK for windows. The final SDK produced is always tar.xz compressed as in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass#n228 . Will it be possible to control the compression? I also wanted to use "--dereference" option to tar. Do we have some external variables to control this? Nov 23 10:10:08 busybox will add rfkill if wifi or bluetooth (next line) is enabled in distro Nov 23 10:10:11 nayfe: And what is a best way to fix my issue? Nov 23 10:11:44 nayfe: Ok, thanks. Let's say, that I now want to keep the rfkill utility.. Then, do I need to write an own recipe with a custom systemd service which will call 'rfkill unblock bluetooth' ? Nov 23 10:13:02 nayfe: It is strange for me, why the rfkill blocks only the bluetooth, but does not blocks the wifi? Nov 23 10:15:21 i know nothing about rfkill :) Nov 23 10:15:32 do you have a recent yocto/kernel version? Nov 23 10:16:12 nayfe: No, I use kernel 4.1.x Nov 23 10:16:31 not that bad :) Nov 23 10:17:25 nayfe: Just I din't see any Yocto layers which examples of rfkill-unblock service in my Yocto sources Nov 23 10:18:47 kuzulis: you can check https://github.com/nefethael/meta-random/tree/master/recipes-example/peakusb for simple systemd recipe Nov 23 10:20:58 nayfe: Ahh.. PeakCAN!! A good choose! :) Many thanks. Nov 23 10:27:25 Morning Nov 23 10:32:52 Morning... Is this visible? Just moved to a new irc client and not sure if working! Nov 23 10:34:31 no_such_user morning Nov 23 10:34:39 Aha! Thanks :-) Nov 23 10:34:42 :) Nov 23 10:38:20 kuzulis: if you're using connman note that out of the box that disables comms until the user turns them on Nov 23 10:38:24 nayfe: Is in that example, that service automatically started after reboot? Nov 23 10:38:52 nop, it's just an systemd service recipe example Nov 23 10:39:15 kanavin: any idea why the libdnf upgrade would take 300s more to build? Nov 23 10:39:38 So, is anyone have a reasonable handle on using the sstate cache? It seems that it's advantageous to use a workflow that involves project specific sstate mirrors but not sure how much or how little to include in each mirrored cache... Should one use a single cache for each poky release or one per build / target? Nov 23 10:39:51 kuzulis: but it is automatically called by systemd Nov 23 10:40:04 no_such_user: you can just share a single cache if you want Nov 23 10:40:37 so you'll need to set nothing in ExecStart, and just put your unblock in ExecStop Nov 23 10:41:04 rburton: Ok, thanks for info Nov 23 11:01:35 rburton: how does -next look? I know there were AB fails but they were either odd (debian selftest only) or the PRAUTO thing on opensuse423 Nov 23 11:08:33 mcfrisk: what are you seeing? Nov 23 11:15:29 RP: we need more regular builds of master to populate the buildhistory ;) Nov 23 11:15:59 RP: as the builds are faster now maybe we *should* have an actual automated master run at 2am Nov 23 11:20:57 rburton: yes, we probably should do something like that Nov 23 11:21:27 rburton: called nightly? Nov 23 11:21:30 * RP hides Nov 23 11:21:33 hehe Nov 23 11:22:50 if we kick it at 2am or so then you shouldnt be pushing and it will be done by morning Nov 23 11:23:13 good for keeping buildhistory fresh, and repeatedly running the qa to shake out random failures Nov 23 11:23:42 rburton: yes, I like the idea. Will disrupt some of armin's stable builds but I think we have the capacity to run both Nov 23 11:24:09 yeah, especially if nothing has landed, it will rush through in no time Nov 23 11:25:02 rburton: right. I've just run a master-next, see if this opensuse issue is resolved and see what state more patches are in. About half of -next has been through Nov 23 11:25:22 just doing a test build now and have a pile to rebase again Nov 23 11:25:31 iptables is bust, so don't pick that Nov 23 11:26:15 rburton: I saw your reply, thanks Nov 23 11:33:08 rburton: scheduler added for 1am Nov 23 11:35:07 nice Nov 23 11:43:10 Anybody around? I'm having trouble building scipy. Nov 23 11:43:20 It says it's missing setuptools, but it's not Nov 23 12:07:25 la_croix did you check https://stackoverflow.com/a/47869912/6225741 ? Nov 23 12:09:39 nayfe I can try importing distutils too. I don't currently inherit setuptools, but setuptools3. Should I therefore inherit disutils3? Nov 23 12:13:03 sure Nov 23 12:15:42 but sometimes you have to fix setup scripts with patches to get it work on yocto Nov 23 12:16:31 Hi everybody. How can I make a task signature depend on a file content. The file is part of SRC_URI and used inside the task, but the bitbake-dumpsig doesn't list it as dependency Nov 23 12:18:39 interruptguy: if its part of SRC_URI then it changing will cause a rebuild Nov 23 12:20:52 nayfe Adding distutils didn't help... Nov 23 12:21:57 rburton, My problem is related to do_install. I do use `install ...` and `sed ...` to change some stuff, so basically my file is a template. If I change the template content I can see a package rebuild but the resulting file from the template is not updated. However if I run `bitbake recipe-name -C install` I can see the results Nov 23 12:38:19 I'm using cronie from recipes-extended. How should I add my own task during the build process? Specifically, I want it to run a python script under a particular user Nov 23 12:42:22 la_croix: with addtask Nov 23 12:43:51 la_croix: under a particular user? how is that going to happen? Nov 23 12:43:57 nayfe That will append to the crontab? Nov 23 12:44:09 interruptguy: sounds like your task is broken can you share the recipe? Nov 23 12:45:18 rburton According to the docs: https://github.com/cronie-crond/cronie cronie allows running a cron task as a particular user. I'm not wedded to using cronie, frankly, I just want to be able to add a task to the crontab of some non-root user Nov 23 12:45:50 To clarify, this is not a build task, it's a regular cron task Nov 23 12:51:04 rburton, I cannot share the recipe but I can provide a version that shows my situation. Do you have a preference how to share it? Nov 23 12:51:14 rburton, and thanks for help Nov 23 12:56:10 rburton Do I just need a recipe that literally edits the crontab (sed or similar) or is that bad practice? Nov 23 12:57:17 rburton, kanavin: we have a problem - the dnf python issue has crept into master :( Nov 23 12:57:48 https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/7 - I don't think its from anything in -next Nov 23 13:03:59 New news from stackoverflow: Interfacing ft5x06 touchscreen with yocto Nov 23 13:09:38 rburton, kanavin: perhaps dnf needs to inherit python3-native? Nov 23 13:10:44 hmm, it does Nov 23 13:14:47 Hello everyone, trying to build a toolchain via bitbake -c populate_sdk. I get following error: Nov 23 13:15:01 make[1]: *** No rule to make target 'all'. Stop. Nov 23 13:15:56 Any advice ? I look into the recipe which contains after oe-runmake a "all-host" target Nov 23 13:23:57 moritz_: did you specfy yje image at the end? Nov 23 13:24:17 moritz_: bitbake -c populate_sdk imagename Nov 23 13:27:59 moritz_: a little more context would help like the name of there recipe which fails and the full error Nov 23 13:35:52 interruptguy: pastebin Nov 23 13:36:09 la_croix: oh right, just write a crontab then Nov 23 13:36:49 rburton ok, so I can just have a recipe that sticks a crontab into the correct place? (I'm asking mainly about best practice, etc) Nov 23 13:36:51 rburton, kanavin: easy way to reproduce the dnf problem, rename your host libyaml-0.so.2 out the way Nov 23 13:36:58 Anyone know what might cause a strange artifact on a Raspberry Pi 3 yocto image - every process fails to exist, and instead turns into a zombie/defunct process Nov 23 13:38:36 fails to exit* rather Nov 23 13:38:39 not fails to exist. haha Nov 23 13:57:46 la_croix: yes Nov 23 14:02:42 If I have MACHINE ?= "sumfink" in local.conf, doing a MACHINE="foobar" bitbake image_name should override it, right? Nov 23 14:04:15 yes Nov 23 14:09:01 Next question: For building a virtualbox image, I set my MACHINE to qemux86 and append wic.vmdk to IMAGE_FSTYPES. But of course, that's incompatible (and fails to build) when my machine is set to the actual target (ARM) platform. Since I can't append from the command-line (?) how would I go about doing this? ...besides scripting the build and conditionally sed'ing my conf/local.conf Nov 23 14:10:02 just put those lines in local.conf as they're specific to the build *you* are doing. nothing else of substance should in there anyway Nov 23 14:10:32 you could do a image_fstypes override in your distro if you always want a vmdk when building for x86 Nov 23 14:11:19 I could probably override my IMAGE_FSTYPES from the command-line like I do with MACHINE, but since it's appending and I don't know what else is in there... I can't..right? Nov 23 14:11:57 So would it make sense to have a IMAGE_FSTYPES_append_qemux86 in my image bb? Nov 23 14:12:09 well, i'd do it in your distro conf Nov 23 14:12:12 but image if you want Nov 23 14:12:28 Ok Nov 23 14:12:34 I don't have a distro.conf Nov 23 14:12:54 you should Nov 23 14:13:17 local.conf should solely consist of a DISTRO assignment and setting TMPDIR etc Nov 23 14:13:28 and any other tweaks that are *yours*, not your products Nov 23 14:14:54 Ok. I actually don't put anything in there (except the defaults from oe-env) besides the MACHINE variable Nov 23 14:15:24 put it in the image then for now Nov 23 14:15:55 I should read up on distro.conf Nov 23 14:20:14 I lied. I also put OE_TERMINAL in my local.conf :p But that's exactly the kind of "*my*" specific stuff like you mentioned. :p Nov 23 14:21:02 indeed Nov 23 14:23:28 RP: okay i admit i'm ignorant of how sstate actually works. does the docs cover how to write a new task that puts something in sstate Nov 23 14:24:08 Hi guys. I find it a bit odd that docs refer to a *single* service file for SYSTEMD_SERVICE https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#var-SYSTEMD_SERVICE while several recipes define multiple service files in SYSTEMD_SERVICE for a single package (see watchdog, cups, dhcp, bootchart, nfs-utils recipes). Nov 23 14:24:50 diego_r: patch welcome! Nov 23 14:25:26 Is multiple service file in a single SYSTEMD_SERVICE definition acceptable? How should be SYSTEMD_SERVICE interpreted in that case? Nov 23 14:26:06 rburton: sure, but I want to understand what should be fixed :) Nov 23 14:26:15 multiple is allowed Nov 23 14:27:54 is it possible to enable a service and disable another one inside the SYSTEMD_SERVICE? In other words, is there a sane way to set SYSTEMD_AUTO_ENABLE for each service inside the SYSTEMD_SERVICE list? Nov 23 14:28:14 rburton: probably not exactly. Easier is to take an existing example Nov 23 14:28:23 diego_r: no Nov 23 14:28:24 rburton: how is your meson magic? :) Nov 23 14:28:31 RP: flakey Nov 23 14:29:11 rburton: any idea how to edit a meson probject and make it inject the right RPATH into the binary? Nov 23 14:29:31 oh, rpath breaking again? Nov 23 14:29:35 rburton: basically dnf issue is missing RPATH in libmodulemd Nov 23 14:29:37 i thought we got that fixed a while back Nov 23 14:29:46 RP: #mesonbuild :) Nov 23 14:30:14 rburton: I barely know what meson is Nov 23 14:30:18 RP: so basically do_mytask[sstate-inputdir] = where-my-task-writes-files and [sstateoutputdir = where-i-want-them-to-end-up Nov 23 14:30:33 inputdir being something under workdir and outputdir being eg something under deploydir Nov 23 14:30:33 rburton: yes Nov 23 14:30:48 easy Nov 23 14:30:55 rburton: so multiple is allowed in SYSTEMD_SERVICE, but discouraged if you want to enable / disable one by one. Would that be ok to write in the docs? Nov 23 14:31:04 rburton: I think you need to define a setscene task and addtask that iirc too Nov 23 14:31:14 diego_r: well you can't enable/disable per-service at all Nov 23 14:31:18 (currently) Nov 23 14:31:23 so no need for the disclaimer Nov 23 14:31:49 RP: and that just has to call sstate_setscene (from image.bbclass)? Nov 23 14:39:44 rburton: yes Nov 23 14:40:15 rburton: deploy.bbclass is a good example Nov 23 14:40:46 rburton: there is an SSTATETASKS += too Nov 23 14:40:53 rburton: if I'm reading the bbclass correctly: if SYSTEMD_AUTO_ENABLE is set to "enable" all services are enabled; if SYSTEMD_AUTO_ENABLE is set to "disable" all services are disabled. Is that correct? Nov 23 14:41:35 yes Nov 23 14:41:46 patches welcome to extend that obviously Nov 23 15:04:11 rburton: https://github.com/habitat-sh/core-plans/pull/1551/commits/047e4f4b93c99a26e99c93833259f8ce0f5e8ad7 - basically everyone hacks meson to stop it manipulating rpaths Nov 23 15:35:05 Hey, any idea when meta-java thud branch will be up ? :) Nov 23 15:37:50 otavio mario-goulart ? Nov 23 15:39:55 rburton_: trying -next again with the meson fix Nov 23 16:13:54 RP: thanks for looking into this Nov 23 16:14:39 kanavin_home: np, just hoping it fixes the problem! Nov 23 16:23:21 RP: then I can try to get perl-sanity closer to working shape. not sure if it's a good idea... :) Nov 23 16:23:56 kanavin_home: as long as your own sanity doesn't suffer! :) Nov 23 16:24:49 RP: I worry that it actually might :) Nov 23 16:29:17 If Im writing some housekeeping scripts that need to know the state of variables set in the build (eg MACHINE, DISTRO etc) is there a "right" way to do this? Should I execute "bitbake -e" in my script and parse the output, or write my script and wrap it in a bitbake recipe? Nov 23 16:35:10 kanavin_home: so do I, perl cross isn't fun Nov 23 16:40:11 no_such_user: -e works fine for most people Nov 23 16:40:34 no_such_user: the alternative is to write your housekeeping scripts in python and then they can just poke at bitbake's data store using the tinfoil api Nov 23 16:57:44 rburton_: Ah, thanks! Id not considered the python approach - is there any particular simple example worth looking at? Nov 23 16:58:31 verify-bashisms is python and pokes at the data store Nov 23 17:00:23 rburton_: That's cracking, thanks! **** ENDING LOGGING AT Sat Nov 24 02:59:58 2018