**** BEGIN LOGGING AT Thu Jul 01 02:59:57 2010 Jul 01 07:09:51 morning Jul 01 07:10:42 03Roger Monk  07org.openembedded.dev * r3446a880af 10openembedded.git/conf/machine/omap3evm.conf: (log message trimmed) Jul 01 07:10:42 omap3evm: Cleanup machine config Jul 01 07:10:42 * Set uboot preferred provider Jul 01 07:10:42 * Set VT Jul 01 07:10:42 * Set x-loader machine Jul 01 07:10:50 am3517-evm: Machine config cleanup Jul 01 07:10:50 * Remove legacy OMAP3517 extra machine Jul 01 07:10:51 * Only used internally - safe to remove Jul 01 07:10:51 * Add uboot preferred provider Jul 01 07:10:54 * Set Machine configs for uboot/xloader Jul 01 07:10:54 * Set VT Jul 01 07:10:54 03Roger Monk  07org.openembedded.dev * r20cb868f67 10openembedded.git/recipes/x-load/ (11 files in 3 dirs): Jul 01 07:10:54 x-load: Remove early (alpha) am3517 x-loader recipes and files Jul 01 07:10:54 * 1.41 for am3517 was test build - remove Jul 01 07:17:53 03Khem Raj  07org.openembedded.dev * r1672265fdd 10openembedded.git/recipes/gcc/gcc-svn.inc: Jul 01 07:17:53 gcc-svn: Dont disable long double 128 for ppc Jul 01 07:17:53 Signed-off-by: Khem Raj Jul 01 07:18:02 03Khem Raj  07org.openembedded.dev * r8058b3145d 10openembedded.git/recipes/gcc/ (gcc-4.5.inc gcc-4.5/gcc-uclibc-locale-ctype_touplow_t.patch): Jul 01 07:18:02 gcc-4.5: Make gcc-cross build for ppc target Jul 01 07:18:02 Signed-off-by: Khem Raj Jul 01 07:19:49 khem thanks for your support for the glibc proposal; I agree with you that there are more recipes that require a cleanup, but last time I proposed I caught quite some headwind Jul 01 07:20:21 some people do not seem to understand what a version control system is for and want to keep old stuff around forever :-( Jul 01 07:21:06 03Khem Raj  07org.openembedded.dev * re3d8e1b3bb 10openembedded.git/recipes/uclibc/uclibc_git.bb: Jul 01 07:21:06 uclibc_git.bb: Bump to latest master. Jul 01 07:21:06 Signed-off-by: Khem Raj Jul 01 07:22:09 eFfeM_work, i agree. its a bit ridiculous that there are over 8000 recipes. I guess there are a significant number of these that haven't been built for years. Jul 01 07:50:15 03Dirk Opfer  07org.openembedded.dev * r7ce06f37cd 10openembedded.git/recipes/busybox/ (3 files in 3 dirs): Jul 01 07:50:15 busybox 1.16.2: Fix udhcpd and udhcpc in config Jul 01 07:50:15 Starting with version 1.16.x busybox changed CONFIG_APP_UDHCPxxx into CONFIG_UDHCPCxxx. Jul 01 07:50:15 - Change defconfigs Jul 01 07:50:15 - Fix do_install_append to install the scritps if these options are set Jul 01 07:50:20 03Dirk Opfer  07org.openembedded.dev * r6b32b37752 10openembedded.git/recipes/busybox/ (12 files in 3 dirs): busybox: 1.16.1 -> 1.16.2 (new stable) Jul 01 08:03:59 BlindMan, hi Jul 01 08:08:10 hi blindvt :) Jul 01 08:57:08 03Martin Jansa  07org.openembedded.dev * r98a8f2fa99 10openembedded.git/recipes/busybox/busybox_1.16.2.bb: Jul 01 08:57:08 busybox_1.16.2: increase D_P for shr Jul 01 08:57:08 Signed-off-by: Martin Jansa Jul 01 08:57:16 03Martin Jansa  07org.openembedded.dev * r2a78a6f80c 10openembedded.git/recipes/shr/libphone-utils_git.bb: Jul 01 08:57:16 libphone-utils: move phoneutils_test to separate package to keep debian package naming intact Jul 01 08:57:16 Signed-off-by: Martin Jansa Jul 01 09:03:47 03Koen Kooi  07org.openembedded.dev * r04d4e77616 10openembedded.git/recipes/qt4/ (2 files in 2 dirs): Jul 01 09:03:48 qt4-embedded 4.7.0b1: add WIP recipe Jul 01 09:03:48 qt4-e 4.7b1: make it thru configure, fail in do_compile now: Jul 01 09:03:48 | qxml.cpp:(.text._ZN7QVectorI7QStringE7reallocEii[QVector::realloc(int, int)]+0x2c4): undefined reference to `qBadAlloc()' Jul 01 09:03:50 03Roger Monk  07org.openembedded.dev * rb4c03a78b3 10openembedded.git/recipes/u-boot/u-boot-git/omap3evm/ (16 files): Jul 01 09:03:50 uboot: Remove early (alpha) am3517 u-boot patches Jul 01 09:03:50 * Not required now Jul 01 09:03:50 Signed-off-by: Roger Monk Jul 01 10:23:00 morning all Jul 01 10:24:18 morning Jul 01 10:43:40 gm Jul 01 10:52:06 florian: ping Jul 01 10:52:20 mickey|office: pong Jul 01 10:52:52 florian: hi. when is the deadline for that Tätigkeitsbericht? It looks like I have some time next week to work on that Jul 01 10:53:34 mickey|office: no particular deadline but we need it to renew the tax exemption status Jul 01 10:53:55 * florian unluckily doesn't have time :-( Jul 01 10:57:41 khem, That's the difference of the static libs with the fixed buildsys, can you comment on that, please (i find it plausible)? http://paste.debian.net/79263/ Jul 01 11:06:40 khem, and that's the shared symbols that changed (librt should use a script and pull in libpthread_nonshared in ASNEEDED, probably?): http://paste.debian.net/79264/ Jul 01 11:21:45 03Koen Kooi  07org.openembedded.dev * r90249cc563 10openembedded.git/conf/distro/include/angstrom-jalimo.conf: angstrom-jalimo: add config file tailored to building jalimo stuff for angstrom Jul 01 11:46:52 03Henning Heinold  07org.openembedded.dev * rce58e573b3 10openembedded.git/recipes/xalan-j/xalan-j_2.7.1.bb: xalan: fix staging und bump PR Jul 01 11:53:13 mickey|office: tätigkeitsbericht? Is this something about the E.V. ? Jul 01 12:11:42 dcordes: yes Jul 01 12:26:21 RP: ping Jul 01 12:26:32 zecke: pong Jul 01 12:30:42 RP, zecke do you have any idea when bitbake 1.10 will be frozen and labeled as such (and made available as tarball) Jul 01 12:31:48 eFfeM_work: It would ne nice to get that sorted Jul 01 12:31:54 * RP is probably to blame on that one :( Jul 01 13:41:57 RP, thanks for the info. Jul 01 13:42:38 hm who wrote the new staging system? Jul 01 13:47:15 Hi All, Jul 01 13:47:48 How to configure touch screen with Console , have installed tslib and working fine with X Jul 01 13:47:49 woglinde, no idea, check git on who committed it (and the commit msg) Jul 01 13:48:22 siji, wrong channel, this is the oe dev lounge, not a distro/hw support channel Jul 01 13:48:47 ok Jul 01 13:53:13 siji: tslib_calibrate Jul 01 13:53:31 hi hrw Jul 01 13:55:58 woglinde: rp Jul 01 14:04:24 I'm really starting to get sick and tired of the antagonistic attitude shown by koen & some others. It's enough to burn you out of even working on OE at all. God help you if you do anything more invasive than a change to one little recipe. Jul 01 14:05:22 hm Jul 01 14:05:30 glibc needs cleanup Jul 01 14:05:39 it does indeeed Jul 01 14:05:41 thats my point Jul 01 14:06:03 and we need new stable Jul 01 14:06:12 or new staging in stable Jul 01 14:06:22 OE == Angstrom --- perhaps not the way it was intended to be, but for all practical intents and purposes, that's the way it's become. Jul 01 14:06:24 yeah, we do need a new stable branch. Jul 01 14:06:34 I have been planning to make one for months but never quite got around to it. Jul 01 14:06:38 maybe we should just do it now. Jul 01 14:06:52 pb hm hehe Jul 01 14:06:59 if we reached a useful state i would support this Jul 01 14:07:01 pb hm wait Jul 01 14:07:09 there is one goal Jul 01 14:07:14 before new stable Jul 01 14:07:22 atomic patches for older gcc's Jul 01 14:07:35 does that really need to be a blocking issue for a new stable branch? Jul 01 14:07:44 I would have thought anybody who cares about the atomic stuff can just use a modern gcc. Jul 01 14:07:47 pb_: I would support that Jul 01 14:07:57 yes getting the patches into stable afterwards is pain Jul 01 14:08:05 woglinde: ! Jul 01 14:08:22 even getting them into .dev seems not to be an easy task ... Jul 01 14:08:30 okay. well, do we have a roadmap for getting those patches landed? Jul 01 14:08:51 if it's something that is going to happen in a known timeframe then that's fine, we can wait. Jul 01 14:08:57 * woglinde will discuss it with stefan_schmidt Jul 01 14:09:04 but if it's going to be subject to indefinite delay then I think we should probably just go ahead and branch anyway. Jul 01 14:09:07 that are two patches Jul 01 14:09:14 one fixes atomic-arm support Jul 01 14:09:26 the other libgcc/g++ problem Jul 01 14:09:42 the first is from ubuntu and in use for ages there Jul 01 14:09:52 the 2nd is from the gcc 4.4 stable branch Jul 01 14:10:08 so its upstream already (aka 'good' ;) ) Jul 01 14:10:16 righto Jul 01 14:10:43 I still don't entirely understand why you can't just use gcc 4.4.x, but if the backport patches already exist and are tested then there shouldn't be any real problem with getting them landed. Jul 01 14:10:51 which versions of gcc are you trying to patch, just 4.3.x or older ones too? Jul 01 14:10:59 4.3.x Jul 01 14:11:27 the problem is that angstrom on arm is mostly tested with gcc 4.3.x Jul 01 14:11:58 at least that is the default for now Jul 01 14:12:08 ok, fair enough Jul 01 14:12:30 if it is a choice between patching 4.3.x or conducting a pitched battle with the angstrom maintainers then I guess I can see why you want to patch gcc :-} Jul 01 14:12:54 pb_: we'll sort it out with stefan Jul 01 14:13:03 pb_: ;) Jul 01 14:13:05 ok Jul 01 14:13:29 when do you think you can do that? would, say, next week be a reasonable timeframe? Jul 01 14:13:57 ~seen stefan_schmidt Jul 01 14:14:00 stefan_schmidt <~stefan@p5B032E9A.dip.t-dialin.net> was last seen on IRC in channel #oe, 2d 18h 7m 14s ago, saying: 'woglinde: ok, will try tomorrow'. Jul 01 14:17:00 * florian imagines mickey|zzZZzz sleping on his keyboard flooding IRC channels ;-) Jul 01 14:26:02 :D Jul 01 14:26:53 ah, mickey awakes Jul 01 14:26:57 mickeyl: good morning! Jul 01 14:27:00 good morning pb_ Jul 01 14:30:18 hi mickeyl Jul 01 14:30:29 yo woglinde Jul 01 14:30:56 * mickeyl starting to find out why his new thinkpad immediately resumes after suspend Jul 01 14:31:19 acpi acpi Jul 01 14:31:22 lalalalalaaallaaaa Jul 01 14:31:32 something has failed in the suspend process ? Jul 01 14:31:35 yeah Jul 01 14:31:44 PM: can't suspend device 3-0-0 Jul 01 14:31:45 mickeyl: what model is? Jul 01 14:31:48 Jay7: W701 Jul 01 14:31:58 now what on earth is device 3-0-0 Jul 01 14:32:11 * mickeyl suspects internal usb hub Jul 01 14:32:11 pci? Jul 01 14:33:31 mickeyl: ls -l /sys/bus/usb/devices Jul 01 14:34:53 lspci Jul 01 14:35:22 00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 (rev 11) Jul 01 14:35:23 hmm? Jul 01 14:36:00 acpi Jul 01 14:36:05 usb/3-0:1.0 is Jul 01 14:36:14 the internal hub Jul 01 14:36:22 woglinde: -v Jul 01 14:36:43 mickeyl whats dmesg saying? Jul 01 14:37:31 hm try acpitool -w Jul 01 14:37:33 [ 207.401716] pm_op(): usb_dev_suspend+0x0/0x20 returns -2 Jul 01 14:37:33 [ 207.401720] PM: Device usb3 failed to suspend: error -2 Jul 01 14:37:33 [ 207.401722] PM: Some devices failed to suspend Jul 01 14:38:35 xHCI Host Controller Jul 01 14:39:46 aah! Jul 01 14:39:48 modprobe -r xhci Jul 01 14:39:52 pm_suspend Jul 01 14:39:55 and now it's asleep Jul 01 14:40:01 hehe.. Jul 01 14:40:21 now i can only do that as long as it's not in use, of course Jul 01 14:40:31 let me add some usb devices Jul 01 14:41:57 right, i need that for my mouse Jul 01 14:42:13 so, now to find out why xhci is actually refusing to suspend Jul 01 14:43:02 driver messup I guess Jul 01 14:43:24 and in the end is a bug in bios with acpi Jul 01 14:43:27 * woglinde hides now Jul 01 14:43:51 till later Jul 01 14:43:56 mickeyl: thinkwiki is a good source of information about these topics, usually someone else found a fix already. Jul 01 14:44:49 florian: right Jul 01 14:45:02 Suspend not implemented yet in USB 3.0 (xhci) driver - system cannot suspend unless driver is unloaded first - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/522998 Jul 01 14:45:06 oh well Jul 01 14:45:21 that's what i get for buying new hardware... Jul 01 14:45:29 great :-/ Jul 01 14:47:13 yeah Jul 01 14:47:20 fuck new hw ;) Jul 01 14:47:31 kergoth_: ping? Jul 01 14:48:08 I bought an x301 very early after the launch and had a minor issue with the UMTS modem only... Jul 01 14:48:08 power management on this monster is ridicolous Jul 01 14:48:10 1.5 hours Jul 01 14:48:16 eeks Jul 01 14:48:28 * RP loves his x200s with 9 cell battery Jul 01 14:48:40 (not that i would expect much from a 17" i7 w/ 2 harddrives, but still) Jul 01 14:48:53 Runs for hours upon hours and is light and small Jul 01 14:49:07 and connects to my 24" monitor fine Jul 01 14:49:11 yeah, i still like my x60s, for travelling it's unrivaled) Jul 01 14:49:48 The standard x200s battery is a joke mind Jul 01 14:51:40 * Jay7 is using x61 tablet with 8-cell battery Jul 01 14:58:53 I like my asus ul30a - 8h is granted, 10h is possible Jul 01 15:00:27 hrw: doing what with it? Jul 01 15:00:55 RP: my normal conference use, no hardcore compiling Jul 01 15:01:22 hrw: I like the fact the x200s manages abuse like compiling :) Jul 01 15:01:32 RP: but this is CULV SU7300 so no power monster Jul 01 15:02:13 zecke, kergoth_: Joining us? Jul 01 15:03:38 RP: not today, as I already mentioned not having a meeting to the better half Jul 01 15:03:50 RP: pb_'s mail is changing things a bit though Jul 01 15:03:57 going offline now Jul 01 15:04:11 * Jay7 is compiling OE on x61 :) Jul 01 15:04:44 zecke: ok, we need to resolve things somehow though... Jul 01 15:06:09 'night zecke Jul 01 15:08:21 03Khem Raj  07org.openembedded.dev * r77211ccab1 10openembedded.git/recipes/gcc/gcc-4.5.inc: Jul 01 15:08:21 gcc-4.5: BUMP INC_PR not BINV Jul 01 15:08:21 Signed-off-by: Khem Raj Jul 01 15:42:57 03Martin Jansa  07org.openembedded.dev * r962da8c4e8 10openembedded.git/recipes/xorg-xserver/ (3 files in 2 dirs): Jul 01 15:42:58 xserver-xorg: remove CVS recipe and patches used only there, xserver is in GIT for long Jul 01 15:42:58 Signed-off-by: Martin Jansa Jul 01 15:43:01 03Martin Jansa  07org.openembedded.dev * r29002361a9 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): Jul 01 15:43:01 xserver-xorg: remove 1.8.0, keep 1.8.1 as 1.8 representative Jul 01 15:43:01 Signed-off-by: Martin Jansa Jul 01 15:43:02 03Martin Jansa  07org.openembedded.dev * red1d5351a1 10openembedded.git/ (4 files in 3 dirs): Jul 01 15:43:02 xserver-xorg: upgrade 1.9 RC3 to RC4 Jul 01 15:51:50 03Martin Jansa  07org.openembedded.dev * r9e7262cb51 10openembedded.git/recipes/ (4 files in 4 dirs): Jul 01 15:51:50 linux(-kexecboot): bump SRCREV and remove applied patch Jul 01 15:51:50 Signed-off-by: Martin Jansa Jul 01 15:57:02 I have a generic question: in a recipe, I do "addtask compile_bis before do_sizecheck after do_compile" and I would like this to be machine-specific. Is it possible and how can I do that? Jul 01 15:58:16 You don't, exactly Jul 01 15:58:31 You make compile_bits, in shell check $MACHINE or similar Jul 01 16:01:32 Thanks. It makes sense Jul 01 16:06:21 Hello... Jul 01 16:06:26 I have problens.. Jul 01 16:07:59 I cannot build an rootfs with online builder on Angstrom Jul 01 16:16:50 Hi Jul 01 16:18:07 hi Jul 01 16:18:27 Can you help me? Jul 01 16:18:53 or ANYBODY help me? Jul 01 16:19:42 you'll have to be way more specific Jul 01 16:20:31 I tryed to build one rootfs on Angstrom Online builder... Jul 01 16:20:39 But i cannot use graphics... Jul 01 17:12:22 OLAAAAAAA;;;;;;;;;;;;;HELOOOOOOOOOOO Jul 01 17:13:28 < dm8tbr> you'll have to be way more specific Jul 01 17:16:48 i wonder how pypy will work with OE :o) have someone try ? Jul 01 17:20:28 whats pypy? Jul 01 17:21:10 http://codespeak.net/pypy/dist/pypy/doc/ Jul 01 17:22:21 if i understood, it's python implementation in python , with psyco-like JIT compier Jul 01 17:22:59 but since we use a lot of python C ext , we need C python ext support un pypy Jul 01 17:23:28 write an recipe and try it out Jul 01 17:23:40 dont see anything which stops pypy Jul 01 17:25:45 i told you , the lack of C python extention ported to pypy Jul 01 17:27:10 so whats the problem to enabled this extension in the pyhton-recipe? Jul 01 17:27:28 test it submit a patch and hope it will be integrated Jul 01 17:27:34 if you want it fast Jul 01 17:27:41 you maybee might pay someone Jul 01 17:27:48 doing it for you Jul 01 17:27:54 i've no time and no money , i just ask if someone was curious to test Jul 01 17:28:06 and i could do it myself thanks. Jul 01 17:28:18 sorry we all need a 48h day Jul 01 17:28:36 and i had a git access at time. Jul 01 17:28:57 but i stop OE devel since 2 years , so you don't remember me. Jul 01 17:29:46 hm Jul 01 17:30:06 wasnt you working at the aibo replacement company? Jul 01 17:30:17 aldebaran yes Jul 01 17:30:21 seems Jul 01 17:30:26 i work on my own project now Jul 01 17:30:29 my brain dont lack's sometimes Jul 01 17:30:39 or it lacks the right way Jul 01 17:30:50 my OE system still run there ;-) Jul 01 17:31:34 http://wiki.openembedded.org/index.php/User:Ronan , so old now , i should update it later Jul 01 17:42:05 good morning Jul 01 17:56:28 mwester: ping Jul 01 17:56:42 mwester: are you Mika Westerberg? :) Jul 01 17:57:01 Nope Jul 01 17:57:09 ah, sorry :) Jul 01 17:57:23 Sounds like a good name, though, perhaps I'll borrow it. Jul 01 17:57:26 :p Jul 01 17:57:47 * Jay7 is looking for anyone who know ubifs internals Jul 01 17:59:20 linux-mtd@lists.infradead.org ? Jul 01 18:00:31 but it's not much active :/ bug report reply was just "confirmed, send patch" :/ Jul 01 18:01:12 I've found sources :) Jul 01 18:01:19 that is even better.. Jul 01 18:24:36 hi crofton Jul 01 18:25:07 preparing to leave .de :( Jul 01 18:27:41 is anyone here have ubifs on device? Jul 01 18:28:53 Jay7: I have, why? Jul 01 18:29:09 Tartarus: can you pastebin /proc/partitions from there please? Jul 01 18:29:33 It's got android so it's a little funny Jul 01 18:29:37 But what are you looking for? Jul 01 18:29:45 And you know ubifs needs to be in a ubi container right? Jul 01 18:29:55 a way to detect ubifs from kexecboot :) Jul 01 18:30:01 I ask since i remeinded someone else the otehr day Jul 01 18:30:08 Ah Jul 01 18:30:08 yes.. I've read about this already.. Jul 01 18:30:33 So yeah, that sounds like an unfun task, to automatically figure out what part of the ubi to root Jul 01 18:30:33 yes? Jul 01 18:30:44 or something else? Jul 01 18:30:52 should be harder than I thought Jul 01 18:31:07 yes Jul 01 18:31:18 but I can just show all containers Jul 01 18:32:46 even I will show all containers that have fs and have config file or kernel Jul 01 18:58:46 hey likewise Jul 01 19:03:50 can anyone try if clean then build recipe webkit-gtk works for you? Jul 01 19:04:54 woglinde, uImage is always packaged inside rootfs, so I was ok on that part Jul 01 19:05:56 but thanks for your help Jul 01 19:06:46 gaston and in deploy/glibcfoo/images Jul 01 19:07:29 woglinde, thats were I couldnt get it to regenerate since it obviously thought the old was still ook Jul 01 19:07:38 hm Jul 01 19:07:49 re kergoth Jul 01 19:09:21 Anyone up for trying to build webkit-gtk? Jul 01 19:09:32 not this time Jul 01 19:09:36 takes hours Jul 01 19:09:46 and 10 gig space Jul 01 19:10:05 woglinde: heh 10G is nothing when it comes to angstrom Jul 01 19:12:27 Gaston|Home: I've built it about 2 days ago OK, did you built webkit-efl after it? Jul 01 19:13:01 I was just trying to do a bitbake angstrom-gnome-image Jul 01 19:13:01 Gaston|Home: they conflicts on one .pc file so maybe rebuilding webkit-gtk after webkit-efl doesn't work (uses wrong .pc) Jul 01 19:13:40 Gaston|Home: what's your nick on tinderbox? Jul 01 19:13:57 ok, so cleaning webkit-efl should release the problem? Jul 01 19:14:07 No login on tinderbox Jul 01 19:14:20 I don't know.. I haven't seen the error... Jul 01 19:15:39 Gaston|Home: and webkit-efl is not pulled to angstrom-gnome-image i guess.. so if you haven't build it yourself then cleanning cannot help Jul 01 19:15:50 khem aeh? Jul 01 19:15:58 JaMa: : http://pastebin.org/371335 Jul 01 19:16:02 khem 10g only for this Jul 01 19:16:18 build inside angstroem Jul 01 19:16:34 khem last uclibc_git update broke it Jul 01 19:16:41 problems inside ntpl Jul 01 19:16:47 ups nptl Jul 01 19:18:11 webkit-efl was built on my host, so I'll try to buil webkit-gtk now Jul 01 19:18:24 JaMa: Thanks! Jul 01 19:18:40 Gaston|Home: really strange log, what are lines 1,2? what happen between 3 and 5?, but I don't remember seeing ld killed by -9 Jul 01 19:18:40 hi all Jul 01 19:19:32 woglinde: whats error Jul 01 19:19:38 I was trying to post the command that generated the error in forst but miserably failed to see that the paste didnt go in before the fisrt error-log line Jul 01 19:20:25 khem mom Jul 01 19:21:51 if its a known problem that webkit-efl kills webkit-gtk, would it be hard to make the recipe for webkit-gtk to clean webkit-efl before building webkit-gtk? Jul 01 19:22:35 Gaston|Home: webkit-efl was already merged in upstream source, so proper fix is built both together... Jul 01 19:24:16 ok, I got same error even after cleaning webkit-efl before resuming build on webkit-gtk. I'll try cleaning web-kit-gtk before rebuilding it again. Jul 01 19:26:06 * Gaston|Home will report back in an hour or so Jul 01 19:26:16 khem Jul 01 19:26:17 http://pastebin.com/QzyBTAeu Jul 01 19:29:50 binutils are 2.18 Jul 01 20:29:44 woglinde: hmm cfi_directives is a new feature not present in 2.18 binutils Jul 01 20:30:01 woglinde: any chance of you using newer binutils say 2.20+ ? Jul 01 20:30:20 khem will test tomorrow maybee Jul 01 20:30:21 s/cfi_directives/.cfi_sections/ Jul 01 20:30:55 woglinde: I am inclined to bump up the minimum binutils version for uclibc/arm Jul 01 20:32:19 woglinde: you should have same problem with latest glibc/eglibc as well Jul 01 20:32:49 the thing is you have to have close enough versions of gcc/binutils/glibc/gdb to inter operate well Jul 01 20:33:10 2.18 is pretty old for current development versions Jul 01 20:36:15 sue Jul 01 20:36:17 sure Jul 01 20:36:35 but 2.18 as you remember was the only which got beagle dspstuff compiled Jul 01 20:49:26 woglinde: I still dont know the root cause of that problem Jul 01 20:49:38 woglinde: it could be a user issue Jul 01 20:57:26 re florian Jul 01 20:57:59 re Jul 01 20:59:50 good nite Jul 01 21:07:44 hi all, what's the right way to propose a new bitbake recipe ? Jul 01 21:26:49 khem: around? Jul 01 21:27:50 edsiper: put it in a patch (git email format) and send it to the mailing list for review. Jul 01 21:35:28 hi Jul 01 21:36:19 how hi Jul 01 21:37:58 kergoth__: around? Jul 01 21:38:12 i trying to bitbake helloworld with angstrom distribution and I am not able to build the armv7a-angstrom-linux-gnueabi/eglibc-2.9-r11.9+svnr10153 Jul 01 21:38:23 and it fails at do_compile stage .. Jul 01 21:38:52 where i should change if i want to remove the eglibc dependecy Jul 01 21:43:16 RP: hey Jul 01 21:43:31 * khem waves at ant__ Jul 01 21:43:39 ant__: I have got a problem with klibc Jul 01 21:43:46 khem: Got a minute to talk about toolchains? Jul 01 21:43:51 RP: sure Jul 01 21:44:05 khem:hello Jul 01 21:44:06 khem: I finallly got gcc-runtime working in poky Jul 01 21:44:09 RP: hi Jul 01 21:44:14 RP: cool Jul 01 21:44:26 khem: In the end I resorted to copying libgcc out of the gcc-cross build Jul 01 21:44:27 RP: I hope its not stage caching Jul 01 21:44:40 khem: stage caching? Jul 01 21:44:54 ant__: why do we change KLIBCARCH for x86 in klibc Jul 01 21:45:18 RP: oh I mean we talked about the problem of having libraries for next build last time Jul 01 21:45:45 RP: ok so how did you implement it and why did you resort to libgcc from gcc-cross Jul 01 21:46:06 khem: I couldn't get libgcc to build right standalone :( Jul 01 21:46:29 khem: Too senstive to all kinds of flags issues and required a ton of headers from the gcc compile directory Jul 01 21:46:44 RP: hmm ok Jul 01 21:46:51 khem: I did leave libstdc++ building standalone and finally made that work Jul 01 21:47:10 RP: I thought after it was moved out of gcc tree into its own it should be bit easier Jul 01 21:47:10 I had to patch gcc in the end to allow g++ the option of not linking against libstdc++ Jul 01 21:47:32 khem: Sadly whilst its separate, its hard Jul 01 21:47:33 RP: you could have also said my g++ is gcc Jul 01 21:47:55 khem: I wasn't sure it would have liked that Jul 01 21:48:00 RP: if you have changes somewhere I can look at them Jul 01 21:48:13 RP: its ok to cheat Jul 01 21:48:15 it works :) Jul 01 21:48:19 khem: Its in Poky now, no patche against OE though Jul 01 21:48:38 RP: do you have time to put it into OE Jul 01 21:48:45 or should I look into that Jul 01 21:49:06 khem: At present its not looking like I will have any time for that :( Jul 01 21:49:12 * RP is concentrating on bitbake atm Jul 01 21:49:30 ant__: the problem is that klibc still has code that depends on KLIBCARCH being i386 or x86_64 and that code breaks Jul 01 21:49:36 khem: http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/gcc Jul 01 21:49:41 khem: Look at runtime Jul 01 21:49:56 RP: ok lemme see Jul 01 21:50:02 khem: EXTRA_OEMAKE = "'KLIBCARCH=${KLIBC_ARCH}' \ Jul 01 21:50:04 khem: http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/gcc/gcc-configure-runtime.inc is the core of it Jul 01 21:50:04 RP: most probably I will port it over Jul 01 21:50:06 yea Jul 01 21:50:21 khem: I've only done libssp and libstdc++ but the others shouldn't be hard Jul 01 21:50:21 ant__: so my question why do we set it to x86 Jul 01 21:50:41 I let me re-read klibc ml.. Jul 01 21:50:46 RP: libgcc libstdc++ are basically what we need to get going Jul 01 21:50:50 I think there was some fix Jul 01 21:50:51 everything else can follow Jul 01 21:51:26 khem: I can confirm this at least passes all the tests I've thrown at it. Now I fixed libstdc++, looking back at libgcc is probably a good idea Jul 01 21:52:01 khem: I actually have another topic I'd be interested in your view on - multilibs Jul 01 21:52:15 khem: I saw your email wanting to disable them Jul 01 21:52:33 khem: On the other hand having to only build one arm toolchain would be a neat idea Jul 01 21:52:53 khem: and I've interest in 64 bit support too :/ Jul 01 21:53:10 khem: ./klibc-common.inc:KLIBC_ARCH_x86 = 'i386' is perhaps there just because x86_64 was broken at the time... Jul 01 21:54:24 RP: i was thinking from a SDK pov then it seems its nice to shove all into one toolchain Jul 01 21:54:56 ant__: noo Jul 01 21:55:13 ant__: x86 is a MACHINE override Jul 01 21:55:25 khem: You mean one toolchain per SDK Jul 01 21:55:29 yes, of KLIBC_ARCH = '${TARGET_ARCH}' Jul 01 21:55:29 ? Jul 01 21:55:30 ant__: problem is that now we pass KLIBCARCH=x86 which is not known to klibc Jul 01 21:55:50 RP: I mean one toolchain per arm/multilib Jul 01 21:55:59 * mwester wishes there was a more obvious method for using overrides. Jul 01 21:56:10 RP: like say ppc with fpu/soft/ all in one Jul 01 21:56:16 but its darn complex Jul 01 21:56:23 and we have to churn out glibc as many times Jul 01 21:56:25 khem: right Jul 01 21:56:49 khem: This is the bit that worries me as gcc is upset if you don't have glibc for each multilib? Jul 01 21:56:57 RP: now that we can separate out runtime things might become a bit easier Jul 01 21:57:04 multilib is harder to shovel into the current model Jul 01 21:57:12 Where's Riks patches for amd64 again? Jul 01 21:57:14 Tartarus: yes Jul 01 21:58:28 Tartarus, RP for time being we should disable multilib in gcc Jul 01 21:58:40 and rework design for multilib Jul 01 21:58:47 may be based on roman's patches Jul 01 21:59:02 khem: That I agree with Jul 01 21:59:06 what we have currently is bogus when it comes to multilib Jul 01 21:59:10 khem: I'm just starting to explore the issue Jul 01 21:59:31 khem: BBCLASSEXTEND comes to mind as an interesting tool for multilib... Jul 01 21:59:40 RP: ok then stamp my rfc :) Jul 01 21:59:51 and I will change it. Jul 01 21:59:55 khem: :) Jul 01 22:00:30 RP: w.r.t multilib although we need to have this as a distro feature based on machine arch Jul 01 22:01:34 yes Jul 01 22:01:38 and multilib has many variants we have to select based on arch sometimes e.g. Jul 01 22:01:48 mips has abi based Jul 01 22:02:11 ppc has floating point based and machine word length based Jul 01 22:02:19 x86 is wordlength Jul 01 22:02:25 arm is crappiest of all Jul 01 22:02:53 it has endianness, floating point Jul 01 22:04:00 khem: Its a crazy world Jul 01 22:04:17 there will be changes needed in gcc for selecting runtime libc during compile/link but usually gcc gets it right Jul 01 22:04:38 RP: in my experience its easy to spin a single toolchain doing one thing Jul 01 22:04:41 its way easy Jul 01 22:04:58 ask CSL how many calls they get around mutlilibbinb Jul 01 22:05:21 RP: but we can support some of them Jul 01 22:05:27 like 32/64 bit Jul 01 22:05:34 and mips o32/n32/n64 Jul 01 22:05:39 ppc32/ppc64 Jul 01 22:05:48 khem: They're the ones I'm interested in Jul 01 22:06:00 x86_64/x86 Jul 01 22:06:12 arm I would refrain Jul 01 22:06:15 At least 32/64 Ix86 I can test Jul 01 22:06:37 mwester, thanks, where's the mailing list ? Jul 01 22:07:00 those are clear and I think for x86 glibc configury even supports to build twice automagically Jul 01 22:07:08 but we should not rely on that Jul 01 22:07:24 we should build glibc for earch variant by hand Jul 01 22:07:53 ant__: do you see my issue Jul 01 22:07:55 mwester, this is the project: http://www.monkey-project.com Jul 01 22:07:58 khem: the overrides in 1.5.18 Jul 01 22:08:03 ant__: yes Jul 01 22:08:08 they seems not ok to me Jul 01 22:08:20 honestly I don't remember having added those... Jul 01 22:08:38 ant__: after kernel arch was unified for x86 and x86-64 kernel arch changed to be called x86 Jul 01 22:08:46 I'm checking if targets are updated in 1.5.18 ... Jul 01 22:08:47 same does not hold for klibc as of now Jul 01 22:08:59 ant__: no Jul 01 22:09:02 :/ Jul 01 22:09:08 khem: agreed Jul 01 22:09:19 there are some syscalls which are only arch specific Jul 01 22:09:31 they are not correct at the moment in our klibc Jul 01 22:09:36 still recipe is machine-specific Jul 01 22:09:50 * khem found it when using v86d Jul 01 22:10:18 http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/v86d.spec?r1=1.19&r2=1.20&f=u Jul 01 22:10:22 he he Jul 01 22:10:32 khem: I will continue to give multilibs some thought. Any proposals welcome though :) Jul 01 22:10:59 khem: I was googling Jul 01 22:11:15 RP: ok I will think too Jul 01 22:11:21 RP: lets see what roman has Jul 01 22:12:07 ant__: thats not the problem Jul 01 22:12:28 khem,: feel free to purge klibc_1.5.18.inc, we use the overrides in klibc-common.inc Jul 01 22:12:40 it was so in 1.5.15 iirc Jul 01 22:12:52 (I confess I only build for arm) Jul 01 22:12:52 ant__: I could have done that but I also see the linux is a symlink into kernel sources Jul 01 22:13:22 ant__: I was wondering if there is some think that wants kernel and klibc arch to be same Jul 01 22:13:37 but for now I will remove them for a test and go from there Jul 01 22:14:14 I think we ytalked last time about this issue: th emake_headers_install solves the staging problem, not the building one Jul 01 22:14:35 so I fear we still need th esymlink... Jul 01 22:14:46 oh, this space key... Jul 01 22:15:32 ant__: yeah does it access include// Jul 01 22:15:35 inside kernel Jul 01 22:18:34 yeah fatal error: asm/posix_types.h Jul 01 22:18:41 No such file or directory Jul 01 22:18:43 hmmm Jul 01 22:19:36 so it seems klibc needs to know that if its klibcarch=i386|x86_64 then kernel arch is x86 Jul 01 22:20:12 and also it should know which version of kernel it is using Jul 01 22:20:32 well I think I would assume its always x86 for kernel_arch Jul 01 22:20:48 khem: found how it came Jul 01 22:20:49 http://patchwork.openembedded.org/patch/1968/ Jul 01 22:21:18 Tested only on x86, with kernel 2.6.33 and 2.6.32 Jul 01 22:21:28 then me and JaMa committed 1.5.18 Jul 01 22:22:20 yeah I guess eric only did a build time test Jul 01 22:22:40 I think I know how to fix it Jul 01 22:49:50 'nite Jul 01 22:53:40 03Khem Raj  07org.openembedded.dev * r9151533a27 10openembedded.git/recipes/v86d/v86d_0.1.8.bb: Jul 01 22:53:40 v86d: Add recipe for 0.1.9 Jul 01 22:53:40 * Drop 0.1.8 Jul 01 22:53:40 Signed-off-by: Khem Raj Jul 01 22:53:51 03Khem Raj  07org.openembedded.dev * rd3c1b02dd6 10openembedded.git/recipes/klibc/ (7 files in 2 dirs): (log message trimmed) Jul 01 22:53:51 klibc_1.5.18: Fix the build for x86 on newer kernels. Jul 01 22:53:51 * We were setting KLIBCARCH to match kernel arch Jul 01 22:53:51 while this let klibc build, it did not configure Jul 01 22:53:51 in right syscalls because klibc still use 'i386' Jul 01 23:04:27 03Khem Raj  07org.openembedded.dev * r6bca18ac19 10openembedded.git/conf/distro/include/sane-toolchain.inc: Jul 01 23:04:27 sane-toolchain.inc: use 4.4.4 as PREFERRED_GCC_VERSION for armv7 Jul 01 23:04:27 Signed-off-by: Khem Raj Jul 01 23:04:27 Signed-off-by: Lukas-David Gorris Jul 01 23:46:53 JaMa: webkit-gtk still failed after clean of both webkit-gtk and webkit-efl Jul 02 00:47:24 RP: hey, are you around ? Jul 02 00:47:36 univac: yo Jul 02 01:04:59 zecke: hey, long time no see **** ENDING LOGGING AT Fri Jul 02 02:59:57 2010