**** BEGIN LOGGING AT Tue Oct 04 02:59:58 2011 Oct 04 06:30:27 ERROR: Please set the 'PERSISTENT_DIR Oct 04 06:30:27 any idea? Oct 04 08:13:13 loo: did you post a question about this earlier or is this the first time you have asked, as someone else ran into this error yesterday Oct 04 09:17:39 How would I access: tmp/work/armv5te-poky-linux-gnueabi/php-5.3.6-r8.0/php-5.3.6/ using bitbake variables so that it would work over package versions? Oct 04 09:36:36 Snafflehog: That looks like ${S} ? Oct 04 09:37:27 yep, I just trawled through the poky reference and found it Oct 04 09:37:28 ${S} = ${WORKDIR}/${PN}-${PV} (see bitbake.conf) Oct 04 09:37:52 so I want to install the php config file would this work: Oct 04 09:38:20 install -m 644 ${S}/php.ini-production ${sysdir}/php.ini Oct 04 09:38:28 and that would put php.ini in /etc/php.ini? Oct 04 09:39:17 install -m 644 ${S}/php.ini-production ${sysconfdir}/php.ini Oct 04 09:39:23 ^^ revised Oct 04 09:39:44 install -m 644 ${S}/php.ini-production ${D}${sysconfdir}/php.ini Oct 04 09:39:54 You install things to ${D} Oct 04 09:40:23 ok, so ${D} is like the path to the temporary sysroot Oct 04 09:40:27 You don't want this in your build system's /etc/ directory! Oct 04 09:40:29 Snafflehog: yes Oct 04 09:40:34 haha, no! Oct 04 10:14:32 RP__: is there a way of purging your build directory of all the old sysroots as the file in the folder specifically says not to go deleting willy nilly Oct 04 11:01:13 RP__: do you want me to update jansa/x11 after your partial push? Oct 04 11:02:00 RP__: I can also add one extra commit to it "xorg-driver-common.inc: use virtual/xserver instead of older virtual/xserver-xf86" Oct 04 11:03:51 ah.. "xserver-nodm-init: merge some changes from meta-oe" shouldn't be there :/, updating jansa/x11 now Oct 04 13:06:51 JaMa|Wrk: thanks, I was looking at that commit and wondering why it was there Oct 04 13:07:17 Snafflehog: "old sysroots"? You mean deploy/images? Oct 04 13:10:14 RP__: glx-use-tls is also already converted to .inc in jansa/x11 branch Oct 04 13:10:32 JaMa|Wrk: it wasn't in the series you posted :/ Oct 04 13:11:42 I've updated it only few minutes ago after your input Oct 04 13:11:56 JaMa|Wrk: ah, right, good :) Oct 04 13:12:07 I was hoping that explaining that it's also used in xserver-xorg was enough.. but now it's .inc included by both (mesa and xserver-xorg) Oct 04 13:12:29 JaMa|Wrk: I haven't read through that full series yet, those were just things I'd noticed Oct 04 13:12:33 * RP__ is trying to get to that Oct 04 13:12:39 great, thanks Oct 04 13:14:52 * JaMa|Wrk trying to pinpoint why some python modules are not build anymore in 2.7 Oct 04 13:15:21 JaMa|Wrk: I've held the python patch in master-next for now until the issues are resolved Oct 04 13:18:15 you can add at least that manifest patch to master-next Oct 04 13:18:52 without it all files ends in python-misc package.. Oct 04 13:28:12 JaMa|Wrk: yes, I've been meaning to do that Oct 04 13:28:24 * RP__ should probably drop it until it gets fixed Oct 04 15:36:46 RP: do we have an enhancement request for sstate write locking? Oct 04 16:03:20 are there any "simple" examples of using bitbake to build something, i.e. not a full on cross build generating RPMs/ipks/images etc., like say just compiling a few autotools projects non-cross and tarring up the result Oct 04 16:05:26 the system isn't built to do that.. Oct 04 16:05:39 bitbake is a task executor.. yocto/oe-core chunks are the build system and base meta-data.. Oct 04 16:05:51 you can build a package or two.. but doing something like "bitbake " Oct 04 16:05:53 i.e. bitbake bash Oct 04 16:06:05 this will build anything required to build bash, and of course bash.. Oct 04 16:06:22 right, i understand that Oct 04 16:06:37 but it won't build a filesystem or anythign directly runnable on the target.. if you want that you need to either take the packages that were built and construct your own filesystem, or use the built-in filesystem creation components.. Oct 04 16:06:48 defaults are bitbake core-image-.... Oct 04 16:06:56 fray, i am talking about bitbake *without* OE Oct 04 16:07:21 sure you can use bitbake w/o oe.. but you'll have to write your own build classes and meta-data Oct 04 16:07:25 right Oct 04 16:07:28 i am willing to do that Oct 04 16:07:36 i was just curious if anyone else had done such a thing Oct 04 16:07:59 look at the bitbake repository.. there may be examples in there... I don't know Oct 04 16:09:21 fray, i did, couldn't find anything in a quick internet search so i came here Oct 04 16:09:45 then I doubt there is anything.. you can ask on the bitbake-devel mailing list.. but otherwise, I don't know where to look Oct 04 16:09:59 i may try my hand at it, though it's sort of a tough call whether to invest in this or keep improving our existing build scripts Oct 04 16:10:38 just remember bitbake is simply a task executor written in python.. if that is what you need.. it's a good start.. if that is NOT what you need.. don't use it Oct 04 16:10:46 yep, i understand that =) Oct 04 16:10:47 (bitbake also handles variables, recipe parsing, etc..) Oct 04 17:51:40 walters looks at oe-lite that uses bitbake in some form http://oe-lite.org/ Oct 04 18:00:43 RP__: can you queue the trivial patchset I sent for master-next? Oct 04 18:01:25 RP__: [PATCH 0/3] Minor and trivial fixes <= this subject Oct 04 18:02:23 khem: oelite doesn't really do what he was asking for though Oct 04 18:06:49 RP__: yes however its another usecase of bb Oct 04 18:09:51 he probably wanted to use it like a makefile Oct 04 18:10:25 * walters wonders if the "he" here is me Oct 04 18:12:02 walters: yes there u are Oct 04 18:12:16 sorry about leaving right after asking a question, laptop batteries and stuff you know Oct 04 18:12:49 those quad core intel chips sure burn them down ;) Oct 04 18:13:32 khem, yeah pretty much like a makefile, or a shell script to run makefiles Oct 04 18:13:46 where everyone's homegrown build systems start Oct 04 18:14:28 right oe itself is a huge'ish example you can look at Oct 04 18:15:25 walters: For reference oe-lite approaches build a bit differently with a sysroot per recipe. It also cross compiles so doesn't avoid your problem Oct 04 18:19:58 i just googled oe-lite, but am not finding some sort of one-paragraph description of why it's forked Oct 04 18:21:07 i should note also i tend to immediately and drastically lower my perceptions of people who call things "lightweight" without any links to actual data Oct 04 18:22:40 RP__: I am going to add --enable-gold=both/bfd option to binutils Oct 04 18:23:10 RP__: right now we do not build gold this will build gold and ld both and default to ld.bfd Oct 04 18:23:34 eventually some arches like x86/arm can use gold as system wide default linker Oct 04 18:23:45 and others can stick to ld.bfd Oct 04 18:25:00 actually /bfd or /gold would be determined based on ld-is-gold value Oct 04 18:28:40 I think what we have now is sufficient let me try it out Oct 04 18:36:36 khem: I'll reserve judgement until I see the patches :) Oct 04 18:37:12 RP__: I am trying to let some images built first Oct 04 18:37:18 probably sato-image Oct 04 18:37:25 on x86 and arm Oct 04 18:37:28 and see how it goes Oct 04 18:38:09 khem: sounds good Oct 04 18:38:31 is there any image in oe-core which uses webkit ? Oct 04 18:38:50 khem: no, we removed web from the images due to the build time :/ Oct 04 18:39:03 khem: it would be easy to add web to sato and have that though Oct 04 18:39:14 ok Oct 04 18:39:37 I wanted to contrast build time Oct 04 18:39:46 and webkit is one hog Oct 04 18:45:02 does yocto/poky have patchworks? Oct 04 18:45:23 msm: no, just oe-core Oct 04 18:45:31 RP__: booting qemu images from nfs does not work on ubuntu 11.10 Oct 04 18:45:44 khem: hmm, any idea why? Oct 04 18:46:01 it hits an error which suggests a workaround on F15 Oct 04 18:46:08 but not on ubuntu Oct 04 18:46:12 I am still searching Oct 04 18:46:30 I saw same issue on server and desktop ubuntu 11.10 Oct 04 18:48:25 RP__: how should I handle patches that I sent to yocto that appear to have not been applied and have no comments? resubmit? to poky list this time perhaps? Oct 04 18:48:39 msm: which patches? Oct 04 18:49:21 msm: ah, the ones on the yocto list? Those are against OE-Core so should really be on the oe-core list Oct 04 18:49:24 7 patches in my last barrage did not get applied Oct 04 18:49:30 a few had no comments Oct 04 18:50:01 for instance 'Fix sysprof for powerpc64' Oct 04 18:50:55 ugh, im confused why I sent that to yocto and not oe-core Oct 04 18:51:11 RP__: here is the output http://pastebin.com/pW5z0cr0 Oct 04 18:51:17 msm: I think they've just fallen through the cracks, sorry. Resending them might be the best way forward, refocus our attention Oct 04 18:51:42 msm: you own the patches until they get applied Oct 04 18:51:45 would it be best to use github or someplace to stage them? Oct 04 18:52:02 khem: i know, which is why im asking - i dont want to bug folks if they know about them =) Oct 04 18:52:04 msm: we also have contib repos Oct 04 18:52:18 msm: its fair to ping after a while Oct 04 18:52:22 khem: following the instructions didn't help? Oct 04 18:52:27 and respin them Oct 04 18:52:29 khem: right, i just got all that workign today as well Oct 04 18:52:35 RP__: those are for Fedora Oct 04 18:52:40 RP__: not for ubuntu Oct 04 18:56:23 I think rpcbind has been deleted in ubuntu 11.10 Oct 04 18:58:34 /etc/insserv.conf.d/rpcbind Oct 04 18:58:36 hmmm Oct 04 18:58:41 I thought ubuntu had portmap? Oct 04 18:59:19 it does Oct 04 18:59:23 Having been the author of the original user mode NFS "stuff", I recently updated it (not in the yocto stream) to no longer have the need to use rpcbind / portmap. Oct 04 18:59:24 it just is mucked around Oct 04 18:59:53 jwessel: can you submit that to upstream oe-core ? Oct 04 18:59:58 I would be happy to use it Oct 04 19:00:01 It requires an additional kernel patch to make it work because you just pass the port numbers which are pre-determined for the mountd and nfsd Oct 04 19:00:28 I'll probably try to talk fray into doing it. Oct 04 19:00:29 kernel on host or the one for target Oct 04 19:00:43 zeddii: Already has the kernel patch in hand. Oct 04 19:00:59 It is just the target kernel (what qemu uses) Oct 04 19:01:10 ok that should be easier then Oct 04 19:01:37 The whole idea was to make the user mode NFS another step removed from host dependent things. Oct 04 19:02:51 jwessel: sounds good Oct 04 19:09:13 jwessel: I look forward to seeing the patches :) Oct 04 19:18:03 ah meanwhile I found the way to forge it Oct 04 19:18:17 on ubuntu Oct 04 19:19:02 sudo vi /etc/default/rpcbind Oct 04 19:19:36 add OPTIONS="-w -i" Oct 04 19:19:50 sudo service portmap restart Oct 04 19:20:03 and it should work Oct 04 19:26:25 khem: if that works could you email it to the list please? :_) Oct 04 19:36:49 RP__: Yes it works. just send a patch Oct 04 19:36:51 to ml Oct 04 19:37:02 sent a patch Oct 04 20:08:44 Oh ... gdb fail to build Oct 04 20:09:00 http://paste.debian.net/134153/ Oct 04 20:09:06 khem: any idea? Oct 04 20:10:22 openembedded-core/meta/recipes-devtools/gdb/gdb/no-werror.patch Oct 04 20:10:32 that patch is not applying cleanly Oct 04 20:10:49 recently there has been updates for gdb posted Oct 04 20:11:37 I did not see these errors here on building gdb-cross Oct 04 20:27:24 khem: How do you boot with the user nfs with yocto? Oct 04 20:27:52 I built a small project and just ran "runqemu qemux86-64 nographic" Oct 04 20:28:16 It does not seem to use NFS with those settings. Oct 04 20:28:23 jwessel, I can get you the instructions, I'll send them via other channels. Oct 04 20:31:11 jwessel: runqemu-extract-sdk /b/kraj/angstrom/build/tmp-angstrom_2010_x-eglibc/deploy/images/qemuarm/systemd-GNOME-image-qemuarm.tar.bz2 /tmp/xxx/ Oct 04 20:31:17 runqemu /b/kraj/angstrom/build/tmp-angstrom_2010_x-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /tmp/xxx/ Oct 04 20:31:52 and you need to bitbake meta-ide-support before Oct 04 20:31:59 doing above Oct 04 20:37:50 hi, is it normal that with only 4GB bitbake parsing freeze the machine for a short time(swap) Oct 04 20:37:59 *4GB of ram Oct 04 20:39:23 GNUtoo: it happens for me too Oct 04 20:39:33 I have 2G ram Oct 04 20:39:50 GNUtoo: do u build many machines in single tmpdir Oct 04 20:40:10 yes Oct 04 20:40:37 om-gta02,htcdream,nokia900,nexusone,crespo Oct 04 20:40:58 respectively: Oct 04 20:41:08 ok delete the cache Oct 04 20:41:14 and see if it helps Oct 04 20:41:24 armv4t,armv6-novfp,armv7a,armv7a,armv7a Oct 04 20:41:26 ok Oct 04 20:41:36 which cache exactly? Oct 04 20:42:00 because there are some cache not to delete Oct 04 20:42:10 like persistent stuff Oct 04 20:42:25 buiddir/cache Oct 04 20:42:38 I usually delete that for every machine Oct 04 20:42:51 but that contains bb_persist_data.sqlite3 Oct 04 20:42:52 it reparses the recipes again but thats faster Oct 04 20:42:59 I've autorev Oct 04 20:43:01 on some recipes Oct 04 20:43:02 ok Oct 04 20:43:02 oh Oct 04 20:43:10 then spare that Oct 04 20:44:30 http://www.pastie.org/private/lcb1twg2kcqkviilgn0z8g Oct 04 20:44:47 I guess I keep only persist Oct 04 20:48:41 GNUtoo: actually it is bb_codeparser.dat which should be deleted Oct 04 20:48:47 and then it should work better Oct 04 20:50:36 ok I deleted everything but persist Oct 04 20:53:06 does it seem better now ? Oct 04 20:53:16 khem, yes thanks a lot!!!! it didn't freeze Oct 04 20:53:32 np Oct 04 21:02:49 btw I've a do_configure_prepend that I'd like to override Oct 04 21:02:54 how do I do that? Oct 04 21:12:57 override for what Oct 04 21:14:50 basically I've a recipe that doen't use the autools: xf86-input-mtdev Oct 04 21:15:02 and I want to do that inside: Oct 04 21:15:09 require recipes-graphics/xorg-driver/xorg-driver-input.inc Oct 04 21:15:19 which requires: Oct 04 21:15:27 require recipes-graphics/xorg-driver/xorg-driver-common.inc Oct 04 21:15:30 which has inside: Oct 04 21:15:32 do_configure_prepend () { Oct 04 21:15:40 and that does some stuff with configure.ac Oct 04 21:15:57 but I've no configure.ac xf86-input-mtdev Oct 04 21:16:02 it uses a plain Makefile Oct 04 21:23:47 hmmm I wonder if it should be then using that inc file Oct 04 21:24:01 or the do_configure_prepend should move out from recipes-graphics/xorg-driver/xorg-driver-common.inc Oct 04 21:25:03 aha Oct 04 21:25:10 I'll add a return 0 Oct 04 21:25:20 or something like that Oct 04 21:25:21 because it does that; Oct 04 21:25:24 do_configure(){ Oct 04 21:25:25 : Oct 04 21:25:32 //append stuff here Oct 04 21:26:56 * ant__ sent out the weekly rant about tzcode/tzdata Oct 04 21:29:08 thanks a lot Oct 04 21:29:14 I'll finish that and go to bed Oct 04 21:40:05 ant__: please work up a patch for the tz* issue for oe-core, I think that paul suggested that. Oct 04 21:41:16 sgw: hi, I'm unsure there is a big win. I'll recheck better Oct 04 21:44:02 as for tzcode-native, I hardly understand the NATIVE_INSTALL_WORKS part Oct 04 21:45:58 is NATIVE_INSTALL* part of meta-oe? Oct 04 21:46:50 yes, coming from oe-classic Oct 04 21:46:52 ant__: oe-core has a different approach maybe with "inherit native" Oct 04 21:47:16 http://tinyurl.com/6fqzqzq Oct 04 21:47:32 It would actaull be great if we could sense the latest set and use them instead of constant updating! Oct 04 21:49:10 I'm doubtful about this patch and about the other one (tzdata/tzcode: Switch to subdir= in SRC_URI) Oct 04 21:50:21 the recipe in oe-core seems fine. Well, I have to check for /etc/localtime and /etc/timezone now Oct 04 21:52:20 ant__: Drop the NATIVE_INSTALL_WORKS line Oct 04 21:52:26 ant__: oecore has no need of that Oct 04 21:53:03 thx for confirming it Oct 04 22:00:00 otavio: I merged your 3 patches, thanks Oct 04 22:08:29 RP__: ok, once persuaded Koen to remove tz* from meta-oe the next step will be udev. In oe-core there is an older recipe Oct 04 22:09:54 I don't know exactly which bugs are fixed in the latest releases Oct 04 22:11:35 as for the recipes, there is a different devices cache handling Oct 04 22:14:39 and a much shorter DEPENDS string Oct 04 22:14:58 which sounds always good :p Oct 04 22:15:41 oh, I see now # udev 169 and up require kernel 2.6.36 for ARM Oct 04 22:16:04 how high is the bar today? Oct 04 22:26:05 can anyone comment if this should work: Oct 04 22:26:07 git push poky-contrib refs/heads/master:refs/heads/mattsm/edison_with_fixes Oct 04 22:26:11 for those that use poky-contrib Oct 04 22:35:57 msm: should if you have the poky-contrib origin setup correctly Oct 04 22:37:34 RP__: seems like i should have double checked that, forgot to change to ssh **** ENDING LOGGING AT Wed Oct 05 02:59:58 2011