**** BEGIN LOGGING AT Tue Jul 29 02:59:56 2008 Jul 29 03:45:23 How do I update my OE repos? Jul 29 03:48:35 mtn: warning: protocol error while processing peer monotone.openembedded.org: 'received network error: remote public key hash '549ba2d291b2bd57cb5ed3fec1c6627e9aa4b567' is unknown' Jul 29 03:48:35 mtn: bytes in | bytes out | revs in Jul 29 03:48:35 mtn: 104 | 347 | 0 Jul 29 03:48:35 mtn: error: processing failure while talking to peer monotone.openembedded.org, disconnecting Jul 29 03:48:37 Ideas? Jul 29 03:53:31 Why did you guys choose Monotone? Jul 29 03:57:22 Sargun: what is your update command Jul 29 03:57:50 I deleted it and ran: Jul 29 03:57:52 mtn --db ../OE.mtn pull monotone.openembedded.org org.openembedded.dev Jul 29 03:57:56 that seems to be working Jul 29 03:58:17 alright Jul 29 04:02:01 you could clone from the git server Jul 29 04:02:11 I guess it's getting everything from monotone Jul 29 04:04:20 this is oging to take a while: Jul 29 04:04:20 mtn: 1.5 M | 1.1 M | 260/3001 | 66/745 Jul 29 04:04:38 after 10 minutes Jul 29 04:05:42 Sargun: your database snapshot might be old Jul 29 04:06:19 Sargun: you can download the latest db and that might reduce the number of changesets it needs to pull Jul 29 04:07:14 Why does monotone use a huge big blob? Jul 29 06:27:53 morning Jul 29 07:56:24 bonjour Jul 29 07:58:03 salut Genesis Jul 29 07:58:42 guten tag josch|nsn Jul 29 07:58:46 :D Jul 29 08:29:38 morning Jul 29 08:30:12 morning Jul 29 08:30:18 hrw thanks for the poky tip Jul 29 08:30:26 it worked Jul 29 08:31:13 now i have other things not working (gsmd and some keymap's ) but poky it's better with icons :) Jul 29 08:36:57 morning Jul 29 08:37:00 ;) Jul 29 08:50:07 morning all Jul 29 08:50:36 yo RP Jul 29 08:51:58 florian: good morning Jul 29 08:52:17 hi all Jul 29 09:12:20 hmm, If I was a microSD card where would I hide Jul 29 09:12:44 XorA: Easy, In the last place you'll look Jul 29 09:14:47 hehe this is the reason why i NEVER EVER remove the microSD card from any of my embedded devices - they get lost immediately Jul 29 09:14:56 ;) Jul 29 09:17:53 * XorA found some in old Neo phones Jul 29 09:28:36 ;) Jul 29 09:28:56 one of my neos still has that 128M card which openmoko put in package Jul 29 09:29:04 trouble with moving house, everything is in the wrong place Jul 29 09:29:09 including my bathroom :-( Jul 29 09:30:26 heh Jul 29 09:30:51 XorA: you scare me - i move in a month too :D Jul 29 09:31:14 I keep wandering to where the stairs should be, and I find myself in my spare bedroom Jul 29 09:31:26 then I remeber Im in a flat now Jul 29 09:31:31 josch|nsn: I am moving in september Jul 29 09:31:45 the 128MB card from my neo was one of the first that i never saw again... Jul 29 09:31:50 hrw: bigger place? Jul 29 09:33:55 i hope my new internet provider will not be a crappy one with max 16MBit/s and stuff Jul 29 09:33:58 dinner time! Jul 29 09:34:32 XorA: much Jul 29 09:34:41 josch|nsn: argh! Jul 29 09:34:59 * hrw do not like when people say what kind of net they have... Jul 29 09:35:18 here 3Mbps/512kbps costs me nearly 50 euro... Jul 29 09:35:32 but at new flat 10Mbps/1Mbps would be <30 eur Jul 29 09:36:34 hrw: nice Jul 29 09:36:42 hrw: 10/1.3 is 18GBp Jul 29 09:36:46 hrw: for me Jul 29 09:37:08 ~change 18 gbp to pln Jul 29 09:37:16 i got some error trying that Jul 29 09:37:23 XorA: that's quite good, not that easy to get much up here Jul 29 09:37:46 21.8383 gbp for me Jul 29 09:37:47 florian: ADSL2+ so if I was nearer exchange it could get to 24M Jul 29 09:38:03 XorA: nice Jul 29 09:38:19 in Spain we're not as lucky as you Jul 29 09:38:27 pay another 2 GBP and I can switch some download for upload and get 2.4M up Jul 29 09:38:30 In fact that was the first thing I checked searching for a house ;) Jul 29 09:38:48 * XorA chose this flat so he could get the same ISP :-D Jul 29 09:39:03 149 pln (36.6 gbp, 46,4 eur) for 20/2 Jul 29 09:49:31 XorA: how goes mdev usage? Jul 29 09:50:06 hrw: phone boots are works Jul 29 09:50:18 hrw: lost automounting SD at the moment though Jul 29 09:52:58 hrw: and I had to return to using detect-tsdevice Jul 29 09:53:08 XorA: tried to use mdev for populating and udev for hotplug? Jul 29 09:53:29 hrw: thats what I am doing, but mmc is cold plugged Jul 29 09:53:36 hrw: so gets handled by mdev Jul 29 09:54:06 a yes.. Jul 29 09:54:07 hrw: same with touchscreen Jul 29 09:54:27 hrw: mdev can run scripts though, just need to write one Jul 29 09:55:06 hrw: mdev.conf http://rafb.net/p/7xx53y98.html Jul 29 09:55:09 XorA: "udevadm trigger --system-match=block"? Jul 29 09:55:50 hrw: I was kind of hoping to do away with udev altogether, its seems to be really slow at what it does Jul 29 09:56:43 XorA: openmoko boot is slow anyway Jul 29 09:57:11 hrw: thats why we want more speed Jul 29 10:02:55 XorA: merged poky changes? Jul 29 10:04:11 hrw: no, is that just the first boot taring of /dev? Jul 29 10:04:38 thats just udev... we also have some improvements in initscripts etc Jul 29 10:04:51 1s here, 2s there etc Jul 29 10:07:12 hrw: current discussion with OM is for the official distro to not use initscripts Jul 29 10:08:14 one big linuxrc? Jul 29 10:08:57 yeah Jul 29 10:09:17 what if I would like to install distcc? Jul 29 10:09:26 or other thing with initscript? Jul 29 10:11:45 hrw: we are making a phone, not a general purpose linux device, its upto the community to make it that Jul 29 10:12:10 ko Jul 29 10:12:24 You can always arrange things so that init scripts are run but all the init scripts in the standard image are merged into oneÂ. Jul 29 10:13:18 broonie: or that :-) Jul 29 10:13:49 at the moment I am interested in using busybox as much as possible to save on flash reads which we found are expensive Jul 29 10:33:48 out of interest, what is your current boot time? Jul 29 10:34:00 * pb__ also working on boot time improvements for another product Jul 29 10:35:10 pb__: month ago openmoko had 2m53s Jul 29 10:44:02 We've been improving boot time in poky too - down to about 20 seconds on the zoom Jul 29 10:45:02 btw - someone played with ubifs? Jul 29 10:45:13 ok, great. is that 20 seconds to X and all applications running? Jul 29 10:48:11 pb_: 20 seconds to the X desktop finishing loading Jul 29 10:48:30 righto Jul 29 10:48:46 There is background work that happens afterwards like dropbear starting etc Jul 29 10:48:59 do you know what the time is from power on to linuxrc/init starting to run? That's where I am focussing my efforts at the moment. Jul 29 10:49:18 pb__: kernel time? Jul 29 10:49:25 I think that was about 7 seconds when I measures 20 Jul 29 10:49:40 right, thanks Jul 29 10:49:48 I've cut that to about 4 now Jul 29 10:50:00 ah, very good Jul 29 10:50:16 I think ours is somewhere around 5-6 so there is probably scope for improvement :-) Jul 29 10:50:46 our main offenders seem to be usb and jffs2 Jul 29 10:50:51 It was doing stuff with dhcp and USB RNDIS which I got rid of Jul 29 10:50:52 no surprise about the latter I guess Jul 29 10:51:02 Also, I'm optiing for boot from mmc which helps a lot Jul 29 10:51:13 ah right, I see Jul 29 10:51:22 I don't have that luxury, I must boot from nand. Jul 29 10:51:46 pb__: yaffs or ubifs then? Jul 29 10:52:01 hrw: ping Jul 29 10:52:03 hrw: From the above I'd suspect jffs2 ;-) Jul 29 10:52:09 pong lardman Jul 29 10:52:13 yaffs doesn't compress, so that's no good Jul 29 10:52:26 pb_: You have lzo compression enabled? Jul 29 10:52:28 jffs2 is really slow Jul 29 10:52:35 hrw: Do you know who was after me re Octave? Jul 29 10:52:40 I don't know much about ubifs but it might be worth a try Jul 29 10:52:54 RP: I think we're using zlib rather than lzo but I'm not certain offhand Jul 29 10:53:04 lardman: will check logs in ~20m Jul 29 10:53:21 pb__: lzo is tons faster, I know because I wrote it for that exact reason ;-) Jul 29 10:53:36 ah, excellent :-) Jul 29 10:53:45 lardman: frikker was the person Jul 29 10:53:52 on gp2x yaffs improved boot time versus jffs2 Jul 29 10:54:00 hrw: thanks Jul 29 10:54:03 frikker: ping Jul 29 10:54:03 there's also the jffs2 "central summary" patches which I've been meaning to try, although annoyingly there is no offline summarizer for that. Jul 29 10:55:06 also considering changing to a read-only filesystem for the rootfs, since we never actually need to write to it in a production environment. Jul 29 10:55:27 I'm not sure whether there are any existing read-only, compressed filesystems that will perform well on nand though Jul 29 10:55:35 pb__: As an idea of the speedup lzo decreaed the boot time of the n800 by about 25% Jul 29 10:55:46 excellent, I'll have to try that Jul 29 10:56:59 first though I need to fix my lirc problems Jul 29 10:57:02 * pb__ stabs samsung Jul 29 10:57:40 bbiab, heading to the hardware lab for a while Jul 29 11:09:21 hi Jul 29 11:12:41 hi Jul 29 11:12:49 hi diego Jul 29 11:12:53 hm right Jul 29 11:12:54 apr Jul 29 11:13:01 *GÃœ Jul 29 11:13:04 aeh *g* Jul 29 11:13:13 sorry but I had to fix libstdc++ Jul 29 11:13:22 :D Jul 29 11:13:30 otherwise I didnt had a compiler Jul 29 11:14:11 at the end i've tried some fix, that did'nt work Jul 29 11:15:18 and just gone with this: http://bugs.openembedded.net/show_bug.cgi?id=4148#c1 Jul 29 11:15:39 (it works, but it's not a solution) Jul 29 11:41:34 right, phew, lirc working now Jul 29 11:41:44 * pb_lab stabs samsung, SLOB, crazy kernel h4x0rs Jul 29 11:42:25 hi pb Jul 29 11:42:46 hi woglinde Jul 29 11:42:50 hm isnt infrared dead? Jul 29 11:43:03 hm besides remote control Jul 29 11:43:15 indeed Jul 29 11:43:27 RP: by the way, would lzo be a win for zImage decompression as well? Jul 29 11:43:51 it occurs to me that we probably have about 0.5 second or so spent on that. Jul 29 11:46:46 hi piroko Jul 29 11:50:57 woglinde: Mornin Jul 29 11:54:35 hm, drat, loading usb-ohci-hcd as a module doesn't seem to be a win Jul 29 11:54:41 * pb__ stabs usb Jul 29 11:54:46 hehe Jul 29 11:54:55 I wonder what it's doing in there. Jul 29 11:54:57 pb ultra secret projekt? Jul 29 11:56:14 me? no, not really secret, just trying to make the boot time faster on our devices. Jul 29 11:56:32 ah Jul 29 11:56:41 hm what is it now? Jul 29 11:57:30 pb__: but you can load module and do something at that time... Jul 29 11:57:43 pb__: or load module after starting user stuff? Jul 29 11:57:46 about 1.64 seconds from kernel boot to rootfs mounted, then a second or two of unknown delay (might be our scripts), then about another second of usb-related delay Jul 29 11:58:29 hrw: well, yes, that's what I hoped. but it doesn't seem to work that way. Jul 29 11:58:45 pb yes sys-rc and the shell scripts consume a lot Jul 29 11:58:49 sysv-rc Jul 29 11:59:25 yah Jul 29 11:59:29 I need to abolish sysvinit Jul 29 11:59:39 hm you could try minit Jul 29 12:00:09 dont which services you start *g* Jul 29 12:00:21 none, really Jul 29 12:00:26 hi otavio Jul 29 12:00:33 I think we're probably going to end up writing our own custom /sbin/init Jul 29 12:00:40 yeah Jul 29 12:00:47 thats probably the best Jul 29 12:02:04 it looks like jffs2 mount is currently taking almost exactly 1 second so that should be another obvious candidate for improvement Jul 29 12:02:52 not sure what to do about the other 0.6 seconds of kernel boot time, there don't seem to be any obvious single things there that are consuming a lot of time. Jul 29 12:02:57 ~curse networkmanager crap Jul 29 12:02:58 May the fleas of a thousand camels infest your most sensitive regions, networkmanager crap ! Jul 29 12:03:34 oh, mtd bad block scan of course, that takes 0.13 seconds. Jul 29 12:03:55 in theory I guess I could delay the bad block scan for everything except the rootfs partition until later in boot-up. Jul 29 12:04:41 probably only gonna save me about 0.07 seconds though, I'm not sure it will be worth the effort. Jul 29 12:05:12 pb__: Yes, lzo fo kernel image decompression would be a win Jul 29 12:05:36 morning rp Jul 29 12:05:59 It doesn't quite quite as good compression but its about 10 times faster at decompression Jul 29 12:06:01 hi woglinde Jul 29 12:06:41 ok, great, I'll give that a try as well Jul 29 12:07:15 we have a bit of a delicate balance in that our kernel partition is basically full, so any reduction in compression means we will probably have to boot something else out to a module. and, given insmod slowness, that would offset the gains from faster unzipping. Jul 29 12:07:43 on the other hand if lzo is 10x faster than zlib then it will probably be a net win even in that case. Jul 29 12:07:57 argh... who invented NM should be shot Jul 29 12:08:08 hrw seems you have a good day Jul 29 12:08:51 woglinde: my c7x0 has my home wifi in wpa-supplicant config file so 'ifup wlan0' is able to connect to wifi network. Jul 29 12:09:25 woglinde: but, if NM is running then it require network password to be entered and this pass is too hard to remember to enter it each time when I reflash image Jul 29 12:09:48 hehe Jul 29 12:10:00 make tatoo out of it Jul 29 12:10:01 hahah Jul 29 12:10:06 Brilliant Jul 29 12:10:06 heh Jul 29 12:12:02 maybe I do not understand use of NM but I prefer to have it removed from all my devices Jul 29 12:13:43 XorA: on my c7x0 with mmc card plugged I have working /dev/mmcblk* entries after reset with dev.tar trick Jul 29 12:13:54 hrw: It is meant to look useful but instead generally piss you off Jul 29 12:14:08 XorA: but I cant test it with cf and sd inserted - lost all cf cards Jul 29 12:14:38 hrw: you re-run udev trigger? Jul 29 12:14:49 piroko: for people who change ethernet<>wifi<>gsm often it maybe is useful.. Jul 29 12:15:19 XorA: yes - but only for some subsystems Jul 29 12:15:54 hrw: I've yet to be convinced its working 100% right :/ Jul 29 12:16:15 RP: I know ;] Jul 29 12:16:28 hm.. alix have 2gb cf... Jul 29 12:16:38 hi ant Jul 29 12:16:48 hi woglinde Jul 29 12:16:59 morning channel Jul 29 12:17:11 hrw: sweet to see your c7x0 is ON Jul 29 12:17:44 ant|work: and even works with 2.6.26 Jul 29 12:17:51 hrw: I'm eagerly waiting your udev_124 fixes Jul 29 12:18:03 new prob of today: no /dev/dsp Jul 29 12:18:06 55% battery is max for current battery Jul 29 12:18:14 ough Jul 29 12:18:24 mine is almost dead too Jul 29 12:19:31 hrw: ah, I have /dev/dsp Jul 29 12:19:51 oss_audio: failed to open audio device /dev/dsp Jul 29 12:19:58 must be a new bug then Jul 29 12:20:15 (I was testing flite_time) Jul 29 12:20:16 ant|work: 16 usd for new battery at amazon Jul 29 12:21:15 after reboot with sd and cf both have proper dev entries Jul 29 12:21:51 great Jul 29 12:22:06 have you seen my logs on #4118 ? Jul 29 12:22:16 mtd and mmc are the slowest! Jul 29 12:22:29 on c7x0 Jul 29 12:27:09 ant|work: my sd cards are 1.9-1.94 MB/s according to "hdparm -tT" Jul 29 12:28:11 uh, I thought we could reach more than this... Jul 29 12:28:12 RP: hm, yes, lzop seems to compress about 10% worse than gzip, so it does indeed tip our kernel over the edge. Jul 29 12:28:31 * pb__ tries to find something else to modularise Jul 29 12:28:53 hrw: http://www.penguin.cz/~utx/zaurus/tests Jul 29 12:29:38 I guess that might be a problem for our rootfs as well actually, that partition is pretty full Jul 29 12:30:05 ant|work: you have c7x0 or cxx00? Jul 29 12:30:07 hrw: your results confirm these Jul 29 12:30:22 lardman|lunch: ping :) Jul 29 12:30:29 I have both but I'm working only on c7x0 atm Jul 29 12:30:55 ant|work: pxa25x is slow when it comes to sd Jul 29 12:31:04 ah, even... Jul 29 12:31:56 hrw: CF slot is a bit better but it's too precious (BT) Jul 29 12:32:34 I think I somewhere read SD is 4bits while CF is 8bits Jul 29 12:32:53 but the difference is risible Jul 29 12:33:00 ant|work: mmc is 1bit, sd is 1 or 4 bits, mmc+ is 1/4/8 bits Jul 29 12:33:06 something like that Jul 29 12:33:15 pxa25x is 1bit iirc, pxa27x can do 4 bits Jul 29 12:33:32 so, it's the worst Jul 29 12:34:30 hrw: yeah, I reckon Zaurus is a bit outdated in this domain... Jul 29 12:36:07 pb__: did you tried to disable calibration of delay loop? on my c760 is takes 0.2s Jul 29 12:37:37 hmm.. c760 is quite fast.. 9.28s to init... 5.03s is mount of rootfs Jul 29 12:38:33 hrw: did you identify the race condition? Jul 29 12:38:44 if one exist? Jul 29 12:39:23 * ant|work is talking about udevsettle (/etc/init.d/udev) Jul 29 12:39:43 today udevadm settle Jul 29 12:45:06 pb__: Like everything its a compromise. If you do write a kernel decompression patch I'd be interested though :) Jul 29 12:46:11 RP: sound modules do not register on c760 Jul 29 12:46:49 RP: modules loads, appear in dmesg and lsmod but /proc/asounds/cards is empty Jul 29 12:46:51 elo mickeyl Jul 29 12:47:23 hi hrw Jul 29 12:47:25 moin folks Jul 29 12:47:53 hrw: I have 0 [Corgi ]: WM8731 - Corgi Jul 29 12:48:30 hrw: Is this with mainline? Jul 29 12:48:49 hrw: Mainline needs a patch to register the I2C bus. Jul 29 12:48:56 hrw: cat /proc/asound/card0/id -> Corgi Jul 29 12:49:33 broonie: and I just wrote that patch part for corgi Jul 29 12:49:36 ant|work: 2.6.26? Jul 29 12:49:47 hrw: cat /proc/asound/card0/oss_mixer -> all values are zero Jul 29 12:50:13 hrw: 2.6.24 Jul 29 12:50:33 ant|work: 2.6.26 has some bugs here Jul 29 12:50:36 * hrw -> lunch Jul 29 12:56:36 03mickeyl 07org.oe.dev * ra65bd305... 10/ (1 conf/distro/include/angstrom-2007-for-openmoko.inc): angstrom-2007-for-openmoko.inc: depend generic feed-configs package Jul 29 12:58:36 hrw: Oh, I've already written that (it's blocked on rmk but I thought it was in OE already) Jul 29 12:59:39 03  07master * r347a8fdaba 10OE.dev/conf/distro/include/angstrom-2007-for-openmoko.inc: angstrom-2007-for-openmoko.inc: depend generic feed-configs package Jul 29 12:59:41 03  07org.openembedded.dev * r347a8fdaba 10OE.dev/conf/distro/include/angstrom-2007-for-openmoko.inc: angstrom-2007-for-openmoko.inc: depend generic feed-configs package Jul 29 13:00:52 broonie: there is for poodle and spitz Jul 29 13:01:08 Oh, right. My submitted version had all three. Jul 29 13:01:26 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5174/1 Jul 29 13:01:45 cool Jul 29 13:02:41 reflashed... Jul 29 13:04:12 now it needs to charge before will boot... Jul 29 13:04:16 ~curse zaurus batteries Jul 29 13:04:17 May the fleas of a thousand camels infest your most sensitive regions, zaurus batteries ! Jul 29 13:05:11 morning Jul 29 13:05:22 i need a suggestion Jul 29 13:05:23 time to refresh friendshop with US guys Jul 29 13:05:28 If that were to happen, I think the chemicals would kill the fleas :o Jul 29 13:05:35 i found out why my dbus stuff only runs on 2nd boot Jul 29 13:05:39 and subsequent boots Jul 29 13:05:47 mickeyl: you start too early? Jul 29 13:05:50 no, because we don't run dbus Jul 29 13:05:58 on first boot, that is Jul 29 13:06:06 because ipkg reconfigure installes the initscript Jul 29 13:06:13 because we are not doing offline postinst for dbus Jul 29 13:06:14 mickeyl: Ts, ts ;-) Jul 29 13:06:18 mickeyl: poky has fix for it Jul 29 13:06:26 oh Jul 29 13:06:30 mickeyl: today I pushed change to update-rc.d class Jul 29 13:06:31 tell me Jul 29 13:06:51 so update-rc.d stuff is at top of postinsts so image contain links before flashing... Jul 29 13:06:54 (yes, alphaone actually found out and it was worth the whole night) Jul 29 13:06:56 :) Jul 29 13:06:57 so you have all inits Jul 29 13:07:08 interesting. Jul 29 13:07:11 mickeyl: :-) Jul 29 13:07:12 let me try Jul 29 13:07:19 hrw: pushed already? Jul 29 13:07:32 mickeyl: r4976 Jul 29 13:07:46 Cool stuff. Jul 29 13:07:54 Everything coming together now. Jul 29 13:08:03 hmm Jul 29 13:08:10 ah Jul 29 13:08:13 "pushed in poky" !? Jul 29 13:08:18 not pushed in OE, right Jul 29 13:08:33 *g* Jul 29 13:08:42 since we're in #oe this was kind of misleading :D Jul 29 13:08:54 /invite mickeyl #poky Jul 29 13:08:57 hehe Jul 29 13:08:59 mickeyl: one more (navit_svn): binding_dbus:plugin_init:enter 1 \ binding_dbus:plugin_init:Failed to open connection to session message bus: Did not receive a reply. Jul 29 13:09:03 didnt see hrw commits for a while Jul 29 13:09:21 woglinde: it was some time when last time I build image from OE Jul 29 13:09:24 mickeyl: it does not receive gps data Jul 29 13:09:39 woglinde: I am waiting for git in OE land Jul 29 13:09:43 final git Jul 29 13:09:48 hrw: ok. then i will push that change from yours Jul 29 13:09:53 mickeyl: thx Jul 29 13:09:54 hrw I thought it Jul 29 13:10:02 ~curse zaurus batteries again Jul 29 13:10:03 May you be reincarnated as a Windows XP administrator, zaurus batteries again ! Jul 29 13:13:03 http://git.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=850eec5890105d0faaa0f6cb381142aec6bf022d <- this commit is breaking my build. INITRAMFS_IMAGE is set in my kernel bb file, but do_compile is not actually depending on INITRAMFS_TASK. Jul 29 13:15:34 * stephank can't find what's causing it though. Looks fine? Jul 29 13:26:22 mickeyl: btw, are you ok with the emails I drafted? Jul 29 13:26:34 * RP is determined to move this forwards... Jul 29 13:27:01 let me check now Jul 29 13:28:04 fine w/ me Jul 29 13:28:07 well written Jul 29 13:31:56 mickeyl: thanks. I'll send them out shortly :) Jul 29 13:32:39 rp hurry up Jul 29 13:33:45 Crofton: heh :) Jul 29 13:33:56 03mickeyl 07org.oe.dev * rbd558b4e... 10/ (1 classes/update-rc.d.bbclass): Jul 29 13:33:56 make sure update-rc is always executed in an offline postinst (from poky r4976) Jul 29 13:33:56 (Note: This fixes (among other things) dbus not being started on first boot) Jul 29 13:35:53 do we have some kind of flag "this is first boot"? Jul 29 13:36:08 03  07org.openembedded.dev * r5f04f6a67f 10OE.dev/classes/update-rc.d.bbclass: Jul 29 13:36:08 make sure update-rc is always executed in an offline postinst (from poky r4976) Jul 29 13:36:08 (Note: This fixes (among other things) dbus not being started on first boot) Jul 29 13:36:17 03  07master * r5f04f6a67f 10OE.dev/classes/update-rc.d.bbclass: Jul 29 13:36:17 make sure update-rc is always executed in an offline postinst (from poky r4976) Jul 29 13:36:17 (Note: This fixes (among other things) dbus not being started on first boot) Jul 29 13:36:28 I have one postinst which should not be called on first boot (as it was done during build time) but should be on upgrades... Jul 29 13:37:27 i'm afraid not Jul 29 13:37:29 familiar had that Jul 29 13:37:40 we can do that in bootmisc Jul 29 13:37:50 create a .firstbootdone Jul 29 13:37:52 somewhere Jul 29 13:38:00 then check for it Jul 29 13:38:03 I can do "touch /tmp/firstboot in opkg-configure script and remove that on end of that script" Jul 29 13:38:24 or that. but it may be interesting also for non postinst Jul 29 13:38:32 I always get so excited when someone uses the touch command Jul 29 13:38:47 hrw: postinstalls done at build time should not run again Jul 29 13:39:30 RP: during build time it use native tool to parse big xml. then on device (when you update package) it should parse that xml... Jul 29 13:39:41 RP: package is shared-mime-info to be exact Jul 29 13:39:54 parsing 1MB xml on device hurts Jul 29 13:39:58 hrw: So just let the instal complete on the build syste, Jul 29 13:40:13 It shouldn't then run at first boot if its already run Jul 29 13:40:17 yep Jul 29 13:40:23 ~lart me Jul 29 13:40:24 * ibot gets a hotmal account and SPAMs hrw Jul 29 13:41:01 it will be generated on host *each* time... Jul 29 13:41:04 ~lart me Jul 29 13:41:04 * ibot frags hrw with his BFG9000 Jul 29 13:41:34 auć Jul 29 13:41:35 at first run you make a ts calibration Jul 29 13:41:49 methril: what for? you can ship it precalculated Jul 29 13:42:03 hrw: it's a bit wrong on c7x0 btw Jul 29 13:42:17 right-top corner Jul 29 13:42:30 ant|work: feel free to send patch Jul 29 13:42:42 is C860 == C760? Jul 29 13:42:53 i'm going to try a patch for the gsmd Jul 29 13:43:04 ant|work: yes Jul 29 13:43:07 ~boxer Jul 29 13:43:07 extra, extra, read all about it, boxer is Sharp SL-C860, or a dog. in reality, this is an SL-C760 with a different case color. please don't support stupid marketing tricks. Jul 29 13:43:45 hrw: strange that nobody have seen this before then Jul 29 13:43:56 it's as always only me Jul 29 13:44:53 hrw: I would need an OE-controlled robot to exactly touch the ts, though! Jul 29 13:45:38 ant thats life Jul 29 13:46:43 woglinde: and more you live and more you rant! Jul 29 14:15:32 hi mickeyl Jul 29 14:15:47 hi pb__ Jul 29 14:15:53 i have got an interesting report Jul 29 14:16:09 didn't confirm yet Jul 29 14:16:13 "Workaround for screenshot error: "cannot be converted to ISO-8859-1 encoding"" Jul 29 14:16:21 The screen capture porgram (gpe-scap) fails to open /lib/libc.so, Jul 29 14:16:21 so I solved with: Jul 29 14:16:21 ln -s libc.so.6 /lib/libc.so Jul 29 14:16:30 sounds strange to me Jul 29 14:16:33 what do you think? Jul 29 14:17:27 that does sound very strange Jul 29 14:17:56 nothing has any business trying to open /lib/libc.so, and I can't think why the iconv code would want to. Jul 29 14:18:27 let me know if and when you can confirm that. Jul 29 14:18:56 I failed again to get qemu working last night, so if the libc.so thing doesn't solve your problem I will have to find a different way to investigate. Jul 29 14:22:07 d'oh Jul 29 14:22:11 confirmed. Jul 29 14:22:26 i just don't understand why though Jul 29 14:23:38 crazy stuff Jul 29 14:23:44 what version of glibc are you using? Jul 29 14:24:16 root@om-gta02:~# opkg info libc6 Jul 29 14:24:16 Package: libc6 Jul 29 14:24:16 Version: 2.6.1-r9 Jul 29 14:24:34 and can you capture the output of "strace -f gpe-scap 2>&1 | grep open" for me? Jul 29 14:28:42 actually, maybe a better idea, just run ldd on /usr/lib/gconv/ISO8859-1.so and see what it says Jul 29 14:47:31 doh, stupid X crashed on me there Jul 29 14:47:54 hmm Jul 29 14:47:57 which package provides ldd? Jul 29 14:48:13 ah, never mind Jul 29 14:48:16 it's ldd (sic!) Jul 29 14:49:08 heh Jul 29 14:49:52 root@om-gta02:/var/volatile/tmp/usr/bin# ./ldd /usr/lib/gconv/ISO8859-1.so Jul 29 14:49:52 libc.so.6 => /lib/libc.so.6 (0x40010000) Jul 29 14:49:52 /lib/ld-linux.so.3 (0x2a000000) Jul 29 14:50:12 well, that all seems in order Jul 29 14:50:16 (with the link in place) Jul 29 14:50:36 can you remove the link and check again? I don't think it should make any difference, but... you never know. Jul 29 14:51:11 d'oh Jul 29 14:51:14 were are up to something Jul 29 14:51:16 root@om-gta02:/var/volatile/tmp/usr/bin# ./ldd /usr/lib/gconv/ISO8859-1.so Jul 29 14:51:16 libc.so.6 => /lib/libc.so.6 (0x40010000) Jul 29 14:51:16 /lib/ld-linux.so.3 (0x2a000000) Jul 29 14:51:16 libc.so => not found Jul 29 14:51:22 oh ho Jul 29 14:51:30 well, that's no good Jul 29 14:51:46 try "readelf -a" on ISO8859-1.so, see if it actually has a DT_NEEDED for libc.so Jul 29 14:51:53 if yes, your gconv modules have been mis-linked somehow Jul 29 14:52:14 need to check the glibc do_compile log to find out why Jul 29 14:52:41 hmm, which package is readelf in? Jul 29 14:52:56 elfutils? Jul 29 14:53:08 use objdump Jul 29 14:53:08 yeah, but probably easiest to run readelf on your build host Jul 29 14:53:19 it's a generic program, the i386 version can read arm binaries Jul 29 14:53:21 ah Jul 29 14:53:22 k Jul 29 14:53:24 at least, to the extent that we need here Jul 29 14:55:22 http://rafb.net/p/gnUBaV44.html Jul 29 14:55:45 yah, there it is Jul 29 14:55:46 0x00000001 (NEEDED) Shared library: [libc.so] Jul 29 14:55:49 boo, hiss Jul 29 14:56:25 can you find the corresponding final link line in the glibc compile log? Jul 29 14:57:03 le me try Jul 29 14:58:33 http://rafb.net/p/0knm5H87.html ? Jul 29 14:59:52 hm, no, that looks like the final link for libc.so.6 itself Jul 29 14:59:57 you want the final link for ISO8859-1.so Jul 29 15:00:15 oh, that Jul 29 15:00:23 hmm, let me upload the whole log.do_compile Jul 29 15:00:36 good idea Jul 29 15:03:45 http://linuxtogo.org/~mickeyl/misc/log.do_compile.1432 Jul 29 15:03:49 11mb... Jul 29 15:06:08 okay Jul 29 15:06:18 * pb__ not scared of 11mb files Jul 29 15:08:41 * mwester is terrified of any file so large that emacs warns before loading it :-D Jul 29 15:09:35 Lol Jul 29 15:09:54 mwester: A real editor wouldn't warn you. It would just take it like a man Jul 29 15:10:09 *cough cough* VIM *cough cough* Jul 29 15:10:11 :D Jul 29 15:10:42 you must have some puny version of emacs, mine doesn't warn about that Jul 29 15:11:06 are you sure you didn't install the ladies' edition by mistake? Jul 29 15:12:05 mickeyl: well, hm, that final link seems to be in order as well Jul 29 15:12:24 it refers to /local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/libc.so, which I guess you'd expect, but doesn't seem to have any other extraneous libc.so references Jul 29 15:13:00 right Jul 29 15:13:25 so if you don't have any idea... i guess we're out of 'em then ? :) Jul 29 15:13:44 do you still have that build tree on hand? Jul 29 15:13:45 ~lart toolchain issues Jul 29 15:13:45 * ibot judo chops toolchain issues Jul 29 15:13:51 pb__: ya, the complete build tree is here Jul 29 15:14:03 if so, maybe you could try re-running that final link manually and inspecting the resulting ISO8859-1.so to see if it has the same issue Jul 29 15:14:18 can you cut me the line of out the log? Jul 29 15:14:30 ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -shared -static-libgcc -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-z,defs -B/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/csu/ -Wl,--version-script=gconv.map -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi -L/loca Jul 29 15:14:30 l/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/math -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/elf -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/dlfcn -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/nss -L Jul 29 15:14:30 /local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/nis -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/rt -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/resolv -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/cr Jul 29 15:14:35 ypt -L/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/nptl -Wl,-rpath-link=/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi:/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/math:/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linu Jul 29 15:14:40 x-gnueabi/elf:/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r9/build-arm-angstrom-linux-gnueabi/dlfcn:/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linu Jul 29 15:14:43 sorry about the wrapping Jul 29 15:14:45 ~fishslap xchat Jul 29 15:14:46 * ibot slaps xchat up side the head with a wet fish. Jul 29 15:14:55 hehe Jul 29 15:14:59 that's ok, thanks Jul 29 15:15:17 I'm going to search for -o ISO8859-1.so Jul 29 15:15:21 also, maybe use readelf on that libc.so file and see what it thinks its soname is Jul 29 15:15:39 remember that it's "-o /ISO8859-1.so" Jul 29 15:16:01 0x0000000e (SONAME) Library soname: [libc.so.6] Jul 29 15:16:11 ok, that's good Jul 29 15:16:49 so, if you still get the spurious libc.so output, I guess that must mean you have a busted linker Jul 29 15:17:05 what linker is angstrom using these days, gold or gnu ld? Jul 29 15:18:05 relinking... Jul 29 15:19:10 oh Jul 29 15:19:15 it's gone Jul 29 15:19:45 hrm Jul 29 15:19:49 no idea on the linker Jul 29 15:19:51 mysterious Jul 29 15:19:53 i suspect still gnu ld Jul 29 15:19:59 well, seems like the linker is exonerated anyway Jul 29 15:20:25 how complicated would it be to switch to gold? Jul 29 15:20:27 some other agency must be putting it there, though it's hard to imagine what Jul 29 15:20:37 not very, I think the two are basically compatible Jul 29 15:21:27 I remember looking at gold, then getting sidetracked by dolt. In the end I upgraded libtool instead Jul 29 15:21:54 pb__: gold does not support all architectures yet Jul 29 15:22:11 I seem to remember arm being one it doesn't support yet :/ Jul 29 15:22:24 pb__: least of all arm that is used commonly by OE community is not supported Jul 29 15:22:29 RP: hey Jul 29 15:22:39 hmm Jul 29 15:22:40 hi kergoth Jul 29 15:22:45 hi khem as well :) Jul 29 15:22:47 RP: did you read thesings problem Jul 29 15:22:55 ah, okay, in that case gold is probably not such a good option Jul 29 15:22:58 ok, i'm afraid i will insert that link in my postprocess for the time being Jul 29 15:23:01 khem: er, not sure Jul 29 15:23:02 postprocess_rootfs Jul 29 15:23:09 anyway, I think it's probably irrelevant to the case at hand Jul 29 15:23:30 pb__: down the lane may be gold is good option. It does speed up linking quite a bit Jul 29 15:23:39 and its multithreaded Jul 29 15:24:10 yeah Jul 29 15:24:21 RP: BB_STAMP_POLICY = "whitelist" Jul 29 15:24:25 and I get this error Jul 29 15:24:31 khem: ah, the circular dependency? Jul 29 15:24:32 ERROR: Task /home/kraj/work/oe/org.openembedded.dev/packages/eglibc/eglibc-initial_svn.bb (do_setscene) has circular dependency on /home/kraj/work/oe/org.openembedded.dev/packages/gcc/gcc-cross_4.2.4.bb (do_setscene) Jul 29 15:24:38 RP: maybe you would like to add arm support to gold rather than changing the override syntax :-} Jul 29 15:24:41 RP: yeah Jul 29 15:25:09 pb__: Neither are likely to happen with my time constraints at present ;-) Jul 29 15:25:13 heh, oh well Jul 29 15:25:41 khem: Do you understand the problem? Jul 29 15:25:50 I am trying to Jul 29 15:26:12 RP: what is different when you set policy to whitelist Jul 29 15:26:20 w.r.t bitbake Jul 29 15:26:59 khem: It checks the whole dependency tree for timestamp mismatches rather than stoping at .bb file boundaries like the tradntional bitbake Jul 29 15:27:05 RP: is there a whitelist somewhere that needs attention ? Jul 29 15:27:12 khem: Its not that simple Jul 29 15:27:23 khem: One second, I'm trying to find something Jul 29 15:28:42 eglibc-intial DEPENDS on virtual/${TARGET_PREFIX}gcc-initial and linux-libc-headers Jul 29 15:29:02 khem: Basically something in eglibc-initial is depending on something in gcc-cross and something in gcc-cross depends on something is also doing the reverse Jul 29 15:29:22 khem: Does this happen with glibc too? Jul 29 15:30:07 RP: yes thesing saw it with glibc 2.6.1 Jul 29 15:30:21 so why don't I see this with poky? :/ Jul 29 15:30:27 hmmm Jul 29 15:30:49 khem: Can you dump the task graph for something simple like bitbake busybox? Jul 29 15:30:57 (bitbake -g busybox) Jul 29 15:31:10 then share that somewhere Jul 29 15:31:57 RP: it would not let me generate that Jul 29 15:32:01 dies before Jul 29 15:32:42 khem: ok, can you generate it without the whitelist? Jul 29 15:32:50 yeah Jul 29 15:33:38 will take few mins now that I changed my local.conf Jul 29 15:35:01 * pb__ go home now Jul 29 15:35:02 later all Jul 29 15:35:44 pb__: bfn Jul 29 15:35:57 bye pb__ Jul 29 15:36:06 80% done Jul 29 15:36:22 hi khem Jul 29 15:36:38 khem: I have tried to run the powerpc toolchains, but I ran into libtool problems Jul 29 15:36:42 hey likewise long time no see Jul 29 15:36:51 likewise: hmmm Jul 29 15:37:51 RP: here is depends.dot Jul 29 15:37:53 http://rafb.net/p/pLkG3v71.html Jul 29 15:38:13 khem: task-depends.dot please Jul 29 15:38:59 RP: here it is http://rafb.net/p/aOXoMU53.html Jul 29 15:39:49 khem: I have to leave already... I will try to make some time to backtrack... Jul 29 15:41:14 likewise: ok Jul 29 15:41:21 RP: "eglibc-initial.do_package_write_ipk" -> "gcc-cross.do_package" Jul 29 15:41:39 khem: I was just about to paste that Jul 29 15:41:53 You need to track that down, that is the problem Jul 29 15:42:18 Perhaps eglibc-initial needs PACKAGES = "" ? Jul 29 15:43:01 Also monotone has finished as has parsing so I can reproduce this now Jul 29 15:43:06 RP: it means eglibc-initial.do_package_write_ipk needs gcc-cross.do_package ? Jul 29 15:43:20 yes Jul 29 15:43:25 weird Jul 29 15:43:40 I think that one comes from debian.bbclass Jul 29 15:44:06 but that isn't the real problem Jul 29 15:46:00 RP: I invoke CC in do_stage task for eglibc_initial Jul 29 15:46:09 could that create this ? Jul 29 15:46:14 yes Jul 29 15:46:19 hmmm Jul 29 15:46:48 but why gcc-cross and not gcc-cross-initial :/ Jul 29 15:46:56 then how can I push it to use CC that is previously provided by cross-gcc-initial Jul 29 15:47:16 yeah thats what I wonder Jul 29 15:47:26 well, I'd like to understand why gcc-cross and not gcc-cross-initial before we go any further Jul 29 15:47:44 yeah me too Jul 29 15:47:49 I have this DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial" Jul 29 15:47:55 in eglibc-initial bb Jul 29 15:48:48 and in gcc-cross-initial.inc I have this PROVIDES = "virtual/${TARGET_PREFIX}gcc-initial" Jul 29 15:49:11 ah there you see Jul 29 15:50:28 my bad I thought there was a spelling error but its not Jul 29 15:51:29 Its possible this is a bitbake bug... Jul 29 15:53:00 RP: hmm Jul 29 15:53:04 There are only a limited number of places places write_ipk is added as a dependency Jul 29 15:53:14 We should work out which one this happens in for starters Jul 29 15:53:26 just few lines above I am seeing "eglibc-initial.do_configure" -> "gcc-cross-initial.do_populate_staging" Jul 29 15:53:49 so it does depend on gcc-initial Jul 29 15:53:54 for some tasks Jul 29 15:53:55 Yes, which makes me wonder if this gcc-cross comes from somewhere else Jul 29 15:54:39 Basically this dependency has to come from debian.bbclass or package_ipk.bbclass Jul 29 15:55:22 * RP reads the comment at the top of debian.bbclass. Hmm :/ Jul 29 15:56:25 hmmm RDEPEND Jul 29 15:59:09 If PACKAGES is empty it should be ignoring all R* variables Jul 29 15:59:32 I wonder if bitbake actually knows that though Jul 29 16:00:10 bbl, bye Jul 29 16:03:13 khem: RRECOMMENDS = "" in glibc-initial.inc fixes that Jul 29 16:03:16 I think Jul 29 16:03:40 It could be argued this is a bitbake bug since it should be ignoring RRECOMMENDS and RDEPENDS if PACKAGES is empty Jul 29 16:05:47 ok, there is sound on 2.6.26/corgi now Jul 29 16:06:30 khem: This changes the problem to glibc and gcc-cross conflicting :) Jul 29 16:08:11 and poky does show the problem, I didn't see it due to a cache glitch Jul 29 16:09:38 khem: Its all down the the RRECOMMENDS = "libgcc" in glibc.inc Jul 29 16:09:51 morning Jul 29 16:10:02 hi kergoth`work Jul 29 16:10:56 khem: With whitelist and packaged staging combined, each depends on the other so one can't be installed without breaking the other's dependencies Jul 29 16:11:20 its bitbake saying it can't make consistent timestamps for that combination of options Jul 29 16:12:29 hey khem, ever run the gdb testsuite remotely? Jul 29 16:13:40 03koen 07org.oe.dev * rc0550ca4... 10/ (1 packages/linux/gumstix-kernel_2.6.21.bb): gumstix-kernel: use linux.inc Jul 29 16:14:11 03  07org.openembedded.dev * r15d99fd3fc 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: use linux.inc Jul 29 16:14:17 03  07master * r15d99fd3fc 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: use linux.inc Jul 29 16:14:21 bye guys Jul 29 16:21:49 RP: hmmm that change I see Jul 29 16:21:55 RP: now it makes sense Jul 29 16:22:15 RP: earlier in build order gcc built before glibc Jul 29 16:22:22 he khem Jul 29 16:22:45 but now glibc is building before final cross gcc Jul 29 16:22:53 RP have to run to work now Jul 29 16:22:58 see you Jul 29 16:23:03 bye khem Jul 29 16:23:05 woglinde: hi and bye Jul 29 16:23:13 woglinde: catch you laters Jul 29 16:23:17 yes Jul 29 16:23:31 I will send my patche for gcc to the ml Jul 29 16:23:37 for review Jul 29 17:05:53 cbrake: ping Jul 29 17:06:15 where is the CSS stuff defined? Jul 29 17:06:21 for the wiki? Jul 29 17:07:14 Mediawiki:Common.css Jul 29 17:07:20 Scheint es wohl zu sein Jul 29 17:13:22 03koen 07org.oe.dev * re886103e... 10/ (1 packages/linux/gumstix-kernel_2.6.21.bb): gumstix-kernel: set S Jul 29 17:13:57 is anyone using OE with an ixp4xx based machine? Jul 29 17:18:55 03  07org.openembedded.dev * re9ec9dc3c7 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: set S Jul 29 17:18:57 :) Only several thousand people. Jul 29 17:19:01 03  07master * re9ec9dc3c7 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: set S Jul 29 17:21:31 Unslung and SlugOS are built with OE, and Angstrom runs on the IXP4xx as well. Jul 29 17:23:02 right, I guess I meant to ask if anyone in the channel right now is using ixp4xx? Specifically I'm interested in NFS root on ixp4xx which would require NPE firmware being handled outside of the root filesystem Jul 29 17:29:00 so is there someone, one of the core devs perhaps, that wants to take the oz/oe domains off my hands? Jul 29 17:29:09 i'd like to do it before they're up for renewal, finally Jul 29 17:29:15 * Crofton kicks mickey|away Jul 29 17:29:43 kergoth`work, soon we should have an organization that can hold them Jul 29 17:29:56 there is some paperwork that needs completing Jul 29 17:30:00 mwester, also, I'm running into an issue building madwifi-ng regarding ath_hal.o having EABI v4 and xscale-be-elf.hal.o having EABI v0 Jul 29 17:30:07 this should occur before the renewal date :) Jul 29 17:30:27 k Jul 29 17:32:33 whats the status of the git switch? /me really should subscribe to the lists Jul 29 17:35:30 RP, is working on it Jul 29 17:35:35 he posted today Jul 29 17:35:38 k Jul 29 17:35:41 also, who do i email an mtn key to, again, mickeyl and koen? Jul 29 17:35:43 :) Jul 29 17:35:47 I think both Jul 29 17:36:35 k Jul 29 17:52:51 is there a way to specify extra compiler flags for a specific package in something like a local/machine/distro conf? Jul 29 17:53:34 tharvey hm? Jul 29 17:54:40 can I specify extra CFLAGS for a package in an upper conf file without having to modify the package recipe? ie, is there some sort of EXTRA_CFLAGS_ override? Jul 29 17:55:00 hm Jul 29 17:55:07 dont know Jul 29 17:55:25 maybee its working like USE_NLS you could try Jul 29 17:56:36 CFLAGS_packagename Jul 29 17:56:50 hm let me try with bitbake shell Jul 29 17:58:17 no sorry Jul 29 17:58:39 good morning kergoth`work Jul 29 17:58:47 hey pb_ Jul 29 17:59:30 woglinde, ok thx - don't think thats my issue anyway Jul 29 18:00:23 trying to figure out why madwifi-ng complains when linking the module about the hal's EABI=v0 and the rest of the module's EABI=v4 - my kernel config does define CONFIG_OABI_COMPAT Jul 29 18:00:55 hm I hope madwifi will be histroy with the new atheros driver Jul 29 18:01:54 no kidding.... Jul 29 18:02:16 ath5k is working well in my tests but it doesn't support AP yet Jul 29 18:03:30 tharvey: CONFIG_OABI_COMPAT is just for userspace binaries, it doesn't allow you to mix and match ABIs within the kernel Jul 29 18:05:37 tharvey: There should be patches specfiically for something like that in the OE package for the madwifi driver... Jul 29 18:06:43 The changes, IIRC, need to be made inside the madwifi sources and makefiles -- but I don't recall why it was not possible or practical to override. Jul 29 18:06:47 morning all Jul 29 18:09:20 pb_, ah... ok thanks Jul 29 18:10:33 mwester, well the issue is that the binary HAL is build with EABI=v0 (OABI?) but my cross compiler is using EABI - would not the only solution be to have my cross-compiler not use EABI Jul 29 18:11:04 wondering how slugos/unslung solves this Jul 29 18:11:48 tharvey: IIRC, we had to do something with the HAL binaries to select one (or to hack the elf header up) so that it could link with it. That stuff should all be in there, in the form of patches that are selected only if building for SlugOS or ixp4xx or something. Jul 29 18:12:07 mwester, ah... you mean WHACKELF? Jul 29 18:12:51 Ah, yes. That was one of the things that had to be hacked up. It removed floating point stuff that was preventing the linking from working, even when the driver used no floating point either. Jul 29 18:13:11 s/WHACKELF/WACKELF/ Jul 29 18:13:38 ok... I recall having to use that in the past... I didn't realize that the EABI stuff could simply be 'changed' in the elf header Jul 29 18:14:18 mwester, yes I see them now in the recipe... thanks! Jul 29 18:14:37 I don't know if it can; someone had to convince me that wackelf was an ok thing to do. Jul 29 18:17:46 it sounds so dirty heh.... Jul 29 18:17:57 probably ok to do behind closed doors Jul 29 18:18:46 hehe! Jul 29 18:19:10 mwester, I see the patches for VFP, are you sure the EABI stuff is in the header and can be changed without consequences as well? Jul 29 18:21:18 mwester, looks like wackelf is only for VFP manipulation in elf header Jul 29 18:34:18 tharvey: yes, it's for VFP. I didnt' say that tool would solve your problem, just that there was something similar that illustrated a technique . Jul 29 18:40:38 <_gpg_> hello Jul 29 20:08:44 03koen 07org.oe.dev * ra94d96e7... 10/ (1 packages/ffmpeg/ffmpeg_git.bb): ffmpeg git: bump SRCREV Jul 29 20:11:08 03  07org.openembedded.dev * r8deb60609a 10OE.dev/packages/ffmpeg/ffmpeg_git.bb: ffmpeg git: bump SRCREV Jul 29 20:11:13 03  07master * r8deb60609a 10OE.dev/packages/ffmpeg/ffmpeg_git.bb: ffmpeg git: bump SRCREV Jul 29 20:11:59 Laibsch: you find what you need? Jul 29 20:29:17 03koen 07org.oe.dev * re70bb851... 10/ (3 files in 2 dirs): firefox 3: fix idl stuff Jul 29 20:30:51 mwester, heh... turns out I think all I need is to add '--no-warn-mismatch' to get around the EABI version mismatch issue Jul 29 20:40:17 tharvey: :) That's almost too easy! Thanks for finding and fixing that, as I'll be needing that as soon as I upgrade SlugOS (I have an atheros card in my DSM-G600). Jul 29 20:40:33 re Jul 29 20:42:29 mwester, well actually I haven't found/fixed it completely yet... not sure why it isn't getting picked up by ath_hal/Makefile Jul 29 20:42:43 but I did find that it tells ld to not gripe about the mismatch Jul 29 20:42:50 03  07org.openembedded.dev * r539c5483d5 10OE.dev/: Jul 29 20:42:50 merge of 'a94d96e725d7b1b902a9b09b6c9628a3d59d5cf8' Jul 29 20:42:50 and 'e70bb85147c1884a42eb239c03283cb35fc63033' Jul 29 20:42:50 03  07org.openembedded.dev * rd4fa3ae63d 10OE.dev/packages/mozilla/ (3 files in 2 dirs): firefox 3: add patches from mamona Jul 29 20:42:50 03  07org.openembedded.dev * rccb6a7d7a4 10OE.dev/packages/mozilla/ (firefox.inc firefox_3.0.bb): firefox 3: fix idl stuff Jul 29 20:42:56 03  07master * rccb6a7d7a4 10OE.dev/packages/mozilla/ (firefox.inc firefox_3.0.bb): firefox 3: fix idl stuff Jul 29 20:42:58 03  07master * r539c5483d5 10OE.dev/: Jul 29 20:43:00 merge of 'a94d96e725d7b1b902a9b09b6c9628a3d59d5cf8' Jul 29 20:43:02 and 'e70bb85147c1884a42eb239c03283cb35fc63033' Jul 29 20:43:04 03  07master * rd4fa3ae63d 10OE.dev/packages/mozilla/ (3 files in 2 dirs): firefox 3: add patches from mamona Jul 29 20:43:16 mwester, I suppose its because OE's not using madwifi-ng's build system to make it... its building it as an out-of-tree kernel module Jul 29 20:44:00 Is there a better way we should do this, perhaps? Jul 29 20:45:40 not sure yet... still trying to get OE to pass in the --no-warn-mismatch Jul 29 20:45:51 to make sure thats all that's needed Jul 29 20:46:06 and not sure why this isn't an issue for unslung etc Jul 29 20:46:46 PACKAGE_LDFLAGS += "--no-warn-mismatch" in the recipe isn't working Jul 29 20:51:25 hm... how do I add LDFLAGS to a recipe? Jul 29 21:03:04 mwester, ya, its that the toplevel Makefile for madwifi does a '$(MAKE) -C $(KERNELPATH) SUBDIRS=$(shell pwd) modules' which doesn't pass any LDFLAGS Jul 29 21:08:56 Tartarus: yes I have run the gdb testsuite in cross env Jul 29 21:09:09 Got the dejagnurc magic around by chance? Jul 29 21:09:27 Tartarus: hmmm probably not here right now Jul 29 21:09:31 but I will have a look Jul 29 21:09:38 I found an old ref, but it didn't get far, cross-compiled one of the host programs Jul 29 21:09:40 thanks Jul 29 21:10:18 Tartarus: yeah I think mostly cross gcc one worked but there are some more quirks Jul 29 21:10:48 RP: how should be solve that circular dep problem Jul 29 21:10:53 RP: /awa Jul 29 21:11:59 Currently I think if we need various utilities from glibc then we need yet another glibc build phase Jul 29 21:12:24 like memusage etc. Jul 29 21:13:28 thesing: dropping RRECOMMENDS += "libgcc" from glibc.inc should solve the problem you reported Jul 29 21:14:24 khem: that's kind of funny Jul 29 21:14:38 thesing: I know Jul 29 21:14:39 but it's also no real option Jul 29 21:14:58 any other ideas? Jul 29 21:15:00 or drop BB_STAMP_POLICY for now Jul 29 21:15:40 yeah. But its a neat feature. Jul 29 21:15:52 thesing: until we fix it Jul 29 21:16:01 then it can be reintroduced Jul 29 21:16:25 I dont use it. I just wanted to try it and it didn't work ;) Jul 29 21:16:46 thesing: I see Jul 29 21:17:05 But I think I would use it. Jul 29 21:18:03 thesing: I think another method to fix it would be to introduce glibc-intermediate step Jul 29 21:20:38 and build glibc after cross-gcc as we did before Jul 29 21:24:25 there has to be some other way. Doesn't the whitelist stuff help? Jul 29 21:26:27 thesing: may be bitbake could do somethign I dont know Jul 29 21:26:37 problem is clear to me Jul 29 21:26:56 currently cross-gcc depends on glibc Jul 29 21:27:20 and by saying RRECOMMEND on libgcc we make glibc depend on cross-gcc Jul 29 21:27:32 because libgcc comes from cross-gcc Jul 29 21:27:41 hence the problem Jul 29 21:28:05 Do we know if all images need libgcc? Jul 29 21:28:26 thesing: in general nptl glibc will need it Jul 29 21:28:36 and linuxthreads is thing of past Jul 29 21:29:20 the we could add the "RRECOMMEND libgcc if glibc and nptl" to task-base Jul 29 21:29:44 hmmm will that solve the problem Jul 29 21:30:10 maybe we can find some better package that could depend on libgcc Jul 29 21:30:32 gcc-intermediate also produces libgcc Jul 29 21:30:47 but its a temporary libgcc Jul 29 21:31:11 does it differ from the final one? Jul 29 21:31:52 it doesnt Jul 29 21:32:23 I could make libgcc provided by both gcc-cross and gcc-cross-intermediate Jul 29 21:32:35 but that will create duplicate provides Jul 29 21:32:47 I think bitbake will not like it Jul 29 21:36:45 no, that would be a bad idea. gcc-cross-intermediate shouldn't be generating any packages. Jul 29 21:37:04 frankly, I think that the original addition of a libgcc RRECOMMEND to glibc was a bad idea, for the reasons I mentioned at the time. Jul 29 21:38:14 I would strongly encourage you to add the libgcc dependency only to the packages that actually need it, i.e. to the packages that are linked with nptl and call pthread_cancel. Jul 29 21:39:44 mtn is just getting exponentially slower :( Jul 29 21:41:13 pb_: yeah that would be perfect place Jul 29 21:41:34 Crofton: I agree with you Jul 29 21:42:07 Crofton: I think it heard about getting replaced by git so it has no motivation to impress us anymore :) Jul 29 21:42:16 yeah Jul 29 21:43:07 we should convert the database quickly to git least it should decide to corrupt that too :=) Jul 29 21:43:52 thesing: do you remember which package was needing pthread_cancel Jul 29 21:44:02 when you did not have libgcc on target Jul 29 21:45:07 pb_: I dont think we keep nptl'ness global Jul 29 21:45:17 I don't know. I saw this message several times until the boot finished to a kernel panic Jul 29 21:46:06 khem: probably not, but glibc could stash some flag in the staging area Jul 29 21:46:12 pb_: we poke GLIBC_ADDONS currently to decide if we are compiling nptl Jul 29 21:47:06 thesing: do u have log handy ? Jul 29 21:47:25 I remember you mentioned it on IRC Jul 29 21:48:24 unfortunatly not. Jul 29 21:50:24 khem: or, alternatively (less intrusively but perhaps less neatly) examine libc.so.6 to see if it contains the NPTL banner. Jul 29 21:52:18 i.e. if it says "Native POSIX Threads Library by Ulrich Drepper et al" then it's nptl, if it says "linuxthreads-0.10 by Xavier Leroy" then it's linuxthreads. Jul 29 21:54:58 incidentally, I think you also want to be setting RRECOMMENDS_${PN}, not just RRECOMMENDS. Jul 29 21:55:25 pb_: yeah Jul 29 21:55:26 the original change, as currently applied to glibc, will mean that all the subpackages also have a recommendation on libgcc Jul 29 21:55:54 pb_: or may be we can do like debian add the NEEDED for nptl unconditionally in the elf header Jul 29 21:57:32 I'm not sure I follow. What exactly does debian do there? Jul 29 21:57:55 I mean in the mklibs code Jul 29 21:59:12 I think its /bin/sh thats needing the pthread_cancel so creating RECOMMEND in busybox will be good Jul 29 21:59:31 really? I find it hard to believe that /bin/sh is really multithreaded. Jul 29 22:00:56 iirc, neither busybox nor bash links with -lpthread at all Jul 29 22:02:38 but in principle yes, if some package P requires pthread_cancel then that same package P should be the one to RRECOMMEND (or even RDEPEND) on libgcc. Jul 29 22:09:03 pb_: its exceptions not threads really I have not verified if its really busybox but provided it starts complaining early enough that is a prime suspect Jul 29 22:09:30 khem: what exceptions do you mean? Jul 29 22:11:02 C++ programs should be getting linked with libgcc anyway, and exception handling in C is pretty much a fringe pursuit. Jul 29 22:11:30 again I would be quite surprised if either busybox or bash was exception-using. Jul 29 22:11:45 unwinding Jul 29 22:11:57 right, but unwinding triggered by what? Jul 29 22:12:24 afaik, there is precisely one situation in which you can end up needing the unwinder in an "unexpected" situation, and that's when you call pthread_cancel and nptl needs to dlopen() it. Jul 29 22:12:51 for all other unwinding scenarios you should already have libgcc present as a hard dependency. Jul 29 22:14:34 I dont know if it directly uses it but in past I have seen that on arm the wrapped functions were called more often Jul 29 22:15:26 the unwind functions might be called even when exception might be thrown Jul 29 22:15:39 not only when exception is really thrown Jul 29 22:17:32 that sounds bizarre. do you have a test case? Jul 29 22:18:13 what counts as "might be thrown" in this situation? surely you don't mean that you think the unwinder is called on every function invocation that might possibly throw? Jul 29 22:20:17 yes Jul 29 22:20:31 but I might be confusing sjlj model here Jul 29 22:20:45 at least that was the case before Jul 29 22:20:50 yeah, I was about to ask if you were thinking of sjlj-exceptions Jul 29 22:21:01 in the case of sjlj, there is no unwinding anyway so this is all irrelevant Jul 29 22:21:24 but you're right, in that case you do end up calling setjmp for any catch block Jul 29 22:21:37 or, well, __builtin_setjmp anyway Jul 29 22:21:40 yeah Jul 29 22:22:15 so, that's a non-issue in that case. Jul 29 22:22:42 hmmm yes unless we are using sjlj which I think for EABI atleast we dont Jul 29 22:22:53 either you're using sjlj, in which case the unwinder doesn't enter into it, or you're using eabi/dwarf exceptions, in which case the unwinder is only triggered when an exception is thrown. Jul 29 22:23:25 no, even for sjlj it is a non issue. there is no unwinding in sjlj, that's the whole difference between sjlj and dwarf/eabi exception handling. Jul 29 22:24:29 in any case, if this was an issue for sjlj exceptions it would have shown up years ago. Jul 29 22:25:47 but, anyway, you're right that eabi uses eabi exceptions (!) rather than sjlj, so even if it was an issue with sjlj that wouldn't be the cause of the problem at hand. Jul 29 22:26:55 hmmm I was think that libgcc needs libc.so Jul 29 22:27:30 yes, it usually does Jul 29 22:27:54 that's the whole reason why we (used to) have glibc-intermediate, so that you could build libgcc.so against a correct libc.so Jul 29 22:28:23 libgcc1 doesn't have any libc.so dependencies but libgcc2 does Jul 29 22:28:51 or, at least, libgcc1 didn't use to. possibly it does nowadays, I haven't checked. Jul 29 22:31:29 pb_: yeah right Jul 29 22:32:01 it did not need real libc.so though Jul 29 22:32:19 it needed it to be there but did not really use funcitons from libc.so Jul 29 22:32:59 but I am thinking about finding the right package to stick in the libgcc RRECOMMEND Jul 29 22:33:27 sounds a good solution instead of asking it in glibc Jul 29 22:33:35 like I said earlier, I am fairly convinced that it would be the packages that call pthread_cancel. Jul 29 22:33:45 unless some code in glibc is invoking these routines which need libgcc Jul 29 22:34:01 I have yet to be persuaded that there are any other circumstances where libgcc is required but not already present. Jul 29 22:34:42 some code flow inside libc itself that invokes libgcc ? maybe Jul 29 22:34:50 inside nptl, yes Jul 29 22:35:12 see unwind-forceunwind.c for example Jul 29 22:35:42 handle = __libc_dlopen ("libgcc_s.so.1"); Jul 29 22:35:55 if (handle == NULL Jul 29 22:35:57 [...] Jul 29 22:36:04 ) Jul 29 22:36:04 __libc_fatal ("libgcc_s.so.1 must be installed for pthread_cancel to work\n"); Jul 29 22:37:52 linuxthreads doesn't have that requirement, mostly because linuxthreads doesn't make any effort to unwind the thread stack when it's cancelled Jul 29 22:42:23 right Jul 29 22:42:42 pb_: is there any other path than pthread_cancel that could reach to this point Jul 29 22:42:49 not that I know of Jul 29 22:43:08 I don't think there is any other operation that will cause an implicit thread cancellation Jul 29 22:44:04 so, I repeat my assertion from earlier on :-} Jul 29 22:44:06 I would strongly encourage you to add the libgcc dependency only to the packages that actually need it, i.e. to the packages that are linked with nptl and call pthread_cancel. Jul 29 22:44:18 * pb_ zzz now Jul 29 22:44:30 pb_: good night Jul 29 22:44:33 pb_: sleep well Jul 29 22:44:54 if you can find any other concrete examples of packages that genuinely need libgcc and don't link with it explicitly, I will happily change my mind :-) Jul 29 22:44:57 in that case, send mail to the list Jul 29 22:44:58 I will try to find out if thats the only place that can call this Jul 29 22:45:00 night all Jul 29 22:52:56 how can I make a "do_configure_prepend() {" function in a recipe $MACHINE specific? Jul 29 22:53:27 so that it is only ran when I use that $MACHINE Jul 29 22:57:17 there is linux-kaiser_2.6.24+git.bb and I have a different machine that uses the same kernel but needs a different defconfig. currently kaiser gets the .config by coyping arch/arm/configs/htckaiser_defconfig in do_configure_prepend Jul 29 23:12:18 good night Jul 30 00:12:46 dcordes: bb.data.getVar('MACHINE',d) in ['your machine'] Jul 30 00:41:04 thesing: I tried a console-image with eglibc without RRECOMMEND on libgcc and I still see libgcc is pulled in. What is image you tried Jul 30 00:41:42 I used console image too. But my machine is oabi. Jul 30 00:55:46 thesing: oabi ah hmmm Jul 30 00:56:44 thesing: I think we should get rid of libgcc recommend in glibc instead do it like pb_ suggested Jul 30 00:57:58 I think its quite complicated to find out which packages use pthread_cancel. Well fgrep works of course. Jul 30 00:58:28 thesing: yeah let me see if I can find Jul 30 00:59:21 as long as libgcc gets into my images I'm happy ;) Jul 30 01:05:57 thesing: can you post you depends.dot somewhere generated by bitbake -g console-image ? Jul 30 01:10:22 khem: http://www2.informatik.hu-berlin.de/~tkunze/task-depends.dot Jul 30 01:11:02 thesing: depends.dot plz Jul 30 01:13:16 http://www2.informatik.hu-berlin.de/~tkunze/depends.dot Jul 30 01:13:32 ok. Time to sleep. Nite all. Jul 30 01:18:37 gn thes **** ENDING LOGGING AT Wed Jul 30 02:59:56 2008