**** BEGIN LOGGING AT Mon Sep 12 02:59:58 2016 Sep 12 06:01:12 Hey guys, quick question. If I make any code change to a "project" and call bitbake core-image-minimal or bitbake project it won't recompile, I have to execute a cleansstate on the project to get it recompiled. Is this normal or am I doing something wrong? Sep 12 06:16:39 flitjes: are you using AUTOREV? Sep 12 06:17:45 otherwise, you'd change SRCREV to point to the new version. that'd cause the recipe to be rebuilt. Sep 12 06:18:20 if you're using AUTOREV, then see the last paragraph of http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-AUTOREV Sep 12 06:18:47 imo, the documentation should have explained why it needs to be in PV, but i think that's required for it to get automatically rebuilt at least Sep 12 06:19:15 ${SRCPV} that is Sep 12 06:25:27 sleep time now though Sep 12 08:29:45 meh, why is poky adding a -use-binary-wrapper to g-ir-scanner? Sep 12 08:30:08 it breaks on my machine, with scanner not recognising this option Sep 12 08:31:27 because GIR and cross compilation are fundamentally incompatible, so there's hopefully invisible patches Sep 12 08:31:30 * zeenix tries a `bitbake -c cleansstate gobject-introspection` Sep 12 08:32:04 yup, that helped Sep 12 10:39:26 anyone seen this while building bluez? http://paste.fedoraproject.org/427128/47367674/ Sep 12 10:40:27 Ulfalizer: thnx I'll look in to it Sep 12 10:42:04 this patch works for my debian-using colleague but not me: http://paste.fedoraproject.org/427129/76902147/ Sep 12 11:11:42 hmm.. now poky/krogoth's patches to dbus don't apply possibly because of conflict with patches from meta-ivi :( Sep 12 11:41:58 hmm.. meta-ivi's master branch seems to be for jethro :( Sep 12 12:07:37 rburton, i'm guessing jethrow is not the branch fedora folks use? Sep 12 12:12:33 ERROR: ParseError at /home/zeenix/pelux/sources/meta-openembedded/meta-oe/recipes-support/maliit/maliit-plugins_git.bb:7: Could not inherit file classes/qt4x11.bbclass Sep 12 12:13:08 remember to match up your branches Sep 12 12:13:31 ie you probably forgot to switch meta-oe and/or meta-qt4 Sep 12 12:13:35 ah yes Sep 12 12:14:04 i switched back to krogoth in poky and forgot to do so in meta-oe Sep 12 12:56:54 oh where is jku when you need him Sep 12 12:57:01 ah, he just quit Sep 12 13:00:21 | make[4]: *** No rule to make target 'GdkPixbuf-2.0.typelib', needed by 'all-am'. Stop. Sep 12 13:00:21 | make[4]: *** Waiting for unfinished jobs.... Sep 12 13:00:21 | make[4]: Leaving directory '/home/zeenix/pelux/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.32.3-r0/build/gdk-pixbuf' Sep 12 13:00:27 rburton, seen this? Sep 12 13:01:05 nope. decided to do GI for some reason. what release? Sep 12 13:03:21 rburton, version of? it's krogoth branch Sep 12 13:05:34 so gdk-pixbuf inherits gobject-introspection which passes —disable-introspection in native builds Sep 12 13:07:00 hm looks like krogoth's g-i support doesn't blanklet disable it for native builds Sep 12 13:07:31 cherry-pick be18364edd5cd2c664f68120063a1e147563faab Sep 12 13:07:43 (1b71c59b12301a6d4816bf1d8659db3060870b63 if you have a poky clone) Sep 12 13:08:54 makes sense.. Sep 12 13:09:24 (if that fixes, you can submit it to the stable branch by sending that commit rebased to krogoth to the list with [krogoth] in the subject Sep 12 13:09:48 will do Sep 12 13:22:44 rburton, it works! Sep 12 13:22:54 rburton, which list i shoudl be sending to? Sep 12 13:23:13 zeenix: oe-core@lists.openembedded.org Sep 12 13:29:49 rburton: does that shortened form work? Sep 12 13:30:11 openembedded-core@lists.openembedded.org Sep 12 13:32:54 erm, no Sep 12 13:32:55 sorry Sep 12 13:33:05 i was going to put oe-core@ for conciseness Sep 12 13:41:28 I just noticed something. In lib/oe/package_manager.py, the system now makes a local copy of the RPMs into the workdir and then runs smart and rpm against that. (including package signing and everything else). I no longer see any way to sign the packages, or update the index of the packages in the 'deploy/rpms' directory. Am I missing something? Sep 12 13:41:38 the problem is it's now suddenly much harder to setup a remote feed Sep 12 13:41:42 ist there a variable to reference the native sysroot? like PKG_CONFIG_SYSROOT_DIR references the target sysroot? Sep 12 13:58:02 ahh forgot about package-index -- however that doesn't seem to work Sep 12 13:58:24 tells me there are no packages in the directory, it never went into the individual arch folders and generated the index.. :/ Sep 12 14:01:06 rburton, patch sent Sep 12 14:08:21 i want to create a package that just specifies dependencies. (that would be a meta package in normal yum/rpm). Yocto creates a foobar-dev rpm. The foobar-dev rpm has a dependency on foobar which does not exist. Sep 12 14:09:04 * fray opned bug 10258 Sep 12 14:09:05 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10258 normal, Undecided, ---, mark.hatle, NEW , bitbake package-index does not work with 'rpm' Sep 12 15:31:58 Is there an easy way to find out where a particular task is defined? I have a task that is failing and I would like to look at the source and attempt to debug Sep 12 15:37:12 a1cypher: what task is it? standard tasks like do_compile, etc., are defined in base.bbclass or one of the classes it inherits. other tasks would come from bblasses you inherit via INHERIT or in the recipe. Sep 12 15:37:39 you can search for the task in the output of bitbake -e. its source will be listed there. Sep 12 15:38:02 then you could grep for a part of that source to see where it's defined. might be in meta/classes for example. Sep 12 15:38:21 bit roundabout. bitbake -e doesn't seem to give locations for functions though. just the source. :/ Sep 12 15:38:57 Ulfalizer: its do_image_sdcard Sep 12 15:48:04 a1cypher: looks like it's in the meta-freescale layer. it's a bit tricky to search for, because it's defined using IMAGE_*_sdcard variables. Sep 12 15:48:40 you want to look at meta-freescale/classes/image_types_fsl.bbclass Sep 12 15:48:49 search for _sdcard in there Sep 12 15:53:28 ok, thanks. I'll go look in there Sep 12 15:56:39 btw, the 2.2 versions of the manuals have quite a lot of new information, in case you're reading 2.1 Sep 12 16:20:46 does bitbake cache tasks? Ie, if I change the code by adding some bbnote lines will the new bbclass be immediately active or do I have to flush some cache somewhere? Sep 12 16:23:06 it'll realize the task needs to be rerun automatically Sep 12 16:27:09 Ok, this is behaving strangely then. I added a note to the IMAGE_CMD_sdcard cmd in image_types_fsl.bbclass and then when I do bitbake core-image-full-cmdline -e and look through for the do_image_sdcard function I see the old source without my bbnote in it Sep 12 16:28:43 nm. figured it out. I have meta-fsl-arm and meta-freescale maybe two copies of the same thing. the one thats executing is meta-fsl-arm Sep 12 16:30:19 Hi. Has there been a change in how MACHINE_OVERRIDES is built? Not using SOC_FAMILY perhaps? Sep 12 16:32:14 arkver: you can search for MACHINE_OVERRIDES in the output of bitbake -e to check. before the line that lists the value of the variable, there's comments explaining how it got that value. Sep 12 16:39:24 Thanks. I think I need to check out krogoth and try it there since master is suddenly not finding my machine in the recipe for firmware-imx. I just did a repo sync & blew away my old tmp dir unfortunately. Sep 12 17:13:46 wow, that autoreconf-include patch that was removed due to being upstreamed had been in the oe repo since 2004 Sep 12 17:18:38 Hello! Sep 12 17:20:10 I am building a rootfs image using yocto, but when I generate the SDK (-c populate_sdk) I get OpenCV but not OpenCVConfig.cmake (needed for CMake use) Sep 12 17:20:32 OIN the gerenerated image (not SDK) I get this file, but not on SDK Sep 12 17:20:39 *On Sep 12 17:23:56 it exists on "./out-glibc/sysroots/apalis-t30/usr/share/OpenCV/OpenCVConfig.cmake" but not on /usr/local/oecore-x86_64/sysroots/apalis-t30/usr/share/OpenCV/ Sep 12 17:38:48 LeoB: TOOLCHAIN_TARGET_TASK lists the target (for the machine you're building for) packages that get installed into the SDK. i'm not familiar with how the standard poky distribution sets things up, but maybe you can trace it out from there. Sep 12 17:39:16 it's something that ought to be documented though, because it's really basic. the manuals have strange holes sometimes. Sep 12 17:40:14 https://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-TOOLCHAIN_TARGET_TASK Sep 12 17:42:37 i meant poky's setup, with the packagegroups it uses Sep 12 17:42:58 just two mentions of TOOLCHAIN_TARGET_TASK in the development and reference manuals is pretty silly too Sep 12 17:43:04 maybe i'll get around to it later Sep 12 17:43:30 hello, I've been getting a sanity test error in my build but I am unable to find any documentation on what this is. Can someone explain? Sep 12 17:44:09 nisha: which one is it? Sep 12 17:46:09 Ulfalizer, the error message looks like this: ERROR: qtivi-extension-wrapper-v3-git-r0 do_populate_sysroot: QA Issue: JLRVehicleFunctions.pc failed sanity test (tmpdir) in path /mnt/build/c1c8666e3485664ca3f10aabc52c6bc28e451d67/cascadia-image-hmi-intel-corei7-64-debug/tmp/work/corei7-64-cascadia-linux/qtivi-extension-wrapper-v3/git-r0/sysroot-destdir/usr/lib/pkgconfig [pkgconfig] Sep 12 17:46:59 so do_populate? Sep 12 17:48:10 nisha: search for "failed sanity test (tmpdir)" in the reference manual. there's an explanation there. Sep 12 17:49:13 Ulfalizer, thanks! Sep 12 17:49:41 you're including too much stuff in the paths in the .pc file. they should not include the sysroot path. Sep 12 17:49:44 np Sep 12 18:22:49 Krogoth adds SOC_FAMILY into MACHINEOVERRIDES when including soc-family.inc, which is included from imx-base.inc Sep 12 18:23:43 Master does not, and appears to create a lot of target specific MACHINEOVERRIDES_EXTENDER_* variables. Still digging to see where this came from and what I'm missing in my machine's conf. Sep 12 18:28:18 ok, so Krogoth's imx6 machine confs (eg. imx6dlsabresd.conf) has SOC_FAMILY, like this Sep 12 18:28:26 SOC_FAMILY = "mx6:mx6dl" Sep 12 18:28:39 Master just does this... Sep 12 18:28:42 MACHINEOVERRIDES =. "mx6:mx6dl:" Sep 12 18:29:20 So I guess the mechanism has changed and meta-fsl-arm at least no longer uses SOC_FAMILY. Hey ho. Sep 12 18:39:03 arkver: you probably already have it figured out, but i extended the *OVERRIDES variable descriptions a lot recently btw: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-OVERRIDES Sep 12 18:45:36 Yeah, thanks. I'll read the updated docs. Sep 12 18:45:40 Here, fyi... Sep 12 18:45:44 https://github.com/Freescale/meta-fsl-arm/commit/90c00bba1ce3d3df78138c146323c7244099aa26 Sep 12 18:46:35 That'll teach me to read the commit logs before I update my work area. :) Sep 12 18:51:14 it's nice that they're trying to make it simpler to understand at least. i appreciate the sentiment. Sep 12 19:02:54 Indeed. And just for the record, here's Otavio's patch series... Sep 12 19:03:04 https://lists.yoctoproject.org/pipermail/meta-freescale/2016-September/019045.html Sep 12 19:06:34 so using a SRCREV_FORMAT like 'foo_foo-pkg' breaks things because '_' isn't actually used to split things, all possible subsitution is done. Which means that using names which are substrings of other names probably shouldn't be allowed. Sep 12 19:07:14 I'm noting this because I just ran into an interesting bug where sometimes XXXXX_XXXXX-pkg is used and sometimes XXXXX_YYYYYY is used for the same recipe. Sep 12 19:13:34 Ulfalizer, so to add a package to a sdk I need to do more than add it to "IMAGE_INSTALL_append" on local.conf Sep 12 19:14:20 this TOOLCHAIN_TARGET_TASK variable, can I change it from local.conf? Sep 12 19:14:28 jmesmon: I've seen the same thing recently, and unfortunately SRCREV_FORMAT's behavior isn't defined, so it's being used with both _ and - as separator Sep 12 19:14:44 LeoB: yup, IMAGE_INSTALL is for the image. TOOLCHAIN_TARGET_TASK_append should work though. Sep 12 19:14:59 thank you! Sep 12 19:15:38 neverpanic: yep, the code in bitbake doesn't actually treat anything as a seperator, and the docs, while suggesting an example using '_' as a seperator, never call it a seperator. Sep 12 19:15:40 LeoB: might help to know how variable scopes work btw. see the note in http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values. Sep 12 19:16:50 jmesmon: the code is in get_srcrev() in bitbake/lib/bb/fetch2/__init__.py btw. maybe it could be fixed to split on '_' instead. that's be an improvement at least. Sep 12 19:17:14 it just does format = format.replace(name, rev) at the moment Sep 12 19:17:20 yep Sep 12 19:17:29 another separator like ':' would've been better though, because that can't appear in names :/ Sep 12 19:17:35 but too late i guess Sep 12 19:18:06 Can ':' appear in PV, though? SRCREV_FORMAT needs to generate a PV. Sep 12 19:18:27 i meant having it replace the ':' by something else later Sep 12 19:18:39 Ulfalizer: The problem with changing it now is that you either keep having the same problem because you need to replace substrings, or you break the recipes that use '-' Sep 12 19:18:42 kinda loses some flexibility though Sep 12 19:18:43 I guess one could sanitize it prior to handing it back from get_srcrev Sep 12 19:18:53 neverpanic: yeah, "but too late i guess" Sep 12 19:19:49 jmesmon: it could also replace the longest matches first. bit hackish, but that solves your problem at least. Sep 12 19:21:12 that's an interesting idea. Would there be any common cases not covered by that? Sep 12 19:21:53 can't think of any. it'd probably do "what you expect" in ambiguous cases. Sep 12 19:22:32 guess you could run into trouble if stuff expand to other stuff that then matches some name, but you could probably work around that Sep 12 19:23:09 the current version might have that problem too Sep 12 19:23:47 haha, yep. If somehow the name & the srcrev prefix happen to be the same... Sep 12 19:24:14 I don't think that would happen, unless you name your source like a revision number or git commit hash Sep 12 19:24:42 (which I'd consider a case of "doctor, it hurts when I do this") Sep 12 19:25:31 best would've been something like "%foo%_%bar%" instead of the current "foo_bar". then it'd be both flexible and much safer. but too late... Sep 12 19:25:48 sure, it's unlikely. but if the length is correct, it's possible to get collisions on the 8 characters or so used for the hash. Sep 12 19:26:42 Ulfalizer: or "{foo}_{bar}" so it matches python format strings. Could then lean on .format() to do the substr Sep 12 19:26:48 s/substr/subst/ Sep 12 19:26:53 yeah, works too Sep 12 19:33:01 jmesmon: names_sorted_by_len = sorted(ud.names, key=len) Sep 12 19:33:08 for name in names_sorted_by_len: Sep 12 19:33:09 ... Sep 12 19:33:16 i think that would be a reasonable patch to submit Sep 12 19:33:23 along with a comment that explains why they're sorted by len Sep 12 19:33:44 hmm, maybe i sorted it in the wrong order there, but you get the idea :P Sep 12 19:34:19 names_sorted_by_len = sorted(ud.names, key=len, reverse=True) seems to work Sep 12 19:35:12 or just for name in sorted(ud.names, key=len, reverse=True): Sep 12 19:47:31 jmesmon: i could submit that patch if you don't feel like it. just let me know. Sep 12 19:48:16 Ulfalizer: it sounds like you've already got one together, so if you'd like to submit it feel free. (I've already worked around this locally by adjusting my `name`s). Sep 12 19:48:31 Ulfalizer: If you'd like you can CC me: Cody P Schafer Sep 12 19:49:02 ok, will do Sep 12 20:18:45 hmm Sep 12 20:23:55 hmm, bitbake doesn't respond well to event handlers raising exceptions, we should work on that Sep 12 20:24:16 File "/scratch/dogwood/pdk-licensing/poky/bitbake/lib/bb/ui/uihelper.py", line 48, in Sep 12 20:24:16 eventHandler Sep 12 20:24:16 del self.running_tasks[event.pid] Sep 12 20:31:00 Ulfalizer, using -e i found out that _append is working. (i.e. TOOLCHAIN_TARGET_TASK gets opencv and cmake at the end) Sep 12 20:31:12 but still no .cmake file Sep 12 20:32:17 on the installed sdk. Sep 12 20:35:39 LeoB: to get the .cmake file, you probably need to add the -dev package to TOOLCHAIN_TARGET_TASK Sep 12 20:36:26 the -dev package depends on the base package by default, so you'll get that too if you just add the -dev package Sep 12 20:37:32 LeoB: take a look at http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#viewing-package-information-with-oe-pkgdata-util too for an easy way to see what files are in what packages Sep 12 20:40:42 kergoth: in get_srcrev() in bitbake/lib/bb/fetch2/__init__.py, what does len(urldata[scms[0]].names) represent? would it only be larger than one if you specify the same repository more than once, with different names? Sep 12 20:41:41 that's the case where multiple names/branches/srcrevs are specified for a single url, afaik Sep 12 20:41:50 i.e. ;name=foo,bar;branch=alpha,beta Sep 12 20:42:02 ok, that's what i thought. thanks. Sep 12 20:42:49 not very common. iirc it used to be used in older linux-yocto kernels, nowadays there are two repositories with different names instead Sep 12 20:43:01 * kergoth had to deal with this when working on shallow Sep 12 20:44:35 RP: does FILE not work as expected during the parse of a bbclass? I just added a class to INHERIT, did a := on ${FILE}. and the result is the absolute path to bblayers.conf.. Sep 12 20:57:15 kergoth: I was talking with fray about this recently who ran into it. It seems FILE isn't updated during class parsing Sep 12 20:57:23 kergoth: it always seems to have done this, I don't know why Sep 12 20:57:39 kergoth: Its not something that particularly makes sense to me Sep 12 20:58:04 huh, strange. iirc the logic is straightforward, it's set when the parsing of a file starts Sep 12 20:58:11 * kergoth adds a note to investigate at some point Sep 12 20:58:17 not exactly a priority :) Sep 12 20:58:56 kergoth: http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/parse/parse_py/BBHandler.py#n141 Sep 12 20:59:06 kergoth: I know where it does it, why though... Sep 12 21:00:07 kergoth: I have been tempted to remove it before... Sep 12 21:01:11 that's strange. i'm guessing maybe it didn't want to screw up the value of FILE in the recipe, but it wouldn't anyway since we keep track of the 'old' value Sep 12 21:01:13 Ulfalizer, thank you! I learned a lot today! Sep 12 21:01:14 * kergoth shrugs, not a clue Sep 12 21:02:06 kergoth: its not been annoying enough that I've run the risk of removing it Sep 12 21:03:20 indeed, fair enough Sep 12 21:03:25 maybe something to try right after a release Sep 12 21:05:28 kergoth: along with getVar defaulting to expand :) Sep 12 21:05:50 indeed Sep 12 21:06:23 you know what i'll like about that change.. dict access being more useful. d.get("SOME_VAR", "DEFAULT_VALUE") would actually be of use Sep 12 21:06:34 s/dict/mapping/ Sep 12 21:07:38 kergoth: been working towards it for a while :) Sep 12 21:08:25 RP: you see the change to use compact dict in python 3.6? pretty interesting Sep 12 21:10:15 kergoth: I haven't seen that, no Sep 12 21:10:31 https://mail.python.org/pipermail/python-dev/2016-September/146327.html Sep 12 21:10:38 kergoth: I get kind of sad I'm so buried in the here and now I don't get to see things like this :/ Sep 12 21:13:11 kergoth: that is quite interesting. Its nice to think we can benefit from 3.x features at some point :) Sep 12 21:14:53 indeed Sep 12 21:16:39 I wonder (time scale wise) when we can finally expect that to be available in the python3 on various hosts... Sep 12 21:32:32 fray: don't depress me please ;-) Sep 12 22:11:56 <_markfeatherston> I'm having trouble with glibc locales on the krogoth branch. "glibc-locale: 815 installed and not shipped files. [installed-vs-shipped]". Could anyone point me in the right direction for debugging this? I'm trying to understand how to see what packages are created from PACKAGES_DYNAMIC. Sep 12 22:19:33 read the glibc-locale recipe to start with.. Sep 12 23:00:16 <_markfeatherston> I have definitely done that, but I haven't worked on a recipe quite as complex Sep 12 23:01:02 <_markfeatherston> I just reproduced this with a slightly simpler build - adding DISTRO_FEATURES "x11 opengl" and building core-image-sato reproduces the same problem. Sep 12 23:09:39 _markfeatherston: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#viewing-package-information-with-oe-pkgdata-util might be helpful to see what packages get built Sep 12 23:10:04 if you look in image/ instead of packages-split/, you can see what files get installed by do_install Sep 12 23:10:19 (it's ${D}) Sep 12 23:13:37 <_markfeatherston> Thanks, I'll look into that **** ENDING LOGGING AT Tue Sep 13 02:59:57 2016