**** BEGIN LOGGING AT Wed Jun 12 03:00:27 2019 Jun 12 07:19:43 LetoThe2nd: YW, I just wanted you to focus on the foggiest part of the recipe ;-) Jun 12 07:19:55 good morning Jun 12 07:20:58 mckoan: not exactly good, but it is a morning Jun 12 07:21:15 mckoan: and any input is appreciated :) Jun 12 07:24:00 i'm looking for a way to get the exact version of a package (git sha). background is, i want to collect this infos in my os-release package. what approach do you suggest? Jun 12 07:47:06 is there an equivalent of checkpatch from the kernel in Yocto? So that I can actually test my patch will not be rejected by the build/test bots? Jun 12 07:48:29 because I get this error: http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283497.html Jun 12 07:48:45 And the message is pretty unhelpful Jun 12 07:49:02 especially for those not used to code in Python Jun 12 09:31:39 qschulz: I think that test is broken. patchtest has been offline for a while and now its back, it seems a little cranky :/ Jun 12 09:32:00 qschulz: there is a way to run the tests locally against a patch, I just wish I could remember what it is Jun 12 10:29:24 I wonder if anybody could tell what could be causing this phenomenon: in my local.conf I have PREFERRED_VERSION_linux-yocto ?= "4.4%", however, 'uname' on the generated Linux distro returns 4.12. The bzImage is 4.4 as well as /lib/modules/4.4.113-yocto-standard. It almost seems that I have 4.12 stuff which is just named 4.4. Any ideas? Jun 12 10:31:09 muppe: weird, could you share more details on machine etc? Jun 12 10:48:02 hi, I have some special need to setup list of systemd units which are found in source directory. I tried to create task which is running after do_fetch with basically setting d.setVar('SYSTEMD_SERVICE_' + d.getVar('PN'), ' '.join(x for x in systemd_units)) Jun 12 10:48:13 but it looks like it doesn't work (variable is not set) Jun 12 10:48:33 is there any way how to do it? Jun 12 11:27:18 has anyone found a free-for-oss CI system that is usable for actual OE builds? i.e. you can maintain a sstate-cache between runs to avoid building the world on every run Jun 12 11:27:32 azure pipeline caching isn't ready yet Jun 12 11:29:44 travis caches to S3 which sounds like its going to be very slow to restore an entire sstate Jun 12 11:29:45 opennandra: hmm, I did a simple test and if I set something using d.setVar() in a python task that value seems gone in next task even if next task runs after. If I have an anonymous python function that does d.setVar() it will be available in other tasks though. Jun 12 11:30:41 anon py runs before all the tasks Jun 12 11:30:44 Maybe someone can explain why changes to d in one task doesn't propagate to other tasks, there's problably an explanation that makes sense Jun 12 11:31:21 erbo: yes this is also my finding Jun 12 11:31:46 rburton: ok but I can change my python function to anonumous but need to be sure it's called only after source is fetched Jun 12 11:32:06 anon py happens *before any tasks are run* Jun 12 11:32:07 opennandra: you can't, since they run at parsing Jun 12 11:32:53 rburton: hmm is there some other way how to achieve what I want to do? Jun 12 11:33:07 basically wait until unpack is done Jun 12 11:33:12 and then update variable Jun 12 11:33:17 or it is no go Jun 12 11:34:43 basically in my python task I look at certain location in ${S} and list files which will be then added to SYSTEMD_SERVICES variable Jun 12 11:34:57 and got issues when fynction is anonymous Jun 12 11:35:16 because sometimes can happen that if parsed before all tasks then S is not available Jun 12 11:37:11 opennandra: Maybe you can add that code in a do_package_prepend since that's where the variable is used. Then it should be within the same task and might work Jun 12 11:39:10 erbo: FILES_${PN} also? Jun 12 11:41:17 erbo: ok it looks like it's working when use anonymous and line which look for file is in try except block Jun 12 11:42:09 opennandra: Hmm, that doesn't seems right Jun 12 11:42:51 erbo: but I can see varibales are update Jun 12 11:42:55 when check with -e Jun 12 11:42:56 Are you sure it's not working just because you had the files in place due to having run bitbake before? Jun 12 11:43:27 So if you'd clean your recipe, does it still work? Jun 12 11:43:54 erbo: sec Jun 12 11:44:37 erbo: you're right :( Jun 12 11:44:47 when cleansstate it's again not working Jun 12 11:45:03 But I think it should work with do_package_prepend Jun 12 11:45:09 just give it a shot :) Jun 12 11:46:18 ok sec Jun 12 11:49:51 erbo: nope also not working Jun 12 11:54:02 opennandra: are you checking with bitbake -e, or trying the whole thing? Jun 12 11:54:18 with -e Jun 12 11:54:35 But -e shows environment after parsing only I think Jun 12 11:54:40 See https://pastebin.com/rPbsSKVz Jun 12 11:55:44 bitbake -e example doesn't show FOO being set there either, but it works within the task Jun 12 11:56:07 ok but I tried and get package QA issue about installed vs shipped Jun 12 11:56:11 so variable is not updated Jun 12 11:57:27 I mean FILES_${PN} variable Jun 12 12:01:47 erbo: I am building for intel-corei7-64. Most of my layers are from rocko which I guess comes with 4.12. However, I have cleaned everything and tried to build 4.4. I wonder if something is still forcing 4.12 somehow. Jun 12 12:04:26 muppe: what kind of image do you build? I'm thinking if it's possible that you updated rootfs but leaving old kernel in place? Jun 12 12:06:20 opennandra: Ok, then I don't really have any nice ideas. I would probably debug it by inserting some prints into systemd.bbclass to see if your changes are used, and then go from there. Jun 12 12:06:39 erbo: ok thanks anyway for help Jun 12 12:19:28 erbo: with anonymous function seems to work (do cleansstate then build) but get do_package, the basehash value changed from 3 Jun 12 12:19:36 I think it's bacause I updated variable Jun 12 12:19:52 is there anything I can prevent to have this error? Jun 12 12:28:45 erbo: nevermind fixed it Jun 12 12:28:47 somehow :) Jun 12 12:29:52 I think it's strange if you got it working with the anonymous function, it shouldn't work if the code there needs some files in place Jun 12 12:30:19 At least it should be unpredicable result Jun 12 12:30:49 But if you got it working I might be wrong, I'm not a guru like some others lurking here Jun 12 12:31:44 erbo: np it's working so lesson learned : you can set variables only in anonymous functions ;) Jun 12 12:40:47 opennandra: each task runs in its own context: variables set in one don't reach the next. if your anonpy is looking at what was unpacked then it won't work with a clean build tree. Jun 12 12:41:36 rburton: ok thanks I'll try to play more with it Jun 12 12:53:38 erbo: I am building a UEFI live USB stick image. Once I boot it, /boot/ folder has bzImage-4.4.113-yocto-standard but uname -r gives me 4.12.28-yocto-standard. Jun 12 12:56:30 muppe: so is that a .wic file you dd to the USB-stick? Jun 12 13:01:08 I still think the kernel is taken from somewhere else than /boot/. You can verify by grepping for the version string uname -r gives you. grep "4.12.28-yocto-standard" /boot/bzImage-4.4.113-yocto-standard Jun 12 13:01:48 If you don't find it, that's not the kernel you booted Jun 12 13:02:20 erbo: I am generating .uefiimg (the image has meta-mender in it so that's probably why the output image is like that) Jun 12 13:02:22 Maybe "dmesg | head" on the booted system can give you a hint Jun 12 13:04:56 [ 0.000000] Linux version 4.12.28-yocto-standard (oe-user@oe-host) (gcc version 7.3.0 (GCC) ) #1 SMP PREEMPT Thu May 9 11:55:51 UTC 2019 Jun 12 13:04:57 [ 0.000000] Command line: BOOT_IMAGE=(hd1,gpt2)/boot/bzImage root=/dev/sdb2 console=tty0,115200n8 console=ttyS0,115200n8 console=ttyO0,115200n8 console=ttyAMA0,115200n8 rootwait Jun 12 13:07:38 and grep gave no results so obviously I am booting something 4.12 instead of 4.4. Jun 12 13:08:00 So I guess your device has another partition which contains the /boot/bzImage the command line specifies Jun 12 13:09:34 The device has an SSD where I have dd'ed 4.12 based image a while ago. Is it possible that it is booting the kernel from /dev/sda instead of /dev/sdb? Jun 12 13:10:30 The booting process is definitely starting from the USB stick (after changing the BIOS settings to boot from UEFI mass storage). Jun 12 13:11:25 Try mounting both /dev/sda2 and /dev/sdb2 when the system has booted and see what kernels they contain? Jun 12 13:11:54 hmm... actually that hd1 at BOOT_IMAGE makes me wonder.... Jun 12 13:12:22 autobuilder worker showing a process running for 5124107hours which is 805 years. Suspect. Jun 12 13:12:54 RP: so it's true when they say yocto build can take some time then :D Jun 12 13:13:19 erbo: that and we appear to have time travel Jun 12 13:13:27 finally! Jun 12 13:15:38 RP: can you please travel to after my current bug hunt, and when you return tell me what the problem was? Jun 12 13:17:34 erbo: Thanks for the tips. Apparently there was a wrong definition in grub.cfg. mender_grub_storage_device was set to hd1 whereas it should have been hd0. After manually changing that, the system booted kernel 4.4. Jun 12 13:19:20 Glad you found it Jun 12 13:19:28 muppe: for mender question you can ask on hub.mender.io Jun 12 13:19:59 muppe: there alre also topics about how to port mender to x86 board (intel nuc e.g.) so you can get also some info there (I'm author of some of them :)) Jun 12 13:21:10 muppe: https://hub.mender.io/t/intel-nuc/308 Jun 12 14:02:36 New news from stackoverflow: Yocto Bitbake Recipes for Nvidia Jetson Nano for Python whl files not on PyPi Jun 12 14:32:09 RP: does oe-core ship recipe for rc kernel? Jun 12 14:45:04 psrcode: we have a -dev kernel which you could probably configure to do that Jun 12 14:45:19 but by default? Jun 12 14:45:30 does -dev kernel target a rc kernel? Jun 12 14:46:43 psrcode: -dev is currently set to 5.2-rc+ so it does but its not default Jun 12 14:46:52 k Jun 12 14:47:15 yeah thats a problem for lttng-modules Jun 12 14:47:39 psrcode: I think the git lttng-modules recipe is the best way forward for this, it will bring us as close as we can get Jun 12 14:47:50 yeah Jun 12 15:52:28 * zeddii notes that the pacific timezone blows for trying to keep up with mailing list threads. Jun 12 15:52:33 always last to comment :D Jun 12 17:14:26 Hi, when a systemd service (node js app) is configured as `StandardOutput=journal+console` and then I output something to the console like this `process.stdout.write('HELLO\n');`, am I supposed to see the message passed in my console when I start the service with `systemctl start myservice` ? I guest that as the service is started with a different shell then the output cannot be display on MY console. Jun 12 17:55:40 I try to run tests, but get this: images/qemux86/core-image-sato-qemux86.testdata.json Not Found. Have you built the image with INHERIT+="testimage" in the conf/local.conf? Jun 12 17:55:50 I have INHERIT+="testimage" in my local.conf Jun 12 17:56:04 MACHINE = "qemux86" Jun 12 17:56:16 I build it with bitbake core-image-sato -c testimage Jun 12 18:28:09 I added a layer 'meta-mytest' and a basic "helloworld" recipe. `bitbake helloworld' successfully compiles the simple program, but when I try to bitbake my full system image, I get the message "ERROR: Nothing RPROVIDES 'mytest'" Jun 12 18:28:49 The next line says: NOTE: Runtime target 'mytest' is unbuildable, removing... Jun 12 18:29:48 How is "mytest" becoming a target instead of just a layer? The only place that the string "mytest" appears in a file is inside poky/build/conf/bblayers.conf Jun 12 18:38:55 ecdhe, did you add that to the BBLAYERCOLLECTION? (or whatever it's called) Jun 12 18:41:27 BBFILE_COLLECTIONS += "mytest" Jun 12 18:41:48 litb: yes Jun 12 18:43:33 it was my understanding (per tutorials) that BBFILE_COLLECTIONS names a variable suffix that bitbake can then append to a set of known basenames for parameter discovery. Jun 12 18:43:57 e.g, BBFILE_PATTERN_mytest, BBFILE_PRIORITY_mytest etc Jun 12 18:51:48 that's my understanding aswell Jun 12 18:52:15 and in BBLAYERDIRS or whatever it's called, you need to add all the directories of all your layers I think Jun 12 18:52:26 in conf/bblayers.conf Jun 12 18:56:54 litb: that's where I've got my layer listed. to make sure the syntax was right, I used the 'add-layer' command of I forget what tool. Jun 12 18:57:32 If I removed my custom layer from bblayers.conf, the RDEPENDS issue goes away, but of course, my packages can't be included Jun 12 19:00:15 I think I had that issue aswell. I renamed my layer name , and then it worked Jun 12 19:00:17 ecdhe, ^ Jun 12 19:00:32 litb: is there a cache I can clear instead? Jun 12 19:05:37 litb, this is very interesting; I renamed my layer to "fourtest" but I'm still getting the error about 'mytest' being required but not provided. the name 'mytest' seems to be cached somewhere! Jun 12 19:06:47 unlikely. try grep Jun 12 19:07:14 kergoth, running `grep -r mytest' Jun 12 19:10:59 kergoth: you were right. the file 'meta-fourtest/recipes-images/core-image.bbappend' was trying to append the layer name (not the package name) with an IMAGE_INSTALL_append directive. Jun 12 19:11:34 This was from my inadequate mental model of layers/recipes/packages earlier today Jun 12 19:11:41 The thing is finally building! **** ENDING LOGGING AT Thu Jun 13 02:59:57 2019