**** BEGIN LOGGING AT Tue Jul 25 03:00:02 2017 Jul 25 08:43:45 Hi, guys. I'm having some trouble with my Yocto build, hoping to find some help. Have I come to the right place? Jul 25 08:44:42 tharald: ahrd to tell without knowing your actual problem :-) Jul 25 08:48:12 LetoThe2nd: fair point Jul 25 08:51:39 I've been working with the build for a while, but suddenly I can't make changes to my kernel recipe. I'm trying to add a config fragment, but when I do, I get an error when I try to run bitbake Jul 25 08:51:57 It says "do_rootfs: Unable to install packages", and " Jul 25 08:52:04 Collected errors: * Solver encountered 1 problem(s): * Problem 1/1: * - nothing provides packagegroup-core-boot needed by packagegroup-distro-base-1.0-r83.av2 * * Solution 1: * - do not ask to install a package providing packagegroup-base-extended" Jul 25 08:52:59 When I remove the changes, it works fine again, maybe because it doesn't have to rebuild anything Jul 25 09:13:16 tharald: is there a packagegroup-core-boot package under tmp/deploy/... ? Jul 25 09:16:11 bluelightning: there is a folder under tmp/deploy/licenses named packagegroup-core-boot Jul 25 09:16:40 are you using rpm or ipk packaging? Jul 25 09:16:51 ipk Jul 25 09:17:11 ok, so no packagegroup-core-boot* under tmp/deploy/ipk/ ? Jul 25 09:17:53 hmm, no Jul 25 09:18:13 tons of packagegroup-core- packages, though, but no -boot Jul 25 09:20:13 hmm, that is odd Jul 25 09:20:40 my personal bet actually would be some hard to spot syntax error Jul 25 09:20:41 tharald: bitbake -e packagegroup-core-boot | grep ^WORKDIR= Jul 25 09:21:06 tharald: then have a look under temp, what's in there? Jul 25 09:22:48 it finds /tmp/work/md-poky-linux/packagegroup-core-boot/1.0-r17 Jul 25 09:24:00 WORKDIR="/data/tharald/dart/build-dart/tmp/work/md-poky-linux/packagegroup-core-boot/1.0-r17" Jul 25 09:24:46 right, what's in temp under that directory Jul 25 09:24:57 particularly interested if there is a log.do_package_write_ipk Jul 25 09:26:34 it's a 151 line log file Jul 25 09:26:39 anything specific you're after? Jul 25 09:27:31 it has some errors: "FileNotFoundError: [Errno 2] No such file or directory: '/data/tharald/dart/build-dart/tmp/work/md-poky-linux/packagegroup-core-boot/1. 0-r17/packages-split/packagegroup-core-boot'" Jul 25 09:29:03 and three similar ones, with not found packagegroup-core-boot-dbg, -ptest and -dev Jul 25 09:29:36 packagegroup-core-boot/1.0-r17/packages-split is indeed empty Jul 25 09:40:06 tharald: that's very odd Jul 25 09:46:09 tharald: can you tar up that entire WORKDIR so it's preserved and then bitbake -c clean packagegroup-core-boot followed by bitbake packagegroup-core-boot and see if that fixes it? Jul 25 10:11:21 hi, could someone help out with the following query? I have a do_patch() error on poky/krogoth/for renesas r-car gen3 (m3). Failure error states 'could not checkout branch', 'could not update git tree'. However the origin src tree (tmp/work-shared/m3ulcb/ketrnel-sources) shows the right branch is checked out (v4.9/rcar-3.5.3) and kgit-meta do_patch fails on 'git checkout'right after track_branch call. I would appreciate any hints on ho Jul 25 10:17:39 bluelightning: didn't fix it, unfortunately Jul 25 10:18:55 kanavin: last night i solved the mystery random checkpkg failures. i really hate wget. Jul 25 10:26:30 anyone dealing with toradex here? do they support something more recent than morty? Jul 25 10:43:27 hello. i am trying to build a project (configure by someone who isn't available) and that says "the recipe x is trying to install files into a shared area when those files already exit" and then i see a list of files Jul 25 10:43:38 i try to build with devtool, just to see whether my code would compile Jul 25 10:44:12 any suggestion on where to look? i don't even need this to be correct, i just need to be able to compile such that i can work until the dude who knows yocto is back :)) Jul 25 10:45:00 the first compilation seems to be ok, but after that, i need to delete /tmp every time, which means it takes 1h+ to test a tiny change Jul 25 10:46:04 talin: try bitbake -c compile Jul 25 10:46:55 talin: this will only make the compile. not the after steps. I guess it will suffice. Jul 25 10:47:44 if that works, i will be so happy. i'm going to try once this attempt fails Jul 25 10:51:21 yikes, i think it might work. i introduced an error in my code on purpose, and it didn't complain, so that's a bad sign, but at least it doesn't continue and complain about the rest now. thank you so much Jul 25 10:52:49 talin: after every code change to also this: bitbake -c cleansstate Jul 25 10:53:42 talin: this will clean the recipe workspace and it will get your new code again Jul 25 10:56:00 hmm, it doesn't clean up the workspace/sources, does it? Jul 25 10:56:05 because i am testing my changes in there Jul 25 10:58:10 it will cleanup the recipe work directory under the tmp/work/... folder Jul 25 11:01:31 Tamis, does clean actually clean all state now? Jul 25 11:04:55 redengin: you mean at the sstate folder? I am not really sure about that. Jul 25 11:06:42 talin: bitbake myrecipe -C compile Jul 25 11:06:57 "mark compile as needing to be rerun, and build myrecipe" Jul 25 11:07:04 so that will compile, install, package, etc Jul 25 11:07:15 Tamis, I've not updated in awhile, but clean usually only carried out underlying clean methods Jul 25 11:09:01 rburton: hmm, i just want to test that one of my repos compiles. with -C won't it do a lot more than that? Jul 25 11:09:16 if you just want to test compile, then use -c compile Jul 25 11:09:52 if you're iterating then -c devshell will give you a terminal in the build tree you can run make or whatever in Jul 25 11:11:13 hmm, nice. that sounds perfect Jul 25 11:17:17 pohly: Anything more I need to do on the chaining compression patches? Jul 25 11:17:24 rburton: I haven't seen random checkpkg failures here, is it something local to your setup? Jul 25 11:17:31 Tartarus: they look fine to me. Jul 25 11:17:39 kanavin: the Ab seems them most runs Jul 25 11:17:47 I wanna get on to the next part, posting the vmdk/etc part as a proper COMPRESSION_CMD :) Jul 25 11:17:54 kanavin: patch on the bitbake list if you're curious Jul 25 11:18:12 pohly: Can you ack them then please? Perhaps that'll help get them picked up by RP and then I can ask about pyro and double check if morty needs it too Jul 25 11:18:18 so is anyone in refkit land working out what happens now that beignet appears to have been cancelled? Jul 25 11:19:07 rburton: so is there a branch where you published meson wip? Jul 25 11:19:24 kanavin: ross/meson in poky-contrib and meta-oe-contrib Jul 25 11:19:51 rburton: thanks, I got bugs and version updates out of the way now :) Jul 25 11:20:06 rburton: oh, and ftp needs to die Jul 25 11:20:20 kanavin: (the latter needs to be rebased still) Jul 25 11:20:32 yeah i removed a few more ftp servers in the same series Jul 25 11:21:42 rburton: you want me to sort gtkdoc, and then g-i, right? Jul 25 11:21:44 Yeah, it needs to be done in morty too Jul 25 11:22:01 kanavin: it seems to be that gtkdoc would be easier than gi Jul 25 11:22:48 rburton: yep, there's less moving parts in it Jul 25 11:23:24 kanavin: really hope that the exe_wrapper could just be used, that would make it so easy Jul 25 11:23:44 set it right in the meson class to use qemu, make meson respect exe_wrapper if in cross Jul 25 11:24:13 kanavin: oh i need to push my meta-oe branch,done now Jul 25 11:24:19 rburton: I might remember wrong, but meson wouldn't execute anything directly. it would run gtk-doc scripts written in perl, and those would execute binaries via qemu (for which there is a special arrangement) Jul 25 11:24:52 rburton: similar in g-i, only a lot more hairy Jul 25 11:24:57 kanavin: we already patch those so that woud just work right? Jul 25 11:27:59 rburton: we currently set GTKDOC_RUN in template makefiles provided by gtk-doc, and that is picked up by gtk-doc scripts. in meson, something similar needs to be done, as meson would only run the scripts Jul 25 11:28:14 rburton: basically, an additional environment variable at compile time Jul 25 11:32:58 if a program is linked with -lcrypt, does also the recipe requires hard dependency to glibc? Jul 25 11:37:02 question: if I want to make a change to the kernel config in my layer, what's the 'correct' way to make the change? create a config fragment and add it to the .bb file in the 'linux' folder under recipes-kernel? Jul 25 11:38:24 "bitbake repo -c compile" doesn't find any errors in my code (when i have introduced some on purpose), whereas "devtool build repo" does Jul 25 11:40:55 talin: I would assume you did devtool modify in between right? Jul 25 11:41:31 tharald: that sounds like the right approach yes Jul 25 11:43:06 bluelightning: hmm, i didn't do modify between Jul 25 11:43:28 bluelightning: will that overwrite my workspace dir? because i have a few changes there and i don't really want to lose it Jul 25 11:43:35 i did make a backup of it though Jul 25 11:44:15 talin: no, I'm asking because devtool build just runs bitbake itself so I can't see how you could get different results (though devtool build does -c package IIRC) Jul 25 11:45:25 bluelightning: strangely, devtool seems to do the whole shebang. i can't see any diff between running bitbake recipe and devtool build recipe Jul 25 11:45:44 but bitbake recipe -c compile, seems to do what i want, except it doesn't register my changes Jul 25 11:45:58 talin: where are you making your changes? Jul 25 11:46:29 bluelightning: in workspace/sources/repo/, which was fetched using devtool modify repo Jul 25 11:47:15 talin: what kind of changes did you make? perhaps I can try the same here Jul 25 11:47:39 bluelightning: it's some c++ code where i wrote "blah" on a blank line, just to see that it registers my changes Jul 25 11:48:01 I'm fetching data from a mountpoint via rsync in a recipe's do_fetch() and to avoid errors with the new recipe specific sysroots feature I'm adding: do_fetch[depends] = "util-linux-native:do_populate_sysroot rsync-native:do_populate_sysroot", is this the right way to do it? Jul 25 11:48:59 aratiu: if you do += rather than = yes Jul 25 11:49:21 thank you Jul 25 11:49:52 talin: I guess this is a recipe of your own since I can't find it by searching the layer index Jul 25 11:50:14 bluelightning: yes, i think someone here made the recipe Jul 25 11:50:20 probably Jul 25 11:50:47 talin: would it be possible to show it to me? Jul 25 11:51:47 bluelightning: yes, if i can figure out where it is Jul 25 11:52:12 RP: I've just sent updated /boot patchset. The reason do_image_tar was failing is the bug in the patchset. I somehow managed to forget to unlink /etc/fstab before updating :( Jul 25 11:52:57 ah cool, thanks ed2 Jul 25 11:53:38 ed2: sorry I meant to CC you on the wic-tools patch I sent earlier Jul 25 11:54:11 rburton: It was so obvious, but I managed to overlook that anyway :) Jul 25 11:54:36 bluelightning: thanks, will look at it. Jul 25 11:54:47 bluelightning: this would be a .bb-file, right? Jul 25 11:55:17 talin: yes... bitbake -e repo | grep ^FILE= will tell you where it is FYI Jul 25 12:03:12 bluelightning: when I do it this way, I get the error discussed earlier. do you have any tips on how to proceed? can I reinstall the packages somehow? if not, can I reinstall or clean the entire project in any way? Jul 25 12:04:03 tharald: try bitbake -c cleansstate packagegroup-core-boot then try again Jul 25 12:04:20 tharald: I don't think this issue is directly related to your change Jul 25 12:09:24 bboozzoo: AFAIK no Jul 25 12:10:01 Is it possible to only include a kernel config fragment when a specific package is to be installed? Jul 25 12:10:29 LostInPXE: I'm afraid not, no Jul 25 12:10:32 bluelightning: yeah, me neither. I think I must have made some change while debugging something else, and messed it up, because this has worked fine for me before Jul 25 12:11:00 tharald: I'd love to know what you might have done to cause this, I've never seen this kind of failure before Jul 25 12:11:57 bluelightning: yeah, I've spent the last two hours backtracking with no luck, unfortunately Jul 25 12:12:11 but it seems like the cleansstate might have done the trick Jul 25 12:13:35 tharald: if you wouldn't mind sending me the tarball you made of the workdir that would be great - maybe I can diagnose what happened Jul 25 12:17:33 mckoan: thx, got it somewhat to build with master branches of meta-freescale[-3rdparty] and poky, running into some problems with u-boot though Jul 25 12:17:44 bluelightning: ah, I deleted it when the last commands didn't help. sorry Jul 25 12:18:02 but thanks a lot for your help Jul 25 12:18:06 bboozzoo: you could manage it out of Yocto tree though Jul 25 12:18:10 tharald: sigh - that was kind of why I asked you to create it... oh well Jul 25 12:18:20 tharald: glad that your problem got fixed in any case Jul 25 12:18:26 bluelightning: yeah, I assumed it was just for backup purposes Jul 25 12:18:34 sorry I should have said Jul 25 12:18:38 I don't even really know what's in there Jul 25 12:19:00 the work directory is where all of the intermediate files for a particular recipe get written to Jul 25 12:20:01 ah, I see Jul 25 12:20:08 anyway if you hit this kind of issue again please do let me know and we'll dig into it Jul 25 12:20:34 kanavin: is the icu 59.1 upgrade the one that breaks qt4? Jul 25 12:20:35 definitely Jul 25 12:33:26 ed2: er, that doesn't make sense since it wasn't the fstab file that changed? Jul 25 12:51:56 rburton: yes Jul 25 12:55:37 mckoan: https://lists.yoctoproject.org/pipermail/meta-freescale/2017-July/020781.html this + masking xserver-xorg, python3-docutils & mtd-utils bbappends got the build to complete Jul 25 13:11:17 bboozzoo: ;-) Jul 25 13:39:53 is it bad form to RPROVIDES a -dev package? I have separate package that requires elements from a -dev package at runtime. Jul 25 13:41:36 RDEPENDS you mean? Jul 25 13:43:01 rburton: No, I have a package that RDEPENDS on this -dev package, but the recipe for that -dev package doesn't RPROVIDES it, so bitbake complains about there not being an RPROVIDES for this -dev package. Jul 25 13:43:36 but bitbake will know that the -dev package exists because its in PACKAGES... Jul 25 13:44:33 Hmm... Jul 25 13:44:36 typo. Jul 25 13:46:03 rburton: thanks - I had a _ instead of -. Jul 25 13:49:43 Actually, now I just get a QA dev-deps issue. Jul 25 14:20:28 pohly: Bah, I have IMAGE_FSTYPES += "vmdk" being converted automatically to wic.vmdk Jul 25 14:20:32 But no symlinks being made Jul 25 14:28:01 Hi, I want to provide patch with fix for systemd rcS support for OE-Core layer. This support was broken in Krogoth and dropped in Pyro. I can provide patch for Krogoth and Morty that fix broken rcS support. And I can create patch for current master that returns support for rcS. What is correct way to provide patch? If I send patch to maillist according to http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded what is Jul 25 14:28:01 correct way to specify target branch? Jul 25 14:28:35 m_kim: in the email subject Jul 25 14:28:42 'morty', etc Jul 25 14:28:58 and if the support was dropped in pyro, I wouldn't try and re-introduce it Jul 25 14:29:01 just fix in morty Jul 25 14:32:54 Ok, thank you Jul 25 15:24:52 hello guys ! i'm using the meta-raspberrypi to build an image for a rasperry pi0 Jul 25 15:25:19 in particular i need to use the gpu Jul 25 15:26:03 from what I have understood the precompiled libraries/binaries that I need are there: https://github.com/raspberrypi/firmware Jul 25 15:26:20 in particulare in ./hardfb Jul 25 15:26:48 in the meta-raspberrypi layer there is a file called firmware.inc that: Jul 25 15:27:05 RPIFW_DATE ?= "20170405" Jul 25 15:27:06 RPIFW_SRC_URI ?= "https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz" Jul 25 15:27:06 RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}" Jul 25 15:27:06 SRC_URI = "${RPIFW_SRC_URI}" Jul 25 15:27:06 SRC_URI[md5sum] = "ea82d14a7cd8cfae9b78e00d4e56bc71" Jul 25 15:27:06 SRC_URI[sha256sum] = "2f4e5bddbac1372590db203002c35cbba3fb9d6172a93c314ee27bf05ae13bff" Jul 25 15:27:06 PV = "${RPIFW_DATE}" Jul 25 15:27:39 so that the firmware is downloaded into the building folder Jul 25 15:28:21 the bcm2835-bootfiles.bb includes the firmware.inc Jul 25 15:28:58 "include recipes-bsp/common/firmware.inc" Jul 25 15:29:22 but the ./hardfp is not included in the final image Jul 25 15:30:00 and I think it's correct because there are no install directive to put the firmware files anywhere Jul 25 16:15:24 fberg: the packaging is different for OE Jul 25 16:15:57 its inline with standard paths instead of rpi foundation structure Jul 25 16:16:26 usually the machines define if they support vfp and distros then decide if they should be hardfp Jul 25 16:16:31 ABI wise Jul 25 16:21:19 thank you khem Jul 25 16:21:53 by the way I don't have understood. I'm pretty new to the yocto worls Jul 25 16:23:01 I've found the recipe: meta-raspberrypi/recipes-graphics/vc-graphics-hardfp.bb Jul 25 16:23:15 that probably does what I wan to: Jul 25 16:23:48 obiusly there is a conflict problem since: Jul 25 16:24:36 ERROR: Nothing RPROVIDES 'vc-graphics-hardfp' (but .../poky/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it) Jul 25 16:24:36 ERROR: vc-graphics-hardfp was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to userland, not vc-graphics-hardfp Jul 25 16:25:55 now with the help of my old friend "grep -r" I've found that meta-raspberrypi/conf/machine/include/rpi-default-providers.inc Jul 25 16:26:01 includes the line: Jul 25 16:26:13 PREFERRED_PROVIDER_virtual/libgles2 ?= "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}" Jul 25 16:26:20 that seems to generate the error Jul 25 16:40:09 pohly: You should hang out in #oe ;) I've got a fix for the metadata is inconsistent error msg that pops up when you start chaining 2+ CONVERSION_CMDs together, ie ext4.gz.sha256sum Jul 25 17:57:08 rburton: what is that degnome stuff? Jul 25 17:57:18 just wondering :) Jul 25 18:52:31 hi Jul 25 18:52:52 does yocto download something only when doing "sync" ? Jul 25 19:54:01 ranran: what do you mean by sync? Jul 25 19:54:13 ranran: what exactly is this "sync" you're talking about? bitbake provides no "sync". if you're talking about "repo sync", that's not provided by the yocto project tooling at all, and would be something provided by your vendor Jul 25 19:54:38 and the answer in that case would be no, bitbake fetches sources for software from upstream in its fetch tasks Jul 25 19:58:33 Thanks. the fetch is responsible for download. I understand now. **** ENDING LOGGING AT Wed Jul 26 03:00:02 2017