**** BEGIN LOGGING AT Fri Nov 11 03:00:01 2016 Nov 11 05:07:50 So just curious, what is the general expectation of compatibility with regards to running Yocto/OE/Poky on RHEL 6.x (which has a 2.6.32 kernel)? Nov 11 06:13:30 nrossi: IITC there was some check that the build system is at least on 3.0, but i might be mistaken Nov 11 06:13:44 IIRC, even Nov 11 06:15:13 LetoThe2nd: I was able to build without it complaining (oe-core master + poky distro), but the qemu recipe is broken. Just wanted to known whether it is actually incompatible rather than just broken. Nov 11 06:18:18 nrossi: ah ok. sorry, no in-depth knowledge here on my side Nov 11 08:50:45 any idea where partitioning configuration is done? I want to increase my root partition Nov 11 08:53:27 aV_V: How are you building the disk image? IMAGE_FSTYPES, wic, etc? Nov 11 08:54:37 nrossi: IMAGE_FSTYPES = "sdcard tar.xz" Nov 11 08:55:58 aV_V: are you using a bsp layer like meta-fsl-arm? Nov 11 08:56:11 nrossi: yes Nov 11 08:56:33 I also have a bootscr script Nov 11 08:56:53 aV_V: if you just want to increase the free space left on the rootfs look at IMAGE_ROOTFS_EXTRA_SPACE (and maybe IMAGE_OVERHEAD_FACTOR) Nov 11 08:56:56 I'm looking at it but here are no size parameters Nov 11 08:57:23 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE Nov 11 08:59:14 aV_V: sure if that applies to the sdcard imagefstype, looks like it does use "ROOTFS_SIZE" though so might work (http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/image_types_fsl.bbclass#n173) Nov 11 08:59:26 s/sure/not sure/ Nov 11 09:06:55 nrossi: I think that should work fine , image.bbclass calculates that based on all the configuration Nov 11 09:08:09 jku: I'm not familiar with the fsl image types was all :) Nov 11 09:20:03 how can i deal with an autotools based project where out of tree builds are brocken? Nov 11 09:20:25 its an upstream project (i can not just fix the autotools setup) Nov 11 09:20:33 autotools-brokensep Nov 11 09:21:30 JaMa: thanks! Nov 11 09:32:55 jku, nrossi: I did IMAGE_OVERHEAD_FACTOR = "1.5" Nov 11 09:33:15 that gave me 50% extra free space Nov 11 09:33:31 thank you Nov 11 12:56:13 hi Nov 11 12:59:34 I'm trying to provide a kernel update using opkg. I set up a repo and I can install and upgrade packages from there. but opkg list doesnt show the new kernel version (even though it appears in the inventory on my webpage) Nov 11 13:00:32 maybe I'm looking at the wrong package name Nov 11 13:01:33 looking at kernel-4.4.18_4.4.28, current one is 4.4.13, my guess here is that the "name" is different because bitbake look at version after the _, but is it valid for opkg as well? Nov 11 13:01:42 it doesnt even list the new one Nov 11 13:02:25 how is the real current one name ? Nov 11 13:03:33 what is running the postinstall scripts on the system at first boot? Nov 11 13:04:37 opkg list-installed returns : kernel-4.4.13 - 1:4.4.13+git0+680be5e27a-r0 Nov 11 13:05:06 mathieu_la, so opkg list-upgradable does not show the repo one ? Nov 11 13:05:12 I created a 'postinst' package that includes a few scripts Nov 11 13:05:18 no Nov 11 13:06:20 well ,sorry cant help en-detail here Nov 11 13:06:34 rburton: the patch isn't as simple as sed/readdir_r/readdir/ btw Nov 11 13:07:54 Hello, I'm building with cmake and yocto. Now i have to add some CMAKE variable on the yocto build process Nov 11 13:07:58 How i can do that ? Nov 11 13:08:16 maybe it's on the server. I'll try to build new versions of other packages as well and see what happens Nov 11 13:08:53 with the EXTRA_OE_CMAKE var ? Nov 11 13:09:31 also your recipe need to inherit cmake Nov 11 13:10:17 EXTRA_OECMAKE += "-Dtest_DIR=blub" Nov 11 13:10:20 I tried this Nov 11 13:12:37 this should work or? Nov 11 13:13:16 I guess so yes Nov 11 13:15:10 rburton: oh and i'm try to find out what enables Werror but haven't succeeded so far Nov 11 13:15:39 rburton: is it possible there is some yocto-specific flag to enable that and i'm grepping for the wrong thing? Nov 11 13:15:41 zeenix: it may be the upstream makefile being stupid but i'd be surprised if we hadn't seen it already Nov 11 13:24:51 zeenix: so which recipe was this actually? Nov 11 13:25:59 jku: nss Nov 11 13:26:10 jku: i get it when building it native Nov 11 13:27:32 apparently it's build system has some magic code for deciding Werror or not unless NSS_ENABLE_WERROR is defined Nov 11 13:27:44 * zeenix is grepping for NSS_ENABLE_WERROR if some recipe sets it Nov 11 13:29:29 ah Nov 11 13:29:49 if i understand the script correct, nss itself set it if gcc >= 4.8 Nov 11 13:30:57 zeenix: it's possible we don't use nss for much anything, so it might just be upstream defaulting to something stupid... Nov 11 13:31:20 that seems to be the case Nov 11 13:35:24 yep, quick search says the only thing that depends on it is lsb packagegroup Nov 11 14:07:22 I'm getting some warnings about "Unable to export ... expression was ... which triggered exception ...", is there a way to see the exception backtrace in these cases so I can track down the source? Nov 11 15:06:08 RP: ping Nov 11 15:10:00 kergoth: pong Nov 11 15:11:37 RP: I just noticed that, with BB_NO_NETWORK, an attempt to contact upstream in PREMIRRORS immediately halts mirror processing, even if there are *local* mirrors after the upstream ones. thoughts on doing something about that, i.e. postponing the error propogation until the end of mirror processing, only aborting on the attempt to contact upstream if we couldn't get it via any other means? alternatively, reordering premirrors only with respect to file:// Nov 11 15:11:38 vs non-file:// and only when BB_NO_NETWORK is set? Nov 11 15:11:58 just looking for a quick opinion on the idea before i open a bug Nov 11 15:12:23 aborting the fetch when i have the file somewhere on disk is a bit silly :) Nov 11 15:12:29 just due to mirrors ordering Nov 11 15:13:01 kergoth: I'd have thought the error shouldn't be fatal Nov 11 15:13:11 kergoth: only fatal if it couldn't find anything Nov 11 15:13:25 so I guess that means postponing it Nov 11 15:13:46 kergoth: the git handling of PREMIRRORS for existing clones is also tricky with network access :/ Nov 11 15:14:57 yeah, that's a tough one. i wish we knew whether a mirror tarball was better or worse than our current clone Nov 11 15:15:43 okay, i'll open a bug about the premirrors exception handling thing. should be enough to collect up the network access failure(s) and re-raise only if we failed to fetch, i expect. thanks Nov 11 15:18:57 I have found what looks like a bug with the DpkgPM, it seems to call the postinst scripts without any arguments, which I think never should happen (should be called with configure argument) Nov 11 15:28:12 btw I found my opkg issue : I guess bitbake updates the package manifest only at image creation, so my Package file was outdated. I updated it with opkg-make-index and now it's fine Nov 11 15:28:54 mathieu_la: there's also a package-index recipe which just wraps the opkg-make-index for you, for that purpose Nov 11 15:30:34 oh nice thanks I'll use that next time, it's safer than the doing manually Nov 11 15:32:48 ecksun: file a bug please (we do say that dpkg is the least-tested backend) Nov 11 15:33:05 rburton, cool, I mostly wanted to discuss with someone that Im correct about it Nov 11 15:33:42 in debian the postinstall script is called with the argument "configure", which is missing from bitbake, which breaks my postinst scripts Nov 11 15:37:12 I will write a patch and send it to the mailinglist now Nov 11 15:37:14 but speaking of patches, I sent a patch earlier to the mailing list, got a positive reply but I dont know what to do next, how do I get it merged? Nov 11 15:40:10 ecksun: it is likely queued or already merged Nov 11 15:40:16 what patch? Nov 11 15:40:43 patches haven't flowed in for a few days due to various "it all breaks with this patch in" problems Nov 11 15:41:04 http://lists.openembedded.org/pipermail/openembedded-core/2016-October/128106.html Nov 11 15:41:42 rburton: did the new V2 musl patch help Nov 11 15:41:55 khem: yes! thanks. Nov 11 15:42:27 there was a pagesize related regression which had caused the crashes Nov 11 15:42:35 ecksun: that was marked here as "need to look at carefully" :) Nov 11 15:43:34 rburton, alright Nov 11 15:43:40 can I see that somehow? Nov 11 15:43:55 ecksun: marked here in that the patch has a star next to it :) Nov 11 15:44:10 ah :D Nov 11 15:44:25 so I just need to have patience then Nov 11 16:00:53 Hi folks, I'm trying to use `bitbake my-image -c populate_sdk_ext` to build an extended sdk, but bitbake appears to be using some other DISTRO (not mine, at least) when it is fetching (???) things in copy_buildsystem, which leads to the build failing. Normal sdk builds without issue. Is there some caveat I need to be aware of wrt the sdk_ext? Nov 11 16:25:44 jmesmon: there is a problem that has just been resolved where if you use uninative on the host it fails when building the sdk, so current master enforces use of uninative as a workaround. Nov 11 16:35:54 rburton: I'm not quite sure I understand: so populate_sdk_ext is setting DISTRO to uninative? Is that only for nativesdk related bitbake targets or all of them? Do I just need to ensure everything for target parses properly with DISTRO=uninative, or does it use some of the target metadata while DISTRO=uninative? Nov 11 17:26:26 is there some test-suite for the poky python code? Nov 11 17:26:44 nvm, found a tests folder Nov 11 17:27:06 doesnt seem to have much though Nov 11 17:28:40 on Beaglebone etc is the clock voltage set in the device tree now or some board specific code? Nov 11 17:29:18 ecksun: fwiw your systemd patch is now in my local branch Nov 11 17:29:40 ecksun: non-trivial to review but fell out the front page of my mail… sorry Nov 11 17:29:58 rburton, cool! Nov 11 17:30:00 no problem Nov 11 17:31:44 I never realized until now that build-time systemctl command is just a shim Nov 11 19:56:59 halstead: are you doing admin on the ab tonight? Nov 11 19:57:34 rburton, Not at the moment. I'm working on testopia issues. Nov 11 19:58:10 halstead: should i be safe to fire a build? or can i ask you to fire one when you're done with yocto admin Nov 11 19:58:10 rburton, It looks like a good time right now. Shall I do it and ping you when it's ready? Nov 11 19:58:47 rburton, How about you go ahead and fire it off. I'll get the work done afterward. Nov 11 19:59:13 ok. it might be a quick run. kill it if you need, it's just a test. Nov 11 20:37:30 I'm trying to boot Yocto on Xen / EC2 and there is no eth0 device. Can anyone suggest what I need to do to enable eth0? thanks Nov 11 22:27:16 Hi all, how can I remove certain package information in sstate-cache? We want to publish sstate-cache for our customer, but we cannot have certain libraries (due to licensing issues) even though they are required during the build. Nov 11 22:39:11 manju: I would think you cold run one of the bitbake clean command against the recipe(s) in question Nov 11 22:39:25 s/cold/could Nov 11 22:40:17 dreyna: yeah i was thinking on same lines probably -c cleansstate on that particular recipe Nov 11 22:42:19 yes that is what i was thinking and have used in the past, when the sstatecache gets out of sync (recipes with untracked changed files). There is also "bitbake -c cleanall package" in the YP documentation Nov 11 22:43:25 .. and also the documented example "bitbake -c cleansstate linux-yocto" Nov 11 22:44:02 at ( http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#build-the-modified-qemu-kernel-image) Nov 11 22:46:22 yep, http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#ref-tasks-cleansstate Nov 11 22:46:24 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-tasks-clean Nov 11 22:46:32 :D Nov 11 22:46:32 manju: cleansstate task, or sstate-cache-management.sh, or manual, depending on what you need to remove Nov 11 22:47:03 +1 Nov 11 23:16:56 kergoth: thanks, sstate-cache-management.sh is what i needed Nov 11 23:17:02 np Nov 12 00:56:37 does anyone have any experience building an image with NVIDIA discrete GPU support? for example 367.57 stable? **** ENDING LOGGING AT Sat Nov 12 03:00:00 2016