**** BEGIN LOGGING AT Tue Sep 11 02:59:58 2012 Sep 11 07:11:06 morning Sep 11 07:26:05 morning folks Sep 11 07:35:20 is it planned to use pseudo as a chroot soon ? Sep 11 07:36:01 i don't understand why while configuring or compiling, tools have access to the host filesystem... Sep 11 07:39:30 ie: configuring a program for compilation with --without-postgres, configure still checks for it, even if it's not present in oe because it can find the pg_config in my PATH Sep 11 07:40:01 configure:31924: checking for pg_config Sep 11 07:40:01 configure:31942: found /usr/bin/pg_config Sep 11 07:40:21 that's so annoying Sep 11 08:07:18 morning all Sep 11 08:07:25 hi Sep 11 08:25:46 morning all Sep 11 08:33:23 hmm, I found something interesting. should LDFLAGS be flags for ld, or for gcc? Sep 11 08:33:49 doesn't that depend on whether gcc is doing the linking or not? Sep 11 08:34:08 when gcc is doing the linking i guess it calls ld Sep 11 08:34:10 bitbake.conf sets it up for gcc, with -Wl prefixes. but that makes a kernel devshell build barf Sep 11 08:34:54 presumably this is not with master? Sep 11 08:34:56 since the kernel build calls ld $(LDFLAGS), and also inherits LDFLAGS from the environment Sep 11 08:35:46 checking versions... Sep 11 08:36:34 (I ask because I ran bitbake -c devshell virtual/kernel yesterday and it worked) Sep 11 08:37:29 is your kernel recipe (or includes) clearing LDFLAGS? Sep 11 08:39:23 oe master does: export TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}" Sep 11 08:39:40 so I guess that's cleared/handled elsewhere Sep 11 08:40:59 though I can't find anything. I guess I need to do a test build. Sep 11 08:47:58 hi bluelightning Sep 11 08:48:15 hi afournier Sep 11 08:49:07 hi silvio Sep 11 09:25:28 I don't get it when the asterisk configure script looks for openssl, it says this in the config.log Sep 11 09:25:32 configure:39389: ccache i586-oe-linux-gcc -m32 -march=i586 --sysroot=/home/afournier/NAS/oe/tmp-eglibc/sysroots/qemux86 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -lssl -lcrypto -lm >&5 Sep 11 09:25:33 /tmp/ccooGFtH.o: In function `main': Sep 11 09:25:33 /home/afournier/NAS/oe/tmp-eglibc/work/i586-oe-linux/asterisk-1.6.2.14-r0/asterisk-1.6.2.14/conftest.c:266: undefined reference to `ssl2_connect' Sep 11 09:26:24 but when i check the libssl.so in /home/afournier/NAS/oe/tmp-eglibc/sysroots/usr/lib/libssl.so with objdump the symbol is present Sep 11 09:26:51 0000c8f0 l F .text 00001d74 ssl2_connect Sep 11 09:27:30 and when i look on the system libssl.so, it does not have the symbol Sep 11 09:28:11 so i guess it looks on the host system instead of the sysroot... any idea ? Sep 11 09:30:21 bluelightning: I do get it in oe master. "arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'" Sep 11 09:31:29 output dump from devshell virtual/kernel: http://pastebin.com/v1SbFXRa Sep 11 09:32:00 am I not supposed to do like that? Sep 11 09:33:16 Zagor: I'm not sure but clearly it shouldn't break like that... Sep 11 09:33:27 if I clear the LDFLAGS environment variable, the build works fine Sep 11 09:38:56 kernel.bbclass does "unset LDFLAGS" (and some others) prior to oe_runmake Sep 11 09:39:41 perhaps it should do the same when starting devshell? Sep 11 09:49:23 bluelightning: thanks for sanity fix! :) Sep 11 09:49:30 JaMa: np :) Sep 11 09:55:58 what could cause pkg_cv_XORG_CFLAGS -> XORG_CFLAGS in config.log like this: http://pastie.org/4700673, I had to cleansstate virtual/xserver to get input/video drivers building again Sep 11 09:56:41 and xorg-server.pc seems the same Sep 11 10:00:41 hi Sep 11 10:00:54 first parsing for aarch64 passed Sep 11 10:05:33 hrw: congrats :) Sep 11 10:05:58 bluelightning: there are few files/classes to fork/hack/create Sep 11 10:52:32 hi all Sep 11 11:10:27 bluelightning: you live in uk now, right? Sep 11 11:10:43 hrw: yes, for about 5 years now Sep 11 11:11:07 bluelightning: which part? Sep 11 11:13:08 hrw: London, slightly to the west from where the old o-hand offices were Sep 11 11:17:18 bluelightning: never visited the new one ;) Sep 11 11:17:49 when OH got acquired I was on a meeting right on the other side of Thames Sep 11 11:21:52 hrw: I mean the one in bromley, I thought you went there ? Sep 11 11:24:54 bluelightning: yes, was there at OH XMas 2007 Sep 11 11:25:26 bluelightning: arrived when Millenium Falcon was nearly built Sep 11 11:25:35 hi RP Sep 11 11:25:50 hrw: Hi Marcin! Sep 11 11:26:44 hrw: the office is just up the road from the meeting near tower bridge Sep 11 11:35:50 morning all Sep 11 12:58:21 hi pb_ Sep 11 13:05:15 is there any simple way to mark task from runqueue as reqired to rebuild? Sep 11 13:24:50 ventyl: -f -c command (where taskname = do_command) Sep 11 13:26:22 bluelightning: i need to rebuild kernel image after some minor changes Sep 11 13:26:47 ventyl: after making changes where? Sep 11 13:27:04 ventyl: also which version are you using? Sep 11 13:28:06 3.0.1 Sep 11 13:28:13 changes inside machine definition file Sep 11 13:34:30 bluelightning, I build "xmlrpc-c" on OE-core,but I used an old version from a recipe of OE-classic, and I patch it. Could be usefull for the comunity? Sep 11 13:35:05 silvio_: I think so yes Sep 11 13:35:20 ventyl: I mean, which version of OE Sep 11 13:35:34 bluelightning: oe-core from git Sep 11 13:35:55 distroless if that changes anything Sep 11 13:36:07 ventyl: in which case just bitbake virtual/kernel should rebuild if the changes have affected variables the kernel recipe uses Sep 11 13:36:54 in this case changes are that subtle that probably nothing except kernel build system notices Sep 11 13:37:10 i made changes just in one .c file (different gpio assignments, etc.) Sep 11 13:37:36 so bitbake virtual/kernel or even core-image-minimal states that nothing needs to be rebuild Sep 11 13:37:50 ventyl: in which case bitbake -c compile -f virtual/kernel Sep 11 13:39:23 ok thanks Sep 11 13:39:30 i'll try tomorrow Sep 11 18:08:59 So I've gotten a bbappend file for my kernel partially working: The patches I've listed appear to be getting applied but my defconfig is got being grabbed. I've listed it in the same way I've seen elsewhere (SRC_URI+=), and my understanding is that it should take precedence, but that doesn't appear to be the case. Any suggestions? Sep 11 18:28:20 you aren't setting FILESEXTRAPATHS properly. without it, it won't find any file:// uris in the layer your bbappend is i Sep 11 18:28:24 in Sep 11 18:28:27 grep for examples Sep 11 18:33:12 thanks kergoth, I suspected as much, though I've already done that and I think I'm following the proper guidelines. I'll grep again. Sep 11 18:38:56 Is there a way to not have the .git directory copied into the source directory when the source code is obtained from a git repo? Sep 11 18:59:37 kergoth, would you explain a bit more about the proper setting. I've gripped and my value and directory structure seems consistent with some of the recipes. Sep 11 19:03:04 e.g I've got ${THISDIR}/linux-mainline-3.2 where THISDIR is the dir my bbappend sits. I know it is being parsed as the PR gets incremented. I know the patches I've placed in ${THISDIR}/linux-mainline-3.2/beagle/ and referenced with SRC_URI+= file://beagle/xxx.patch are also getting found as the code in the work directory shows their contents as having been applied. Sep 11 19:04:22 but even though I've also got file://defconfig added to the SRC_URI and ${THISDIR}/linux-mainline-3.2/defconfig exists, it is not getting pulled in Sep 11 19:04:45 spacecolonyone, hi Sep 11 19:06:44 spacecolonyone, FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Sep 11 19:06:44 hi Sep 11 19:08:08 doesn't that imply I've got a folder (here PN=3.2, as i understand it) ${THISDIR}/3.2 Sep 11 19:08:40 PV=3.2 Sep 11 19:08:42 not PN Sep 11 19:08:48 PN=linux-mainline Sep 11 19:08:55 PN == Package Name Sep 11 19:09:01 PV == Package Version Sep 11 19:09:01 oh, right right Sep 11 19:09:14 but anyway it was just an adaptable pointer that I gave you Sep 11 19:09:23 it's up to you to adapt it to fit your needs Sep 11 19:09:47 but I've manually coded linux-mainline already, so should it not already be working? Sep 11 19:10:01 the point is: Sep 11 19:10:10 FILESEXTRAPATHS_prepend := "something:" Sep 11 19:10:15 do not forget the last : Sep 11 19:10:24 something should be for instance: Sep 11 19:10:32 right, and iv'e got FILESEXTRAPATHS_prepend := "${THISDIR}/linux-mainline-3.2:${THISDIR}/linux-mainline-3.2/${MACHINE}:" Sep 11 19:10:58 ${THISDIR}/${PN} or ${THISDIR}/linux-mainline-3.2 or ${THISDIR}/${P} etc... Sep 11 19:11:16 which should be the same as FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:${THISDIR}/${PN}-${PV}/${MACHINE}:", no? Sep 11 19:11:21 then cleansstate and retry Sep 11 19:11:26 bitbake -e is also your friend Sep 11 19:11:57 I'd already tried the cleansstate bit Sep 11 19:13:29 as an aside, does bitbake -c cleansstate some-image-recipe automatically do cleansstate for all the constituents of the recipe, some behavior I've seen makes me think no Sep 11 19:17:17 the MACHINE bit there is completely unnecessary, also Sep 11 19:17:34 cleansstate removes all sstate archives for all the recipe's sstate tasks, yes Sep 11 19:17:50 you can read the cleansstate task if you want to know exactly what it does.. Sep 11 19:18:25 yea, that was me trying to match the meta-ti structure where the machine's defconfig is actually located under linux-mainline-3.2/beagleboard Sep 11 19:21:07 in short: 1) my FILESEXTRAPATHS_prepend is set in a functional manner, 2) patches are being found and applied, 3) my defconfig is not being used. Sep 11 19:22:32 Is possible it is being copied and then overwritten? For instance if I do bitbake virtual/kernel -f -c configure then manually cp my defconfig over the defconfig in the work directory, it still is not used. Sep 11 19:23:19 The only way i've ever successfully managed to change the config settings is by using the bitbake menuconfig after configure Sep 11 19:53:41 ok, I've redone it all: bitbake -f -c cleansstate virtual/kernel, then bitbake -f -c clean virtual/kernel, and bitbake virtual/kernel. I can confirm that the patches were applied, but the defconfig in the work directory reflects the default meta-ti defconfig, barring one addition which is not from my layer must (I'll try to track that down now) Sep 11 19:55:03 it comes from a patch in the meta-ti layer Sep 11 19:56:30 spacecolonyone: are you trying to override defconfig from your own layer? Sep 11 20:05:19 denix: yes Sep 11 20:07:27 have you checked layer priorities? Sep 11 20:08:24 BBFILE_PRIORITY_m2fs-layer = "1" BBFILE_PRIORITY_meta-ti = "10" Sep 11 20:08:31 lower is hight, right? Sep 11 20:08:36 higher* Sep 11 20:14:58 no, lower is lower Sep 11 20:15:39 but, BBFILE_PRIORITY doesn't apply to SRC_URI, only to the .bb files. Sep 11 20:17:31 ugh, so then then won't be it. I'll still change it so it doesn't bite me about something else in the future Sep 11 20:19:09 the only thing that matters for SRC_URI is the order of things in FILESPATH. have you verified (with "bitbake -e" or similar) that you're getting the right thing there? Sep 11 20:21:16 pb_ I have looked at the output of bitbake -e, but I'm not really sure what exactly I'm looking for and nothing really jumped out at me Sep 11 20:21:30 well bitbake -e virtual/kernel Sep 11 20:23:53 file://defconfig is listed twi Sep 11 20:23:56 doh Sep 11 20:25:31 "file://defconfig" appears twice in the SRC_URI, the first time possibly from my bbappend as the patches I added follow it in the list (although the order is reversed in the bbappend) Sep 11 20:26:42 The second time it appears it is followed by file://logo_linux_clut224.ppm, which immediately follows file://defconfig in the original .bb file Sep 11 20:26:59 if you append to SRC_URI, you don't need to list the files that are already there Sep 11 20:28:14 denix: in other words if i stick my defconfig in my overlay in the same path hierarchy as used by the original bb it should just be picked up? Sep 11 20:28:15 please paste the output of: bitbake -e virtual/kernel | grep 'FILESPATH=' Sep 11 20:29:04 yes, it's already in SRC_URI, all you are doing is extending FILESPATH with extra dirs where to look for it Sep 11 20:29:05 http://pastebin.com/aL7j62U0 Sep 11 20:29:30 * spacecolonyone look at output as well Sep 11 20:29:57 meta-ti comes before m2fs-layer Sep 11 20:30:09 priority issue? Sep 11 20:31:14 oh, right. what's the order of your BBLAYERS? Sep 11 20:31:33 I hadn't quite registered before that you had multiple layers with .bbappends on the same recipe. Sep 11 20:32:18 pb_: I don't Sep 11 20:32:36 your layer should come before meta-ti in BBLAYYERS list Sep 11 20:32:49 linux-mainlin_3.2.bb is defined in meta-ti and I'm trying to extend it in my layer m2fs-layer with a bbappend Sep 11 20:32:53 check your bblayers.conf Sep 11 20:33:20 ah, ok. same applies: BBLAYERS. Sep 11 20:33:34 you might think that this all sucks, and you would be right. Sep 11 20:33:36 as to bblayers: I added my layer in via EXTRALAYERS, Sep 11 20:34:04 I've never heard of EXTRALAYERS Sep 11 20:34:09 me neither Sep 11 20:34:10 which looks like it gets combined at the end of the file after BSPLAYERS, in which meta-ti is defined Sep 11 20:34:12 * pb_ google Sep 11 20:34:18 oh, is this some angstrom thing? Sep 11 20:34:21 bitbake -e virtual/kernel | grep "BBLAYERS=" Sep 11 20:34:21 yea Sep 11 20:34:27 ah Sep 11 20:34:46 if you had mentioned that at the outset, I would have told you to take up your grievances with #angstrom :-} Sep 11 20:35:15 ah, right, EXTRALAYERS is used after BSPLAYERS... Sep 11 20:35:19 but, in this case, it sounds as though EXTRALAYERS is not the right place for your layer. you need it to be before meta-ti, by whatever means. Sep 11 20:35:32 pb_: I never really know where to draw the line. I'm trying to extend angstrom using oe, so it is murky :) Sep 11 20:35:48 ok Sep 11 20:35:54 whether that means that you have to tell angstrom that your layer is a bsp layer, or just set BBLAYERS manually, I dunno. Sep 11 20:36:13 Oh it isn't bad: Sep 11 20:36:15 BBLAYERS = " \ Sep 11 20:36:16 ${TOPDIR}/sources/meta-angstrom \ Sep 11 20:36:17 ${BASELAYERS} \ Sep 11 20:36:19 ${BSPLAYERS} \ Sep 11 20:36:20 ${EXTRALAYERS} \ Sep 11 20:36:21 ${TOPDIR}/sources/openembedded-core/meta \ Sep 11 20:36:22 " Sep 11 20:36:33 okay, fair enough Sep 11 20:36:34 all in one file, just making stuff tidy Sep 11 20:36:43 right, insert it before BSPLAYERS Sep 11 20:36:45 ok, so I'll do that and see how it goes Sep 11 20:36:46 so, just do whatever you need to do to get your layer in there before meta-ti. Sep 11 20:37:12 I keep mis-parsing BSPLAYERS as "bs players" for some reason Sep 11 20:37:16 heh Sep 11 20:37:22 crap, wait Sep 11 20:37:37 * pb_ waits Sep 11 20:37:43 that means the kernel patches in my layer will be applied before the patches in the meta-ti layer, right? Sep 11 20:37:55 no, the actual order of application is determined by SRC_URI Sep 11 20:37:59 pb_: he asked crap to wait... :) Sep 11 20:38:32 so since my src_URI appends… it is all good Sep 11 20:38:34 but if you have the same patch, your will be used instead of the one from meta-ti Sep 11 20:39:32 right, I just have patches that apply on top of the meta-ti patches, (perhaps that ins't good practice, but I'm still learning) Sep 11 20:39:40 yeah, that's fine Sep 11 20:44:59 well that made my layer go to the front of the line in BBLAYERS, but meta-ti is still ahead of m2fs-layer in FILESPATH Sep 11 20:45:13 * spacecolonyone ttys again anyway Sep 11 20:49:16 no dice Sep 11 20:51:56 do the new paste for FILESPATH Sep 11 20:54:24 denix: that still may be the issue as meta-ti continues to come before m2fs-layer, though I don't understand why Sep 11 20:54:25 http://pastebin.com/u2LunLpG Sep 11 21:05:22 I'm off, but will be back later Sep 11 23:10:41 denix: did you have any more thoughts? all: is there a way to manually set FILESPATH? Sep 11 23:12:30 spacecolonyone: bbappends are applied in layer priority order as defined by the variables in the layer.conf files, not by the BBLYERS order. BBLAYERS order only affects BBPATH (conf/class priority) Sep 11 23:15:09 ok, pb_ said it didn't apply to SRC_URI additions, though I guess a look as the relevant code (whatever and wherever that is) would answer that. in this case my layer has priority BBFILE_PRIORITY_m2fs-layer="99" and meta-ti has priority 10 Sep 11 23:15:24 So I should be good there, no? Sep 11 23:20:05 also, if you just want to override defconfig or something, you dont ned to add it to src_uri at all. as pb said, src uri is just a list of uris, it doesn't know or care what uri came from what file/layer Sep 11 23:20:25 and, i'd highly suggest using the bitbake-layers tool to inspect your setup Sep 11 23:20:48 in the case of defconfig, it's generally already in src_uri, so adding it again gains you nothing. Sep 11 23:21:33 ok, well I can remove it and see if the file is grabbed Sep 11 23:22:09 I will explore bitbake-layers, I'd not heard of it before Sep 11 23:22:55 and start using bitbake -e, it's invaluable. if you'd used bitbake -e to inspect SRC_URI, you'd see the duplicate entry :) Sep 11 23:25:21 yea, i noticed that just recently. Is there a good way to edit what is given by bitbake -e Sep 11 23:26:22 what would be awesome would be to have a manual that is remotely up to date, when i first started i actually tried reading it but I was pretty quickly told: don't bother :0 Sep 11 23:26:35 I mean I see things like SRC_URI_append_beagleboard Sep 11 23:27:03 i don't understand what you mean edit what's given by bitbake -e. bitbake -e is the result of parsing the config files and metadata. if you want to change what ends up in the metadata, change a config file or recipe Sep 11 23:29:08 and I suspect/infer that this means that bb supports conditional appending of SRC_URI based on the machine by introspection of the python variable name, but I'm not even sure where to go looking at the source to try and confirm what other goodies like that there are. for that matter I've been tempted to just put "print some_python_statement" in a bb file and see what happens, but haven't gotten around to it Sep 11 23:29:42 You got me, thats the answer Sep 11 23:31:35 look at the OVERRIDES variable. it's a list of allowed 'overrides', which are used for conditional variable definition or append/prepend Sep 11 23:32:13 the intent was for overrides to be, conceptually, a metadata layering mechanism, letting more specific information override less specific information Sep 11 23:32:28 so e.g. the architecture would be used in preference to the global default, but a version defined for this particular machine would override the arch Sep 11 23:33:34 this sort of metadata layering (note: different use of the term, not referring to layers/bblayers) is also reflected in the order in which the config files are included by bitbake.conf. generally it tries to load them in less specific to more specific order, so the latter can override the former Sep 11 23:34:40 also, print won't do anything. there's no print statemetn in recipes. you could call print() inside a python function, but that sort of output is suppressed — it goes into log files only, so you'd have to look there for it Sep 11 23:36:34 ok, well thanks. I'll play with bitbake-layers and look around for any other utilities in the folder it live in and try giving the compile another go no that the duplicate reference is gone. right now I've got to go purchase groceries Sep 11 23:36:52 np Sep 11 23:56:02 kergoth: Do you know what to use in LICENSE field for proprietary license ? Sep 11 23:56:11 I am looking for a general term Sep 11 23:56:51 iirc CLOSED is intended to be used for that, as in, closed source Sep 11 23:57:06 ah k Sep 11 23:57:15 it should only be used in limited circumstances though, you could create one for your own company, and point to the exact terms of your proprietary license, though Sep 11 23:57:21 to do it more proper Sep 11 23:57:34 but closed is a nice way to sidestep the issue :) Sep 11 23:58:04 heh I was using "Closed" Sep 11 23:58:13 was close enough :) Sep 11 23:58:16 heh :) Sep 11 23:59:08 Is there a way to not have the .git directory copied into the source directory when the source code is obtained from a git repo? I am having the issue with -dirty tag being added my linux kernel and it is built and I have patches being put on top of it. Sep 11 23:59:45 *to my linux kernel when its built when I have Sep 12 00:00:08 if you're patching it, it arguably *is* dirty :) Sep 12 00:01:55 True but I don't need git to tell on me. Sep 12 00:34:08 * mr_science hits the road... Sep 12 00:38:27 kergoth: have you tried putting OE images onto USB media Sep 12 00:38:41 I wonder if we have some handy scripts Sep 12 00:40:47 haven't, but i bet the sdcard image format stuff would be of use Sep 12 00:43:06 there is a script in scripts/contrib/ddimage Sep 12 00:43:09 pretty basic though Sep 12 00:43:25 otherwise there are scripts and classes scattered throughout various layers Sep 12 00:43:50 would be good to have a single image writing tool with a framework that layers could hook into to provide whatever custom image writing was necessary for specific machines Sep 12 00:43:51 there are some scripts that create images. Sep 12 00:44:14 mebbe angstrom has this...I look. Sep 12 00:44:18 * bluelightning is off to bed, g'night Sep 12 01:06:35 i followed instructions here to create sd card for booting on olinuxino micro ---> http://www.jann.cc/2012/08/08/building_freescale_s_community_yocto_bsp_for_the_olinuxino.html Sep 12 01:07:15 i can boot the sd card but I have no keyboard and the video is offset on the TV Screen Sep 12 01:10:31 I have tried downloading the defconfig configuration file ---> https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/iMX233 and booting and it does the same as before although I have gotten the one generated by Dimitar Gamishev to work perfectly Sep 12 01:12:05 when I bitbake what do I need to do to ensure the settings from menuconfig are being used? Sep 12 01:15:36 bitbake -cmenuconfig virtual/linux Sep 12 01:16:06 ka6sox: sure I am aware of many but I wanted to know if we have some officially image writer support in Core Sep 12 01:16:25 not that I've found Sep 12 01:18:34 right. I think something we should work on in future Sep 12 01:26:28 so would end up in deploy/images? Sep 12 01:35:02 preferably Sep 12 01:35:24 iirc there was an email thread about potentially reworking image creation stuff, but i can't recall the subject of the email Sep 12 01:42:32 okay I'll try to find it. Sep 12 01:43:46 "RFC: OE-Core image creation and deployment" Sep 12 01:43:58 it's still in my inbox waiting for me to find the time to read it and reply.. Sep 12 01:43:59 heh Sep 12 02:11:51 hmm, is bitbake-devel not on gmane? Sep 12 02:16:43 wtf, sanity is failing out saying the bblayers.conf version mismatches, even though it doesn't Sep 12 02:16:46 * kergoth scratches head Sep 12 02:20:16 hmmmm Sep 12 02:24:34 ah, right Sep 12 02:38:02 * ka6sox sees that a LOT these days... **** ENDING LOGGING AT Wed Sep 12 02:59:58 2012