**** BEGIN LOGGING AT Thu Jan 12 02:59:57 2012 Jan 12 04:26:04 hello folks Jan 12 04:27:25 i still don't really understand the practical differences between OE and Yocto so I am going to try building something with both Jan 12 04:27:47 (just putting that out there) Jan 12 05:14:06 what is the difference between OE "classic" and "meta"? Jan 12 05:14:36 (for instance, which branch/ref would I check out for meta?) Jan 12 07:26:45 03Frans Meulenbroeks  07master * r9231b084bb 10openembedded.git/recipes/ntpclient/ntpclient_2010_365.bb: (log message trimmed) Jan 12 07:26:46 ntpclient: updated to 2010_365 version Jan 12 07:26:46 Changes since ntpclient_2007_365: Jan 12 07:26:46 -- fixed type of sa_xmit_len, thanks vapier Jan 12 07:26:46 -- dropped underscores in spelling of adjtimex(2), might make uClibc happier Jan 12 07:26:46 -- include netdb.h and always define _BSD_SOURCE to get prototype for herror Jan 12 07:26:47 -- minor formatting to align with Nilsson's fork Jan 12 07:50:53 good morning Jan 12 08:08:35 Has anyone tried to bring X up in minimum package ? Jan 12 09:42:22 good morning Jan 12 09:45:30 morning florian, all Jan 12 10:06:30 hi all Jan 12 10:07:43 hi pb_ Jan 12 10:09:01 hi all Jan 12 10:09:46 pb_: may I ask your comment about 1) # libc is removing zoneinfo files from package vs. 2) # Only eglibc is removing zoneinfo files from package ? Jan 12 10:13:07 I'm not quite sure I understand the question. Can you expand on it? Jan 12 10:14:00 I'm finishing a new tzdata recipe http://paste.debian.net/151979/ and I see zone.tab and iso3166.tab are recreated because '*libc' would remove the files Jan 12 10:14:55 in meta-oe is even declared that only eglibc would delete those Jan 12 10:15:58 iirc only uclibc handles TZ differently Jan 12 10:23:10 ah, I see. offhand I am afraid I have no idea. Jan 12 10:25:47 pb_: np, thx. I think I'll have to add a check for uclibc, though Jan 12 10:59:03 hi mickey_office Jan 12 11:13:00 * pb_ stabs lenovo Jan 12 11:13:17 apparently the laptop I ordered is out of stock and won't be available for 3 weeks Jan 12 11:15:47 acer has stocks :p Jan 12 11:21:20 pb_: I had to learn that Lenovo is not IBM as well :-/ Jan 12 11:24:09 florian: why? I heard that Lenovo is good for its quality/price ratio Jan 12 11:32:08 * bluelightning is happy with his lenovo x201 Jan 12 11:32:15 (not new anymore) Jan 12 11:32:18 reisei, because the IBM quality level and support was at least twice as good as the Lenovo one? Jan 12 11:32:27 yeah, the annoying thing is that they waited 2 weeks to tell me it was out of stock, and I was hoping to take it to california with me tomorrow. Jan 12 11:33:16 I don't think it's true to say that the IBM quality was twice as good. I had several ibm thinkpads and I think I have had two lenovo ones, and the difference is not as much as all that. Jan 12 11:34:02 There was always quite a lot of variation between one model and another even in IBM days. Jan 12 11:34:27 I think it might be fair to say that the support was twice as good from ibm though. Jan 12 11:35:05 bluelightning: yeah, I though about buying an x201 but I decided to get an x121 in the end Jan 12 11:35:59 much cheaper so long as you don't take out the "ThinkPad Protection" :-) Jan 12 11:36:04 this was the one I was given, but I quite like it... the only negative is the annoying back/next buttons near the cursor keys... probably not uncommon on laptops but they still catch me out even a year on Jan 12 11:36:42 see http://pbcl.net/~pb/lenovo.jpg for the slightly startling quotation that their web store came up with Jan 12 11:36:52 woah Jan 12 11:41:11 yeah, my old x61 has the stupid back key thing as well, also still catches me out regularly Jan 12 11:41:19 I should use the power of xmodmap to defeat it, I suppose Jan 12 11:41:43 very annoying when I have just finished filling in a big web form and then press it by mistake and lose all my data Jan 12 11:44:09 exactly :/ Jan 12 11:44:34 in KDE I can disable them system-wide but that only applies to KDE apps; firefox does not allow configuring those shortcuts Jan 12 11:47:21 the other thing I was a bit unclear about with the thinkpad was which wifi to buy for best performance and linux compatibility Jan 12 11:47:29 they have about four options but I have no idea what the real differences between them are. Jan 12 11:52:06 hey has some one worked auto resolution selection ? Jan 12 12:02:24 reisei: I have a x301 and I'm happy with it... but the support more and more sucks. Jan 12 12:03:17 reisei: It took me a mail to get the USB port fixed (involves replacing the mainboard). Jan 12 12:04:09 reisei: But I was not able to get the broken speaker cover fixed even if this seems to be a quite common issue with that model. Jan 12 12:04:57 heh. Here, in Russia we almost forgot that word — support. Jan 12 12:10:54 on the subject of buying new hardware, I also need a new oscilloscope. does anybody have any DSO recommendations? Jan 12 13:10:58 khem: ping Jan 12 13:19:09 he yoZ Jan 12 13:49:39 florian: could build and install a system now, but only boot it from ext2 partition Jan 12 13:50:12 florian: ext4 now hangs at pcmcia_socket blabla time out after reset Jan 12 14:03:03 florian: not the could not read blabla ext2 stuff it did before Jan 12 14:07:52 brb buying wifi card that has better support (airo_cs drivers only support WEP but the card is able to do WPA) Jan 12 14:09:09 florian: forget what I said about ext4, I had sd card in the slot again rogntuudjuu Jan 12 14:57:31 Hi everybody Jan 12 14:58:32 Can I use base_conditional in another base_conditional? Jan 12 15:25:36 mgundes: if you're trying to get that complicated you may consider using a python function to do what you want Jan 12 15:25:49 s/may consider/may want to consider/ Jan 12 15:26:15 #include Jan 12 15:27:19 bluelightning: actually I tried to do with function Jan 12 15:27:43 I want to update SRC_URI up to environment variables conditianally Jan 12 15:28:07 at that time I use bb.data.getVar and bb.data.setVar to check and set SRC_URI Jan 12 15:28:29 but when I update SRC_URI in function I think I could not set it globally Jan 12 15:28:52 because in other function, like patch, not updated version is used Jan 12 15:29:38 do you have any idea why bb.data.setVar(SRC_URI, "valur", d) does not update environment globally for that bb file Jan 12 15:30:46 this is my function: http://pastebin.com/NT6Xe6Hp Jan 12 16:20:41 does anyone know how about this error: ERROR: sysroot task found /local/jenkins/workspace/yocto-iso-test/label/ubuntu1004-64b/yocto/meta/recipes-core/meta/meta-environment.bb Jan 12 16:21:03 is it not supposed to find these? Jan 12 16:21:42 weird Jan 12 16:21:49 this is from staging.bbclass Jan 12 16:22:03 it seems to continue just fine… do you know the original intent of that check? Jan 12 16:23:14 * kergoth has no clue Jan 12 16:23:27 * msm as well Jan 12 16:24:38 anyone know what happened to python-pickle-native Jan 12 16:30:17 hmm, how do I create an empty package with only pkg_postinst und pkg_prerm hooks? Jan 12 16:30:37 somehow only -dev and -dbg get generated but not the package itself Jan 12 16:31:05 ALLOW_EMPTY_${PN} = "1" Jan 12 16:32:43 thanks! I whould try to remember or write it down somewhere; now that I see it, I'm pretty sure I asked and used that once already Jan 12 16:33:43 also, reading bitbake.conf helps ;) Jan 12 16:33:46 it sets that for -dbg and -dev Jan 12 16:34:52 moment Jan 12 16:34:55 oops wrong window ;) Jan 12 17:18:32 JaMa|Off: whats up Jan 12 17:19:39 kergoth: that answer to Jin's questions is a sure shot entry for FAQ Jan 12 17:19:50 or how-to Jan 12 17:20:58 heh, indeed Jan 12 17:28:31 kergoth, khem: hi there Jan 12 17:28:58 khem: I already bothered the channel before, prolly you can shed some light Jan 12 17:29:04 I'm finishing a new tzdata recipe http://paste.debian.net/151979/ and I see zone.tab and iso3166.tab are recreated because '*libc' would remove the files Jan 12 17:31:35 is it still actual? Is the timezone support built in? I see in the web commits like "eglibc : remove timezone support ; there is already package timezone-data" Jan 12 17:48:55 * ant_work heading home, bbl Jan 12 18:35:21 about oe-core Jan 12 18:44:58 should layers be placed in the openembedded-core folder? or can they placed anywhere on disk? Jan 12 18:45:11 i've seen these scripts and all that rely on them being under oe-core Jan 12 18:46:58 CMoH|office: I think you can have them anywhere, just make sure your confs are ok Jan 12 18:47:24 my custom layers are separate from oe-core for example Jan 12 18:48:10 ok, ty Jan 12 19:29:40 Jin^eLD, is there any other doc on how to start with oe-core except by running the oe-init-build-env script? Jan 12 19:36:25 CMoH|office: I am not aware of any doc for that, but I can point you to my git tree which does not use the oe-int script Jan 12 19:36:49 that should kind of help you to understand what you need if you want to have your own layout/configuratin Jan 12 19:37:50 https://gitorious.digitalstrom.org/dss-oe Jan 12 19:38:04 you can browse the tree directly if you don't want to clone Jan 12 19:38:40 let me know if you want me to explain the basic idea/config layout Jan 12 19:51:03 if you dont want to use init script then follow the classic oe approach Jan 12 19:51:18 any reason not to use it Jan 12 19:51:56 that's what I did btw, I think my setup is based on some ancient blog from hrw, I used his guide in the oe classic times Jan 12 19:52:14 khem: for me it was doing too much "behind the scenes" Jan 12 19:52:35 I also did not like it being in ~/.oe or wherever it installs itself into Jan 12 19:53:08 I needed a slick configuration for a selected number of targets with hand picked layers and some custom tweaking on top Jan 12 19:53:25 so I reproduced my oe classic setup with oe core, actually I still use both Jan 12 19:53:47 till classic based products get updated to the new core based rootfs I still have to maintain the old stuff too Jan 12 20:00:46 hmm are you talking about angstrom or about oe-core ? Jan 12 20:00:50 when it comes to layers Jan 12 20:00:52 Jin^eLD, thanks; i' Jan 12 20:00:58 i have to go now, but i hope i Jan 12 20:01:03 will get to it tomorrow Jan 12 20:01:33 khem: well both, angstrom does way too much automagic anyway, core just sets the env but still not the way I prefer it :) Jan 12 20:01:50 CMoH|office: np, see you tomorrow Jan 12 20:03:05 one thing that I do not like with the new bitbake is, that you have to be in a specific directory in order to build stuff; with older bitbake versions it was enough to set the env and you could bitbake from any directory Jan 12 20:03:14 Jin^eLD: OK you can setup layers the way you want true Jan 12 20:03:18 I do not know if it is a bug or if it changed on purpose Jan 12 20:03:38 I have slugos on top of oe-core like below https://github.com/kraj/slugos-setup Jan 12 20:03:51 I use git submodules Jan 12 20:03:57 to manage layers Jan 12 20:04:27 but you have only one local.conf? i.e. you always build "the same"? Jan 12 20:05:04 I use my own layers on top of angstrom on top of oe core, and I have 5 layers which I select, with 3 machine configurations per layer Jan 12 20:05:19 i.e. I have 5 feeds, development, testing, staging-fieldtest, fieldtest, production Jan 12 20:05:27 where production is the end customer deployment Jan 12 20:05:54 and all those before are beta testers, automated testing, internal testing and developers Jan 12 20:06:27 once a package/features passed testing they travel to the higher layer Jan 12 20:06:58 so I need a separate conf per machine per layer Jan 12 20:07:15 well, not per layer, per "my feed" Jan 12 20:07:25 which is solved as a layer on top of angstrom + oe-core Jan 12 20:07:46 oe/angstrom layers are submodules too Jan 12 20:08:23 you only need different feeds as I see Jan 12 20:09:20 I use the same OE "base" everywhere, well I have to come up with some procedure when I want to gradually update OE Jan 12 20:09:33 because there I have to start in dev/testing feed and slowly propagate the updates in direction of production Jan 12 20:09:54 but right now I use an OE/angstrom snapshot and the remaining changes happen in my "feed"-layers Jan 12 20:11:08 https://gitorious.digitalstrom.org/dss-oe/dss-oe/trees/master -> OE has all the oe/angstrom layers, dS keeps my custom "feed"-layers, org.openembedded is the classic config, targets/ holds various local.conf's for each feed/machine combo Jan 12 20:11:23 and I setup the environment by sourcing setup-oe-core.sh targets/myconfig Jan 12 20:12:22 and can build right away, with the limitation that my cwd has to be in targets/myconfig, with classic I could build independently from cwd as long as the environment was sourced correctly Jan 12 20:12:32 no idea why this does not work anymore with new bitbake Jan 12 20:18:39 florian: tworaz seems to build his kernel in a different way than the rest of oe Jan 12 20:18:50 look at how we setup environment in angstrom it does not need to be in any given dir Jan 12 20:18:59 florian: just now starting to understand where to put the config Jan 12 20:19:12 khem: the env in angstrom setups a `pwd`/conf/auto.conf Jan 12 20:19:33 and somehow relies on that Jan 12 20:19:47 I could not reproduce it, but something has definitely changed in bitbake Jan 12 20:20:08 how is your BBPATH setup Jan 12 20:20:11 i.e. I could not reproduce whatever angstrom does, but to be honest I did not play around with this automagic script too much Jan 12 20:20:44 it's: /oe/jin/dss-oe/targets/dss11-testing and under this dir there is a conf directory that points to the remaining layers and so on Jan 12 20:22:42 I believe that should be enough, no? and I can build only and only if my cwd is the same as $BBPATH Jan 12 20:22:57 anyone know what happened to python-pickle-native? Jan 12 20:23:05 I got hungry Jan 12 20:23:08 if I try it from some other dir, bitbake won't find the ./conf directory Jan 12 20:23:24 i.e. it always looks for ./conf instead of $BBPATH/conf Jan 12 20:23:35 at least that's my impression, I did not debug the code or anything Jan 12 20:23:56 Crofton|work: classic oe ? Jan 12 20:24:38 bitbake obeys bbpath the way it always has Jan 12 20:25:13 kergoth: well, I can only say that 0.12 or so did seem to behave differently Jan 12 20:25:42 90% chance it's user error Jan 12 20:25:45 but i can look into it Jan 12 20:25:48 this is a non-layers-based setup? Jan 12 20:26:12 (as with layers there's no need to set any env vars or source anything at all, necessarily, though I think angstrom does) Jan 12 20:26:25 kergoth: this is a layer based setup now Jan 12 20:26:25 well, i lied, i think it might need BUILDDIR Jan 12 20:26:39 well, layers obeys bbpath, i use it every day in 20+ setups Jan 12 20:26:43 some upstream, some mentor Jan 12 20:26:49 Jin^eLD: the trick in in conf/bblayers.conf Jan 12 20:26:53 use bitbake -e to verify BBPATH is what you think it is. Jan 12 20:27:01 see how its setting up TOPDIR Jan 12 20:27:05 yeah, you should definitely set your base BBPATH (that is, the build directory) in bblayers.conf Jan 12 20:27:34 each layer adds itself to bbpath, but your build directory doesn't, it has to be added in bblayers.conf or your environment Jan 12 20:27:51 that looks OK with -e: http://pastebin.mozilla.org/1446857 Jan 12 20:28:01 khem: let me have a look Jan 12 20:30:48 khem: my TOPDIR is correct Jan 12 20:31:10 it's /oe/jin/dss-oe Jan 12 20:31:23 or should it be same as my BBPATH dir? Jan 12 20:32:20 for example if I cd.. from my $BBPATH dir Jan 12 20:32:26 and try to run bitbake, I get this: Jan 12 20:32:27 http://pastebin.mozilla.org/1446868 Jan 12 20:32:44 interesting line is: conf/bitbake.conf not found in /oe/jin/dss-oe/targets/dss11-testing Jan 12 20:33:00 I indeed have no bitbake.conf there Jan 12 20:33:28 the only bitbake.conf there is around is here: ./openembedded-core/meta/conf/bitbake.conf Jan 12 20:33:45 so should this layer be in BBPATH as well? Jan 12 20:34:24 the layer is configured via bblayers.conf in /oe/jin/dss-oe/targets/dss11-testing/conf Jan 12 20:34:34 as i already told you, layers add themselves to bbpath automatically via their layer.conf Jan 12 20:35:05 kergoth: you did - so why is bitbake looking for bitbake.conf in my testing dir instead of the layer dir? Jan 12 20:35:57 don't know, you have something odd lurking in your setup Jan 12 20:36:08 I'd think that if the layer dirs get appended to BBPATH, which seems to be the case if I inspect with -e, it theoretically should find that conf file... Jan 12 20:36:12 try this, just as a sanity check. git clone --recursive http://github.com/kergoth/oe-core-template; cd oe-core-template; make Jan 12 20:36:21 Jin^eLD: whats your path and bbpath Jan 12 20:36:58 khem: in the -e output? Jan 12 20:37:27 kergoth: trying Jan 12 20:39:06 khem: from -e: http://pastebin.mozilla.org/1446875 Jan 12 20:39:52 kergoth: that's the make output: http://pastebin.mozilla.org/1446876 Jan 12 20:40:22 did you clone with --recursive? Jan 12 20:40:33 very odd Jan 12 20:40:35 yes, I pasted your lines from IRC Jan 12 20:40:48 that builds fine here :\ Jan 12 20:40:50 very strange Jan 12 20:40:52 what version of bitbake is this? Jan 12 20:40:56 well wait it wants xterm Jan 12 20:40:59 no Jan 12 20:41:02 that's what the errr message says Jan 12 20:41:02 thats for the debugging bit Jan 12 20:41:14 yes, because it wants to spawn a devshlel for you to fix the problem Jan 12 20:41:16 oh, this git does not come with a bitbake tree? Jan 12 20:41:17 it's n ot the root error Jan 12 20:41:25 oh, right, i think it does Jan 12 20:41:26 hmmm Jan 12 20:41:32 because then it would be using my systems bitbake which is ancient Jan 12 20:41:35 * kergoth clones and makes to check sanity himself Jan 12 20:41:37 in my setup I use a bitbake tree from git Jan 12 20:42:11 okay, that's good Jan 12 20:42:14 hmm Jan 12 20:42:25 hmm as in it's failing on your system too? Jan 12 20:42:37 I see there is a bitbake dir under oe-core-template Jan 12 20:44:42 cloning Jan 12 20:53:39 ah, right, i'm blind, apparently Jan 12 20:53:41 heh Jan 12 20:55:15 Jin^eLD, yeah, set TERMCMD = "${SCREEN_TERMCMD}" and the same for TERMCMDRUN, or similar, in the conf/local.conf, then make again :\ sorry about that Jan 12 20:57:07 ok did that, its building pseudo now... Jan 12 20:57:16 okay, good sign Jan 12 20:57:28 just wanted to make sure an existing environment builds okay Jan 12 20:57:44 it started building, quilt and other stuff Jan 12 20:57:46 maybe you should pastebin your bblayers.conf and local.conf (i assume they're in the same dir?) Jan 12 20:57:47 so that seems to work Jan 12 20:57:47 * kergoth nods Jan 12 20:57:57 go ahead and kill it, just wanted a sanity check on the environment Jan 12 20:57:59 heh Jan 12 20:58:21 they are, here for example: https://gitorious.digitalstrom.org/dss-oe/dss-oe/trees/master/targets/dss11-1gb-testing/conf Jan 12 20:59:56 OETREE in my case is the top directory, i.e. a `pwd` when being here in a checked out tree: https://gitorious.digitalstrom.org/dss-oe/dss-oe/trees/master Jan 12 21:00:57 you aren't adding your top dir to BBPATH Jan 12 21:01:01 which means it won't find and read your local.conf Jan 12 21:01:22 https://github.com/kergoth/oe-core-template/blob/master/conf/bblayers.conf Jan 12 21:01:59 but my local.conf is under /oe/jin/dss-oe/targets/dss11-testing/conf/local.conf Jan 12 21:02:42 and this directory is in $BBPATH Jan 12 21:02:58 ah, your local.conf is in a layer? hmmm. well, i'm rapidly running out of ideas Jan 12 21:03:04 heh Jan 12 21:03:08 no no, the local conf is not in a layer Jan 12 21:03:21 ? Jan 12 21:03:23 oh well, would you like to check out the tree? :) Jan 12 21:03:28 would be faster to try it Jan 12 21:03:28 that'd be easier, yeah :) Jan 12 21:04:11 git://gitorious.digitalstrom.org/dss-oe/dss-oe.git Jan 12 21:04:16 is the repo Jan 12 21:04:24 --recursive is for submodules? Jan 12 21:04:39 if yes you'll need it too, I'm not that fluent with git Jan 12 21:06:12 yep Jan 12 21:06:34 once you checked it out you source the setup script like this: Jan 12 21:06:49 source setup-oe-core.sh targets/dss11-testing Jan 12 21:07:13 after that I can bitbake something provided that I do not go to any other directory in this terminal Jan 12 21:07:20 k Jan 12 21:07:57 the targets dir holds only configs of what I want to build, i.e. local.conf and bblayers.conf Jan 12 21:08:05 ah, right, i see.. the issue is that bitbake looks for conf/bblayers.conf. you can't go above that dir or it won't be able to load it Jan 12 21:08:10 the layers themselves are under $TOPDIR/OE and $TOPDIR/dS Jan 12 21:08:11 hmmm Jan 12 21:08:26 and this did work with older bitbakes in oe classic Jan 12 21:08:55 this is how layers work, and have always worked. it finds conf/bblayers.conf, and loads it, and then loads all the layer.conf files, then loads conf/bitbake.conf from bbpath Jan 12 21:09:10 you could work around it, i fyou want to keep this setup Jan 12 21:09:23 work around by adding the path to bitbake.conf to $BBPATH too? Jan 12 21:09:33 I'd like to keep this setup, yes :) Jan 12 21:10:02 i'm not sure why you'd prefer env based to path based, but what we did for work was to create a little bitbake wrapper Jan 12 21:10:14 cds into $BUILDDIR (the top directory), then runs the real bitbake Jan 12 21:10:21 its temporary, until we change how we do our builds Jan 12 21:10:38 alternatively, you could set hte full BBPATH in the env and avoid the layer based configuration entirely Jan 12 21:10:44 ok so that means, the difference between my old setup and this one is that I simply did not use layers in classic? Jan 12 21:10:51 or rework your setup so you don't have a bunch of bblayers.confs deep in the tree Jan 12 21:10:52 yep Jan 12 21:11:06 afaict anyway Jan 12 21:11:57 well,there is only one bblayers.conf per active config Jan 12 21:12:47 so it's not "a bunch" for an active configuration, i.e. only one targets/xx dir is visible at a time Jan 12 21:12:49 well, i mean, put your bblayers.conf at toplevel, when all you have to be is anywhere under that, rather than deeper in tree Jan 12 21:12:56 s/when/then/ Jan 12 21:13:46 well, that won't make it possible to have different bblayers.conf files, right? Jan 12 21:13:51 that's what you meant by "a bunch"? Jan 12 21:14:31 but why does it matter anyway? the layers resolve to full paths, i.e. ${OETREE}/dS/meta-dss11-testing resolves to an absolute path Jan 12 21:14:50 or is the problem the order, that it looks for bitbakel.conf in the beginning, but would get it only after parsing BBLAYERS ? Jan 12 21:15:29 it won't find bblayers.conf at all unless you're cd'd into the dir its in, or below it Jan 12 21:16:27 so that means it's not searching in absolute $BBPATH? Jan 12 21:16:38 $BBPATH/conf rather Jan 12 21:16:39 ? Jan 12 21:16:42 bbpath is how it finds bitbake.conf, NOT how it finds bblayers.conf Jan 12 21:16:52 bblayers.conf is usually what *sets* bbpath Jan 12 21:16:55 so that'd be rather circular Jan 12 21:16:59 hmm Jan 12 21:17:11 and there is no env var for bblayers? Jan 12 21:17:26 no, the whole point of how it works was to avoid the over-dependence on env vars, afaik Jan 12 21:17:34 I see Jan 12 21:18:14 well, I guess if I want to stick to this setup I'll have to live with staying in a particular dir when building Jan 12 21:21:50 Jin^eLD, https://gist.github.com/1603201 is what i was talking about before. add the dir with that in it to the path ahead of the rest of the bits Jan 12 21:21:58 and set BUILDDIR or change it to whatever you already set Jan 12 21:22:15 basically it just cd's there for you based on the env, rather than having to cd there yourself Jan 12 21:22:26 thats what we're using so it behaves like the old oe for now Jan 12 21:22:34 i see, thanks Jan 12 21:22:43 np Jan 12 21:23:34 sorry for the hoops, took me a while to grasp what your root issue was :) Jan 12 21:23:46 np, thanks a lot for looking into it :) Jan 12 21:23:58 re Jan 12 21:23:58 at least I know the reasons now Jan 12 21:24:01 wb florian Jan 12 21:24:28 the idea behind using bblayers, imo, is rather "project" oriented. cd into your project area, build. could avoid setting many env vars at all Jan 12 21:25:17 well, I am not setting that much env vars; in classic I just hat my own recipe collection under targets/myconfig/recipes and oe.dev was in $TOPDIR/oe.dev Jan 12 21:25:36 now I am using layers instead of collections Jan 12 21:25:50 i mean things like bbpath Jan 12 21:25:56 and I put them somewhere else.. I figured this should not matter, but it all makes sense now of course, since you mentioned the bblayers.conf thing Jan 12 21:26:04 * kergoth nods Jan 12 21:27:02 my interpretation of BBPATH was wrong, I thought it would seach for conf/*.conf in $BBPATH Jan 12 21:27:10 i usually setup a completely different area for each machine/task i'm working on, including all the layers, but that's because i like to keep my metadata changes isolated Jan 12 21:27:13 and it does, but just not including bblayers :) Jan 12 21:27:18 exactly :) Jan 12 21:27:52 well, our metadata changes are isolated per custom layer :) Jan 12 21:47:58 Hi Jan 12 21:48:04 I need to update SRC_URI up to my some variables but I need nested if conditionals, Jan 12 21:48:10 so that I wanted to do it with python function as here: http://pastebin.com/N59EhhDd Jan 12 21:48:28 I can print end of function and see that it is changed Jan 12 21:49:12 that's wrong Jan 12 21:49:13 but when SRC_URI used in other function for instance in do_patch, I see updates are not appended to SRC_URI Jan 12 21:49:19 you want an anonymous python fucntion, or a RecipeParsed event handler Jan 12 21:49:24 tasks get isolated datastores Jan 12 21:49:29 intentionally, nothing they do affects any other task, ever Jan 12 21:49:47 so what is the correct way? Jan 12 21:50:40 http://pastebin.com/YxUarqyJ Jan 12 21:50:56 or Jan 12 21:50:57 http://pastebin.com/baV3czKN Jan 12 21:51:16 erm, the first example isn't quite right, need a d = e.data above the code and after the return Jan 12 21:52:20 by the way I am using OE-classic Jan 12 21:52:31 take your pick, either method will do. the first is an event handler, the second is an anonymous python function. both accomplish the same thing, they run at the end of the parse against the metadata Jan 12 21:52:34 it is valid for oe-classic right? Jan 12 21:52:48 RecipeParsed required a particular version of bitbake, but i'm not sure which one offhand. Jan 12 21:52:59 anonymous python has worked since shortly after we started the oe project Jan 12 21:53:19 ok I will check it right now Jan 12 21:55:10 I got error Jan 12 21:55:11 AttributeError: 'module' object has no attribute 'RecipeParsed' Jan 12 21:55:18 k, try the other one :) Jan 12 21:56:24 Does manual include instructions about anonymous python functions? Jan 12 21:56:48 maybe? Jan 12 21:57:48 unfortunately, it does not Jan 12 21:58:50 that's a glaring gap :\ Jan 12 21:59:11 they're all over the metadata, used whenever you need to programmatically manipulate the metadata Jan 12 21:59:20 well, its not the only way, but very common Jan 12 21:59:26 can I use base_conditional in another base_conditional :) Jan 12 22:00:33 well, base conditional looks at the content of the variable Jan 12 22:00:40 but there is a base_ifelse that acts solely on the arguments Jan 12 22:00:46 see utils.bbclass and lib/oe/utils.py Jan 12 22:01:42 ok Jan 12 22:23:49 kergoth: thanks, my base_ifelse conditions are not easily readable but at least it worked :) Jan 12 22:24:07 hehe Jan 12 22:24:18 oh, recent python lets you do one liner conditionals Jan 12 22:24:23 foo if this else that Jan 12 22:24:28 might be able to use that Jan 12 22:25:28 it is ok for now, thanks :) Jan 12 22:26:06 my son plays trainyard game and he builds this complex tracks for simple connections train keep going and going before they reach destination Jan 12 23:32:15 florian: k today just learned a bt on how to do package.bb's need to go to sleep can't be such a zombie tomorrow Jan 12 23:35:07 cs_nbp: very good... I'm still working. Have to get some important job done tomorrow. Jan 12 23:45:36 whooo jlime-base-image built! Jan 12 23:45:51 florian: only one lil prob: i added a directory next to the epdf and claws-mail directories in jlime Jan 12 23:46:02 florian: and put an emacs23.bb into it Jan 12 23:46:15 but now xorg is down so I can't build other stuff Jan 12 23:46:22 florian: then i of course put that into some jlime task directly under epdfview Jan 12 23:46:42 florian: but it says ERROR: Nothing RPROVIDES 'emacs23' Jan 12 23:46:55 florian: even if i bitbake the direct path Jan 12 23:47:07 florian: to the bb Jan 12 23:51:37 cs_nbp: first change the name of the bb... bitbake reads the version from the file name Jan 12 23:53:04 florian: so it should be emacs_23.1.bb? Jan 12 23:54:30 cs_nbp: Jan 12 23:54:55 cs_nbp: if 23.1 is the version number then this would be what you want Jan 12 23:55:52 florian: or should it hace the same name structure the .tar.gz has? Jan 12 23:57:52 cs_nbp: not always... in most cases yes when you have properly named archives, but there are quite some one with less common names. Jan 12 23:58:32 florian: so the version name is something that has to be there but that I can make up in principle? Jan 12 23:59:12 florian: not that it would be advised to do so Jan 12 23:59:50 cs_nbp: right Jan 13 00:00:46 but anyways 23.1 is the correct version Jan 13 00:01:04 firefox will be at 23.1 in 4 weeks Jan 13 00:01:25 cs_nbp: it is a good idea to follow common conventions so that the package manager is able todifferentiate between older and newer Jan 13 00:01:31 :-) Jan 13 00:02:03 florian: well ill try to find some of those common conventions, i guess in the manual Jan 13 00:02:21 cs_nbp: Jan 13 00:03:14 cs_nbp: oops... no, but just like at some software around. usually its something like major.minor Jan 13 00:03:39 florian: ah k, i do that anyways to less confuse myself Jan 13 00:04:23 florian: so ill add some _23.1.2012_r1.bb or so Jan 13 00:04:53 ok i really need some sleep today :D Jan 13 00:05:20 cyaZ tomorrow (and good luck w ur 'thing' tomorrow) Jan 13 02:07:23 hello, I have a question regarding drivers for OE. If I have a driver for a device that works with x86 linux (lets say it's a USB video capture device), will this driver be compatible with an Angstrom distribution? If not is there a guide for writing/porting drivers to OE? Jan 13 02:08:14 angstrom for Omap 3 **** ENDING LOGGING AT Fri Jan 13 02:59:57 2012