**** BEGIN LOGGING AT Wed Mar 11 02:59:58 2015 Mar 11 09:46:25 morning Mar 11 09:47:35 I'm trying to use Qt 5.4.1 with Yocto 1.4. Can someone make sense of this compile error? -> http://pastebin.com/JsAxCL44 Mar 11 09:53:14 morning all Mar 11 09:53:28 hi mago Mar 11 09:53:30 hi bl Mar 11 09:54:57 gm Mar 11 09:55:15 hi crofton Mar 11 09:55:25 crofton still awake? Mar 11 09:55:32 or in europe again? Mar 11 09:56:16 just woke up Mar 11 09:58:13 hi bluelightning, woglinde, Crofton|work Mar 11 09:58:33 do we have a tiny image viewer like qiv in OE ? Mar 11 10:00:08 woglinde, we also had the DST time thing Mar 11 10:05:18 bitbake fbida Mar 11 10:10:27 mckoan yes Mar 11 10:19:05 woglinde: I used qiv Mar 11 15:12:14 hmm, I'm trying to provide an asound.state in a layer using a bbappend. But it uses the default dummy even though I use FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}" Mar 11 15:12:44 what parameters affect the order of FILESPATH? Mar 11 15:14:31 erbo use bitbake -DDD to see more output and examine the resulting do files in the workdir/temp dir Mar 11 15:46:07 can also use bitbake -e to examine both FILESPATH and FILESEXTRAPATHS and see how they got set the way they are / what modified them Mar 11 16:16:21 kergoth: LICENSE = "A & B" Mar 11 16:20:22 yes? Mar 11 16:28:40 ergoth: for LICENSE field if I have A and B licenses how is relationship expressed Mar 11 16:28:48 kergoth: that was my original message Mar 11 16:29:48 that's how it's expressed. if both apply, AND is the correct relationship. OR is only appropriate if you have a choice of which to use Mar 11 16:30:15 that woudl be A | B Mar 11 16:31:51 FYI: https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management Mar 11 16:44:51 nice Mar 11 18:43:40 guys, I don't seem to get it, what is supposed to be entered in the SSTATE_DUPWHITELIST? the package name or the specific file that was staged? Mar 11 18:46:41 I could not find SSTATE_DUPWHITELIST in Yocto's manual, hence the question... Mar 11 18:53:17 ok never mind, it seems it looks for actual file names, not packages Mar 11 19:05:08 is anyone using RPM4 successfully? I cannot get an image to build when following the instructions in meta-yocto/conf/local.conf.sample.extended Mar 11 19:27:06 mhm could someone help me out with "trying to install files into a shared area" again please? :) I can't figure out what files exactly are supposedly going into a shared area, one package puts everything under /usr, the other one under /www, I unpacked both ipk' and the data tarballs Mar 11 19:27:52 or should I aso check -dev/-doc packages? Mar 11 19:28:29 aem, I mean .dbg Mar 11 19:29:37 -dbg and -dev are empty Mar 11 19:32:40 https://pastebin.mozilla.org/8825342 Mar 11 19:33:05 dss-web recipe provides dss-web and additionally dss-web-module, more or less same contents but in different directories Mar 11 19:33:20 and nothing should be overlapping on the rootfs Mar 11 19:33:31 so what is it complaining about, or rather - how do I figure this out? Mar 11 19:35:23 i'd start with a fresh build directory in case you had remnants of previous work floating around Mar 11 19:35:40 no, it was a clean build but multimachine Mar 11 19:35:50 althouth I cleaned the package for both now Mar 11 19:35:55 and its still failing Mar 11 19:36:04 (clean build as in wiped build dir) Mar 11 19:36:32 it would be helpful if it actually printed the conflicting files Mar 11 19:36:40 well, it looks wrong that your -dev and -dbg packages are armv5t when the rest are all Mar 11 19:36:46 sounds like you didn't inherit allarch? Mar 11 19:36:51 unless i'm missing something Mar 11 19:36:54 good point Mar 11 19:37:05 * kergoth shrugs Mar 11 19:37:07 I'll explain the situation, because you might indeed be right Mar 11 19:37:10 here's the thing Mar 11 19:37:14 the result of the build is allarch Mar 11 19:37:23 but in order to actually do the build some native binaries are compiled Mar 11 19:37:31 when I inherited "allarch" everything broke Mar 11 19:37:34 and did not compile Mar 11 19:37:44 so I set: Mar 11 19:37:44 PACKAGE_ARCH_${PN} = "all" Mar 11 19:37:44 PACKAGE_ARCH_${PN}-module = "all" Mar 11 19:37:51 which, as I understand, probably caused my problem? :) Mar 11 19:38:09 it's built using: Mar 11 19:38:09 EXTRA_OEMAKE = "'CC=${CCACHE} ${BUILD_PREFIX}gcc' 'CXX=${CCACHE} ${BUILD_PREFIX}g++' 'LD=${CCACHE} ${BUILD_PREFIX}ld'" Mar 11 19:39:06 it's actually a web interface but some gettex processing is done in the make step Mar 11 19:39:25 what would be the proper way to handle something like that? Mar 11 19:39:26 i'm guessing the machine changed, which caused the recipe to be rebuilt even though its output ends up the same, so it steps on the other builds of itself for the other machines. so i suspect that indeed caused your problem Mar 11 19:39:35 not sure, though, not an expert on that sort of situation Mar 11 19:40:12 I could probably drop the allarch part Mar 11 19:40:19 and let it be machine dependant Mar 11 19:40:29 it does not really matter I guess, just a cosmetic thing Mar 11 19:40:39 worth trying to see if the error/wraning goes away to see if that's actually the cause, if nothing else Mar 11 19:40:56 ok, thx, let me test that Mar 11 19:46:20 that did not help Mar 11 19:46:27 the -dev/dbg are still arm Mar 11 19:46:31 while the main package is allarch Mar 11 19:46:40 even after me removing the PACKAGE_ARCH statements Mar 11 19:46:59 I could force it $MACHINE_ARCH Mar 11 19:47:01 ? Mar 11 19:50:57 ok, that solves the error Mar 11 19:51:00 but brings the warning: Mar 11 19:51:01 Recipe dss-web is marked as only being architecture specific but seems to have machine specific packages?! The recipe may as well mark itself as machine specific directly. Mar 11 19:51:16 I set: Mar 11 19:51:17 PACKAGE_ARCH_${PN} = "${MACHINE_ARCH}" Mar 11 19:51:17 PACKAGE_ARCH_${PN}-module = "${MACHINE_ARCH}" Mar 11 19:51:32 what exactly is it complaining about? Mar 11 19:51:47 ah Mar 11 19:51:49 I should drop the PN Mar 11 19:51:49 if a recipe has machine specifics, then the recipe has to flagged as machine specific Mar 11 19:51:55 not just the packages Mar 11 19:52:08 i'd drop all PACKAGE_ARCH bits and remove the inherit of allarch, should be fine Mar 11 19:52:20 dunno though, i don't mess with multimachine builds anymore really Mar 11 19:52:52 I tried not messing with arch at all, that produced arm5te for dev/dbg and allarch for the main package Mar 11 19:53:06 the main packgae won't be allarch unless you set it that way or inherited allarch Mar 11 19:53:15 it doesn't magically get that way Mar 11 19:53:17 it did happen though.. I did not have allarch inherited? Mar 11 19:53:39 I thought it would simply go over the contents and mark itself allarch if it did not find any binaries/anything executable? Mar 11 19:54:33 or how else could that happen? I really did remove PACKAGE_ARCH for one test and did not have allarch inherited Mar 11 19:55:18 this combo works without errors or warnings Mar 11 19:55:19 PACKAGE_ARCH = "${MACHINE_ARCH}" Mar 11 19:55:19 PACKAGE_ARCH_${PN}-module = "${MACHINE_ARCH}" Mar 11 19:56:16 probably not *the* correct solution but well, I have no idea what else to try.. Mar 11 20:04:17 afaik allarch is only ever an explicit operation, not automatic or implicit Mar 11 20:04:32 I wonder how it happened then, I may give it another try later on Mar 11 20:17:53 does anyone know what happened to the Angstrom feeds? Mar 11 20:17:54 http://feeds.angstrom-distribution.org/ Mar 11 20:18:51 sorry, should have check Anstrom list first ... Mar 11 20:19:14 looks like they lost a disk, so are in process of rebuilding Mar 11 20:20:13 l8r **** ENDING LOGGING AT Thu Mar 12 02:59:58 2015