**** BEGIN LOGGING AT Wed Dec 08 02:59:57 2010 Dec 08 05:45:13 hey, is there away to configure busybox? Dec 08 05:46:09 compile time, IIRC it uses a defconfig or so Dec 08 06:17:49 no menuconfig type of option? Dec 08 06:38:21 gandhijee: I guess you could create a config using menuconfig, but that's not exactly part of OE. OE just builds what it has. You might get away with that dev shell or what it's called. Dec 08 06:38:48 bitbake prepares everything for compiling the package and drops you to a shell. never used that though. Dec 08 08:46:30 i am not using chrooted environment for my oe buildup Dec 08 08:46:53 can i create my oe root directory in $HOME Dec 08 09:19:46 ksinkar: yes Dec 08 09:20:49 imho, this setup is widely used Dec 08 09:22:52 hmm, where would i get the vanilla arm kernel if i would like to compile it by hand? Dec 08 09:25:38 atiti: kernel.org? Dec 08 09:25:54 there is only one kernel :) Dec 08 09:26:08 but you can compile it for arm Dec 08 09:26:29 arent there a set of patches that need to be applied? Dec 08 09:28:52 afaik, vanilla almost working on Zauruses already Dec 08 09:29:09 cool, what is missing Dec 08 09:29:11 except power management, but anyway there are no patches for this Dec 08 09:29:30 03Roger Monk  07org.openembedded.dev * r05a76eb70f 10openembedded.git/recipes/ti/ti-framework-components_2.26.00.01.bb: Dec 08 09:29:30 ti-framework-components: Add v2.26.00.01 Dec 08 09:29:30 * Add v2.26.00.01 Dec 08 09:29:30 Signed-off-by: Roger Monk Dec 08 09:29:30 Signed-off-by: Koen Kooi Dec 08 09:29:33 atiti: ask ant about this Dec 08 09:29:35 03Roger Monk  07org.openembedded.dev * rfc91ef014e 10openembedded.git/recipes/ti/ti-codec-engine_2.26.02.11.bb: Dec 08 09:29:35 ti-codec-engine: Add version 2.26.02.11 Dec 08 09:29:35 * Add version 2.26.02.11 Dec 08 09:29:35 Signed-off-by: Roger Monk Dec 08 09:29:36 Signed-off-by: Koen Kooi Dec 08 09:30:08 anyway, ill try to compile the latest one from kernel.org then, thanks jay7 :) Dec 08 09:30:18 atiti: you can look an recipes/linux directory :) Dec 08 09:31:19 well.. Dec 08 09:31:46 * Jay7 was started http://www.kexecboot.org Dec 08 09:31:55 now we have place for docs Dec 08 09:34:10 nice Dec 08 10:01:53 Hi all.. I have submitted patches to OE on 30th nov but i didnt got any reply comments ... please have a review on the patches and let me know ur valuable feed back . my patches are for am3517-crane board. Dec 08 10:57:09 mmh... recent binutils-git give 'Error: SVC is not permitted on this architecture' when building for a cortex-m3 :( Dec 08 11:48:36 gm Dec 08 11:50:43 has anyone here used crosstool-ng Dec 08 11:51:20 ksinkar: yes, but it's off-topic Dec 08 11:57:29 likewise: i am trying to link the crosstool-ng toolchain with my oe env Dec 08 13:50:50 Anyone awake that remembers what the actual mechanic to neuter install -s that we use is? Dec 08 13:51:34 ah, there Dec 08 13:51:43 setting STRIP to something else Dec 08 13:52:50 Er, that's not neutering it, it's just making it have a valid strip... Dec 08 13:55:18 hmm, i thought we were patching coreutils-native to neuter it, not just make it use STRIP Dec 08 13:55:20 * kergoth scratches head Dec 08 13:56:21 So did I, but I don't see it Dec 08 13:56:29 I see a patch to coreutils-6.0 to obey STRIP Dec 08 13:56:32 And nothing else Dec 08 13:57:28 hmm Dec 08 13:58:43 i can't find it.. but i can't believe that we wouldn't be doing that, as far as i knew its the only reason we need coreutils-native at all Dec 08 13:58:47 strange Dec 08 13:58:51 i hope we're missing something :) Dec 08 13:58:58 yeah Dec 08 13:59:25 i do have a patch which drops coreutils-native and uses an install wrapper to kill it -- not sure if that's an ideal solution, but it does work Dec 08 13:59:39 k Dec 08 13:59:56 I'm thinking about a class to check for lsb installed modules and bump up ASSUME_PROVIDED based on Dec 08 14:00:03 Since that does mandate install, but not the behavior of it Dec 08 14:01:08 https://github.com/kergoth/openembedded/commit/d066be77b3a6a236a83c2f69cacd5477e629834c - my only concern with this style solution is performance impact due to the extra layer of indirection, but i doubt its statistically significant to a build Dec 08 14:18:48 Hmm, *if* use of a wrapper does affect performance, could always make it optional, and make it fail out when -s is used, as a way to at least identify the makefiles that need patching Dec 08 14:30:13 kergoth_: My gut feeling is that we're going to end up with a set of "deep" sanity testing build modes Dec 08 14:30:39 kergoth_: Ones which are too slow to use on a day to day basis but are good to run once in a while to detect problems creeping in Dec 08 14:31:09 agreed. Dec 08 14:31:16 i expect most people don't know recipe_sanity exists.. Dec 08 14:31:17 heh Dec 08 14:34:34 kergoth_: swabber is another example Dec 08 14:35:08 i have one that runs checkbashisms against all shell scripts in ${S} to try to start avoiding the need for /bin/sh being bash Dec 08 14:35:15 but that one dies on ./configure, not a good sign :) Dec 08 14:35:55 There's definitely a need for some "once a week" type builds to be run with extra sanity checking stuff done Dec 08 14:46:51 damnit, i keep forgetting to bring my toasted motherboard up to the mail box place to send it in for RMA.. would be nice to have a functional desktop sometime this year Dec 08 14:50:01 Tartarus: I'm hoping to get to the point we can do that with the core Dec 08 14:50:30 RP__: what's blocking? A lack of resources or something else? Dec 08 14:50:38 I just might be able to throw resources at the problem :) Dec 08 14:50:47 (s/resources/compute resources/) Dec 08 14:50:51 RP__: If I want to stop bitbake from returning 1 in the case of non-fatal errors - what would I have to touch? Dec 08 14:51:22 if its non-fatal, it doesn't return 1. what exactly are you seeing? Dec 08 14:51:43 florian: return_value = 1 in knotty.py in MsgError Dec 08 14:51:55 oh, right Dec 08 14:51:58 That's what I thought as well Dec 08 14:52:03 that's .. not right Dec 08 14:52:24 kergoth_: why not? An error occurred... Dec 08 14:52:39 Tartarus: Its really a problem that we're still getting features sorted out and haven't had time to work on the sanity tests Dec 08 14:52:42 current master doesn't do that. Dec 08 14:52:49 The behaviour has changed a while ago... here it returns 1 e.g. i I want to build two targets providing the same. Dec 08 14:53:02 1.10.1 does Dec 08 14:53:05 because what bitbake calls an error really isn't an error. Dec 08 14:53:35 right... i would make this a warning anyway. Dec 08 14:53:37 bitbake's error is what most tools would call a warning Dec 08 14:53:41 * kergoth_ nods Dec 08 14:53:44 heh Dec 08 14:53:53 kergoth_: bb.warn means its a warning, bb.error means something should be fixed. I'm therefore not unhappy with what bitbake is doing Dec 08 14:54:10 kergoth_: The fact that bb.warn isn't used so much is bad Dec 08 14:54:46 uh, an "error" which is just something that should be fixed describes a warning pretty well, in my opinion Dec 08 14:54:59 i don't think there's a need for an "error" that isn't fatal, personally Dec 08 14:55:09 and i think its the reason no one uses warn Dec 08 14:55:39 but /shrug, i don't feel very strongly about it Dec 08 14:56:36 hmm Dec 08 14:57:35 kergoth_: Its partly a user perception thing. Seeing Error on the screen is bad Dec 08 14:57:50 kergoth_: We're way too close to bitbake to see that though Dec 08 14:58:58 well, bitbake spits out way too much crap to begin with, its impossible to tell what's important and what isn't. we need to audit all output, both the log levels used (error, warning, etc) and the content, and whether it should be shown at all Dec 08 14:59:10 kergoth_: no disagreement Dec 08 14:59:32 kergoth_: But I think gently moving some errors to warnings would be a good move Dec 08 14:59:40 agreed Dec 08 15:01:09 i guess we can summarize it as: warning = someone's doing something questionable, fix it. error = something went *wrong*, but we can continue, fatal = something went *wrong* and we can't continue. so i guess you're right, given that, it makes sense to exit with 1 when an error is seen, but effectively I think we shouldn't do that until after a messaging audit Dec 08 15:02:45 anytime we exit nonzero, somebody's tinderbox may go red, so we need to avoid that happening unnecessarily Dec 08 15:03:33 aside: /usr/bin/time -a -f %e -o somefile is handy Dec 08 15:03:54 run a command under that multiple times, you get somefile with a list of times in seconds, one line per execution Dec 08 15:04:42 (note: have to use /usr/bin/time or $(which time), the shell builtin for time isn't as capable as the real one) Dec 08 15:12:31 * kergoth_ mutters Dec 08 15:21:31 mmm, donut Dec 08 15:31:32 hrm Dec 08 15:33:36 How do I use meta-toolchain-qte with qt-4.7.1. According to http://docs.openembedded.org/usermanual/html/ch05s08.html Dec 08 15:34:09 the produced tar.gz file should contain everything I need. Dec 08 15:35:44 morning kergoth_ Dec 08 15:35:50 hey pb__ Dec 08 15:36:03 I don't know, but there seems to have been a change and meta-toolchain-qte provides a bunch of packages instead Dec 08 15:36:16 risca: what do you mean? Dec 08 15:36:42 anything you build is going to emit packages in deploy/{ipk,deb,rpm} -- for the meta toolchain, you want the tarball in deploy/sdk, iirc Dec 08 15:37:12 Yeah, but the contents of that tarball is a bunch of ipk packages Dec 08 15:37:22 Not what I suspected Dec 08 15:37:28 hmm, strange Dec 08 15:37:29 Note: Qt 4.7.1 Dec 08 15:41:51 * kergoth_ continues performance testing separate-ui-and-server branch Dec 08 15:42:25 foerster|away: any news on the work you were doing to fix the partial cache saving on interrupt and the like? Dec 08 15:43:22 Hmm, strange... I must have untarred something wrong. Now everything is there Dec 08 15:43:27 Forget I asked :P Dec 08 15:43:29 hehe Dec 08 15:44:28 kergoth_: haven't had a chance to look at it lately. Have a big project supposed to be done by end of year, so been swamped with that. Dec 08 15:44:34 I got it close, but had to put it down. Dec 08 15:44:49 Was was basically the ordering of shutdown stuff that was happening. Dec 08 15:44:50 ah, np Dec 08 15:45:13 been on this damn new product for 8 months Dec 08 15:45:21 the finish line is in sight, woohoo Dec 08 15:45:27 * foerster does a little happy dance Dec 08 15:45:41 i guess we need to ensure that the cookerShutdown initiates a cookerparser shutdown if it was parsing at the time Dec 08 15:46:01 right, and I had some issues with ordering wrt queue closing/etc Dec 08 15:46:25 okay, i think that part should be gone now, i reworked parsing to use a pool, its much less error prone in that way now Dec 08 15:46:31 don't have to worry as much about deadlocking Dec 08 15:47:12 cool. where do you have that? I can rebase my stuff on it when I get a chance. Dec 08 15:47:21 current master Dec 08 15:47:23 ok Dec 08 15:47:52 i have it modified (locally) to call parser.Shutdown if cookerState is cookerParsing Dec 08 15:47:58 i was running into a queue issue there Dec 08 15:48:02 maybe your changes will assist me Dec 08 15:49:01 yeah i saw that bit in the branch commented out, was tempted to mess with it but figured I'd check on status Dec 08 15:49:32 let me spend a few minutes here. I'll try to rebase onto current master (and see what horrible death that causes me). Dec 08 15:49:55 although you already did it once, so hopefully it won't be too bad Dec 08 15:50:52 there's no rush, plenty of other work to be done, but we should consider whether this should go in for the next release or not -- planning on doing one with parallel parsing + the poky bitbake changes once they're fully synced Dec 08 15:51:46 ok. Well, I wouldn't let this hold up a release. The parallel parsing is the big ticket item which will directly affect everyone (in a good way). Dec 08 15:51:49 * kergoth_ nods Dec 08 15:52:11 my time will be greatly limited til after the first, as the bosses want this product done Dec 08 15:52:24 this is primarily a step in the right direction more than a big win by itself, a start to simplifying and cleaning up the way the bits interact Dec 08 15:52:31 np Dec 08 15:52:40 yea. I think we can do a lot of things nicer/better. Dec 08 15:53:00 and performance wise, the separation didn't seem to affect us negatively. Dec 08 15:53:36 although, the firther I did in, the more I cringe :) Dec 08 15:53:40 further* Dec 08 15:53:54 hehe Dec 08 15:54:03 i think thats the case with most of bitbake at this point Dec 08 15:54:37 git stash is fun Dec 08 16:07:41 i wonder why the atexit sync of the cache doesn't work with the split. it worries me, if the server process is exiting without running those.. Dec 08 16:07:44 hmm Dec 08 16:08:10 I'm guessing it's something I don't fully understand about multiprocessing.Process or something Dec 08 16:08:30 That's why I had to put in the hooks to call cooker.Shutdown (which calls parser.shutdown) in the first place Dec 08 16:08:37 * kergoth_ nods Dec 08 16:09:09 * foerster is rebasing onto master, requiring a fair bit of manual intervention Dec 08 16:10:48 if its looking painful and you don't have a ton of time to spend, dont' worry about it, i can look into it Dec 08 16:11:22 i'm almost through it (i think). Dec 08 16:11:53 looking at the cache.py right now where you switched to use pickled Dec 08 16:12:03 you're not throwing any cache parse events - should I just leave that off for now? Dec 08 16:12:11 hrm... is it possible bitbake 1.10.1 still advertises itself as 1.10.0? Dec 08 16:15:56 foerster: i figured your branch can add them -- they aren't of very much use without the ui/server split Dec 08 16:16:10 florian: its possible, might have not bumped the version Dec 08 16:16:32 kergoth_: obviously... Dec 08 16:16:54 kergot_: right. I just removed then for this rebase - I'll add them back in later since we'll have to look at the file progress or whatever Dec 08 16:22:36 florian: if thats the case, might want to get a 1.10.2 out shortly Dec 08 16:22:53 * foerster tests the result of massive rebase :) Dec 08 16:23:07 * kergoth_ is battling the atexit issue Dec 08 16:23:23 "__version__ = "1.10.0"" Dec 08 16:23:43 kergoth_: yes... just found it in bitbake Dec 08 16:24:31 kergoth_: that's always a good sign when you run bitbake -p, and it immediately returns to the prompt lol Dec 08 16:26:01 d'oh, I see what I did Dec 08 16:30:31 kergoth_: i think the interrupt during parsing works now Dec 08 16:40:43 anyone ever seen a glibc do_package failed with 256 - Task failed: localedef returned an error ... http://pastebin.com/9f1ebBzi Dec 08 16:40:47 hey - is there any documentation on how to use BBLAYERS and .bbappend recipes? Dec 08 16:41:39 CMoH|office, I don't believe so other than the maillist - search there Dec 08 16:42:03 yay - i found it http://sakrah.homelinux.org/ Dec 08 16:42:09 http://sakrah.homelinux.org/blog/2010/11/bblayers-bbappend/ Dec 08 16:42:16 for bbappend its very simple - you have to use bitbake master as version with it hasn't been released yet. You simply put a $PN.bbappend in the filespath and it will be appended to the recipe Dec 08 16:42:45 but take a not, that some recipes don't work with bbappend :) Dec 08 16:42:56 I was told that wasn't all that correct with regards to BBLAYERS Dec 08 16:42:59 for me it's lcdproc for example, but didn't time to dig into it deeper yet Dec 08 16:43:06 s/not/note/ Dec 08 16:43:30 ynezz, well... you surely have to have to tailor your bbappend per recipe but I can't see how it wouldn't work Dec 08 16:43:56 it isn't $PN.bbappend Dec 08 16:43:56 simply it doesn't :) Dec 08 16:44:00 it's based on the .bb filename Dec 08 16:44:28 its location doesn't matter, only the filename. s/.bb$/.bbappend/ to the fn and make sure the bbappend is in BBFILES Dec 08 16:44:42 I have like 20 .bbappend recipes which works Dec 08 16:44:57 I did the same for the lcdproc and it does not work, that's all Dec 08 16:45:24 ynezz, bitbake 'will' append the recipe.... its your contents of the bbappend that are wrong :P Dec 08 16:45:40 it's usually SRC_URI_append Dec 08 16:45:55 yep. if the bbappend has the right filename, it will be appended, period Dec 08 16:45:56 thats the trap I fell into... that completely depends on the recipe Dec 08 16:46:21 for example if the recipe uses SRC_URI_ anywhere then you do 'not' use SRC_URI_append for that machine Dec 08 16:46:38 as the SRC_URI_ will replace SRC_URI and your append will do nothing Dec 08 16:46:48 and you'd be bitten just as well by using SRC_URI_append in the recipe as in the bbappend, the behavior is exactly the same, not bound to bbappend Dec 08 16:47:01 agreed Dec 08 16:47:28 thanks for that. when's bitbake gonna be released? Dec 08 16:47:37 with this feature i mean Dec 08 16:47:59 soon Dec 08 16:48:01 the caviot with bbappend is that you should pin your versions so that your bbappend doesn't get lost if the recipe bumps to a new 'version' (requiring you to add a new bbappend) Dec 08 16:48:09 so what's wrong with this include? http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/lcdproc/lcdproc5.inc Dec 08 16:48:13 for bbappend I mean Dec 08 16:48:26 getting a new release out is a priority for both bbappend availability and parallel parsing Dec 08 16:48:27 ah, tharvey, i thought this would be one of the advantages of it Dec 08 16:49:03 CMoH|office, I agree - I see it as an advantage as well - your bbappend should depend on what your appending Dec 08 16:49:35 parallel parsing is awesome! been using it a week now and am very happy with the performance Dec 08 16:49:41 glad to hear it Dec 08 16:50:12 ynezz, can't say whats wrong with your file without seeing the actual recipe (not the inc) and the bbappend and knowning what machine/distro your bitbaking for (depending on onverrides) Dec 08 16:50:20 well, its an advantage and a disadvantage. yes, you should really know what you're appending to, but on the other hand, there's no easy way to tell if your local changes *aren't* being applied to the current built version Dec 08 16:50:31 I'm betting your getting lost in an override - I found bitbake -e to be very useful when working on bbappend's Dec 08 16:50:38 possibly need a bitbake option to warn if one version of something is appended, but the current one isn't, or something Dec 08 16:51:08 tharvey: I've tried the -e but didn't see anything, it got parsed but nothing appended Dec 08 16:51:29 ynezz: set FOO=bar in the .bbappend Dec 08 16:51:32 bitbake -e | grep \^FOO Dec 08 16:51:39 er, bitbake -e lcdproc that is Dec 08 16:51:44 kergoth_, you mean some warning that tells you if there is a bbappend in your layer that is not being used? b/c you can perhaps assume if you have a bbappend it should always be used? not sure you can make that assumption Dec 08 16:51:54 kergoth_: ok, will try that Dec 08 16:52:19 tharvey: that's why i said it should be both opt in and a warning. worst case, if you explicitly don't want any local changes to a newer version, you could ignore the warning or touch an empty bbappend for it Dec 08 16:52:45 ynezz, bitbake -e shows you the vars after parsing/processing - if you put something like a SRC_URI_append in your bbappend and don't see it with bitbake -e then your likely hitting an override in the original recipe and your bbappend is wrong Dec 08 16:53:12 a warning/error would be better than a silent change Dec 08 16:53:16 kergoth_, I can see that being useful Dec 08 16:53:22 which you then have to dig for Dec 08 16:53:56 tharvey: i'd think of it being yet another opt-in sanity check -- we have a lot of those Dec 08 16:53:59 hmm Dec 08 16:54:11 an option that errors on such event I would like better than some warning you have to grep for Dec 08 16:54:58 a class you inherit that will error if any bbappend is found that is unused? although bbappend is a bitbake thing and not a oe class thing Dec 08 16:55:36 it might be hard to implement in the metadata. we can inspect BBFILES, but what version of something is going to be built is in the runqueue, which isn't safely accessible from the metadata Dec 08 16:55:55 there's no hooks for before a build starts, with access to the list of tasks about to be built, today Dec 08 16:56:38 JaMa|Off: piiiing Dec 08 16:57:05 seems like if its simply a cmdline option to bitbake it can get easily forgotton - what about based off a var which can be set in a conf file? Dec 08 16:58:32 well, for me a command that prints all orphaned .bbappend recipes to a file would be enough Dec 08 16:58:57 i could make an external script that compares that to a reference file and mail me if they differ Dec 08 16:59:19 Is there someone that work if EFL? Dec 08 16:59:27 I would like something that I could put in my local.conf Dec 08 17:00:02 oh, oh... by the way.... can i have more config files in builddir/conf (where local.conf is) Dec 08 17:00:14 why wouldn't you be able to? Dec 08 17:00:36 well, say i wanna supply a default local.conf that could be overwritten by a developer Dec 08 17:00:37 bitbake isn't magic. people seem to think it is. when bitbake starts, it finds conf/bitbake.conf in BBPATH and loads it. that's all that happens for the config Dec 08 17:00:51 bitbake.conf happens to include conf/local.conf, which it finds in BBPATH also Dec 08 17:00:53 that's it Dec 08 17:01:06 is there any "if i exists load it, else don Dec 08 17:01:09 't" Dec 08 17:01:14 that's called "include" Dec 08 17:01:21 and is how local.conf is loaded Dec 08 17:01:23 sry, misstyped Dec 08 17:01:32 local.conf is technically optional, its just that oe won't work right without the vars you set there Dec 08 17:01:45 ah, well.. i assumed "include" errors if the file is not found Dec 08 17:01:52 "require" does that Dec 08 17:02:02 cool! Dec 08 17:02:25 and i both files set a value, which one has priority? Dec 08 17:03:16 okay, i've found some answers - thanks for your help :) Dec 08 17:07:02 kergoth_: getting closer here. Running into: File "/home/foerster/dev/openembedded/dev/bitbake/lib/bb/cache.py", line 412, in sync Dec 08 17:07:02 for key, value in self.depends_cache.iteritems(): Dec 08 17:07:03 RuntimeError: dictionary changed size during iteration Dec 08 17:07:18 when I call parser.shutdown(False) Dec 08 17:07:44 seems odd, as the pool should have been joined by then Dec 08 17:11:27 hmm, that is strange Dec 08 17:11:54 since that throws an exception, my process sits in limbo Dec 08 17:12:02 turns out that multiprocessing uses os._exit() to quit its processes, and has its own finalizer stuff, but doesn't appear to run the atexit/sys.exitfunc bits Dec 08 17:12:27 hm. Well, I have a hook in place in my server to make sure the cache sync is always joined Dec 08 17:12:32 (when you exit with os._exit, the atexit funcs aren't calle) Dec 08 17:12:33 * kergoth_ nods Dec 08 17:12:38 * kergoth_ looks at shutdown again Dec 08 17:13:57 evening Dec 08 17:16:43 something weird is going on. It seems that even though I say "server.stop", it isn't stopping any more. That leads me to believe it got an exception somewhere (which wasn't handled or printed) Dec 08 17:19:25 kergoth_: I have to take off for now. I'll try to keep digging into this later. Dec 08 17:20:05 gah, need to handle interrupts during cache load too -- at that point the cooker parser hasn't even begun to work, much less in a state where it can be shutdown cleanly.. Dec 08 17:20:09 * kergoth_ grumbles Dec 08 17:20:34 ok. In my version, that shouldn't matter, as SIGINT is blocked for everything Dec 08 17:20:42 only UI gets sigint Dec 08 17:20:44 not sure what you mean. Dec 08 17:20:51 the UI still needs to be able to shut down the server Dec 08 17:21:02 which is a tad difficult to do cleanly when the parser is still beign constructed Dec 08 17:21:09 ah Dec 08 17:21:12 gotcha Dec 08 17:21:25 anyway, later :) Dec 08 17:21:35 got it. later. Dec 08 17:21:53 and that may be it - i have a message in my server loop, so i was hitting ctrl quickly Dec 08 17:21:54 :) Dec 08 17:23:54 could shift cache load into a thread, make parse_next a no-op until the load completes, let shutdown() kill off the thread if it has to Dec 08 17:25:28 its either that or we give cache loading an async api and utilize that Dec 08 17:27:54 oh, i see why the depends_cache thing is happening Dec 08 17:28:02 i think Dec 08 17:29:44 * kergoth_ fixes Dec 08 17:30:53 hrm Dec 08 17:34:40 hmmm Dec 08 17:38:38 what exit code are apps supposed to exit with for SIGINT? Dec 08 17:38:39 hmm Dec 08 17:41:31 does someone know if there is a n OE MACHINE profile that target armv7 and directfb ? Dec 08 17:41:52 for uncaught signals, the exit code is 128 + signum Dec 08 17:44:12 i assume it varies when caught, no standard Dec 08 17:51:16 whew, think i got it Dec 08 18:16:17 anybody knows what the hell has happened to OE git? where's the history for the past 2 days? Dec 08 18:17:25 more specifically, why master is not the same as org.openembedded.dev anymore? Dec 08 18:49:51 false alarm, sorry. old page got cached somewhere - refreshed several times and now see the latest history Dec 08 18:50:17 damnit Dec 08 18:50:18 hrm Dec 08 18:50:57 * kergoth_ somehow broke -p in fixing this other issue Dec 08 18:56:58 kergoth_: having fun I see :) Dec 08 18:57:30 ensc|w: hmmm does that come with the recent update I did or it was there already Dec 08 18:58:00 gm all Dec 08 18:59:49 foerster: if you run process.shutdown() from cooker.shutdown(), i'm thinking its a race -- ui runs cooker.shutdown() via xmlrpc while the parser is running. if instead we set cookerState to cookerParsed, just as a way of indicating we shouldn't keep looping for more parsing, then the updateCache() call will end early, the command will finish early, and the server can then exit cleanly Dec 08 18:59:58 thats my theory, anyway Dec 08 19:01:07 cookerParsed would mean it has finished parsing Dec 08 19:01:14 i know Dec 08 19:01:20 successfully Dec 08 19:01:23 i know. Dec 08 19:01:28 i jsut read the code that uses it two seconds ago Dec 08 19:02:04 is it for breaking the execution in middle ? Dec 08 19:02:35 yeah, need to interrupt the parsing cleanly, and the command code loops on cookerParsed. guess i can add a new state to make it clearer Dec 08 19:02:49 yes new state wuld be better Dec 08 19:03:12 in gcc front end there is error recovery module Dec 08 19:03:25 when sudden breaks are found Dec 08 19:03:47 they get executed from signal handlers Dec 08 19:03:53 one annoying thing is cooker has *two* items of state. clean/parsing/parsed and then run/shutdown/stop Dec 08 19:04:00 and they're independent, for no apparent reason that i can see Dec 08 19:04:08 hmmm Dec 08 19:04:10 considering the cooker can't run tasks until its parsed Dec 08 19:04:25 kergoth_: I'll play with it later this afternoon to see what I can get working Dec 08 19:04:42 right I think two states could be troublesome to synchronise in meaning and state itself Dec 08 19:04:46 have a 2 hour meeting starting right now Dec 08 19:04:59 the alternative would be to do if cookerState != cookerParsed and cookerAction not in (cookerStop, cookerShutdown) Dec 08 19:05:01 foerster: in some meetings I can code :) Dec 08 19:05:02 in multiple places Dec 08 19:05:04 which is pretty lame Dec 08 19:05:24 kergoth: I think unifying states would be better imo Dec 08 19:05:29 agreed Dec 08 19:05:34 i just don't know if i feel like doing that right now Dec 08 19:05:36 hehe Dec 08 19:05:41 heh LSB 4.1 is released Dec 08 19:05:42 * kergoth_ grumbles Dec 08 19:06:01 khem: it's due to a recent binutils-git update; it was added to to binutils head in september http://sourceware.org/ml/binutils/2010-09/msg00413.html Dec 08 19:06:04 khem: I hear ya, and I probably will - though I have to be semi-alert for this, as it's a conference call meeting :) If they ask me something, I have to be half alert! Dec 08 19:06:12 khem: I wrote upstream report http://sourceware.org/bugzilla/show_bug.cgi?id=12296 Dec 08 19:06:27 foerster: well ask again ? Dec 08 19:06:50 heh say couldnt hear problem in telephone line voice is breaking etc. :) Dec 08 19:07:03 and of course, some of this async stuff could likely just go away with the server/ui split Dec 08 19:07:05 there are many execuses to cover up Dec 08 19:07:07 hrm Dec 08 19:07:10 khem: that's realistic - we all use voip, and quality tends o not be great Dec 08 19:07:18 I know Dec 08 19:07:37 khem: for now I hack around it with https://www.cvg.de/people/ensc/cortex-svc.patch Dec 08 19:08:00 in fact, i just had to have my mother in law stop playing mickey mouse videos for my 1 year old daughter up stairs, as it was eating all my bandwidth Dec 08 19:08:42 ensc|w: how can that patch impact m3 ? Dec 08 19:08:48 foerster, heh Dec 08 19:08:55 that's when it's time to cache some stuff locally :) Dec 08 19:09:08 khem: cortex-m3 is armv7 Dec 08 19:09:44 Tartarus: I'll need to. Mother in law goes just searches on youtube right now for videos Dec 08 19:10:12 ensc|w: yes but the patch seems not to modify v7 Dec 08 19:11:24 ensc|w: I see nevermind Dec 08 19:11:37 That said, I need to myself. Just got a boxee box (xmas gift from the family to the family :)) Dec 08 19:11:37 ensc|w: you should propose this patch for OE Dec 08 19:12:08 heh Mother in laws are always interesting creatures Dec 08 19:12:17 khem: I really do not know whether this is the right place... (and for what prohibiting 'svc' is good) Dec 08 19:12:39 are there really some arm architectures which do not have 'svc'? Dec 08 19:13:11 ... and is cortex-m3 really interesting for OE? ;) Dec 08 19:13:44 (it's a plain mcu without mmu and linux is not running there) Dec 08 19:13:54 ensc|w: likewise was experimenting with it Dec 08 19:14:02 ensc|w: yes some armv6 dont have it Dec 08 19:14:52 ah ok; I will post some patches to the maillist... Dec 08 19:16:43 kergoth_: can we use test for cookerAction == cookerShutdown like we do with the runqueue? Dec 08 19:17:05 b/c that will get set appropriately Dec 08 19:17:12 give me a second, testing a merging of cookerState/cookerAction Dec 08 19:17:17 :) Dec 08 19:18:41 switching to this process based server will make all other code nicer, as you won't have to worry about intrusive user interrupts Dec 08 19:23:15 ensc|w: btw the patch should be added to M3 define if available and not to general armv7 Dec 08 19:24:22 hmmm yesterday I tried to boot uclibc/nptl OE system for arm,mips,ppc,x86 and only mips booted well :(, x86 had issues with qemu-native otherwise when I booted it with qemu from my distro it booted too Dec 08 19:24:30 but arm and ppc simply crashed Dec 08 19:24:40 I hate to debug dynamic linker Dec 08 19:24:53 and seems there is no other way Dec 08 19:25:05 we should be more careful to test commits to uclibc Dec 08 19:25:47 :wq Dec 08 19:25:48 bah Dec 08 19:26:28 :wq should save the world and quit Dec 08 19:26:32 :) Dec 08 19:29:26 kergoth_: I just checked for cookerShutdown in parse_next, seems working pretty well at first glance. Dec 08 19:30:12 have to be careful messing with this stuff, can end up running parser.shutdown() more than once, etc. i ended up adding a 'active' member to the parser Dec 08 19:31:11 ok. added if self.cooker.cookerAction == cookerShutdown: Dec 08 19:31:11 self.shutdown(clean=False) Dec 08 19:31:11 return False Dec 08 19:31:18 added that to very beginning of parse_next Dec 08 19:31:19 hmm Dec 08 19:31:27 m4 did not install in the image I think Dec 08 19:32:18 no Dec 08 19:33:16 http://pastebin.com/7MCz6xRi Dec 08 19:33:43 why is autom4te trying to run m4 from the sysroot directory? Dec 08 19:34:03 foerster: there's a function in command.py that keeps running updateCache() as long as cookerState isn't cookerParsed Dec 08 19:34:47 khem, do you have any idea on this? http://permalink.gmane.org/gmane.comp.handhelds.openembedded/40363 Dec 08 19:35:01 is this a gcc or binutils or lib regression? this used to work Dec 08 19:35:08 kergoth_: when parse_next returns false, updateCache sets cookerState to cookerParsed Dec 08 19:35:10 and to be safe, you need to check for cookerStop too everywhere you check for cookerShutdown, in case you hit ^C multiple times in a row quickly Dec 08 19:35:20 ah Dec 08 19:35:33 such a mess :) Dec 08 19:35:36 :) Dec 08 19:36:30 well, the good news, is that other than this, the server is always make sure cached is sync'd too Dec 08 19:37:01 * kergoth_ isn't a big fan of async code with state machines Dec 08 19:37:17 well, 'twas once necessary Dec 08 19:37:24 yep Dec 08 19:37:48 would be a fairly dramatic shift to move away Dec 08 19:37:57 meaning lots of stuff in server/cooker/etc would change Dec 08 19:37:58 *cough*rewrite*cough* Dec 08 19:38:05 baby steps Dec 08 19:38:07 lol Dec 08 19:38:13 one of the biggest annoyances i have with this stuff is how intertwined everything is Dec 08 19:38:19 you're telling me Dec 08 19:38:22 you can't replace components without modifying EVERYTHING Dec 08 19:38:25 hehe Dec 08 19:38:26 as an outsider looking in, I go WTF Dec 08 19:38:42 cooker has self.parser. parser has self.cooker huh? Dec 08 19:39:10 everything has reference to everything Dec 08 19:39:20 * foerster smashes head against desk Dec 08 19:40:42 btw: anyone an opinion on this: http://article.gmane.org/gmane.comp.handhelds.openembedded/40301 (and if you agree can I have an ack and if not please tell why) Dec 08 19:41:01 I'd like to try rewriting runqueue. i think its the worst offender in that area. though the command/cooker thing is annoying Dec 08 19:41:07 have you seen how the commandline is handled? Dec 08 19:41:27 the cooker parses it, the ui asks the cooker for it, then sends it back to the cooker to run the command it got from the cooker.. what? Dec 08 19:41:49 :) Dec 08 19:41:53 if the cooker is the one parsing teh commandline, why the hell do i have to ask it for it and then hand it back? that's just .. ugh Dec 08 19:42:16 I found that odd too Dec 08 19:52:21 kergoth_: how did you implement cache load progress file file info before? Dec 08 19:52:24 fidencio: p o ng Dec 08 19:55:47 khem, ping Dec 08 19:56:22 foerster: https://github.com/kergoth/bitbake/commit/466a59ae#L2R192 Dec 08 19:57:00 thanks Dec 08 19:57:15 kergoth_: I have parse interruption working well here (at least so far) Dec 08 19:57:23 i can stop it at any time, haven't seen an issue yet Dec 08 19:58:12 same here, though i made updateCache shut down the parser, just so the parser doesn't have to look at the cooker's state Dec 08 19:58:43 that's probably better Dec 08 19:58:53 i just wanted to make my server version work :) Dec 08 19:59:03 * kergoth_ nods Dec 08 19:59:04 eFfeM: richard purdie already acked your patch on the mailing list. besides that, i think unused variables should always be removed and you can add my ack, too, if you want Dec 08 19:59:16 now figure out ^C'ing cache load ;) Dec 08 19:59:52 well, do we need to actually interrupt it, since it takes so little time? Dec 08 20:00:08 its not about need, its about what people will do, and the behavior when they do Dec 08 20:00:17 last time i tried it, it deadlocked joining a process Dec 08 20:00:20 :) Dec 08 20:00:25 i'm not seeing any problems here Dec 08 20:00:36 unless i'm just not hitting it Dec 08 20:00:42 * kergoth_ tries again Dec 08 20:00:45 let me put my cache progress back in, then i can be sure Dec 08 20:00:45 obi thanks, can you paste me a signoff line Dec 08 20:01:00 did you get yours rebased on master? i should probably start using your tree again, the branches are deviating Dec 08 20:01:05 kergoth_: you may have issues since you're single threaded Dec 08 20:01:07 yes, I did Dec 08 20:01:17 let me remove some prints Dec 08 20:01:19 then i'll push again Dec 08 20:01:23 hehe, k Dec 08 20:01:30 obi, as this affects quite some recipes (although harmless) I prefer to have two acks as the policy suggests/indicates Dec 08 20:01:39 eFfeM: Acked-by: Andreas Oberritter Dec 08 20:01:44 obi, thanks Dec 08 20:01:46 Tartarus, ping Dec 08 20:01:52 np Dec 08 20:02:03 ah, i have on other thing I need to try again too, that earlier dictionary changed thing made me go on a tangent Dec 08 20:03:39 kergoth: what's your opinion about allowing an environment variable to overrade the location of bblayers.conf? that would allow to run bitbake from any location, like it is already possible if bblayers aren't used Dec 08 20:03:39 Tartarus, your m4 change to autoconf.inc case appears to break autoconf installed on machine .... Dec 08 20:03:55 s/overrade/override/ Dec 08 20:04:29 hi all Dec 08 20:04:42 Crofton|work: which change? Dec 08 20:04:50 There's been some back and forth in there for different scenarios Dec 08 20:06:00 And break what case, exactly? Dec 08 20:06:04 I am thinking of starting a branch to refactor the recipes in same way like poky ? opinions Dec 08 20:06:17 root@usrp-embedded:~# grep balister /usr/bin/autom4te Dec 08 20:06:17 my $m4 = $ENV{"M4"} || '/home/balister/oe/tmp/sysroots/x86_64-linux/usr/bin/m4'; Dec 08 20:06:17 root@usrp-embedded:~# Dec 08 20:06:22 is what I see on the machine Dec 08 20:06:29 khem: where we can look on poky way? :) Dec 08 20:06:42 did you mean layers? Dec 08 20:06:44 Crofton: So the m4 that ends up on the target device, OK Dec 08 20:06:47 8da17586c547f365ae667eb2608ba89a1c375afc Dec 08 20:06:48 Jay7: yes Dec 08 20:06:51 yeah Dec 08 20:06:54 can't find it Dec 08 20:07:02 I soft linked things to make it work ... Dec 08 20:07:09 Crofton|work: But... why is that change being seen outside of -native? Dec 08 20:07:17 not sure Dec 08 20:07:33 I just found the problem and I tossing blame about wildly Dec 08 20:07:38 heh Dec 08 20:07:46 It's all a not nice case :( Dec 08 20:07:49 M4=`which m4` Dec 08 20:07:50 but you adjust the path in the inc file Dec 08 20:07:55 should find it Dec 08 20:08:03 We need to make sure that (a) when we build autoconf the build uses our m4 Dec 08 20:08:07 which would be used by native and non-native Dec 08 20:08:22 if ${@['true', 'false'][bb.data.inherits_class('native', d)]} Dec 08 20:08:30 is before we start fiddling with those variables Dec 08 20:08:48 basically this worked last motnh Dec 08 20:08:53 I think someone needs to go and clean up the dir so we can use do_configure_prepend_virtclass-native or so Dec 08 20:09:44 Are you able to go and whack things about a little? or test a patch? Dec 08 20:10:07 khem: someone should start that branch :) Dec 08 20:10:26 if you have some suggestions I will try them Dec 08 20:10:32 Jay7: i will, I wanted to discuss it here Dec 08 20:10:39 about to run out for a couple of hours though Dec 08 20:10:54 Crofton|work: ok, preferred email? Dec 08 20:10:59 khem: as I understand, we will have some kind of categories like poky have? Dec 08 20:11:01 I have gnuradio building on the hardware so can't test soon Dec 08 20:11:15 Jay7: yes Dec 08 20:11:31 khem: will we use same layout? Dec 08 20:11:37 frak Dec 08 20:11:39 or it should be discussed too? Dec 08 20:11:47 gcc died in the copile Dec 08 20:11:53 stupid regressions Dec 08 20:12:42 gcc dying .. Dec 08 20:12:43 http://pastebin.com/R3pFHPUd Dec 08 20:12:44 Jay7: same layout to remain compatible Dec 08 20:12:59 khem, we've seen that before, then it went away, now it came back Dec 08 20:13:09 before Thansgiving things were ok Dec 08 20:13:39 Crofton|work: is it happening while doing make on target ? Dec 08 20:13:40 Is it possible to create SRC_URI dynamically with Python? Dec 08 20:13:42 or cross compiling Dec 08 20:13:53 davidlt: of course Dec 08 20:14:03 Any package for example? Dec 08 20:14:13 kergoth_: do we care about # of entries loaded from cache, or should I remove that? b/c we don't have that info with cachesize Dec 08 20:14:14 right Dec 08 20:14:26 foerster: good question :) Dec 08 20:14:37 Loaded 20823270 entries from dependency cache. Dec 08 20:14:39 we do have that info, but its in the form of len(self.depends_cache) Dec 08 20:14:39 :) Dec 08 20:14:40 Crofton|work: right for former or latter Dec 08 20:14:43 * kergoth_ shrugs Dec 08 20:14:46 ah Dec 08 20:14:58 well, I'll put it, we can decide later Dec 08 20:15:03 it's more work to remove it at this point Dec 08 20:15:29 er Dec 08 20:15:43 building on target Dec 08 20:15:45 not really. the total value in the event is still useful for progress, all you'd have to do is remove the print of it to the user. we can revisit later Dec 08 20:15:51 * kergoth_ grumbles Dec 08 20:16:13 * kergoth_ goes back to performance testing on single core Dec 08 20:18:37 Crofton|work: I think the problem is evidently that libgcc.so should not be deleted in favor of a symlink Dec 08 20:28:57 Crofton|work: can you try this quick fix http://pastebin.com/eJGhxueF Dec 08 20:29:14 Crofton|work: apply this and then do bitbake -c clean gcc;bitbake gcc Dec 08 20:30:49 khem or anyone else, any idea on my __gnu_thumb1_case_uqi nonrepresentable section issue ? Dec 08 20:31:45 * eFfeM feels stuck Dec 08 20:32:21 eFfeM:is this on target ? Dec 08 20:32:32 eFfeM: I mean when compiling on target board Dec 08 20:32:37 or cross-compiling Dec 08 20:33:07 cross Dec 08 20:33:11 recipe mediatomb Dec 08 20:33:15 in doconfigure Dec 08 20:33:22 hmm Dec 08 20:33:33 see http://permalink.gmane.org/gmane.comp.handhelds.openembedded/40363 for log Dec 08 20:33:38 eFfeM: ok have you built target gcc ? Dec 08 20:33:52 is it possible for a process to check its provisioning? to see which processors it has available? Dec 08 20:33:52 kergoth_: pushing in a minute so you can see what I have Dec 08 20:33:57 foerster: k, thanks Dec 08 20:33:59 eFfeM: do this, go into your target sysroot and find libgcc_s.so for me Dec 08 20:34:21 eFfeM: once you find it run file on it and tell me what type of file is it Dec 08 20:34:54 one sec, will do so in 5-10 mins Dec 08 20:35:52 need to logon into a different sys Dec 08 20:39:10 khem: frans@ax010-bob64:/home/hudson/jobs/FM_TEST/workspace/tmp/sysroots$ file ./armv5te-oe-linux-gnueabi/lib/libgcc_s.so Dec 08 20:39:10 ./armv5te-oe-linux-gnueabi/lib/libgcc_s.so: ASCII C program text Dec 08 20:39:17 it is only 4 lines of text Dec 08 20:39:23 kergoth_: updates are pushed https://github.com/foerster/bitbake/tree/separate-ui-and-server Dec 08 20:39:34 eFfeM: ok thats correct Dec 08 20:39:48 eFfeM: so which recipe fails Dec 08 20:39:48 khem and the .1: ./armv5te-oe-linux-gnueabi/lib/libgcc_s.so.1: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped Dec 08 20:40:03 mediatomb, in do_configure Dec 08 20:40:23 eFfeM: can you locate the test which fails in configure script ? Dec 08 20:40:27 yes Dec 08 20:40:38 ok pastebin that gcc call somewhere Dec 08 20:40:43 khem, see http://permalink.gmane.org/gmane.comp.handhelds.openembedded/40363 Dec 08 20:41:27 it is a wrinked due to line wraps Dec 08 20:41:54 7th line Dec 08 20:42:31 eFfeM: ok I see why is this happening Dec 08 20:42:45 eFfeM: let me see if I can hack up a quick patch for you Dec 08 20:42:54 ah cool, thanks! Dec 08 20:44:10 eFfeM: u are using gcc 4.5 right ? Dec 08 20:47:19 eFfeM: here it is http://pastebin.com/ivmFb3vv Dec 08 20:47:44 eFfeM: apply it then rebuild gcc-cross Dec 08 20:47:47 khem, yes Dec 08 20:48:27 eFfeM: best way to do that is bitbake -c clean gcc-cross gcc-cross-initial gcc-cross-intermediate eglibc eglibc-initial; bitbake gcc-cross Dec 08 20:49:16 eFfeM: once you finish rebuilding gcc-cross then rebuild mediatomb and see if it helps Dec 08 20:50:05 * khem (SIGFOOD) Dec 08 20:50:14 ENOFOOD :) Dec 08 20:53:03 khem, will try, still have a bould running ,but the .so file already has GROUP ( libgcc_s.so.1 libgcc.a ) Dec 08 20:53:19 have a differnet build running that must finish first Dec 08 20:53:37 (almost done 4520/4560) Dec 08 20:53:44 foerster: fyi, eventHandler.get(.25) isn't setting a timeout of .25. it's passing the argument as the value of 'block', which is boolean, and .25 isn't 0, so is intepreted as true, and you end up with behavior equivalent to eventHandler.get(), which blocks Dec 08 20:54:01 foerster: this blocking isn't problematic, but you can remove the try/except aout Empty Dec 08 20:56:56 kergoth_: d'oh :) Dec 08 20:57:13 i had that b/c the original one was actually making the server do work there :) Dec 08 20:57:54 original one = single process for everything Dec 08 20:57:57 yeah, knotty doesn't actually do anything beyond waiting on events in that loop at this point, so blocking is harmless Dec 08 20:58:00 * kergoth_ nods Dec 08 20:58:03 yeah, fair point Dec 08 20:58:16 yet another spot simplified by this branch Dec 08 20:58:41 hi khem Dec 08 20:58:45 hrm Dec 08 20:59:11 do you remember why you removed do_configure in gcc-configure-sdk in a00e4c89ba413a0c877f9d36382477fe2fd3e965 ? Dec 08 21:00:51 khem: now sdk is broken (missing libmpfr.so.4 libelf.so.0 libmpc.so.2) Dec 08 21:01:53 kergoth_: the cooker_logfile in bin/bitbake I believe is unused. I'm not familiar with the logging, so I didn't touch it. Dec 08 21:02:32 in fact, all of the logger stuff probably should be moved into the cooker Dec 08 21:02:37 foerster: the stupid daemonize module for the server spawn forcibly shoves stdout into a file, as far as i can see it was required Dec 08 21:02:42 i think thats what that was Dec 08 21:02:47 should be no point to any of that Dec 08 21:02:52 now Dec 08 21:02:52 ah, ok. Dec 08 21:03:57 that daemonize module is pretty lame anyway, there's a better one nowadays if we do end up wanting to make the server a proper daemon Dec 08 21:04:07 but there's no need for that at this point, since the server's lifetime is bound to the UI Dec 08 21:04:15 right, for now at least. Dec 08 21:04:19 * kergoth_ nods Dec 08 21:04:26 thought of daemon server, with inotify for bb files :) Dec 08 21:05:02 yeah, that kind of thing would be lovely, but we have lots of things to fix for that to work well Dec 08 21:05:12 ideally one daemon would be able to do multiple builds, which means events have to stop being global Dec 08 21:05:19 also all our caches have no expiration policies at all right now Dec 08 21:05:24 which is problematic for long running daemon Dec 08 21:05:37 true. Dec 08 21:05:54 if we move to the process server, I think life becomes easier in all the other pieces Dec 08 21:06:03 agreed Dec 08 21:06:25 I don't know how effective it would be to capture stdout to a stringIO and send them to UI Dec 08 21:06:37 but there is a LOT of writing to stdout right now Dec 08 21:07:05 i think our server should probably kill its stdout entirely at some point, and every task needs to capture its stdout into the log file. python tasks can use the logging module to send things to the UI cleanly Dec 08 21:07:15 hrm Dec 08 21:08:14 i like the ncurses ui, in that it shows you currently running tasks (clearly) Dec 08 21:08:24 but it gets killed with all the stdout writing Dec 08 21:08:33 s/killed/trashed/ Dec 08 21:09:55 yeah Dec 08 21:10:02 we need to implement the text input box there too Dec 08 21:10:15 it has one, just needs to take input and send it as commands Dec 08 21:10:25 would replace the old bitbake interactive mode shell Dec 08 21:12:43 we can do it easily if we get stdout controlled Dec 08 21:16:20 http://wiki.openembedded.org/images/logo.png is missing Dec 08 21:17:45 kergoth_: pushed fix for eventHandler.get() Dec 08 21:25:09 03Martin Jansa  07master * r170128f906 10openembedded.git/recipes/e17/elmdentica_svn.bb: Dec 08 21:25:09 elmdentica: add elmdentica-themes to RDEPENDS Dec 08 21:25:09 Signed-off-by: Martin Jansa Dec 08 21:31:31 03Andreas Oberritter  07org.openembedded.dev * r5d269d7d29 10openembedded.git/recipes/mythtv/mythplugins_0.23+fixes.bb: Dec 08 21:31:31 mythtv: depend on virtual/libsdl instead of libsdl-x11 Dec 08 21:31:31 Signed-off-by: Andreas Oberritter Dec 08 21:31:31 Signed-off-by: Frans Meulenbroeks Dec 08 21:31:43 03Frans Meulenbroeks  07org.openembedded.dev * rc9ca1ec7a9 10openembedded.git/ (71 files in 33 dirs): Dec 08 21:31:43 removed unused var AUTOTOOLS_STAGE_PKGCONFIG Dec 08 21:31:43 Signed-off-by: Frans Meulenbroeks Dec 08 21:31:43 Acked-by: Richard Purdie Dec 08 21:31:43 Acked-by: Andreas Oberritter (on irc) Dec 08 21:32:46 khem, applied the patch, but don't have enough time to run the build, will do so tomorrow and report back Dec 08 21:33:01 patch applies fine Dec 08 21:33:41 calling it a day now, need to get up early tomorrow ... cya & have fun Dec 08 21:36:06 hrrr Dec 08 21:36:10 Can't ge Bitbak Dec 08 21:37:09 I have assignment (python) in recipe, but it breaks Bitbake Dec 08 21:37:10 SyntaxError: EOL while scanning string literal Dec 08 21:37:25 Can't get it, because it works on python interpreter Dec 08 21:37:47 davidlt: show us the offending line? Dec 08 21:37:50 And I have like this SRC_URI = "${@}" Dec 08 21:38:17 ok, what's Dec 08 21:38:27 SRC_URI = "${@str('http://www.sqlite.org/sqlite-autoconf-{:d}{:02d}{:02d}{:02d}.tar.gz').format(*map(lambda x, y: y if x is None else int(x), bb.data.getVar('PV', d, 1).split('.'), [0]*4))}" Dec 08 21:38:55 This should generate links for SQLite with their new naming schema Dec 08 21:39:06 But it fails on Bitbake Dec 08 21:39:34 hmm. Dec 08 21:39:41 I think it meats "}" in string and calls it as python statement Dec 08 21:40:02 Yeah: str('http://www.sqlite.org/sqlite-autoconf-{:d Dec 08 21:40:16 that's my guess Dec 08 21:40:24 \{ maybe? Dec 08 21:41:02 not sure it it will handle that, kergoth_ would know more of the details on how that works Dec 08 21:41:41 kergoth_: up? Dec 08 21:44:16 davidlt: SRC_URI = "${@str('http://www.sqlite.org/sqlite-autoconf-%d%02d%02d%02d.tar.gz').format(*map(lambda x, y: y if x is None else int(x), bb.data.getVar('PV', d, 1).split('.'), [0]*4))}" Dec 08 21:44:32 does that work? can you use %d, etc instead of {:d}? Dec 08 21:45:05 str() isn't necessary, it's already a string :) Dec 08 21:45:18 afaik, anyway Dec 08 21:45:55 yeah I know, I put it trying to solve problem Dec 08 21:46:13 I don't know if python supports old fomating, give a sec Dec 08 21:46:41 no support Dec 08 21:47:55 Wait Dec 08 21:48:17 How could I forgat that :) Dec 08 21:48:30 "%d" % (5) would work :) Dec 08 21:48:38 right, don't use .format Dec 08 21:48:57 I haven't worked with python just for half a year and already forgo Dec 08 21:48:58 t Dec 08 21:51:50 worked! Dec 08 21:54:39 ericben: hmmm I see Dec 08 21:54:49 ericben: can you test this fix for me please Dec 08 21:54:51 http://pastebin.com/EUvTdUHP Dec 08 21:55:07 ericben: this should hopefully fix the issue Dec 08 22:02:32 davidlt: remember that OE only requires bitbake 1.8 at this time, which means it only really requires python 2.4. best be cautious about inline python usage, keep an eye to portability Dec 08 22:03:19 it should work on 2.4 I think Dec 08 22:04:00 the format method on strings doesn't exist there :) Dec 08 22:04:09 havfe to use % to stay portable Dec 08 22:04:11 for now, anyway Dec 08 22:04:36 * kergoth_ checks to see if the use of tell() in the cache progress is adding any overhead Dec 08 22:04:53 Yeah, now I am trying to fix work dir Dec 08 22:10:23 khem: ok thanks, I'm launching the build now, will keep you informed tomorrow morning (fr time ;-) Dec 08 22:10:50 ericben: ok cool thx Dec 08 22:11:17 ericben: that was how it was supposed to be. I dont know how I missed the append part Dec 08 22:11:46 khem: ok I didn't had time to test the generated sdk until today :-( Dec 08 22:11:58 so sdk generated in release are broken Dec 08 22:12:35 back and testing fixes Dec 08 22:12:36 thanks guys Dec 08 22:12:51 Crofton|work: I gave one for you Dec 08 22:12:56 I see Dec 08 22:12:58 the same link as ericben Dec 08 22:13:05 http://pastebin.com/EUvTdUHP Dec 08 22:13:10 try that our Dec 08 22:13:13 out Dec 08 22:13:13 anyway now I know that for next release I'll do the possible to run test before the release :) Dec 08 22:13:40 compile testing is good, run testing better but that takes lot of time ... Dec 08 22:13:52 this one? Dec 08 22:13:56 ericben|away: yes, thats why I kept asking for more testing in last couple of days Dec 08 22:14:10 khem, it was a holiday :) Dec 08 22:14:21 Crofton|work: friday ? Dec 08 22:15:02 khem: yes unfortunatly december is not the good month for me to have free time to test, lot of projects to finish before the end of month/year ... Dec 08 22:15:21 Friday after thanksgiving is the day we all stay home and monitor our credit card limits Dec 08 22:15:30 ericben|away: yeah we might shift it to Nov next year Dec 08 22:15:34 well, I was flying Dec 08 22:15:42 bye more news tomorrow ! Dec 08 22:15:43 Crofton|work: haha yes Dec 08 22:15:54 ericben|away: ok gn Dec 08 22:16:11 Crofton|work: try that fix out and rebuild gcc Dec 08 22:16:18 and reinstall it on your board Dec 08 22:16:24 lets see if it does any better Dec 08 22:23:28 khem both, or just the gcc-package-target one Dec 08 22:24:15 git clone, update file, git commit, git pull . Gonna commit my changes? Dec 08 22:42:14 Crofton|work: you can try the complete patch Dec 08 22:42:25 although you only need target gcc one Dec 08 22:42:36 it should not harm Dec 08 22:42:41 or if it does then we know Dec 08 22:43:42 I only applied the first Dec 08 22:43:45 rebuilding image Dec 08 22:49:37 khem, hi, did you find solution to the fortran problem I showed you? :) Dec 08 22:57:57 pespin: well its simple add fortran to LANGUAGES variable Dec 08 22:58:00 and recompile gcc-cross Dec 08 23:00:46 khem, should I set that one in local.conf? like LANGUAGES += "fortran" ? Dec 08 23:04:38 hi all Dec 08 23:05:16 I'm fighting against a sigegv of qemu-native while running an OE image (x86) Dec 08 23:05:29 angrstrom-2010.12 distro Dec 08 23:05:35 pespin: hmm no in gcc configure file in the recipes dir Dec 08 23:05:47 alx_: yes I saw that too Dec 08 23:05:57 alx_: unfortunately no solition yet Dec 08 23:06:05 use the host installation of qemu Dec 08 23:06:49 khem, did anyone discover the issue ? Dec 08 23:09:52 alx_: well issue is discovered but not analysed or fixed Dec 08 23:09:56 imo Dec 08 23:19:09 hmmmmm Dec 08 23:24:45 khem: strange failure here: http://tinderbox.openembedded.net/public/logs/task/12740495.txt Dec 08 23:24:56 see config.log http://pastebin.ca/2014298 Dec 08 23:25:41 I have the /usr/share/pygobject/2.0/codegen in my sysroots/i686-linux Dec 08 23:27:07 ant__: seems like pkgconfig crap to me Dec 08 23:27:11 I'm reading configure.ac... Dec 08 23:27:12 CODEGENDIR=`$PKG_CONFIG --variable=codegendir pygtk-2.0` Dec 08 23:27:22 there we go Dec 08 23:28:03 btw configure: line 11462: ./libtool: No such file or directory Dec 08 23:28:36 ant__: thats secondary Dec 08 23:32:00 ant__: find out why pkg-config chickens out Dec 08 23:32:50 first I was thinking simply because of some missing deps but it doesn't seem the case Dec 08 23:33:01 ant__: ah I see should this be pygobject-2.0 instead Dec 08 23:33:23 ant__: there we go apply this patch and see if it works Dec 08 23:33:25 http://code.google.com/p/pywebkitgtk/issues/detail?id=47 Dec 08 23:34:04 ah, yes, in fact those files are staged by pygobject Dec 08 23:35:46 hm Dec 08 23:38:33 hrm Dec 08 23:49:57 Tartarus, http://pastebin.com/X2JykAYF Dec 08 23:50:27 ok Dec 08 23:50:32 where's it reside? Dec 08 23:50:39 since before it was /home/..../ right? Dec 08 23:50:52 supposed to be in /usr/bin Dec 08 23:51:05 autoconf should have packaged that for you Dec 08 23:51:13 yeah Dec 08 23:51:15 but is it? Dec 08 23:51:18 Is autoconf installed on target Dec 08 23:51:19 if not where is it? Dec 08 23:51:37 Tartarus: if not then we should package it up with autoconf Dec 08 23:51:43 autoconf can't exec autom2te Dec 08 23:51:53 hmmm Dec 08 23:51:57 Crofton, right, but are we having a path problem or what? Dec 08 23:52:06 yeah Dec 08 23:52:13 /usr/bin/autom4te: not found Dec 08 23:52:13 root@usrp-embedded:~/gnuradio# which autom4te Dec 08 23:52:13 /usr/bin/autom4te Dec 08 23:52:30 Crofton|work: run file on it Dec 08 23:52:31 What're the buggy path(s) now? Dec 08 23:52:55 Does it have exec bits set ? Dec 08 23:53:01 it should be a shell script Dec 08 23:53:20 yuck a perl script Dec 08 23:53:50 khem: problem in current tree (crofton has a patch for me) is that m4 path is wrong, on thje target Dec 08 23:54:32 Tartarus: this may be unrelated to that though Dec 08 23:54:54 Crofton: can you execute it on shell Dec 08 23:55:24 khem, right Dec 08 23:55:29 root@usrp-embedded:~/gnuradio# autom4te Dec 08 23:55:29 -sh: autom4te: not found Dec 08 23:55:41 comman completion works Dec 08 23:55:56 Right, but what's the file itself look like, incl contents Dec 08 23:55:58 #! /home/balister/oe/tmp/sysroots/x86_64-linux/usr/bin/perl -w Dec 08 23:55:58 # -*- perl -*- Dec 08 23:56:00 got it Dec 08 23:56:00 what is the path for checking out OE using git+ssh? I can't seem to find it on the wiki... Dec 08 23:56:05 Yeah, ah-ha :) Dec 08 23:56:14 Crofton: thats what I said Dec 08 23:56:17 * grg is a git noob Dec 08 23:56:18 you need perl Dec 08 23:56:20 grg: git@git.openembedded.org:openembedded Dec 08 23:56:21 :) Dec 08 23:56:31 well, I need perl in /home/balister/oe/tmp/sysroots/x86_64-linux/usr/bin/perl Dec 08 23:56:33 grg: sign up for patchwork too Dec 08 23:56:42 khem, yup, just did that a moment ago Dec 08 23:56:48 ok Dec 08 23:56:57 kergoth_, is it the same as non ssh? Dec 08 23:57:00 now I soft link perl to there and check khems fix :) Dec 08 23:57:08 grg: git://git.openembedded.org/openembedded Dec 08 23:57:19 completely different protocol, so i don't see how it could be. Dec 08 23:57:39 grg: one is ssh Dec 08 23:58:00 grg: so clone using git@git.openembedded.org:openembedded Dec 08 23:58:05 and then you should be able to push Dec 08 23:58:08 personally, i use a recent git with pushInsteadOf Dec 08 23:58:35 kergoth_: grg just mentioned he is a git noob ;) Dec 08 23:58:42 dont scare him off as yet Dec 08 23:58:50 yeah. i've never done a git push before Dec 08 23:58:52 hehe Dec 08 23:58:56 fair enough Dec 08 23:59:09 if anyone else is curious: https://gist.github.com/734139 Dec 08 23:59:16 then git clone oe:openembedded Dec 08 23:59:21 and git push will automatically switch to ssh Dec 09 00:01:22 Tartarus, I softlinked perl so it ran, which led to http://pastebin.com/NmWMNq7X Dec 09 00:01:43 So it's still there,ok Dec 09 00:01:49 But... why Dec 09 00:02:55 But it really does all work if you undo 8da17586c547f365ae667eb2608ba89a1c375afc ? Dec 09 00:06:05 I am thinking about trying that .... Dec 09 00:06:14 it worked last month :) Dec 09 00:08:07 Can anyone point me to THE AUTHORITATIVE GOSPEL for building kernels for open embedded? I need a complete sanity check here and the documentation I have found is fragmented at best. Dec 09 00:08:14 I have built a KNOWN WORKING kernel image, I have extracted the config from that function kernel. I want to make changes to the config but even if I just use the KNOWN WORKING config, my overo fails to boot. However, when I copy the original kernel over, it boots just fine. I feel I have missed a step, but I have repeated the instructions I've followed repeatedly Dec 09 00:09:58 coreyfro: this is not a paid support channel first of all. So writing in CAPS can throw off people Dec 09 00:10:31 coreyfro, linux.inc will make some changes to your config. You could check that this is not removing/adding something that affects your kernel adversely Dec 09 00:11:33 damnit Dec 09 00:11:36 hmm Dec 09 00:11:41 Thanks GRG, I'll take a look Dec 09 00:14:46 Is there a How To for building kernels alla OE? I've used http://www.openembedded.org/index.php/Kernel_Building but it's incomplete. Dec 09 00:15:19 Or at least following those directions alone has not resulted in a built kernel Dec 09 00:16:06 documentation probably is a problem in OE so we always ask for sending doc fixes when someone like you go through the tribal rituals of OE Dec 09 00:16:31 are you using OE master or some offshoot Dec 09 00:16:35 if we had good documentation, no one would pay us for consutling Dec 09 00:16:53 khem: OE master Dec 09 00:16:57 * Crofton hopes coreyfro has a sense of humour Dec 09 00:17:12 coreyfro, did you find xoras blog entry on this Dec 09 00:17:32 Crofton: I've worked for the feds, either I do, or I don't have feelings, so it doesn't matter Dec 09 00:17:48 coreyfro: ok, usually machine maintainers should have added a working defoconfig to relevant kernel Dec 09 00:17:51 No, but I'm going to go look for it Dec 09 00:18:06 http://www.xora.org.uk/2009/12/10/openembeddedangstrom-kernel-workflow/ Dec 09 00:18:13 he's asleep now Dec 09 00:18:16 or drunk Dec 09 00:18:19 or both Dec 09 00:18:46 * kergoth_ sighs, just ran into a deadlock in bitbake using the separated ui branch + his changes when its limited to just one processor Dec 09 00:18:54 * kergoth_ grumbles Dec 09 00:18:55 heh Dec 09 00:18:58 tough stuff Dec 09 00:19:18 I hope to run the device driver I jsut "finished" on a multi core arm one day Dec 09 00:19:26 I suspect that will be very educational Dec 09 00:19:28 thankfully there's very little shared state, and its mostly just a matter of ensuring that queues are emptied before shutting down a process and the like Dec 09 00:19:47 Tartarus, do you want me to revert that changeset and see if things work Dec 09 00:19:52 * kergoth_ prefers mostly collaborative multitasking with explicit communications channels Dec 09 00:19:56 messaging > shared Dec 09 00:20:32 * khem needs some article to read during the light rail ride Dec 09 00:20:52 coreyfro: which kernel version is it building Dec 09 00:21:52 Ok, I found a defconfig for Beagleboard in recipes/linux/linux-omap-2.6.32 Dec 09 00:21:59 linux-omap_2.6.29.bb seems to have preference Dec 09 00:22:39 unfortunetly, I need the thin wifi firmware for Overo, which means I need the later kernels Dec 09 00:22:44 coreyfro: look in your build tree and see which version is it choosing Dec 09 00:22:49 And I got it working, I just don't remember how Dec 09 00:23:33 I built the kernel and configured it myself following http://www.openembedded.org/index.php/Kernel_Building Dec 09 00:23:41 khem, your fix looks good Dec 09 00:23:52 Crofton|work: thank you Dec 09 00:24:08 I don't believe it built a kernel, I've always built it alone Dec 09 00:24:11 I now need confirmation from ericben and effem for their fixes then I can commit all 3 in one Dec 09 00:24:52 coreyfro: building any image or sdk will automatically build a kernel as a part of the build process, or you can just bitbake virtual/kernel. nothing to it Dec 09 00:25:10 You know what, I think I prefixed MACHINE="beagleboard" before the bitbake command, does the MACHINE variable matter for this opperation? Recently I was using OVERO Dec 09 00:25:25 heh Dec 09 00:25:26 of course it does. it has *EVERYTHING* to do with this Dec 09 00:25:37 machine is what controls which kernel is built and what config is used for it Dec 09 00:25:57 hah, but I am building for an overo Dec 09 00:26:15 khem, no Dec 09 00:26:15 and overo isn't working Dec 09 00:26:17 failed again Dec 09 00:26:25 khem, sorry I was premature Dec 09 00:26:28 lemme see if that makes it work Dec 09 00:26:39 Crofton|work: ok now on your target Dec 09 00:26:47 ok Dec 09 00:26:49 find . -name "libgcc_s.so" Dec 09 00:26:59 doh Dec 09 00:27:02 wait a minute Dec 09 00:27:10 wrong window Dec 09 00:27:13 sorry :) Dec 09 00:27:13 I mean find / -name "libgcc_s.so" Dec 09 00:27:22 I looked at the old failure :) Dec 09 00:27:28 it is still going Dec 09 00:27:36 * Crofton|work needs to take a break Dec 09 00:27:41 * khem see's crofton's wiggly eyes Dec 09 00:27:54 I just had it up to see where the failure was Dec 09 00:28:05 ok so it worked or not ? final answer Dec 09 00:28:07 I am 99% certain the build is past it now Dec 09 00:28:15 99% certain fix is good Dec 09 00:28:29 ok I will grab a tea and see if 1% is falling on me Dec 09 00:28:37 03Chris Larson  07master * rfc64eff03f 10bitbake.git/lib/bb/ (command.py cooker.py): Dec 09 00:28:37 cooker: add shutdown/stop methods Dec 09 00:28:37 Signed-off-by: Chris Larson Dec 09 00:28:39 03Chris Larson  07master * rc7c8945ef7 10bitbake.git/lib/bb/ (command.py cooker.py): Dec 09 00:28:39 cooker: merge cookerState and cookerAction Dec 09 00:28:39 Signed-off-by: Chris Larson Dec 09 00:29:17 Are any of you in the SF bay area? We have a new Embedded Linux group at Noisebridge Dec 09 00:29:32 We meet on thursdays Dec 09 00:31:02 I am there sometimes Dec 09 00:31:10 khem works there Dec 09 00:33:04 * Jay7 -> sleep Dec 09 00:39:30 oh son of a bitch Dec 09 00:39:32 * kergoth_ sighs Dec 09 00:45:02 okay, this will work around it for now.. hrm Dec 09 00:49:37 i really hate ^C. Dec 09 00:51:29 argh Dec 09 00:56:26 coreyfro: oh TinyTux thing Dec 09 00:57:02 coreyfro: Allison mentioned it on our meetup for Silicon Valley Linux Technology group Dec 09 00:57:27 coreyfro: I am in San Jose and hate the commute to city Dec 09 00:57:51 unless it was somewhere local it would be interesting Dec 09 01:03:15 khem, then you should check out hackdojo. It's the baby of David Weekly of PBWIKI and Super Happy Dev House fame Dec 09 01:03:33 khem: So, the beagleboard kernel works on my overo Dec 09 01:03:40 coreyfro: ok enjoy Dec 09 01:03:41 but not my overo kernel Dec 09 01:03:55 coreyfro: I talk at SVLT few times thats all Dec 09 01:04:10 on various things related to embedded lnx Dec 09 01:04:38 * kergoth_ sighs at bitbake Dec 09 01:04:55 * kergoth_ can see the attraction of a rewrite :| Dec 09 01:10:57 * Crofton|work notes kergoth_ has said that for years Dec 09 01:11:07 * kergoth_ nods Dec 09 01:11:13 still true Dec 09 01:13:34 hard to work up the energy to take on something like that though, particularly since itd be a long time until it got to the point where it worked as well as the current bits Dec 09 01:14:54 kergoth_: rewrite is probably harder but refactoring can lead to rewrite over a period of time Dec 09 01:15:15 yeah, thats the goal, but its slow going, and frustrating at times Dec 09 01:15:21 I know Dec 09 01:15:23 :) Dec 09 01:15:43 I am starting a branch for recipes layers Dec 09 01:15:44 the worst is the lack of unit tests. refactoring without unit tests is MADNESS Dec 09 01:15:50 on lines with poky Dec 09 01:16:18 looked at koen's angstrom repo? might want to build on that Dec 09 01:16:21 yeah unit test is must actually its never late it needs to be started at some point Dec 09 01:16:59 its tough to add them when the components are so intertwined though :( Dec 09 01:17:08 need to refactor to unit test to refactor Dec 09 01:17:09 or something Dec 09 01:17:13 :) Dec 09 01:17:26 koen layed on top of poky isnt it Dec 09 01:18:05 well, until the vote occurs, we don't know which direction we're going in, either way there's a risk that any work on layering will be wasted Dec 09 01:18:16 right Dec 09 01:18:30 what I am gonna try is create same structure within OE Dec 09 01:18:38 and use OE recipes Dec 09 01:19:03 we can then easily plugin yocto into core or out of core Dec 09 01:19:13 should probably focus on the bits that aren't already in yocto/poky then, eh? Dec 09 01:19:15 hmm Dec 09 01:19:15 whatever we decide Dec 09 01:19:17 its a good idea Dec 09 01:19:58 we can fine tune the layers later Dec 09 01:20:07 as we go Dec 09 01:20:16 going to go category based, graphics, multimedia, etc? Dec 09 01:20:21 yes Dec 09 01:20:22 i'd think itd be the best route Dec 09 01:20:36 outside of the distro/machine layers, anyway Dec 09 01:20:49 yes Dec 09 01:21:02 the machine/distro thing will be next Dec 09 01:21:43 I dont know if git will let me sync update into moved trees Dec 09 01:21:47 I mean dirs Dec 09 01:22:16 you should be able to leverage filter-branch to rip out full history of files/dirs into a separate branch and put that in another repo later Dec 09 01:22:18 if not then one day we have to have a flag day Dec 09 01:22:32 the problem is updating filter-branch'd branches from upstream Dec 09 01:22:35 thats a nightmare Dec 09 01:22:36 hmm Dec 09 01:22:42 and just mv'ing is worse Dec 09 01:22:46 due to conflicts Dec 09 01:22:47 hmm Dec 09 01:23:01 yeah so prolly I have to work on master Dec 09 01:23:08 and seep in the changes Dec 09 01:23:56 hmmm Dec 09 01:24:15 git has a subtree merge, but thats for the reverse, putting another tree into a subdir, not taking a subdir of another tree Dec 09 01:25:13 I think if git could identify moved files it will be nice Dec 09 01:25:26 it can, but i'm not sure how smart it is about merges with them Dec 09 01:25:40 yeah need to see Dec 09 01:25:54 last time I tried something like that it did not go well Dec 09 01:25:59 I had to rename and commit Dec 09 01:26:07 push Dec 09 01:26:40 i remember seeing lots of conflicts any time i tried stuff like that, but i think i saw the most problems with rm'ing and then merging changes to the rm'd files, moving might be less painful Dec 09 01:26:44 * kergoth_ thinks Dec 09 02:23:59 JaMa|Zzz: hey you! **** ENDING LOGGING AT Thu Dec 09 02:59:57 2010