**** BEGIN LOGGING AT Mon May 08 03:00:02 2017 May 08 09:03:24 hi May 08 09:04:39 I was wondering about the LICENSE_PATH and what I have to put as LIC_FILES_CHKSUM to reference a file from there? May 08 09:06:15 cause right now I'm referencing it with "file://MY_DUBIOUS_LICENSE" and bitbake complains, saying something like: "Could not find MY_DUBIOUS_LICENSE in my_dubious_pkg/git/c0ffee/" May 08 09:06:30 I was following https://www.yoctoproject.org/blogs/khem/2014/suppliment-common-licenses-yocto-project May 08 09:07:00 and bitbake -e shows that my LICENSE_PATH indeed contains the license directory that contains MY_DUBIOUS_LICENSE May 08 10:28:59 im having trobble setting up QT for a qt qml application. When i open the main.qml qt shows a red line under: import QtQuick.Controls and list it as it cant be found May 08 10:36:51 hello all May 08 10:37:25 I'm having troubles with the libndp_1.6.bb: " libndp-1.6-r0 do_fetch: Failed to fetch URL http://libndp.org/files/libndp-1.6.tar.gz" May 08 10:37:33 is this a know issue? May 08 10:37:59 MarcWe: have you checked the QtQuick module within the root directory? May 08 10:38:47 iirc you need to list it as a RDEPENDS of your main application. The build won't fail if it does not exist. May 08 10:43:36 T_UNIX QtQuick module in the root dir???? the QtQml folder with content is existing in the cortexa8hf-neon-linux-gnueabi/usr/include/qt5/QtQml/ path May 08 10:46:22 Anyone seen this (or something similar) before? May 08 10:46:26 ERROR: Recipe avahi-ui is trying to change PR from 'r11.0' to 'r0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. May 08 10:46:32 ERROR: Function failed: read_subpackage_metadata May 08 10:47:27 The command line was: May 08 10:47:28 bitbake cube-essential cube-dom0 cube-dom1 cube-gw cube-server cube-desktop May 08 10:47:57 ...because I'm building Wind River Pulsar 8 Linux (a yocto distribution.) May 08 10:48:28 msvb-lab: probably unrelated to your original problem: bitbake does not support multiple targets in one go, at least not that i knew of May 08 10:49:13 msvb-lab: and to go even more nitpicking: WRLInux is a yocto compatible OE distribution, not a yocto distribution ;-) May 08 10:49:17 LetoThe2nd: Interesting. Do you think if I rebuild from scratch using one target after another, that the errors will disappear? May 08 10:49:51 msvb-lab: no idea. maybe that has changed lately or WR patches bitbake. you can of course give it a try. May 08 10:50:31 msvb-lab: but generally, this kinda sounds more like something related to maybe a PRSERV in use? May 08 10:50:51 what makes you think bitbake doesn't support multiple targets in one go? May 08 10:51:30 we most certainly do support it, the YP autobuilders do that all the time May 08 10:51:39 LetoThe2nd: By the way, I've reduced my set of customizations (vanilla Wind River now) and using the same multi target command I believe the build is working. May 08 10:52:15 joshuagl: ah really? thanks for the clarification, i happily stand corrected. May 08 10:52:53 LetoThe2nd: np, have you observed a case where it fails? May 08 10:53:03 The PR from 'r11.0' to 'r0' problem is probably related to my customizations. Probably from including rabbitmq-server from meta-openembedded/meta-openstack or a similar addition I made. May 08 10:54:13 I've grep(1)ed the entire 1GB of Wind River yocto source for 'PR.*avahi-ui' and similar. May 08 10:54:19 PR shouldn't go backwards, and if a layer affects it that's a concern. Sounds like you might be using a PRServer and there's a recipe/bbappend somewhere explicitly setting PR ? May 08 10:54:29 ...and not figured out where things are changing from r11.0 to r0. May 08 10:54:50 joshuagl: no i haven't i just thought it was discussed in some way. did i maybe mix it up with devtool? May 08 10:55:33 hmm, perhaps. I don't really know devtool May 08 10:57:15 msvb-lab: if it's a bbappend or recipe setting PR it'll just be an assignment line like `PR = "r0"` somewhere May 08 10:57:37 rather than a PN override May 08 10:57:44 joshuagl: I find the place where avahi-ui PR is defined to r11.0 in: May 08 10:58:43 https://github.com/WindRiver-OpenSourceLabs/wr-core/layers/oe-core/meta/recipes-connectivity/avahi/avahi-ui_0.6.31.bb May 08 10:59:01 ...but I can't find a second overriding 'PR.*=' line anywhere. May 08 10:59:03 "Not Found" May 08 10:59:35 The line in question (that I did find) is: May 08 10:59:38 PR = "${INC_PR}.0" May 08 10:59:45 joshuagl: you really should check it out ;) May 08 11:04:00 joshuagl: I'm trying to get the tree URL for you so you don't need to check it out, but Wind River integrates oe-core as a submodule or something, so the canonical location is elsewhere (in another repository.) May 08 11:07:07 MarcWe: never mind. It seems you're talking about QtCreator. So either your paths are incorrect (e.g. you didn't source the environment script before starting qtcreator), or you're missing files. May 08 11:14:26 hello, when trying to build an extensible sdk for my image that has qt5 in it I get this error: https://pastebin.com/0QfsudXV May 08 11:18:17 my image is based on standard example fsl-image-qt5 from Freescale community BSP and contains inherit populate_sdk_qt5 in its recipe May 08 11:20:33 T_UNIX: ty May 08 11:22:08 here is the full error log: https://pastebin.com/4VKrKXiN May 08 11:25:58 T_UNIX: if done some searching in the sdk but i cant finde .qml files May 08 11:41:40 joshuagl: I figured out the canonical URL for the oe-core submodule in Wind River's yocto compatible OE distribution. May 08 11:41:45 https://github.com/WindRiver-OpenSourceLabs/oe-core/blob/c2ff48990dd438d8dddaffed85d64b2da2ef62ee/meta/recipes-connectivity/avahi/avahi-ui_0.6.31.bb May 08 11:41:58 INC_PR is defined in: https://github.com/WindRiver-OpenSourceLabs/oe-core/blob/c2ff48990dd438d8dddaffed85d64b2da2ef62ee/meta/recipes-connectivity/avahi/avahi.inc May 08 11:42:33 ...so the question is 'why does the PR = r11.0 definition get changed to r0 and where does this happen?' May 08 11:44:00 ...to cause the build failure: May 08 11:44:00 ERROR: Recipe avahi-ui is trying to change PR from 'r11.0' to 'r0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. May 08 11:44:11 ERROR: Function failed: read_subpackage_metadata May 08 11:47:06 There's all kinds of recipes defining 'PR = r0' like gdb or nss, but this would seem unrelated since avahi-ui/avahi.inc is clearly setting 'PR = r11.0' only once. May 08 11:48:09 There is python.inc where 'INC_PR = r0' at: May 08 11:48:10 https://github.com/WindRiver-OpenSourceLabs/oe-core/blob/7cccaafc69e7758d4c2cfd2b0d19e06c7fbb10ee/meta/recipes-devtools/python/python.inc May 08 11:48:27 ...but I don't think avahi-ui...bb is including it? May 08 11:48:31 Wild goose chase... May 08 11:50:47 msvb-lab: bitbake avahi -e | less, search for PR=, and see what sets it May 08 11:51:02 avahi-ui, even May 08 11:53:16 rburton: Thanks, going to try that now... May 08 11:55:57 regarding the libndp_1.6.bb May 08 11:56:08 rburton: ERROR: Only one copy of bitbake should be run against a build directory May 08 11:56:11 ...because I May 08 11:56:24 ...because I've got a bitbake(1) operation in another window. May 08 11:56:33 so abort that, or wait for it to finish May 08 11:56:37 Should I just mkdir build-2 && cd build-2 and try again. May 08 11:56:57 the host libndp.org is down. Is someone taking care to update the libndp_1.6.bb with mirrors? May 08 11:57:04 msvb-lab: not worth the risk in case its a local.conf change that is causing problems May 08 11:57:31 rburton: Okay, with a heavy heart I'm going to abort my 11 hour build now... May 08 11:57:31 ilial: you can be the proud author of the patch! :) May 08 11:57:44 msvb-lab: it will continue where it left off May 08 11:58:20 rburton: a proudthor! May 08 11:59:05 rburton: Even if I kill -TERM the residual cc1plus(1) and other processes? May 08 11:59:28 A ton of stuff keeps running when I abort a bitbake(1) and usually keeps me waiting 5 minutes. May 08 11:59:56 ...so the 'continue where it left off' saves me 11 hours but still costs me 10 minutes. May 08 12:00:32 I'll try anyway, since I haven't tried bitbake(1) avahi-ui -e yet. May 08 12:01:25 how to I build extensible SDK with qt5 support? May 08 12:08:20 msvb-lab: control-c once to tell bitbake to stop when all current tasks have ended, control-c again to make it abandon the tassk May 08 12:24:51 Hello. May 08 12:24:51 I am developing my own image and application to run on it. I need some help with 2how i get my applications to autostart preferably with systemd as i have some prior knowlege about it. May 08 12:24:51 The applications uses autotools and the recipes for them just contain the description, license and git remote data. Could someone point me to a guide or tutorial for extending an autotools recipe with systemd start/stop service? May 08 12:28:59 hattzy: i'd have a look at something that already is systemd enabled, like dropbear: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/dropbear/dropbear.inc May 08 12:29:23 Thanks. I'll do that May 08 12:45:37 If my bblayers.conf includes oe-core and the build breaks, then I mv oe-core.old && git clone oe-core (that's a different version) May 08 12:45:50 ...will bitbake completely rebuild all packages in the oe-core layer? May 08 12:46:33 it will rebuild everything that changed yes May 08 12:47:10 My test with bitbake avahi-ui -e didn't tell me much. 23000 lines where I learned that if PR is not defined bitbake considers it to be 'r0.' May 08 12:47:36 ...but still no smoking gun. I can't figure out why avahi-ui is changing from r11.0 (found that definition!) to r0 (nowhere?) May 08 12:48:43 rburton: My new theory is that because I updated oe-core to the tip revision (Wind River used a version missing rabbitmq recipes) that may be the place where r0 is getting implicitly defined. May 08 12:49:22 Implicit means that I can't search and find a 'PR = r0' anywhere in the 1GB sources. May 08 12:52:06 yes May 08 12:52:19 current oe-core only sets PR if absolutely required May 08 12:52:47 it shouldnt have gone backwards without a PV bump too though May 08 12:53:32 rburton: You're saying I can gain insight in the bitbake avahi-ui -e dump by searching for 'PV'? May 08 12:53:35 yes, we upgraded to 0.6.32 and removed the PR May 08 12:53:51 rburton: What do you recommend to grep for, 'PV .*' or something better? May 08 12:54:09 tbh i'm not sure what your problem is May 08 12:55:09 Wind River is using avahi-ui_0.6.31.bb which I guess includes 'PR = r11.0' (after variable expansion.) May 08 12:55:15 yes May 08 12:56:01 And the problem is that bitbake is failing with the message: May 08 12:56:02 ERROR: Recipe avahi-ui is trying to change PR from 'r11.0' to 'r0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. May 08 12:57:01 Since I'm neither manually upgrading avahi-ui to 0.6.32 nor is this version anywhere in the sources (at the time of failure) I can't imagine that the new change (implicitly setting PR = r0) is the root of the problem. May 08 12:57:45 Maybe if I turn this problem on its head and explicitly update to 0.6.32 then my build error will go away? May 08 12:59:00 msvb-lab: can you replicate that error if you try again with the provided layers? May 08 12:59:26 (at first glance it sounds like you're changing the recipe during the build) May 08 12:59:56 rburton: If you mean 'try again without making my custom changes' then that's what I'm building to test right now. A vanilla Wind River (with old oe-core and other old stuff) layers. May 08 13:00:09 just bitbake avahi-ui will do, obviously May 08 13:00:33 rburton: I've changed recipes quite a lot, but only in response to build errors (trying to solve them.) May 08 13:01:26 rburton: Okay, doing bitbake(1) avahi not and will follow that with avahi-ui. May 08 13:02:21 rburton: Typo, I'm trying bitbake(1) avahi now... May 08 13:05:44 So bitbake(1) avahi completed successfully, trying avahi-ui now with the old (original Wind River) oe-core and new (git clone master) meta-cloud-services, which is the only customization I've made. May 08 13:06:29 Spoke to soon, I'm still waiting for avahi to finish (it was only a fetch operation that succeeded.) May 08 13:15:12 rburton: that was not answer to my question, but I'll try. thank you May 08 13:16:57 Does this make sense: May 08 13:17:09 Currently 4 running tasks (904 of 973):0: binutils-native-2.25.1-r0 do_compile May 08 13:17:09 1: coreutils-8.24-r0 do_compile May 08 13:17:09 2: avahi-0.6.31-r11.1 do_compile May 08 13:17:09 3: readline-6.3-r0 do_package_write_rpm May 08 13:17:38 ...I mean, if avahi depends on coreutils then it obviously can't build at the same time. May 08 13:17:55 If avahi depends on coreutils, then coreutils must first finish building before avahi can start surely? May 08 13:18:14 where does avahi depend on coreutils? May 08 13:18:17 And if avahi doesn't depend on coreutils, then whey does coreutils build when I type $ bitbake avahi May 08 13:18:38 because dependencies \o/ May 08 13:18:53 its probab;y working up to building rpm or something May 08 13:19:45 rburton: Oh, so linking avahi.o doesn't require some coreutils thing, but packaging avahi (to avahi.rpm) requires rpm(1) which depends on coreutils. May 08 13:19:50 ...that's your theory right? May 08 13:19:56 yeah something along those lines May 08 13:20:04 you can ask bitbake for a full dep tree if you want May 08 13:20:30 Seems correct, and would explain why avahi has a weak dependency to coreutils but can indeed build at the same time (until packaging starts.) May 08 13:21:12 rburton: I don't want to look at a dep tree, but thanks for the advice. May 08 13:21:44 I'm just sad that $ bitbake avahi output states '973 tasks to build' which seems like quite a bit. May 08 13:22:14 ...like now libx11 is building, what? May 08 13:22:56 Sure, many things might depend on avahi but I can't image that avahi depends on hundreds of libraries. May 08 13:23:28 dbus May 08 13:24:13 Hmm, good guess with dbus. May 08 13:28:23 Okay, finally I can say that avahi succeeded, and now I'm going to try with avahi-ui. If avahi-ui doesn't crash, then this test was inconclusive. May 08 13:29:39 Really hoping that avahi-ui crashes now, and proves that a vanilla Wind River build with meta-cloud-services updated localizes the error. May 08 13:30:42 or it works fine and it proves that WR isn't broken, you broke it somehow May 08 13:32:09 rburton: That's what I mean, that I included a package that caused the error. May 08 13:32:34 it won't be another package, it would have to be a change to the recipe (or a layer that appends it) May 08 13:34:48 rburton: That's my suspicion as well, I think I added a meta- to the bblayers.conf and the new recipes are defective, causing a double inclusion (and incompatability) of avahi-ui. May 08 13:36:43 Just for example, after including some (not sure which of 5) meta- in bblayers.conf I started seeing the 'consider defining a PREFERRED_PROVIDER entry' warning due to having perl-avahi and avahi-ui both in the build. May 08 13:36:59 that's special May 08 13:38:03 Meaning that one of the recipes in one of the new meta- depends on either perl-avahi or avahi-ui, and the vanilla Wind River config depends on the other one, I guess? May 08 13:38:50 more likely that perl-avahi is a fork of avahi-ui, just tweaked differently May 08 13:39:07 (the summary is that the avahi recipes need to be destroyed and rewritten) May 08 13:39:13 can't find perl-avahi on layers.yp May 08 13:40:00 if you get a preferred provider warning its because two recipes provide the same names May 08 13:41:42 rburton: About the preferred provider warning, it seems those are harmless. Just to be sure I've specified preferences, but unfortunately those preferences are my best guesses. No idea if one of the alternatives are fresher, less buggy, more feature rich, or whatever. May 08 13:42:04 they're not harmess :) May 08 13:43:24 rburton: Hmm, well Wind River's config doesn't specify any preferences so I assume it's okay to ignore the wanings? At least Wind River thinks so, and I think their vanilla build succeeds. May 08 13:44:40 Back to my new theory, the vanilla oe-core layer includes avahi-ui_0.6.31.bb and my updated meta-cloud-services layer includes python-avahi_0.6.32.bb. May 08 13:45:09 rburton: So if you're right about perl-avahi being a renamed avahi-ui recipe, then this would explain the error. May 08 13:45:33 python-avahi wouldn't conflict May 08 13:45:37 oh maybe it would May 08 13:45:55 ...since PR was reset to r0 when avahi-ui reached 0.6.32. May 08 13:46:19 oooh May 08 13:46:19 yeah May 08 13:46:26 The PR numbers would conflict if I only update one of the two layers containing incompatible recipes. May 08 13:46:42 still not sure why you're getting a conflict May 08 13:46:54 ...so that's a pretty strong indicator, and I hope I've solved the mystery. The bitbake build will prove this theory right or wrong. May 08 13:48:02 rburton: You're not sure? I believe it's because inside avahi-ui v0.6.31 there's an explicit PR = r11.0 but in the newer perl-avahi v0.6.32 the PR definition is removed (implicitly meaning PR = r0.) May 08 13:48:06 Does that make sense? May 08 13:48:28 do you mean python-avahi May 08 13:49:09 Sorry, not perl rather I mean python, yes. May 08 13:49:30 rburton: But if you're thinking 'they are two separate packages and could each have their own version and PR' then I understand your concern. May 08 13:50:06 no i'm wondering why you got that error mid-build and why avahi-ui conflicts with python-avahi May 08 13:53:42 rburton: Maybe avahi-ui doesn't conflict with python-avahi. Looking at the latter's bb file it doesn't include anything nor depend or reference avahi*. May 08 13:54:52 And avahi-ui*.bb does include avahi.inc but seems quit isolated from the python-avahi logic. May 08 13:55:28 RP, rburton: when I include layers with BBLAYERS = "/fast/work/intel-iot-refkit/openembedded-core/meta /fast/work/intel-iot-refkit/meta-yocto/meta-poky /fast/work/intel-iot-refkit//meta-intel" I end up with an error ("BBPATH references the current directory, either through an empty entry,...") because meta-yocto prepends and OE-core appends. May 08 13:55:40 This leads to: BBPATH="/fast/work/intel-iot-refkit/meta-yocto/meta-poky::/fast/work/intel-iot-refkit/openembedded-core/meta:/fast/work/intel-iot-refkit//meta-intel:/fast/work/intel-iot-refkit//meta-intel/common" May 08 13:57:19 I'm not sure how to avoid that. I'm not even sure why it works in Poky :-/ Need to check... May 08 13:59:47 Ah, I am missing the BBPATH = "${TOPDIR}" in my artificial bblayers.conf. May 08 14:18:53 pohly: it's not mandatory to put anything in BBPATH, is it? Isn't it a bug in meta-yocto? May 08 14:20:09 https://patchwork.openembedded.org/patch/28487/ May 08 14:20:12 JaMa: I don't know. Both layers assume that BBPATH isn't empty, so perhaps initializing BBPATH with TOPDIR is an established convention that has to be followed. May 08 14:20:48 rburton: So bitbake(1) avahi-ui just finished with no build errors. There is a avahi-ui_0.6.31.bb including 'PR = r11.0' from Wind River's oe-core (chosen revision) layer and a python-avahi_0.6.32.bb file with an implicit 'PR = r0' from my custom git clone meta-cloud-services layer update. May 08 14:20:57 I've recently dropped TOPDIR from all our build setups, but I'm not using meta-yocto anywhere luckily May 08 14:21:25 also discussed here: May 08 14:21:26 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg18427.html May 08 14:24:07 https://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/image_types_wic.bbclass?id=88bda7d78d6f20bce48cf6a49d392864f866ae90 May 08 14:27:44 https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg51473.html May 08 15:26:35 hi! just a question about network-manager May 08 15:27:19 When I try to install networkmanager instead of connman, and try #nmcli d May 08 15:27:57 return NetworkManager is not running May 08 15:28:38 hi, is freescale git down or dead? May 08 15:28:39 any clue about how I can run the NetworkManager in core-image-sato? May 08 15:34:27 vm_: which URL? May 08 15:35:06 git://git.freescale.com/imx/imx-firmware.git May 08 15:36:14 web interface is accessible May 08 15:36:22 but not git May 08 15:37:12 vm_: rigth, something is wrong May 08 15:37:42 since minimum 2 days May 08 15:47:22 lsandov: can you do something there? May 08 15:47:48 vm_: let me ping Otavio May 08 15:48:10 that would be nice, thx May 08 15:49:48 vm_: Otavio is aware and will check in two hours May 08 15:50:00 thx alot May 08 15:57:27 Anyone know what results from a (1) successful bitbake build, defining new PREFERRED_PROVIDER entries in local.conf, and then (2) carrying out the same bitbake command? May 08 15:59:16 I'm trying to understand the meaning of PREFFERED_PROVIDER, and I guess that the *.bb files which specify IMAGE_INSTALL contents use the preferred packages. May 08 15:59:16 If no preferences are defined then those images make a random choice? May 08 16:00:17 ...so it would seem that if the random choices coincide with the fresh build's new PREFERRED_PROVIDER definitions, then nothing new would be build. May 08 16:01:07 But if even a single IMAGE_INSTALL definition changes implicitly (due to a new PREFERRED_PROVIDER definition) then the image would be rebuilt using a different set of packages? May 08 16:01:38 That's my understanding yes. May 08 16:02:08 afaik it's undefined, not random. might be the same, might not, depends on circumstances which are entirely unknown, but there's no guarantee it'll work at all, particularly if multiple providers for a thing both end up built May 08 16:02:38 neverpanic: Cool, I'm about to rebuild (bitbake with same arguments) after changing PREFERRED_PROVIDERS, and I'm hoping to make a better image. May 08 16:03:54 kergoth: Random is the wrong word, thanks for correcting me. There's probably some bitbake internal logic which make the choice based on a set of conditions (like if a similar component was already used.) May 08 16:05:23 The problem I'm having is that after adding six new meta- paths to bblayers.conf, I see a bunch of bitbake warnings recommending that I make PREFERRED_PROVIDER entries. May 08 16:06:26 But I don't have time to go down rabbit holes inspecting each alternative and how it interacts with the sofware dependent on it. So I make semi-educated guesses when entering PREFERRED_PROVIDERS. May 08 16:07:00 not too surprising. the layer that adds the new provider that conflicts with oe-core should define weak defaults in layer.conf, IMO. I'm not sure if DEFAULT_PREFERENCE will do that context or not May 08 16:07:13 in either case it's a bug in the layer that added the new provider, in my opinion.. May 08 16:07:14 I guess this workflow is okay? Or maybe there's a better way, like no PREFERRED_PROVIDER entries at all until one is sure of which alternative is safe to prefer? May 08 16:07:20 does the readme for that layer indicate how it should be set? May 08 16:07:30 meta-java, for example, has multiple providers, and iirc the readme explicitly covers it May 08 16:07:44 you're far, far better off setting it to *anything* Than nothing May 08 16:07:49 as i said, the behavior is undefined otherwise May 08 16:07:56 better to know what you're getting, even if you don't know what's best May 08 16:09:51 The preference guesses I've made are: https://ghostbin.com/paste/rxds2 May 08 16:10:30 kergoth: I've never seen a README give advice on how to set a PREFERRED_PROVIDER, but I'm not using yocto or bitbake too often. May 08 16:11:19 Some things are obvious, like my choice to stick with NodeJS 6 (LTS) rather than 7 (dev) but that's only because I know my way around. May 08 16:11:43 Like the preference of mdns version 'git' as opposed to '544' is totally opaque. I have no idea even which one is newer or contains less bugs. May 08 16:12:04 kergoth: Thanks for confirming that any choice is better than no choice. May 08 16:12:08 np May 08 16:35:17 RP: I have something to run by you if you have a minute May 08 16:43:03 marka: I have a few minutes May 08 16:44:00 I was noticing some QA warnings on older builds "pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to" May 08 16:44:14 when I went to reproduce these on master I notice they don't show up May 08 16:44:18 so I dug in May 08 16:45:17 I noticed there was some anon python added to base.bbclass May 08 16:45:41 around do_unpack, it adds S to cleandirs May 08 16:45:57 --- May 08 16:45:59 if d.getVar('S') != d.getVar('WORKDIR'): May 08 16:46:00 d.setVarFlag('do_unpack', 'cleandirs', '${S}') May 08 16:46:02 --- May 08 16:46:23 this is hiding the QA warning, since cleandirs not only removes the directory but also creates it May 08 16:46:49 according to build.py May 08 16:47:06 -- May 08 16:47:07 bb.utils.remove(cdir, True) May 08 16:47:09 bb.utils.mkdirhier(cdir) May 08 16:47:10 --- May 08 16:47:42 marka: unintended side effect I think May 08 16:48:00 is it an important one though? ie. should we care? May 08 16:48:18 thus why I thought I would bring it up May 08 16:48:47 it really does not make any difference, other than you end up with an empty directory May 08 16:49:08 and we are executing do_qa_unpack which will never do anything May 08 16:49:18 or usually do nothing I suppose May 08 16:51:42 marka: Its a good question. That code should probably just clean that directory if it exists and not create it. We don't have a bitbake "shortcut" for that right now. We could however tweak do_unpack directly I guess May 08 16:51:58 I don't think its hugely important but ${S} pointing at invalid directories was annoying May 08 16:52:51 sounds like it is a 50/50 issue, damn, I was hoping for clarity :D May 08 16:53:31 I will raise a defect and somebody who is more invested could make the call then May 08 16:56:00 marka: I'd be tempted just to move the directory deletion into base_do_unpack. I do worry how many warnings that might trigger though May 08 16:57:57 ya, been like this since Mar 2016, so a pretty long shaddow May 08 16:58:57 I will toy with it and see what the fallout is, regardless I will writeup a defect so this is documented May 08 16:59:52 marka: I created http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=97ad5ea4347718220fa79b65ce1ee8bf51f220c2 to play with locally FWIW May 08 17:02:03 sounds good May 08 17:06:27 RP, you really need to work on not being so verbose in your long logs of commits. :) May 08 17:25:04 rburton: the updates were already pushed May 08 17:25:10 to kraj/master May 08 18:31:09 hey all, I'm receiving a "ParseError in configuration INHERITs: ...". Is there a way to add verbosity to bitbake to determine the precise ParseError? May 08 18:31:26 (-v, -D do not appear to work) May 08 19:00:03 jrsharp_: -DDD ? May 08 19:00:32 yeah, same thing... I tried -D, -DD, -DDD, -DDDD, -DDDDD each May 08 19:01:03 desperate for more output, I tried "-D -D -D -D -D", also May 08 19:01:04 ;) May 08 19:02:19 jrsharp_: is it a custom class? May 08 19:03:48 so, it is the 'machine-overrides-extender.bbclass' from the meta-freescale repo May 08 19:04:01 using the 'morty' branch May 08 19:07:46 jrsharp_: related? https://groups.google.com/a/lists.mender.io/forum/#!topic/mender/I7dsq385bYY May 08 19:08:04 RP, rburton: are patches being accepted for 2.4 on master yet, or has it not yet diverged from pyro? May 08 19:11:40 kergoth: we were discussing this on friday and we're about to branch. master-next has stuff in, and i have another ~80 or so patches queued. May 08 19:12:14 marka: maybe? hard to say... it's related to the imx, for sure, and yes, I suspect it's related to a variable that's not being set properly... I was hoping for some way to add debugging output in order to determine what the missing var might be May 08 19:14:01 whenever I have run into similar issues I haven't been able to rely on logging, just do what you can to get isolate conquor May 08 19:14:46 is it a specific recipe throwing the error, you can potentially devshell into the recipe and run the failing task by hand from the temp/ dir May 08 19:15:15 I don't even know how to isolate to a specific recipe May 08 19:15:41 so this happens right at parse time? I suppose that makes sense May 08 19:16:01 yeah... it's happening up front, I think May 08 19:16:11 dump your bblayers.conf in a pastebin May 08 19:17:44 jrsharp_: always worthwhile to try out master if at all possible May 08 19:18:07 if only to see if you are attempting to fix something that is already fixed May 08 19:18:43 yeah... I think the vendor in this case has only recenly released support for morty... May 08 19:19:13 I updated to morty in part to address issues in build that I have attributed to my Ubuntu 17.04 build machine May 08 19:19:34 and was hopeful that the OE/yocto base parts had been updated to support 17.04 in morty May 08 19:22:13 I assume there is a filename as part of the "..." in your "ParseError in configuration INHERITs: ..." May 08 19:25:29 jrsharp_: in the d.getVar(X,Y) function call, not sure if currently the boolean Y is needed May 08 19:28:57 jrsharp_: I mean, there is no need to use the Y argument, which is True in that bbclass May 08 19:29:04 try removing it May 08 19:29:27 ok, I will try... May 08 19:33:46 vm_: is URL now alive? May 08 20:18:29 thanks all! with your hints, it looks like I was able to sort this out... May 08 20:25:03 lsandov: no its not working May 08 20:27:28 vm_: ok, I wonder if there are mirrors for that repo May 08 20:27:40 jrsharp_: which was the issue? May 08 20:28:55 heh, me. ;) the older (deprecated) meta-fsl-arm repo was being referenced somehow May 08 20:29:21 so, both meta-fsl-arm and meta-freescale layers were being included somehow May 08 20:29:24 jrsharp_: got it. well the s/fsl/nxp/qualcomm is confusing May 08 20:30:07 yeah... I'm still picking up yocto... have always used buildroot in past May 08 20:33:07 lsandov: should it work? May 08 20:33:40 vm_: i think so May 08 20:35:15 lsandov: did otavio said that? it still does not work May 08 20:35:57 vm_: I have not talked to him since this morning :( May 08 20:36:08 so, better to send a email to the proper mailing list May 08 20:37:11 lsandov: if it does not work in some hours i will try that, thx for your help May 08 20:37:43 vm_: ok **** ENDING LOGGING AT Tue May 09 03:00:01 2017