**** BEGIN LOGGING AT Thu Sep 17 02:59:57 2009 Sep 17 03:05:30 my patch fixes Sep 17 03:05:31 - *no) REPLACE_WCWIDTH=1 ;; Sep 17 03:05:31 + *no) ;; Sep 17 03:05:33 :-) Sep 17 03:17:52 m4t OE's site/* files are used to provide defaults for autoconf tests in a consistent fashion. Sep 17 03:22:28 kergoth thanks Sep 17 04:13:13 03Khem Raj  07org.openembedded.dev * r43690fb819 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc: Sep 17 04:13:13 preferred-xorg-versions-X11R7.4.inc: Lock PREFERRED_VERSION_dri2proto ?= "1.1" Sep 17 04:13:13 * With dri2proto 2.0 recipe being added now it gets picked up Sep 17 04:13:13 this recipes needs newer version of xorg-utils so we tie down Sep 17 04:13:14 the version of dri2proto to 1.1 Sep 17 04:13:18 Signed-off-by: Khem Raj Sep 17 04:13:20 03Khem Raj  07org.openembedded.dev * rf43c3adb4b 10openembedded.git/recipes/ (22 files in 2 dirs): (log message trimmed) Sep 17 04:13:23 glib-2.0-native_2.21.4.bb: New recipe for native glib 2.21.4 Sep 17 04:13:25 * Build shared library instead of static. Sep 17 04:13:27 * with libint.a the link order matters and generally for uclibc Sep 17 04:13:29 targets we append -lintl to LDFLAGS and sometime it gets specified Sep 17 04:13:31 before the objects and symbols do not get pulled in. Better we Sep 17 04:13:33 generate shared object so the linking order does not matter Sep 17 04:13:35 03Khem Raj  07org.openembedded.dev * r249fc51167 10openembedded.git/recipes/clutter/clutter.inc: Sep 17 04:13:38 clutter.inc: Add omap5912osk to COMPATIBLE_MACHINE Sep 17 04:13:40 Signed-off-by: Khem Raj Sep 17 04:13:44 03Khem Raj  07org.openembedded.dev * rcb86af0943 10openembedded.git/recipes/proxy-libintl/ (2 files in 2 dirs): Sep 17 04:13:49 proxy-libintl-20080418: Add the patch to compile as shared library Sep 17 04:13:51 * Keep generating .a file. Sep 17 04:13:53 Signed-off-by: Khem Raj Sep 17 04:19:27 good mornink Sep 17 04:42:39 czr_: good morning Sep 17 04:43:03 hey khem Sep 17 04:43:21 * czr_ is waiting for coffee to get a spurt of energe to do some kernel slicing and dicing Sep 17 04:56:03 czr_: which part of world are you in Sep 17 04:56:16 khem, finland. you? Sep 17 04:56:24 I am in US Sep 17 04:56:41 thought so (explains the timing of the commits :-) Sep 17 04:57:22 Do you work for nokia :) Sep 17 04:57:43 heh. not everybody here works for nokia :-). no. I have worked on couple of projects for them though (maemo-related) Sep 17 04:58:08 I read somewhere that they are largest employer there Sep 17 04:58:34 well, we don't have so many large companies to start with :-). so it's not difficult :-) Sep 17 04:59:08 czr_: maemo stuff in OE seems to be stale Sep 17 04:59:12 http://www.uranus.fi/en/jobseekers/jobs/open.php?id=19982 that's a good list of top 100 companies in finland and their industries Sep 17 04:59:29 probably so yes. although don't look at me, I haven't touched maemo for couple of years now :-) Sep 17 04:59:47 I regret that I never made to scandinavia when I lived in germany Sep 17 05:00:53 I should travel more as well. Although I visited the states a month ago or so Sep 17 05:01:45 hello Sep 17 05:01:47 good morning Sep 17 05:01:59 i wanted to ask how to change the kernel version i'm using Sep 17 05:02:27 czr_: which city were you in here Sep 17 05:02:36 tio: which machine ? Sep 17 05:03:00 linux Sep 17 05:03:10 khem, we (me and gf) were staying near Savannah (GA) where my mother lives, we also travelled around there and went to orlando for couple of days. Sep 17 05:03:29 nice Sep 17 05:03:38 tio: did I ask OS ? Sep 17 05:03:46 it wasn't bad. hot but nice (compared to finland anything is hot :-) Sep 17 05:04:35 khem, where in the us are you? Sep 17 05:04:41 CA Sep 17 05:04:59 ah. never visited that part :-) Sep 17 05:05:07 asking the board i'm working @ khem Sep 17 05:05:21 yes Sep 17 05:05:36 beagleboard Sep 17 05:06:05 tio: which version is it compiling now Sep 17 05:06:23 2.6.29 Sep 17 05:06:29 i want to use 2.6.24 Sep 17 05:06:47 because i want to use csl-2008q3 Sep 17 05:08:36 with it Sep 17 05:10:13 tio: remove DEFAULT_PREFERENCE_beagleboard = "1" from linux-omap_2.6.29.bb Sep 17 05:11:44 I doubt .24 will be any good on beagle Sep 17 05:12:36 will there be some problem? Sep 17 05:12:45 using .24 on beagle Sep 17 05:13:33 beagle is newer than .24 Sep 17 05:13:43 ok Sep 17 05:13:57 .26 will work then? Sep 17 05:14:07 no idea Sep 17 05:14:18 tio, why do you insist using older kernels? Sep 17 05:14:21 ok Sep 17 05:14:23 +on Sep 17 05:14:40 actually for the newer version i have to chnage the toolchain Sep 17 05:14:52 i want to use csl-2008q3 only Sep 17 05:14:55 i wouldn't use anything older than .28 on a beagleboard. The most recent omap linux tree is best Sep 17 05:15:10 tio, build the kernel with a different toolchain than you use for other stuff? Sep 17 05:15:33 although I have no idea how to tell oe to do that, but I'm sure it's possible. Sep 17 05:15:44 ok Sep 17 05:36:56 IMAGE_FSTYPES = "jffs2 tar.bz2" i ve but it doesnt create the tar one .. any hints ? Sep 17 05:47:42 rob_w_: use MAGE_FSTYPES = "jffs2 tar" Sep 17 05:48:30 tryed that before .. (if you meant IMAGE_FSTYPES) Sep 17 05:50:45 hmph. kernel works but fails to run init from nfsroot. Sep 17 05:53:19 rob_w_: it works here Sep 17 05:53:44 czr_: did you forget to enable NFS in kernel Sep 17 05:53:58 khem, no. it mounts nfs root :-). Sep 17 05:54:11 ok then whats the error Sep 17 05:54:32 rob_w_: which machine/distro Sep 17 05:55:00 khem, http://pastebin.com/m3a41da36 I'm thinking it's something to do with library versions or something, but it's weird. the same rootnfs works with vendor kernel. Sep 17 05:55:04 ppc440e-angstrom-linux/ Sep 17 05:55:54 I'll dump some traffic on nfs-server side to see what's happening, don't worry too much :-) Sep 17 05:56:37 rob_w_ just curious, what kind of ppc440e board is it? vendor/model? Sep 17 05:56:39 btw, is cliff barke around on irc? Sep 17 05:57:34 m4t, its a custom board , vendor can be found under elotec-systems.eu Sep 17 05:58:03 czr_: enable DEBUG_USER Sep 17 05:58:24 khem, yeah, will do that after I check out what happens on nfs server :-) Sep 17 05:58:35 czr: he is but right now its 2 am where he lives :) Sep 17 05:59:13 rob_w_ interesting, thanks Sep 17 05:59:16 ah, what's his nick? Sep 17 05:59:34 m4t, if you are interested in it ,, feel free to get back to me Sep 17 05:59:53 khem, btw if you're not too busy, would you mind checking out the sane-toolchain.inc-patch that I sent on the oe-list yesterday? it's a trivial small thingy Sep 17 06:00:03 m4t, they use eldk for the development but i want it tobe oe ! Sep 17 06:00:17 czr_: Its in already Sep 17 06:00:24 ah, cool. thanks. Sep 17 06:00:27 thanks for it Sep 17 06:00:51 am rebuilding now the image with only tar .. lets see what happens Sep 17 06:00:55 np Sep 17 06:02:03 rob_w_: which machine conf file are you using Sep 17 06:02:12 i,e NACHINE=? Sep 17 06:03:04 canyonlands or sequoia Sep 17 06:03:12 hey khem, http://pastebin.com/d43431ce9, those are some of the packages i added or updated Sep 17 06:04:30 send the patch m4t to the list if you would like to contribute the changes here Sep 17 06:04:39 yup Sep 17 06:04:49 i will aim for this weekend Sep 17 06:05:01 i need to clean up some tarballs etc. from various recipes/ dirs Sep 17 06:05:12 there are some i couldnt get, too, that arent on there Sep 17 06:05:19 cool I will be happy to review them Sep 17 06:05:21 i was going for grep, gzip, bzip2, gnupg, ... Sep 17 06:05:40 but i decided to just use busybox builtins for compression, and i guess gnupg is 'fine' where it is for now Sep 17 06:05:44 rob_w_: I think I see your problem Sep 17 06:06:26 add this to your local.conf IMAGE_FSTYPES_local = "jffs2 tar" Sep 17 06:07:02 actual override wont work because machine confs say IMAGE_FSTYPES = "jffs2" Sep 17 06:07:08 gnupg 1.4.10 and perl 5.10 would be great Sep 17 06:07:24 hmmm m4t yeah busybox is handu Sep 17 06:07:28 handy Sep 17 06:08:30 there are a couple security fixes for udev 1.24, irssi, postfix 2.2.x, and a few others Sep 17 06:08:43 oh and lynx Sep 17 06:09:03 thats nice Sep 17 06:10:36 yea Sep 17 06:11:26 m4t: are you in Germany ? Sep 17 06:11:27 some of the new versions have fixed dependencies and oe_conf_extra per kergoth's missingdeps.bbclass Sep 17 06:11:33 nope, us Sep 17 06:11:53 cool which city Sep 17 06:13:19 m4t: it's working for you? note that it's not perfect, because some libtool/pkg-config crap can pull in indirect deps. so if your app links against libfoo, and libfoo links against libbar, some crappy setups will result in the app linking against both foo and bar, so the dep checker would report both. hard to avoid that, though, short of patching libtool and the pkg-config scripts, or using -Wl,--as-needed everywhere Sep 17 06:14:05 kergoth: I think as-needed is better way to go Sep 17 06:14:18 and we can blacklist packages along the way which dont behave Sep 17 06:14:19 i am down south Sep 17 06:14:25 i agree, but sadly it's not that easy, because the argument only affects libs after it on the commandline Sep 17 06:14:33 and not all buildsystems put LDFLAGS before thel ibs Sep 17 06:14:51 so it wont always be used everywhere Sep 17 06:15:11 kergoth: we can force gcc to emit it properly for linking Sep 17 06:15:12 hmmm. khem, nfs side seems ok (I see uclibc loaded (0.9.28 = vendor version)), but I get unimplemented system call: http://pastebin.com/m1491fa7d Sep 17 06:15:22 khem: by default, missingdeps.bbclass disables itself when you aren't using --as-needed. i had m4t enable it forcibly for his testing Sep 17 06:15:29 I think I've disabled 16-bit compatibility syscalls from the kernel embedded optimizations, so I'll try to enable them now Sep 17 06:15:46 khem: well, arguably the behavior where it only affects following libs is good, because there are cases where you might want to force inclusion of a lib, and not let it leave it out.. Sep 17 06:15:57 * kergoth shrugs Sep 17 06:16:45 http://gist.github.com/187895 is the class, for the curious Sep 17 06:18:14 kergoth: then they might use -Wl.--no-as-needed --Wl, --as-needed Sep 17 06:18:37 that's true, so you're thinking just change the default.. that's a good idea Sep 17 06:18:38 but we have to take a stance if we want to use as-needed Sep 17 06:18:47 yes Sep 17 06:19:05 i can't see any reason why not. there's no reason an app should have to care about what its libs are using Sep 17 06:19:26 exactly Sep 17 06:19:53 unless you're on solaris or something, in which case good luck... Sep 17 06:19:56 :) Sep 17 06:20:09 slowaris is dead elephant Sep 17 06:20:17 thankfully Sep 17 06:20:34 well, to be fair, it was pretty nice on sparcs, but holy crap did it suck on x86 Sep 17 06:20:38 * czr_ starts looking for the ivories Sep 17 06:21:19 kergoth: truly I liked alpha better when it comes to that age Sep 17 06:21:26 * kergoth nods Sep 17 06:21:41 didn't those usually run digital unix? Sep 17 06:21:46 they did Sep 17 06:21:55 and also there was some lnx ports Sep 17 06:22:06 * kergoth used to have to do tech support for all these unix variants when he worked at digi.... those serial port cards with 300+ ports for dumb terminals, pre-ethernet Sep 17 06:22:18 12 yera old openserver boxes and shit.. Sep 17 06:22:20 * kergoth shudders Sep 17 06:22:26 heh Sep 17 06:23:12 I met a guy from the largest finnish online banner company. He said that they were stuck with linux on alphas because nothing else could handle the traffic Sep 17 06:23:29 however, after a while I learned that they learned stock apache, so that explains the load pretty much ;-) Sep 17 06:23:38 they used even. Sep 17 06:23:53 remembering past I thought SGI boxes running IRIX were cool Sep 17 06:24:03 out of my sheer love for mips Sep 17 06:24:24 hehe Sep 17 06:25:12 IRIX has so many enhancements that even today linux lacks Sep 17 06:25:25 so does windows. Sep 17 06:25:27 * czr_ hides & runs Sep 17 06:26:11 windows is nice for multimedia what I think today Sep 17 06:26:38 I haven't used windows for ages. primarily I mean. it just feels wrong. Sep 17 06:26:53 it only takes 20 seconds on the windows "command line" to get me mad. Sep 17 06:27:54 hmm. is there an easy way to test whether a binary or .so is pre-EABI or EABI? Sep 17 06:28:04 hmm. file should know, right? Sep 17 06:28:06 oh well I try to get OE build working on my Macbook Pro these days Sep 17 06:28:35 czr_: you could dump the ELF headers Sep 17 06:28:50 I'd need a cross readelf for that though. Sep 17 06:28:50 with readelf -e or somesuch Sep 17 06:28:57 * czr_ nods Sep 17 06:29:11 yes or you can build one for target and install it Sep 17 06:29:18 the embedded options didn't make the problem go away, so I'm thinking that I'm actually trying to run pre-eabi stuff on the kernel. Sep 17 06:29:29 well, the target is still running vendor nfsroot. Sep 17 06:29:34 I'd rather not touch that quite yet Sep 17 06:29:43 czr_: enable OABI in kernel Sep 17 06:29:55 yes :-) Sep 17 06:30:19 I think that could be a problem Sep 17 06:30:37 what version of vendor kernel do they have on box Sep 17 06:30:42 2.6.26.6 Sep 17 06:30:51 same one that I'm building since the vendor patches are against that. Sep 17 06:31:03 I might try to forward port the patches later, but that's not a priority right now Sep 17 06:31:04 hmm then I doubt it is OABI nfsroot but anything is possible Sep 17 06:31:35 can you put libuClibc.so binary from vendor rfs somewhere Sep 17 06:31:42 I can inspect it Sep 17 06:31:57 yup. enabling oabi didn't help. Sep 17 06:32:04 give me a sec. Sep 17 06:32:20 how about enabling THUMB Sep 17 06:32:28 that's already done ages ago Sep 17 06:32:41 did you see the pastebin with user_debug enabled? Sep 17 06:32:51 http://pastebin.com/m1491fa7d this one. Sep 17 06:34:06 http://koltsoff.com/pub/4khem/ Sep 17 06:34:14 that has uclibc and busybox Sep 17 06:34:19 (vendor nfsroot versions) Sep 17 06:35:29 hmm. it's eabi (readelf -e says so). Sep 17 06:35:36 i'm getting this error when i'm trying to build Sep 17 06:35:37 Please set a valid MACHINE in your local.conf Sep 17 06:35:47 though i have set omap-3430sdp Sep 17 06:35:52 in my conf file Sep 17 06:36:13 mayhem, did you check that there's a proper conf for that machine under conf/machine/ ? Sep 17 06:36:18 (under openembedded/) Sep 17 06:37:04 i'll just check it Sep 17 06:41:22 what regarding this error Sep 17 06:41:23 hello Sep 17 06:41:24 Error, Your PACKAGE_ARCHS field contains duplicates. Perhaps you set PACKAGE_EXTRA_ARCHS twice accidently through some tune file? Sep 17 06:41:50 i just did bitbake nano & copy it to SD card Sep 17 06:42:11 And booting from beagleboard and opkg install ~~.ipk Sep 17 06:42:28 then i got package nano md5sum mismatch Sep 17 06:42:42 i got error message Sep 17 06:42:53 i did opkg update Sep 17 06:42:59 and opkg upgrade Sep 17 06:43:08 but it does not working Sep 17 06:43:23 anyone know this issue? Sep 17 06:43:52 jin: you need to run some image build Sep 17 06:44:01 Error, Your PACKAGE_ARCHS field contains duplicates. Perhaps you set PACKAGE_EXTRA_ARCHS twice accidently through some tune file? Sep 17 06:44:07 what about this error Sep 17 06:44:22 mayhem: which machine/distro Sep 17 06:44:36 czr_: you seem to be dying in mmap Sep 17 06:44:38 omap-3430sdp Sep 17 06:44:44 distro Sep 17 06:44:46 tilinux Sep 17 06:44:54 khem, cool :-) Sep 17 06:45:01 I dont see such a machine omap-3430sdp Sep 17 06:45:09 in distro/machines Sep 17 06:45:17 what I did now was I built a small hello world (static) with the cross gcc, then copied that as /sbin/init, and it runs ok. Sep 17 06:45:25 so I'll just ignore the vendor rootfs for now Sep 17 06:45:41 it is khem Sep 17 06:46:00 unless you have some ideas how to get it to work easily. google isn't finding anything useful for me. Sep 17 06:46:11 mayhem: which branch are you on Sep 17 06:46:14 i'm sorry but i don't understand "run some image build" Sep 17 06:46:29 now i using beagleboard & angstrom Sep 17 06:46:39 what do ypu mean by branch @ khem Sep 17 06:46:43 you* Sep 17 06:48:52 czr_: the error in that pastebin you posted is indeed what you'd get trying to run oabi binaries on an eabi kernel. ef90005a is sys_mmap in oabi, but that instruction should never appear in an eabi binary. Sep 17 06:49:31 hmm. weird. but my kernel has oabi now. Sep 17 06:49:41 and the error doesn't go away. and readelf says that uclibc.so is eabi. Sep 17 06:49:48 mayhem: you need to run package_update_index_ipk task Sep 17 06:50:20 pb____, don't worry about it though. I'm replacing the vendor rootnfs with something that OE builds. Sep 17 06:50:27 hi pb____ Sep 17 06:50:35 what's the easiest/smallest tar-based image I can build with micro? Sep 17 06:50:52 micro-base-image Sep 17 06:51:16 thanks. Sep 17 06:51:39 jin: you need to run package_update_index_ipk task Sep 17 06:51:59 mayhem: I mean OE branch Sep 17 06:52:25 czr: the file sizes I get for that are: Sep 17 06:52:27 -rw-r--r-- 1 pb pb 671528 2009-09-16 15:05 micro-micro-base-image-uclibc-ipk-20090916-nslu2be.rootfs.tar.gz Sep 17 06:52:43 -rw-r--r-- 1 pb pb 6881039 2009-09-16 15:36 micro-micro-base-image-eglibc-ipk-20090916-nslu2be.rootfs.tar.gz Sep 17 06:52:43 pb____, uclibc? Sep 17 06:52:50 ah yes. /me be bling. Sep 17 06:52:54 blind even. and bad typist. Sep 17 06:53:10 ugh, the eglibc is huge :-) Sep 17 06:53:18 the eglibc build does seem a bit massive, I don't know what's going on there. Sep 17 06:53:28 I guess it is including everything. Sep 17 06:53:36 personally I am only using the uclibc one at the moment so I am not too bothered :-} Sep 17 06:53:38 so it's more or less same as glibc I guess. Sep 17 06:53:42 * czr_ nods Sep 17 06:53:48 I'm building an eglibc one right now Sep 17 06:53:58 even for plain glibc that file size seems a bit excessive. Sep 17 06:54:41 oh, crazy eglibc, it's shipping all the timezone data in libc6.ipk Sep 17 06:54:54 and ldconfig, even though that's meant to be disabled for miro Sep 17 06:54:55 micro Sep 17 06:54:55 it wants to take over the world. Sep 17 06:55:15 jin: you can do bitbake package-index Sep 17 06:55:22 oh Sep 17 06:55:25 ok Sep 17 06:55:36 thanks now i try Sep 17 06:55:40 I think the eglibc packaging must just be busted. you might be better off with plain glibc at the moment. Sep 17 06:56:06 well, I'll figure it out as I go. Sep 17 06:56:07 pb____: hmmm thats prolly wrong I remember someone adding it Sep 17 06:56:29 khem: adding what? the timezone data? Sep 17 06:56:34 yeah Sep 17 06:56:44 it should be a separate package Sep 17 06:57:17 khem: should run this task first package_update_index_ipk?? Sep 17 06:58:32 hmm. does timezone stuff go into eglibc-localedata-x-y? Sep 17 06:58:47 no, that's for the locale data (!) Sep 17 06:58:54 hmm. right. :-) Sep 17 06:59:00 timezones are separate :-} Sep 17 06:59:11 it does look like both eglibc and glibc just stuff them into libc6.ipk at the moment, actually Sep 17 06:59:21 I guess the glibc packaging needs a bit of reworking for micro Sep 17 06:59:33 99% of the contents of libc6.ipk is erroneous and should not be there. Sep 17 06:59:44 ah. libc6_2.10-r6.1_armv5te.ipk = 2208578 bytes Sep 17 07:00:25 khem: i did bitbake package-index and got Packages, Packages.filelist, packages.gz, Packages.stamps in /oe/tmp/deploy/glibc/ipk folder Sep 17 07:00:43 right, that's almost exactly the size that I get Sep 17 07:01:15 khem: i just installed OE and try bitbake nano Sep 17 07:01:27 it did well with no error Sep 17 07:01:30 pb____: I plan to look at eglibc packaging in coming days Sep 17 07:01:52 when I will also add cross locale generation capability Sep 17 07:01:54 khem: what else i have to do? Sep 17 07:02:00 yeah, all of the timezone stuff is included here as well. Sep 17 07:02:00 the ldconfig thing is just wrong in eglibc-package.inc. I guess you could copy the right bits from glibc-package, which should save 500k or so before compression. Sep 17 07:02:13 then there's the timezone thing, and a load of extraneous libs. Sep 17 07:02:33 also, I find some weird progs, under libexec: POSIX_V6_ILP32_OFF32 and 5 other similar progs Sep 17 07:02:50 although I guess it's only one executable and linked with multiple names Sep 17 07:03:10 anyhow, I guess I can still use this for testing, so it's not a biggie. Sep 17 07:03:13 thanks all :-0 Sep 17 07:04:32 pb____: ok the USE_LDCONFIG stuff Sep 17 07:05:32 right Sep 17 07:05:49 may be it could be a separake ipk Sep 17 07:09:44 yes, that would be ok Sep 17 07:09:56 nobody seems particularly keen to have that feature but it certainly wouldn't hurt anything. Sep 17 07:10:12 khem: do i have to copy package* to SD card with nano_2.0~.ipk? Sep 17 07:16:16 hmm. should micro have a getty or something? Sep 17 07:16:35 http://pastebin.com/m63944b71 Sep 17 07:16:47 that's it. no login nothing. Sep 17 07:23:24 ah. my /dev/ is almost empty. weird. Sep 17 07:23:37 so no tty devices on which to start getty. Sep 17 07:27:59 it's meant to be populated at runtime by mdev, I think Sep 17 07:28:12 not sure offhand whether the standard micro-base-image includes a getty. quite likely not since many devices are headless. Sep 17 07:29:33 ah yes, it should be running getty on ttyS0 Sep 17 07:30:31 looking at your pastebin output, it never seems to be getting to runlevel 5 for some reason. Sep 17 07:31:21 yes. but well. there's no ttyS0 (there's ttyNS0 in theory, but /dev/ contains this: http://pastebin.com/m6d9d5b9d ) Sep 17 07:31:50 it runs all of the rcS stuff, but I guess that getty starts at that point and something confuses someone since I get no output after that Sep 17 07:32:18 if I remove the sleep from S50debug.sh, then the output will be cut as well. so someone is trying to do something, but seeing as /dev/ isn't populated properly.. nothing will work. Sep 17 07:32:54 czr_: I think you are hitting the mmap bug in uclibc 0.9.28 Sep 17 07:33:06 http://lists.uclibc.org/pipermail/uclibc/2007-March/038326.html Sep 17 07:33:12 khem, you mean the vendor rootnfs? Sep 17 07:33:22 czr_: yes Sep 17 07:33:26 cool. thanks a lot. Sep 17 07:33:41 and they might have wired NR_mmap in their kernel to get around the issue Sep 17 07:34:40 hmm. that would also mean that the kernel that they ship in binary form is not the same that I'm getting with 2.6.26.6. and their patches. how shocking.. Sep 17 07:34:55 nokia used to do that all the time with maemo-devices. Sep 17 07:35:34 khem, I gave up on the vendor rootnfs though. using micro-base now. but having some issues (as you might have noticed above) Sep 17 07:36:18 czr_: I generally use console-image Sep 17 07:36:25 works well for me Sep 17 07:36:31 is it much larger? Sep 17 07:36:36 sort of Sep 17 07:36:50 I'll start building it. will report later. thanks Sep 17 07:36:54 4Mb rfs IIRC Sep 17 07:36:55 khem: how would the lack of that uclibc patch cause the "obsolete syscall" diagnostic? I can't immediately think why that could be related. Sep 17 07:37:18 bur takes quite a while to compile because bluez pulls in all sort of crap Sep 17 07:37:39 ah. and I see that there's stuff coming from xorg as well Sep 17 07:37:45 and gtk.. Sep 17 07:37:47 oh my. Sep 17 07:38:03 pb____: uclibc precompiled code is calling the old mmap syscall but czr_ 's new kernel does not have the call Sep 17 07:38:09 khem: right, but that would not cause this error Sep 17 07:38:11 thats my guess Sep 17 07:39:01 btw, what's OE's stance on adding new machines with kernel patches which are GPLv2 but the vendor is not actively pushing them into vanilla? Sep 17 07:39:03 (or even arm) Sep 17 07:39:13 because that's what I'm working with atm. Sep 17 07:39:22 simply calling a syscall which isn't implemented would not elicit that message; it means specifically that you have a calling standard mismatch. Sep 17 07:40:39 pb____: yes I think old mmap was left OABI in kernel Sep 17 07:41:01 old_mmap is only implemented for oabi, yes. Sep 17 07:41:24 but, my point is that calling sys_old_mmap would not cause the error message in question. Sep 17 07:41:29 in uclibc with EABI the call passed the sysnum in r7 Sep 17 07:41:49 03Steve Sakoman  07stable/2009 * rbdf9269286 10openembedded.git/recipes/ebtables/ebtables_2.0.6.bb: Sep 17 07:41:49 ebtables: fix GNU_HASH error Sep 17 07:41:49 Signed-off-by: Koen Kooi Sep 17 07:41:49 Acked-by: Denys Dmytriyenko Sep 17 07:43:54 hmmm looking at czr_ s uclibc it seems its OABI Sep 17 07:44:15 because all syscalls are passing the syscall number as argument to swi Sep 17 07:44:33 hmm. but I have oabi support in kernel.. Sep 17 07:44:39 plus, readelf says it's eabi. Sep 17 07:45:15 anyhow guys, don't spend any time on it :-). Sep 17 07:46:30 czr_: your uclibc is OABI Flags: 0x202, has entry point, GNU EABI, software FP Sep 17 07:48:56 hmm. 0x202 = oabi? Sep 17 07:49:02 czr_: for EABI it has to have flags |= (EABI_VER << 28) Sep 17 07:49:07 yes Sep 17 07:49:18 ah. I see. I was just looking at the "GNU EABI". Sep 17 07:49:28 yes Sep 17 07:49:45 so You need to have full OABI support in kernel Sep 17 07:49:55 or even compile the kernel with oabi Sep 17 07:50:02 toolchain Sep 17 07:50:34 but better use all pieces from OE you will feel better Sep 17 07:50:35 ah. I don't care about oabi actually that much. I built with EABI and enabled OABI support but I guess that's not quite enough. Sep 17 07:50:38 because it will work Sep 17 07:50:40 yeah. OE <3. Sep 17 07:50:59 anyway time to sleep here Sep 17 07:51:03 good night Sep 17 07:51:07 night, thanks a bunch Sep 17 08:36:41 florian_kc: good morning! Sep 17 08:37:13 good morning Sep 17 08:38:08 denix: ping Sep 17 08:38:22 (morning channel btw :) Sep 17 08:38:30 hi ant_work Sep 17 08:38:53 good morning , florian Sep 17 08:39:07 dth: hi Sep 17 08:41:02 florian: do you plan to attend the oedem in november? I am just trying to count up the final numbers. Sep 17 08:41:37 pb____: oh... yes I do. Forgot to answer your mail again :-} Sep 17 08:42:58 florian: righto, excellent. thanks. Sep 17 08:43:53 03Brijesh Singh  07org.openembedded.dev * r05a753b24b 10openembedded.git/recipes/gstreamer/gst-player_svn.bb: gst-player: add recipe for a simple gstreamer player Sep 17 08:43:54 03Brijesh Singh  07org.openembedded.dev * r33e67dff77 10openembedded.git/recipes/ti/ (2 files in 2 dirs): Sep 17 08:43:54 gstreamer-ti: remove mp3 cap from gst_ti auddec1 element. Sep 17 08:43:54 * Default TSPA codec does not have mp3 decoder and this patch removes the mp3 decoder caps from auddec1 element. This will help playbin on auto-detecting mp3 decoder when dsp decoder is not available. Sep 17 08:43:57 03Brijesh Singh  07org.openembedded.dev * rcac885572c 10openembedded.git/recipes/ti/ (2 files in 2 dirs): gstreamer-ti: import omapfbsink in gst_ti and add support for hw accelerated framecopy based on dmai transport buffers. The new element is registered as "omapdmaifbsink" Sep 17 08:44:01 03Brijesh Singh  07org.openembedded.dev * r0624cfcd88 10openembedded.git/ (conf/checksums.ini recipes/ti/ti-cs1-omap3530_1.0.1.bb): ti-cs1-omap35330: update SR_URI Sep 17 08:44:11 pb____: yw Sep 17 08:47:56 is it possible to make changes to source code in tmp/work/* then re-bitbake that package without wiping those changes out? Sep 17 08:48:30 with care, yes. try "bitbake -f -c compile" Sep 17 08:48:46 pb____: would be possible to have more details on OEDEM ? Sep 17 08:50:35 pb____: thx. looks like that worked Sep 17 09:30:42 test Sep 17 09:32:19 ahem... first time here. Can I ask a question? Sep 17 09:33:42 ispcb: I'm also new, but I'm pretty sure you can just ask without asking to ask :) Sep 17 09:34:25 so if i ve a PREFERRED_VERSION in a machine conf but the build pulls even a lower version , something has overwritten my config ? Sep 17 09:34:57 ispcb: ~ask Sep 17 09:35:01 ok. the question may be simple ... I am doing "bitbake -b zip_2.32.bb" which needs (like many other receipes) sha256sum Sep 17 09:35:20 the problem is sha25sum is not available Sep 17 09:35:31 and I have to do bitbake -b shasum before Sep 17 09:35:35 by hand Sep 17 09:35:39 is it normal? Sep 17 09:36:04 ispcb: bitbake zip will build you the latest zip with all your dependancy's Sep 17 09:38:06 ispcb: never use bitbake -b Sep 17 09:38:14 ok ? Sep 17 09:38:16 .. Sep 17 09:38:23 ispcb: it is for experts only Sep 17 09:39:01 bitbake what non experts should be doing Sep 17 09:39:46 another way to ask the same question: When doing "bitbake zip_2.32.bb" shouldn't the sha256sum be build before (as a dependency) ? Sep 17 09:40:33 XorA : thanks for the advice! Sep 17 09:40:35 ispcb: bitbake zip is the correct form of that command Sep 17 09:40:57 ispcb: or bitbake zip-2.32 if you need to use a non default version Sep 17 09:41:08 ok I got that but I have the sha256sum problem with any other receipe that uses sha256sum Sep 17 09:41:14 ispcb: and that will build sha256sum Sep 17 09:41:22 ok Sep 17 09:41:27 I will give it a try Sep 17 09:41:34 ispcb: all dependencies in the tree are built before the target Sep 17 09:41:43 that's what I tought Sep 17 09:41:51 -b breaks that Sep 17 09:42:12 than that should be it ... I followed closely the documentation from OE :) Sep 17 09:43:10 XorA : no further questions. Thanks again for your time! Sep 17 09:44:30 ispcb: no problem, the more happy users the better for me Sep 17 09:47:59 XorA, what was the command to show the depency list of a specific target ? Sep 17 09:48:40 rob_w: bitbake -g Sep 17 09:50:48 03Xerxes Rånby  07org.openembedded.dev * r718a561ceb 10openembedded.git/recipes/llvm/ (3 files in 2 dirs): Sep 17 09:50:48 llvm 2.7: New recipe. Sep 17 09:50:48 llvm-native 2.7: Likewise. Sep 17 10:13:57 NOTE: checking PREFERRED_PROVIDER_glibc-2.6.1 Sep 17 10:13:57 NOTE: checking PREFERRED_PROVIDER_glibc-2.6.1-r35.0 Sep 17 10:13:57 NOTE: selecting glibc to satisfy runtime libsegfault due to PREFERRED_PROVIDER_virtual/libc = glibc Sep 17 10:14:15 what does my beloved bitbake telling me with this ? Sep 17 10:14:52 rob_w: it's just conversational, you can almost certainly ignore it. Sep 17 10:16:03 satifying a runtime libsegfault . sounds horrible Sep 17 10:16:15 :-) Sep 17 10:19:32 but thanks pb__ for the clarification Sep 17 10:20:01 what it actually means is that bitbake has encountered something which RDEPENDS on libsegfault, and it has decided to build glibc in order to obtain libsegfault because that's what you have selected as your preferred provider for glibc. Sep 17 10:21:09 so is that the initial depend which pulls in glibc as such ? Sep 17 10:28:03 no, the dependency on libsegfault must be coming from some kind of debug tool package Sep 17 10:28:14 ok Sep 17 11:26:07 pb__: could you put my name down for oedem ? Sep 17 11:28:02 lrg: sure thing Sep 17 11:28:50 pb_:thanks. XorA and I will probably travel down together (maybe drive) Sep 17 11:32:19 how big of a party is oedem usually ? Sep 17 11:39:32 rob_w, we work late :) Sep 17 11:39:54 hmm i see Sep 17 11:39:57 ;-) Sep 17 11:44:54 * ant_work finally googled to see what's the buzz about that Zippy...an expansion board like a BUGvonHippel Sep 17 12:02:37 mckoan: I am still working on some of the details, but if there is anything in particular that you want to know, feel free to ask and I will see what I can do. Sep 17 12:09:28 mckoan: take coffee and spaghetti with you... Sep 17 12:09:41 * czr_ peeks Sep 17 12:10:18 ant_work: we have both of those in plenty :-D Sep 17 12:34:39 pb__: thx, I basically need to know the location in order to book an hotel Sep 17 12:35:04 pb__: something clean, cheap, nearby Sep 17 12:37:44 mckoan: the most likely location is postcode cb1 3js, which is on the east side of the city. Sep 17 12:38:46 fallback location is th1's office which is on the science park, postcode cb4 0fy I think Sep 17 12:40:04 pb__: do you have the address please? Sep 17 12:40:38 * mckoan need to discover an hotel in the nearby using google maps Sep 17 12:41:24 pb__: maybe you know where other developers are staying there? Sep 17 12:42:07 http://wiki.openembedded.net/index.php/Oedem/2009 Sep 17 12:42:24 mckoan, can you put some suggestions on this page? Sep 17 12:43:03 hmm. for some reason mdev -s doesn't setup my devices properly. Sep 17 12:43:18 maybe I'll just replace it quickly. Sep 17 12:43:48 hmm. the display says 640x480@59Hz Sep 17 12:43:55 czr_: that is odd, it just reads from sysfs Sep 17 12:44:07 it does? where from? Sep 17 12:44:17 .26 didn't yet have /sys/dev/{char,block}. Sep 17 12:44:22 mckoan: first one is coldhams lane, the second one is science park, milton road. the postcodes are probably easier for looking up on google maps though. Sep 17 12:44:28 I just backported that from .27 to .26, but mdev -s still doesn't do them. Sep 17 12:44:46 Crofton|work: I created contents in such page :-D Sep 17 12:45:17 czr_: I imagined from /sys/block/* and /sys/char/* but I have never actually checked Sep 17 12:45:54 well, iterating the info from there is error-prone and quite complex. that's why the /sys/dev/ thingy was added in .27. makes bootstrapping the devnodes much easier Sep 17 12:46:06 but, I'll try to hack something together and test it out, no biggie. Sep 17 12:46:17 yeah, I don't think mdev uses /sys/dev yet Sep 17 12:46:29 at least, not in any version I've seen. might be that way in the latest eleet busybox I guess. Sep 17 12:47:07 could try stracing mdev -s, that'd give a clue as to what's wrong Sep 17 12:47:21 I can't get a console on the target ;-) Sep 17 12:47:34 heh, just hack the initscript to run mdev under strace Sep 17 12:47:38 http://pastebin.com/m7304a676 <- this is what /sys/dev/char/ looks like on a PC. very nice thing to iterate. Sep 17 12:48:09 well, I'll do the strace if I fail otherwise (i have an idea I want to try out) Sep 17 12:50:47 ah yes. the reason why the target didn't advance to runlevel 5 was that it didn't have a tty to start getty on Sep 17 12:51:54 (it works now) Sep 17 12:56:06 http://www.freewrt.org/trac/changeset/3708 found this, but it seems ancient. Sep 17 12:58:31 page updated http://wiki.openembedded.net/index.php/Oedem/2009 although I still find it not very useful Sep 17 13:10:00 pb_, what company do you work for? Sep 17 13:15:29 czr_: doh, that seems like it must be a bug in init Sep 17 13:15:42 Crofton|work: www.reciva.com Sep 17 13:16:18 what's up with the abandoned airfield west of cambridge? Sep 17 13:17:11 509 Coldhams Ln? Sep 17 13:19:45 Crofton|work: right Sep 17 13:19:52 which airfield are you thinking of, Bourn? Sep 17 13:20:14 just trying to work out the location :) Sep 17 13:20:28 the abandoned one on the way to the science park Sep 17 13:20:36 if so, I don't think it's actually abandoned: it was a bomber base during world war II and I think it has been used for GA/light aircraft since then Sep 17 13:20:42 obviously an airfiled, but stuff on the runways Sep 17 13:20:48 ah Sep 17 13:20:50 hm, let me have a look at google maps and see if I can figure out which one you are looking at Sep 17 13:20:56 can you give me a grid reference for it? Sep 17 13:22:04 on the a428 Sep 17 13:22:27 http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=citrix&sll=52.248456,0.081968&sspn=0.029375,0.061798&ie=UTF8&ll=52.217494,-0.042229&spn=0.058791,0.123596&t=h&z=13 Sep 17 13:22:56 right, that is bourn airfield Sep 17 13:23:15 http://en.wikipedia.org/wiki/Bourn#RAF_Bourn Sep 17 13:23:36 thanks :) Sep 17 13:24:00 OEDEM will be at 509 Coldhams Ln? Sep 17 13:24:10 most likely, yeah Sep 17 13:24:22 the other location is quite far from town Sep 17 13:24:47 I think they're about the same distance. Sep 17 13:26:32 pb__: is that the same place that the webserver dudes are/were? Sep 17 13:26:57 03Koen Kooi  07org.openembedded.dev * r2f514aa042 10openembedded.git/recipes/ffmpeg/ffmpeg_svn.bb: ffmpeg svn: sync with git version to fix versioning Sep 17 13:27:02 03Koen Kooi  07org.openembedded.dev * r6d3ad5fb21 10openembedded.git/recipes/linux/ (19 files in 4 dirs): linux-omap 2.6.31: add extra EHCI and USB patches from http://arago-project.org/git/people/?p=ajay/omap-usb-driver.git;a=summary Sep 17 13:27:02 03Koen Kooi  07org.openembedded.dev * ra0818d6ec7 10openembedded.git/conf/machine/omap3-touchbook.conf: omap3-touchbook: also generate squashfs files Sep 17 13:28:03 pb__, I might take a better look at it later, trying to build a uclibc version now. Sep 17 13:28:19 pb__: what about Appletree House Bed and Breakfast‎ in Coldhams Lane? Sep 17 13:31:51 pb_, is this correct? Sep 17 13:34:06 http://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=101521096530279421199.000473c5fc6d86d6f952a&ll=52.192838,0.176382&spn=0.00096,0.001931&t=h&z=19 Sep 17 13:34:18 that might help make my other statement make sense Sep 17 13:34:24 anyone can edit the map Sep 17 13:35:57 Crofton|work: pb__ : how can you get there from railway stn? Sep 17 13:38:25 http://www.cambridgeshire.gov.uk/transport/ Sep 17 13:38:31 pb__: looks like it is a B&B http://www.allenbell.co.uk/ Sep 17 13:39:11 Crofton|work: of course, but a few details may be useful Sep 17 13:40:16 we can just form a tent city near venue :-) Sep 17 13:48:29 Crofton|work: nearly, you need to go a couple of hundred metres northwest Sep 17 13:48:53 http://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=101521096530279421199.000473c5fc6d86d6f952a&t=h&ll=52.195256,0.172487&spn=0.000914,0.00239&z=19 Sep 17 13:49:21 mckoan: the citi 1 bus runs nearby, takes about 25 minutes from the rail station Sep 17 13:49:53 failing that, take any bus into the city centre and then take bus 16 which runs right outside our building (but only once per hour) Sep 17 13:49:57 citi 1 is every ten minutes Sep 17 13:50:35 XorA: not sure which webserver dudes you're thinking of. zeus? Sep 17 13:50:39 they were at the science park Sep 17 13:51:02 pb__: yeah zeus, I forgot their name Sep 17 13:51:10 pb__: Ive been to that building Sep 17 13:53:56 ttp://maps.google.com/maps/ms?ie=UTF&msa=0&msid= Sep 17 13:53:56 101521096530279421199.000473c5fc6d86d6f952a Sep 17 13:54:01 do you get the edit button? Sep 17 13:54:30 no Sep 17 13:54:48 * Crofton|work grumbles Sep 17 13:55:00 stupid google maps Sep 17 13:55:36 at least google maps inability to show hills is not an issue in cambridge :-) Sep 17 13:55:43 heh Sep 17 13:55:46 we do have one hill Sep 17 13:55:59 pb__: thats a molehill :-D Sep 17 13:56:38 eneded up walking up a steep nasty hill on sat because I couldnt see it was a hill on the map :-D Sep 17 13:59:19 mckoan: yeah, there are several B&Bs in the area. Sep 17 13:59:43 there is also a holiday inn express a few hundred metres from our office Sep 17 14:00:43 in the centre of town there is a crowne plaza, a devere, and a doubletree. Sep 17 14:01:34 there are a couple of other holiday inns scattered around the city as well, one near the train station and one on the north edge. plus a "premier inn" which has just opened and which I had never heard of before Sep 17 14:02:28 plus various other smaller independent hotels. Sep 17 14:35:24 have a nice rest of the day Sep 17 14:51:23 sakoman: I think the overo branch needs mickey's fix: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=306ae77b3bd17c9a7e04227fc6b7b2d66c264476 Sep 17 14:52:34 cbrake: what are the symptoms with the previous binutils? Sep 17 14:52:56 I've been using the overo brnach and haven't noticed any problems! Sep 17 14:53:18 sakoman: I got a "wrong kernel version" on a clean build yesterday Sep 17 14:53:41 sakoman: not sure if that is what fixed it, but I seem to recall some discussion on #oe about it Sep 17 14:53:43 interesting! I did clean builds of all my images this weekend with no issue! Sep 17 14:54:01 sakoman: indeed, very interesting Sep 17 14:54:08 but I was going to do a merge with oe.dev today anyway, so will pick it up then Sep 17 14:54:23 hopefully it doesn't break my stuff :-) Sep 17 14:54:30 sakoman: :-) Sep 17 14:55:03 I usually lose a day or two f productivity every time I do a merge :-) Sep 17 14:55:20 sakoman: yeah, moving forward is not free! Sep 17 14:55:22 but I wait to push to the overo branch till I am back in business :-) Sep 17 14:55:32 cbrake, my understanding is Angstrom does not use the sane-toolchain stuff Sep 17 14:57:05 Crofton|work: you are correct Sep 17 14:57:18 Crofton|work: sakoman: here is the error message: http://pastebin.ca/1569695 Sep 17 14:57:49 anyone know what causes "FATAL: kernel too old" error messages when building glibc? Sep 17 14:58:19 I think there is a fix for that, but it is a different one Sep 17 14:58:45 * cbrake searches history ... Sep 17 14:59:17 ahh: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=18158e33775356f5d166908d253159b05125a2fb Sep 17 14:59:23 cbrake: wow, that is a new one to me! Sep 17 15:00:01 linux-libc-headers 2.6.31 has the needed patch applied Sep 17 15:00:13 but I have had time to check my build actually works Sep 17 15:00:18 havent Sep 17 15:01:20 c Sep 17 15:02:20 or actually I did accidently check it last night Sep 17 15:02:26 forgot I booted my zoo,m2 Sep 17 15:02:34 that seems like a weird patch. why doesn't angstrom just set OLDEST_KERNEL to 2.6.24? Sep 17 15:03:21 * sakoman wonders why his builds worked Sep 17 15:03:46 yeah, my micro builds seem to work fine as well. Sep 17 15:03:55 I don't quite understand what the issue is that angstrom is trying to solve with that patch. Sep 17 15:04:08 * XorA doesnt either, have to ask koen Sep 17 15:04:16 kind of seems like something else must be broken somewhere but I don't really know what. Sep 17 15:04:44 zecke: good evening Sep 17 15:05:30 some machines set OLDEST_KERNEL would that interfere? Sep 17 15:05:54 distro beats machine Sep 17 15:07:21 still, if that patch makes it work for angstrom, and it isn't broken for anybody else, I guess it isn't worth worrying about. Sep 17 15:09:49 just did a merge with oe.dev, we'll see if it breaks anything for me Sep 17 15:09:57 pb__: the patch works (angstrom/dev/glibc/armv5te) Sep 17 15:10:07 tested two builds Sep 17 15:11:18 ant__: very good Sep 17 15:11:43 * sakoman tested 10 builds on 2 machines, removing tmp first and had no issues prior to the patch Sep 17 15:12:02 we'll see what happens post patch now Sep 17 15:12:59 pb__: 2.6.26 fwiw Sep 17 15:13:56 I really don't like anonymous wikis (or anonymous anything for that matter) http://wiki.openembedded.net/index.php?title=Getting_started&diff=1678&oldid=1671 Sep 17 15:15:13 doh Sep 17 15:15:26 bbl Sep 17 15:16:43 cbrake: its pretty universal feature on wikis, if its not about pr0n its probably wrong Sep 17 15:18:29 XorA: most of the effort on our wiki seems to be cleaning up spam. It seems like it would be a small thing to ask editors to create an account. Sep 17 15:26:00 heh Sep 17 15:26:10 I wonder why someone would make that change Sep 17 15:26:39 I have no problem requiring a login to edit the OE wiki Sep 17 15:26:50 bbl, lunch Sep 17 15:39:18 can i force opkg to install a local package instead of getting a newer version from angstrom? it was working this morning! Sep 17 15:39:35 -force-downgrade doesn't work Sep 17 15:46:22 Could people take a look and ack a pull from our repository? I'm with those changes done locally for long time and want to stop bothering about them and merge them all. Please take a look at https://projetos.ossystems.com.br/git/?p=users/otavio/org.openembedded.dev.git;a=summary Sep 17 16:14:01 otavio: use __always_inline instead of __inline__ what issues do you have without this patch Sep 17 16:14:47 otavio: -fPIC for libgpg-error's CFLAGS Sep 17 16:14:50 looks ok Sep 17 16:16:17 otavio: Sep 17 16:16:18 Avoids overwriting Python's built-in `str' in get_devtable_list Sep 17 16:16:30 is this just a cleanup Sep 17 16:17:59 other ones look ok to me Sep 17 16:24:49 khem: http://git.pokylinux.org/cgit.cgi/poky/log/?h=canadian Sep 17 16:39:00 khem: ld.so doesn't work without always_inline Sep 17 16:39:14 see the logs for this channel, we had a long discussion about it at the time Sep 17 16:43:09 khem, mips ? Sep 17 16:43:21 + uclibc ? Sep 17 16:43:45 without the patch? Sep 17 16:45:29 pb__: it works well here on arm thats why i was wondering Sep 17 16:45:40 it fails on mips, at least, and I think it only works on arm by chance Sep 17 16:47:21 pb__, I had this issue,we debuged it and mario goulard pushed in the patch from the uclibc repository Sep 17 16:47:31 s/pb__/khem Sep 17 16:47:51 the patch was made a little bit after the release...so Sep 17 16:48:00 that's why we have this problem Sep 17 16:52:30 right Sep 17 16:53:57 I think that patch is fine, you can land it in the .dev tree. Sep 17 16:54:05 the gpg-error one is a bit startling. Sep 17 16:57:00 I just ran a build of libgpg-error here and it does seem to be coming out PIC without your patch. If that isn't working for you then it seems like maybe you have a generic libtool malfunction. Sep 17 16:57:26 and, if that's the case, it would be better fixed in libtool rather than patching the individual packages. Sep 17 16:58:01 the image.bbclass one looks fine to me, might be worth asking mickey|fsomeetin to bless it with his python skills Sep 17 16:59:41 x11r7.5, presumably fine though the existence of that whole file seems a bit premature. Sep 17 17:04:09 03Koen Kooi  07org.openembedded.dev * rfd8af199bb 10openembedded.git/recipes/linux/ (5 files in 4 dirs): linux-omap 2.6.31: add some more display fixes Sep 17 17:15:09 khem: uclibc fails on mips Sep 17 17:15:30 khem: yes, str is a cleanup but worth IMO Sep 17 17:16:50 pb__: the 7.5 is nice to have since the pieces that are being tested can be enables and allow for a on going development besed on the new Xorg modules Sep 17 17:16:58 pb__: to avoid duplicated work Sep 17 17:17:17 pb__: gpg-error fails in mips as well Sep 17 17:17:40 right, I'm happy enough with the x11r7.5 thing, it just seems a bit odd to have an include file for a release that doesn't exist yet. Sep 17 17:17:52 regarding the gpg-error thing, as I wrote above it seems like that would be better fixed in libtool. Sep 17 17:18:12 or possibly in gpg-error's use of libtool; which file exactly was getting built as non-pic? Sep 17 17:18:57 pb__: I don't recall anymore Sep 17 17:19:16 pb__: I sent it long time ago and kept it for pushing and never did Sep 17 17:19:31 pb__: well; i droped it for now and then will push the rest then Sep 17 17:19:35 okay. I think it would be worth doing some more investigation before landing that patch in the tree. Sep 17 17:19:43 yes, the others look fine Sep 17 17:20:33 done Sep 17 17:20:37 03Mario Domenech Goulart  07org.openembedded.dev * r8a40ec536f 10openembedded.git/recipes/uclibc/ (2 files in 2 dirs): Sep 17 17:20:37 uClibc: use __always_inline instead of __inline__ Sep 17 17:20:37 Signed-off-by: Otavio Salvador Sep 17 17:20:39 03Otavio Salvador  07org.openembedded.dev * rd96238b177 10openembedded.git/ (8 files in 4 dirs): Sep 17 17:20:42 xf86-video-geode: update to 2.11.4.1 Sep 17 17:20:44 Since it is a bugfix release we updated from 2.11.2 to 2.11.4.1 and Sep 17 17:20:46 also set this as preferred version for the distros using the upcoming Sep 17 17:20:48 Xorg 7.5 release or the 7.4 (updates). Sep 17 17:20:50 Signed-off-by: Otavio Salvador Sep 17 17:20:52 03Otavio Salvador  07org.openembedded.dev * r7daf6b3e17 10openembedded.git/recipes/pcmanfm/ (files/auto_mount.patch pcmanfm_0.5.bb): Sep 17 17:20:55 pcmanfm: fix automounting support Sep 17 17:20:57 Signed-off-by: Otavio Salvador Sep 17 17:21:01 03Otavio Salvador  07org.openembedded.dev * r4fdfbf9af2 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.5.inc: Sep 17 17:21:04 preferred-xorg-versions-X11R7.5.inc: bump xf86-video-intel to 2.6.3 Sep 17 17:21:06 Signed-off-by: Otavio Salvador Sep 17 17:21:10 03Mario Domenech Goulart  07org.openembedded.dev * r55f42a3dd5 10openembedded.git/classes/image.bbclass: Sep 17 17:21:15 Avoids overwriting Python's built-in `str' in get_devtable_list Sep 17 17:21:17 Signed-off-by: Otavio Salvador Sep 17 17:21:30 and thx :-) Sep 17 17:41:10 heh so i rm'd deploy/uclibc/ipk/ppc.../* Sep 17 17:41:18 to try to rebuild everything Sep 17 17:41:30 but staging is/was still populated Sep 17 17:41:44 in the future, is there a better way to clean that up for a rebuild? Sep 17 18:07:22 03Koen Kooi  07org.openembedded.dev * rb4aa04a13f 10openembedded.git/recipes/ti/gstreamer-ti_svn.bb: gstreamer-ti: only patch in omapfb for armv7a Sep 17 18:09:04 03Koen Kooi  07org.openembedded.dev * rfde321de55 10openembedded.git/recipes/u-boot/u-boot.inc: u-boot: if there's a fw-env in SRC_URI build and install tools as well Sep 17 18:09:05 03Koen Kooi  07org.openembedded.dev * r8d8b1db7fc 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3: switch to FLIP wsegl Sep 17 18:09:06 03Koen Kooi  07org.openembedded.dev * r6092bf2816 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add omap3-touchbook support Sep 17 18:20:43 Gnutoo: which version of gcc were you using and was it for mips only ? Sep 17 18:20:58 khem, yes mips only Sep 17 18:21:07 I'll check the gcc version Sep 17 18:21:11 Gnutoo: the change is semantically same for compiler to unless you had a buggy compiler I would not expect any changes Sep 17 18:21:18 khem ^^ any quick suggestions? i wanted to rebuild all to make sure deps are being used correctly etc Sep 17 18:21:20 in generated code Sep 17 18:21:33 now im running into a bunch of problems because i rm'd the ipk without cleaning up staging Sep 17 18:22:00 you can bitbake -b recipe.bb -c clean Sep 17 18:22:04 yea Sep 17 18:22:07 then bitbake recipe Sep 17 18:22:11 yes... Sep 17 18:22:12 it should get the deps Sep 17 18:22:14 maybe 4.2.4 not shure Sep 17 18:22:23 what if i rm'd staging? Sep 17 18:22:43 i mean, how do i completely rebuild everything except the toolchain Sep 17 18:22:54 -native -cross etc. Sep 17 18:22:58 m4t: if you have packaged staging then it should be able to reconstruct staging from ipks Sep 17 18:23:40 khem: we tested with many versions while debugging it. 4.2.4, 4.3. and other that I don't recall. mario-goulart do you remember which versions we tested? Sep 17 18:23:41 m4t: you mean just the target recipes ? Sep 17 18:24:01 tmp/deploy/uclibc/ipk/ppc405 is what i rm'd Sep 17 18:24:07 and khem, yea target recipes Sep 17 18:24:20 i pretty much rebuilt everything Sep 17 18:24:25 * mario-goulart reads the backlog Sep 17 18:24:37 but i got rid of libgcc and libssp too ;/ Sep 17 18:24:58 and now gettext is mising libiconv headers (oh no) Sep 17 18:25:26 i might have it fixed Sep 17 18:25:47 the only thing is....i'd much rather have it link, during compilation, to the .ipk that will be installed on my target Sep 17 18:26:10 rather than using the stray libs and headers etc. that remained after i removed the .ipk from deploy/uclibc/ipk/ppc405 Sep 17 18:26:15 otavio: the patch is good actually I am more intested in the fact that it could have smeared on another problem Sep 17 18:27:15 khem, otavio you are talking about the uclibc patch (use __always_inline instead of __inline__)? Sep 17 18:27:18 what has happened is that a package will build, because it finds the libaries/headers, but when it comes time to build the actual .cpio image, it craps out, because the .ipk that originally populated staging is missing Sep 17 18:27:32 mario-goulart: yes Sep 17 18:28:02 khem, mario-goulart, is the one who commited the patch Sep 17 18:28:11 hi marcosmamorim Sep 17 18:28:12 oops Sep 17 18:28:17 m4t: I think your build became inconsistent I would say rebuilt all Sep 17 18:28:20 hi mario-goulart Sep 17 18:28:35 Hi Gnutoo Sep 17 18:28:42 khem: I've tested it with gcc 4.3.2, 4.1.2 and 4.2.4. Sep 17 18:28:45 heh khem, when you say 'all', do you also imply my cross compiler toolchain and native utilities? Sep 17 18:29:05 m4t: to be safe yes Sep 17 18:29:13 awesome Sep 17 18:29:18 mario-goulart: what was original problem Sep 17 18:29:54 well thats no problem. its mostly a deterministic build, but said build requires me to chpax a few things before they wind up in staging etc. Sep 17 18:30:23 i should really enable pax_softmode, would make things like this a bit easier Sep 17 18:30:24 khem: dynamicaly linked applications segfault on mips when using uclibc Sep 17 18:31:27 mario-goulart: ok which means the function did not get inlined and a call was made before ld could do function calls Sep 17 18:31:33 which is usually the case Sep 17 18:32:23 mario-goulart: However __inline__ is defined same as __always_inline Sep 17 18:32:34 so why it did not get propagated in mips Sep 17 18:32:37 hrm khem, well, that might enable me to try adding that syscall udev > 124 needs Sep 17 18:32:46 ie. uclibc/kernel header patch Sep 17 18:32:56 yes are you on arm ? Sep 17 18:33:35 oh, no Sep 17 18:33:40 i could try to port it over to ppc Sep 17 18:33:44 well then you dont worry about it Sep 17 18:34:03 03Thomas Zimmermann  07shr/import * re02daee84e 10openembedded.git/ (2 files in 2 dirs): Sep 17 18:34:03 Blueman: Add depencies (startup-notification 0.9 from org.oe.dev) Sep 17 18:34:03 Signed-off-by: Klaus Kurzmann Sep 17 18:34:04 03Thomas Zimmermann  07shr/import * r999a29eaa1 10openembedded.git/recipes/vagalume/vagalume_0.7.1.bb: Sep 17 18:34:04 Vagalume: Depend on gst-plugin-mad only if ENTERPRISE_DISTRO is not set Sep 17 18:34:06 I thought ppc already wired the ppoll and pselect syscalls Sep 17 18:34:08 Signed-off-by: Klaus Kurzmann Sep 17 18:34:10 03Martin Jansa  07shr/import * r73dc33009c 10openembedded.git/ (18 files in 9 dirs): Sep 17 18:34:10 but I may be mistaked Sep 17 18:34:13 Synchronize subversion stuff with oe.org.dev compiled fine now. Sep 17 18:34:15 Signed-off-by: Klaus Kurzmann Sep 17 18:34:17 03Thomas Zimmermann  07shr/import * r7b2c538f9a 10openembedded.git/ (conf/checksums.ini recipes/blueman/blueman_1.10.bb): Sep 17 18:34:22 Blueman: add reciepe (just for development, because runtime depencies aren't fullfilled) Sep 17 18:34:24 Signed-off-by: Klaus Kurzmann Sep 17 18:34:36 * RP hugs his new SDK tarballs Sep 17 18:34:47 i did run into the error where udev spewed a bunch of logs related to one syscall Sep 17 18:34:52 lets see Sep 17 18:35:24 ./udev/udevd.c:fdcount = ppoll(pfd, nfds, NULL, &orig_mask); Sep 17 18:35:30 RP: I havent looked at the patches yet. I plan to see them later today Sep 17 18:35:32 i think that is the line from udev-141 Sep 17 18:35:53 RP: :-) Sep 17 18:36:26 khem: Its taken a few core changes particularly the layout stuff but I'm really pleased with the result. Id be intersted in come other eyes on it... Sep 17 18:36:47 RP: yeah and we should get it into OE as well Sep 17 18:37:04 RP: those are patches for SDK producing? Sep 17 18:37:17 otavio: yes Sep 17 18:37:28 khem: I actually haven't checked how they are defined. It is weird that they are the same. Probably there are some redefinition specific for mips? Sep 17 18:38:06 mario-goulart: include/sys/cdefs.h defines __always_inline Sep 17 18:38:17 and __inline__ is gnu extension which is same as __inline Sep 17 18:38:27 hmmmm Sep 17 18:38:37 khem: Yes, I'd love to see this in OE. I've kept everything in a new namespace which should help integration Sep 17 18:39:13 03Stefan Schmidt  07org.openembedded.dev * r3ecdded38a 10openembedded.git/conf/distro/include/ (shr-autorev-unstable.inc shr-autorev.inc): shr-autorev*: Soem auto and some fixed revs for upcoming SHR merge (from SHR) Sep 17 18:39:14 03Stefan Schmidt  07org.openembedded.dev * r80c55c2574 10openembedded.git/recipes/shr/e-wm-theme-illume-shr_git.bb: e-wm-theme-illume-shr: Add recipe (from SHR) Sep 17 18:39:15 03Stefan Schmidt  07org.openembedded.dev * r0393c7cc15 10openembedded.git/recipes/shr/e-wm-sysactions-shr_git.bb: e-wm-sysactions-shr: Add recipe (from SHR) Sep 17 18:39:17 03Stefan Schmidt  07org.openembedded.dev * ra318f679fc 10openembedded.git/recipes/shr/libphone-utils_git.bb: bphone-utils: Add recipe (from SHR) Sep 17 18:39:20 03Stefan Schmidt  07org.openembedded.dev * re8622747c6 10openembedded.git/recipes/shr/ (22 files in 2 dirs): initscripts-shr: Add SHR initscripts (from SHR) Sep 17 18:39:23 03Stefan Schmidt  07org.openembedded.dev * ra86973493b 10openembedded.git/recipes/shr/alsa-scenarii-shr_git.bb: alsa-scenarii-shr: Add recipe (from SHR) Sep 17 18:39:26 03Stefan Schmidt  07org.openembedded.dev * r08678a65e4 10openembedded.git/recipes/shr/etk-theme-shr_git.bb: etk-theme-shr: Add recipe (from SHR) Sep 17 18:39:31 03Stefan Schmidt  07org.openembedded.dev * r2ff4462e97 10openembedded.git/recipes/shr/e-wm-menu-shr_git.bb: e-wm-menu-shr: Add recipe (from SHR) Sep 17 18:39:34 03Stefan Schmidt  07org.openembedded.dev * r0c186bfb52 10openembedded.git/recipes/efl1/ (13 files): illume-keyboard*: A bunch of illume keyboard layouts. (from SHR) Sep 17 18:40:13 RP: where are the patches available? Sep 17 18:40:39 re Sep 17 18:41:04 khem: the end result is that this is a backport from a uclibc upstream fix. So it is much better to discuss it on their ml then in OE ;-) Sep 17 18:41:20 otavio: http://git.pokylinux.org/cgit.cgi/poky/log/?h=canadian Sep 17 18:41:22 khem: they did it in their git master and we backported it Sep 17 18:41:29 otavio: Undergoing testing atm... Sep 17 18:41:49 otavio: yes I know but I wanted a better understanding Sep 17 18:42:45 khem: it took a mounth for us to get it working ;-) Sep 17 18:44:19 RP: are you intending to make a branch for people play with it in OE? Sep 17 18:44:48 otavio: I don't think I've got the time for that :/ Sep 17 18:45:14 otavio: I see Sep 17 18:45:20 otavio: We'll see but I'm extremely sort of time atm Sep 17 18:45:48 RP: :( Sep 17 18:46:12 * otavio don't intend to get used to poky to play with it :-) Sep 17 18:46:22 RP: ok Sep 17 18:46:27 otavio: Poky and OE have the same core ;-) Sep 17 18:55:49 otavio: mario-goulart I see that the fix correctly now Sep 17 18:56:12 the fix is correct Sep 17 18:57:07 uclibc is defining it __GNUC_PREREQ as minimum supported version so basically it will be defined to __inline __attribute__ ((__always_inline__)) Sep 17 18:57:11 which makes sense Sep 17 18:57:20 push it to .dev Sep 17 19:01:33 RP: this canadian branch seems to be long lasting one Sep 17 19:02:02 khem: hmm, its not intended to be Sep 17 19:02:16 khem: How do you mean long lasting? Sep 17 19:03:02 RP: I mean will you keep it alive or merge is to poky trunk Sep 17 19:03:12 khem: It will be merged back soon Sep 17 19:03:18 ok Sep 17 19:03:27 Remove layout_* variables I like it Sep 17 19:04:57 khem, otavio: http://pastebin.ca/1569976 is the email I just sent to the list Sep 17 19:05:10 (pasted here since I know what the list repsonse time is like :/ ) Sep 17 19:06:18 go for it Sep 17 19:06:29 03Stefan Schmidt  07org.openembedded.dev * r83688479d4 10openembedded.git/recipes/efl1/e-wm-illume-dict-pl_git.bb: e-wm-illume-dict-pl: Polish dict for the illume keyboard (from SHR) Sep 17 19:06:30 03Stefan Schmidt  07org.openembedded.dev * rdd9df493e1 10openembedded.git/recipes/shr/e-wm-theme-illume-sixteen_git.bb: e-wm-theme-illume-sixteen: Add recipe (from SHR) Sep 17 19:06:30 03Stefan Schmidt  07org.openembedded.dev * r60a6249237 10openembedded.git/recipes/shr/e-wm-theme-illume-niebiee_git.bb: e-wm-theme-illume-niebiee: Add recipe (from SHR) Sep 17 19:06:32 03Stefan Schmidt  07org.openembedded.dev * rd56ffbe90a 10openembedded.git/recipes/shr/ (2 files): elementary-theme-*: Elementary themes (from SHR) Sep 17 19:07:43 RP: SDK_ARCH is same as HOST_ARCH in logic so I think you could make it SDK_HOST_ARCH Sep 17 19:08:39 pb__: Are these nominations to go to the list or to you privately? When you say arrange a vote, is that at OEDEM or are we adding internet members to the e.V. first? Sep 17 19:09:06 RP: internet voting should be allowed at the EGM Sep 17 19:09:09 khem: True, I just followed what OE already has for that Sep 17 19:09:22 RP: thats the whole purpose of the EGM Sep 17 19:09:23 XorA: ah, true Sep 17 19:10:04 ~curse libsdl Sep 17 19:10:05 May you be reincarnated as a Windows XP administrator, libsdl ! Sep 17 19:10:07 XorA: is info available for internet voting somewhere on wiki Sep 17 19:10:39 khem: no, I guess someone needs to agenda it at the EGM Sep 17 19:11:36 03Martin Jansa  07shr/import * r4220590e12 10openembedded.git/ (7 files in 3 dirs): Sep 17 19:11:36 Rebased glamo patch from Andrzej Zaborowski http://repo.or.cz/w/mplayer/glamo.git (just -vo glamo without vidix driver stub), bump mplayer revision Sep 17 19:11:36 Signed-off-by: Klaus Kurzmann Sep 17 19:11:37 RP: I think you could rename crosssdk.bbclass to cross-sdk.bbclass and nativesdk.bbclass -> native-sdk.bbclass Sep 17 19:12:11 and cross-canadian.bbclass could be called canadian-cross-sdk.bbclass Sep 17 19:13:07 canadian-cross does nt deal with SDK only I guess so canadian-cross.bbclass is ok Sep 17 19:13:55 khem: cross-sdk causes a namespace clash with existing gcc/binutils recipe names and I wished to avoid it ;-) Sep 17 19:15:38 I think you can use the existing ones with your work Sep 17 19:15:45 who will use them after your patch Sep 17 19:16:15 khem: right, it just allows easier merging Sep 17 19:16:24 ok Sep 17 19:16:27 makes sense Sep 17 19:22:15 RP: task-sdk-host.bb has mixture of -nativesdk and -cross-canadian packages Sep 17 19:22:45 why is that Sep 17 19:22:49 http://git.pokylinux.org/cgit.cgi/poky/commit/?h=canadian&id=cd1e4062a813ae91586d4baaafc252a8ba910831 Sep 17 19:23:33 khem: They all run on SDK_ARCH so why not? Sep 17 19:24:00 khem: We want things like pkgconfig as well as our canadian compiler Sep 17 19:24:45 RP: so why not have pkgconfig-cross-canadian Sep 17 19:24:59 khem: pointless ;-) Sep 17 19:25:09 yeah Sep 17 19:25:44 pkgconfig-nativesdk is already a canadian-cross Sep 17 19:27:38 RP: in the same commit above you removed gdb-cross-nativesdk but did not add gdb-cross-canadian Sep 17 19:28:09 khem: gdb is broken atm, thanks for the reminder! :) Sep 17 19:28:45 I think the patches look sane to me Sep 17 19:29:06 khem: Imagine how users might install an sdk - a core (nativesdk), a target specific part (gcc/bintutils/gdb) and a target rootfs Sep 17 19:29:33 khem: I like the idea of at least being able to make that split in theory Sep 17 19:29:39 khem: cool :) Sep 17 19:30:05 RP: why would one need tools on target I can understand libgcc libstdc++ etc. Sep 17 19:30:39 khem: target specific as in cross-canadian tools Sep 17 19:30:47 ah I see Sep 17 19:31:20 for users host arch and target arch are what they care Sep 17 19:31:30 build_arch is only for builders Sep 17 19:31:35 like oe and poky Sep 17 19:31:38 khem: right Sep 17 19:31:59 khem: The SDK also includes its own glibc now which is an improvement really Sep 17 19:32:13 yes saw that Sep 17 19:32:14 no more strange glibc compatibility issues... Sep 17 19:32:43 khem: Merging with OE wise, I worry about the layout changes Sep 17 19:32:55 If we can get that in, the rest is easy... Sep 17 19:33:21 RP: yeah but I think that change should go first if it be Sep 17 19:33:33 then sdk changes may follow Sep 17 19:33:37 khem: right Sep 17 19:33:49 right now .dev is in good shape relatively Sep 17 19:34:00 so its best time for you to get your stuff in if you like Sep 17 19:34:07 I can help in testing it out Sep 17 19:34:35 khem: right. Time wise I'm going to hit a wall at the end of this week with travel though :( Sep 17 19:34:45 * RP has been rushing to at least get it into poky Sep 17 19:35:01 I see Sep 17 19:38:12 RP: you can push Remove layout_* variables patch Sep 17 19:38:19 and we can stabilize it on .dev Sep 17 19:38:33 I think micro changes the layout Sep 17 19:38:50 so that will need to be handled Sep 17 19:39:07 khem: I'll see if I can massage it to fit OE but no promisies time wise :/ Sep 17 19:39:43 ok Sep 17 19:50:00 can someone run bitbake openocd-native. It fails during configure on my x86 32-bit 9.04. Sep 17 19:54:23 actually, it's libftdi Sep 17 19:54:42 whats the error Sep 17 19:55:04 03Koen Kooi  07org.openembedded.dev * r62b5c01bde 10openembedded.git/ (conf/checksums.ini recipes/gstreamer/gst-rtsp_0.10.4.bb): Sep 17 19:55:04 gst-rtsp: add 0.10.4 Sep 17 19:55:04 * vala and python binding haven't been enabled, they most likely require some patching Sep 17 19:55:05 03Koen Kooi  07org.openembedded.dev * r2d899b917c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev Sep 17 19:55:46 avoid those merge messages in org.openembedded.dev Sep 17 19:55:53 history folks Sep 17 19:59:57 khem: Hi. Do you mean we can avoid merges to appear in GIT? Sep 17 20:02:33 yes Sep 17 20:02:52 dont push directly from oven Sep 17 20:03:17 nobody is interested to know about your local merges Sep 17 20:03:28 it clutters the history Sep 17 20:04:57 I found rebase very powerful Sep 17 20:05:12 and I hardly use git merge Sep 17 20:05:25 usually git pull will merge Sep 17 20:06:29 git fetch;git reabase origin/org.openembedded.dev Sep 17 20:06:56 khem: ah, I never use git merge. I use --rebase. I'm a GIT noob, so this is all by pure accident :-) Sep 17 20:07:48 you are on right path :) Sep 17 20:08:01 some one should tell koen Sep 17 20:08:12 I see many merge messages from him Sep 17 20:08:31 I also did this for sometime but then I figured it otu Sep 17 20:08:58 git pull --rebase also works for me Sep 17 20:21:20 cbrake: yes Sep 17 20:21:55 my command reminds me always that I am rebasing to right remote branch :) Sep 17 20:23:06 nod, explicit is good somethings Sep 17 20:26:15 it seems my son pulled the laptop cable at home I cant login anymore Sep 17 20:29:01 qgit is also useful for looking at history Sep 17 20:42:27 03Stanislav Brabec  07org.openembedded.dev * r33cee05869 10openembedded.git/recipes/autoconf/ (6 files in 4 dirs): Sep 17 20:42:27 autoconf: Fixed calling of perl and m4: Sep 17 20:42:27 * removed path_prog_fixes.patch Sep 17 20:42:27 * set needed ac_cv_* variables for non-native builds Sep 17 20:42:27 * depend on perl Sep 17 20:42:29 * for more see http://thread.gmane.org/gmane.comp.handhelds.openembedded/26476 Sep 17 21:00:45 03Graeme Gregory  07org.openembedded.dev * rb0a80126c9 10openembedded.git/recipes/libsdl/ (files/libsdl-1.2.11-pagesize.patch libsdl-x11_1.2.11.bb): libsdl-x11_1.2.11.bb : remove asm/page.h as its no longer there Sep 17 21:06:33 03Martin Jansa  07shr/import * r3b1f42c691 10openembedded.git/recipes/mplayer/files/ (configh configmak): Sep 17 21:06:33 Fix mplayer build with HAVE_NEON 0 Sep 17 21:06:33 Signed-off-by: Klaus Kurzmann Sep 17 21:23:46 03Graeme Gregory  07org.openembedded.dev * r0159d8fb1e 10openembedded.git/recipes/mplayer/files/pld-onlyarm5-svn.patch: mplayer/files/pld-onlyarm5-svn.patch : refresh for newest svn Sep 17 21:24:59 03Stefan Schmidt  07org.openembedded.dev * r0bea79bae6 10openembedded.git/recipes/shr/frameworkd-config-shr_git.bb: frameworkd-config-shr: SHR specific frameworkd config (from SHR) Sep 17 21:25:10 03Stefan Schmidt  07org.openembedded.dev * r4884db8974 10openembedded.git/recipes/shr/ (3 files): libframeworkd-phonegui*: Abstraction libs for fso and efl (from SHR) Sep 17 21:28:11 ant__: hey, did you ping? Sep 17 21:29:34 03Martin Jansa  07shr/import * r45035c57c3 10openembedded.git/contrib/source-checker/bump.preferred-xorg-versions-live.sh: Sep 17 21:29:34 Add script for bumping xorg revisions to contrib Sep 17 21:29:34 Signed-off-by: Klaus Kurzmann Sep 17 21:29:37 03Martin Jansa  07shr/import * re62a3bcef8 10openembedded.git/ (170 files in 18 dirs): Sep 17 21:29:37 Latest xorg stuff and Thomas White's KMS glamo driver Sep 17 21:29:38 Signed-off-by: Klaus Kurzmann Sep 17 21:29:40 03Martin Jansa  07shr/import * r51d6c31e50 10openembedded.git/conf/distro/include/shr-om-gta02-kms.conf: Sep 17 21:29:43 Fix glamo-kms revision Sep 17 21:29:45 Signed-off-by: Klaus Kurzmann Sep 17 21:29:47 03Martin Jansa  07shr/import * r700cdd73cd 10openembedded.git/contrib/source-checker/bump.preferred-xorg-versions-live.sh: Sep 17 21:29:50 Use relative paths in xorg bumping script Sep 17 21:29:52 Signed-off-by: Klaus Kurzmann Sep 17 21:29:54 03Martin Jansa  07shr/import * rbb77c14faf 10openembedded.git/conf/distro/shr.conf: Sep 17 21:29:57 Enable glamo KMS for distribution Sep 17 21:29:59 Signed-off-by: Klaus Kurzmann Sep 17 21:30:03 03Martin.Jansa  07shr/import * r5617c4ec96 10openembedded.git/recipes/xorg-xserver/xserver-xorg_git.bb: Sep 17 21:30:08 Disable dmx for git-master Sep 17 21:30:10 Signed-off-by: Klaus Kurzmann Sep 17 21:38:51 Argh, why do we keep SRCREV in a single file, while we have revision dependent patches sitting in the recipe subdirectories?? Sep 17 21:39:17 hmm Sep 17 21:39:33 do you mean sane-srcrev.inc Sep 17 21:40:26 khem: yes, it's just I sometimes do not understand why we generalize so much hiding away the detailed dependencies. Sep 17 21:40:38 cant say Sep 17 21:40:52 I thought it was better to decide such things in recipes Sep 17 21:41:16 me neither; probably the reasoning behind this design decision is hard to track back. Sep 17 21:41:47 khem: btw, I need to unbreak eglibc for angstrom/arm: http://www.pastebin.ca/1570139 Sep 17 21:42:21 khem: that's my proposed fix, although koen says he's working on something different, so I'll wait for his idea. Sep 17 21:42:24 get rid of the second assignment Sep 17 21:42:54 khem: why? It's an appending assignment (.=_ Sep 17 21:43:01 .= Sep 17 21:43:15 I think angstrom should use include sane-toolchain files Sep 17 21:43:34 instead of angstrom-*.inc Sep 17 21:43:47 khem: sane-toolchain? hmm, I missed that. Sep 17 21:44:17 look in conf/distro/include on .dev Sep 17 21:44:20 khem: but angstrom does not want to change toolchain when micro/minimal do and vice versa Sep 17 21:44:45 you can override Sep 17 21:45:03 in angstrom distro file after including sane toolchain Sep 17 21:45:40 khem: as angstrom existed first you could say the reverse as well Sep 17 21:46:01 XorA: idea is credited to angstrom Sep 17 21:46:07 I see problems because too many people fiddling in it for their cases Sep 17 21:46:12 but angstrom is a disto like others Sep 17 21:46:20 and sanetoolchain is more common term Sep 17 21:46:24 except we do not like breakage :) Sep 17 21:46:38 khem: the very idea that sane-toolchain is sane is broken Sep 17 21:47:04 why do u think so Sep 17 21:47:08 Crofton|work: fiddling for their cases is what's needed to get cases added, errors get made in .dev. Sep 17 21:47:26 khem: because it assumes too much distro knowledge Sep 17 21:47:34 khem: for example the thumb policy Sep 17 21:48:15 that agreed can be moved to respective distros Sep 17 21:49:14 its like a little helper that can be readily used by distros Sep 17 21:49:23 personally I think toolchain is a distro choice, not an OE choice Sep 17 21:49:43 and as angstrom overides a good portion of that file, kind of pointless Sep 17 21:49:52 yes everything is eventually a distro/machine choice Sep 17 21:50:23 its just abstracting common parts out Sep 17 21:50:32 and if needed they can be overridden Sep 17 21:50:35 but even the choice of gcc is not common Sep 17 21:50:45 all use gcc so far Sep 17 21:50:52 its just the version is different Sep 17 21:51:05 sane toolchain just says that this version I have it tested Sep 17 21:51:10 03Koen Kooi  07org.openembedded.dev * r5a790b1f8e 10openembedded.git/conf/distro/include/angstrom-eglibc.inc: angstrom-eglibc: fix eabi target os assignment Sep 17 21:51:23 khem: overrides mean that if the default changes the change propagates. Angstrom doesn't want that Sep 17 21:51:32 exactly Sep 17 21:52:03 took me personally a long time to test the reliability of the toolchains we use Sep 17 21:52:18 unfortunately some folks started not to use sane-srcrevs.inc anymore, that's all i know. just continue using it Sep 17 21:52:25 RP: doesn't matter. I was expecting people to send them to me privately, but if you want to copy the list as well then that's fine. Sep 17 21:53:32 denix: reping Sep 17 21:54:19 RP: eventually its like a pure virtual function in C Sep 17 21:54:21 C++ Sep 17 21:54:49 every distro inheriting need to provide its own implementation Sep 17 21:55:03 may be that analogy is better Sep 17 21:56:54 ant__: pong Sep 17 21:57:17 pb_: ok, I don't see any reason not to cc the list really... Sep 17 21:57:40 RP: XorA probably moving version choices out to distro files is not a bad idea Sep 17 21:58:18 RP: righto Sep 17 21:58:47 khem, rp, xora: but then there is even more dependency between the SCM versions and the OE-locally kept patches against them. Sep 17 21:59:39 mickey|fsomeetin: a change to this file ended up a full reparse Sep 17 22:00:00 that was a PITA everytime you bumped a rev Sep 17 22:00:21 likewise: There was a move to mark patches as to which versions of the scm they apply to Sep 17 22:00:30 works well for svn, git is just a pain Sep 17 22:00:49 RP: you mean the mindate maxdate stuff Sep 17 22:00:50 although I did add something to poky so you could only apply a patch against a given revision Sep 17 22:00:54 likewise: I think your on a different subject with a similar name Sep 17 22:01:04 khem: and minrev, maxrev, rev and notrev :) Sep 17 22:01:27 RP: ok git defeats it Sep 17 22:01:47 khem: rev= is as good as I can come up with for that Sep 17 22:02:47 XorA: well actually this is coming full circle with the previous topic. Sep 17 22:03:05 Hmm, I can't change the default linker with this toolchain. Time to hack gcc I guess Sep 17 22:03:10 pb_: mickey|fsomeetin I think we should move out the toolchain versions out of sanetoolchain file into micro and minimal confs Sep 17 22:03:18 about how to match the patches against the revision stuff we centralized away from the patches themselves Sep 17 22:04:25 khem: what would that get us? Sep 17 22:04:51 mickey|fsomeetin: toolchains are very much distro policy Sep 17 22:04:59 I wish it were otherwise Sep 17 22:05:01 RP: I guess you could do something with git rev-list that would let you say "commit is an [ancestor|descendant] of the current version". Sep 17 22:05:01 mickey|fsomeetin: moral victory if angstrom also starts to use it Sep 17 22:05:38 RP: sane-toolchain is part of distro config only Sep 17 22:05:49 pb_: Yes, I guess we can know that at patch time. Assuming we run the commands on the repo directory instead of the workdir Sep 17 22:05:54 you could mark the rev the patch applies with then get OE to automatically rebase the patch in :-) Sep 17 22:06:05 or throw up git mergtool on failure :-) Sep 17 22:06:20 i think we should codify best distro knowledge into something that is useful for more than just one distro Sep 17 22:06:29 that's why sane-toolchain.inc has been born in the first place Sep 17 22:06:48 apparantly it's hard to get all these configs right Sep 17 22:07:16 mickey|fsomeetin: Its hard to get everyone to agree on them, or test version increments on all combinations Sep 17 22:07:41 RP: the combinations quickly tend to infinity Sep 17 22:07:45 mickey|fsomeetin: You bump gcc to 4.4, does that break arm? mips? x86_64? Sep 17 22:07:48 that's the reason why it's not the default Sep 17 22:07:54 but rather included by some distros Sep 17 22:07:57 while others do not include it Sep 17 22:07:58 so=? Sep 17 22:08:14 mickey|fsomeetin: So its unlikely to ever be included by more than one distro Sep 17 22:08:16 we could argue if it was included from bitbake.conf Sep 17 22:08:24 only distros with ~= aims Sep 17 22:08:53 mickey|fsomeetin: I'm just saying a general toolchain set of confs is very hard to do :( Sep 17 22:09:06 yes Sep 17 22:09:09 i don#t doubt that Sep 17 22:09:17 angstrom seems to have a good hand at that Sep 17 22:09:27 that's why i outfactored their settings into a dedicated file back then Sep 17 22:09:36 RP: yes agreed however this is not mandatory distro can chose the versions Sep 17 22:09:37 to be useful for more distros Sep 17 22:09:42 with similar aims, yes Sep 17 22:11:54 i'm afraid i can't quite follow why we're discussing about that Sep 17 22:12:43 if you're offended about the name, rename it Sep 17 22:12:49 mickey|fsomeetin: angstrom is sufferring from a problem for TARGET_OS that I solved for distros including sane toolchain Sep 17 22:13:28 thats where it started :) Sep 17 22:13:46 i see, i'm afraid you need to change angstrom then, since obviously there's political issues here preventing angstrom to use something i created . Sep 17 22:14:00 even if it came from there Sep 17 22:14:01 *shrug* Sep 17 22:14:02 oh Sep 17 22:14:19 * khem likes to stay out of politics Sep 17 22:14:22 * mickey|fsomeetin too Sep 17 22:14:26 this is what the problem is 99% of that file is invalid for angstrom Sep 17 22:14:46 can we outfactor the 1% of helpful stuff? Sep 17 22:14:52 but some people insist on trying to start political arguments Sep 17 22:15:02 bummer. whom? Sep 17 22:15:19 mickey|fsomeetin: you just did! Sep 17 22:15:24 heh Sep 17 22:15:24 gah, come on guys... Sep 17 22:15:36 XorA: I think its quite useful even for angstrom you need to override toolchain versions and thumbness Sep 17 22:15:58 what else is conflicting with angstrom Sep 17 22:15:59 khem: I think the bottom bit looks very useful, the top half not so Sep 17 22:16:14 Is this on the agenda at OEDEM? Can we lock the parties in a room and not let you out until a truce is called? :) Sep 17 22:16:20 khem: which is pretty much the split between versions and the abi stuff Sep 17 22:16:32 XorA: top half can be overridden in angstrom.conf Sep 17 22:17:13 XorA: the top half is just a fallback for lazy distros who dont have set rigid requirements on toolchain versions Sep 17 22:17:33 khem: I am against overiding and overiding and overriding as like C++ its an unreadable mess Sep 17 22:18:04 XorA: well its a design thing alternative is you copy and copy Sep 17 22:18:24 khem: that is not so bad in all cases Sep 17 22:18:49 there is a limit to re-use Sep 17 22:18:49 yes sometimes you have a fix which needs to then copies over to all places Sep 17 22:18:59 XorA: yes I agree Sep 17 22:19:30 khem: its 23:20 and Im working on some stuff to help someone learn OE, maybe when Ive got a spare minute I might look again Sep 17 22:19:44 but I guess we are not over overriding in context of sane toolchain Sep 17 22:20:07 XorA: sure no problem let me know if this can be improved Sep 17 22:22:23 Actually I want to add the eglibc customizations which will be controlled by variables settable by distros Sep 17 22:22:30 sounds good to me Sep 17 22:23:02 e.g. if a distro says I dont care about versioning sysbols Sep 17 22:23:16 I think from def detect_arm_abi (d): downwards is truely generic, everything else is distro Sep 17 22:23:41 http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/option-groups.def?rev=8712&view=markup Sep 17 22:23:53 these are available knobs Sep 17 22:29:41 03Stanislav Brabec  07org.openembedded.dev * r698ae87ee4 10openembedded.git/recipes/libtool/ (16 files): libtool: Use more clean way to set ac_cv_path_* variables. Never load libtool.inc twice. Sep 17 22:52:07 03Graeme Gregory  07org.openembedded.dev * r4997a9ed43 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into org.openembedded.dev Sep 17 22:52:18 03Omar Barron  07org.openembedded.dev * ra2b8a408e9 10openembedded.git/recipes/linux/ (2 files in 2 dirs): Sep 17 22:52:18 linux-omap-zoomsync_2.6.31.bb : added new kernel for omapzoom2 Sep 17 22:52:18 Move to linux-omap kernel TI sync at Sep 17 22:52:18 git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git Sep 17 22:52:20 Signed-off-by: Omar Barron Sep 17 23:56:39 http://blog.aurel32.net/?p=47 nice thigs Sep 17 23:56:50 about eglibc :) Sep 18 00:00:52 khem: Did they switch in the end? Sep 18 00:34:23 Haha, Ulrich Drepper is a tool... Sep 18 00:35:03 does this mean eglibc will be a proper fork of glibc? I would love that Sep 18 00:44:54 grg: It always has been. Sep 18 00:45:30 really? i thought it was just a repackaging of the same shit Sep 18 00:45:36 but good to know Sep 18 00:47:01 Well they have always strived to be api compatible, with extras for systems with Ulrich though were useless(read: anything other then x86). Sep 18 00:48:44 So yeah, you can basically build eglibc in a way that it works exactly the same as if you pulled from Ulrich. In that sense you are correct, it is the same but a different package. However its only as different as you want it to be. Sep 18 00:49:12 any chance for strlcpy and friends in eglibc then? Sep 18 00:51:27 I am not familar with it, however if its put together as a configurable add on, and its of use, I am not sure that it would be turned down. You just gotta work with their community. Which for the most part is just the glibc folks with out UD. Sep 18 01:39:44 RP: yes they did Sep 18 01:39:56 infact ubuntu 9.10 will have eglibc Sep 18 01:40:00 as default library Sep 18 01:41:03 it sounds like xfree86->xorg all over again :) Sep 18 01:41:16 grg: eglibc has many adv for embedded stuff Sep 18 01:41:33 plus the community will be more supportive than glibc one **** ENDING LOGGING AT Fri Sep 18 02:59:56 2009