**** BEGIN LOGGING AT Tue Dec 14 02:59:57 2010 Dec 14 03:06:00 Hm. Well, that gave me a different error at least. Thanks, and I'll see about trying master. Dec 14 03:08:52 kergoth_, remove PWD from preserved_envvars_list() ? Dec 14 03:18:09 Okay, screwy setup script wasn't actually setting up the environment as it should. Appears to be working now. Grabbing BitBake from Git fixed the 'cooker' variable problem...thanks again. Dec 14 06:32:05 03Bob Foerster  07master * r9683d9ac90 10openembedded.git/classes/base.bbclass: Dec 14 06:32:06 base.bbclass: Get rid of "WARNING: Function do_build doesn't exist" Dec 14 06:32:06 Signed-off-by: Bob Foerster Dec 14 06:32:06 Acked-by: Chris Larson Dec 14 06:32:06 Signed-off-by: Khem Raj Dec 14 06:32:22 03Melissa Watkins  07master * r6bdfc316ee 10openembedded.git/recipes/ti/ti-pru-sw-edma-library_1.00.00.bb: (log message trimmed) Dec 14 06:32:22 ti-pru-sw-edma-library: fix package dependencies Dec 14 06:32:22 * This package is not installed on the target system but only Dec 14 06:32:22 staged for use by other packages. Therefore it does not need Dec 14 06:32:22 an RDEPENDS entry. Dec 14 06:32:23 * The package does DEPEND on the ti-pru-sw-edma-driver being Dec 14 06:32:23 built prior to building. Dec 14 06:32:24 03Melissa Watkins  07master * rd4e22bd830 10openembedded.git/recipes/ti/ti-pru-sw-edma-driver_1.00.00.bb: (log message trimmed) Dec 14 06:32:24 ti-pru-sw-edma-driver: do not strip driver Dec 14 06:32:25 * Added PACKAGE_STRIP = "no" so that the module will not be Dec 14 06:32:25 stripped and can be insmoded into the kernel. Failure to Dec 14 06:32:26 do so results in errors like: Dec 14 06:32:26 : module has no symbols (stripped?) Dec 14 06:32:26 * Changed PR setting to key off changes to MACHINE_KERNEL_PR Dec 14 06:32:27 03Melissa Watkins  07master * r209a538d3d 10openembedded.git/recipes/ti/ti-pru-sw-app-loader_1.00.00.bb: (log message trimmed) Dec 14 06:32:28 ti-pru-sw-app-loader: remove unneeded RDEPENDS Dec 14 06:46:37 gm Dec 14 06:53:03 hey, is there away to get oe to install the linux io.h into the toolchain dir? Dec 14 06:53:19 or path or where ever it needs to go Dec 14 06:55:02 i what to be able to build test software outside of OE with the OE toolchain Dec 14 06:55:13 before i add it to my recipes and stuff Dec 14 06:56:57 khem, thanks for peeking into the samba issue, will test it asap, but need to work late tonight so it'll probably be tomorrow evening before I can. Dec 14 06:57:43 gandhijee, do you mean tmp/sysroots/armv7a-oe-linux-gnueabi/usr/include/sys/io.h ? Dec 14 06:58:50 oh my, i called it from the wrong location Dec 14 06:58:51 sorry Dec 14 06:59:27 khem: samba built fine Dec 14 07:38:47 * davidlt morning Dec 14 08:14:39 I had a toolchain-issue earlier that returned on the latest upstream-fetch. libmpfr and libgmp seem to have gone from static to dynamic linkage in gcc, and Ubuntu 10.10 lacks the proper versions. Dec 14 08:15:17 so again it only builds for me on the machine that actually created the sdk, because of the rpath gcc has into my TMPDIR Dec 14 08:49:51 good morning Dec 14 08:52:06 hey mckoan Dec 14 08:57:05 morning Dec 14 08:59:58 morning all Dec 14 09:01:15 How does BAD_RECOMMENDATIONS works Dec 14 09:01:17 ? Dec 14 09:01:35 Didn't find any documenation on it. Dec 14 09:13:23 morning all Dec 14 09:16:04 gremlin[it]: hello, I haven't read you for ages! :-D Dec 14 09:18:01 mckoan, true ... really busy ... but now i read "movement" about yocto and want to know how thing will evolve :D Dec 14 09:18:38 gremlin[it]: looks a bit foggy Dec 14 09:19:34 gremlin[it]: I'm also trying to understand what exactly yocto is and which benefit can give to oe Dec 14 09:23:47 mckoan, yocto seem interesting, but i don't understand tecnically what yocto is now and what want to be ... Dec 14 09:36:02 03Koen Kooi  07org.openembedded.dev * r19b366e05b 10openembedded.git/recipes/linux/ (2 files in 2 dirs): Dec 14 09:36:02 linux-omap 2.6.37rc: bump SRCREV Dec 14 09:36:02 Signed-off-by: Koen Kooi Dec 14 09:36:53 gremlin[it]: see www.yoctoproject.org also perhaps read Dec 14 09:36:53 http://bec-systems.com/site/755/yocto-and-openembedded and maybe http://lwn.net/Articles/419642/ (havent read the latter as I am not an lwn subscriber) Dec 14 09:40:22 eFfeM_work: query Dec 14 09:40:35 eFfeM_work: I sent you free link to that LWN article Dec 14 09:40:55 hrw thanks, the link has also been sent to the list by someone else Dec 14 09:41:10 I just opened it. Dec 14 09:41:25 I did not read it yet neither Dec 14 09:41:27 but thanks alot! Dec 14 09:43:30 np Dec 14 09:44:42 anything interesting in that lwn article? Dec 14 09:46:00 gremlin[it]: have a look at this thread from november if you didn't already see it: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/026598.html Dec 14 09:55:48 hi all,I am trying to build my own recipe for hawkboard and I did git pull now I am getting this error : http://pastebin.com/4KvBE1ns Dec 14 09:57:14 ynezz: worth reading Dec 14 09:59:39 Aarti: which version of bitbake - 1.8? Dec 14 10:00:00 eFfeM_work: How does BAD_RECOMMENDATIONS work? Dec 14 10:00:18 no idea, never used it, why are you asking me ? Dec 14 10:00:59 I added opensp to that list and my image compiled Dec 14 10:01:22 foerster: bitbake version is 1.8.18 Dec 14 10:01:24 Right now I changed iputils to disable man pages (they are still no included in my OS image) Dec 14 10:01:47 Aarti: there was a patch on 1.8 branch just yesterday I think for that Dec 14 10:01:59 Aarti: http://cgit.openembedded.org/cgit.cgi/bitbake/log/?h=1.8 Dec 14 10:02:05 see the most recent commit Dec 14 10:02:17 foerster: Isn't it better to move to 1.10.X ? Dec 14 10:02:32 davidlt: I would think so Dec 14 10:03:26 davidlt: 1.11 is coming out soon Dec 14 10:04:10 Any big changes? Dec 14 10:04:27 foerster: so what shold I do? Dec 14 10:04:32 davidlt: parallel parsing is the big one Dec 14 10:04:33 * eFfeM_work vaguely recalls that odd numbered versions are dev versions and releases get even numbers; that would make it 1.12) Dec 14 10:04:55 have to upgrade my vitbake Dec 14 10:04:58 eFfeM_work: that makes sense -- I haven't been around BB/OE long enough to know that ;) Dec 14 10:05:00 Aarti: yes Dec 14 10:05:01 bitbake? Dec 14 10:05:10 bluelightning: hey Dec 14 10:05:14 Aarti: best to get it from git Dec 14 10:05:24 bluelightning: ERROR: libqpe-opie-1.2.4: http://sources.openembedded.org/opie-1.2.4-split_library.tar.bz2 cannot check archive integrity Dec 14 10:05:36 foerster:thnax let me try Dec 14 10:05:44 foerster: there will be no release of bitbake 1.11 Dec 14 10:05:45 foerster: how good bitbake is with 16 logic cores machine? Does it give more performance comparing to 2-4 cores? Dec 14 10:06:04 davidlt: 16 cores? all will be used Dec 14 10:06:23 davidlt: http://marcin.juszkiewicz.com.pl/2008/04/07/speeding-up-bitbake-builds/ Dec 14 10:06:43 davidlt: bitbake will make num parse threads = num cores Dec 14 10:06:47 Jay7: is this because of missing checksums?# Dec 14 10:06:58 davidlt: so far I did not found machine which had free cpu time when I started build Dec 14 10:07:16 davidlt: max so far was dual quad xeon so 8 cores Dec 14 10:07:33 I don't see that compilation would take a lot of resources Dec 14 10:07:35 Hi Guys - um, how would I get the my password on the new patchwork instance reset (I seem to have miss-typed it)? Dec 14 10:08:11 davidlt: doing OE build consists thousands of tasks to do. fetch/unpack/configure/compile/package/clean - you can run any amount of them in parallel Dec 14 10:08:20 bluelightning: yes Dec 14 10:08:21 davidlt: all depends on cpu and i/o power you have Dec 14 10:08:41 Jay7: hmm ok, so I need to add these Dec 14 10:08:48 will have to wait until this evening Dec 14 10:08:52 I have old machine right now 2 x P4 @ 3Ghz Dec 14 10:08:53 davidlt: I did test builds on quad core machine with 32 tasks and parallel make - worked fine Dec 14 10:09:03 But I have Mac Pro somewhere around Dec 14 10:09:10 davidlt: parellel parsing from scratch(no cache) here takes approx 1 minute on quad core xeon Dec 14 10:09:22 davidlt: you can use icecream to run one OE build on both ;D Dec 14 10:09:30 * hrw -> out for some Dec 14 10:09:37 bluelightning: http://pastebin.ca/2019216 Dec 14 10:10:45 PARALLEL_MAKE this is simple environment variable or I have to put in some special file? Dec 14 10:11:43 kergoth_, is it just me who's ending in an endless loop in bb's logging? Dec 14 10:11:52 davidlt: in default case this is variable for local.conf Dec 14 10:11:58 davidlt, put it in your local.conf Dec 14 10:12:09 I see, ok Dec 14 10:53:16 export BBPATH="${OVEROTOP}/build:${USERBRANCH}:${OEBRANCH}" Dec 14 10:53:48 which local.conf is used. from overo-oe/build/conf/local.conf Dec 14 10:54:26 or fro overo-oe/org.openembedded.dev/contrib/ ... ? Dec 14 11:51:00 I am about to update the freerdp recipe ... Dec 14 11:51:28 however since I have been "out" of OE development for long time I am in doubt if we ought to use gitver or gitpkgv? Dec 14 11:59:32 JaMa|Wrk: : there's a problem here. Crofton broke it by installing the i2c-dev as i2c-user-dev Dec 14 11:59:54 JaMa|Wrk: i'd like to revert that so we need to bring it back to the mailing list Dec 14 12:01:19 ah I didn't know it's known problem Dec 14 12:02:37 yeah, it worked before Dec 14 12:05:05 there is only one package that lists i2c-dev as DEPENDS Dec 14 12:05:25 whicjh file is installed on your desktop? Dec 14 12:06:10 i2c-tools on Fedora 14 does not install that file and there is no -dev package Dec 14 12:07:50 on my gentoo it's the version installed by kernel headers.. sys-kernel/linux-headers-2.6.36.1 (/usr/include/linux/i2c-dev.h) Dec 14 12:08:02 my distro has something called libi2c-dev Dec 14 12:08:15 which overwrites the header Dec 14 12:08:18 where did they put the header? Dec 14 12:08:34 they added a "redirection" notice, but that's about it Dec 14 12:08:50 JaMa|Wrk: well, the problem is there are two versions Dec 14 12:09:06 03Martin Jansa  07master * recdd40e080 10openembedded.git/ (11 files in 4 dirs): Dec 14 12:09:06 xserver-xorg: 1.9.2.902 is now 1.9.3, remove old 1.9.2 Dec 14 12:09:06 Signed-off-by: Martin Jansa Dec 14 12:09:06 the i2c-tools one has static inline functions Dec 14 12:09:10 which the kernel one lacks Dec 14 12:09:13 and both get installed in the same place Dec 14 12:10:11 it just seems bizarre to me anyone would think it is a good idea to overwrite files in include/linux Dec 14 12:10:25 what package is having trouble? Dec 14 12:11:04 mickey|office: I know, I have checked the diff and used the right one to finish fsodeviced build locally Dec 14 12:11:39 mickey|office: just wanted to say that gentoo ebuild for i2c-tools also doesn't install i2c-dev.h (is using the one from kernel-headers) Dec 14 12:11:51 check libi2c-dev Dec 14 12:11:57 does gentoo have something like that? Dec 14 12:12:03 Crofton: fsodeviced Dec 14 12:12:09 with couple of warnings like: Dec 14 12:12:10 tools/i2cset.c:246:13: warning: called from here Dec 14 12:12:10 include/linux/i2c-dev.h:213:21: warning: inlining failed in call to ‘i2c_smbus_read_word_data’: call is unlikely and code size would grow Dec 14 12:12:22 heh Dec 14 12:12:34 mickey|office: gentoo have -dev as part of normal package Dec 14 12:13:45 basically, it appears desktops distros are not consistent Dec 14 12:14:01 if it is installed, uhd stops building Dec 14 12:14:24 I can talk with the author of uhd and see what he thinks Dec 14 12:14:41 although this is a erally bad time for this Dec 14 12:15:31 kergoth_, ok so, i'm ending up in an endless loop for bb.utils.mkdirhier("/foo") for the level 3 debug in that function. From the looks there is a loop in logging parents. I can reproduce it with 'bitbake -D -D -D -D -D -D -D -D -D -D -D -D -v -v -v -v -v -v -v -v -v stagemanager-native' Dec 14 12:15:59 mickey|office: in the meantime we can prefer i2c-tools-3.0.1 where it's not renamed :/ Dec 14 12:16:13 if it's new enough for fsodeviced Dec 14 12:16:40 that would lead to the risk of inconsistent builds; though Dec 14 12:16:53 the problem will drive you crazy when it happens Dec 14 12:17:32 crazy is that i2c-tools upgrade now removes i2c-dev and you have to know that you should rebuild linux-libc-headers to get any i2c-dev.h at all :) Dec 14 12:18:17 well, at least we know what the problem is now :) Dec 14 12:18:32 hi, what's the best between inherit autotools and an empty do_configure for Makefile based programs(no autotools) Dec 14 12:32:32 is it possible to set BB_LOCALCOUNT_OVERRIDE = "" for specific recipes only? Dec 14 12:34:37 no, only LOCALCOUNT afaik Dec 14 12:35:35 i just git pulled and took bitbake 1.8.18 but i get an bitbake error after parsing 100% File "/data/oe/101214/bitbake/lib/bb/__init__.py", line 100, in plain Dec 14 12:35:35 bb.msg.warn(''.join(args)) Dec 14 12:35:35 TypeError: warn() takes at least 2 arguments (1 given) Dec 14 12:40:43 rob_w: http://cgit.openembedded.org/cgit.cgi/bitbake/log/?h=1.8 see first commit Dec 14 12:41:48 so should i git pull bitbake or change this by hand ? Dec 14 12:42:02 thx btw !! Dec 14 12:42:47 it's not in a tagged release, so git pull; git checkout 1.8 should do it i believe Dec 14 12:45:55 sorry, probably need to reverse the order Dec 14 12:46:01 git checkout 1.8; git pull Dec 14 12:46:07 sure ;-) Dec 14 12:46:22 i will just fix it by hand . .thanks . i just want to run a quick build test Dec 14 14:40:07 * kergoth_ glares at subprocess Dec 14 14:40:16 denix: ping Dec 14 14:53:46 03Koen Kooi  07org.openembedded.dev * r9ff5ca924f 10openembedded.git/recipes/ti/ti-libd2cmap_git.bb: Dec 14 14:53:46 ti-libd2cmap: add git version that builds from the omapzoom L24.11 tag Dec 14 14:53:46 Signed-off-by: Koen Kooi Dec 14 14:53:49 03Koen Kooi  07org.openembedded.dev * rab0ecd9fed 10openembedded.git/recipes/ti/ti-tilermemmgr_git.bb: Dec 14 14:53:49 ti-tilermemmgr: add git version that builds from the omapzoom L24.11 tag Dec 14 14:53:49 Signed-off-by: Koen Kooi Dec 14 14:53:54 03Koen Kooi  07org.openembedded.dev * reefc9f1dbb 10openembedded.git/recipes/ti/ti-syslink_git.bb: Dec 14 14:53:54 ti-syslink: add git version that builds from the omapzoom L24.11 tag Dec 14 14:53:54 Signed-off-by: Koen Kooi Dec 14 14:53:56 03Koen Kooi  07org.openembedded.dev * r26d3cbffe1 10openembedded.git/recipes/ti/libdce_git.bb: Dec 14 14:53:56 libdce: add latest git Dec 14 14:53:56 Signed-off-by: Koen Kooi Dec 14 15:15:32 03Chris Larson  07master * r2c8683234a 10bitbake.git/lib/bb/ (build.py process.py): (log message trimmed) Dec 14 15:15:32 Fix PWD issue with new exec_func_shell Dec 14 15:15:32 The previous attempt was incorrect. The issue isn't that subprocess fails to Dec 14 15:15:32 set PWD, it's that PWD is in the metadata, inherited from the environment, and Dec 14 15:15:32 is re-exported, overwriting the actual accurate one in the shell environment Dec 14 15:15:33 with the old one from the metadata. So, ensure that PWD in the metadata is Dec 14 15:15:34 not exported. Dec 14 15:17:36 bitbake env handling sucks. Dec 14 15:19:53 and i'm not sure that i like poky's much better, but i don't have any better ideas offhand Dec 14 15:19:56 hrmph Dec 14 15:36:07 * kergoth_ glares at the lsb SDK Dec 14 15:59:26 kergoth_: Poky's is a step in the right direction, I'm not going to claim its perfect :/ Dec 14 15:59:38 s/right/better/ Dec 14 16:01:28 anybody has seen this error starting xinit before? Dec 14 16:01:30 FBIOPUT_VSCREENINFO: Invalid argument Dec 14 16:01:35 http://pastebin.com/cJU14Zrq Dec 14 16:09:46 damnit Dec 14 16:09:47 * kergoth_ grumbles Dec 14 16:22:49 interesting Dec 14 16:22:50 03Koen Kooi  07org.openembedded.dev * re2f8fbd164 10openembedded.git/recipes/ti/libdce_git.bb: Dec 14 16:22:50 libdce: roll back one commit Dec 14 16:22:50 17:09 <@robclark> koen: could you try rolling back one commit in libdce, and backing out that patch to set the two extra param's? Dec 14 16:22:50 17:09 <@robclark> I think all is not right with latest h264 decoder Dec 14 16:22:50 17:09 * robclark had just noticed the issues with some clips about 15 minutes ago.. so needs some time to debug Dec 14 16:22:51 Signed-off-by: Koen Kooi Dec 14 16:22:57 03Koen Kooi  07org.openembedded.dev * r44bc29c4c0 10openembedded.git/recipes/ffmpeg/omapfbplay-dce_git.bb: Dec 14 16:22:57 omapfbplay-dce: add DCE capable omapfbplay Dec 14 16:22:57 Signed-off-by: Koen Kooi Dec 14 16:22:58 03Koen Kooi  07org.openembedded.dev * r018b214c35 10openembedded.git/recipes/ffmpeg/omapfbplay_git.bb: Dec 14 16:22:58 omapfbplay: bump SRCREV Dec 14 16:22:58 Signed-off-by: Koen Kooi Dec 14 16:23:09 03Koen Kooi  07org.openembedded.dev * rebc22d904b 10openembedded.git/recipes/linux/ (9 files in 2 dirs): linux-omap4 2.6.35.3: add patches from Mans Dec 14 16:23:14 Python note: if you subclass 'file' for your own object, much code will bypass the write() on it and write to .fd on the object Dec 14 16:23:31 but if you just subclass object and implement the write method, it'll act closer to normal Dec 14 16:23:50 03Chris Larson  07master * r1c8be64732 10bitbake.git/lib/bb/build.py: Dec 14 16:23:50 build: fix -D with shell functions Dec 14 16:23:50 Signed-off-by: Chris Larson Dec 14 16:23:58 hrm Dec 14 16:28:15 03Chris Larson  07master * r0ebb46e252 10bitbake.git/lib/bb/build.py: Dec 14 16:28:15 build: ensure LogTee has a valid name property Dec 14 16:28:15 Signed-off-by: Chris Larson Dec 14 16:38:11 seems all my angstrom-2008.1 builds was failed.. Dec 14 16:40:15 yes, it is so Dec 14 16:47:32 Jay7: same thing here Dec 14 16:48:26 why? Dec 14 16:49:04 perl fails, kergoth_ is studying the root reason in bitbake Dec 14 16:49:28 which may already be solved in fact but I have to relaunch a build using bitbake master Dec 14 16:49:52 ah ok Dec 14 16:50:26 should be fixed now Dec 14 16:50:36 as of 2c8683234acf514706b2b69f5b29405485e664dd Dec 14 16:50:38 kergoth_: launching a build using master Dec 14 16:50:44 cool, let me know how it goes Dec 14 16:50:59 sorry about that, guess i didn't do enough test builds Dec 14 16:51:21 kergoth_: do you plan to merge the ui fixes of foerster ? Dec 14 16:52:04 kergoth_: don't I'm unskilled enough in bitbake to do some test while you improve the beast ;-) Dec 14 16:52:35 yes, i intend to merge that asap Dec 14 16:52:48 cool Dec 14 16:53:33 kergoth_: kind of "hacky", but what if we make another Event in bin/bitbake, and the server can check that to see if the main process is still alive. If not, it can shut down. Dec 14 16:53:54 then, in the future, if you run in daemon mode, it can just ignore that Event Dec 14 16:54:09 Event => multiprocessing.Event, not bb.event Dec 14 16:54:15 i figured :) Dec 14 16:54:30 hmm Dec 14 16:54:33 should help to eliminate the cases where server remains alive, like with kill, etc Dec 14 16:54:57 its better than nothing, and gets us to a state where we can merge with a bit more confidence Dec 14 16:55:01 we can always come up with another solution later Dec 14 16:55:04 right. Dec 14 16:56:27 kergoth_: hmm. That still won't work if you use kill with something we can't catch Dec 14 16:56:48 server needs pid of main process perhaps? Can check if alive periodically? Dec 14 16:56:56 ugly, but maybe necessary. Dec 14 16:57:16 hmm Dec 14 16:58:01 foerster: hi, for the ui wishlist, one cool thing would be to be able to launch bitbake on a compile server and be able to connect using the gtk ui froma remote workstation. Dec 14 16:58:50 ericben: good input. That's one of the reasons we're trying to split the server and UI, so cool things like that could be done. Dec 14 17:01:01 http://www.youtube.com/watch?v=3ZlOu-gLsh0 : yocto eclipse plugin screen cast Dec 14 17:09:22 vim plugin would be better :p Dec 14 17:10:12 kdevelop :) Dec 14 17:10:45 Makefiles! Dec 14 17:33:45 well.. minimal seems failing too Dec 14 17:43:04 Muahah Dec 14 17:43:19 Another man with OpenSP problems, at least it is confirmed Dec 14 18:08:37 I am an idiot :) Dec 14 18:11:31 Crofton|work: congratulations ;) Dec 14 18:12:14 dumb typo Dec 14 18:17:16 jo Dec 14 18:40:49 sakoman, ping Dec 14 18:41:04 03Steve Sakoman  07org.openembedded.dev * r6f0ed3e2ce 10openembedded.git/recipes/coreutils/ (coreutils-target.inc coreutils.inc): coreutils: experimental coreutils fix Dec 14 18:41:25 03Philip Balister  07org.openembedded.dev * rc63e599a33 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: i2c-tools : Fix dumb typo. Dec 14 18:41:36 I really should have editted the commit message from sakoman :) Dec 14 18:41:36 Crofton|work: pong Dec 14 18:41:43 I just pushed your fix Dec 14 18:41:57 even if it is not quite right, it is still better than what is in there now Dec 14 18:42:13 Crofton|work: heh, I didn't really intend for that to go upstream! It was just a hack to keep forward progress for a customer! Dec 14 18:42:30 right, it at least yeilds a working package Dec 14 18:42:34 well, we all have customers Dec 14 18:42:44 and the current behavior is completely wrong Dec 14 18:42:47 though I am still not sure why it doesn't work aas written Dec 14 18:42:51 yeah Dec 14 18:42:52 same here Dec 14 18:43:07 gm all Dec 14 18:43:09 gm Dec 14 18:43:10 that's why I haven't updated the patch with a real fix and message Dec 14 18:43:15 gm khem! Dec 14 18:43:26 jo khem Dec 14 18:43:29 * khem yawns Dec 14 18:43:31 and crofton and sakoman Dec 14 18:43:32 you should always plan for things to work and go upstream :) Dec 14 18:43:36 khem whats up? Dec 14 18:43:47 saves editing history Dec 14 18:44:33 Crofton|work: in this case I knew it was a complete hack Dec 14 18:44:39 sure Dec 14 18:44:56 and would never have submitted it myself for fear of boos and hisses Dec 14 18:44:58 :-) Dec 14 18:44:58 although I am not sure why they feel the need the existence test Dec 14 18:45:09 * Crofton|work has a thick skin Dec 14 18:45:30 and see earlier point about this creating more correct images Dec 14 18:45:33 me either -- poky doesn't have the -e tests Dec 14 18:46:35 that is the other reason I was ok pushing it Dec 14 18:46:43 we should check the history there :) Dec 14 18:49:18 hmmm Dec 14 18:50:02 jo kergoth Dec 14 18:50:50 khem, as the libc kind of guy, do you have any thoughts on the i2c-dev.h header file problem? Dec 14 18:51:00 from i2c-tools Dec 14 19:08:48 sakoman, did you ever figure out pulseaudio on gnome? Dec 14 19:10:30 Crofton|work: no, haven't gotten back to that yet Dec 14 19:11:42 after I stop futzing with the shipping image, I will try to look at it also Dec 14 19:12:05 * kergoth_ experiments with a slightly different way of handling compile/eval/exec for metadata python functions Dec 14 19:14:57 this is cleaner, i think. avoids the use of 'exec' entirely, just compiles it as a python function and hands you the function object via eval, for you to call as with any other function Dec 14 19:19:07 hmm Dec 14 19:19:40 think i might restart the new bb.event integration as a piecemeal integration, so i can work through the issues slowly rather than the entire bitbake run beating me over the head with complexities Dec 14 19:19:54 actually, think i'll postpone the integration entirely until a later time Dec 14 19:20:18 We should suggest the Linux Foundation send you to Hawaii and not let you return until you rewrite bitbake Dec 14 19:20:25 hehe Dec 14 19:20:35 we're making good progress on improving the code incrementally now Dec 14 19:21:09 Crofton|work: wasn't the next Yocto Summit in Hawaii anyway? Dec 14 19:21:21 foerster redid the server, i reworked portions of bb.cache for parallel parsing, the reimplemented bb.build works fine, though its api was the same Dec 14 19:21:26 * stefan_schmidt needs to re-think if he wants to candidate for the SC chair ;) Dec 14 19:21:32 foerster is also hacking away at the non-knotty UIs Dec 14 19:21:34 riofl Dec 14 19:21:36 bb.event is well on the way Dec 14 19:21:43 up next i want to test a runqueue that uses multiprocessing.Pool Dec 14 19:47:15 hmmmm Dec 14 19:49:34 Crofton|work: hmmm I think where we have conflicts with lnx kernel glibc tries to have its own file but uclibc is opposite and relies on kernel headers Dec 14 19:49:57 Crofton|work: and its sometimes case to case bases Dec 14 19:50:05 basically in short its messy Dec 14 19:50:14 khem, in this case, the i2c-dev.h file comes from a package that is not kernel, nor glibc Dec 14 19:50:14 and its a distribution policy in the end Dec 14 19:50:34 Crofton|work: ok now tell me where do they install this file Dec 14 19:50:52 include/linux/i2c-dev.h Dec 14 19:50:55 and I think they should be conflicting with lnx kernel Dec 14 19:50:59 over top of the kernel one Dec 14 19:51:41 ok Dec 14 19:51:47 now how does it get developed Dec 14 19:52:02 well, there seem to be two recipes in OE that use ut Dec 14 19:52:09 one expects the kernel version Dec 14 19:52:09 iow does the patches flow into i2c package and then into kernel ? Dec 14 19:52:18 the other expects the one from i2c-tools Dec 14 19:52:27 thats messy hmmm Dec 14 19:52:31 i2c-tools is user space only Dec 14 19:52:36 right Dec 14 19:53:07 what we can do is that install .h from i2c-tools in usr/include/i2c-tools Dec 14 19:53:26 yeah, that seems like a reasonable idea Dec 14 19:53:27 and redirect the compiler to choose the right one for those given packages Dec 14 19:53:38 thats what we do in OE in general Dec 14 19:54:03 so default remains to use the one from kernel Dec 14 19:54:53 and if someone needs the one from i2c-tools he/she adds a DEPENDS on i2c-tools to recipe and prepends right -I option which peeps into /usr/include/i2c-tools Dec 14 19:55:06 before /usr/include/linux Dec 14 19:55:19 that avoids the problem of wiping out the kernel one Dec 14 19:55:23 yes Dec 14 19:55:36 and I do not think it is good for OE to let this be a DISTRO decision :) Dec 14 19:56:47 with distro I meant not OE distros but other distros like debian/fedora etc Dec 14 19:56:55 in this case OE is also a distro Dec 14 19:57:05 not the offsprings of OE Dec 14 19:57:11 OE is not a distro, it is build system for distros :) Dec 14 19:57:26 oh well I know heh I am putting a different context Dec 14 19:57:32 i can't believe you can't build the latest m4 without *gperf* installeed Dec 14 19:57:32 :) Dec 14 19:57:34 what the fuck Dec 14 19:57:39 must stay on message Dec 14 19:57:44 kergoth_, ? Dec 14 19:57:49 ah Dec 14 19:57:50 ok Dec 14 19:58:04 outside of oe, building the bleeding edge m4 Dec 14 19:58:08 yeah Dec 14 19:58:18 I saw the wtf, not the first line Dec 14 19:58:25 * HACKING: Mention new prerequisite of gperf. Dec 14 19:58:27 :| Dec 14 19:58:31 kergoth_: which version of m4 ? Dec 14 19:58:31 very strange Dec 14 19:58:40 oh bleeding ... Dec 14 19:58:41 * kergoth_ digs for a disable option Dec 14 19:59:04 it should just need texi2html thats it other than libc Dec 14 19:59:45 ah, i think its recent gnulib that's the problem Dec 14 19:59:50 and m4 uses gnulib Dec 14 20:00:23 are they using some sort of hash or what now Dec 14 20:00:45 why does m4 use gnulib Dec 14 20:01:38 gnulib/lib/gen-uni-tables.c:7189: We use gperf to implement the hash lookup, giving it the 928 sets of Dec 14 20:01:42 * kergoth_ rolls eyes Dec 14 20:02:20 kergoth_: ok however I dont see a reason for m4 to depend on gnulib Dec 14 20:02:22 mhhh release-2010.12 no longer exist ?! ... Dec 14 20:02:36 gremlin[it]: tag should be there Dec 14 20:02:46 branch should not Dec 14 20:03:02 ** A number of portability improvements inherited from gnulib. Dec 14 20:03:05 how very vague Dec 14 20:03:36 hrmm Dec 14 20:10:26 I am pushing the cross localedef changes Dec 14 20:10:34 nice Dec 14 20:10:40 so they get tested before next testing is pulled in Dec 14 20:10:46 I will work on making it more parallel Dec 14 20:10:53 so it builds them n times faster Dec 14 20:14:01 03Khem Raj  07master * r4e6b1bfe28 10openembedded.git/ (21 files in 3 dirs): (log message trimmed) Dec 14 20:14:01 eglibc/glibc: Use/add cross-localedef to generate locales Dec 14 20:14:01 * Add recipe for cross-localedef-native Dec 14 20:14:01 * Consolidate eglibc/glibc to share common contructs in bbclass Dec 14 20:14:01 * Move common code in eglibc to eglibc.inc Dec 14 20:14:01 * By default use cross-locaedef to generate locales now instead of qemu Dec 14 20:14:02 Signed-off-by: Khem Raj Dec 14 20:14:13 03Khem Raj  07master * rcf2f37aaa8 10openembedded.git/recipes/gcc/ (gcc-4.5.inc gcc-4.5/gcc-revert-pr42172.patch): Dec 14 20:14:13 gcc-4.5.inc: Revert PR 42172 backport Dec 14 20:14:13 * This fixes the gcc ICE as seen compiling samba Dec 14 20:14:13 Signed-off-by: Khem Raj Dec 14 20:14:13 Acked-by: Eric Bénard Dec 14 20:14:16 03Khem Raj  07master * r4ba7aa07c0 10openembedded.git/recipes/samba/samba_3.2.15.bb: Dec 14 20:14:16 samba_3.2.15.bb: Fix build failure on ARM/thumb due to GCC ICE Dec 14 20:14:16 * As a hotfix we currently avoid compiling it in thumb mode. Dec 14 20:14:16 Due to gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 Dec 14 20:14:17 Signed-off-by: Khem Raj Dec 14 20:15:47 hmm, calculate_task_weights really belongs in the RunqueueSchedulerSpeed, but it'd have to be split first, the weights into there but the circular dep checking moved out Dec 14 20:15:50 which makes sense anyway.. Dec 14 20:15:52 hmm Dec 14 20:23:34 khem, do you have a personal branch about avr32 target ? ... or better if i play with testing-next ? Dec 14 20:25:15 gremlin[it]: no there is no separate branch for avr32 Dec 14 20:25:35 gremlin[it]: you are probably better off starting from release or one of the testing tags Dec 14 20:27:20 khem now i#m trying with release-2010.12 but seem it stop early at gcc-cross :( ... Dec 14 20:29:51 err ok Dec 14 20:30:09 not surprising we did not test many combos and certainly no one tested avr Dec 14 20:31:17 latest testing work quite well ... it stopped at x264 ... and i don't need it Dec 14 20:44:23 kergoth_: even with bitbake master I still have the perl-5.8.8 problem : ./miniperl : command not found Dec 14 20:45:10 * kergoth_ kicks off a perl build Dec 14 20:47:26 | configure.ac:382: warning: macro `AM_GCONF_SOURCE_2' not found in libra Dec 14 20:53:23 hmm || make/ threaded BB problem with libcanberra I think Dec 14 20:59:53 khem: What sort of solution is preferrable for the svn checkout for eglibc? Dec 14 21:00:32 rphillips, this is use of svn port versus http? Dec 14 21:01:10 Crofton|work: right Dec 14 21:01:23 you understand the bigger issue? Dec 14 21:01:32 not really Dec 14 21:01:36 what is the bigger issue? Dec 14 21:01:53 that OE is hopeless if you don't have svn, git, possibly cvs ports available Dec 14 21:02:18 so swictching one recipe to http does not really make much of a difference Dec 14 21:02:55 i beg to differ... it actually does... svn, git, and mercurial all support http transport which is proxiable Dec 14 21:03:09 s/[D// Dec 14 21:03:24 cvs is a problem Dec 14 21:03:35 but there are very few things that are still in CVS Dec 14 21:03:38 sure Dec 14 21:04:02 but my understanding is not all git servers support http for example Dec 14 21:04:35 no they don't... that is an issue, but repo.or.cz does have a decent bridge that works Dec 14 21:04:59 the new git-http-backend is extremely good. Dec 14 21:05:22 the problem is we can't dictate to every project that they provide a http based way to get the source Dec 14 21:05:29 it's the git protocol over http, so it's time complexity is on the same order as a git protocol checkout Dec 14 21:05:39 I understand the technical issues Dec 14 21:06:12 I believe the patch is an incremental improvement of a core piece of OE. Dec 14 21:06:12 if we change to http for eglibc, what will we do for the next package that creates this problem?? Dec 14 21:06:45 I'm sort of wondering what is in poky also :) Dec 14 21:06:59 do what I did... I went to the eglibc team and requested they export their repository over http. it took them some time, but they got around to it Dec 14 21:07:00 * kergoth_ thinks we should start maintaining a git repo per source on git.openembedded.org with our sources, pre-patched, per-version branches Dec 14 21:07:11 I have a request pending with Yocto to enable git over http Dec 14 21:07:20 heh Dec 14 21:07:36 wouldn't it be easier to explain this to your IT group? Dec 14 21:07:47 * Crofton|work has some understanding of that level of pain though Dec 14 21:08:00 not at the company I work for Dec 14 21:08:19 which is dell Dec 14 21:08:28 yeah I worked that out :) Dec 14 21:08:30 what's so difficult on tunneling all needed repos? Dec 14 21:08:35 * kergoth_ thinks dell should at least open up CONNECT Dec 14 21:09:04 * JaMa|Off was building and using all services on public wifi with only :80 enabled for more then 2 months Dec 14 21:09:08 it's a policy that most likely won't change Dec 14 21:09:36 heh, that sort of draconian policy leads to sneakernets and worse security Dec 14 21:09:59 * kergoth_ fondly recalls sending all of his work traffic through ppp over ssh to his house ;) Dec 14 21:10:12 JaMa|Off, do you have an example how to do that? Dec 14 21:10:47 JaMa|Off: their http proxy doesn't support CONNECT, so i don't see how you'd be able to do that without control over a server on the remote end to tunnel through Dec 14 21:11:04 rphillips, does switching eglibc to http completely solve your specific problem? Dec 14 21:12:10 Crofton|work: yes. currently without the patch the svn checkout just hangs. We get a complete minimal-image built fine with the rest of the defaults with the patch Dec 14 21:12:56 you can't ssh out? Dec 14 21:13:37 * kergoth_ hacks on bb.runqueue Dec 14 21:13:43 I'm ssh'ed out now :) but it's a long process, and isn't a 'normal' work environment Dec 14 21:14:19 run an ssh tunnel with socks, painless, just point local bits to the socks proxy that funnels over the ssh connection to work Dec 14 21:14:30 erm, home Dec 14 21:14:37 * kergoth_ can't type/think today Dec 14 21:14:55 it's what I'm doing now... but I can't tell a hundred developers to go do that Dec 14 21:15:17 ah, right Dec 14 21:16:24 can you sue the layer/amend that khem suggested? Dec 14 21:17:00 that might be helpful if you run into other problems like this down the road, where there is no easy solution Dec 14 21:17:35 we can suggest the TSC recommend people prefer http urls in recipes Dec 14 21:18:24 Crofton|work: I was using sshd on home:443 and first switching git:// svn:// destination manually with script, later I just routed every git:// svn:// through vpn also on home:443 Dec 14 21:19:58 when I worked on gentoo years ago, it was frowned upon using vcs checkouts... developers would snapshot them, then the mirrors would pick it up. Dec 14 21:20:14 if hundred developers need to fight with corporate proxy then something is wrong :) Dec 14 21:20:20 the layer/amend suggestion is good. we'll probably leverage that Dec 14 21:20:37 and only one developer is enough to maintain in-company OE pre-mirror :) Dec 14 21:20:48 JaMa|Off, I think we have all been politely avoiding that :) Dec 14 21:21:23 * JaMa|Off has nothing against switching to http:// where possible.. :) Dec 14 21:24:25 thanks for the feedback Dec 14 21:25:37 rphillips, we can't save the world from IT guys :) Dec 14 21:26:19 hahahhahahaha +1 Dec 14 21:27:35 i'm trying to 'teach' this company ways on doing things better and interfacing with open source... it's a slow process Dec 14 21:29:36 yeah, I understand Dec 14 21:29:51 I once worked for "the man" (not Dell though) Dec 14 22:15:33 03Martin Jansa  07master * r03d662450e 10openembedded.git/recipes/freesmartphone/msmcomm.inc: Dec 14 22:15:33 msmcomm: bump SRCREV to compatible version with current cornucopia SRCREV Dec 14 22:15:33 Signed-off-by: Martin Jansa Dec 14 22:19:58 * kergoth_ wonders how long a bitbake -k -n world will take Dec 14 22:20:27 http://tinderbox.openembedded.net/builders/Jay7-tb/ Dec 14 22:20:36 tonights build run Dec 14 22:20:46 qemux86 was failed too Dec 14 22:21:11 just something is wrong with oestats again Dec 14 22:21:56 ericben|away: i just built perl fine *shrug* any particular configuration that encounters it? Dec 14 22:23:12 http://pastebin.ca/2019789 Dec 14 22:23:28 grep ERROR from logs Dec 14 22:25:07 khem: B.testing.minimal.qemux86.log:ERROR: locale_arch_options not found for target_arch=i686 Dec 14 22:25:08 B.testing.minimal.qemux86.log:ERROR: unknown arch:i686 for locale_arch_options Dec 14 22:25:16 this may be interesting for you Dec 14 22:25:22 if not was fixed already Dec 14 22:34:20 bluelightning: I'll remember you about checksums :) Dec 14 22:52:57 Jay7: yep, almost finished writing a python script to mangle all of the recipes Dec 14 22:54:04 well.. now I have tmpdirs with {angstrom-2008.1, minimal} {collie, akita, efikamx, ben-nanonote, qemux86} Dec 14 22:55:34 did anyone else recieve some Lab126 kindle/amazon job recruitment spam recently? Dec 14 22:56:01 * grg wonders where the very targetted spam's spammer got their email addresses Dec 14 22:56:17 grg: linkedin? Dec 14 22:56:38 cisco HR spam was coming from there one time :) Dec 14 22:56:44 Jay7, nah. i don't do linkedin Dec 14 22:57:21 it just seems really targetted, because i work on an ebook reader and i got a recruitment mail to work on the kindle... Dec 14 22:57:46 either its a coincidence and lots of people got it, or someone is stalking me Dec 14 23:03:58 cross-localedef is definitely faster :) Dec 14 23:04:52 (dreaming mode) better to do it in parallel.. Dec 14 23:09:27 NOTE: Multiple libraries (libnss_nis.so.2, libnss_nisplus.so.2, libnss_hesiod.so.2) found, but LEAD_SONAME 'libc.so' doesn't match any of them Dec 14 23:09:30 JFYI Dec 14 23:09:44 NOTE: Couldn't find shared library provider for libgcc_s.so.1 Dec 14 23:09:49 another JFYI :) Dec 14 23:41:56 hm.. kexec-tools-klibc is failing again Dec 14 23:55:03 http://tinderbox.openembedded.net/packages/1280010/ Dec 14 23:55:09 gettext is failed Dec 14 23:55:34 minimal/{collie, tosa} Dec 14 23:55:48 +efikamx Dec 15 00:38:10 hm.. Dec 15 00:38:24 bitbake -c compile kexec-tools-klibc fails Dec 15 00:38:41 but using devshell and starting run_oemake there is working ok Dec 15 00:38:50 what is wrong? Dec 15 00:40:08 whats in the log when it does fail? Dec 15 00:40:52 it's just failing with http://pastebin.ca/2019864 Dec 15 00:41:04 ERROR: Task 6 (/storage/oe/testbuilder/openembedded/recipes/kexec-tools/kexec-tools-klibc_2.0.2.bb, do_compile) failed with exit code '256' Dec 15 00:41:24 I'm looking into run.do_compile Dec 15 00:43:24 hm.. looking ok for my experience.. Dec 15 00:43:59 there is no log.do_compile* at all Dec 15 00:53:17 03Paul Eggleton  07master * r44b0a42ec8 10openembedded.git/recipes/libqpe/libqpe-opie_1.2.5.bb: Dec 15 00:53:18 libqpe-opie: fix 1.2.5 recipe to use INC_PR Dec 15 00:53:18 Signed-off-by: Paul Eggleton Dec 15 00:53:31 03Paul Eggleton  07master * r01133f3860 10openembedded.git/recipes/ (179 files in 170 dirs): Dec 15 00:53:31 Opie: add checksums to 1.2.4 recipes Dec 15 00:53:31 Signed-off-by: Paul Eggleton Dec 15 00:53:32 03Paul Eggleton  07master * r80deab3c97 10openembedded.git/recipes/opie-reader/ (opie-reader.inc opie-reader_1.2.4.bb opie-reader_1.2.5.bb): Dec 15 00:53:32 opie-reader: fix SRC_URI and INC_PR Dec 15 00:53:32 * SRC_URI has been removed from the inc file and added to 1.2.4 version Dec 15 00:53:32 * Fixed 1.2.5 version to use INC_PR as other opie-reader files do Dec 15 00:53:33 Signed-off-by: Paul Eggleton Dec 15 00:53:33 03Paul Eggleton  07master * r7fb797ff59 10openembedded.git/recipes/opie-i18n/opie-lrelease-native_1.2.5.bb: Dec 15 00:53:34 opie-lrelease-native: fix 1.2.5 recipe to use INC_PR Dec 15 00:53:34 Signed-off-by: Paul Eggleton Dec 15 00:53:35 03Paul Eggleton  07master * r1ee0629b1e 10openembedded.git/recipes/opie-icon-reload/opie-icon-reload_1.2.5.bb: Dec 15 00:53:37 opie-icon-reload: add 1.2.5 version Dec 15 00:53:37 Signed-off-by: Paul Eggleton Dec 15 00:53:37 03Paul Eggleton  07master * r9efe17f2fc 10openembedded.git/recipes/ (182 files in 170 dirs): Dec 15 00:53:37 Opie: add checksums to 1.2.5 recipes Dec 15 00:53:37 Signed-off-by: Paul Eggleton Dec 15 01:07:46 03Paul Eggleton  07master * r9ec2920dd8 10openembedded.git/contrib/opie/ (4 files): Dec 15 01:07:46 contrib/opie: add useful management scripts Dec 15 01:07:46 Add scripts to aid management of Opie recipes and source tarballs Dec 15 01:07:46 Signed-off-by: Paul Eggleton Dec 15 01:18:23 Jay7: there you go :) Dec 15 01:18:37 bluelightning: cool! :) Dec 15 01:18:50 I'll fire up testbuilder Dec 15 01:22:21 bluelightning: started for my zauruses Dec 15 01:22:49 but we have broken gettext and kexec-tools-klibc.. Dec 15 01:23:06 so not sure how much it will do Dec 15 01:26:44 Jay7: hmm :( Dec 15 01:26:50 thanks for testing though Dec 15 01:27:05 I did a test fetch of all recipes, worked OK Dec 15 01:36:58 * Jay7 -> sleep Dec 15 01:36:59 khem, TARGET_FPU = "soft" appears to have been broken with your latest {e,}glibc changes Dec 15 01:37:29 --without-fp does not appear in run.do_configure, while it did in my last build Dec 15 01:37:49 And i get this failure http://tinderbox.openembedded.net/packages/1279490/ Dec 15 01:38:17 i686 is broken too as I see Dec 15 01:39:46 * bluelightning -> sleep also Dec 15 01:42:26 grg: hmmm I see Dec 15 01:43:23 interestingly, in my last build, without-fp is passed to configure twice Dec 15 01:44:00 03Chris Larson  07master * r82f0e471f0 10bitbake.git/lib/bb/runqueue.py: Dec 15 01:44:00 runqueue: fix a get_task_id call Dec 15 01:44:00 Signed-off-by: Chris Larson Dec 15 01:46:53 khem, fyi, here's a diff of the two run.do_configure scripts: http://pastebin.com/936BUi6f Dec 15 01:47:03 grg: try this untested patch http://pastebin.com/phsQSH41 Dec 15 01:47:08 :) Dec 15 01:51:33 khem, yes, that did the trick. Thanks Dec 15 01:51:45 can add my acked-by Dec 15 01:53:09 grg: ok thx Dec 15 01:53:20 grg: have you played with yocto ? Dec 15 01:54:54 grg: which MACHINE should I try to test it out Dec 15 02:03:16 thanks grg for reporting it pushed the fix now Dec 15 02:03:18 03Khem Raj  07master * rec41074add 10openembedded.git/recipes/eglibc/eglibc.inc: Dec 15 02:03:18 eglibc.inc: Pass FPU type to GLIBC_EXTRA_OECONF Dec 15 02:03:18 Signed-off-by: Khem Raj Dec 15 02:03:18 Acked-by: Graham Gower Dec 15 02:07:58 khem, i have MACHINE=qemumipsel and TARGET_FPU=soft in my local.conf Dec 15 02:08:09 haven't played with yocto, no Dec 15 02:08:13 its on my todo list Dec 15 02:08:27 grg: ok Dec 15 02:08:34 anyway tested with ppc405 and arm Dec 15 02:08:38 and seems to be fixed now Dec 15 02:09:30 03Chris Larson  07master * r49e06bba60 10bitbake.git/lib/bb/runqueue.py: Dec 15 02:09:31 runqueue: fix check_stamp_task call in chck_stamp_fn Dec 15 02:09:31 Signed-off-by: Chris Larson Dec 15 02:09:54 blah, typo **** ENDING LOGGING AT Wed Dec 15 02:59:57 2010