**** BEGIN LOGGING AT Wed Jun 15 02:59:57 2011 Jun 15 05:49:36 03Steffen Sledz  07org.openembedded.dev * r0cd580ad80 10openembedded.git/recipes/linux/linux-2.6.24/hipox/ox810-pci-read-config-fix.patch: Jun 15 05:49:36 linux-2.6.24: fix diff pathes in hipox machine specific patch file Jun 15 05:49:36 Signed-off-by: Steffen Sledz Jun 15 05:57:05 Is there a command I can use to fetch everything that will be needed for my build? Jun 15 05:58:00 I would like to pull the latest from .dev, and then fetch everything my next build is going to require, then build offline. Jun 15 09:15:43 hej, anyone could do me a favour and compile a glibc links_2.x (without -x11) for armv7a and upload it somewhere? - don't have a toolchain with me... Jun 15 09:16:19 morning all Jun 15 09:17:17 gm Jun 15 09:30:45 pb_: daily ping... Jun 15 09:30:49 hi ant Jun 15 09:31:21 again about packaging: Jun 15 09:32:11 how are the RDEPENDS related to $PN? I thought those are referring to the packaged files, isn't? Jun 15 09:33:09 i.e. I do PACKAGES = "${PN} ${PN}-dev" Jun 15 09:33:14 correct Jun 15 09:33:36 $PN is klibc Jun 15 09:33:45 now I want libklibc Jun 15 09:33:59 FILES_libklibc ? Jun 15 09:34:05 03Richard Purdie  07master * r9bff182a4b 10bitbake.git/lib/bb/codeparser.py: Jun 15 09:34:05 codeparser: When loading the cache, ignore ValueError Jun 15 09:34:05 Signed-off-by: Richard Purdie Jun 15 09:34:20 is libklibc in PACKAGES? Jun 15 09:34:31 or do you mean that "libklibc" is what you get after package renaming? Jun 15 09:35:08 I aim to have libklibc and libklibc-dev packaged Jun 15 09:35:19 debian renaming seems doing anythingù Jun 15 09:35:30 http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/klibc/klibc_1.5.23.bb?h=org.openembedded.dev Jun 15 09:36:19 I extended PACKAGES += "libklibc_${PV} Jun 15 09:37:04 then all RDEPENDS are broken Jun 15 09:37:33 so, I tried to adjust them in the same way, s/${PN}/libklibc-${PN}/ Jun 15 09:37:42 err .. Jun 15 09:37:46 so, I tried to adjust them in the same way, s/${PN}/libklibc-${PV}/ Jun 15 09:38:46 I understand what is listed in RDEPENDS has to be explicitely packaged Jun 15 09:42:38 (I'm looking at the linphone patch right now) Jun 15 09:43:05 I'm not quite sure I understand what you're saying about RDEPENDS and explicit packaging. Jun 15 09:43:46 I mean that I have to package libklibc if then I RDEPENDS on it, while anything could DEPEND on klibc Jun 15 09:44:06 Looking at the recipe, rather than using all that RDEPENDS craziness, I think you would be better to just set a distinct soname and let the regular mechanisms handle it. Jun 15 09:44:33 klibc emits a bogus soname Jun 15 09:45:31 i.e. klibc-eYJuVoHAdWma5s-zMiYBcWeYQjY.so Jun 15 09:45:39 that should be ok Jun 15 09:45:45 does it change every time? Jun 15 09:45:56 yes, seems random Jun 15 09:46:11 yeah, then you should be all set. that will do instead of worrying about putting "= ${PV}" in all your rdepends Jun 15 09:48:57 I'm unsure we get twice the same hash even with constant (= ${PV}-${PR})" Jun 15 09:49:08 I don't think so Jun 15 09:49:29 so, why was it written like it is once ago? Jun 15 09:53:13 pb_: so, after expansion it should just be RDEPENDS_klibc-utils-sh = "libklibc" Jun 15 09:53:27 doh, seems I have two ssh processes each consuming 100% cpu Jun 15 09:53:33 eek Jun 15 09:53:36 ant_work: the auto-depends code should take care of it Jun 15 09:53:46 you shouldn't need to set any specific RDEPENDS for yourself Jun 15 09:53:57 each utils is packaged separately Jun 15 09:54:04 that doesn't matter Jun 15 09:54:12 package.bbclass knows about that, it will sort it out Jun 15 09:54:27 mumble mumble Jun 15 09:54:46 that's a bit a gray-zone for me :p Jun 15 09:57:09 pb_: this recipe is a pandora-box Jun 15 09:57:35 heh Jun 15 09:57:43 ..and I'm the dumb one insisting for opening it.. Jun 15 09:58:18 now, I'll try to simplify Jun 15 09:58:36 yeah, I don't think it needs to be very complicated Jun 15 09:58:47 and btw PACKAGES = "${PN} ${PN}-dev" nukes the debian renaming, isn't? Jun 15 09:58:54 no Jun 15 09:59:06 what If I don't set it? Jun 15 09:59:21 probably won't make much difference. the default PACKAGES (from bitbake.conf) is fairly similar. Jun 15 09:59:50 there was smthg about .so in normal package Jun 15 09:59:57 yes, a QA Jun 15 10:00:01 that's a question of FILES, not PACKAGES Jun 15 10:00:09 oh, sure Jun 15 10:00:35 but in this case I suspect the qa check is in error. Jun 15 10:00:47 should perhaps try to make recipe_sanity a bit smarter, or just disable that check for klibc Jun 15 10:01:08 I see debian ships the .so in libklibc and libklibc-dev Jun 15 10:01:18 maybe one should be a symlink? Jun 15 10:01:45 really sorry to bother you but this is really non-standard recipe :/ Jun 15 10:02:41 it does sound wrong to have the same file in two packages Jun 15 10:03:25 ah, debian puts in two places Jun 15 10:03:43 /usr/lib/klibc/lib/klibc-eYJuVoHAdWma5s-zMiYBcWeYQjY.so (dev) Jun 15 10:04:07 and /lib/klibc-eYJuVoHAdWma5s-zMiYBcWeYQjY.so Jun 15 10:04:15 the normal libklibc Jun 15 10:10:30 03Scott Garman  07master * rdbf5f42b06 10bitbake.git/ (10 files in 6 dirs): Jun 15 10:10:30 make exception handling syntax consistent Jun 15 10:10:30 Update exception handling syntax to use the modern style: Jun 15 10:10:30 except ExcType as localvar Jun 15 10:10:30 Signed-off-by: Scott Garman Jun 15 10:10:30 Signed-off-by: Richard Purdie Jun 15 10:10:36 that seems a bit weird, but I guess it is harmless enough Jun 15 10:16:11 ok, that RDEPENDS are anyway bogus/wrong when building klibc-static-utils Jun 15 10:16:24 yeah, just get rid of them Jun 15 10:16:29 doh, no space left on device Jun 15 10:16:33 * pb_ deletes some files Jun 15 10:17:33 pb_: which filesystem do you use for building? Jun 15 10:17:42 ext3 Jun 15 10:17:51 we used to use xfs but it sucked Jun 15 10:17:59 oh, ext4 actuallyu Jun 15 10:18:02 s/u$// Jun 15 10:18:14 well, I was just asking about xfs Jun 15 10:18:28 I use it on the servers and am very happy Jun 15 10:18:40 Gentoo builds are very snappy so I thought.. Jun 15 10:18:41 in particular, xfs sucked really badly when creating and deleting lots of small files. Jun 15 10:19:05 did you tune it? Jun 15 10:19:21 buffers and so on Jun 15 10:19:27 no, not really Jun 15 10:20:03 I kind of assumed that the default configuration would be a sensible one Jun 15 10:20:42 fwiw, we found that a simple "tar xf large-file.tar" kind of thing was four times as slow on xfs compared to ext4 Jun 15 10:21:08 and "rm -rf" on the resulting tree was about 20 times slower Jun 15 10:21:49 I can't say, here with a cheap LSI SAS 15k RAID1 Gentoo flies Jun 15 10:22:41 we'll ask some yocto folk, they'll find time to bench the builds ;) Jun 15 10:22:45 our main problem was that if we had one user doing a big tar operation then the whole filesystem became unusable for anything else Jun 15 10:22:57 Hello all Jun 15 10:23:08 if you're on an essentially single user machine then it probably isn't going to be so noticeable. Jun 15 10:23:59 hi celston Jun 15 10:25:18 Can anyone comment on the validity of this suggestion for using busybox mdev to replace udev: http://www.sleepyrobot.com/?p=83 ? Jun 15 10:25:43 Having problems compiling udev because our kernel doesn't have CLOEXEC. Jun 15 10:26:06 depends what you want to do with it. mdev is fine for simple things, and you might find that you don't even need that in some cases. Jun 15 10:26:31 I did wonder about all the dependencies on specifically udev. Wouldn't it make more sense to have a virtual/devicemanager (or similar) ? Jun 15 10:26:43 What is it that actually depends on udev? Jun 15 10:26:56 I suspect most of the packages that do, do so because they genuinely are trying to do things that only work with udev. Jun 15 10:27:00 task-core-boot, hence core-image-minimal Jun 15 10:27:04 for example, they rely on being able to install udev-specific rules files Jun 15 10:28:00 oh, task-core-boot. yeah, dunno, I think that whole recipe is a bit full of suck. Jun 15 10:28:05 :) Jun 15 10:28:28 How would one override task-core-boot in a distro layer? Jun 15 10:28:32 celston: try just enabling devtmpfs if you don't have special needs Jun 15 10:28:54 celston: just provide your own equivalent .bb file Jun 15 10:30:07 ant_work: Where's the switch for devtmpfs? Jun 15 10:30:20 kernel Jun 15 10:30:46 2.6.18 kernel :) Jun 15 10:31:19 pb_: may I ask you one more Q ? Would you still let klibc support 2.6.2x kernels with those extra-patches? Jun 15 10:31:32 or should I remove those like udev is doing? Jun 15 10:32:05 up to you really. if it doesn't hurt anything to keep them then I would be inclined to leave them in. Jun 15 10:32:10 upstream answer is clear. drop Jun 15 10:32:27 ant_work: noooo :( Jun 15 10:32:48 I spent last night refactoring the OE patches ;) Jun 15 10:33:03 maybe a couple will be acceted upstream Jun 15 10:33:32 (btw the maintainer asked how to clone a specific portion of the git tree, impossible atm, isn't?) Jun 15 10:36:10 yeah, I don't think you can do that. git doesn't really work in a way that would allow you to sensibly clone only part of the tree. Jun 15 10:38:37 ..so I added some history in the patch headers and sent him the tarball Jun 15 10:43:52 food now, brb Jun 15 11:29:09 I've battered task-core-boot a bit and now I have an image with busybox-mdev instead of udev :) Cheers chaps. Jun 15 11:29:22 very good Jun 15 11:29:42 Any idea where I would put a gcc flag which needs to go to *EVERY* compile? Jun 15 11:29:57 toolchain is either endianness. Jun 15 11:30:05 and I want to select the non-default one :) Jun 15 11:30:07 Sticking it on the end of ${CC} seems to be traditional. Jun 15 11:30:12 That's what we do with -march= and suchlike. Jun 15 11:30:25 CC_append = "-EL" ? Jun 15 11:30:46 yeah, something like that. Need a space though, or you might just be able to use "CC += ..." Jun 15 11:31:23 What is the advantage of bb having two append syntax? Is one historical, or are there use cases for both? Jun 15 11:31:59 Mostly historical. The _append one is almost always the wrong thing, but it is also the only convenient way of doing a conditional append. Jun 15 11:32:40 They are processed slightly differently so there are also a few cases where you need to use _append rather than +=/.=. But they are moderately rare and I don't think this is one of them. Jun 15 11:33:02 Cool, I'll default my brain to += then. Jun 15 11:39:20 doh, tinylogin was removed from busybox.net Jun 15 11:39:32 finally died? Jun 15 11:39:34 * pb_ stabs the busybox h4x0rs Jun 15 11:39:47 yeah, it seems. http://tinylogin.busybox.net/downloads/ is 404 now Jun 15 11:39:50 Yes, noticed that the other day. It's been rolled into busybox pkg I think. Jun 15 11:39:54 iirc tinylogin got merged into busybox few years ago Jun 15 11:40:26 yeah, it did, but that requires having busybox be setuid Jun 15 11:40:54 we had a long discussion about this on the mailing list at the time. Jun 15 11:41:02 I know Jun 15 11:41:09 I wonder how big a busybox compiled with *just* tinylogin would be? Jun 15 11:41:10 started one of them even Jun 15 11:41:27 pb_: busybox has setuid separation inside for quite long time too Jun 15 11:41:32 we just do not use it Jun 15 12:04:19 celston: good question, though that doesn't really solve the setuid problem Jun 15 12:08:28 pb_: doesn't tinylogin need to be suid currently? Jun 15 12:08:34 yes,it does Jun 15 12:08:59 the point is that, if you want to audit your setuid binaries, it is much easier to figure out what is going on with tinylogin than with busybox. Jun 15 12:09:29 right, but if a busybox with only tinylogin features enabled could be built separately as tinylogin wouldn't that satisfy the situation? Jun 15 12:09:31 since, even though busybox does drop setuid privs for applets that don't need them, any part of busybox can call into any other function in the binary. Jun 15 12:10:06 and, since the busybox code changes quite frequently, it is hard to be absolutely certain of which pieces of code might be getting executed in setuid context. Jun 15 12:10:35 hmm, well that's a good point Jun 15 12:11:05 the nice thing about tinylogin is that it's small, self-contained and virtually never changes. Jun 15 12:11:23 so, if you can convince yourself once that it's secure, you don't have to worry about it again. Jun 15 12:11:43 did anyone oppose merging tinylogin upstream? I wonder if there was a big discussion there as well Jun 15 12:12:02 dunno Jun 15 12:12:14 I don't think it's a bad thing to have it in busybox as well. Jun 15 12:12:36 and, in fact, on most of the platforms I am working on right now, virtually everything runs as root anyway so the setuid thing is basically a non-issue. Jun 15 12:16:35 :/ Jun 15 12:47:23 03Steffen Sledz  07org.openembedded.dev * rd62c4492d1 10openembedded.git/recipes/linux/linux-2.6.24/hipox/ox810-pci-abort-handler.patch: Jun 15 12:47:23 linux-2.6.24: fix a buggy patch file for hipox machine Jun 15 12:47:23 Signed-off-by: Steffen Sledz Jun 15 13:08:07 ahem..what does it mean if showkeys gives 3 codes for a single key? Jun 15 13:09:08 Hello ... Jun 15 13:09:20 I am working at integrating our SDK into OE-Core Jun 15 13:09:40 first thing I found is that it lacks cmake sdk recipe Jun 15 13:10:31 should I use BBEXTENDCLASS or write a new recipe? Jun 15 13:12:14 otavio: I think BBCLASSEXTEND is preferred unless it's unavoidable... is this something that's in oe-dev? Jun 15 13:12:53 bluelightning: it is but bad done IMO Jun 15 13:13:00 ok Jun 15 13:20:02 humm, does make any sense to have cmake for target? Jun 15 13:21:04 presumably as much sense as any other development package, right? Jun 15 13:21:30 we are capable of building autotools for the target, so I don't see why not Jun 15 13:22:32 yeah, exactly. a bit of a fringe interest but we have always supported that in the past. Jun 15 13:25:18 it seems cmake will then need a lot of changes to support all this Jun 15 13:25:18 how I can do to a patch to be applied only for non-native? Jun 15 13:59:53 not sure if this is an oe bug or a libsndfile one, but libsndfile built within the minimal distro doesn't work on either arm or x86 systems, it dies with an assertion - sf_count_t == 8, this is related to off_t being 4 bytes on 32 bit and the configure script for libsnd file doing some checks for arch and assigning sf_count_t accordingly - i think it means to assign loff_t ono 32bit systems but i think it also has something to Jun 15 13:59:53 do with lfs possibly being unavailable in the minimal image? Jun 15 14:16:04 Hi everyone Jun 15 14:16:40 I need to add CPPFLAGS="-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS" before the "configure" command when compiling sqlite 3 in yocto Jun 15 14:16:52 where should I place them in the recipe? Jun 15 14:19:41 EXTRA_CFLAGS += "-Dblahblah" Jun 15 14:19:55 also, #yocto or #poky are probably better bets :) Jun 15 14:20:44 kergoth : ok Thank you!! Jun 15 14:21:00 np Jun 15 14:21:15 doh, mesa compile fail Jun 15 14:21:17 * pb_ files a bug Jun 15 14:21:35 btw..these are extra CPPflags...is it the same? Must I always use EXTRA_CFLAGS? Jun 15 14:27:38 ops...sorry I confused C pre processor flags with c++ flags.... my mistake Jun 15 14:28:16 I don't think you did. CPPFLAGS is preprocessor, CXXFLAGS is C++. Jun 15 14:28:23 -D would usually belong in CPPFLAGS Jun 15 14:28:42 yes---I was thinking about c++ flags...but CPP is c pre processor :-) Jun 15 14:29:13 erm, yes, you should use the correct flags var, clearly i haven't had my coffee Jun 15 14:29:17 * kergoth shakes head Jun 15 14:30:28 thinking of sqlite3, it might be worth turning on USE_PREAD64 in there as well. for some slightly odd reason sqlite doesn't seem to use that by default. Jun 15 14:44:46 khem: ping Jun 15 14:49:18 So...I've added EXTRA_CPPFLAGS = "-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_ICU" in sqlite3.inc Jun 15 14:49:32 but it doesn't seem to use that defines Jun 15 14:49:50 I've rebuild it forcing the clean and the compilation Jun 15 14:49:54 mrAlmond: CPPFLAGS += Jun 15 14:50:02 doh! Jun 15 14:50:06 don't use =, make sure you append to what already exists, and i was remembering wrong with the extra Jun 15 14:50:36 thank you for the suggestion...I was aware about it but I totally forgot that advise! Jun 15 14:50:59 for reference, see conf/bitbake.conf Jun 15 14:51:09 it defines all the main global configuration variables Jun 15 14:51:11 including the flags Jun 15 15:03:10 03Richard Purdie  07master * rd97f7d762e 10bitbake.git/lib/bb/server/process.py: Jun 15 15:03:10 process.py: Fix issue where early errors weren't making it to the console Jun 15 15:03:10 Signed-off-by: Richard Purdie Jun 15 15:26:29 I have added some paths to FILES_${PN}, and they get put into the package. I'd also like to add the paths to the sysroot, what variable do I need to add them to? Or do I need to provide my own do_populate_sysroot to do that? Jun 15 15:27:21 you likely need to provide your own, pretty sure the defaults leave out non-standard paths, and its not controlled by variables Jun 15 15:28:06 otavio: have you used qt4-tools-nativesdk in oe-core btw? Jun 15 15:29:25 kergoth: yes, I feared that might be the case :) sysroot_stage_dirs is the function I think. Jun 15 15:29:40 * kergoth nods Jun 15 15:29:47 of course, you can just append to the existing do_populate_sysroot Jun 15 15:29:50 no need to duplicate anything Jun 15 15:32:49 Of course :) Magic. Still getting used to the idea of appending to a function. Jun 15 15:36:27 What's the deal with do_stage ? Jun 15 15:36:28 Does appending a shell function to a python function work? Jun 15 15:36:40 do_stage is a remnant of how things used to be done Jun 15 15:36:43 thats' all Jun 15 15:36:52 don't create one, adn if you see one, look into removing it Jun 15 15:37:01 in the past, putting things in the sysroot was an explicit operation by the recipe Jun 15 15:37:08 now its taken from do_install's output Jun 15 15:37:22 right now you can't append shell to python or vice versa, as its a direct concatenation Jun 15 15:37:33 its on my todo to fix this, by making functions internally a list of recipe functions to execute Jun 15 15:37:40 with append/prepend simply adding to that list Jun 15 15:38:53 bluelightning: not yet; I will use it as soon as I fix the cmake stuff Jun 15 15:39:43 otavio: there's an issue with FILESPATHPKG that I have a fix for, but after that it's failing with this error: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623281 Jun 15 15:39:57 (although I there is some suggestion that that issue was arch related and I think that's not the case here) Jun 15 15:40:22 cool, I assumed it wouldn't be possible, so I append a python func which calls a shell func. Jun 15 15:43:16 celston: yeah, that's a pretty common workaround for the issue :) Jun 15 15:43:20 gets the job done Jun 15 15:43:29 bluelightning: http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qt4-x11.git;a=blob;f=debian/patches/sh.diff;h=94a4598c46853ae039a2824cea1d263956e2ecd7;hb=23927e8cd13bfd0f8ec001c180aa0135c6f22b44 <= Jun 15 15:46:57 kergoth: this: "do_populate_sysroot_append () {" gives this error "NOTE: Error expanding variable do_populate_sysroot" Jun 15 15:47:16 adding python before the append makes no difference. Jun 15 15:47:53 that's insufficient information to say what's going on. expansion errors generally indicate why the expansion failed.. Jun 15 15:48:15 bitbake -e is helpful, also, to make sure things are the way you think they are Jun 15 15:48:19 rather than just inspecting Jun 15 15:49:49 otavio: I'm not building for sh though here, it's for beagleboard on an x86-64 system Jun 15 15:53:50 The context is that the toolchain is bi-endian, and therefore has two lots of libs which need staging. Jun 15 15:55:04 kergoth: Fixed - can't call shell function direct from python (D'oh). What I've ended up with is this: http://pastie.org/2072878 Is there a more optimal way to do that? Jun 15 15:55:48 exec_func is the correct way to execute a function from python, yes Jun 15 15:56:34 i could see turning the functions into python function objects at parse time and just run them at task execution time, bypassing exec_func entirely, at some point. then just inject those into the context of the python functions, and you'd be able to run them directly Jun 15 15:56:36 heh Jun 15 15:57:35 I suppose I could access the bb variables in the appended function with getVar and skip the middle call. Jun 15 16:03:59 kergoth: thanks for the help, working now. Jun 15 16:04:07 great Jun 15 16:25:20 I wonder why more people aren't interested in a purely-srctree based oe-ish setup. It seems like it'd be lovely to work with to me Jun 15 16:25:23 nontrivial to put together of course Jun 15 16:25:25 but still Jun 15 16:26:20 kergoth: what do you mean by purely-srctree based? Jun 15 16:27:22 are you familiar with srctree? Jun 15 16:27:42 nope, link? Jun 15 16:28:24 Got one. Jun 15 16:28:31 celston: http://bec-systems.com/site/711/openembedded-srctree-and-gitver Jun 15 16:28:32 http://bec-systems.com/site/711/openembedded-srctree-and-gitver Jun 15 16:28:37 :) Jun 15 16:28:41 cbrake has some nice articles Jun 15 16:29:01 at any rate, basically you have a local source tree that you build out of, a git clone. no fetch/unpack/patch at all Jun 15 16:29:39 the best part is if you want to inspect something, you don't have to go 42 dirs deep in tmpdir Jun 15 16:29:43 Interesting. Jun 15 16:31:36 btw, I found SYSROOT_PREPROCESS_FUNCS (reference gtk+.inc) which also does what I was trying to do with staging. Jun 15 16:31:45 Although I can't make it see my staging func :( Jun 15 16:40:26 What's the story with underscores and dashes in function names in recipes? Jun 15 16:40:46 I had to rename a function to remove dashes before it would appear in the task's environment. Jun 15 16:40:56 avoid dashes. iirc shell doesn't support them in functions Jun 15 16:41:52 Right, note made :) Jun 15 16:42:16 kergoth: does that mean we should be blowing up if we find those during parsing? Jun 15 16:43:42 good question. probably Jun 15 16:44:11 Grrrr: cora_oe/cora-build-el/tmp-glibc/sysroots/elisa/el/lib/../../lib/libc.so.6: could not read symbols: File in wrong format Jun 15 16:44:15 and, of course, avoid underscores because you might get accidental override substitution :-} Jun 15 16:44:35 the bloody toolchain is going to the el/ lib path, then backing up and going to the be libs :( Jun 15 16:45:15 So close, but yet so far. Jun 15 16:45:45 pb_: hehe, i was thinking that Jun 15 16:46:03 crumbs, qemu.log is 3.7G Jun 15 16:46:09 that's quite a lot of log output Jun 15 16:46:13 Oh, hang on. There's some sed magic in the external toolchain install that adds in a relative ../../lib Jun 15 16:48:18 pb_: -v -v -v :D Jun 15 16:48:34 heh Jun 15 16:48:50 and, after all that, I only wanted about the last eight lines :-} Jun 15 16:53:14 03Andrea Adami  07org.openembedded.dev * r6c2736280a 10openembedded.git/recipes/klibc/ (klibc-utils.inc klibc.inc): Jun 15 16:53:14 klibc: fix packaging of mv Jun 15 16:53:14 * bad copy and paste Jun 15 16:53:14 * bump INC_PR to trigger rebuild (just in case) Jun 15 16:53:14 Signed-off-by: Andrea Adami Jun 15 16:57:02 hm. so, this is rather weird. my localedef is calling sys_brk and then just jumping off into the weeds. Jun 15 17:07:27 bluelightning: but maybe the arch didn't match on configure Jun 15 17:08:03 otavio: I checked the configure log, didn't see a similar message Jun 15 17:10:32 bluelightning: you might want to push it somewhere so I can look at it? Jun 15 17:10:46 * otavio still fighting with cmake Jun 15 17:10:47 otavio: the log? Jun 15 17:10:52 bluelightning: the patches Jun 15 17:11:11 otavio: oh yes sure am just in the process of doing that now Jun 15 17:22:59 kergoth: hello Jun 15 17:23:12 RP__: any thoughts on such a patch http://paste.ubuntu.com/627483/ Jun 15 17:23:21 khem: RP fixed the exit silently issue. Jun 15 17:23:35 khem: you had an error in the configuration metadata parsing, which it wasn't reporting to you Jun 15 17:23:40 at least, thats what i saw Jun 15 17:23:51 kergoth: hmmm yes I believe thats the case Jun 15 17:24:06 usually bitbake is pretty verbose about errors Jun 15 17:24:17 in a way thats helpful then being a silent killer Jun 15 17:33:13 otavio: oecore contrib paule/qt4-nativesdk-fix Jun 15 17:52:41 otavio: have filed this: http://bugzilla.pokylinux.org/show_bug.cgi?id=1168 Jun 15 18:15:27 bluelightning: humm it seems to be another issue on the qt Jun 15 18:15:31 bluelightning: not the same Jun 15 18:15:50 otavio hm Jun 15 18:16:01 bluelightning: i recall of a patch that has been dropped from oe-core of gcc issue Jun 15 18:16:08 bluelightning: might be worth a look on the log Jun 15 18:16:16 bluelightning: maybe it was the issue Jun 15 18:16:18 otavio: ok, I'll check that out Jun 15 18:16:19 woglinde: ? Jun 15 18:16:42 show the log Jun 15 18:17:12 woglinde: it is the bug bluelightning has pasted above Jun 15 18:17:24 hm wasnt there Jun 15 18:17:28 at the time Jun 15 18:17:42 bluelightning: http://bugzilla.pokylinux.org/show_bug.cgi?id=1168 Jun 15 18:17:45 woglinde: http://bugzilla.pokylinux.org/show_bug.cgi?id=1168 Jun 15 18:18:03 woglinde: sorry, didn't see you connecting Jun 15 18:20:47 hehe atomic Jun 15 18:21:09 hm but this seems easy to fix Jun 15 18:21:17 removing const at some point Jun 15 18:21:19 or add it Jun 15 18:29:38 woglinde: true we can hack it, but I'm after the most correct fix Jun 15 18:29:49 which may turn out to be the same as the hack of course :) Jun 15 18:29:55 *g* Jun 15 18:30:13 I am thinking it is fixed upstream anyway Jun 15 18:33:05 grr, I wish the git fetcher didn't just get wedged like this if you forget to start the ssh agent Jun 15 18:33:18 03Tom Rini  07master * r821f47e170 10openembedded.git/recipes/tiobench/ (tiobench-0.3.3/tiobench-makefile.patch tiobench_0.3.3.bb): Jun 15 18:33:18 tiobench: Rework tiobench-makefile patch, update install rule Jun 15 18:33:18 We need to pass in PREFIX=${D}/usr in order to have apps installed where Jun 15 18:33:18 expected (/usr/bin) and we need to move the docs over into Jun 15 18:33:18 /usr/share/docs as that's where they belong. Jun 15 18:33:18 Signed-off-by: Tom Rini Jun 15 18:33:25 hi pb Jun 15 18:33:32 hi woglinde Jun 15 18:36:21 hi Jun 15 18:36:32 hi gnutoo Jun 15 18:36:35 I've an update to do to SHR's connman init script Jun 15 18:36:45 they do not use INC_PR Jun 15 18:36:50 grr it seems cmake-nativesdk won't be easy to get done Jun 15 18:36:53 should I convert it to INC_PR? Jun 15 18:37:15 GNUtoo: I have been doing it when fixing stuff Jun 15 18:37:32 GNUtoo: sometimes I do the opposite like merging the inc into the bb Jun 15 18:37:39 ok Jun 15 18:38:24 there are 9 recipes an 1 inc file Jun 15 18:38:38 +another recipe that is broken but that is no connmand Jun 15 18:38:50 ah no Jun 15 18:38:54 7 recipes Jun 15 18:38:58 some frontends Jun 15 18:39:00 and 1 inc file Jun 15 18:40:49 hi effem Jun 15 18:47:02 hi woglinde, all Jun 15 19:03:46 ok; first cleanup patch is out Jun 15 19:03:56 lets now work on cmake-nativesdk Jun 15 19:04:14 I am confused about nativesdk on oe-core Jun 15 19:04:33 it seems it doesn't has the compiler set Jun 15 19:04:44 am I missing anything? Jun 15 19:06:32 if PR was r6 Jun 15 19:06:46 incPR can't be r1 Jun 15 19:06:51 *INC_PR Jun 15 19:06:59 so I guess I've to put the highest PR Jun 15 19:10:20 I'll try Jun 15 19:10:32 I remember doing INC_PR= "r1" Jun 15 19:14:28 does OE (classic) output a file of all packages and licenses used (still using Angstrom) Jun 15 19:14:51 hm in the labs folder I think Jun 15 19:16:09 woglinde: the testlab folder does not seem to have anything, but perhaps my OE snapshot is too old Jun 15 19:19:14 looks like distribute-license.bbclass is probably what I need Jun 15 19:19:51 cbrake, usually when I bitbake foo it distributes the source of only foo Jun 15 19:19:58 not of its deps Jun 15 19:20:08 I guess that needs fixing Jun 15 19:20:16 GNUtoo: so you need to do a full rebuild? Jun 15 19:20:51 so it doesn't work Jun 15 19:21:03 let's say I bitbake an image Jun 15 19:21:10 it will distribute the source of the image only Jun 15 19:21:21 not for instance its kenrel or busybox Jun 15 19:21:30 GNUtoo: interesting, even with a full rebuild? Jun 15 19:21:34 yes Jun 15 19:22:02 it's been broken this way since I started to use openembedded(long time ago) Jun 15 19:22:25 but if that can be fixed Jun 15 19:22:33 like for instance an inherit in the local.conf Jun 15 19:22:36 or something like that Jun 15 19:22:39 it would be great Jun 15 19:23:06 GNUtoo: yes, local.conf is probably how its supposed to work Jun 15 19:23:36 ok, if you get it working, I'd be interested in the solution Jun 15 19:23:40 GNUtoo: looks like cd /usr/lib/opkg/info; grep License * will also work to get things quickly Jun 15 19:24:05 btw I'm interested in license filtering Jun 15 19:24:15 is there anything like that in yocto or oe Jun 15 19:24:54 GNUtoo: Yocto takes it pretty seriously: http://elinux.org/images/e/ec/Elc2011_flanagan.pdf Jun 15 19:26:00 ok, I guess there is also a video of it at free electrons Jun 15 19:26:41 how the non-gplv3 is enforced? Jun 15 19:27:02 I'd like something like that but for preventing non-free stuff to come inside our images and repos Jun 15 19:31:40 woglinde, btw if I've PR="r6" and that I change to PR="r1.0" that won't work I guess, I need to start INC_PR at r7 Jun 15 19:33:37 quite a few of the LICENSE flags are LGPL with no version -- hopefully OE core has fixed that Jun 15 19:34:41 nick pepermint Jun 15 19:34:46 ops Jun 15 19:45:20 GNUtoo YES Jun 15 19:45:42 cbrake oe-core has it fixed Jun 15 19:45:47 ok I've tested on target and it behaved like expected Jun 15 19:46:03 cbrake or the recipes arent in oe-core meta-oe yet Jun 15 19:46:21 how does one run ldd on an ARM binary? Jun 15 19:46:33 (to get a list of dependent libs) Jun 15 19:46:42 ? Jun 15 19:46:47 cbrake, ldd is a script, it runs on target Jun 15 19:46:48 install ldd on the device Jun 15 19:47:01 if you want to ldd it on host, use the binutils instead Jun 15 19:47:08 it's not as good as ldd tough Jun 15 19:47:30 since it has no way to see if the deps are present Jun 15 19:48:04 cbrake: i'd just use readelf personally Jun 15 19:50:08 kergoth: thanks, readelf -d works I think Jun 15 19:50:32 yeah Jun 15 19:51:26 is there any chance that dependent libs link to additional libs that do not show up? Jun 15 19:51:37 and does it matter for license compliance? Jun 15 19:54:55 cbrake: not directly, but something could be using dlopen Jun 15 19:54:58 (afaik) Jun 15 19:55:01 also there's static linking to consider Jun 15 19:59:55 if something uses dlopen, it should be in RDEPENDS or RRECOMMANDS ideally Jun 15 20:05:34 DJWillis, hi Jun 15 20:07:14 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * r91e41a3fff 10openembedded.git/recipes/connman/ (connman.inc files/shr/connman): (log message trimmed) Jun 15 20:07:14 connman: SHR distribution: ignore the htcdream's network interfaces Jun 15 20:07:14 The SHR images uses iliwi by default, which call udhcpc, Jun 15 20:07:14 udhcpc blocks near the end: Jun 15 20:07:14 Lease of 192.168.1.147 obtained, lease time 600 Jun 15 20:07:15 [blocked here,"adding dns 192.168.1.1" not shown] Jun 15 20:07:16 The routes contain problematic lines such as(rmnet interface is normal): Jun 15 20:07:24 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * rcd6bb9f47f 10openembedded.git/recipes/connman/ (8 files): Jun 15 20:07:24 connman: convert to INC_PR Jun 15 20:07:24 Signed-off-by: Denis 'GNUtoo' Carikli Jun 15 20:09:17 Hey GNUtoo :) Jun 15 20:09:57 DJWillis, I found an issue in slim: it depend on bash Jun 15 20:10:26 what's the better fix? Jun 15 20:10:33 remove bash dependency Jun 15 20:10:47 or add bash to RDEPENDS_${PN} Jun 15 20:10:57 btw I added some games to oe: Jun 15 20:11:02 *wordwarvi Jun 15 20:11:13 *I fixed crimsonfields Jun 15 20:11:20 GNUtoo: I would guess that would be the best way. RDEPENDS would also work, there are some messy bits in there, that was my reason for not mainline pushing it ;). Jun 15 20:12:03 yes but I really needed slim Jun 15 20:12:11 for my bug20 Jun 15 20:12:40 btw will the pandora move to oe-core? Jun 15 20:12:49 GNUtoo: I know, I also need it for the OpenPandora, I am going to have to clean it up to get it into meta-oe. Jun 15 20:13:10 ok nice Jun 15 20:14:04 GNUtoo: https://github.com/openpandora << Look at what I am hacking on in my free time, meta-oe, oe-core, meta-angstrom and it's own BSP layer (the old -vendor stuff is also in it's own layer). Jun 15 20:14:14 ok Jun 15 20:14:54 we need a game directory in meta-oe Jun 15 20:15:31 also slim would be nice for xfce46-image Jun 15 20:15:39 maybe it could be integrated there Jun 15 20:20:39 GNUtoo: also reminds me that I need to sink more hours into working on Xfce 4.8.* Jun 15 20:22:46 ah that would be nice Jun 15 20:25:24 GNUtoo: I should shove it into a branch, sort of stopped work trying to get things working in oe-core/meta-oe and gave up on classic. Jun 15 20:25:56 ah? Jun 15 20:27:18 GNUtoo: not really working on anything other than oe-core/meta-oe, trying to work on that and a org.oe.dev tree is just to much like work when you only have a few hours a week to hack ;) Jun 15 20:27:33 ok Jun 15 20:51:31 khem: are you there? Jun 15 20:52:02 khem: to fix cmake properly I need to mangle the variables used for its compilation but I'd need some guidance to avoid wasting too much time on that Jun 15 20:52:08 khem: mind to give me a hand? Jun 15 21:38:44 anyone know what the current support level for UBIFS images in 2011.03-maintenance is? is it expected to work, or is it still experimental? Jun 15 22:07:21 kg4ysn: it should work Jun 15 22:07:29 otavio: I am here now Jun 15 22:21:45 03Andrea Adami  07org.openembedded.dev * re16a751548 10openembedded.git/recipes/klibc/ (klibc-utils.inc klibc.inc klibc_1.5.23.bb): Jun 15 22:21:45 klibc: repackage according to debian naming for libs Jun 15 22:21:45 * RDEPENDS cleanings for the (shared) utils Jun 15 22:21:45 * bump PR Jun 15 22:21:45 Signed-off-by: Andrea Adami Jun 15 22:27:05 khem: ok thanks, i'll keep looking into it then. the volume doesn't seem to be mounting, so i think i'm having a mismatch in the MKUBIFS_ARGS and UBINIZE_ARGS variables. **** ENDING LOGGING AT Thu Jun 16 02:59:57 2011