**** BEGIN LOGGING AT Tue Mar 05 02:59:57 2019 Mar 05 05:23:32 New news from stackoverflow: How to fix the "No symbol __gcov_flush in current context" error while flushing the coverage from the image generated through bitbake Mar 05 09:24:19 New news from stackoverflow: How to generate code coverage for yocto modules Mar 05 11:11:33 RP, rburton I'll be on holiday until 25th of March Mar 05 11:11:56 kanavin: cool, enjoy! Mar 05 11:12:27 LetoThe2nd, thanks :) Mar 05 11:14:38 kanavin: have a good one Mar 05 11:55:13 RP: should src_patches() in patch.bbclass return patches that have apply=0 set? Mar 05 12:00:23 oh it doesn't via mysterious magic Mar 05 12:00:34 good stuff Mar 05 12:10:52 Hi, i have used fsl-image-qt5 when developing my application. Thx to this forum i have everything as i want ( almost). Now i wonder what best practice is to create my "final" image. I have looked at creating my own image with qt5 support but it does not look trivial. The other idea i have was to create an bbappend to the fsl-image-qt5 to remove examples etc. What is the best way to this? Mar 05 12:12:44 best is maybe not the word I'm looking for, rather common practice Mar 05 12:17:10 kanavin: thanks for the headsup, have fun! Mar 05 12:24:56 New news from stackoverflow: yocto fails to build mono-xsp Mar 05 12:25:49 Willie2: ideally, your image just contains IMAGE_INSTALL += "your_application" Mar 05 12:26:20 Willie2: and the recipe of your application would depend on qt and all the other things it needs. Mar 05 12:29:15 oh my god, i have been re-compling this 0,5GB image a few times each day and installing it Mar 05 12:30:05 Willie2: hm? Mar 05 12:30:43 nwm, just a lot of unnecessery installing for me :) Mar 05 12:31:09 Willie2: i mean, there are corner cases, sure. but generally the mind set is: "the image recipe should not know of any internal (dependencies) of the applications it ships" Mar 05 12:33:41 Okay nice. For some reason i thought QT needed complex instructions to get installed Mar 05 12:34:06 Since i looked at the meta-fsl-release image recipes Mar 05 12:34:34 Willie2: it might need tuning in the MACHINE or DISTRO configs. especially when we are talking about accelerated graphics drivers Mar 05 12:35:58 LetoThe2nd: hmm ok. I will still be using the standard imx6sabresd. I'm only using rootfs from Yocto Mar 05 12:36:18 Willie2: that sentence does not really make sense Mar 05 12:36:53 I'm not a good multi-tasker Mar 05 12:38:39 LetoThe2nd: Sorry, what I'ment was i will be using the same settings in DISTRO and MACHINE Mar 05 12:38:42 Willie2: imx6sabresd is the machine. if you stick to the board, this is the one thats most likely to not change Mar 05 12:39:35 Willie2: whereas there is really nothing wrong with taking the DISTRO that came with it and beating it into shape for what you really need. often this can slim down the build process substantially Mar 05 12:41:37 Willie2: and if your application build breaks if the image recipe leaves out things, this strongly indicates that your dependencies are incorrect Mar 05 12:44:54 LetoThe2nd: Thanks! This is really helpful. I will start by creating a "core-image" with my application and see how it builds Mar 05 12:45:51 Willie2: exactly. have fun! Mar 05 12:55:02 New news from stackoverflow: Yocto /boot partition not using opkg/ipk packages Mar 05 13:49:37 Are the python variables documented anywhere? I want to change background picture and I think bb.utils.contains('DISTRO_FEATURES' can have something to do with it Mar 05 13:49:57 Willie2: define background picture Mar 05 13:49:59 The standard is so ugly with the green edges Mar 05 13:50:20 the sato theme has nothing to do with distro features, if that's what you mean Mar 05 13:50:33 but sato hasn't been green for a while, so maybe not Mar 05 13:50:43 rburton: The desktop picture i guess? that is in the background Mar 05 13:50:56 nothing to do with distro features Mar 05 13:51:40 DISTRO_FEATURES is stuff like support for bluetooth, wifi, extended attributes, opengl, x11 Mar 05 13:51:46 Okay, it was added when i put ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland', 'weston-xwayland xterm', '', d)} in my recipe thats why i guessed that Mar 05 13:51:47 not what picture is used for the wallpaper Mar 05 13:52:11 "if the distro contains x11 and wayland, install weston-xwayland and xterm' Mar 05 13:52:38 nice Mar 05 13:52:54 thx! Any idea where wallpaper settings are located? Mar 05 13:53:05 no, because you haven't said what is drawing the background Mar 05 13:53:54 given that trigger to get it shown, probably somewhere in the weston-xwayland region Mar 05 13:54:07 It kinda looks like this (without the example applications ) Mar 05 13:54:11 http://wiki.wandboard.org/Integrate_Qt5_into_yocto_sato_image_on_Wandboard Mar 05 13:54:12 weston's wallpaper is grey Mar 05 13:54:30 But it has a ugly green edge on the top Mar 05 13:54:38 thats very old sato Mar 05 13:54:44 change the matchbox theme Mar 05 13:55:08 i also take offense at ugly, it was cool when it was drawn Mar 05 13:55:24 rburton: hrhrhr Mar 05 13:55:28 i dont even think i was born Mar 05 13:55:33 when taht was drawn Mar 05 13:55:34 https://blogs.gnome.org/thos/2007/08/01/sato-has-landed/ Mar 05 13:56:08 https://www.yoctoproject.org/docs/1.0/poky-ref-manual/screenshots/ss-sato.png awwww Mar 05 13:56:19 exactly Mar 05 13:56:20 that one Mar 05 13:56:24 ah the days when that was cutting edge Mar 05 13:56:49 rburton: its carnival! shouldn't you be drunk like the rest of us old hags? Mar 05 13:58:32 Willie2: the green was removed quite a while ago. consider upgrading your OE. Mar 05 13:59:17 2.2 moved to greys instead of greens Mar 05 13:59:41 so you're using 2.1 or earlier Mar 05 14:00:15 Hm, not sure if i can or should. I'm using a customized board from our supplier and they gave me customised bsp to work with Mar 05 14:00:24 tell them they're selling you insecure software Mar 05 14:00:29 and ask what they're doing about it Mar 05 14:01:02 2.1 was released in 2016 Mar 05 14:01:36 latest point release was 2.1.3 in july 2017 Mar 05 14:01:50 (i'm assuming you're using 2.1 and not anything even older) Mar 05 14:04:28 I only have a few months linux experience and yocto even less so dont assume anything :d Mar 05 14:09:36 rburton: And the only way to get a newer sato is to use something newer? like sumo or rocko Mar 05 14:10:35 you could backport all the bits but thats hard Mar 05 14:10:46 easier to just change the theme Mar 05 14:16:10 Okay, I'll start with trying to add a custom wallpaper :) Mar 05 14:16:12 thx again! Mar 05 14:42:14 I have a (custom) package that is failing to compile and it's not very clear why. Mar 05 14:42:14 Is there a way I can "step into" the build environment bitbake creates and watch the actual compilation? Mar 05 14:42:34 Something like emerge's ebuild tool? Mar 05 14:43:11 Quazil: basically, bitbake -c devshell IIRC Mar 05 15:57:00 YPTM: armin is on Mar 05 15:59:29 #YPTM: Joshua Watt here Mar 05 16:01:37 YPTM: Join with Zoom at: https://zoom.us/j/990892712 Mar 05 16:01:37 YPTM: Richard joined Mar 05 16:02:10 YPTM: vmeson/Randy MacLeod est la Mar 05 16:02:30 * derRichard needs to refine his irc nickname highlight ;=) Mar 05 16:02:31 YPTM: Zach Booth and Dustin Bain are also here Mar 05 16:04:20 YPTM: Tim joined Mar 05 16:15:46 RP: http://errors.yoctoproject.org/Errors/Build/78095/ Mar 05 16:16:38 2.7 Planning document: https://docs.google.com/document/d/15jB6nUJU2wrtnu6w07L9RZpNlj6AoxSTPEX5aELts1g/edit?usp=sharing Mar 05 16:19:48 Is there a tool to convert the reports generated by cve-check to JUnit format? Mar 05 16:19:56 armpit: nothing provides curl-dev = 7.61.0-r0.0 needed by curl-staticdev-7.61.0-r0.0.armv5e Mar 05 16:21:51 yeah, that is the error. I had the commit http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/sumo-next&id=8b165b1063e47407c6e00af9cf6893e629052c2d Mar 05 16:22:03 and that did not help Mar 05 16:25:41 last clean build is at http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/sumo-next&id=d3dcc4f92e0fdf1e044bbd71741b77581f64ce6d Mar 05 16:32:52 what was the bug# ? Mar 05 16:33:10 https://bugzilla.yoctoproject.org/show_bug.cgi?id=8729 Mar 05 16:33:11 Bug 8729: enhancement, Medium, Future, dimtass, IN PROGRESS REVIEW , grub: create a script to boot between rootfs and a maintenance partition Mar 05 16:33:14 k Mar 05 16:37:31 YPTM is over. Mar 05 16:39:44 RP, I am re-running sumo-nmut2 to re-establish a clean point. sumo-next was rebased so I don't know 100% where is passed last Mar 05 16:45:18 RP, i have a thud build running, if clean I will start on the result tool integration Mar 05 17:25:54 New news from stackoverflow: Can't run Yocto image with runqemu like described in documentation Mar 05 18:21:23 I'm trying to build network-manager from oe Mar 05 18:21:43 I'm getting the following error: tmp/work/x86_64-poky-linux/mozjs/17.0.0-r0/mozjs17.0.0/js/src/config/rules.mk:726: recipe for target 'jsapi-tests' failed Mar 05 18:21:49 any idea for workaround? Mar 05 18:44:15 networkmanager* Mar 05 19:27:41 turns out it was because of corrupted object files. Just cleaning and rebuilding worked Mar 05 20:02:22 RP: I have most everything working, except lttng for mips/mips64. I’m going to spend some time on that now, but will likely send a series later even if I don’t get it building. Mar 05 20:16:24 zeddii: is it lttng specific or related to yocto/oe? if lttng related I might be able to answer question if you have any Mar 05 20:18:36 ahah. I just figured it out. There were build errors against the 5.x kernel + my new libc headers. So I dumped the current lttng recipe in favour of one I keep around to build from the git branches. That fixed all archs except mips. But looking at it, I dropped a patch that we’ve been carrying for a while for mips to not have a build_bug_on fire … When I dumped the 8 patches on the stable lttng branch AND kept tha Mar 05 20:18:37 patch around, it seems to be building Mar 05 20:18:40 phew. that’s a mouthful Mar 05 20:18:53 but hopefully, that’ll get me moving with all arches. Mar 05 20:27:07 zeddii: I would be interested in seeing those patches, see if any can be ported upstream Mar 05 21:55:03 kanavin: Are you still here? Mar 05 21:57:09 zeddii: cool, mips proving a pain as ever :/ Mar 05 21:57:51 psrcode: not sure if you saw but I managed to improve our lttng-tools ptest test scores. Still a few failing tests to investigate :/ Mar 05 21:58:04 armpit: am I overdue any patch merging? Mar 05 21:58:21 armpit: that patch you pointed at earlier looked like the right fix, disappointing it didn't work Mar 05 21:59:38 RP: yes. Thanks a lot. I'm currently setting up a dev env for yocto to help you a bit on that side (getting a weird mkfs4 error on core-image-minimal), did you saw the email I sent regarding the glibc problem we have with lttng-ust? Mar 05 21:59:39 not for sumo.. I just finish checkout thud-next. is has a openssl10 fix folks are wait for Mar 05 22:00:10 yeah, sumo is be troublesome this week Mar 05 22:00:35 psrcode: yes, its on my todo list. Basically my repsonse is lets rip out those glibc patches Mar 05 22:00:49 psrcode: if you wanted to send a patch removing them I'd likely take it Mar 05 22:01:02 (with a suitable justification in it) Mar 05 22:01:19 we have no business carrying patches rejected upstream like those :( Mar 05 22:01:56 RP: I might have questions regarding overall yocto/oe-core process regarding package update and all, we want (EfficiOS) to be a bit more proactive on the yocto packaging. Mar 05 22:01:58 psrcode: I did hack out a set of tests as they hang. Wasn't sure if that was due to testing under qemu Mar 05 22:02:29 psrcode: I preferred the suite completing than hanging and getting killed though! Mar 05 22:02:38 yeah the notification tests, most probably missing the test executable. I'll look into it Mar 05 22:02:40 RP, i looks like packagegroup-core-x11-base may have a problem.. Mar 05 22:03:00 psrcode: I suspect we could use the help. Happy to try and give the yocto/oe-core process pointers where I can (others here are helpful too) Mar 05 22:03:15 dependency.. haven't tracked it down Mar 05 22:03:26 psrcode: our ptest mangling to get on target is a bit ugly :/ Mar 05 22:04:13 RP: I'm sure I'll get to appreciate it ;p given enought time. Mar 05 22:04:41 psrcode: its the bulk of the lttng-tools recipe. There may be some neater way to do it with upstream Makefile help Mar 05 22:05:12 RP: as for the glibc stuff I'll wait for your feedback, take your time. Mar 05 22:06:19 psrcode: I basically want to collate up the feedback from upstream and write a patch to OE-Core dropping the patches Mar 05 22:08:40 armpit: did you see the thud backport request for rng-tools? Mar 05 22:09:28 armpit: I just forwarded, just in case Mar 05 22:09:42 armpit: I'm happy enough to risk cherry-picking that one int Mar 05 22:10:35 psrcode: Just for reference I'm a bit busy at the moment with the release, YP governance pieces and a conference next week :( Mar 05 22:10:58 RP: I've cced Andreas (glibc) anyway I think I'll ping the bugzilla in the upcoming days, might be the best way to get their attention. Mar 05 22:13:38 RP, I am good with that. Mar 05 22:13:41 psrcode: sounds good Mar 05 22:13:54 RP: take your time, we have a lttng-ust fix/workaround for it anyway. Mar 05 22:14:10 psrcode: I don't like having broken glibc patches though ;-) Mar 05 22:14:23 khem: did you see that discussion btw? Mar 05 22:14:39 i'm sure nobody does... Mar 05 22:15:28 it was just a bit *unexpeceted* ;) Mar 05 22:16:05 psrcode: We are getting better at sorting patches. That one looked sensible and was submitted upstream so seemed like an ok bet Mar 05 22:16:17 we then never saw it get rejected Mar 05 22:17:10 RP: one of the two was rejected, the other one (the one with a major impact) is in limbo. Mar 05 22:17:41 anyway we can continue this via email when you have the time, I'm sure you have other things to do at the moment. Mar 05 22:17:46 psrcode: but seemed likely to be rejected on the same basis? Mar 05 22:18:48 from my perspective based on the feedback from Compudj (mathieu desnoyers) but we are no glibc maintainers! Mar 05 22:19:17 psrcode: right, neither are we :/ Mar 05 22:19:26 psrcode: however khem may have more of an idea Mar 05 22:24:23 armpit: tweaked thud, thanks Mar 05 22:24:30 k Mar 05 22:28:52 I'm currently trying to build a core-image-mininal inside lxc and I end up with the following error during the do_image_ext4 phase: https://pastebin.com/raw/KHFzEJLv Mar 05 22:29:00 no much luck with google Mar 05 22:30:08 psrcode: which filesystem is that on? It looks like the filesystem size calculation is going wrong and the image runs out of space Mar 05 22:30:15 zfs Mar 05 22:31:23 psrcode: would be interesting to see what the size of /root/oe-core/build/tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/rootfs is by different measurement Mar 05 22:31:35 psrcode: you can see the calculation it made... Mar 05 22:32:51 psrcode: you could also try IMAGE_OVERHEAD_FACTOR = "2" or something instead of its default of 1.3 Mar 05 22:33:00 psrcode: just force the rootfs to be larger Mar 05 22:33:15 horrible hack but if it gets you working... Mar 05 22:33:18 yeah -> du -ks yield: 100707 rootfs/ Mar 05 22:33:42 while "du -ks --apparent-size" yield 158973 rootfs/ Mar 05 22:33:59 le me try with the addition of apparent size Mar 05 22:37:31 that fix it Mar 05 22:37:54 psrcode: interesting. We tend to avoid zfs as we found we could break it too easily :/ Mar 05 22:38:17 I had a similar problem lately with zfs for tracefile size :P Mar 05 22:38:54 psrcode: obviously it should work and we should figure this out and fix it... Mar 05 22:40:22 psrcode: actually we should probably note this in a bug... Mar 05 22:40:31 yeah will do for sure ! Mar 05 22:40:36 thanks :) Mar 05 22:40:39 even add a base patch for it Mar 05 22:41:26 psrcode: that log you shared along with the output from du and du --apparent-size gives a great place to start Mar 05 22:41:34 good Mar 05 22:41:44 but beer is calling Mar 05 22:41:51 we shouldn't technically need apparent size as ext should handle sparse files and so on Mar 05 22:42:04 * RP is waiting for a late meeting :( Mar 05 22:45:05 jonmason: thanks for the patches! :) Mar 05 22:45:13 jonmason: did you get KMACHINE working? Mar 05 22:48:06 jonmason: halstead and I had a look at the arm server and I think we have some idea on what we need to sort there Mar 05 22:58:45 I tried it but was unable to get the "KMACHINE_qemuarm = qemuarma15" working. I think zeddii is looking at it Mar 05 23:00:37 RP: glad someone is working on the arm build servers. As soon as I get back from SCaLE, I'll spend 100% of my time on that (assuming that the KMACHINE thing is done and you haven't solved the build issues yet) Mar 05 23:01:18 jonmason, We set -cpu host to get kvm acceleration working for qemuarm64 images. Mar 05 23:05:02 but didn't half the packages fail to build? Mar 05 23:28:10 jonmason, I was testing the oe-selftest prereqs specifically. There are many build problems I haven't looked at yet. Mar 05 23:41:15 psrcode: there's almost definitely a bug for that already Mar 05 23:42:20 psrcode: see poky-contrib:ross/du for my attempt at fixing this blind without access to a file system that i know is troublesome :) Mar 05 23:49:56 RP: is it about https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282 Mar 05 23:49:57 Bug 19282: was not found. Mar 05 23:52:45 RP: I have expressed my concern when they were originally proposed but they were still applied Mar 05 23:53:25 RP: its fine to drop 0026-reset-dl_load_write_lock-after-forking.patch and 0027-Acquire-ld.so-lock-before-switching-to-malloc_atfork.patch Mar 05 23:53:28 we lose nothing Mar 06 00:06:01 khem: I don't think I understood the issue at the time. We should drop them... Mar 06 00:14:55 RP:let me send the patch to remove them Mar 06 00:16:31 khem: thanks :) Mar 06 00:19:53 RP: I sent just now, this builds and boots rpi3 Mar 06 00:20:23 but I only built glibc ipk and updated so full sytem build is not yet done but try it out Mar 06 00:20:57 khem: given the rest of the world survives without these I'm optimistic. I'll add them to -next and run the tests Mar 06 00:23:14 RP:yes I am sure, some realtime folks might be seeing the behaviors these were "fixing" but we do not have any traction on them to come to a upstreamable solution Mar 06 00:38:55 khem: right, with things like that deep in glibc we need upstream's review Mar 06 02:15:13 https://twitter.com/realpython/status/1093876626117545984/ Mar 06 02:15:17 RP: ^ Mar 06 02:15:19 hehe Mar 06 02:40:31 kergoth: same is true for js, rust, golang .. **** ENDING LOGGING AT Wed Mar 06 02:59:57 2019