**** BEGIN LOGGING AT Tue Nov 13 02:59:59 2018 Nov 13 04:20:29 * OutBackDingo offers $$$s for the secret bitbake recipes to an encrypted rootfs running core-image-weston to anyone... khem ? nrossi ? Nov 13 08:45:58 khem: Waiting for root device /dev/mapper/crypt... ??? Nov 13 08:55:38 OutBackDingo: i assume you have configured your kernel with /dev/mapper and crypt support? Nov 13 09:00:12 OutBackDingo: if yes, also make sure if they are configured as modules that they are included in your initramfs Nov 13 09:04:43 nrossi: how do i include them in initramsd froom local.conf or do i need a bb recipe Nov 13 09:05:55 OutBackDingo: depends, first check if they are included already or not by checking the image manifest in deploy/images/..../.manifest Nov 13 09:06:36 OutBackDingo: you should see kernel-module-dm-crypt (or similar not sure the exact module name) at least Nov 13 11:21:23 FYI: on sumo, setting S to custom directory with a trailing slash / triggers race conditions in RSS sysroot generation.. so beware Nov 13 11:26:42 How do I add extra compilation flag for package build with Yocto? I want to build with NEON SIMD enabled Nov 13 11:36:22 mcfrisk: bug please :) Nov 13 11:53:08 learningc, what package? Nov 13 12:02:38 Crofton, opencv :) Nov 13 12:55:58 I've bbappended to init-ifupdown in order to provide my own "interfaces" file, but on first-run (e.g. after doing some modifications) it always fails on "[...] license-destdir’: No such file or directory". Works fine if I re-run my bitbake. Any ideas how to fix it? Seems like a race-condition.. Nov 13 12:56:37 The issues that Google shows me seem really old.. Nov 13 13:04:48 Hi. We recently upgraded our OS and kernel from an ancient kernel vesion, 2.6.35.14, to 4.9.28. Now when the RAM is used up the system freezes, and before we would get a panick and it would reboot. Swap and OOM-killer are turned off in both cases. Why does it freeze now? I would prefer if it just panic'ed. Nov 13 13:45:02 New news from stackoverflow: Trying to create sample linux mage with yocto prject but cause building error Nov 13 14:02:03 rburton: I was going to ask if there was any sort of testing for meta-mingw.... I guess that answers the question :) Nov 13 14:02:57 JPEW: build test yes, run test, no Nov 13 14:03:44 Right. I was thinking about it, and maybe it would be useful (and easier to test) if the SDK had a built in "self test"? Nov 13 14:04:34 JPEW: not sure about that. We do already have SDK tests, they would just need wine Nov 13 14:06:39 RP: Ya, I did see those. I think Wine is a good idea, but it would also be nice to have the option to run some tests on actual different Windows versions Nov 13 14:07:54 JPEW: that is probably a new set of tests since even testexport won't work on windows easily Nov 13 14:08:24 RP: Right.... possibly just straight python3+unittest Nov 13 14:08:43 * RP hates duplication Nov 13 14:10:28 RP: Indeed.... wine makes sense as a first step (I'm assuming that so that it can be run on the autobuilders?). The rest we can think about for a while Nov 13 14:11:11 JPEW: we'd probably need to add something to the host dependencies or build a -native for it Nov 13 14:11:24 * RP doesn't know how feasible a -native it Nov 13 14:11:26 is Nov 13 14:12:56 JPEW: my only worry about installing host side would be the wide differences in host versions. That said we could do it on a specific worker Nov 13 14:13:09 (wine specific build tied to a specific worker with wine) Nov 13 14:15:09 New news from stackoverflow: Create and run an application on pandaboard using Qt Nov 13 14:17:07 RP: I'll look Nov 13 14:17:31 ...hmm I'm really not convincing myself that I *shouldn't* be a maintainer of meta-mingw Nov 13 14:23:08 JPEW: :D Nov 13 14:45:48 JPEW: well if we were running on gitlab we could add a windows builder to the CI pool for the mingw tests Nov 13 14:45:49 * rburton runs Nov 13 14:46:22 RP: i think for what mingw will need, any host wine will be sufficient Nov 13 14:46:31 just get halstead to drop it on all the workers Nov 13 14:46:42 its not like gcc is going to be using the latest directx api Nov 13 14:47:16 rburton: you clearly haven't used wine for a while :/ Nov 13 14:47:24 heh, true Nov 13 14:48:15 rburton: btw, leaning to taking the avahi ptest on the basis that more could be added Nov 13 14:48:33 rburton: merge -next and move onward with master now? Nov 13 14:48:46 RP: seriously doubt more could be added fwiw Nov 13 14:48:50 * RP suspects he's got as far with thud as we're going to Nov 13 14:48:56 it doesn't have a non-interactive test suite really Nov 13 14:49:05 and the initial ones barely count as a test suite Nov 13 14:49:26 rburton: the names of the others did sound promising Nov 13 14:49:56 some of them just start services and expect the developer to inspect Nov 13 14:50:04 rburton: I guess I'll leave it then since you've looked at them Nov 13 14:51:39 rburton: this new sources mirror test is going to be annoying for master-next and mut since selftest will error due to "missing" sources which haven't made the mirror yet due to the new additions in the build :/ Nov 13 14:52:28 RP: just firing a local build of next here to give it my approval Nov 13 14:52:39 rburton: ok Nov 13 14:52:54 rburton: the autobuilder isn't good enough for you? :) Nov 13 14:53:06 doesn't (yet) show me buildhistory-diff Nov 13 14:53:33 rburton: er, http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/ Nov 13 14:53:39 oh right Nov 13 14:53:41 forgot ;) Nov 13 14:54:05 dare i ask how big that repo is to clon Nov 13 14:54:33 hmm, it may not have a decent recent master build to compare against Nov 13 14:54:44 rburton: smaller than it used to be? Nov 13 14:55:38 rburton: anyhow, help improve this! :) Nov 13 14:56:43 yeah the repo is huge :) Nov 13 14:57:58 single-branch cloning to the 'rescue' Nov 13 14:58:07 only 140k objects instead of 700k Nov 13 14:58:22 It does build history for every arch :) Nov 13 15:20:36 nrossi: feels like its all there, just not proompting me fopr a password to decrypt it Nov 13 15:20:52 rburton: let me ask a different question - what output is useful based on buildhistory? Nov 13 15:21:03 systemd or init script missing ? Nov 13 15:31:35 RP: the buildhistory-diff against master Nov 13 15:41:24 rburton: put a text file into the build output somewhere? Nov 13 15:41:26 buildhistory-diff in that repo is a bit knackered Nov 13 15:41:42 rburton: knackered how? Nov 13 15:41:46 master not being up to date? Nov 13 15:42:07 bb.utils.VersionStringException: Invalid version specification in "(dev).tmpl'" - invalid or missing operator Nov 13 15:42:11 i thought we fixed that Nov 13 15:42:28 packages/x86_64-nativesdk-pokysdk-linux/nativesdk-libpng/nativesdk-libpng-dbg: PKGR changed from r0 [default] to r0.0 Nov 13 15:43:15 the output is *huge* but its 99% the sdk version changing, so every nativesdk package path changed Nov 13 15:45:27 New news from stackoverflow: bitbake - custom image task called twice Nov 13 15:46:39 rburton: we should probably add that version to the list of things to filter? Nov 13 15:47:07 do some builds enable or disable pr service? Nov 13 15:56:59 OutBackDingo: sorry was afk. Yer sounds like you don't have anything that initializes the mapped mount. The cryptsetup recipe looks like it has a default for systemd systems but nothing for sysvinit Nov 13 15:57:54 rburton: Its tested in oe-selftest Nov 13 16:02:57 RP I am thinking of backporting scritps/autobuilder-worker-prereq-tests for sumo Nov 13 16:03:51 armpit: I'm not sure we'd run them there would we? Nov 13 16:04:48 armpit: the prereq tests are the ones which quickly test if a new worker is working, we then have the nightly-bringup target to actually test the corner cases like oe-selftest which could be from different releases Nov 13 16:05:14 so you would only use master to do that? Nov 13 16:05:27 armpit: I think so, at least that is how we're using it Nov 13 16:05:51 k Nov 13 16:09:32 * RP notes bugzilla reminding him "Your mind needs to be slightly warped to understand runqueue.py" Nov 13 16:11:14 ha Nov 13 16:12:38 i created a do_install_append() function in base-files_%.bbappend which appends a line to ${D}${sysconfdir}/fstab Nov 13 16:14:03 which works, but my previous attempt was appending the wrong line to fstab and after bitbaking with the new function, that old, erroneous line is is still in the fstab file (before the new, correct line) Nov 13 16:14:17 doesn't bitbake detect this is a dependency and rebuild the file? Nov 13 16:14:48 changes to do_install will re-run do_install, which should result in recopying/creating it Nov 13 16:15:24 kergoth: but i didn't change do_install(), rather my do_install_append() in my custom layer Nov 13 16:15:52 are you sugesting i make a fake change to do_install() to get it to regenerated/ Nov 13 16:15:55 regenerate? Nov 13 16:15:59 no, you're misunderstanding how the file format works Nov 13 16:16:03 _append concatenates Nov 13 16:16:11 do_Install_append appends to do_Install, thereby changing do_Install Nov 13 16:16:18 so changes to that should re-run the task Nov 13 16:16:48 was this a bug? i'm still using morty... (please don't yell at me) Nov 13 16:17:22 kergoth: i indeed changed my do_install_append() and indeed my new rootfs.tar.bz2 had the old line in. Nov 13 16:17:49 here is my base-files_%.append: https://paste.fedoraproject.org/paste/aBzHNENRcD2o-n17gcOGsw Nov 13 16:17:49 I just noticed a new patchwork group "Yocto Project Layers" Nov 13 16:17:57 doesn't make much sense unless base-files is writing to ${D} in do_compile or something equally broken Nov 13 16:18:03 what layers are those ? Nov 13 16:18:28 armpit: things from yocto@ Nov 13 16:18:49 so meta-security and meta-virt ? Nov 13 16:18:55 armpit: hopefully Nov 13 16:19:15 kergoth: here is the poky/meta/recipes-core base-files file: https://paste.fedoraproject.org/paste/i0Ph7c8NbWXQh4pbobFyAw Nov 13 16:19:23 fyi, if that helps explain something. Nov 13 16:19:24 RP thanks will help Nov 13 16:20:08 is that correct? or broken? Nov 13 16:21:31 am i doing something stupid? Nov 13 16:22:16 isn't the last argument to the "install" command the destination? Nov 13 16:23:09 RP is I run a rocko build, will it interfere with QA testing ? Nov 13 16:23:30 armpit: no Nov 13 16:23:33 k Nov 13 16:25:07 kergoth: ? Nov 13 16:25:48 I'm trying to move my yocto build to a different hard drive, deleted tmp and conf and rebuilt, but I'm getting errors that "useradd command did not succeed", https://pastebin.com/6ni7QiiC Nov 13 16:26:34 Do I need to also delete my state-cache? Nov 13 16:26:54 nope Nov 13 16:27:18 Oh and that error only happens when I try to use devtool modify Nov 13 16:28:57 kergoth: "nope" to me or someone else? Nov 13 16:30:43 * yates wonders if kergoth has /ignored him Nov 13 16:31:41 nathani_: at a guess there is some dependency missing which devtool is not understanding. Have you tried building the thing you want to modify before running the modify command? Nov 13 16:31:51 nathani_: if that works it would be worth a bug report Nov 13 16:32:22 yates: fwiw that append looks right to me which suggests either it isn't being found or that something else is also changing that file Nov 13 16:33:12 RP: ok. i'll look and see if there is another base-files Nov 13 16:34:02 RP: Thanks, I did a cleanall on the recipe and bitbaked it without issue. And devtool was working before I removed the old location. Nov 13 16:34:52 nathani_: something old in workspace ? Nov 13 16:35:30 RP: also removed the workspace Nov 13 16:36:31 nathani_: not sure then sorry Nov 13 16:36:33 Trying to think of anything else I can remove, before I do a full rebuild. Nov 13 16:36:44 RP: no problem, thanks for the 2nd opinion Nov 13 16:37:13 nathani_: sstate is meant to be path independent so it shouldn't be that Nov 13 16:37:32 (we test that very heavily on the autobuilder) Nov 13 16:38:08 RP: there is one other base-files_%.bbappend but it just does this: https://paste.fedoraproject.org/paste/LqNIMIwJqzPiqaVwkGiH-Q Nov 13 16:39:04 yates: what about other fstab files there? Nov 13 16:43:29 RP: yes! that was it. the fstab in the tmp/work/... directory had been modified. i think i did that when i was using the wrong variables in my fstab path prefix in my bbappend Nov 13 16:43:32 thanks. Nov 13 16:43:50 i think.. Nov 13 16:44:00 i need to rebuild to make sure Nov 13 16:45:41 where is the final place for the raw fstab file before it gets zipped up into rootfs.tar.bz2? Nov 13 16:52:28 Hi, I'm upgrading our BSP from krogoth to sumo, but I am stuck at kernel module recipes. Nov 13 16:53:13 We have kernel-module-foo and kernel-module-bar. The bar module needs header files that foo module installs. Nov 13 16:55:39 I added DEPENDS = "kernel-module-foo" to the recipe of module bar. And the foo include files appear in recipe-sysroot of kernel-module-bar. Nov 13 16:56:35 But still I get a error when compiling module bar saying that it can't find the foo header files. Nov 13 16:57:38 Any suggestions how to make this work in Yocto sumo ? Nov 13 17:21:56 i did a fresh build a yesterday. a XYZrootfs.tar.bz2 file was generated. i deleted that file and reran bitbake. that file is not being rebuilt. why? Nov 13 17:23:16 (in tmp/deploy/images//, that is) Nov 13 17:24:04 doesn't bitbake regenerate files when they are missing? Nov 13 17:25:23 https://paste.fedoraproject.org/paste/qHSuQrXdWe-5kvu66Dq~DQ Nov 13 17:26:11 @yates: what bitbake command did you use ? Nov 13 17:26:49 Winfried: bitbake hw-test-image Nov 13 17:29:03 am i losing my mind, or is there a big problem here? Nov 13 17:29:21 Yes, that should regenerate the image, Nov 13 17:31:10 Or maybe not. Do 'bitbake hw-test-image -c clean' and then 'bitbake hw-test-image'. Nov 13 17:33:22 Winfried: i am doing that now. but why should i have to do this? shouldn't bitbake be smart enough to know to regenerate missing files? Nov 13 17:39:24 ...crickets... Nov 13 17:42:13 yates: don't delete stuff from deploy. problem solved Nov 13 17:44:33 yates: if you delete the corresponding stamps in tmp/stamps it will rerun tasks Nov 13 17:45:11 yates: bitbake is not like make and does not maintain a list of every file under tmp and how to rebuild each one. There are millions of them and it would be near impossible to track reliably Nov 13 17:47:07 georgem: why not just allow things to segfault? problem solved! Nov 13 17:47:26 RP: i probably forgot that. Nov 13 17:47:34 yates: ? Nov 13 17:54:34 ok, this is evil. Nov 13 17:56:19 after doing a "bitbake hw-test-image -c clean" i can find no files "fstab" or "base-files*" with the string "XYZ" (figurative). Nov 13 17:57:04 yet after doing a "bitbake hw-test-image", the /ext/fstab found in rootfs.tar.bz2 has the (wrong) string "XYZ". Nov 13 17:57:43 as i mentioned earlier, this string was an error i had made yesterday. now it seems to be indelibly "stuck" in yocto... Nov 13 17:58:12 must I recheck the entire repo and rebuild from scratch? Nov 13 17:59:49 https://paste.fedoraproject.org/paste/DLdwfgJBg59fvBvcYmUCdg Nov 13 18:00:07 there must be something stuck in the sscache? Nov 13 18:00:45 line 7 is wrong, line 8 is correct Nov 13 18:01:34 here is my bbappend (again, for reference) https://paste.fedoraproject.org/paste/EgqZSQHYsGoofjIGngdZ8g Nov 13 18:04:25 help? Nov 13 18:05:46 is there a way to regenerated the ss-cache? Nov 13 18:05:52 simply remove it? Nov 13 18:06:30 RP: thoughts? Nov 13 18:06:59 i'd rather not wait another 2+ hours for this to rebuild... Nov 13 18:07:10 yates: remove all the *base-files* from sstate ? Nov 13 18:07:32 yates: I suspect you managed to corrupt the cache if you were poking around work/ by hand Nov 13 18:08:07 yates: a "bitbake base-files -c cleansstate" may do it? Nov 13 18:09:59 ok, i'll try that Nov 13 18:10:07 thanks Nov 13 18:11:46 that caused a few more tasks to be rerun, so that looks promising... Nov 13 18:12:00 7557/7655 Nov 13 18:15:45 yes. that worked. Nov 13 18:16:14 thank you, RP Nov 13 18:20:20 Hello, is yocto project similar to distributions like ubuntu ? Nov 13 18:27:41 amosbird, it builds a distribution for you Nov 13 18:27:52 with support for license checking, gpl compliance etc Nov 13 18:55:28 RP are oe-selftest supposed to scale to allow other layers in include their own selftest ? Nov 13 18:55:46 armpit: yes Nov 13 18:57:30 then I don't understand or its broken Nov 13 18:58:02 is the oe-selftest scripted supposed to pick these additions? Nov 13 18:58:17 I don't me the selftest class Nov 13 18:58:21 s/me/mean/ Nov 13 18:59:46 armpit: see meta-yocto-bsp/lib/oeqa/selftest ? Nov 13 19:00:04 * armpit will side with "don't understand" and poke around code a bit more Nov 13 19:00:26 RP that test does not show up in oe-selftest -l Nov 13 19:00:34 armpit: I'm basically saying the test from meta-yocto-bsp works so its not totally broken Nov 13 19:01:46 armpit: https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/96787/raw shows systemd_boot.Systemdboot.test_efi_systemdboot_images_can_be_built Nov 13 19:01:58 armpit: perhaps the listing is bust? Nov 13 19:02:20 armpit: I can believe something is broken but the test does appear to tun Nov 13 19:02:37 I was using it to test if I set things up correctly Nov 13 19:03:42 k, thanks for the validation.. Nov 13 19:08:08 * armpit is a dork.. try including the layer Nov 13 19:15:09 * armpit puts test in meta-yocto-bsp and it is seen... Nov 13 19:16:13 New news from stackoverflow: bitbake not producing a zImage file Nov 13 19:18:46 * armpit cool the test works Nov 13 19:46:20 New news from stackoverflow: Yocto find the recipe that defines a task Nov 13 22:24:09 kergoth: around? Nov 13 22:25:15 kergoth: Just trying to figure out what we were trying to do with http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/main.py#n116 (the warnings code). I'm not convinced its working Nov 13 22:25:55 it was to send python warnings like DeprecationWarning to our loggers instead of directly to stdout Nov 13 22:26:24 been a long time since that was added, though, and i doubt it's currently being tested in our unittests Nov 13 22:26:50 bad example, we explicitly ignore that warning, but others of that nature Nov 13 22:26:58 well, we ignore it in the metadata, not in bitabke istelf :) Nov 13 22:28:04 I'm not sure if that module is still accurate for our eval'd stuff, though? *shrug* you've touched better_* more recently than i Nov 13 22:31:52 is there somewhere in the oe layers that creates a symlink of the log directory under /var to /var/volatile/log? i.e., /var/log -> /var/volatile/log? Nov 13 22:35:43 kergoth: I'm not really sure either :/ I can say the deprecation warnings from bitbake are erratic though Nov 13 22:36:06 kergoth: you fix one, then find others of a different type. Its as if any warning of any kind removes any others Nov 13 22:37:03 you see. if we wrote bitbake in java, it would be so much easier Nov 13 22:37:10 RP: that sort of setup should really go in bitbake_main or something anyway, even if it does work, otherwise the override happens every time main.py is imported, which seems bad Nov 13 22:37:31 * kergoth shrugs Nov 13 22:38:13 should likely write a unit test that does an exec_func on some python code with known deprecated stuff, but we'd hae to account for every python version bitbake supports Nov 13 22:38:21 maybe there's a better warning to test Nov 13 22:39:16 kergoth: we could define a function which we mark as deprecated? Nov 13 22:39:37 kergoth: but yes doing this in main every module load is bad Nov 13 22:50:14 kergoth: I'm wondering if now we're on a recent python we need to filter any of these warnings. At least in 3.6, I'm not seeing many (I have patches for the ones I have seen) Nov 13 22:51:11 bitbake/oe has a minimum required python version, but the user could be running a version newer than that which deprecates stuff we use or the metadata use Nov 13 22:51:21 which will spam the user with warnings they can't do anything about Nov 13 22:51:41 i think that sort of the thing was the origianl reason behind the filtering Nov 13 22:52:22 kergoth: we support 3.4 onwards iirc but it runs cleanly on 3.6 afaict (with some minor tweaks I'll send out) Nov 13 22:52:32 not sure what 3.7 does of course Nov 13 22:52:54 * kergoth nods, probably not a likely case at the moment Nov 13 22:53:18 Hmm, I wonder if there are any tools to check a codebase to determine if anything from versions later than what you support is being used Nov 13 22:53:24 kergoth: contemplating removing that code on the most part and seeing how bad things are with a view to putting back what we need Nov 13 22:53:31 i.e to catch recipes doing things that aren't guaranteed to be available Nov 13 22:53:39 python versions, that is Nov 13 22:53:47 kergoth: that would certainly be handy Nov 13 22:57:53 checking bitbake itself is easy enough, just run bitbake-selftests on multiple python versions with tox or something.. but metadata is less trivial Nov 13 22:58:40 kergoth: we do have all the python code fragments in ast form though Nov 13 23:01:20 right, static analysis could determine the minimum requireed python version. just don't know if such a thing exists arleady or not Nov 13 23:01:33 * kergoth adds to the ever growing one-of-these-days list Nov 13 23:01:53 https://github.com/alikins/pyqver seems to have been precisely that, but only goes up to 3.3. — https://github.com/alikins/pyqver/blob/master/pyqver3.py Nov 13 23:01:56 cool Nov 13 23:04:04 kergoth: right, something like that but up to date :) Nov 13 23:05:18 https://nedbatchelder.com/blog/201803/whats_in_which_python_3436.html Nov 13 23:05:37 nice little summaries Nov 13 23:07:58 kergoth: tracemalloc sounds interesting Nov 13 23:08:22 huh, indeed Nov 13 23:19:51 armpit: I've tracked down a small behaviour difference between 3.4/3.5 and 3.6. will try a fixed build Nov 13 23:20:53 only one worker appears to have 3.6 on it Nov 13 23:21:19 cool Nov 13 23:23:11 * RP tries a different build command and watches it spew more deprecation warnings :/ Nov 13 23:40:09 Evening all. Quick question, my current yocto build allows root ssh access with no password. Although I've found a method to add a root password within local.conf, I'd quite like to be able to add an authorised ssh key, and disable password access (my standard ssh setup for linux) Nov 13 23:45:42 Or would I need to edit the rootfs and modify sshd_config? Nov 14 01:36:20 la_croix_: you can either use a rootfs postprocess hook or better, bbappend the recipe in question to alter its config for your distro Nov 14 01:36:35 for the password option, anyway. the ssh key could be a new recipe or hook **** ENDING LOGGING AT Wed Nov 14 03:00:00 2018