**** BEGIN LOGGING AT Wed Sep 22 02:59:57 2010 Sep 22 03:07:25 khem, as far as i can tell, the bad libbfd.a comes from emacs Sep 22 03:07:41 which has some funky treedir thing Sep 22 03:44:36 hi , when i try to compile sgx with "bitbake omap3-sgx-modules" , i got error on_compile bc_cat.c:490: error: implicit declaration of function 'omap_rev_lt_3_0' , how to fix this problem ? any solution ? Sep 22 03:49:08 JDuke127, you should post to the mailing list with complete logs. Maybe someone there will be able to help. Sep 22 03:51:07 JDuke127: arch/arm/plat-omap/include/plat/cpu.h Sep 22 03:51:16 thats where it is defined Sep 22 03:59:05 ok Sep 22 03:59:08 i send it now Sep 22 04:00:36 do_compile logs? Sep 22 04:01:38 khem, emacs was a red herring. it just has a libbfd.a with the same checksum in its work dir because it copied it from staging Sep 22 04:04:25 ok i got it Sep 22 04:04:29 now i put it on pastebin Sep 22 04:04:51 grg , http://pastebin.com/SV8i88kt Sep 22 04:04:55 khem Sep 22 04:05:17 JDuke127: arch/arm/plat-omap/include/plat/cpu.h , i put Sep 22 04:07:05 i think khem's point was that on_compile bc_cat.c should be including cpu.h somehow Sep 22 04:07:27 hmm let me look Sep 22 04:10:57 ok Sep 22 04:11:05 grg , http://pastebin.com/aggLfKKA Sep 22 04:11:15 my bc_cat.c file Sep 22 04:14:10 i add this ? #include Sep 22 04:19:02 JDuke127, that doesn't look right. Most likely, the kernel makefile(s) should have added arch/arm/plat-omap/include to your include path, and you would have a machine independent include that will pull in the machine dependent file Sep 22 04:19:17 e.g. its quite possible you actually want to include Sep 22 04:19:55 does bc_cat.h include anything? Sep 22 04:26:03 i ve found some error on OMAP Rules.make Sep 22 04:26:23 wrong include path? Sep 22 04:26:23 GRAPHICS_INSTALL_DIR=$(HOME)/INVALIDVAL Sep 22 04:26:47 what must i do for that ? Sep 22 04:27:26 i don't have an omap, nor do i have the package you are having problems with.... sorry, my assistance can only be of a general nature. Sep 22 04:27:45 /home/kadirbasol/INVALIDVAL/GFX_Linux_KM: No such file or directory. Sep 22 04:27:56 now i tried to make , make myself Sep 22 04:28:13 maybe i dont do bitbake will do it in future if compile success? Sep 22 04:30:14 brb Sep 22 05:49:48 bugzilla and tinderbox might be offline for a teensy while Sep 22 05:56:08 hi i am facing problem with bitbake Sep 22 05:56:32 i am behind a proxy and i am unable to download cross compliers and things Sep 22 05:56:39 what to do ? Sep 22 05:56:51 i am stuck for about 2 days Sep 22 05:57:02 please someone help me Sep 22 05:57:04 ?? Sep 22 05:57:43 i want cross complier for gumstix Sep 22 05:57:51 please help me? Sep 22 05:59:40 ???? Sep 22 05:59:58 anyone ?????????? Sep 22 06:00:11 11pm in California...7am in .eu Sep 22 06:00:34 patience will probably be the best thing now. Sep 22 06:00:42 back to working on the servers. Sep 22 06:03:01 ???? Sep 22 06:03:06 any one alive?? Sep 22 06:06:32 03Yann Dirson  07master * r287f5ec79c 10openembedded.git/recipes/git/git_1.7.0.2.bb: (log message trimmed) Sep 22 06:06:32 git: split space-hungry rarely-used commands into -perltools and -large packages. Sep 22 06:06:32 This trims the main package by ~75%, and split of all perl scripts allows Sep 22 06:06:32 to spare the installation of perl, which is no small bargain either. Sep 22 06:06:32 Note that git-remote-http triggers a strange bug (OE#5465), so it is not Sep 22 06:06:32 split out for now. Sep 22 06:06:33 Also drop cpio dependency, which has been unneeded since a number of git Sep 22 06:06:33 03Graham Gower  07master * r71d25fe210 10openembedded.git/recipes/mupdf/ (3 files in 2 dirs): Sep 22 06:06:35 mupdf_0.6.bb: remove recipe. Sep 22 06:06:35 This is now an old release. Much better to use git version instead, Sep 22 06:06:36 as the release tarballs get moved once a new release occurs. Sep 22 06:06:41 Signed-off-by: Graham Gower Sep 22 06:06:41 Signed-off-by: Khem Raj Sep 22 06:06:41 03Graham Gower  07master * recebb10a37 10openembedded.git/recipes/mythfront/mythfront-config.bb: Sep 22 06:06:41 mythfront-config.bb: Fix do_unpack for machines other than epia. Sep 22 06:06:42 Signed-off-by: Graham Gower Sep 22 06:06:42 Signed-off-by: Khem Raj Sep 22 06:06:43 03Yann Dirson  07master * r50fc7462c4 10openembedded.git/recipes/git/git_1.7.0.2.bb: Sep 22 06:06:43 git: replace remaining broken hardlinks with symlinks. Sep 22 06:06:43 Signed-off-by: Yann Dirson Sep 22 06:06:44 Signed-off-by: Khem Raj Sep 22 06:06:45 03Graham Gower  07master * rcffcd879fd 10openembedded.git/recipes/opkg/opkg.inc: (log message trimmed) Sep 22 06:06:45 opkg: disable GPLv3 code. Sep 22 06:06:57 03Yann Dirson  07master * r2823e121e8 10openembedded.git/recipes/git/ (git-native_1.7.0.2.bb git.inc git_1.7.0.2.bb): (log message trimmed) Sep 22 06:06:57 git: activate gitk. Sep 22 06:06:57 It does not work perfectly (complains about possible problems in the tcl Sep 22 06:06:57 package), and buttons are huge, but it allows to browse history. Sep 22 06:06:59 git-gui OTOH does not start at all, it only complains that tk is not Sep 22 06:06:59 correctly installed, so it is commented out. Sep 22 06:06:59 Signed-off-by: Yann Dirson Sep 22 06:07:10 ?? Sep 22 06:10:40 03Michal Minar  07master * rf52590bd49 10openembedded.git/recipes/grub/ (grub-0.97/grub-support-256byte-inode.diff grub_0.97.bb): (log message trimmed) Sep 22 06:10:40 grub 0.97: fixing broken 256byte-inodes patch Sep 22 06:10:40 * original patch causes termination of grub with floating point exception, Sep 22 06:10:40 when operating upon ext2 partitions Sep 22 06:10:40 * the bug description came from: Sep 22 06:10:40 http://bugs.gentoo.org/show_bug.cgi?id=220687 Sep 22 06:10:42 * fixed patch was done by RB Sep 22 06:12:34 03Khem Raj  07master * rde6f06e7d5 10openembedded.git/recipes/libnl/ (libnl2_git.bb libnl_1.1.bb): Sep 22 06:12:34 libnl: Update the homepage url and download urls Sep 22 06:12:34 * Move the git recipe to tip of git. Sep 22 06:12:34 Signed-off-by: Khem Raj Sep 22 06:25:22 khem: morning Sep 22 06:26:09 thought I'd see if the latest patches fixed my sdk-issue, but which patches from you and/or ericben|away should I use? Sep 22 06:27:11 Is there some simple way of determining which recipe staged which file(s) while using rm_work? Sep 22 06:28:40 03Rui Miguel Silva Seabra  07org.openembedded.dev * ra08ed37b1e 10openembedded.git/recipes/omnewrotate/omnewrotate_svn.bb: Sep 22 06:28:40 omnewrotate: bump SRCREV Sep 22 06:28:40 Signed-off-by: Martin Jansa Sep 22 06:28:42 03Martin Jansa  07org.openembedded.dev * rc8a0ee39a2 10openembedded.git/recipes/linux/ (21 files in 2 dirs): Sep 22 06:28:42 linux-openmoko-2.6.34: upgrade to 2.6.34.7 and add patch for lower power consumption in suspend Sep 22 06:28:42 Signed-off-by: Martin Jansa Sep 22 06:38:18 good morning Sep 22 07:17:22 03Koen Kooi  07org.openembedded.dev * re9375f6ec6 10openembedded.git/recipes/netbase/netbase_4.21.bb: Sep 22 07:17:22 netbase: bump PR after 56fa8d7ad350fcbb5dedaa80c656da0bb59a2e7b Sep 22 07:17:22 caught by angstrom testlab: http://gitorious.org/angstrom/angstrom-testlab/commit/2cca591bdb5110fe2bd0f090092645d02c6b8e1a Sep 22 07:17:24 03Koen Kooi  07org.openembedded.dev * r924c62c1c4 10openembedded.git/recipes/alsa/alsa-state.bb: Sep 22 07:17:24 alsa-state: bump PR after 56fa8d7ad350fcbb5dedaa80c656da0bb59a2e7b Sep 22 07:17:24 caught by angstrom testlab: http://gitorious.org/angstrom/angstrom-testlab/commit/bfa0eab7743be68515c730d86fd6cb9b30eb5ef2 Sep 22 07:32:08 morning Sep 22 07:32:49 grg: check files in pstage dir? Sep 22 07:42:15 hrw, thanks, will play tomorrow Sep 22 07:56:58 hi Sep 22 07:57:50 ericben: morning. I applied the patches I suspected were relevant. compiling now. Sep 22 07:58:31 tasslehoff: you can take khem's patch ++ mine for gdb-cross-sdk until I manage to get gdb link ncurses libs statically Sep 22 07:59:49 for information: I will add Linaro gcc into OpenEmbedded Sep 22 08:00:06 ericben: that's the only one I didn't pull in :). I changed mpfr, gmp and gcc-cross. Sep 22 08:01:02 well for the others, khem's patch fixe the problem Sep 22 08:01:16 hrw: interesting, their bench on arm seems promising Sep 22 08:01:37 ericben: I know, I work for them Sep 22 08:01:49 yes I've seen you effort on the packagin ;) Sep 22 08:02:41 if one day you can ask linaro's marketing to write a what is linaro for dummies, this would be great as I still don't understand the goals of this project Sep 22 08:07:37 my view is that Linaro is doing all to make ARM work faster and make platform less complicated Sep 22 08:08:02 ARM kernel compared to x86 kernel is totally other world Sep 22 08:08:18 lot of platform related code, kernels bound to machines Sep 22 08:08:41 on x86 you can build kernel which will boot and work on most of machines. on arm you can't Sep 22 08:08:58 but Linaro works on making single kernel work on many ARM devices Sep 22 08:09:40 ericben: after compiling with khem's patch from .dev, my sdk only contains libmpfr for arm. is the upstream patch not the latest version? Sep 22 08:17:05 hrw: do you think this is a critical feature to be able to boot one kernel on many ARM devices ? Sep 22 08:17:41 except for having a ubuntu for ARM easy to install Sep 22 08:18:14 my understanding is that most products manufacturer customize their kernel which makes it platform dependent Sep 22 08:19:13 anyway, I hope Linaro's kernel will bring better support of i.MX51 in the mainline kernel, especially for video & multimedia features Sep 22 08:20:46 tasslehoff: khem's patch make all these libs compiled statically in gcc Sep 22 08:20:55 morning Sep 22 08:21:26 ericben: ah, so I shouldn't find the files in my sdk. Sep 22 08:22:22 do a readelf -d on gcc & cc1plus in the sdk to check Sep 22 08:25:34 ericben: cc1plus lists mpfr and gmp as needed Sep 22 08:26:16 ericben: I tried cleaning gmp, mpfr, gcc-cross and my toolchain-recipe. now recompiling Sep 22 08:27:02 03Koen Kooi  07org.openembedded.dev * r284286b126 10openembedded.git/recipes/xorg-lib/ (7 files in 2 dirs): Sep 22 08:27:02 pixman 0.19.4: add latest release from the unstable series Sep 22 08:27:02 * forward port the overlapped blit patches Sep 22 08:27:02 * add NEON optimization for 16bpp Sep 22 08:27:02 * fix fast path flags for PAD Sep 22 08:28:05 tasslehoff: clean & build gdb-cross-sdk Sep 22 08:43:52 good morning Sep 22 08:44:13 hi florian Sep 22 08:44:22 hi mckoan Sep 22 08:45:49 ericben: it still needs those libraries shared. could I be missing a patch? Sep 22 08:46:38 tasslehoff: I'll retest and let you know Sep 22 08:49:18 tasslehoff: here cc1plus ont needs libc.so.6 Sep 22 08:49:24 only needs Sep 22 08:49:46 so there is something wrong in your tree$ Sep 22 08:51:20 ericben: and you don't have any local patches / patches not in .dev yet? Sep 22 08:51:53 only khem's commit 03ba2d4f86360abbcfed2a7350a93d3b3777f280 Sep 22 08:53:17 ericben: where/how can I find that one? Sep 22 08:53:25 find/apply Sep 22 08:53:40 using git Sep 22 08:54:34 or you go through cgit generate the patch and apply it on your tree http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=03ba2d4f86360abbcfed2a7350a93d3b3777f280 Sep 22 08:55:19 ericben: that much I understood :-). so this is a commit in upstream but not yet in .dev, that I can (somehow) pull? Sep 22 08:55:22 thanks Sep 22 08:56:26 it is in dev Sep 22 08:56:35 git cherry pick the commit Sep 22 08:57:04 ericben: yeah. I see I already have it... I'm tempted to throw out my TMPDIR and rebuild everything. Sep 22 08:57:38 tasslehoff: did you remove my patches ? Sep 22 08:57:52 and only keep khem's one Sep 22 08:58:13 ericben: yes. was that a bad move? Sep 22 08:59:53 tasslehoff: maybe you also need to rebuild gmp-native libelf-native libmpc-native and mpfr-native then gcc-cross-sdk Sep 22 09:00:06 else the static libs are not yet built Sep 22 09:00:43 ericben: ok. should I keep your patches, or do I only need khem's? Sep 22 09:00:53 only khem's one Sep 22 09:32:19 ericben: that did the trick :) Sep 22 09:32:27 thanks for the coaching Sep 22 09:32:58 ~curse new patch.bbclass Sep 22 09:32:58 May the fleas of a thousand camels infest your most sensitive regions, new patch.bbclass ! Sep 22 11:44:26 03Steffen Sledz  07org.openembedded.dev * r0a543300de 10openembedded.git/recipes/libunwind/libunwind.inc: Sep 22 11:44:26 libunwind: unbreak native build Sep 22 11:44:26 Signed-off-by: Steffen Sledz Sep 22 12:09:20 03Sergey Stasishin  07org.openembedded.dev * r48031c31dd 10openembedded.git/recipes/live555/live555.inc: live555: Packaging live555MediaServer too. Sep 22 13:07:57 03Michael Lippautz  07org.openembedded.dev * r7dda7044c7 10openembedded.git/ (3 files in 3 dirs): Sep 22 13:07:57 x-load/igep0020.conf: Unbreak x-load for igep0020 machine. Sep 22 13:07:57 * x-load is needed since e2b9225af36b2979b255634f79ceecea482601a7 Sep 22 13:07:57 Signed-off-by: Michael Lippautz Sep 22 13:07:57 Acked-by: Eric BĂ©nard Sep 22 14:30:43 hi stefan Sep 22 14:30:51 hi woglinde Sep 22 14:31:03 hi all Sep 22 14:37:59 damn, i want pdb to have ipython's interface with tab completion Sep 22 14:38:57 pdb? Sep 22 14:39:10 python debugger Sep 22 14:39:17 hm oh Sep 22 14:39:19 never used it Sep 22 14:39:37 i haven't used it much, working on doing so Sep 22 14:39:41 can be quite handy Sep 22 14:39:49 fighting with busybox again? Sep 22 14:40:44 not sure how a python debugger would help with busybox :) Sep 22 14:43:36 args bitbake Sep 22 14:43:37 sorry Sep 22 14:43:45 I am tired Sep 22 14:43:48 somehow Sep 22 14:44:24 hehe Sep 22 14:44:30 looking into memory usage Sep 22 14:47:40 *g* Sep 22 14:47:42 haha Sep 22 14:47:45 yeah 2 gig Sep 22 14:49:39 yeah, its a tad excessive Sep 22 14:50:03 i'm wondering if it would help to store the cache in an sql database, rather than pickling/unpickling the giant dict to/from memory/disk Sep 22 14:50:22 then that 150+mb pile of dicts would stay out of ram -- but i don't know how well itd perform Sep 22 14:50:27 hm dont we already have a sqlite stuff? Sep 22 14:50:30 will have to see if RP has played with that Sep 22 14:50:45 persist_data uses sqlite, for things like the rev incrementing for SRCREV stuff Sep 22 14:50:55 the metadata cache is just a pickled dictionary Sep 22 14:53:24 re kergoth Sep 22 14:53:42 hey other me Sep 22 14:53:46 * kergoth kicks windows box Sep 22 14:54:06 hm mentor needs you to use windows Sep 22 14:55:27 not exactly, heh Sep 22 14:55:56 naw, thats my own box i'm kicking Sep 22 14:56:01 :) Sep 22 14:56:38 landscapers decided to start using a wood chipper and chainsaw to break up a tree about 20 feet from our window at 6:30am this morning Sep 22 14:56:40 * kergoth` shakes fist Sep 22 14:56:59 glad i was getting up anyway Sep 22 14:57:05 ooh Sep 22 14:57:12 apparently ipython *does* have an enhanced pdb shell Sep 22 14:57:16 ipython -pdb will do it Sep 22 14:57:22 * kergoth` tests Sep 22 14:57:40 ah.. hmm Sep 22 14:58:12 that'll only load it on seeing an exception, though. would need to manually force it to run programmatically from the code Sep 22 15:03:28 khem: I don't think this is necessary: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=466148c26e4ce92d708e9b4e4368c4cd6fc87a0b Sep 22 15:03:48 hi denix Sep 22 15:03:58 woglinde: hey Sep 22 15:06:17 kergoth: have you looked at do_unpack()? let me know what kind of help/data you need from me... :) Sep 22 15:06:34 been wrapped up in a task for work Sep 22 15:06:45 the thing is, urldata is initialized from SRC_URI Sep 22 15:06:59 denix simplify do_unpack? Sep 22 15:07:00 so it makes no sense that it would magically get entries from SRC_URI modifications that weren't applied Sep 22 15:07:30 look at bitbake/lib/bb/fetch/__init__.py Sep 22 15:07:38 see the init() and urldata stuff Sep 22 15:08:07 the new unpack uses urldata, so that's where the problem must lie, or its in the metadata's calls to bb.fetch.init() somehow (but doubtful) Sep 22 15:09:40 woglinde: http://thread.gmane.org/gmane.comp.handhelds.openembedded/36703/focus=37192 Sep 22 15:09:52 kergoth: I'll take a look at urldata code Sep 22 15:10:27 denix: as a workaround, you could change it to iterate over SRC_URI directly again, without reverting the rest of the cleanup commit, just change that one behavior back Sep 22 15:10:36 kergoth: basically it fails for me with amend stuff, but for Frans it's slithly different - with SRC_URI_ Sep 22 15:11:00 kergoth: let me try that Sep 22 15:11:07 SRC_URI_ shouldn't leak into SRC_URI unless is in overrides, so this is why it makes no sense that itd end up trying to unpack it in the non-mach case Sep 22 15:11:15 they're two separate variables Sep 22 15:11:26 so i dont see how it could end up in the urldata Sep 22 15:11:28 makes no sense Sep 22 15:12:31 kergoth: maybe my case makes more sense to you... :) Sep 22 15:13:09 perhaps, but it may have its roots in the same behavior Sep 22 15:13:59 basically, original recipe sets SRC_URI="somesources${RC}.tgz" and RC="", but then in amend.inc I set RC to something else and it tries to unpack both with -rc and without... Sep 22 15:14:48 hmm, that one does make more sense Sep 22 15:15:01 the thing with amend.inc is, the amend.inc is loaded during the anonymous python function execs Sep 22 15:15:18 so if an anonymous python function ran before the amend.bbclass one which did a bb.fetch.init() against SRC_URI ... Sep 22 15:15:22 you see the problem Sep 22 15:15:33 best to switch back to SRC_URI direct usage for the time being I think Sep 22 15:15:42 bb.fetch needs a rework anyway Sep 22 15:16:05 is it bb.fetch problem? or is it shared with unpack? Sep 22 15:16:26 as it only fetches the correct file, but tries to unpack both... Sep 22 15:16:32 yes.. and? Sep 22 15:16:50 bb.fetch also maintains the urldata from the SRC_URI Sep 22 15:17:00 the whole concept of which is wrong Sep 22 15:17:12 the do_unpack cleanup made it use that urldata rather than SRC_URI directly Sep 22 15:17:37 so again, revert that portion of the unpack cleanup for now, and in the long run urldata will go away in favor of something less crappy Sep 22 15:17:37 does do_fetch use bb.fetch? Sep 22 15:17:42 ... Sep 22 15:17:49 of course it does, thats all it uses Sep 22 15:17:54 what else would it use? Sep 22 15:18:05 so does unpack, because bb.fetch is what knows where the local paths are for the urls Sep 22 15:18:07 then I wonder why do_fetch works fine Sep 22 15:18:27 don't know, don't give a shit Sep 22 15:18:32 :) Sep 22 15:18:44 fine, I won't bother you any more :) Sep 22 15:18:47 like i said, the whole concept is flawed, its not surprising there's issues with it Sep 22 15:18:53 so go back to not using it Sep 22 15:19:02 i thought it was functional, but clearly it can't be trusted Sep 22 15:19:03 I'll try that, thanks Sep 22 15:19:16 np, thanks for your patience, didn't expect any breakage Sep 22 15:20:10 it seems like urldata was intended to be a sort of a cache of the broken up urls Sep 22 15:20:23 hi kgilmer Sep 22 15:20:26 but come on, breaking up a url isn't exactly system intensive, and if it needed to be cached, it could be done much much cleaner than it is Sep 22 15:20:35 and, it doesn't cache based on the SRC_URI contents Sep 22 15:20:36 hi woglinde Sep 22 15:20:43 so changing it doesn't invalidate the cached information Sep 22 15:20:47 its just a mess Sep 22 15:20:50 kgilmer in sf now? Sep 22 15:21:03 yep Sep 22 15:21:08 leaving this afternoon woglinde Sep 22 15:21:12 also, bb.fetch is tightly bound to the metadata, which is just stupid Sep 22 15:21:24 why can't i construct a fetcher and pass it a url and a destination path, and some options, and have it fetch? Sep 22 15:21:29 it doesn't need to poke at metadata variables itself.. Sep 22 15:21:41 Sep 22 15:21:59 good point about the independent fetcher... Sep 22 15:23:15 the concept of fetching is pretty basic, its a utility module, not tied into bitbake or oe at all, really.. Sep 22 15:23:19 heh Sep 22 15:23:21 anyway.. Sep 22 15:23:45 it should be pretty straightforward to switch back the iteration Sep 22 15:23:52 just look at the cleanup commit to see how it was done previously Sep 22 15:23:58 if you don't get to it i'll take a look in a while Sep 22 15:57:16 03Cliff Brake  07org.openembedded.dev * r80cfc923d7 10openembedded.git/recipes/qgears/ (3 files in 2 dirs): qgears: add recipe (used to test perf) Sep 22 16:26:19 anyone have any thoughts on theis python-pyqt build failure Sep 22 16:26:21 http://pastebin.com/KkzY9s31 Sep 22 16:44:18 03Thomas Zimmermann  07org.openembedded.dev * rd2d7afd76a 10openembedded.git/recipes/python/python-pybluez_0.18.bb: Sep 22 16:44:18 python-pybluez: update to version 0.18 Sep 22 16:44:18 Signed-off-by: Thomas Zimmermann Sep 22 16:55:19 Crofton|work: http://bugs.calibre-ebook.com/ticket/1935 it seems that's an error with qt 4.4.3 Sep 22 16:56:47 thanks Sep 22 16:56:50 good tip :) Sep 22 17:02:37 eFfeM_work, pig Sep 22 17:02:40 er Sep 22 17:02:41 ping Sep 22 17:04:20 heh Sep 22 17:05:39 broonie, a friend of mine thinks he can change the sample rate on the TI beagle codec via i2c Sep 22 17:05:45 does this amke sense to you? Sep 22 17:06:03 He posted to the ALSA list overnight? Sep 22 17:06:21 hmm Sep 22 17:06:23 not sure Sep 22 17:06:28 Al Fayez? Sep 22 17:06:46 Yes. Sep 22 17:06:51 He's a wireless engineer by education, not an embedded guy Sep 22 17:06:52 :) Sep 22 17:07:12 I don't know if the hardware is capable of it but he's completely off base WRT implementation. Sep 22 17:07:16 * Crofton|work notes that he is a wireless guy also Sep 22 17:07:20 heh :) Sep 22 17:07:35 He wants to write directly to the registers of the CODEC, ignoring the whole "driver" thing we've got going. Sep 22 17:07:46 he is "hacking" becuase I suspect he is desrperate to make something work for his professor Sep 22 17:07:55 I was leaving that one to Liam t answer since it's TI stuff. Sep 22 17:08:35 it would be really handy for me also to set the clock to odd values Sep 22 17:08:50 maybe I should see if alsa list is available via gmane Sep 22 17:09:12 He's basically a good guy, just out of his area of expertise Sep 22 17:09:37 speaking of over his had Sep 22 17:09:55 I am going to copy this python recipe and change the src uri and see if it works :) Sep 22 17:10:05 It's in gmane, yes. Sep 22 17:10:28 He also needs to fix his MUA to do the word wrapping thing. Sep 22 17:11:05 dev or user? Sep 22 17:11:55 devel Sep 22 17:13:03 libsamplerate eats his processor :) Sep 22 17:13:49 * Crofton|work hearts gmane Sep 22 17:14:09 jesus, he posted from aol webmail Sep 22 17:14:33 Quite. Sep 22 17:14:46 (this was also part of why I didn't rush to answer) Sep 22 17:15:29 I have the thunderbird plugin that lets me know these things for the same reason Sep 22 17:15:53 I don't have a plugin I just notice the stuff rendering very poorly in mutt/vim. Sep 22 17:16:04 well, I'll watch the thread and if he gets any good suggestions I can always walk over and beat him Sep 22 17:20:55 fark Sep 22 17:21:05 pyqt-4.4.3 is ancient Sep 22 17:21:18 looks like current version is 4.7.7 Sep 22 17:23:26 Crofton: see http://www.pyside.org/ this is written by nokia because of the licensing issues with pyqt Sep 22 17:24:28 what is the licensing issue? Sep 22 17:24:57 pyqt : Unlike Qt, PyQt v4 is not available under the LGPL. You can purchase the commercial version of PyQt here. Sep 22 17:25:02 http://www.riverbankcomputing.co.uk/software/pyqt/intro Sep 22 17:25:35 cf 3rd faq here : http://www.pyside.org/faq/ Sep 22 17:25:41 so gpl only? Sep 22 17:26:37 gpl v2 & v3 Sep 22 17:27:17 http://www.riverbankcomputing.co.uk/software/pyqt/license Sep 22 17:27:56 ok Sep 22 17:28:56 that's not a major problem for many usage, only for closed source applications developers Sep 22 17:29:05 yeah Sep 22 17:29:31 i am not concerned about that, just that I be able to build gnuradio :) Sep 22 17:29:55 trying a hack to build 4.4.4 with tarball from another site Sep 22 17:39:19 Hi Sep 22 17:39:43 How can I prevent OE from stripping my binaries in a specific package ? Sep 22 17:43:03 julianpid: PACKAGE_STRIP = "no" Sep 22 17:44:18 thx Sep 22 17:44:19 but why? Sep 22 17:44:25 You can debug by installing the -dbg package Sep 22 17:44:44 I say since that's the common reason for not wanting to strip :) Sep 22 17:44:54 I know Sep 22 17:45:07 ok Sep 22 17:45:43 I'm building a package containings linux headers out of a linux build tree Sep 22 17:46:25 and it contains some very simple binaries Sep 22 17:46:50 I don't want to create a kernel-blah-headers-dbg package Sep 22 17:47:03 that would be extremely stupid Sep 22 17:48:10 and useless Sep 22 17:56:03 any opinion on : http://patchwork.openembedded.org/patch/3013/ ? Sep 22 17:56:35 I think actual order of things there can be wrong in many case Sep 22 17:57:27 that sounds questionable to me Sep 22 17:57:55 hmm Sep 22 17:58:14 example here : http://patchwork.openembedded.org/patch/3012/ I need to chown the directories else the daemon can't write it's pid & log file Sep 22 17:58:43 actually after opkg install update-rc tries ot launch the daemon which fails because it can't write it's pid file Sep 22 17:58:51 as the chown is after update-rc Sep 22 17:58:57 ah, yes, makes sense Sep 22 17:59:07 that seems reasonable to me, then Sep 22 18:00:29 anyone have an opinion on http://github.com/kergoth/bitbake/commit/867153dd26fdcf31b28355b743a1ac0cbc57498d ? Sep 22 18:04:41 ouch still have to walk a lot through the code to understand this kind of stuff :-) Sep 22 18:06:37 re Sep 22 18:18:31 denix: yes that commit is needed otherwise this package is building for my machine efikamx too Sep 22 18:21:58 khem: parentheses are used for grouping, to refer back to it later. is it used that way? dropping parentheses in COMPATIBLE_MACHINE used to work before, afaik Sep 22 18:22:56 it's just a regex.. Sep 22 18:23:52 kergoth: right. so shouldn't matter if it's "machine" or "(machine)" Sep 22 18:23:58 denix: it works I just though () was better Sep 22 18:24:17 for readability for me Sep 22 18:24:43 khem: just wanted to confirm I'm not missing something... :) Sep 22 18:25:26 ok Sep 22 18:25:52 kergoth: with pstage and rm_work if my build breaks and I relaunch it Sep 22 18:26:01 the rm_work and staging is done again Sep 22 18:26:09 I think its not needed Sep 22 18:27:32 kergoth: and it runs do_rm_work and do_rm_work_all Sep 22 18:27:48 whats different between these two Sep 22 18:28:04 denix: right Sep 22 18:28:21 _all is an empty task that ensures rm_work is run not just on the current recipe, but all its deps too Sep 22 18:28:25 same pattern as used in fetchall, etc Sep 22 18:29:43 03Koen Kooi  07org.openembedded.dev * r816a1bfcfe 10openembedded.git/recipes/gstreamer/gst-plugin-gles_git.bb: gst-plugin-gles: bump SRCREV Sep 22 18:29:48 03Koen Kooi  07org.openembedded.dev * r92240950cd 10openembedded.git/recipes/enblend/enblend-enfuse_4.0.bb: enblend-efuse: add 4.0 Sep 22 18:29:48 03Koen Kooi  07org.openembedded.dev * r7bb9447c70 10openembedded.git/recipes/enblend/ (plotutils/01_configure_ac.patch plotutils_2.6.bb): plotutils: add 2.6 Sep 22 18:29:52 03Koen Kooi  07org.openembedded.dev * r674e40568a 10openembedded.git/recipes/gstreamer/gstreamer_0.10.30.bb: gstreamer: add 0.10.30 Sep 22 18:29:53 03Koen Kooi  07org.openembedded.dev * r739fd513b2 10openembedded.git/recipes/gstreamer/gst-plugins-base_0.10.30.bb: gst-plugins-base: add 0.10.30 Sep 22 18:30:06 kergoth_: what are different scheduler policies available in bitbake for tasks Sep 22 18:30:22 speed and completion, and of course the default, which is a useless order Sep 22 18:30:32 completion works to complete a recipe before moving on to the next Sep 22 18:30:37 speed orders based on # of dependencies for the task Sep 22 18:30:57 so speed might defer rm_work for a given recipe Sep 22 18:31:24 yep, so you'd use more disk space during the build Sep 22 18:31:26 same end result Sep 22 18:31:29 just intermediate difference Sep 22 18:31:32 kergoth: ok Sep 22 18:31:32 completion is slower Sep 22 18:32:17 kergoth_: for already built recipes its doing do_setscene->do_package_stage_all->do_build->do_rm_work->do_rm_work_all Sep 22 18:34:48 kergoth_: when I relaunch the build thats what I see I thought it should not do anything second time Sep 22 18:35:02 kergoth_: NOTE: Removing stamps: /scratch/oe/stamps/armv7a-oe-linux-gnueabi/udns-0.0.9-r0. Sep 22 18:35:16 second time around I wonder why bb is doing that Sep 22 18:35:22 it won't re-run setscne and package_stage the second time around. not sure about rm_work Sep 22 18:35:30 its possible there's an issue with the task ordering Sep 22 18:35:41 where I can see that it completed all tasks for this recipe in last invocation Sep 22 18:35:49 is rm_work nostamp? Sep 22 18:36:04 kergoth_: what do u mean Sep 22 18:36:44 nevermind, likely doesn't apply here. pstage will refuse to use an existing ipk if the task graph differs from previous Sep 22 18:37:02 so if you have a task that might or might not run before/after package_stage, what gets captured will vary Sep 22 18:37:13 those things usually need to be pushed either before or after Sep 22 18:37:15 so it stops varying Sep 22 18:39:33 it removed stamps for almost all ipks in second run Sep 22 18:39:55 and then restaged them Sep 22 18:40:03 not very effective Sep 22 18:40:31 never seen that Sep 22 18:40:35 does it only do that with rm_work? Sep 22 18:40:51 I think so I have not tried without rm_work Sep 22 18:43:12 do_setscene -> do_package_stage_all -> do_build -> do_rm_work -> do_rm_work_all Sep 22 18:43:15 thats the order Sep 22 18:43:28 or task executed for a recipe second time around Sep 22 18:43:55 yeah, that shouldn't happen, afaik. setscene isn't nostamp Sep 22 18:44:44 before all that it decides to remove the ipk from staging at very beginning of run Sep 22 18:44:59 do_setscene could be asking for it ? Sep 22 18:45:36 do_setscene[selfstamp] = "1" Sep 22 18:45:48 ah, right, i forgot about that.. Sep 22 18:45:53 crazy voodoo Sep 22 18:47:18 base_scenefunction checks for stamp Sep 22 18:47:38 if it does not exist then it calls do_clean Sep 22 18:48:13 actually it checks for .needclean Sep 22 18:50:55 kergoth: there is a handler to update stamps in rm_work Sep 22 18:51:00 when will it be called Sep 22 19:28:32 hi Sep 22 19:29:02 someone know who broke patch task by appending to patches/series instead of rewriting it? Sep 22 19:29:35 hey hrw Sep 22 19:29:44 * florian is not guilty Sep 22 19:30:25 old way of checking which patches apply to new version (bitbake -b recipe.bb -cpatch) does not work anymore Sep 22 19:31:14 btw - if someone uses Ubuntu 10.10 then ARM cross compiler is in archive - ready to use Sep 22 19:33:36 most likely it was me, when I cleaned up and reorganized unpack and patch Sep 22 19:33:40 should be easy enough to fix Sep 22 19:34:04 though i don't recall any behavior change like that offhand Sep 22 19:34:57 alternatively, it could be the commit that switched to using symlinks for patches Sep 22 19:35:47 yeah, there it is Sep 22 19:36:17 hmm Sep 22 19:37:11 okay, not sure which did it, try some reversion and see Sep 22 19:37:21 hrw: are you using quilt-native ? Sep 22 19:40:48 khem: got it built as part of build Sep 22 19:41:14 hrw: bitbake -b recipe.bb -cpatch works for me Sep 22 19:41:44 khem: add unapplying patch in a middle and call -cpatch twice Sep 22 19:42:43 hrw: you mean unapply by hand Sep 22 19:43:09 khem: edit recipe, add nonworking patch to src_uri. call -cpatch twice Sep 22 19:43:38 second run will get "all good" + nonworking + "all good" in series Sep 22 19:43:46 hmmm Sep 22 19:43:53 remove nonworking patch from src_uri, call -cpatch Sep 22 19:44:04 you will get "all good" + nonworking + "all good" + "all good" in series Sep 22 19:44:18 so patch task will fail Sep 22 19:45:42 anyway need to go - daugher still not sleep so time to read some fG$#@%^@GSGS failytales Sep 22 20:02:00 03Koen Kooi  07org.openembedded.dev * ra6aa9eae24 10openembedded.git/recipes/orc/orc_0.4.9.bb: orc: update to 0.4.9 Sep 22 20:09:52 kergoth_: I think we should remove the series file at the beginning of do_patch Sep 22 20:09:56 what do u think Sep 22 20:11:42 pretty sure Clean() updates the internal knowledge of the patch stack in the class, we should be able to see if the patch is already there in Import and avoid re-importing it Sep 22 20:11:46 at least, i think that was the concept Sep 22 20:11:56 its been a while since i worked on that stuff Sep 22 20:13:12 is Clean called implicitly on unfinished do_patch Sep 22 20:13:23 second time around Sep 22 20:15:34 kergoth: hmm I see Sep 22 20:15:59 code around line 107 in patch.bbclass Sep 22 20:19:53 Tartarus: concerning gdb-cross-sdk, I've hacked something which is using static libncurses libtinfo libz and libexpat (even if the problem was only with libncurses & libtinfo) : is this ok or should I limit to only libncurses & libtinfo ? Sep 22 20:20:50 No, that sounds good Sep 22 20:20:55 libexpat is a pain sometimes :) Sep 22 20:21:17 it's not easy to hack gdb's config & makefiles as most of them are generated by do_compile and not by do_build Sep 22 20:22:18 Same way we hacked gcc should work Sep 22 20:22:31 since gdb/gcc/binutils have the same horrible set of not fun "do our configure in do compile" stuff Sep 22 20:23:11 kergoth_: if some recipe defines patchdir like mplayer_svn then Clean will be called which will unapply all patches applied so far Sep 22 20:23:19 seem wrong to me Sep 22 20:23:21 no Sep 22 20:23:41 patchset.Clean() will be called isnt it Sep 22 20:23:46 Clean runs within the patchdir, a new patch series, it unapplies the patches *in the patchdir* Sep 22 20:23:48 and only the first time Sep 22 20:24:00 it doesn't unapply the patches with a patchdir of ${S} Sep 22 20:24:05 which is the default Sep 22 20:24:10 patchdir is always set, just not always overridden Sep 22 20:24:11 Tartarus: I didn't manage to do it the way you did for gcc, I added a do_configure_append and I'm doing the change using sed here Sep 22 20:24:33 patchdir is the root of a new quilt patch setup, a new patches dir, new series Sep 22 20:24:41 kergoth_: right but classes is empty when we enter the loop first time Sep 22 20:24:50 as it should be Sep 22 20:24:57 so first time it will go into that if and run clean Sep 22 20:24:59 it runs clean at the first patch for each patchdir Sep 22 20:25:04 yes, as it should Sep 22 20:25:07 ok Sep 22 20:25:13 its supposed to unapply all patches forcibly before applying the new series Sep 22 20:25:20 otherwise how would it applied a modified patch? Sep 22 20:25:23 that means in patchset.Clean() I can nuke series Sep 22 20:25:24 it has to unapply the old series first Sep 22 20:25:41 may be not Sep 22 20:25:48 ? Sep 22 20:26:07 Tartarus: I see, in gdb the libs are clearly named in Makefile.tpm and Makefil.in, that's not the case in gdb as using curses or others depends on parameters passed to configure Sep 22 20:26:13 unapplying the old series is the only way to ensure you're applying the current patch series against a pristine tree Sep 22 20:26:15 kergoth_: in Import we create symlinks and append to series file Sep 22 20:26:21 yep Sep 22 20:26:28 it should be safe to wipe series at clean time, yeah Sep 22 20:26:30 i *think* Sep 22 20:26:40 so first pop all patches Sep 22 20:26:46 then wipe series Sep 22 20:26:46 and then delete series Sep 22 20:26:48 then come the imports Sep 22 20:26:49 yeah Sep 22 20:26:56 ok Sep 22 20:27:01 in theory Sep 22 20:27:09 now are there separate series files for each patchdir Sep 22 20:27:20 yes, but you don't have to worry about it Sep 22 20:27:24 its a new instance of the class in each one Sep 22 20:27:41 so a new path, new series path, the class doesn't need to know, other than being passed in the root its operating against Sep 22 20:28:09 hmm Sep 22 20:28:28 03Koen Kooi  07org.openembedded.dev * r1f5fb1e223 10openembedded.git/recipes/mozilla/ (2 files in 2 dirs): firefox 3.6.8: fix build from ARMv4T, patch stolen from debian Sep 22 20:28:32 kergoth_: ok so say I have $WORKDIR/ and WORKDIR/foo as my patchdirs Sep 22 20:28:36 for a recipe Sep 22 20:28:55 so there will be $WORKDIR/patches/series and WORKDIR/foo/patches/series Sep 22 20:28:58 yep Sep 22 20:29:14 two instances of QuiltTree, with $WORKDIR as dir for the first, nad $WORKDIR/foo for the dir for the second Sep 22 20:29:23 i c Sep 22 20:29:37 ok then I think removing series file in Clean would work Sep 22 20:29:40 it was the only i could think that would make sense Sep 22 20:29:49 for the patchdir implementation, i mean Sep 22 20:30:35 kergoth_: yeah but it will be mess to play with a tree which has multiple patchdirs Sep 22 20:30:46 not really Sep 22 20:30:52 kergoth_: one could step on others toes Sep 22 20:30:56 if they modify common files Sep 22 20:31:01 oh, i see what you mean, yeah, that is a problem Sep 22 20:31:09 ideally quilt would support the notion directly Sep 22 20:31:14 and we could just put that in the series file Sep 22 20:31:20 as long as you dont have to generate a new patch for that recipe bb takes care of it Sep 22 20:31:20 not much we can do about it though Sep 22 20:31:22 you are happy Sep 22 20:31:26 and very few recipes use the thing anyway Sep 22 20:31:30 * kergoth_ nods Sep 22 20:31:34 only 1 I found Sep 22 20:31:37 mplayer Sep 22 20:32:00 another alternative would be to modify the patch file to adjust the paths into the patchdir, which would avoid the issue Sep 22 20:32:04 but is less trivial to implement Sep 22 20:32:13 would need to parse the diff format, at least part of it Sep 22 20:32:15 agree Sep 22 20:32:29 let me test the series removal think Sep 22 20:32:31 thing Sep 22 20:32:33 k Sep 22 20:33:22 do we prefer unlink to delete a file or something else Sep 22 20:34:33 ah oe.path.remove Sep 22 21:12:09 we have two versions of libnl Sep 22 21:12:24 are there ABI differences between two Sep 22 21:12:28 they seem to be conflicting Sep 22 21:12:40 khem yes Sep 22 21:12:45 some packages depend on libnl and some on libnl2 Sep 22 21:13:10 woglinde: hmmm Sep 22 21:13:18 we cant select one or other Sep 22 21:13:33 woglinde: do u have some more info on the differences Sep 22 21:14:34 no Sep 22 21:14:44 sorry Sep 22 21:14:56 no other distros ship libnl2 Sep 22 21:15:06 who needs libnl2 and why Sep 22 21:39:46 Is there some simple way to package my kernel up into a named package rather than 'kernel-image' ? Tried adding a PACKAGES + FILES_myname="/boot/uImage" to my recipe bu it's only got module related stuff in it.. Seems like I've got an ordering problem or something. Sep 22 21:40:05 my VIRT is up to 220M now, was about 150 when I started watching it Sep 22 21:40:09 doh Sep 22 21:40:31 loadammo, what do you mean? Sep 22 21:40:39 We intentionally do kernel-image rather than kernel-${MACHINE} Sep 22 21:41:06 I've got two kernels for the same machine, one with inintramfs, one without -- when you build each one it clobbers the packages for the other Sep 22 21:41:26 So then you want to take a look at how linux-kexecboot and linux-preboot recipes work Sep 22 21:41:36 That's how OE supports initramfs using kernels Sep 22 21:42:12 Our kernel doesn't support kexec, and the preboot stuff doesn't fit our model. I'll just patch kernel.bbclass I guess. Sep 22 21:42:18 thanks Sep 22 21:49:19 Right Sep 22 21:49:26 What I'm saying is that those are recipes to look at and modify Sep 22 21:49:48 Since they implement the template of kernel + initramfs Sep 22 21:50:33 If you've gone and modified things such that your kernel + initramfs are built together with one recipe file rather than two, yes, kernel.bbclass needs some hacking Sep 22 21:50:39 Or it did before when I did such a thing Sep 22 21:50:56 (since your kernel recipe needs a little hacking too, unless you aren't having any modules in the initramfs) Sep 22 22:41:25 03Michael Smith  07master * r6aadf6cfe9 10openembedded.git/recipes/gtk+/ (gtk+-2.14.2/no-demos.patch gtk+_2.14.2.bb): Sep 22 22:41:25 gtk+ 2.14.2: add BBCLASSEXTEND = "native" Sep 22 22:41:25 Get this ancient recipe working again. Sep 22 22:41:25 Signed-off-by: Michael Smith Sep 22 22:41:36 03Michael Smith  07master * rd4e8b7241d 10openembedded.git/recipes/musicbrainz/ (2 files in 2 dirs): Sep 22 22:41:36 libmusicbrainz: fix build when prefix = "" Sep 22 22:41:36 Signed-off-by: Michael Smith Sep 22 23:05:43 hi, do you know a tutorial to use distcc to compile oe? Sep 22 23:09:58 distcc no, icecc yes Sep 22 23:11:25 does it work better icecc Tartarus ? Sep 22 23:11:38 same concept but different implementation Sep 22 23:12:29 i found the page on the wiki, thanks Tartarus ;) **** ENDING LOGGING AT Thu Sep 23 02:59:58 2010