**** BEGIN LOGGING AT Wed Jun 08 02:59:59 2016 Jun 08 05:51:24 which package contains libc.a (libc static library) in yocto? Jun 08 06:04:44 parrot: most likely glibc-staticdev or libc6-staticdev, depending on whether it was renamed or not Jun 08 06:18:02 kergoth: ok. Thanks Jun 08 08:04:34 hello, i can't build webkitgtk 2.10.7 with yocto krogoth on Debian 32b(4GB RAM, 8GB swap) system, i'm getting this msg: "mmap: failed to allocate 2502798416 bytes for output file: Cannot allocate memory". has anybody the same problem? Jun 08 08:05:53 isn't 32b capped at 4GB memory? Jun 08 08:07:00 Not with a PAE kernel Jun 08 08:09:59 i'm on PAE kernel Jun 08 08:13:31 does that allow an extended range for a single process? Jun 08 08:13:51 "The 32-bit size of the virtual address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a https://en.wikipedia.org/wiki/Flat_memory_model) is limited to 4 gigabytes of virtual address space." Jun 08 08:15:59 in short, pae means that the system altogether can use more than 4gb, but any single process is still affected by that limit. Jun 08 08:15:59 That looks like the problem Jun 08 08:16:43 but he's just trying to allocate ~2.5 GB of space right which is less than 4GB? Jun 08 08:17:29 well the 4gb are still brutto, i don't know what is net payload Jun 08 08:17:51 anyways, just another reason to not stick with 32b Jun 08 08:19:58 rburton: yes i set up a webserver hosting all the deb packages now, that works fine. Jun 08 08:20:35 next issue: installing things is not permanent when using a rootfs-image... guess i need to setup a root partition on the sdcard Jun 08 08:20:52 parrot: iitc a single process only has 3gb of the address space, and you may have used 1gb of that already Jun 08 08:22:11 (as the kernel has a gb for itself) Jun 08 08:22:46 especially given that that allocation will try to get 2.5GB in *contiguous* virtual address space Jun 08 08:22:56 yeah Jun 08 08:23:09 but yes, for build machines with stuff like webkit and llvm, 32 bit isn't enough Jun 08 08:23:40 i remember a talk where they showed shaders could not be compiled in 32b space... Jun 08 08:23:51 *some Jun 08 08:31:21 am i correct that IMAGE_FSTYPES = " ... sdcard" is the image i want to create an image i can modify after dd'ing and? Jun 08 08:31:54 i've got the same feeling that mmap won't be able to find 2.5GB free in mine 32b PAE system, so i need to build on 64b, thanks for help :) Jun 08 08:35:32 unfortunately creating a sdcard image results in this: http://stikked.xkonni.de/view/90114872 Jun 08 08:35:50 xkonni: 'sdcard' is not a standard image format, but something that usually comes from the fsl layers Jun 08 08:44:16 so did that work before? did you check that the branches (e.g. poky revisions and the fsl layers) match up? Jun 08 08:46:48 LetoThe2nd: i'm using fsl layers. and i didnt build a sdcard image before. actually i just want something i can e.g. dd to the sdcard, tell uboot to run it, apt-get install packages and keep them when rebooting Jun 08 08:47:13 currently using an u-boot rootfs image. but its loaded in the ram and modifications do not persist Jun 08 08:47:34 xkonni: "i just want" is usually not helpful in debugging stuff ;-) Jun 08 08:48:16 LetoThe2nd: yes right. what i meant is: if there are alternatives to 'sdcard' that match my goals, i would consider using one of those Jun 08 08:48:25 xkonni: so take a step back. did you follow the fsl instructions on how to use and configure their layers? did a vanilla rebuild of their getting started guide succeed? Jun 08 08:48:43 the u-boot image works perfectly Jun 08 08:48:58 so i just added 'sdcard' to the image_fstypes, rebuild, ^^ that error Jun 08 08:49:31 the whole build is based on fsl layers Jun 08 08:49:35 but is that the setup as described by them, or something you came up with yourself? does it carry any modifications? Jun 08 08:49:38 (ls1021atwr) Jun 08 08:50:04 besides the sdcard its pretty close to what they describe Jun 08 08:50:15 you're evading my questions. Jun 08 08:50:22 added some packages, vim, ... and deb package management Jun 08 08:50:27 see. Jun 08 08:50:35 not on purpose, let me try again Jun 08 08:50:42 start over with a clean slate. find out when it breaks. Jun 08 08:51:08 mhhm... and a working build is not a 'clean slate'? Jun 08 08:51:13 and really make sure that all the included layer revisions match up Jun 08 08:51:26 a working build is not a clean slate. Jun 08 08:51:53 ok, so i take a minimal fsl image, build it, add 'sdcard' and build it again? Jun 08 08:51:56 because a working build still might carry modifications that just didn't show their effects yes. Jun 08 08:52:33 exactly. my advice is to get the initial, minimal setup that you were provided, and add absolutely nothing. build it, then add the sdcard fstype, and build again. Jun 08 08:52:51 i thought the problem would be something simple. like exceeding rootfs-size, missing some dependency Jun 08 08:53:11 if that already breaks, you know that you have to look in your upstream. if it works, you have to look in your modification. Jun 08 08:53:39 it also might be that the BSP just doesn't support the sdcard image. Jun 08 08:53:53 which its documentation should tell Jun 08 08:54:14 thats an option, yes... will check the other fsl-image configs Jun 08 08:55:59 though the error tell me its something stupid: Exception: TypeError: cannot concatenate 'str' and 'NoneType' objects Jun 08 08:56:13 e.g. missing "" in a config Jun 08 08:56:52 ... which *might* come from the sdcard setting triggering some function, but the layer not providing sufficient configuration data for your board. Jun 08 08:57:11 possible... ;) Jun 08 08:57:47 taking a first look at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/image_types_fsl.bbclass suggests that the sdcard fstype only makes sense for imx and mxs socs, by the way Jun 08 09:04:31 by the way, if its only about persistency during development, you could also resort to a nfs root file system. but in any case, the process of making your device self-bootable and offering persistent memory should be provided by its documentation, as its highly board implementation specific. Jun 08 09:05:09 found the actual issue... IMAGE_CMD is None for sdcard... Jun 08 09:05:28 and thats most likely, as you said, due to missing options for my platform Jun 08 09:05:51 a.k.a. the layers you have do not support the sdcard image for your platform. Jun 08 09:06:05 right, thats what i wanted to say Jun 08 09:06:33 so see my last post before that conclusion :-) Jun 08 09:06:54 yes i just wanted to support your statement Jun 08 09:07:19 nah, i meant the "by the way..." line :-) Jun 08 09:08:29 nfs might work, but then i dont always have a network. having persistent data on the sdcard would be my favorite option Jun 08 09:08:45 then its RTFM time :-) Jun 08 09:08:47 not necessarily with that sdcard image, there are certainly other options Jun 08 09:09:00 right, the docs are rare on that one though Jun 08 09:09:18 so instead of ls1021a + topic i ended up with yocto + topic Jun 08 09:09:32 then kick your supplier, because that really is board specific. Jun 08 09:09:36 hehe Jun 08 09:10:03 some partner said 'here, use that board, its awesome' Jun 08 09:10:06 so here we are... Jun 08 09:10:20 then kick your partner Jun 08 09:10:22 ;D Jun 08 09:12:23 well i do have the rootfs... i can extract it. guess i just need to tell uboot to use mmc 0:1 instead of the image Jun 08 12:16:05 wasnt that hard after all... once you know that bootm addresses can be skipped with a - Jun 08 12:16:56 http://stikked.xkonni.de/view/37681e1d#L9 just in case Jun 08 13:03:22 hello all Jun 08 13:05:06 I'm using ${DATETIME} in my receipes, and I get some "Taskhash mismatch"..., I would like to know how I could avoid this error Jun 08 13:09:29 this was just discussed on oe-core@ Jun 08 13:11:44 rburton, thanks Jun 08 13:12:13 rburton, if it was for me ;) I will try to see archive Jun 08 13:14:44 When bitbaking a package X some other package Y fails. However when doing "bitbake -g X" and grepping the resulting dot file, there are no packages depending on Y. Why is Y included in the build? Jun 08 13:22:17 rburton, can't find anything where was it discussed? Jun 08 13:27:46 (I found through "bitbake -e X" that Y is included through image_types.bbclass; just trying to find how to remove this dependency) Jun 08 13:28:57 change your image type? Jun 08 13:29:20 (concrete examples are great though) Jun 08 13:31:36 It is based on recipes-graphics/images/core-image-minimal.bb and the problematic package is mtd-utils Jun 08 13:32:56 I'm on the dizzy branch of yocto and there are patches fixing mtd-utils in later branches, so I can try to cherry pick those commits Jun 08 14:01:21 Ended up just doing IMAGE_DEPENDS_ubifs = "" in my image file after the inherit. Not a clean fix, but works Jun 08 14:49:48 is there a proper way to influence variables in .bbclass files or append code to them from a different layer? Jun 08 17:42:12 hi, is anyone here familiar with PRU development using meta-ti? I have problems building ti-cgt-pru package Jun 08 17:42:59 I posted a message on meta-ti list: https://lists.yoctoproject.org/pipermail/meta-ti/2016-June/008636.html Jun 08 17:43:17 but maybe someone here knows how to handle this? Jun 08 18:04:06 hmm Jun 08 18:04:28 seems that execution of ti .bin installer fails Jun 08 18:47:46 ok, the problem was: missing 32bit glibc on build host (which should yield a warning, but somehow I missed it) Jun 08 21:39:22 god i hate having to do world builds for testing Jun 08 21:39:24 take so long Jun 08 21:41:59 kergoth: overnight? Jun 08 21:42:49 how many steps in a world build nowadays?? Jun 08 21:43:12 depends on thel ayers you include :) Jun 08 21:43:36 the one i'm running right now is 24,372 regular tasks after 10,230 setscenes Jun 08 21:43:47 whee! Jun 08 21:44:14 calls for a dual socket xeon or similar. Jun 08 21:45:06 that said, we still bottleneck around some key pkgs leaving a lot of the system idle when that happens. Jun 08 21:55:47 I/O is often a serious bottleneck as well Jun 08 21:56:51 any ideas on how we might optimise things? Jun 08 22:03:46 kergoth, yeah I do all my work on dual disk RAID0. Helps some vs. single disk. Jun 08 22:05:32 bluelightning, I'm not sure if this has been done before, but I was entertaining the idea of identifying "hot" pkgs and ensuring they got preferential treatment in download, unpack, configure etc. Jun 08 22:05:46 i.e. on a per step basis. Jun 08 22:08:51 there is no rush to unpack gnome-icon-themes if we've not unpacked for building perl-native yet. :) Jun 08 22:11:09 the odd time I've looked at a build and seen 5 or more pkgs all in do_package / do_rpm ; that is probably more of an I/O bottleneck than unpacking tho.... Jun 08 22:12:48 paulg: i think bitbake already does its best to do that Jun 08 22:12:48 ...not sure how one would avoid that. Jun 08 22:12:57 bottlenecks are built as early as possible in the task sorting Jun 08 22:13:02 in the scheduler class Jun 08 22:13:30 Good. Then I can scratch that idea off my "should look into that someday" list. :) Jun 08 22:13:32 we've expeirmented with adding weighting based on resource type / availability, i.e. no more than N unpack/patch, etc, but i'm not sure that sort of thing ever went anywhere Jun 08 22:13:54 richard's likely experimented with scheduling optimizations more recently than i, though Jun 08 22:14:06 iirc he did and it didn't really help Jun 08 22:19:30 i had similar results a few years ago when i was playing with it, sadly Jun 08 22:27:47 I wonder if the unpack would get a speed-up of pre-reading the entire pkg instead of interspersing the reads with writes... Jun 08 22:28:14 I did something similar to that for gnu diff some many years ago. Jun 08 22:28:28 https://www.cs.helsinki.fi/linux/linux-kernel/2001-41/0047.html Jun 08 22:28:48 I wonder how the performance is when doing builds on a tmpfs, I think someone was playing with that Jun 08 22:29:12 I've done that on other build systtems but not oe/yocto/bitbake Jun 08 22:29:36 the difference wasn't super huge IIRC. Jun 08 22:30:01 the "rm -rf" once done was however much improved. :-) Jun 08 22:31:37 hehe Jun 08 22:32:21 most useful script i have when doing yocto builds: bgrm. just nohup/disown's backgrounded rm -rf, after first renaming/moving it, so you can immediately start the next build rather than twiddling your thumbs waiting on the rm -rf tmp Jun 08 22:33:33 ya, I do sth similar ; "mv tmp deletmelater ; (sleep 12h ; rm -rf deletemelater) & " Jun 08 22:33:51 if I'm still working in 12h then my life already sucks. Jun 08 22:34:25 and less i/o contention assuming I don't need the space ASAP. Jun 08 22:35:01 generally speaking I try and push everything off a cliff as least often as possible. Jun 08 22:35:13 but it still happens too often. :-/ Jun 08 22:35:51 sadly my remote build vms lack the space to delay the removal very far out :) especially when doing world builds. that's a great idea when you hvae the space, though Jun 08 22:36:04 heh, looking at that old thread, I was testing on what was then a low end machine. Whopping 32MB RAM. Jun 08 22:36:08 https://www.cs.helsinki.fi/linux/linux-kernel/2001-41/0667.html Jun 08 22:36:43 you'd not even stop to pick up a gfx card or router out of the trash with that amt of RAM now. :) Jun 08 22:38:59 Good times. Jun 08 22:41:47 reminds me of being quite happy in 1998 or 1999 because of getting a whopping 64 megabytes of EDO RAM :) Jun 08 22:55:16 Hmm, should make it so a sigterm sent to a sleeping delayed rm -rf causes an immediate rm -rf, in case you reboot while one is pending Jun 08 22:55:20 * kergoth does so **** ENDING LOGGING AT Thu Jun 09 02:59:58 2016