**** BEGIN LOGGING AT Mon Jul 18 02:59:58 2016 Jul 18 07:05:10 Hi. We extend our packages' filenames with a build-id like this: "BUILD_ID = "-1044"; PKGR .= "${BUILD_ID}"; PKGR[vardepsexclude] = "BUILD_ID"". Now we want to do a fresh build but keep all existing packages, if they did not change. So I created a new buildroot (one layer removed) and copied the sstate-cache from the old buildroot. We thought that this would just recreate all unchanged packages from sstate. And I think it did that (t Jul 18 07:05:10 elling me xxx task did not have to be rerun) but all packages got that build's build-id instead of keeping their old ones. Does anybody know a solution for this? Jul 18 07:28:25 I think it basically boils down to the question if we can add a custom variable to the sstate so it used in "do_package_write_ipk" Jul 18 08:15:57 damn, my setup script breaks in krogoth .. Jul 18 09:36:05 Hi Jul 18 09:39:05 When will be the next Yocto release after Krogoth? Jul 18 09:40:33 Krogoth has been release on 04/29/2016. Jul 18 09:40:47 The next one will be in six months? Jul 18 09:41:26 The point is to find out if I will be able to play with Qt5.7. Jul 18 09:42:37 qt5.7 is slated for the next yocto release branch in meta-qt5 Jul 18 09:43:46 CTtpollard, and what is the release cycle of Yocto? Jul 18 09:43:52 6 month right? Jul 18 09:44:13 * Ulfalizer found https://wiki.yoctoproject.org/wiki/Releases Jul 18 09:44:22 2.2 is slated for Oct 2016 I believe Jul 18 09:44:22 says oct 2016. dunno how accurate that is though. Jul 18 09:44:28 so yes, 6 months Jul 18 09:44:45 Is it possible to build Qt5 for qemu? If yes, what recipes are needed for the gfx? Jul 18 09:45:22 yes qt5 support the qemu target Jul 18 09:45:26 thanks! Jul 18 09:46:38 CTtpollard: great! I tried running it, but it got hung up in missing opengl during configure, so I suppose something is missing Jul 18 09:49:35 that schedule is very accurate, we slip by a week at most and generally are on schedule Jul 18 09:52:45 Is it possible to have machine specific DEPENDS and RDEPENDS? E.g. my app depends on libgles2-mx6 for my machine, but apparently is does not make sense on qemu Jul 18 09:54:28 sveinse: DEPENDS_append_ = "dependencies to add for " should work. see OVERRIDES and MACHINEOVERRIDES. Jul 18 09:55:02 oh, and make it " dependencies to add for ", because _append does not add an initial space :P Jul 18 09:56:43 sveinse: OVERRIDES is the high-level mechanism in play. FOO_someoverride is applied only if "someoverride" is in OVERRIDES. Jul 18 09:58:24 sveinse: if the mx6 GL stack is doing the right thing, just add a RDEPENDS on libgles2. that should be RPROVIDEd by libgles2-mx6 and it then works for all machines (as qemu's mesa also provides that same name) Jul 18 09:59:03 rburton: Yeah, let me check. The reason I have it my RDEPEDNS it because the QA check complained about it Jul 18 10:01:14 and its best to depend on a virtual name instead of the BSPs provider of said name too Jul 18 10:04:46 It seems it does Jul 18 10:12:20 Are there any different level in support between qemux86 and qemux86-64? Should I prefer the one over the other? Jul 18 10:12:47 perhaps the x86, as my target HW is 32-bit (arm)? Jul 18 10:13:58 sveinse: you won't want x86 qemu if you're targeting arm Jul 18 10:14:39 there are qemuarm targets Jul 18 10:15:22 CTtpollard: True, but can it emulate 3D in some form to be able to run Qt5? Jul 18 10:15:23 qemux86 is a lot faster to emulate though Jul 18 10:15:38 they'll all emulate software 3d Jul 18 10:15:45 so they'll all be terrible Jul 18 10:15:57 qemux86 will be less terrible, especially if you can turn on KVM Jul 18 10:16:24 Yeah, expect so. Doing a proof of concept is the agenda her Jul 18 10:16:44 personally i'd do that on a real x86 machine Jul 18 10:16:51 emulation sucks Jul 18 10:17:36 +1 Jul 18 10:18:08 Yeah.... I must have an old laptop laying around here somewhere. Jul 18 10:19:27 btw (and while I'm waiting on compile), does any of you know wic? Jul 18 10:20:15 How does it assemble the partitions: does it create the entire disk first and then add partition table and partitions to it afterwards? Jul 18 10:21:07 Point is, we have a custom disk image format that need to add to wic Jul 18 10:46:21 \o/ Jul 18 10:56:18 Can I clean *all* files related to a MACHINE, but retain the others? I've been experimenting with various MACHINES and just ran out of disk.... :( Jul 18 10:58:47 are you sharing sstate & dl_dir with all machines? Jul 18 11:00:07 CTtpollard: Yes, I'm doing them over each others in the same build. Shouldn't of, but that the learning from this... Jul 18 11:00:51 it's common to share between targets Jul 18 11:01:32 about that, is it the sstate-cache dir I can share amongst multiple build dirs? Jul 18 11:04:45 heh, you can really tell that you've got many files when rm -rf takes a minute... Jul 18 11:08:40 sveinse: i think it should be safe. the sstate cache just maps task input hashes to cached task output data. those input hashes should naturally vary between machines. Jul 18 11:09:33 safe as long as it does the proper locking, but i think it does :| Jul 18 11:10:39 * Ulfalizer thinks it would be nice if the docs explained the sstate cache in plainer language Jul 18 11:32:06 * sveinse attempting shared sstate-cache and rather have MACHINE builds in separate build dirs Jul 18 11:38:21 Hi, I am currently working on Smarc-samx6i board developed by KONTRON. and i am using Linux kernel 3.10.17. Now I am trying to interface ft5x06 with my board for that I modified the device tree as I am using git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.28-1.0.0_ga polytouch: edt_ft5x06@39 { compatible = "edt","edt_ft5x06","edt-ft5x06"; reg = <0x39>; pinctrl-names = "default Jul 18 11:39:21 any one can understand what said :-( Jul 18 11:40:20 not really but i also can't see a question Jul 18 11:42:30 i am trying to interface a touch screen ft5x06 for that i used module provided by yocto when i modprobe the module it shows on lsmod command but actually its not probing why that happening? Jul 18 11:43:38 joe_____: i bet the ft5x06 driver is not dtb aware in this version Jul 18 11:44:06 i added the the details in device tree! Jul 18 11:44:24 i said the ft5x06.c is not aware of dtbs Jul 18 11:44:46 srry i got it . Jul 18 11:45:02 Any idea how i can interface it? Jul 18 11:45:17 i had to hack dtb support into it in a 3.14 kernel too Jul 18 11:45:33 any suggestion to improvise that module!! Jul 18 11:45:50 currently i am working on kernel 3.10 Jul 18 11:46:06 either add dtb support in the driver or hack the init in your boardfile .. first is the best solution Jul 18 11:46:33 look at its history in a latest 4.x kernel and cherry pick the dtb stuff Jul 18 11:49:13 when i compile your new version of yocto i am getting this error /yocto_latest/build/tmp/work-shared/smarc-samx6i/kernel-source/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory | compilation terminated. Jul 18 11:50:05 joe_____: http://pastebin.com/y2MyZffH <- this is a backport from a 4.1.y to 3.14 basicly .. Jul 18 11:50:26 how can i over come it! Jul 18 11:52:53 Is there anyone in the Northern Europe/Scandinavian region that offers good Yocto training? Jul 18 13:57:12 can I expand the MACHINE variable in filepaths to .inc files? Jul 18 14:33:52 can you use autorev along with a branch in the src uri to always checkout the tip of said branch? Jul 18 14:34:10 yep. that’s what it does. Jul 18 14:34:28 cheers, and I presume autorev default to master if not declared Jul 18 14:34:40 autorev is no different from any SRCREV in that respect. Jul 18 14:34:48 ty zeddii_home Jul 18 14:37:52 is anyone aware of any an issue of using autorev for src_rev in an inc file? Jul 18 14:38:31 From time to time I get errors such as: "/srv/home/yocto/build/tmp/work/x86_64-linux/uim-native/1.8.6-r0/build/uim/.libs/libuim-scm.so: file not recognized: File truncated". One of the devs here tell me this is known automake issues, and that it happens. To me this smells awfully like a race of some kind. Familiarly to anyone? Jul 18 14:39:39 hmm, perhaps uim doesn't cope too well with parallel make Jul 18 14:47:51 sveinse: but races are so fun.... Jul 18 14:58:30 CTtpollard: yes, you get to see who wins and who loses Jul 18 14:58:43 (and drink beer while doing it) Jul 18 14:59:43 +1 for beer Jul 18 15:02:06 If i'm using autorev, and the package I'm using it with is in sstate, will it ever register new commits? Jul 18 15:02:23 + share dl_dir Jul 18 15:07:16 or does bitbake do_fetch to see if there's a new rev? Jul 18 16:05:28 So messing around with RREPLACES a bit I noticed the package is not rebuilt with the updated directive like I expected Jul 18 16:06:27 Should I have to change PR when doing that? Jul 18 16:09:25 did you set RREPLACES_${PN} etc or just RREPLACES Jul 18 16:11:06 rburton: RREPLACES_${PN} Jul 18 16:11:19 hmshould work Jul 18 16:11:24 actually with a suffix too since it's a split package Jul 18 16:12:13 this is on daisy, btw. Maybe there was a bug? Jul 18 17:04:04 morning all -- any advice on a good way to compile only specific kernel modules (.ko files) with bitbake? Jul 18 17:33:54 wrmyrx: for out-of-tree modules: https://www.yoctoproject.org/docs/1.8.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Jul 18 17:34:40 building a single module from a checkout or unpacked kernel source tree... I don't know. Not sure the recipes are setup for that. Jul 18 17:40:41 Is there a way to conditionally `require` a file in a .conf, using a value from local.conf? Jul 18 17:44:06 Ah, thanks Jul 18 17:44:13 I don't need to compile them on the target or anything Jul 18 17:44:45 I'm fine to just recompile kernel modules on the host device, I know how to patch them and everything... I assume there's some subset of bitbake flags that will trigger the driver build Jul 18 17:45:01 *sorry, not on the host device, on the build server rather than on the target Jul 18 18:15:31 wrmyrx: generally you would update the recipe to have bitbake pick up the changes, but if you've just made some change to try something out, you could try bitbake -c compile my-kernel-recipe -f to force bitbake to recompile it Jul 18 18:16:01 it'll then know that the following steps need to be redone and will do so as needed when you build images or such. Jul 18 18:19:05 I'm a little fuzzy on which step does exactly what, but it will do it for all modules, not a single one Jul 18 18:19:40 bitbake my-kernel-recipe after the -c compile one should package them up for you Jul 18 20:03:23 What DEPENDS is needed to allow compilation of Qt5 on qemux86? Jul 18 20:04:42 I was thinking on depending libgles2 from the image, but, isn't technically a missing depends in Qt5 since it does not get what it needs to be built? Jul 18 20:05:23 Its failing on do_configure with missing -lGL, so it has passed dependency checks for some reason Jul 18 20:23:11 sveinse: do_configure() of which package? Jul 18 20:44:50 Hi. I am having an issue with LibEXIF recipe. It builds both static and dynamic libraries, but only the dynamic ones are getting included in my distro. I am really struggling to figure out the logic behind this. Can somebody help me? Jul 18 20:50:44 Guest77446: there was recently a poky change to pass `--disable-static` (or similar) to all configure scripts by default. Perhaps you want to disable that? Also note that by default static libs will only end up in the -dev package, which typically is in sysroot but not included in the image. Jul 18 20:52:30 Ok. Thank you jmesmon. Do you know roughly when this change was? I am not using the newest version of Poky. Jul 18 20:53:09 is that the reason for this though? static libs get packaged in the -staticdev package and that has been true for a long time Jul 18 20:54:12 I think the second thing you said probably nailed it. I see it in the tmp/work space for LibEXIF. Jul 18 20:54:22 Guest77446: commit in poky is 438d6d6e7d8ca1a9d566bbea5b917a2b00a31f4e , it has a date of Feb, not sure when it was merged. Jul 18 20:55:07 Thank you bluelightning. It is probably as simple as this. I included "libexif" in my IMAGE_INSTALL_append. I will try libexif-staticdev. Jul 18 20:55:23 Thank you for checking on that jmesmon. Jul 18 20:55:43 bluelightning: ya, I'm not realy sold on it either. I suppose someone wanted to try to reduce the number of build artifacts they had Jul 18 20:56:19 jmesmon: it all depends on whether you use static linking; if you don't those artifacts are superfluous Jul 18 20:56:28 jmesmon: speeds up builds if you never use them, static libraries are always huge Jul 18 20:56:37 I hate bugging people with questions like this that I think are straightforward. Is there a good place to read up on this? Jul 18 20:56:57 Guest77446: the documentation at yoctoproject.org, or just remember this is the place to ask questions Jul 18 20:57:15 Guest77446: for this question, not really. I don't think it's documented outside of the source. Jul 18 20:57:23 Guest77446: it's fine, I'm always happy to answer questions here even if they're covered in the manual Jul 18 20:59:11 rburton: my main issue with it is that it presumes all EXTRA_OECONF users support a flag "--disable-static" and has a bunch of exceptions. Not sure if there is a better way to handle it, though. Jul 18 20:59:38 jmesmon: better suggestion welcome (or don't use it, it's only enabled in poky not oe-core) Jul 18 21:00:49 Thank you to all. That was exceptionally helpful. Including libexif-staticdev brought in both the static and dynamic libraries. Curious though, why does it bring in the dynamic libraries? Jul 18 21:01:26 sure, sure. I'm just salty because it broke one of my layers & I had to fix it by providing a DISABLE_STATIC override. Jul 18 21:18:07 Thank you all again. Best regards. Jul 18 21:53:04 halstead: around? Jul 18 21:56:07 rburton: I'm here now. Jul 18 21:56:25 halstead: i think the centos7 machine needs libxml-parser-perl installed Jul 18 21:57:03 i think… do the others have it installed? Jul 18 21:57:17 the debian8 machine i just poked does Jul 18 21:57:58 and f23 Jul 18 21:58:12 rburton: I'll check. Is this a new requirement? Jul 18 21:59:07 halstead: no, which is why i'm confused. intltool is failing in some builds on that machine as xml:parser isn't present Jul 18 22:07:46 rburton, I've added perl-libxml-perl and perl-XML-Parser. To the centos defaults. Is that enough? Jul 18 22:08:32 hope so Jul 18 22:08:34 lets see Jul 18 22:09:01 halstead: live now? Jul 18 22:09:15 rburton, On the centos7 machine yes. Jul 18 22:09:41 I'm looking at the others in a second. Jul 18 22:09:56 in theory the others all have it Jul 18 22:10:54 rburton, Do we need to add these to the yocto quickstart? http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html Jul 18 22:11:01 Or is this specific to the autobuilder. Jul 18 22:14:20 halstead: right now not sure. maybe. :/ Jul 18 22:19:36 Note that there's some weirdness going on with intltool; it has a configure test to find the first perl in $PATH and that one better has XML::Parser installed for the test to pass Jul 18 22:20:16 Funny enough, the version of perl found in this test need not actually be the one in your intltool's shebang, so it might not affect your build at all Jul 18 22:21:45 yeah thats likely the problem, its finding host perl when it shouldn't Jul 18 22:22:03 need to hack that test out i guess Jul 18 22:22:10 for tomorrow, its 2322 now Jul 18 22:22:28 Since you autoreconf everything anyway, may I suggest this path: https://trac.macports.org/browser/trunk/dports/textproc/intltool/files/remove-intltool-perl-hack.patch?rev=107542 Jul 18 22:22:36 s/path/patch/ Jul 18 22:23:03 yes you may :) Jul 18 22:23:05 thanks Jul 18 22:24:11 jmesmon: Of qt5 Jul 18 22:24:20 rburton: that's https://bugs.launchpad.net/intltool/+bug/1197875 for your upstream-status tag, btw. Jul 18 22:25:07 +1 Jul 18 22:26:00 thanks Jul 18 22:43:09 hi guys, there is one patch on poky-contrib, ross/mut for linux-firmware Jul 18 22:43:31 could you give me any estimate on when could it find its way to master? Jul 18 22:43:55 linux-firmware: update to revision cccb6a0da9 Jul 18 22:43:57 that's the patch Jul 19 01:06:39 Xz: hopefully tomorrow **** ENDING LOGGING AT Tue Jul 19 02:59:58 2016