**** BEGIN LOGGING AT Mon Jul 21 03:00:00 2014 Jul 21 07:25:56 morning all Jul 21 07:35:59 good morning Jul 21 07:46:12 mood groaning Jul 21 07:47:20 LetoThe2nd: heh Jul 21 12:14:13 It seems 'shadow' is broken. Jul 21 12:14:15 framebuffer fsl-image-machine-test@imx28evk (1/5) | .../build-framebuffer/tmp/work/armv5te-poky-linux-gnueabi/shadow/4.2.1-r0/shadow-4.2.1/libmisc/copydir.c:53:24: fatal error: acl/libacl.h: No such file or directory Jul 21 12:17:05 otavio, there is a fix in master-next I believe Jul 21 12:17:16 kroon: oh let me check Jul 21 12:18:15 kroon: indeed! Jul 21 12:19:23 RP: 'shadow: Add PACKAGECONFIG for acl/attr' seems to address this one. Is it possible to cherry-pick it into master? Jul 21 12:19:28 kroon: thx Jul 21 12:43:19 otavio: the aim is to get it there, yes Jul 21 12:59:33 RP: bluelightning: are you aware of text relocation in libgcrypt? Jul 21 12:59:52 Seems pretty old warning I get on every build Jul 21 12:59:59 ant_work: not specifically no Jul 21 13:00:24 I get it building armv5te and armv4 Jul 21 13:00:41 seen yesterday after git pull Jul 21 13:01:32 bluelightning: http://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028163.html Jul 21 13:01:37 seems upstream issue Jul 21 13:02:38 hmm, not a lot we can do then unless we send them a fix Jul 21 13:08:17 it's strange if you don't get the QA Jul 21 13:10:55 ant_work: I've not done an arm build recently... it would be worth checking the autobuilder logs Jul 21 13:28:06 is there a bitbakte command to just rebuild device tree files of linux kernel? Jul 21 13:33:49 Hi everybody! Jul 21 13:34:31 hi lackS Jul 21 13:34:41 I've got a short question concerning image building, openembedded and bitbake; one of my recipes constantly fails to rebuild. Am I right here to ask for help? Jul 21 13:40:25 lackS: yes, please ask the question Jul 21 13:42:27 or rather, outline the problem Jul 21 13:45:10 I'm trying to build an Image for a Tegra T30 CPU (Toradex Colibri T30), starting with Toradex' example scripts, which work fine. Now I'm trying to adapt their files to my needs; basically, I just added some packages to IMAGE_INSTALL. Some packages (e.g. systemd, wpa-supplicant) fail to build since then. Jul 21 13:45:30 Most problems seem to be related to tries to re-apply already-applied patches. Jul 21 13:46:13 My first approach was a complete rebuild of these packages, e.g. executing "bitbake -c cleanall systemd"; this, unfortunately, does not seem to work. Jul 21 13:46:56 Am I doing something wrong here, or should I execute something else to trigger a complete re-processing of a certain recipe (including download, patching and everything)? Jul 21 13:47:53 cleanall will do that; if that's not working, something is wrong... Jul 21 13:49:50 Is there a possibility to do a full project build reset; keep the toolchain, but re-do everything which is supposed to run on target architecture? Jul 21 13:50:45 I can't see how that will help; from what you're telling me you're rebuilding a recipe effectively from scratch and that's failing; it follows then that if you deleted everything and started from the beginning it would still fail Jul 21 13:51:22 if it's about applying patches, at least Jul 21 13:51:42 I took the (working) meta-toradex folder, copied it over to meta-mine, renamed the needed image recipe and try to build it Jul 21 13:52:22 Does that match your "rebuilding a recipe effectively from scratch"? Jul 21 13:53:23 lackS: hmm... if meta-toradex adds patches to those recipes and you've just made a copy of that entire layer and added it again, that would explain why it's trying to apply patches twice... Jul 21 13:53:53 Oh, good point. So, removing the meta-toradex folder from the layer would probably fix this, right? Jul 21 13:54:51 lackS: yes, but that's not typically how the system is meant to be used - the ideal usage is to add a layer bbappending / replacing / adding just the bits you need rather than copying and modifying the entire layer Jul 21 13:55:16 Seems logic as well :-) Jul 21 13:55:23 that way you avoid a load of rebasing when it comes time to upgrade Jul 21 13:56:01 Good to hear this -- thanks, didn't think of that yet. Jul 21 13:56:50 I'll remove my folder and will try to build a bbappend version instead; this seems to be more reasonable right now, since their working image will just be extended and not stripped as far as I can see right now. Jul 21 13:58:12 although, when customising image recipes I'd say just copy and modify those individually; they tend not to contain anything special other than the list of packages which you usually want to completely customise Jul 21 14:02:11 Ok, copied over the image recipe and wrote a special inc file to suit my additional needs. Jul 21 14:02:31 (which gets required into the new image recipe) Jul 21 14:03:06 By the way, if I want to add a new recipe into an image; is adding it to IMAGE_INSTALL the correct way to include it? Jul 21 14:04:15 technically speaking you add packages to the image (where packages are produced from the recipe) Jul 21 14:05:04 recipes almost always produce more than one package (since there are usually headers, debug symbols, documentation etc. which get packaged separately from the main package) Jul 21 14:05:25 typically the main package for a recipe has the same name as the recipe, though not always Jul 21 14:06:11 And how do I specifially include a certain package into an image? Jul 21 14:09:48 right, I forgot to confirm - yes you use IMAGE_INSTALL to do that Jul 21 14:10:38 Cool, thanks again :-) Jul 21 14:13:20 np Jul 21 14:41:48 bluelightning: Thanks again for your help. The image built as expected :-)) Jul 21 14:42:02 great :) Jul 21 16:33:34 Hi folks - Does anyone know what the minimum kernel version required to use an SDK generated by Yocto 1.6? Context: I've generated an SDK on a machine running Ubuntu 14.04; one of my users has tried to use it on CentOS 6.5 (running 2.6.32) and the packaged tunctl fails with 'FATAL: kernel too old' Jul 21 16:36:15 wotte: I dont think there is definitive answer, since there will be apps which will detect host kernel verison and configure themselves, thats why you use oldest supported distros to generate SDKs Jul 21 16:37:06 khem: Thanks. Is there a recommended distribution/version to use for widest compatibility? Jul 21 16:39:52 khem: hi Jul 21 16:41:45 ant_work: hello Jul 21 16:42:13 wotte: look at the compatible distro list in 1.6 and then use one which is having oldest kernel Jul 21 16:42:19 usually it is one of Centos Jul 21 16:42:31 khem: Thanks very much for your help Jul 21 16:42:40 np Jul 21 16:42:45 khem: about *libc, seen the uclibc-ng desperate fork? Jul 21 16:43:15 khem: time to put efforts on musl? Jul 21 16:45:28 ant_work: havent been peeking at the issues a lot Jul 21 16:46:16 doing other stuff of late getting upto speed again Jul 21 16:46:46 tbh I didn't test uclibc rootfs lately, the size was comparable to eglibc so there was no point Jul 21 16:47:22 ant_work: its still relevant for Nommu systems Jul 21 16:47:31 oh, right Jul 21 16:47:49 but OE doesnt support that config (uclinux) Jul 21 16:49:07 I still use klibc for some specific cases, maybe musl-static will replace that one day Jul 21 16:49:40 ant_work: yes thats possible although musl size is not as compact as klibc Jul 21 16:50:07 klibc got a new release few days ago fwiw, is acttive nowadays Jul 21 16:50:16 I have to update it Jul 21 16:50:42 thats cool Jul 21 16:51:00 but I think we still lack proper naming/handling for static binaries in OE Jul 21 16:51:53 hmm, probably a name alternative would be good I dont know Jul 21 16:51:57 ls.static Jul 21 16:52:03 then symlinked to ls Jul 21 16:52:10 atm klibc.bbclass adds a -klibc suffix Jul 21 16:52:29 for BBCLASSEXTEND'ed recipes Jul 21 16:53:29 thats probably OK we have two properties static'ness is not concerned with which libc is in play Jul 21 16:54:52 the naming issue is apparent while packaging klibc-utils-foo and klibc-utils-foo-static under /tmp-eglibc ;) Jul 21 16:56:26 I can live with it but surely one standardization would be advisable Jul 21 18:13:22 hmm, there are a number of path mismatches in pseudo.logs even in a pure upstream core-image-base, wonder why. /me switches from external to internal toolchain for comparison Jul 21 18:13:35 oh, no, that was internal, okay Jul 21 18:21:22 kergoth -- just from experience, I usually see this when there is some binary that isn't running under pseudo control during the install step.. Jul 21 18:21:34 i.e. a 32-bit binary and there is no 32-bit pseudo wrapper... Jul 21 18:23:28 yeah, thats been my experience as well, but this is a completely stock poky master build not even using an external toolchain Jul 21 18:23:35 its worrisome that any are occurring in this configuration Jul 21 18:24:00 * kergoth hasn't had time to investigate more closely, but wanted to confirm that the errors he' seeing in the mel builds aren't any worse than the stock poky builds :) Jul 21 18:24:12 that shouldn't occur then.. :( not unless something is manually running w/ pseudo disabled.. Jul 21 18:24:19 (or there is a bug.. but we don't have any bugs) ;) Jul 21 18:24:54 hehe Jul 21 18:25:02 * kergoth adds to todo to dig into at some future date Jul 21 18:25:11 yup.. the ever growing list.. :( Jul 21 18:27:05 I can't help but wonder if we shouldn't set up some sort of checks via examining pseudo.log files, either to the metadata as a sanity test or even to automated builds at that level, to keep an eye on these showing up. they hide in the pseudo.log files, easy to miss Jul 21 18:27:08 * kergoth shrugs Jul 21 18:33:57 god from scratch builds are painful, like pulling teeth waiting on those Jul 21 18:34:30 I strongly recommend a dual 12 Core Xeon w/ 8+ GB of ram.. ;) Jul 21 18:34:44 I have this 'target board', which is a builder until needed as a target.. Jul 21 18:34:51 I can do sato in about 25 minutes.. ;) Jul 21 18:35:04 (and this thing has "slow" discs) Jul 21 18:35:40 Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz * 2 w/ HT enabled.. for '48' [virtual] cores Jul 21 18:36:03 64 GB of ram.. Jul 21 18:36:25 it occasionally runs out of memory if I'm doing a multilib build and both sets of toolchain sources build at the same time.. :P Jul 21 18:36:37 (I dropped the -j from 48 to 24 to compensate) Jul 21 18:37:07 'buildstats' also fails on it at times.. and I have no idea why.. turn that off and it's nice and 'fast' Jul 21 18:37:34 [and did I mention the machine is so loud that it sounds like it's going to take off?... which is why it's in the machine room] ;) Jul 21 18:41:31 One downside to full time telecommute, I don't *want* a machine/server room, so don't have a beastly local build box at all anymore. I should set up a slightly slow one just to run overnight builds to prepopulate an sstate mirror Jul 21 18:44:12 $ find build/tmp/work -size +0 -name pseudo.log -print0 | xargs -0 grep -nv /shm/ | cut -d: -f2- | sort -u | wc -l Jul 21 18:44:12 5892 Jul 21 19:13:12 So, I have defined a new minimal cortexa15-based BSP. However, in my deploy directory, I have 2 directories: Jul 21 19:13:42 tmp/deploy/rpm/${MY_ARCH{ and tmp/deploy/rpm/${CC_ARCH} Jul 21 19:13:54 Where CC_ARCH is something like: cortexa15hf_vfp_neon Jul 21 19:14:13 Why isn't everything going under the name of my new arch? Jul 21 19:14:27 (I know my terminology is probably wrong...) Jul 21 19:18:58 Anyone? Jul 21 19:22:21 not all recipes emit binaries which are machine specific. more commonly they'd work fine on any machine using the same tuning Jul 21 19:22:27 so there's no need for them to go in a machine specific area Jul 21 19:23:20 Ah, so this is intentional and not a bug in my BSP.. Jul 21 19:33:50 what is $MY_ARCH Jul 21 19:35:13 packages appear primarily in all-*-* - common across all machines then -*-* common across machine architecture and -*-* which is tragetted for that given machine platform ( e.g. beaglebone ) etc. Jul 21 19:35:53 fray: do you have a bug on the buildstats failure? Jul 21 22:11:13 pidge, not sure if you are still here.. but I just saw your message Jul 21 22:11:50 the buildstat issue is that it's trying to open /proc/ and that fails, causing the rest of the system to fail.. at first we thought maybe it was memory or out of FDs.. but when it fails the FDs are less then 10k in use.. Jul 21 22:11:58 so we're really not sure why it fails, other then it does.. Jul 22 01:56:42 *PACKAGECONFIG Jul 22 01:57:02 ignore that Jul 22 02:33:56 anybody know the impact of ffmpeg 2.3 release vs. libav? **** ENDING LOGGING AT Tue Jul 22 03:00:01 2014