**** BEGIN LOGGING AT Mon Nov 06 03:00:02 2017 Nov 06 04:58:25 * armpit hmmm, guess I don't need to send a pyro merge request after all.. fine, this leave me with morty Nov 06 06:25:22 The framebuffer build is it with directfb? Nov 06 08:18:05 New news from stackoverflow: erroe while compiling my own recipe in yocto (pyro) Nov 06 10:27:05 ping Nov 06 11:14:46 armpit: you sent a pyro merge request didn't you? Nov 06 12:56:02 armpit: the merge of uboot image class was wrong IMO Nov 06 12:56:18 armpit: it will break many people Nov 06 12:56:33 armpit: what was the reasoning to backport? Nov 06 13:35:35 hmm, i'm having trouble compiling linux-xlnx. the do_compile step fails with a very long log with the only error message i could find being "Makefile:145: recipe for target 'sub-make' failed" Nov 06 13:35:55 interestingly, the same recipe configuration compiled before Nov 06 13:38:19 peacememories: check the log there will be an error message somewhere, otherwise pastebin it :) Nov 06 13:44:24 hm, i've got a vague idea why this is failing Nov 06 13:44:42 not from the logs, but i feel like mixing sstate-cache for morty and pyro builds is not a very good idea^^ Nov 06 14:02:53 nrossi: Is there an overview somewhere of the differences between u-boot and u-boot-xlnx? Or is it just MicroBlaze related stuff that's different? Nov 06 14:03:45 JoiF: you can git diff the two trees. But its mainly zynqmp that is not in upstream u-boot, but michal just sent a rather large series to the u-boot ml for that Nov 06 14:03:50 nrossi: What I'm fishing for: Should QSPI (i.e. sf) work with normal u-boot or are some hacks from u-boot-xlnx required? Nov 06 14:04:22 JoiF: QSPI using a single flash device should work fine, DUAL/PARALLELL configs will need u-boot-xlnx Nov 06 14:04:29 zeddii: We're seeing hangs on qemux86-64 early in boot, I'm suspecting something odd going on with timers :/ Nov 06 14:04:45 nrossi: Ok, thanks! Nov 06 14:05:38 nrossi: I'm only trying to do single, so I'll continue banging my head against this wall. ;) Nov 06 14:06:22 hello! I've cleaned my build/tmp/deploy/images/* for some stupid reason. How do I ask to rerun the deploy stage of all recipes so images/* files are recreated? Nov 06 14:07:49 you can run bitbake it will check for changes and probably only do deploy or bitbake -c deploy Nov 06 14:08:00 luneff: wipe the whole build/tmp and rebuild Nov 06 14:09:02 nayfe, it doesn't think 'deploy' action requires any actions Nov 06 14:09:15 mcfrisk, I see it is an option too, but I'd like to save some time :-) Nov 06 14:09:26 -c deploy -f ? Nov 06 14:09:44 nayfe, could be! thanks Nov 06 14:10:09 or -c clean then rebuild, as it is only image, it should be quick Nov 06 14:11:08 nayfe, image is ok, the thing is that there are bcm*-bootfiles, the kernel and something else, I'm not sure what exactly Nov 06 14:11:14 rebuilding the kernel already ;-( Nov 06 14:13:10 luneff: wipe tmp, rebuild with sstate cache. that brings all deployed files back. Nov 06 14:38:11 thanks to all:-) It seemed, that rebuilding kernel was enough for my case Nov 06 15:00:03 otavio, which commit? Nov 06 15:00:55 otavio, there was one I drop from the previous pull request Nov 06 15:02:22 otavio, what got merge did not include that one " Avoid a circular dependency betweew..." Nov 06 15:42:04 armpit: it did, it seems Nov 06 15:42:40 armpit: anyway I did fix the customer layers but it is just for you to know that people might complain Nov 06 15:46:37 otavio, which commit? I have been staring at commits all weekend and its not jumping out to me. have a link or hash Nov 06 15:48:05 If anyone is interested in speeding up patch merging, please do take a look at this week's status report. We need to fix some of the issues we're seeing during tests before we can more forward. Nov 06 15:49:20 armpit: Nov 06 15:49:22 commit 979ff606d8c4c6f66c6dc533a92212f18708089e Nov 06 15:49:23 Author: Tom Rini Nov 06 15:49:23 Date: Fri Jul 21 18:06:34 2017 -0400 Nov 06 15:49:23 image_types.bbclass: Make u-boot signed images more versatile Nov 06 15:50:25 armpit: it shouldn't be on a stable branch update, well ... at least without a notice Nov 06 15:50:50 armpit: it broke meta-freescale, meta-updatehub and a customer layere for me Nov 06 15:51:04 hmm, not the one I was thinking about. Nov 06 15:51:10 armpit: we did fix it already but ... Nov 06 15:51:42 armpit: right, you dropped a different one Nov 06 15:51:50 did I miss the conversation on that patch? Nov 06 15:51:57 RP, yeah.. Nov 06 15:53:15 otavio, is there a patch to fix this or is it more involved that that? Nov 06 15:53:30 * armpit looks at status report Nov 06 16:08:12 FWIW, I thought I warned about possible external layer breakage on "mage_types.bbclass: Make u-boot signed images more versatile" Nov 06 16:08:34 And it's also causing headeache over in AGL as both the AGL layers and meta-updater have some image_types_uboot stuff Nov 06 16:14:34 armpit: well, I think it is done ... Nov 06 16:15:02 armpit: Tartarus the AGL stuff should be straightforward to fix, just removing the inherit Nov 06 16:15:09 armpit: ahh Nov 06 16:15:27 armpit: adding an empty class should make the conversion painless Nov 06 16:15:58 otavio: yes, it's easy just bad timing Nov 06 16:16:33 armpit: I think adding an empty class with a header explaining it is just to avoid breaking existing layer, is good to go Nov 06 16:16:56 +1 Nov 06 16:20:09 wont this be an issue for Rocko too? Nov 06 16:22:34 * armpit wonders how an old man is supposed to remember a warning four month back when I can't remember what I did last week ; ) Nov 06 16:25:04 +1 Nov 06 16:25:09 * zeddii is a goldfish Nov 06 16:25:18 "look a treasure chest" Nov 06 16:25:20 "look a treasure chest" Nov 06 16:25:22 "look a treasure chest" Nov 06 16:25:36 armpit: no; rocko has it Nov 06 16:26:04 armpit: and new release can break it. When people uses a new release they are expecting upgrade issues Nov 06 16:26:14 armpit: but for a stable, not welcome ;-) Nov 06 16:27:34 armpit: one thing we might investigate to put at the release tools is something to detect class removal on stable releases and deny it. Nov 06 16:27:43 armpit: it would have caught it Nov 06 16:30:50 that change was in a pull request sent out to the public and it did not ring any bells Nov 06 16:31:08 otavio, maybe but I just need to get better at this Nov 06 16:34:20 armpit: honestly, it is hard to pick from the commit log Nov 06 16:34:36 armpit: but I think a health check script is good Nov 06 17:21:02 hello guys, I have an issue on yocto... I'm using ${PN} variable in an .inc file and it is expanded to defaultpkgname Nov 06 17:22:57 I can't figure out why is this happening. The line which I added is: FILESEXTRAPATHS_append := "${THISDIR}/${PN}:" Nov 06 17:25:32 using bitbake -e I found that the PN variable is set after the FILESEXTRAPATHS Nov 06 17:26:14 is the .inc file being picked up when the recipe is parsed? Nov 06 17:27:53 actually I have two recipes which are requiring it Nov 06 17:29:33 and I'm building them one at a time Nov 06 17:29:48 drmo aint _prepend ? Nov 06 17:33:03 no matter what I use append or prepend, I get the same exapansion Nov 06 17:33:12 you want BPN fwiw Nov 06 17:33:43 no, I don't want BPN, which btw is obtained from PN Nov 06 17:34:21 ok, unless you've a really special reason, you want to use BPN in FILESEXTRAPATHS. :) Nov 06 17:34:26 I have the name of the recipe_PV.bb and recipe_PV.inc Nov 06 17:35:10 I used BPN but is the same result Nov 06 17:36:22 if this isn't a bbappend why do you need to do this? Nov 06 17:36:42 or do you have two bbappends that include the .inc Nov 06 17:39:09 yes,I have two .bb that include the .inc Nov 06 17:40:38 http://yocto-ab-master.ostc.intel.com/ Nov 06 17:41:24 from my investigation PN = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0] or 'defaultpkgname'}" from bitbake.conf Nov 06 17:41:37 is this parsing only the .bb and .bbappend files? Nov 06 17:41:51 whithout .inc files? Nov 06 17:47:59 if I move the line in the recipe everything works fine Nov 06 18:53:10 evening Nov 06 18:58:13 A commit from ealier this year introduced a symlink from /etc/tmpfiles.d/etc.conf -> /dev/null.. shouldn't systemd-tmpfiles then load the one in /lib/systemd/tmpfiles.d ? Nov 06 19:23:04 I'm having issues with gdk-pixbuf in a multiconfig setup. Seems the pixbufcache script that runs after setscene only works for the main config but not any of the multiconfigs, causing problems for later packages relying on the cache. I've been poking at runqueue.py and base.bbclass but haven't figured out how to make this work for all the multiconfigs Nov 06 19:58:47 is it possible to have http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/recipes-security/AppArmor/apparmor_2.11.0.bb?id=169a02dff0c2c0d7d5f02fd7e5b346c48159cce5 back ported to pyro branch? Nov 06 20:03:20 as it sits, apparmor recipe is broken in pyro as it requires apache2 as a layer dep. and you shouldn't be required to include apache2 because you want to use apparmor for other apps Nov 06 20:06:24 sum1> maybe submit a patch to mailing list ? Nov 06 20:06:46 I can't. Nov 06 20:09:08 legal dept requires >1month review for any OSS contributions. I already had my hand slapped for submitting a bugfix to change a single letter in a bitbake file. Nov 06 20:10:37 ouch ;) Nov 06 20:11:23 armpit: ^^ Nov 06 20:12:09 sum1: I feel your pain... Nov 06 20:15:44 bluelightning, thanks Nov 06 20:15:50 nayfe, can do Nov 06 20:16:06 sum1, can do Nov 06 20:16:31 armpit: no, thank you :) Nov 06 20:16:38 thanks, i appreciate it. Nov 06 20:17:19 i'm working with mgmt and legal atm to attempt to eliminate the requirement of such a lengthy review process so we -can- start contributing back. Nov 06 20:19:46 sum1, thanks for working on that Nov 06 20:36:42 sum1, would the other two previous apparmor changes help you ? http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/recipes-security/AppArmor?h=rocko&id=ac8db19e5027320a1ba1b99e41424bcbe566e40b and http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/recipes-security/AppArmor?h=rocko&id=25b8f02eeab60c01f3dc38c9d9b0ccbd2491ad8b Nov 06 20:43:18 yes, both PACKAGECONFIG rework and runtime fixes would help Nov 06 21:09:56 sum1, thanks. I will backport those too Nov 06 21:36:53 armpit: much appreciated! thank you Nov 06 21:39:05 np Nov 07 02:51:21 New news from stackoverflow: Should I build full u-boot and kernel to get rootfs on yocto? **** ENDING LOGGING AT Tue Nov 07 03:00:02 2017