**** BEGIN LOGGING AT Tue Sep 10 02:59:58 2019 Sep 10 07:08:12 Has anyone here used swupdate? I'm really struggling on how to configure it for a single-copy approach (create initrd image, create the complete .sdcard-image with both the swupdate "rescue" part and the regular system). Sep 10 07:10:38 iceaway: i guess the core thing to get your head around is that this requires two mostly distinct build, with the one being the payload of the other Sep 10 07:18:07 LetoThe2nd: I have never worked with initrd/initramfs before so it's a bit difficult to understand how it all hangs together. It seems like u-boot + kernel + initrd (for swupdate), and u-boot + kernel + regular rootfs are two separate builds, yet they need to become "one" in the image that I flash to the sdcard/emmc. Sep 10 07:19:20 nrossi: did you get anywhere further with the rpaths or should I take a look? Sep 10 07:19:48 RP: working on it now, just trying to get the thing to break the hardlinks Sep 10 07:20:07 RP: out of query should chrpath handle breaking hardlinks? Sep 10 07:20:18 nrossi: ok, cool. Just wanted to check as no point in both of us doing it Sep 10 07:20:34 nrossi: I suspect it doesn't Sep 10 07:21:00 iceaway: yeah, the apprioach is right. the key point is that you must not think of swupdate as some magic to glue it together automatically, but you need basically some recipe that takes the regular build artifacts and bundles them up in some way the swupdate build can use. Sep 10 07:21:14 RP: no it doesn't, but it sort of makes sense that it doesn't. But it could optionally by kwarg since i am already calling process_dir manually Sep 10 07:22:06 nrossi: In the general case its probably working on a copy or it doesn't matter that it changes everything Sep 10 07:22:21 nrossi: having the option is probably ok though Sep 10 07:23:04 LetoThe2nd: yeah I think I grasp the part about the .swu compound image and how that is used. Now I need to figure out 1) how to build an initramfs/initrd image with swupdate, and combine that with my regular image to create a single image for flashing. Sep 10 07:23:21 iceaway: bingo. Sep 10 07:26:54 I'm basing my initramfs image on the core-image-minimal-initramfs recipe, but when I build it there is no /boot directory in the root filesystem, alas when u-boot tries to boot it cannot find /boot/Image.gz. Any clue as to where the kernel image+dtb ends up? Sep 10 09:02:48 New news from stackoverflow: Raspberrypi cm3 not booting (missing kernel.img?) Sep 10 09:32:52 New news from stackoverflow: Rerun bitbake recipes when checkout different layer revision Sep 10 09:51:45 hey, could anyone point me to the good reading about device tree files? It's not really yocto-specific, but i suppose many of you know some whatnots Sep 10 09:52:48 I need some easy things for start, the thing i'm trying to do is enable SPI on RPi CM, but would love to know a little bit of insides instead pasting something from stack Sep 10 09:53:51 kpo, maybe https://www.youtube.com/watch?v=m_NyYEBxfn8 is of interest Sep 10 09:54:40 kroon: thanks :) i prefer readable material, but will surely check Sep 10 10:17:29 Really confused now over the whole initramfs thing. I reckon now after more reading that I should set the INITRAMFS_IMAGE to the image that I want in my initramfs (in my kernel recipe). But the image I set in INITRAMFS_IMAGE is also the image I am trying to bitbake(?). It ends up with what appears to be a circular dependency between the image and the kernel. Sep 10 10:21:22 kpo, the linux kernel also ships with some general devicetree documentation Sep 10 10:28:25 kanavin_: if you do have any time we have two issues which I'm not aware of anyone looking at right now and they block M3. One is strace ptest timing out (arm and x86) Sep 10 10:28:46 kanavin_: other is qemumips systemd with a runtime boot failure (showing as red on all AB builds) Sep 10 10:29:05 kanavin_: on the plus side both look readily reproducible. Not looked into them at all yet Sep 10 10:33:10 hello! Sep 10 10:34:08 I only need hciattach from bluez5 package... If I do PACKAGES += "hciattach" and FILES_hciattach = "/....", ... bitbake says nothing provides hciattach, but bluez5 RPROVIDES hciattach ... how to unRprovide it ? Sep 10 10:45:47 akrpic77: where did you say to yocto you needed hciattach? how? Sep 10 10:46:16 qschulz: to try out, first just bitbake hciattach Sep 10 10:46:32 akrpic77: you can't, you (bit)bake recipes, not packages Sep 10 10:46:35 you bitbake a recipe Sep 10 10:46:39 which then builds packages Sep 10 10:46:45 and you can install some of those Sep 10 10:46:55 you get the packages in tmp/deploy/{type of packages} Sep 10 10:47:02 or use oe-pkgdata-util Sep 10 10:47:11 rburton: oh, new tool to discover! Sep 10 10:47:37 qschulz: thank you Sep 10 10:47:56 akrpic77: and rburton :) Sep 10 10:48:05 and rburton of course. Sep 10 10:48:06 :) Sep 10 10:48:32 but those additional packages added inside bluez*.bb have dep on main package, yes? Sep 10 10:48:39 I also have to remove that dependency Sep 10 10:48:52 they only depend on the main package if they depend on the main package Sep 10 10:49:00 hmm. ok. Sep 10 10:49:24 unless you've *massive* space restrictions this seems fairly pointless though :) Sep 10 10:49:42 what seems to be pointless? Sep 10 10:49:49 *just* installing hciattach Sep 10 10:50:16 ok. the other option I have is to systemd disable bluez5 (bluetooth.service) Sep 10 10:50:33 ... and install it anyway Sep 10 10:50:42 also, remember that by doing that (moving a binary out of one package to another one) might break other recipes. Because they'd RDEPENDS on what used to provide the binary but it's not there anymore. It's not without consequences :) Sep 10 10:51:27 but! adding bluez5 -> dep on hciattach, those that rdepend on bluez will get hciattach Sep 10 10:52:04 akrpic77: true! one more thing to not forget but you're right Sep 10 10:53:48 akrpic77: you can have a bbappend for bluez5 with just INITSCRIPT_PARAMS = "remove" Sep 10 10:53:55 https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-INITSCRIPT_PARAMS Sep 10 10:54:06 if Sep 10 10:54:16 that don't work for systemd though :) Sep 10 10:54:57 https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SYSTEMD_AUTO_ENABLE this one then? Sep 10 10:55:03 right Sep 10 10:55:26 great, thank you qschulz Sep 10 10:56:48 RP: I fired a build with strace Sep 10 11:13:05 anyone has experience with mgmt api of linux's bluetooth stack ? Sep 10 11:15:34 maybe ask in #bluez Sep 10 11:16:13 c Sep 10 11:21:02 rburton: asking already, thank you Sep 10 11:23:32 I don't get in which order bitbake parses assignments/statements.. not even after reading the bitbake manual section 3.1-3.3 for the 4th time Sep 10 11:23:56 _append and _remove come after = and + Sep 10 11:24:55 apart from that, it's parse order. bitbake.conf (and everything it includes) then recipe. Sep 10 11:25:49 rburton, manual says for _append/_prepend: "... their effects are deferred until after parsing completes ...". Is that "parsing" of the whole bitbake recipe ? Sep 10 11:26:40 sort of. = and + happen during the parse of the recipe line by line, _append happens afterwards Sep 10 11:27:10 FOO=1 ; FOO_append="2"; FOO+= "3" would result in FOO=132 Sep 10 11:28:15 rburton, right, sofar I'm with you Sep 10 11:30:00 rburton, For a statement like "${@bb.utils.contains('PACKAGECONFIG', 'python', 'distutils3-base', '', d)}" Sep 10 11:30:30 rburton, I guess I can't use an _append to fill in the "python" PACKAGECONFIG then ? Sep 10 11:30:42 erhm Sep 10 11:30:52 sorry Sep 10 11:31:17 rburton, inherit ${@bb.utils.contains('PACKAGECONFIG', 'python', 'distutils3-base', '', d)} Sep 10 11:32:13 rburton, since I assume bitbake expands the inline python right there during parsing, before the _append's are applied ? Sep 10 11:32:23 khem: it's not -- my browser wasn't actually switching branches when I changed the selection in cgit. Sep 10 11:33:15 kroon i *think* thats right. we do actually have a recipe doing that, which isn't right (probably). paging RP :) Sep 10 11:34:27 rburton, there are lots of recipes doing that I think... at least I added one myself in OE-core pretty recently :-/ Sep 10 11:38:11 and by lots I mean a few that uses "inherit ${.....}" Sep 10 11:38:19 three in core doing it on PACKAGECONFIG Sep 10 11:49:23 rburton, this is what I get from reading the manual: 1. recipe is parsed line by line 2. _append/_prepend/_remove are applied 3. keys are expanded 4. overrides are applied Sep 10 11:51:29 but am not at all sure about the order Sep 10 12:13:02 kroon: appends are applied at variable expansion time Sep 10 12:13:13 kroon: so it depends if your append is set before or after that inherit Sep 10 12:14:17 RP, ok, and the appends are applied in the order they were declared, in case there were multiple of them ? Sep 10 12:15:25 kroon: I'd have thought so Sep 10 12:18:56 RP, so for statements like inherit/include/require, any variable arguments are expanded immediately as the line is parsed ? Sep 10 12:19:12 kroon: yes, there is no other way Sep 10 12:19:24 they're implied immediate expansion Sep 10 12:19:35 INHERIT is the only one which doesn't (for conf files) Sep 10 12:21:14 RP, rburton, ok that clears up a lot for me, thanks Sep 10 12:21:39 kroon: we should probably clarify the manual Sep 10 12:22:08 RP, yeah, i'll see if I can write something up Sep 10 12:22:13 kroon: thanks Sep 10 12:33:24 New news from stackoverflow: Yocto: No recipes available (tegra) || Overriding do_compile() functionality in bbappend Sep 10 12:42:07 RP: just sent a series with the WIP patches sorted and the rpath fix Sep 10 12:44:37 nrossi: looks good, thanks! Sep 10 12:44:48 * RP will fire a new testbuild Sep 10 12:48:12 rburton: I'm leaving the other patches to you in mut for now Sep 10 12:54:32 RP: Kai can work on: Bug 13504 - [master-next] qemumips-lsb sytemd failure -- Sep 10 12:54:33 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13504 normal, Undecided, ---, kai.kang, NEW , [master-next] qemumips-lsb sytemd failure Sep 10 12:59:55 vmeson: thanks Sep 10 12:59:58 kanavin_: also thanks! Sep 10 13:12:28 RP: what is the specific image that strace fails with? Sep 10 13:13:45 Hello Sep 10 13:16:42 kanavin_: would be the -ptest one Sep 10 13:18:47 RP: yeah, started core-image-sato-ptest-fast Sep 10 13:19:06 core-image-minimal ran out of space during the test, as is actually well known Sep 10 13:19:20 (started building, will take a moment) Sep 10 13:19:45 RP, overrides are also applied at variable expansion time ? Sep 10 13:20:07 kanavin_: https://autobuilder.yocto.io/pub/non-release/20190907-4/testresults/qemuarm64-ptest/strace.log vs https://autobuilder.yocto.io/pub/non-release/20190907-4/testresults/qemuarm64-ptest/strace.log and https://autobuilder.yocto.io/pub/non-release/20190907-4/testresults/testresult-report.txt Sep 10 13:20:26 kanavin_: not sure what is going on there Sep 10 13:20:51 kroon: yes, bitbake used to expand at a particular point in time but its now dynamic Sep 10 13:20:51 I have a problem with yocto warrior-21.0.1 the bug is this one : https://bugzilla.yoctoproject.org/show_bug.cgi?id=13442 and the solution that works for me is there : https://git.openembedded.org/openembedded-core-contrib/commit/?h=stable/warrior-nmut&id=8f13dbd9e066670d7407cd2a9293abce5ec3ac05 Sep 10 13:20:52 Bug 13442: normal, Medium+, 2.7.2, akuster, IN PROGRESS DESIGN COMPLETE , linux-yocto-rt 4.19 fails to build Sep 10 13:21:12 RP, ok Sep 10 13:21:14 my question is how do I patch the file in a good "yocto-way" ? Sep 10 13:22:07 I already patched recipes but I don't know how to patch this particular file meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb Sep 10 13:22:26 maybe it's more of a git problem ? Sep 10 13:39:54 hmm.. Where do I send bitbake manual patches ? Sep 10 13:40:05 bitbake-devel ? Sep 10 13:40:22 kroon: please Sep 10 13:41:42 RP, ok, sending. I have 2 patches, not 100% confident they are correct so please review.. Sep 10 13:46:32 kroon: they look correct. I hadn't realised the manual had those old references! Sep 10 13:48:53 RP, ok, good Sep 10 13:49:48 * kroon heads home Sep 10 14:13:06 antoine74: do this modifications in multiple bbappends. I don't know if you can actually have two different ?=, so maybe you'll need to have = instead of ?= in your bbappends Sep 10 14:13:38 do these modifications in multiple bbappends? (suggestion) Sep 10 14:14:08 actually only one is important for me, the linux-yocto-rt_4.19.bb Sep 10 14:14:47 I tried to create a patch and then put it in a bbappend but I'm afraid my paths are wrong somewhere Sep 10 14:15:04 antoine74: yourlayer/recipes-kernel/linux/linux-yocto-rt_4.19.bbappend Sep 10 14:15:35 ok I'm going to try that right now, thank you Sep 10 14:15:43 in there, SRCREV_machine = "ca2e3322f4c5678eaef6434c808d0842c805d74d" and SRCREV_meta = "960be4218436fbbb3500e019f7abf02fa94e6aac" and LINUX_VERSION = "4.19.61" Sep 10 14:15:46 what was your path? Sep 10 14:16:20 JPEW: would you be able to redo the stats patch on top of master-next? Sep 10 14:16:33 I think my paths problems where in the .patch file I created Sep 10 14:16:40 JPEW: I've removed the threading I added and tried to simplify it to the thing which profiling shows was fastest Sep 10 14:16:56 JPEW: also got a small tweak which reduces the number of equiv queries in there Sep 10 14:17:00 antoine74: what do you mean a patch? Sep 10 14:17:29 I thought the right way to do it was to create a .patch file that was applied on the original one Sep 10 14:17:43 but just changing the variables is perfect for me Sep 10 14:18:13 RP: Yes, I'll look it over Sep 10 14:19:08 antoine74: patches are for source code, not for recipes. When you want to modify a recipe, you use bbappend :) Sep 10 14:19:45 ok, I definitly misunderstood that, thank you for the clarification !! Sep 10 14:20:33 RP: does core-image-weston boot in qemu ? Sep 10 14:23:03 khem: don't know. rburton? Sep 10 14:24:52 RP: I am trying to unify weston-init recipe bringing some changes from other BSP layers and was trying on qemuarm64 Sep 10 14:25:49 khem: I am not sure :/ Sep 10 14:26:18 it works on pi3 Sep 10 14:26:26 RP: I am not done testing yet, but it seems as though strace is hitting ptest-runner's inactivity limit Sep 10 14:26:39 which got me thinking that we need to be able to configure it per ptest Sep 10 14:27:02 kanavin_: That sounds like a very slow test then :/ Sep 10 14:27:31 kanavin_: we've talked about per test config, it would be useful. Hard to figure out in practise but we could do with it Sep 10 14:27:31 RP: it has a testcase that outputs nothing for more than 5 minutes, but eventually succeeds Sep 10 14:27:57 kanavin_: could we tweak it to produce output periodically? is the test useful? Sep 10 14:28:12 RP: actually there are three tests that behave like this Sep 10 14:28:47 kanavin_: I'm not surprised, that would explain the output in the logs Sep 10 14:29:18 RP: sched, regex and clock, and another one that is currently crunching Sep 10 14:29:32 I am running the run-ptest directly now, next I will try under ptest-runner Sep 10 14:30:14 RP: it's a bit of unfortunate situation that ptest-runner is written in C Sep 10 14:30:27 RP: if it was python, I could rapidly add support for a per-ptest config file Sep 10 14:30:52 basically we could add some file that goes next to run-ptest that contains an integer that overrides the default timeout Sep 10 14:30:57 (which is 300 seconds) Sep 10 14:34:13 the slow testcases all print this to console Sep 10 14:34:14 [ 1273.665567] futex_atomic_op_inuser: 2 callbacks suppressed Sep 10 14:34:14 [ 1273.665572] futex_wake_op: futex tries to shift op by -849; fix this program Sep 10 14:34:14 [ 1273.668122] futex_wake_op: futex tries to shift op by -849; fix this program Sep 10 14:34:14 [ 1273.669388] futex_wake_op: futex tries to shift op by -518; fix this program Sep 10 14:34:22 I wonder if I could try a newer strace first Sep 10 14:36:52 qschulz yout solution works perfectly, thanks ;) Sep 10 14:39:46 pleasure :) Sep 10 14:42:59 * LetoThe2nd is getting ready to totally fail in doing kernel stuff in public! Sep 10 14:44:08 Hi all, Someone here has already build a meta-xilinx Yocto based image inside Docker container ? because I have a correct trabbl extraction but Xilinx tools are missing :S No trouble on the host machine Sep 10 14:44:21 LetoThe2nd: gl :) Sep 10 14:45:04 you're all invited to watch me break stuff on https://www.twitch.tv/yocto_project Sep 10 14:45:13 starting in 15 minutes. Sep 10 14:46:32 now I'll be really disapointed if you don't break it Sep 10 14:46:45 any tips on getting gfortran built for cross compiling? Sep 10 14:47:06 fullstop: see lapack recipe which documents what to put in local.conf Sep 10 14:47:12 thanks Sep 10 14:47:17 fullstop: there has been work on recent master so it *might* work. older releases have broken fortran support. Sep 10 14:47:30 khem: i think i've seen it in qemux86-64 Sep 10 14:47:32 "works" for me on thud :) Sep 10 14:48:13 fullstop: turn it on, it works. Sep 10 14:48:34 i even added autobuilder tests to ensure it keeps working Sep 10 14:49:55 I'm using the linaro-7.2 layer which may complicate things. Sep 10 14:54:33 RP: the same tests on my host execute reasonably fast. Something is slowing them down inside qemu, I'll try to narrow it down. Sep 10 14:54:41 5.2 kernel is the prime suspect I guess? Sep 10 14:59:33 looks like it is building gfortran now. Thanks all. Sep 10 15:13:37 kanavin_: or maybe an upgrade Sep 10 15:30:54 kanavin_: figuring out what is so slow would be good. KVM qemu system mode shouldn't be that slow Sep 10 15:31:53 RP: yes, I'll try to narrow it down Sep 10 15:58:46 mckoan: i promised i will mess up, i did mess up! Sep 10 15:59:41 LetoThe2nd: It wasn't so bad ... head-up ;-) Sep 10 16:00:42 * LetoThe2nd is off for the evening. Sep 10 16:14:58 RP: regarding strace, reverting to kernel 4.19 makes the slowness go away :-/ Sep 10 16:15:19 RP: I can then try and see if latest upstream of strace has a fix, but otherwise it becomes a bit tricky to narrow down Sep 10 16:20:36 LetoThe2nd: that's not a problem at all. More problems = more learn Sep 10 16:21:12 LetoThe2nd: the useful thing in this case should be to recap and explain what happened Sep 10 16:21:58 LetoThe2nd: in the real life nothing is straightforward. You have to face to the problems and learn to solve them Sep 10 16:25:47 That's what I tell my kids. One day I was learning to walk and fell over and I just never walked again because I failed on my first attempt. Sep 10 16:26:14 They realize how absurd this is, of course, and try again. Sep 10 16:30:53 kanavin_: you could try the 5.0 kernel? Sep 10 16:31:00 (it was remved but easy to get back) Sep 10 16:33:01 RP: trying now... Sep 10 16:44:27 RP: 5.0 also works fine. Seems like a regression in 5.2, but it would be good to still try the latest commit of strace. I'll try to get to it tomorrow. Sep 10 16:55:36 kanavin_: thanks! Sounds like progress at least Sep 10 17:14:59 RP: I went ahead and tried the latest strace commit, and it did not help Sep 10 20:40:25 kanavin_: hmm, so something in 5-0-5.2 :/ Sep 11 02:35:38 New news from stackoverflow: how to configure systemd services in yocto linux to boot faster **** ENDING LOGGING AT Wed Sep 11 03:00:21 2019