| 00:06.19 | khem | thesing: ping |
| 00:08.36 | thesing | khem: pong |
| 00:09.47 | khem | thesing: I did not try BB_POLICY stuff though |
| 00:10.04 | khem | I thought this should have worked |
| 00:10.48 | thesing | I didn't do a clean build. But I don't think this matters. |
| 00:11.30 | thesing | i.e. I did a normal build switched the BB_POLICY stuff on, and tried to build sth. |
| 00:11.33 | khem | circular dependency is happening because earlier glibc was built before gcc-cross and there was no dep for cross-gcc on glibc instead it used glibc-intermediate |
| 00:12.07 | khem | but now glibc is build prior to gcc-cross so there is a dep for cross-gcc on glibc |
| 00:12.51 | khem | I guess this change is confusing bitbake RP might tell more |
| 00:13.05 | khem | but a clean build should work |
| 00:13.29 | thesing | I think there is a whitelist somewhere to solve such stuff. |
| 00:13.46 | khem | hmmm yeah let me look for it |
| 00:13.56 | thesing | a clean build only works until glibc is changed. then it will fail again. |
| 00:14.44 | khem | hmm |
| 00:19.21 | thesing | ok time for bed. Bye |
| 00:19.29 | khem | thesing: good night ! |
| 00:19.35 | khem | are u in europe |
| 00:20.29 | khem | so if I use BB_STAMP_POLICY="whitelist" I should see the problem. I will try it out thx |
| 00:27.34 | *** join/#oe exastra (n=go@75.148.80.90) |
| 00:36.18 | *** join/#oe fredl (n=gruberm@chello212186029093.tirol.surfer.at) |
| 00:40.38 | *** join/#oe ferdl (n=gruberm@chello212186029093.tirol.surfer.at) |
| 00:43.13 | *** join/#oe greentux (n=lemke@Z78d7.z.pppool.de) |
| 00:54.52 | *** join/#oe fredl (n=gruberm@chello212186029093.tirol.surfer.at) |
| 00:59.49 | *** part/#oe waite (n=bwaite@c-24-91-252-221.hsd1.ma.comcast.net) |
| 01:10.11 | *** join/#oe HellDragon (n=jd@Wikipedia/HellDragon) |
| 01:15.48 | *** join/#oe jtaji (n=jtaji@unaffiliated/astro76) |
| 01:26.01 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 01:26.36 | *** join/#oe wrobbie (n=rob@203.117.215.163) |
| 02:14.02 | *** part/#oe josch (n=josch@host140.natpool.mwn.de) |
| 02:21.52 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
| 02:51.36 | *** join/#oe HellDragon (n=jd@Wikipedia/HellDragon) |
| 02:51.41 | *** join/#oe Hrw (n=Hrw@c33-187.icpnet.pl) |
| 03:02.25 | *** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas) |
| 03:03.31 | *** join/#oe Hrw (n=Hrw@c33-187.icpnet.pl) |
| 03:43.27 | *** join/#oe Gnutoo (n=gnutoo@host6-25-dynamic.25-79-r.retail.telecomitalia.it) |
| 03:43.28 | *** join/#oe Sargun (n=Sargun@atarack/staff/sargun) |
| 03:45.23 | Sargun | How do I update my OE repos? |
| 03:48.34 | Sargun | mtn: warning: protocol error while processing peer monotone.openembedded.org: 'received network error: remote public key hash '549ba2d291b2bd57cb5ed3fec1c6627e9aa4b567' is unknown' |
| 03:48.34 | Sargun | mtn: bytes in | bytes out | revs in |
| 03:48.34 | Sargun | mtn: 104 | 347 | 0 |
| 03:48.34 | Sargun | mtn: error: processing failure while talking to peer monotone.openembedded.org, disconnecting |
| 03:48.36 | Sargun | Ideas? |
| 03:53.30 | Sargun | Why did you guys choose Monotone? |
| 03:57.22 | khem | Sargun: what is your update command |
| 03:57.50 | Sargun | I deleted it and ran: |
| 03:57.52 | Sargun | <PROTECTED> |
| 03:57.56 | Sargun | that seems to be working |
| 03:58.17 | khem | alright |
| 04:01.45 | *** join/#oe jilles_ (i=jilles@unaffiliated/jilles) |
| 04:02.00 | rsalveti | you could clone from the git server |
| 04:02.11 | rsalveti | I guess it's getting everything from monotone |
| 04:03.07 | *** join/#oe incandescant (n=incandes@89.145.97.73) |
| 04:04.19 | Sargun | this is oging to take a while: |
| 04:04.20 | Sargun | mtn: 1.5 M | 1.1 M | 260/3001 | 66/745 |
| 04:04.37 | Sargun | after 10 minutes |
| 04:05.42 | khem | Sargun: your database snapshot might be old |
| 04:06.18 | khem | Sargun: you can download the latest db and that might reduce the number of changesets it needs to pull |
| 04:07.15 | Sargun | Why does monotone use a huge big blob? |
| 04:19.53 | *** join/#oe shabble (n=shabble@89.145.97.182) |
| 04:49.19 | *** join/#oe mbuf (n=shakthim@61.16.248.242) |
| 04:52.36 | *** join/#oe hillct (n=hillct@cpe-024-211-242-232.nc.res.rr.com) |
| 05:03.51 | *** join/#oe DarthWader (n=zathras@vorphalack.dialup.corbina.ru) |
| 06:22.55 | *** join/#oe pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au) |
| 06:27.53 | methril | morning |
| 06:50.30 | *** join/#oe bazbel1 (n=a0192809@nat/ti/x-5c932e14131a36a6) |
| 06:50.42 | *** join/#oe cyberdeck (n=molter@iss60.vlsi.informatik.tu-darmstadt.de) |
| 06:51.38 | *** join/#oe trickie|work (n=trickie@basesoft.xs4all.nl) |
| 06:57.15 | *** join/#oe diego_at_work (i=5960ae7b@gateway/web/ajax/mibbit.com/x-0f83a3018716e476) |
| 07:01.00 | *** join/#oe denix1 (n=denix@82.116.198.137) |
| 07:01.23 | *** part/#oe denix1 (n=denix@82.116.198.137) |
| 07:02.43 | *** join/#oe bazbell (n=a0192809@nat/ti/x-8f11f6b3c012cfc3) |
| 07:09.54 | *** join/#oe Kryczek (n=kryczek@jade.gemnetworks.com) |
| 07:10.31 | *** join/#oe kwek (n=kwek@188.Red-213-97-48.staticIP.rima-tde.net) |
| 07:11.02 | *** join/#oe BabelO (n=Fabrice@unaffiliated/babelo) |
| 07:18.22 | *** join/#oe Bernardo (n=Bernardo@sourcemage/Bernardo) |
| 07:21.08 | *** join/#oe rob_w (n=bob@M9cb6.m.pppool.de) |
| 07:40.06 | *** join/#oe wrobbie (n=rob@203.117.215.163) |
| 07:47.14 | *** join/#oe anothermike (n=wittke@130.75.242.230) |
| 07:51.20 | *** join/#oe Genesis (n=Ronan@AMontsouris-153-1-31-87.w86-212.abo.wanadoo.fr) |
| 07:56.24 | Genesis | bonjour |
| 07:57.02 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C06D.access.telenet.be) |
| 07:58.03 | josch|nsn | salut Genesis |
| 07:58.42 | Genesis | guten tag josch|nsn |
| 07:58.46 | josch|nsn | :D |
| 08:03.31 | *** join/#oe NineX (i=ninex@gentoo.netzone.kom.pl) |
| 08:07.19 | *** join/#oe smancke (n=smancke@gate.tarent.de) |
| 08:11.30 | *** join/#oe rschuster (n=rob@e178080043.adsl.alicedsl.de) |
| 08:25.39 | *** join/#oe Genesis (n=Ronan@AMontsouris-153-1-25-238.w86-212.abo.wanadoo.fr) |
| 08:29.38 | hrw | morning |
| 08:30.04 | *** join/#oe DarthWader (n=sith@unaffiliated/darthwader) |
| 08:30.12 | methril | morning |
| 08:30.17 | methril | hrw thanks for the poky tip |
| 08:30.26 | methril | it worked |
| 08:31.13 | methril | now i have other things not working (gsmd and some keymap's ) but poky it's better with icons :) |
| 08:34.22 | *** join/#oe florian__ (n=fuchs@217.146.132.69) |
| 08:36.57 | XorA | morning |
| 08:37.00 | hrw | ;) |
| 08:50.06 | RP | morning all |
| 08:50.36 | XorA | yo RP |
| 08:51.58 | pb__ | florian: good morning |
| 08:52.16 | florian | hi all |
| 08:53.24 | *** join/#oe dcordes (n=dcordes@unaffiliated/dcordes) |
| 09:12.20 | XorA | hmm, If I was a microSD card where would I hide |
| 09:12.44 | RP | XorA: Easy, In the last place you'll look |
| 09:12.45 | *** join/#oe lrg (n=liam@lumison.wolfsonmicro.com) |
| 09:14.47 | josch|nsn | hehe this is the reason why i NEVER EVER remove the microSD card from any of my embedded devices - they get lost immediately |
| 09:14.56 | hrw | ;) |
| 09:17.52 | XorA | found some in old Neo phones |
| 09:28.35 | hrw | ;) |
| 09:28.56 | hrw | one of my neos still has that 128M card which openmoko put in package |
| 09:29.04 | XorA | trouble with moving house, everything is in the wrong place |
| 09:29.09 | XorA | including my bathroom :-( |
| 09:30.26 | florian | heh |
| 09:30.50 | josch|nsn | XorA: you scare me - i move in a month too :D |
| 09:31.14 | XorA | I keep wandering to where the stairs should be, and I find myself in my spare bedroom |
| 09:31.26 | XorA | then I remeber Im in a flat now |
| 09:31.31 | hrw | josch|nsn: I am moving in september |
| 09:31.45 | josch|nsn | the 128MB card from my neo was one of the first that i never saw again... |
| 09:31.49 | XorA | hrw: bigger place? |
| 09:33.54 | josch|nsn | i hope my new internet provider will not be a crappy one with max 16MBit/s and stuff |
| 09:33.58 | josch|nsn | dinner time! |
| 09:34.32 | hrw | XorA: much |
| 09:34.41 | hrw | josch|nsn: argh! |
| 09:34.59 | hrw | do not like when people say what kind of net they have... |
| 09:35.17 | hrw | here 3Mbps/512kbps costs me nearly 50 euro... |
| 09:35.32 | hrw | but at new flat 10Mbps/1Mbps would be <30 eur |
| 09:36.34 | XorA | hrw: nice |
| 09:36.41 | XorA | hrw: 10/1.3 is 18GBp |
| 09:36.46 | XorA | hrw: for me |
| 09:37.07 | hrw | ~change 18 gbp to pln |
| 09:37.22 | florian | XorA: that's quite good, not that easy to get much up here |
| 09:37.32 | *** join/#oe jekhor (n=jek@87.252.242.24) |
| 09:37.45 | hrw | 21.8383 gbp for me |
| 09:37.47 | XorA | florian: ADSL2+ so if I was nearer exchange it could get to 24M |
| 09:38.03 | florian | XorA: nice |
| 09:38.19 | methril | in Spain we're not as lucky as you |
| 09:38.27 | XorA | pay another 2 GBP and I can switch some download for upload and get 2.4M up |
| 09:38.29 | florian | In fact that was the first thing I checked searching for a house ;) |
| 09:38.48 | XorA | chose this flat so he could get the same ISP :-D |
| 09:39.03 | hrw | 149 pln (36.6 gbp, 46,4 eur) for 20/2 |
| 09:47.49 | *** join/#oe ribbits (n=bob@91.84.60.59) |
| 09:49.30 | hrw | XorA: how goes mdev usage? |
| 09:50.06 | XorA | hrw: phone boots are works |
| 09:50.18 | XorA | hrw: lost automounting SD at the moment though |
| 09:52.58 | XorA | hrw: and I had to return to using detect-tsdevice |
| 09:53.08 | hrw | XorA: tried to use mdev for populating and udev for hotplug? |
| 09:53.29 | XorA | hrw: thats what I am doing, but mmc is cold plugged |
| 09:53.36 | XorA | hrw: so gets handled by mdev |
| 09:54.06 | hrw | a yes.. |
| 09:54.06 | XorA | hrw: same with touchscreen |
| 09:54.27 | XorA | hrw: mdev can run scripts though, just need to write one |
| 09:55.06 | XorA | hrw: mdev.conf http://rafb.net/p/7xx53y98.html |
| 09:55.08 | hrw | XorA: "udevadm trigger --system-match=block"? |
| 09:55.50 | XorA | hrw: I was kind of hoping to do away with udev altogether, its seems to be really slow at what it does |
| 09:56.43 | hrw | XorA: openmoko boot is slow anyway |
| 09:57.10 | XorA | hrw: thats why we want more speed |
| 10:00.22 | *** join/#oe AvengerMoJo (n=alex@61.14.130.209) |
| 10:02.55 | hrw | XorA: merged poky changes? |
| 10:04.11 | XorA | hrw: no, is that just the first boot taring of /dev? |
| 10:04.38 | hrw | thats just udev... we also have some improvements in initscripts etc |
| 10:04.50 | hrw | 1s here, 2s there etc |
| 10:07.12 | XorA | hrw: current discussion with OM is for the official distro to not use initscripts |
| 10:08.14 | hrw | one big linuxrc? |
| 10:08.57 | XorA | yeah |
| 10:09.16 | hrw | what if I would like to install distcc? |
| 10:09.26 | hrw | or other thing with initscript? |
| 10:11.22 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
| 10:11.45 | XorA | hrw: we are making a phone, not a general purpose linux device, its upto the community to make it that |
| 10:12.09 | hrw | ko |
| 10:12.24 | broonie | You can always arrange things so that init scripts are run but all the init scripts in the standard image are merged into oneÂ. |
| 10:13.18 | XorA | broonie: or that :-) |
| 10:13.49 | XorA | at the moment I am interested in using busybox as much as possible to save on flash reads which we found are expensive |
| 10:33.01 | *** join/#oe jconnoll1 (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) |
| 10:33.48 | pb__ | out of interest, what is your current boot time? |
| 10:34.00 | pb__ | also working on boot time improvements for another product |
| 10:35.09 | hrw | pb__: month ago openmoko had 2m53s |
| 10:44.02 | RP | We've been improving boot time in poky too - down to about 20 seconds on the zoom |
| 10:45.02 | hrw | btw - someone played with ubifs? |
| 10:45.13 | pb__ | ok, great. is that 20 seconds to X and all applications running? |
| 10:48.11 | RP | pb_: 20 seconds to the X desktop finishing loading |
| 10:48.30 | pb__ | righto |
| 10:48.46 | RP | There is background work that happens afterwards like dropbear starting etc |
| 10:48.58 | pb__ | 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. |
| 10:49.18 | hrw | pb__: kernel time? |
| 10:49.24 | RP | I think that was about 7 seconds when I measures 20 |
| 10:49.40 | pb__ | right, thanks |
| 10:49.47 | RP | I've cut that to about 4 now |
| 10:50.00 | pb__ | ah, very good |
| 10:50.16 | pb__ | I think ours is somewhere around 5-6 so there is probably scope for improvement :-) |
| 10:50.46 | pb__ | our main offenders seem to be usb and jffs2 |
| 10:50.50 | RP | It was doing stuff with dhcp and USB RNDIS which I got rid of |
| 10:50.52 | pb__ | no surprise about the latter I guess |
| 10:51.02 | RP | Also, I'm optiing for boot from mmc which helps a lot |
| 10:51.12 | pb__ | ah right, I see |
| 10:51.21 | pb__ | I don't have that luxury, I must boot from nand. |
| 10:51.46 | hrw | pb__: yaffs or ubifs then? |
| 10:51.51 | *** join/#oe lardman (n=lardman@enpc-smm11.bath.ac.uk) |
| 10:52.00 | lardman | hrw: ping |
| 10:52.03 | RP | hrw: From the above I'd suspect jffs2 ;-) |
| 10:52.08 | hrw | pong lardman |
| 10:52.13 | pb__ | yaffs doesn't compress, so that's no good |
| 10:52.26 | RP | pb_: You have lzo compression enabled? |
| 10:52.28 | diego_at_work | jffs2 is really slow |
| 10:52.34 | lardman | hrw: Do you know who was after me re Octave? |
| 10:52.40 | pb__ | I don't know much about ubifs but it might be worth a try |
| 10:52.53 | pb__ | RP: I think we're using zlib rather than lzo but I'm not certain offhand |
| 10:53.04 | hrw | lardman: will check logs in ~20m |
| 10:53.20 | RP | pb__: lzo is tons faster, I know because I wrote it for that exact reason ;-) |
| 10:53.36 | pb__ | ah, excellent :-) |
| 10:53.45 | hrw | lardman: frikker was the person |
| 10:53.51 | diego_at_work | on gp2x yaffs improved boot time versus jffs2 |
| 10:54.00 | lardman | hrw: thanks |
| 10:54.03 | lardman | frikker: ping |
| 10:54.03 | pb__ | there's also the jffs2 "central summary" patches which I've been meaning to try, although annoyingly there is no offline summarizer for that. |
| 10:55.06 | pb__ | also considering changing to a read-only filesystem for the rootfs, since we never actually need to write to it in a production environment. |
| 10:55.27 | pb__ | I'm not sure whether there are any existing read-only, compressed filesystems that will perform well on nand though |
| 10:55.34 | *** join/#oe bazbell (n=a0192809@nat/ti/x-4d2639280eae2e72) |
| 10:55.35 | RP | pb__: As an idea of the speedup lzo decreaed the boot time of the n800 by about 25% |
| 10:55.45 | pb__ | excellent, I'll have to try that |
| 10:56.59 | pb__ | first though I need to fix my lirc problems |
| 10:57.02 | pb__ | stabs samsung |
| 10:57.40 | pb__ | bbiab, heading to the hardware lab for a while |
| 11:06.24 | *** join/#oe pb_lab (n=pb@castle.reciva.com) |
| 11:07.23 | *** join/#oe Laibsch (n=Laibsch@ip-62-143-12-162.hsi.ish.de) |
| 11:09.03 | *** join/#oe woglinde (i=woglinde@e178088144.adsl.alicedsl.de) |
| 11:09.21 | woglinde | hi |
| 11:12.41 | diego_at_work | hi |
| 11:12.49 | woglinde | hi diego |
| 11:12.53 | woglinde | hm right |
| 11:12.54 | woglinde | apr |
| 11:13.01 | woglinde | *GÃ |
| 11:13.04 | woglinde | aeh *g* |
| 11:13.13 | woglinde | sorry but I had to fix libstdc++ |
| 11:13.21 | diego_at_work | :D |
| 11:13.30 | woglinde | otherwise I didnt had a compiler |
| 11:14.11 | diego_at_work | at the end i've tried some fix, that did'nt work |
| 11:15.18 | diego_at_work | and just gone with this: http://bugs.openembedded.net/show_bug.cgi?id=4148#c1 |
| 11:15.39 | diego_at_work | (it works, but it's not a solution) |
| 11:21.46 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 11:41.34 | pb_lab | right, phew, lirc working now |
| 11:41.44 | pb_lab | stabs samsung, SLOB, crazy kernel h4x0rs |
| 11:42.25 | woglinde | hi pb |
| 11:42.46 | pb_lab | hi woglinde |
| 11:42.49 | woglinde | hm isnt infrared dead? |
| 11:43.03 | woglinde | hm besides remote control |
| 11:43.14 | pb_lab | indeed |
| 11:43.27 | pb_lab | RP: by the way, would lzo be a win for zImage decompression as well? |
| 11:43.50 | pb_lab | it occurs to me that we probably have about 0.5 second or so spent on that. |
| 11:45.21 | *** join/#oe piroko (n=jeremy@pohl.ececs.uc.edu) |
| 11:46.46 | woglinde | hi piroko |
| 11:50.49 | *** join/#oe wittke_ (n=wittke@130.75.33.77) |
| 11:50.57 | piroko | woglinde: Mornin |
| 11:54.35 | pb__ | hm, drat, loading usb-ohci-hcd as a module doesn't seem to be a win |
| 11:54.41 | pb__ | stabs usb |
| 11:54.46 | woglinde | hehe |
| 11:54.54 | pb__ | I wonder what it's doing in there. |
| 11:54.57 | woglinde | pb ultra secret projekt? |
| 11:56.14 | pb__ | me? no, not really secret, just trying to make the boot time faster on our devices. |
| 11:56.31 | woglinde | ah |
| 11:56.41 | woglinde | hm what is it now? |
| 11:57.30 | hrw | pb__: but you can load module and do something at that time... |
| 11:57.43 | hrw | pb__: or load module after starting user stuff? |
| 11:57.45 | pb__ | 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 |
| 11:58.28 | pb__ | hrw: well, yes, that's what I hoped. but it doesn't seem to work that way. |
| 11:58.44 | woglinde | pb yes sys-rc and the shell scripts consume a lot |
| 11:58.49 | woglinde | sysv-rc |
| 11:59.25 | pb__ | yah |
| 11:59.29 | pb__ | I need to abolish sysvinit |
| 11:59.39 | woglinde | hm you could try minit |
| 12:00.09 | woglinde | dont which services you start *g* |
| 12:00.19 | *** join/#oe otavio (n=otavio@debian/developer/otavio) |
| 12:00.21 | pb__ | none, really |
| 12:00.26 | woglinde | hi otavio |
| 12:00.33 | pb__ | I think we're probably going to end up writing our own custom /sbin/init |
| 12:00.40 | woglinde | yeah |
| 12:00.47 | woglinde | thats probably the best |
| 12:02.04 | pb__ | it looks like jffs2 mount is currently taking almost exactly 1 second so that should be another obvious candidate for improvement |
| 12:02.52 | pb__ | 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. |
| 12:02.57 | hrw | ~curse networkmanager crap |
| 12:02.58 | ibot | May the fleas of a thousand camels infest your most sensitive regions, networkmanager crap ! |
| 12:03.34 | pb__ | oh, mtd bad block scan of course, that takes 0.13 seconds. |
| 12:03.55 | pb__ | in theory I guess I could delay the bad block scan for everything except the rootfs partition until later in boot-up. |
| 12:04.41 | pb__ | probably only gonna save me about 0.07 seconds though, I'm not sure it will be worth the effort. |
| 12:05.11 | RP | pb__: Yes, lzo fo kernel image decompression would be a win |
| 12:05.35 | woglinde | morning rp |
| 12:05.59 | RP | It doesn't quite quite as good compression but its about 10 times faster at decompression |
| 12:06.01 | RP | hi woglinde |
| 12:06.41 | pb__ | ok, great, I'll give that a try as well |
| 12:07.15 | pb__ | 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. |
| 12:07.43 | pb__ | on the other hand if lzo is 10x faster than zlib then it will probably be a net win even in that case. |
| 12:07.57 | hrw | argh... who invented NM should be shot |
| 12:08.08 | woglinde | hrw seems you have a good day |
| 12:08.50 | hrw | woglinde: my c7x0 has my home wifi in wpa-supplicant config file so 'ifup wlan0' is able to connect to wifi network. |
| 12:09.24 | hrw | 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 |
| 12:09.48 | woglinde | hehe |
| 12:10.00 | woglinde | make tatoo out of it |
| 12:10.01 | woglinde | hahah |
| 12:10.06 | pb__ | heh |
| 12:10.06 | piroko | Brilliant |
| 12:12.02 | hrw | maybe I do not understand use of NM but I prefer to have it removed from all my devices |
| 12:12.07 | *** join/#oe wittke_ (n=wittke@130.75.242.230) |
| 12:13.43 | hrw | XorA: on my c7x0 with mmc card plugged I have working /dev/mmcblk* entries after reset with dev.tar trick |
| 12:13.54 | piroko | hrw: It is meant to look useful but instead generally piss you off |
| 12:14.08 | hrw | XorA: but I cant test it with cf and sd inserted - lost all cf cards |
| 12:14.38 | XorA | hrw: you re-run udev trigger? |
| 12:14.49 | hrw | piroko: for people who change ethernet<>wifi<>gsm often it maybe is useful.. |
| 12:15.19 | hrw | XorA: yes - but only for some subsystems |
| 12:15.54 | RP | hrw: I've yet to be convinced its working 100% right :/ |
| 12:16.15 | hrw | RP: I know ;] |
| 12:16.28 | hrw | hm.. alix have 2gb cf... |
| 12:16.30 | *** join/#oe ant|work (n=ant|work@host214-85-static.34-85-b.business.telecomitalia.it) |
| 12:16.38 | woglinde | hi ant |
| 12:16.48 | ant|work | hi woglinde |
| 12:16.59 | ant|work | morning channel |
| 12:17.11 | ant|work | hrw: sweet to see your c7x0 is ON |
| 12:17.44 | hrw | ant|work: and even works with 2.6.26 |
| 12:17.50 | ant|work | hrw: I'm eagerly waiting your udev_124 fixes |
| 12:18.02 | ant|work | new prob of today: no /dev/dsp |
| 12:18.06 | hrw | 55% battery is max for current battery |
| 12:18.14 | ant|work | ough |
| 12:18.23 | ant|work | mine is almost dead too |
| 12:18.39 | *** join/#oe rob_w (n=bob@Ma16a.m.pppool.de) |
| 12:19.30 | ant|work | hrw: ah, I have /dev/dsp |
| 12:19.50 | ant|work | oss_audio: failed to open audio device /dev/dsp |
| 12:19.57 | ant|work | must be a new bug then |
| 12:20.15 | ant|work | (I was testing flite_time) |
| 12:20.16 | hrw | ant|work: 16 usd for new battery at amazon |
| 12:21.15 | hrw | after reboot with sd and cf both have proper dev entries |
| 12:21.50 | ant|work | great |
| 12:22.06 | ant|work | have you seen my logs on #4118 ? |
| 12:22.16 | ant|work | mtd and mmc are the slowest! |
| 12:22.29 | ant|work | on c7x0 |
| 12:25.49 | *** join/#oe Laibsch (n=Laibsch@ip-62-143-12-162.hsi.ish.de) |
| 12:27.09 | hrw | ant|work: my sd cards are 1.9-1.94 MB/s according to "hdparm -tT" |
| 12:28.11 | ant|work | uh, I thought we could reach more than this... |
| 12:28.12 | pb__ | RP: hm, yes, lzop seems to compress about 10% worse than gzip, so it does indeed tip our kernel over the edge. |
| 12:28.31 | pb__ | tries to find something else to modularise |
| 12:28.53 | ant|work | hrw: http://www.penguin.cz/~utx/zaurus/tests |
| 12:29.37 | pb__ | I guess that might be a problem for our rootfs as well actually, that partition is pretty full |
| 12:30.05 | hrw | ant|work: you have c7x0 or cxx00? |
| 12:30.07 | ant|work | hrw: your results confirm these |
| 12:30.22 | frikker | lardman|lunch: ping :) |
| 12:30.28 | ant|work | I have both but I'm working only on c7x0 atm |
| 12:30.54 | hrw | ant|work: pxa25x is slow when it comes to sd |
| 12:31.04 | ant|work | ah, even... |
| 12:31.56 | ant|work | hrw: CF slot is a bit better but it's too precious (BT) |
| 12:32.33 | ant|work | I think I somewhere read SD is 4bits while CF is 8bits |
| 12:32.53 | ant|work | but the difference is risible |
| 12:32.59 | hrw | ant|work: mmc is 1bit, sd is 1 or 4 bits, mmc+ is 1/4/8 bits |
| 12:33.06 | hrw | something like that |
| 12:33.15 | hrw | pxa25x is 1bit iirc, pxa27x can do 4 bits |
| 12:33.32 | ant|work | so, it's the worst |
| 12:34.30 | ant|work | hrw: yeah, I reckon Zaurus is a bit outdated in this domain... |
| 12:35.54 | *** join/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
| 12:36.07 | hrw | pb__: did you tried to disable calibration of delay loop? on my c760 is takes 0.2s |
| 12:37.37 | hrw | hmm.. c760 is quite fast.. 9.28s to init... 5.03s is mount of rootfs |
| 12:37.53 | *** join/#oe chouimat|work (n=dieu@209.217.106.98) |
| 12:38.04 | *** join/#oe aloisiojr (n=aloisio@200.184.118.132) |
| 12:38.33 | ant|work | hrw: did you identify the race condition? |
| 12:38.44 | ant|work | if one exist? |
| 12:39.23 | ant|work | is talking about udevsettle (/etc/init.d/udev) |
| 12:39.43 | ant|work | today udevadm settle |
| 12:45.06 | RP | pb__: Like everything its a compromise. If you do write a kernel decompression patch I'd be interested though :) |
| 12:46.05 | *** join/#oe dijenerate (n=dijenera@72.22.142.107) |
| 12:46.10 | hrw | RP: sound modules do not register on c760 |
| 12:46.49 | hrw | RP: modules loads, appear in dmesg and lsmod but /proc/asounds/cards is empty |
| 12:46.51 | hrw | elo mickeyl |
| 12:47.22 | mickeyl | hi hrw |
| 12:47.25 | mickeyl | moin folks |
| 12:47.53 | ant|work | hrw: I have 0 [Corgi ]: WM8731 - Corgi |
| 12:48.30 | broonie | hrw: Is this with mainline? |
| 12:48.49 | broonie | hrw: Mainline needs a patch to register the I2C bus. |
| 12:48.56 | ant|work | hrw: cat /proc/asound/card0/id -> Corgi |
| 12:49.33 | hrw | broonie: and I just wrote that patch part for corgi |
| 12:49.35 | hrw | ant|work: 2.6.26? |
| 12:49.47 | ant|work | hrw: cat /proc/asound/card0/oss_mixer -> all values are zero |
| 12:50.12 | ant|work | hrw: 2.6.24 |
| 12:50.33 | hrw | ant|work: 2.6.26 has some bugs here |
| 12:50.36 | hrw | -> lunch |
| 12:56.36 | CIA-24 | 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 |
| 12:58.36 | broonie | hrw: Oh, I've already written that (it's blocked on rmk but I thought it was in OE already) |
| 12:59.39 | CIA-24 | 03 <mickeyl@openembedded.org> 07master * r347a8fdaba 10OE.dev/conf/distro/include/angstrom-2007-for-openmoko.inc: angstrom-2007-for-openmoko.inc: depend generic feed-configs package |
| 12:59.41 | CIA-24 | 03 <mickeyl@openembedded.org> 07org.openembedded.dev * r347a8fdaba 10OE.dev/conf/distro/include/angstrom-2007-for-openmoko.inc: angstrom-2007-for-openmoko.inc: depend generic feed-configs package |
| 13:00.52 | hrw | broonie: there is for poodle and spitz |
| 13:01.07 | broonie | Oh, right. My submitted version had all three. |
| 13:01.26 | broonie | http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5174/1 |
| 13:01.45 | hrw | cool |
| 13:02.41 | hrw | reflashed... |
| 13:04.11 | hrw | now it needs to charge before will boot... |
| 13:04.16 | hrw | ~curse zaurus batteries |
| 13:04.17 | ibot | May the fleas of a thousand camels infest your most sensitive regions, zaurus batteries ! |
| 13:05.11 | mickeyl | morning |
| 13:05.22 | mickeyl | i need a suggestion |
| 13:05.23 | hrw | time to refresh friendshop with US guys |
| 13:05.28 | stephank | If that were to happen, I think the chemicals would kill the fleas :o |
| 13:05.35 | mickeyl | i found out why my dbus stuff only runs on 2nd boot |
| 13:05.39 | mickeyl | and subsequent boots |
| 13:05.47 | hrw | mickeyl: you start too early? |
| 13:05.50 | mickeyl | no, because we don't run dbus |
| 13:05.58 | mickeyl | on first boot, that is |
| 13:06.06 | mickeyl | because ipkg reconfigure installes the initscript |
| 13:06.13 | mickeyl | because we are not doing offline postinst for dbus |
| 13:06.14 | alphaone | mickeyl: Ts, ts ;-) |
| 13:06.18 | hrw | mickeyl: poky has fix for it |
| 13:06.26 | mickeyl | oh |
| 13:06.29 | hrw | mickeyl: today I pushed change to update-rc.d class |
| 13:06.30 | mickeyl | tell me |
| 13:06.51 | hrw | so update-rc.d stuff is at top of postinsts so image contain links before flashing... |
| 13:06.54 | mickeyl | (yes, alphaone actually found out and it was worth the whole night) |
| 13:06.56 | mickeyl | :) |
| 13:06.57 | hrw | so you have all inits |
| 13:07.08 | mickeyl | interesting. |
| 13:07.11 | alphaone | mickeyl: :-) |
| 13:07.12 | mickeyl | let me try |
| 13:07.19 | mickeyl | hrw: pushed already? |
| 13:07.32 | hrw | mickeyl: r4976 |
| 13:07.46 | alphaone | Cool stuff. |
| 13:07.54 | alphaone | Everything coming together now. |
| 13:08.02 | mickeyl | hmm |
| 13:08.10 | mickeyl | ah |
| 13:08.13 | mickeyl | "pushed in poky" !? |
| 13:08.18 | mickeyl | not pushed in OE, right |
| 13:08.32 | woglinde | *g* |
| 13:08.42 | mickeyl | since we're in #oe this was kind of misleading :D |
| 13:08.54 | hrw | <PROTECTED> |
| 13:08.56 | mickeyl | hehe |
| 13:08.58 | ant|work | 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. |
| 13:09.03 | woglinde | didnt see hrw commits for a while |
| 13:09.20 | hrw | woglinde: it was some time when last time I build image from OE |
| 13:09.24 | ant|work | mickeyl: it does not receive gps data |
| 13:09.38 | hrw | woglinde: I am waiting for git in OE land |
| 13:09.43 | hrw | final git |
| 13:09.47 | mickeyl | hrw: ok. then i will push that change from yours |
| 13:09.53 | hrw | mickeyl: thx |
| 13:09.53 | woglinde | hrw I thought it |
| 13:10.02 | hrw | ~curse zaurus batteries again |
| 13:10.03 | ibot | May you be reincarnated as a Windows XP administrator, zaurus batteries again ! |
| 13:13.03 | stephank | 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. |
| 13:15.34 | stephank | can't find what's causing it though. Looks fine? |
| 13:26.22 | RP | mickeyl: btw, are you ok with the emails I drafted? |
| 13:26.34 | RP | is determined to move this forwards... |
| 13:27.00 | mickeyl | let me check now |
| 13:28.04 | mickeyl | fine w/ me |
| 13:28.06 | mickeyl | well written |
| 13:31.55 | RP | mickeyl: thanks. I'll send them out shortly :) |
| 13:32.17 | *** join/#oe birunko (n=birunko@200.184.118.132) |
| 13:32.38 | Crofton | rp hurry up |
| 13:33.45 | RP | Crofton: heh :) |
| 13:33.56 | CIA-24 | 03mickeyl 07org.oe.dev * rbd558b4e... 10/ (1 classes/update-rc.d.bbclass): |
| 13:33.56 | CIA-24 | make sure update-rc is always executed in an offline postinst (from poky r4976) |
| 13:33.56 | CIA-24 | (Note: This fixes (among other things) dbus not being started on first boot) |
| 13:34.34 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 13:35.53 | hrw | do we have some kind of flag "this is first boot"? |
| 13:36.08 | CIA-24 | 03 <mickeyl@openembedded.org> 07org.openembedded.dev * r5f04f6a67f 10OE.dev/classes/update-rc.d.bbclass: |
| 13:36.08 | CIA-24 | make sure update-rc is always executed in an offline postinst (from poky r4976) |
| 13:36.08 | CIA-24 | (Note: This fixes (among other things) dbus not being started on first boot) |
| 13:36.16 | CIA-24 | 03 <mickeyl@openembedded.org> 07master * r5f04f6a67f 10OE.dev/classes/update-rc.d.bbclass: |
| 13:36.17 | CIA-24 | make sure update-rc is always executed in an offline postinst (from poky r4976) |
| 13:36.17 | CIA-24 | (Note: This fixes (among other things) dbus not being started on first boot) |
| 13:36.28 | hrw | I have one postinst which should not be called on first boot (as it was done during build time) but should be on upgrades... |
| 13:37.27 | mickeyl | i'm afraid not |
| 13:37.29 | mickeyl | familiar had that |
| 13:37.40 | mickeyl | we can do that in bootmisc |
| 13:37.49 | mickeyl | create a .firstbootdone |
| 13:37.51 | mickeyl | somewhere |
| 13:38.00 | mickeyl | then check for it |
| 13:38.03 | hrw | I can do "touch /tmp/firstboot in opkg-configure script and remove that on end of that script" |
| 13:38.23 | mickeyl | or that. but it may be interesting also for non postinst |
| 13:38.32 | piroko | I always get so excited when someone uses the touch command |
| 13:38.47 | RP | hrw: postinstalls done at build time should not run again |
| 13:39.29 | hrw | RP: during build time it use native tool to parse big xml. then on device (when you update package) it should parse that xml... |
| 13:39.40 | hrw | RP: package is shared-mime-info to be exact |
| 13:39.54 | hrw | parsing 1MB xml on device hurts |
| 13:39.57 | *** join/#oe jconnolly (n=jconnoll@ip-66-80-197-243.atl.megapath.net) |
| 13:39.58 | RP | hrw: So just let the instal complete on the build syste, |
| 13:40.13 | RP | It shouldn't then run at first boot if its already run |
| 13:40.16 | hrw | yep |
| 13:40.23 | hrw | ~lart me |
| 13:40.23 | ibot | gets a hotmal account and SPAMs hrw |
| 13:41.00 | hrw | it will be generated on host *each* time... |
| 13:41.03 | hrw | ~lart me |
| 13:41.03 | ibot | frags hrw with his BFG9000 |
| 13:41.34 | hrw | auÄ |
| 13:41.35 | methril | at first run you make a ts calibration |
| 13:41.48 | hrw | methril: what for? you can ship it precalculated |
| 13:42.03 | ant|work | hrw: it's a bit wrong on c7x0 btw |
| 13:42.17 | ant|work | right-top corner |
| 13:42.29 | hrw | ant|work: feel free to send patch |
| 13:42.41 | ant|work | is C860 == C760? |
| 13:42.53 | methril | i'm going to try a patch for the gsmd |
| 13:43.04 | hrw | ant|work: yes |
| 13:43.06 | hrw | ~boxer |
| 13:43.07 | ibot | 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. |
| 13:43.45 | ant|work | hrw: strange that nobody have seen this before then |
| 13:43.55 | ant|work | it's as always only me |
| 13:44.53 | ant|work | hrw: I would need an OE-controlled robot to exactly touch the ts, though! |
| 13:45.38 | woglinde | ant thats life |
| 13:46.42 | ant|work | woglinde: and more you live and more you rant! |
| 13:50.39 | *** join/#oe rsalveti (n=salveti@200.184.118.132) |
| 13:53.18 | *** join/#oe Gnutoo (n=gnutoo@host6-25-dynamic.25-79-r.retail.telecomitalia.it) |
| 13:56.29 | *** join/#oe CSMan (n=csman@bas1-montreal42-1178047204.dsl.bell.ca) |
| 14:09.16 | *** join/#oe mhnoyes (n=mhnoyes@adsl-99-151-252-43.dsl.pltn13.sbcglobal.net) |
| 14:15.31 | pb__ | hi mickeyl |
| 14:15.46 | mickeyl | hi pb__ |
| 14:15.52 | mickeyl | i have got an interesting report |
| 14:16.09 | mickeyl | didn't confirm yet |
| 14:16.13 | mickeyl | "Workaround for screenshot error: "cannot be converted to ISO-8859-1 encoding"" |
| 14:16.21 | mickeyl | The screen capture porgram (gpe-scap) fails to open /lib/libc.so, |
| 14:16.21 | mickeyl | so I solved with: |
| 14:16.21 | mickeyl | ln -s libc.so.6 /lib/libc.so |
| 14:16.30 | mickeyl | sounds strange to me |
| 14:16.33 | mickeyl | what do you think? |
| 14:17.26 | pb__ | that does sound very strange |
| 14:17.56 | pb__ | nothing has any business trying to open /lib/libc.so, and I can't think why the iconv code would want to. |
| 14:18.27 | pb__ | let me know if and when you can confirm that. |
| 14:18.56 | pb__ | 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. |
| 14:22.06 | mickeyl | d'oh |
| 14:22.11 | mickeyl | confirmed. |
| 14:22.26 | mickeyl | i just don't understand why though |
| 14:22.54 | *** join/#oe CosmicPenguin (n=nobody@163.181.251.103) |
| 14:23.38 | pb__ | crazy stuff |
| 14:23.44 | pb__ | what version of glibc are you using? |
| 14:24.16 | mickeyl | root@om-gta02:~# opkg info libc6 |
| 14:24.16 | mickeyl | Package: libc6 |
| 14:24.16 | mickeyl | Version: 2.6.1-r9 |
| 14:24.34 | pb__ | and can you capture the output of "strace -f gpe-scap 2>&1 | grep open" for me? |
| 14:28.42 | pb__ | actually, maybe a better idea, just run ldd on /usr/lib/gconv/ISO8859-1.so and see what it says |
| 14:34.31 | *** join/#oe greentux (n=lemke@ip-217-18-181-130.static.reverse.dsi.net) |
| 14:41.32 | *** join/#oe josch (n=josch@host140.natpool.mwn.de) |
| 14:47.23 | *** join/#oe pb__ (n=pb@castle.reciva.com) |
| 14:47.31 | pb__ | doh, stupid X crashed on me there |
| 14:47.54 | mickeyl | hmm |
| 14:47.57 | mickeyl | which package provides ldd? |
| 14:48.13 | mickeyl | ah, never mind |
| 14:48.15 | mickeyl | it's ldd (sic!) |
| 14:49.08 | pb__ | heh |
| 14:49.52 | mickeyl | root@om-gta02:/var/volatile/tmp/usr/bin# ./ldd /usr/lib/gconv/ISO8859-1.so |
| 14:49.52 | mickeyl | <PROTECTED> |
| 14:49.52 | mickeyl | <PROTECTED> |
| 14:50.12 | pb__ | well, that all seems in order |
| 14:50.16 | mickeyl | (with the link in place) |
| 14:50.36 | pb__ | can you remove the link and check again? I don't think it should make any difference, but... you never know. |
| 14:50.49 | *** join/#oe NineX (i=ninex@gentoo.netzone.kom.pl) |
| 14:51.11 | mickeyl | d'oh |
| 14:51.14 | mickeyl | were are up to something |
| 14:51.15 | mickeyl | root@om-gta02:/var/volatile/tmp/usr/bin# ./ldd /usr/lib/gconv/ISO8859-1.so |
| 14:51.15 | mickeyl | <PROTECTED> |
| 14:51.15 | mickeyl | <PROTECTED> |
| 14:51.15 | mickeyl | <PROTECTED> |
| 14:51.22 | pb__ | oh ho |
| 14:51.30 | pb__ | well, that's no good |
| 14:51.46 | pb__ | try "readelf -a" on ISO8859-1.so, see if it actually has a DT_NEEDED for libc.so |
| 14:51.53 | pb__ | if yes, your gconv modules have been mis-linked somehow |
| 14:52.14 | pb__ | need to check the glibc do_compile log to find out why |
| 14:52.41 | mickeyl | hmm, which package is readelf in? |
| 14:52.56 | mickeyl | elfutils? |
| 14:53.08 | hrw | use objdump |
| 14:53.08 | pb__ | yeah, but probably easiest to run readelf on your build host |
| 14:53.18 | pb__ | it's a generic program, the i386 version can read arm binaries |
| 14:53.20 | *** join/#oe |cepera| (n=cepera@86.110.163.29) |
| 14:53.21 | mickeyl | ah |
| 14:53.22 | mickeyl | k |
| 14:53.24 | pb__ | at least, to the extent that we need here |
| 14:55.22 | mickeyl | http://rafb.net/p/gnUBaV44.html |
| 14:55.44 | pb__ | yah, there it is |
| 14:55.46 | pb__ | 0x00000001 (NEEDED) Shared library: [libc.so] |
| 14:55.49 | pb__ | boo, hiss |
| 14:56.25 | pb__ | can you find the corresponding final link line in the glibc compile log? |
| 14:56.48 | *** join/#oe gnutoo_ (n=gnutoo@host14-133-dynamic.40-79-r.retail.telecomitalia.it) |
| 14:57.02 | mickeyl | le me try |
| 14:58.33 | mickeyl | http://rafb.net/p/0knm5H87.html ? |
| 14:59.52 | pb__ | hm, no, that looks like the final link for libc.so.6 itself |
| 14:59.56 | pb__ | you want the final link for ISO8859-1.so |
| 15:00.15 | mickeyl | oh, that |
| 15:00.23 | mickeyl | hmm, let me upload the whole log.do_compile |
| 15:00.36 | pb__ | good idea |
| 15:03.45 | mickeyl | http://linuxtogo.org/~mickeyl/misc/log.do_compile.1432 |
| 15:03.48 | mickeyl | 11mb... |
| 15:06.14 | pb__ | okay |
| 15:06.18 | pb__ | not scared of 11mb files |
| 15:07.57 | *** join/#oe piroko (n=jeremy@pohl.ececs.uc.edu) |
| 15:08.41 | mwester | is terrified of any file so large that emacs warns before loading it :-D |
| 15:09.35 | piroko | Lol |
| 15:09.53 | piroko | mwester: A real editor wouldn't warn you. It would just take it like a man |
| 15:10.09 | piroko | *cough cough* VIM *cough cough* |
| 15:10.11 | piroko | :D |
| 15:10.41 | pb__ | you must have some puny version of emacs, mine doesn't warn about that |
| 15:11.06 | pb__ | are you sure you didn't install the ladies' edition by mistake? |
| 15:12.05 | pb__ | mickeyl: well, hm, that final link seems to be in order as well |
| 15:12.24 | pb__ | 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 |
| 15:12.59 | mickeyl | right |
| 15:13.25 | mickeyl | so if you don't have any idea... i guess we're out of 'em then ? :) |
| 15:13.44 | pb__ | do you still have that build tree on hand? |
| 15:13.45 | mickeyl | ~lart toolchain issues |
| 15:13.45 | ibot | judo chops toolchain issues |
| 15:13.51 | mickeyl | pb__: ya, the complete build tree is here |
| 15:14.02 | pb__ | 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 |
| 15:14.17 | mickeyl | can you cut me the line of out the log? |
| 15:14.30 | pb__ | 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 |
| 15:14.30 | pb__ | 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 |
| 15:14.30 | pb__ | /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 |
| 15:14.35 | pb__ | 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 |
| 15:14.40 | pb__ | 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 |
| 15:14.43 | pb__ | sorry about the wrapping |
| 15:14.45 | pb__ | ~fishslap xchat |
| 15:14.46 | ibot | ACTION slaps xchat up side the head with a wet fish. |
| 15:14.55 | mickeyl | hehe |
| 15:14.58 | mickeyl | that's ok, thanks |
| 15:15.17 | mickeyl | I'm going to search for -o ISO8859-1.so |
| 15:15.20 | pb__ | also, maybe use readelf on that libc.so file and see what it thinks its soname is |
| 15:15.38 | pb__ | remember that it's "-o <long pathname>/ISO8859-1.so" |
| 15:15.53 | *** join/#oe piroko (n=jeremy@pohl.ececs.uc.edu) |
| 15:16.02 | mickeyl | <PROTECTED> |
| 15:16.11 | pb__ | ok, that's good |
| 15:16.48 | pb__ | so, if you still get the spurious libc.so output, I guess that must mean you have a busted linker |
| 15:17.05 | pb__ | what linker is angstrom using these days, gold or gnu ld? |
| 15:18.05 | mickeyl | relinking... |
| 15:19.10 | mickeyl | oh |
| 15:19.15 | mickeyl | it's gone |
| 15:19.45 | pb__ | hrm |
| 15:19.49 | mickeyl | no idea on the linker |
| 15:19.51 | pb__ | mysterious |
| 15:19.53 | mickeyl | i suspect still gnu ld |
| 15:19.58 | pb__ | well, seems like the linker is exonerated anyway |
| 15:20.24 | mickeyl | how complicated would it be to switch to gold? |
| 15:20.26 | pb__ | some other agency must be putting it there, though it's hard to imagine what |
| 15:20.37 | pb__ | not very, I think the two are basically compatible |
| 15:21.27 | RP | I remember looking at gold, then getting sidetracked by dolt. In the end I upgraded libtool instead |
| 15:21.53 | khem | pb__: gold does not support all architectures yet |
| 15:22.11 | RP | I seem to remember arm being one it doesn't support yet :/ |
| 15:22.24 | khem | pb__: least of all arm that is used commonly by OE community is not supported |
| 15:22.29 | khem | RP: hey |
| 15:22.39 | mickeyl | hmm |
| 15:22.40 | RP | hi kergoth |
| 15:22.45 | RP | hi khem as well :) |
| 15:22.47 | khem | RP: did you read thesings problem |
| 15:22.54 | pb__ | ah, okay, in that case gold is probably not such a good option |
| 15:22.57 | mickeyl | ok, i'm afraid i will insert that link in my postprocess for the time being |
| 15:23.01 | RP | khem: er, not sure |
| 15:23.02 | mickeyl | postprocess_rootfs |
| 15:23.09 | pb__ | anyway, I think it's probably irrelevant to the case at hand |
| 15:23.30 | khem | pb__: down the lane may be gold is good option. It does speed up linking quite a bit |
| 15:23.38 | khem | and its multithreaded |
| 15:24.09 | pb__ | yeah |
| 15:24.21 | khem | RP: BB_STAMP_POLICY = "whitelist" |
| 15:24.25 | khem | and I get this error |
| 15:24.31 | RP | khem: ah, the circular dependency? |
| 15:24.32 | khem | 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) |
| 15:24.37 | pb__ | RP: maybe you would like to add arm support to gold rather than changing the override syntax :-} |
| 15:24.40 | khem | RP: yeah |
| 15:25.08 | RP | pb__: Neither are likely to happen with my time constraints at present ;-) |
| 15:25.13 | pb__ | heh, oh well |
| 15:25.41 | RP | khem: Do you understand the problem? |
| 15:25.50 | khem | I am trying to |
| 15:26.12 | khem | RP: what is different when you set policy to whitelist |
| 15:26.19 | khem | w.r.t bitbake |
| 15:26.59 | RP | khem: It checks the whole dependency tree for timestamp mismatches rather than stoping at .bb file boundaries like the tradntional bitbake |
| 15:27.04 | khem | RP: is there a whitelist somewhere that needs attention ? |
| 15:27.12 | RP | khem: Its not that simple |
| 15:27.22 | RP | khem: One second, I'm trying to find something |
| 15:28.42 | khem | eglibc-intial DEPENDS on virtual/${TARGET_PREFIX}gcc-initial and linux-libc-headers |
| 15:29.02 | RP | 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 |
| 15:29.22 | RP | khem: Does this happen with glibc too? |
| 15:30.07 | khem | RP: yes thesing saw it with glibc 2.6.1 |
| 15:30.21 | RP | so why don't I see this with poky? :/ |
| 15:30.27 | khem | hmmm |
| 15:30.48 | RP | khem: Can you dump the task graph for something simple like bitbake busybox? |
| 15:30.56 | RP | (bitbake -g busybox) |
| 15:31.10 | RP | then share that somewhere |
| 15:31.57 | khem | RP: it would not let me generate that |
| 15:32.01 | khem | dies before |
| 15:32.41 | RP | khem: ok, can you generate it without the whitelist? |
| 15:32.49 | khem | yeah |
| 15:33.37 | khem | will take few mins now that I changed my local.conf |
| 15:35.01 | pb__ | go home now |
| 15:35.02 | pb__ | later all |
| 15:35.43 | RP | pb__: bfn |
| 15:35.57 | khem | bye pb__ |
| 15:36.06 | khem | 80% done |
| 15:36.22 | likewise | hi khem |
| 15:36.38 | likewise | khem: I have tried to run the powerpc toolchains, but I ran into libtool problems |
| 15:36.42 | khem | hey likewise long time no see |
| 15:36.50 | khem | likewise: hmmm |
| 15:37.51 | khem | RP: here is depends.dot |
| 15:37.53 | khem | http://rafb.net/p/pLkG3v71.html |
| 15:38.13 | RP | khem: task-depends.dot please |
| 15:38.59 | khem | RP: here it is http://rafb.net/p/aOXoMU53.html |
| 15:39.49 | likewise | khem: I have to leave already... I will try to make some time to backtrack... |
| 15:41.14 | khem | likewise: ok |
| 15:41.21 | khem | RP: "eglibc-initial.do_package_write_ipk" -> "gcc-cross.do_package" |
| 15:41.39 | RP | khem: I was just about to paste that |
| 15:41.53 | RP | You need to track that down, that is the problem |
| 15:42.18 | RP | Perhaps eglibc-initial needs PACKAGES = "" ? |
| 15:42.55 | *** join/#oe enigmaedge (n=root@209.191.15.3) |
| 15:43.00 | RP | Also monotone has finished as has parsing so I can reproduce this now |
| 15:43.06 | khem | RP: it means eglibc-initial.do_package_write_ipk needs gcc-cross.do_package ? |
| 15:43.20 | RP | yes |
| 15:43.25 | khem | weird |
| 15:43.40 | RP | I think that one comes from debian.bbclass |
| 15:44.06 | RP | but that isn't the real problem |
| 15:44.22 | *** join/#oe dipro (n=Miranda@hunter.netmodule.com) |
| 15:46.00 | khem | RP: I invoke CC in do_stage task for eglibc_initial |
| 15:46.09 | khem | could that create this ? |
| 15:46.14 | RP | yes |
| 15:46.19 | khem | hmmm |
| 15:46.48 | RP | but why gcc-cross and not gcc-cross-initial :/ |
| 15:46.56 | khem | then how can I push it to use CC that is previously provided by cross-gcc-initial |
| 15:47.16 | khem | yeah thats what I wonder |
| 15:47.26 | RP | well, I'd like to understand why gcc-cross and not gcc-cross-initial before we go any further |
| 15:47.43 | khem | yeah me too |
| 15:47.48 | khem | I have this DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial" |
| 15:47.55 | khem | in eglibc-initial bb |
| 15:48.47 | khem | and in gcc-cross-initial.inc I have this PROVIDES = "virtual/${TARGET_PREFIX}gcc-initial" |
| 15:49.11 | khem | ah there you see |
| 15:50.28 | khem | my bad I thought there was a spelling error but its not |
| 15:51.28 | RP | Its possible this is a bitbake bug... |
| 15:52.54 | *** join/#oe Gnutoo (n=gnutoo@host205-164-dynamic.40-79-r.retail.telecomitalia.it) |
| 15:53.00 | khem | RP: hmm |
| 15:53.03 | RP | There are only a limited number of places places write_ipk is added as a dependency |
| 15:53.14 | RP | We should work out which one this happens in for starters |
| 15:53.25 | khem | just few lines above I am seeing "eglibc-initial.do_configure" -> "gcc-cross-initial.do_populate_staging" |
| 15:53.48 | khem | so it does depend on gcc-initial |
| 15:53.54 | khem | for some tasks |
| 15:53.55 | *** join/#oe DarthWader (n=sith@92.243.163.7) |
| 15:53.55 | RP | Yes, which makes me wonder if this gcc-cross comes from somewhere else |
| 15:54.39 | RP | Basically this dependency has to come from debian.bbclass or package_ipk.bbclass |
| 15:55.22 | RP | reads the comment at the top of debian.bbclass. Hmm :/ |
| 15:56.25 | khem | hmmm RDEPEND |
| 15:59.09 | RP | If PACKAGES is empty it should be ignoring all R* variables |
| 15:59.32 | RP | I wonder if bitbake actually knows that though |
| 16:00.09 | ant|work | bbl, bye |
| 16:01.32 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
| 16:03.13 | RP | khem: RRECOMMENDS = "" in glibc-initial.inc fixes that |
| 16:03.16 | RP | I think |
| 16:03.40 | RP | It could be argued this is a bitbake bug since it should be ignoring RRECOMMENDS and RDEPENDS if PACKAGES is empty |
| 16:05.47 | hrw | ok, there is sound on 2.6.26/corgi now |
| 16:06.30 | RP | khem: This changes the problem to glibc and gcc-cross conflicting :) |
| 16:08.11 | RP | and poky does show the problem, I didn't see it due to a cache glitch |
| 16:08.48 | *** join/#oe Robwoerle (n=bob@Ma3c7.m.pppool.de) |
| 16:09.38 | RP | khem: Its all down the the RRECOMMENDS = "libgcc" in glibc.inc |
| 16:09.51 | kergoth`work | morning |
| 16:09.55 | *** join/#oe greentux (n=lemke@ip-217-18-181-130.static.reverse.dsi.net) |
| 16:10.02 | RP | hi kergoth`work |
| 16:10.55 | RP | khem: With whitelist and packaged staging combined, each depends on the other so one can't be installed without breaking the other's dependencies |
| 16:11.20 | RP | its bitbake saying it can't make consistent timestamps for that combination of options |
| 16:12.29 | Tartarus | hey khem, ever run the gdb testsuite remotely? |
| 16:13.40 | CIA-24 | 03koen 07org.oe.dev * rc0550ca4... 10/ (1 packages/linux/gumstix-kernel_2.6.21.bb): gumstix-kernel: use linux.inc |
| 16:14.11 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * r15d99fd3fc 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: use linux.inc |
| 16:14.17 | CIA-24 | 03 <koen@openembedded.org> 07master * r15d99fd3fc 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: use linux.inc |
| 16:14.20 | hrw | bye guys |
| 16:17.00 | *** join/#oe rkirti (n=kirtibr@203.199.213.3) |
| 16:18.27 | *** join/#oe Varoudis (n=varoudis@87-194-34-216.bethere.co.uk) |
| 16:19.20 | *** join/#oe rob__w (n=bob@Ma1ce.m.pppool.de) |
| 16:21.49 | khem | RP: hmmm that change I see |
| 16:21.55 | khem | RP: now it makes sense |
| 16:22.14 | khem | RP: earlier in build order gcc built before glibc |
| 16:22.22 | woglinde | he khem |
| 16:22.45 | khem | but now glibc is building before final cross gcc |
| 16:22.52 | khem | RP have to run to work now |
| 16:22.58 | khem | see you |
| 16:23.03 | woglinde | bye khem |
| 16:23.05 | khem | woglinde: hi and bye |
| 16:23.13 | khem | woglinde: catch you laters |
| 16:23.17 | woglinde | yes |
| 16:23.31 | woglinde | I will send my patche for gcc to the ml |
| 16:23.36 | woglinde | for review |
| 16:53.28 | *** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 16:53.31 | *** join/#oe gnutoo_ (n=gnutoo@host253-186-dynamic.37-79-r.retail.telecomitalia.it) |
| 17:05.52 | Laibsch | cbrake: ping |
| 17:06.15 | Laibsch | where is the CSS stuff defined? |
| 17:06.21 | Laibsch | for the wiki? |
| 17:07.14 | Laibsch | Mediawiki:Common.css |
| 17:07.20 | Laibsch | Scheint es wohl zu sein |
| 17:07.53 | *** join/#oe greentux (n=lemke@Z78d7.z.pppool.de) |
| 17:09.20 | *** join/#oe bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 17:10.17 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C06D.access.telenet.be) |
| 17:13.22 | CIA-24 | 03koen 07org.oe.dev * re886103e... 10/ (1 packages/linux/gumstix-kernel_2.6.21.bb): gumstix-kernel: set S |
| 17:13.57 | tharvey | is anyone using OE with an ixp4xx based machine? |
| 17:18.54 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * re9ec9dc3c7 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: set S |
| 17:18.57 | mwester | :) Only several thousand people. |
| 17:19.01 | CIA-24 | 03 <koen@openembedded.org> 07master * re9ec9dc3c7 10OE.dev/packages/linux/gumstix-kernel_2.6.21.bb: gumstix-kernel: set S |
| 17:21.30 | mwester | Unslung and SlugOS are built with OE, and Angstrom runs on the IXP4xx as well. |
| 17:23.02 | tharvey | 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 |
| 17:28.40 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 17:28.59 | kergoth`work | so is there someone, one of the core devs perhaps, that wants to take the oz/oe domains off my hands? |
| 17:29.09 | kergoth`work | i'd like to do it before they're up for renewal, finally |
| 17:29.14 | Crofton | kicks mickey|away |
| 17:29.42 | Crofton | kergoth`work, soon we should have an organization that can hold them |
| 17:29.56 | Crofton | there is some paperwork that needs completing |
| 17:30.00 | tharvey | 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 |
| 17:30.07 | Crofton | this should occur before the renewal date :) |
| 17:30.26 | kergoth`work | k |
| 17:32.33 | kergoth`work | whats the status of the git switch? /me really should subscribe to the lists |
| 17:35.30 | Crofton|work | RP, is working on it |
| 17:35.35 | Crofton|work | he posted today |
| 17:35.38 | kergoth`work | k |
| 17:35.41 | kergoth`work | also, who do i email an mtn key to, again, mickeyl and koen? |
| 17:35.43 | kergoth`work | :) |
| 17:35.47 | Crofton|work | I think both |
| 17:35.59 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 17:36.35 | kergoth`work | k |
| 17:45.16 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 17:52.50 | tharvey | is there a way to specify extra compiler flags for a specific package in something like a local/machine/distro conf? |
| 17:53.33 | woglinde | tharvey hm? |
| 17:54.40 | tharvey | 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_<some_package> override? |
| 17:55.00 | woglinde | hm |
| 17:55.07 | woglinde | dont know |
| 17:55.25 | woglinde | maybee its working like USE_NLS you could try |
| 17:56.36 | woglinde | CFLAGS_packagename |
| 17:56.50 | woglinde | hm let me try with bitbake shell |
| 17:58.17 | woglinde | no sorry |
| 17:58.39 | pb_ | good morning kergoth`work |
| 17:58.47 | kergoth`work | hey pb_ |
| 17:59.30 | tharvey | woglinde, ok thx - don't think thats my issue anyway |
| 18:00.23 | tharvey | 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 |
| 18:00.55 | woglinde | hm I hope madwifi will be histroy with the new atheros driver |
| 18:01.54 | tharvey | no kidding.... |
| 18:02.16 | tharvey | ath5k is working well in my tests but it doesn't support AP yet |
| 18:03.30 | pb_ | tharvey: CONFIG_OABI_COMPAT is just for userspace binaries, it doesn't allow you to mix and match ABIs within the kernel |
| 18:05.12 | *** join/#oe thesing (n=tkunze@BAA26a1.baa.pppool.de) |
| 18:05.36 | mwester | tharvey: There should be patches specfiically for something like that in the OE package for the madwifi driver... |
| 18:06.42 | mwester | 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. |
| 18:06.46 | thesing | morning all |
| 18:09.20 | tharvey | pb_, ah... ok thanks |
| 18:10.32 | tharvey | 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 |
| 18:11.04 | tharvey | wondering how slugos/unslung solves this |
| 18:11.47 | mwester | 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. |
| 18:12.07 | tharvey | mwester, ah... you mean WHACKELF? |
| 18:12.50 | mwester | 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. |
| 18:13.11 | tharvey | s/WHACKELF/WACKELF/ |
| 18:13.38 | tharvey | 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 |
| 18:14.18 | tharvey | mwester, yes I see them now in the recipe... thanks! |
| 18:14.37 | mwester | I don't know if it can; someone had to convince me that wackelf was an ok thing to do. |
| 18:17.46 | tharvey | it sounds so dirty heh.... |
| 18:17.56 | tharvey | probably ok to do behind closed doors |
| 18:18.20 | *** join/#oe DuckFault (n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com) |
| 18:18.46 | mwester | hehe! |
| 18:19.09 | tharvey | 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? |
| 18:21.18 | tharvey | mwester, looks like wackelf is only for VFP manipulation in elf header |
| 18:21.38 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
| 18:24.34 | *** join/#oe jekhor (n=jek@87.252.242.87) |
| 18:28.48 | *** join/#oe bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 18:34.18 | mwester | 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 . |
| 18:40.27 | *** join/#oe _gpg_ (n=_gpg_@lns-bzn-60-82-254-225-57.adsl.proxad.net) |
| 18:40.38 | _gpg_ | hello |
| 18:42.09 | *** join/#oe Magon (n=Magon@213.155.232.70) |
| 18:45.15 | *** join/#oe Gnutoo (n=gnutoo@79.37.186.253) |
| 18:55.40 | *** join/#oe angom (n=angom@201.170.65.143) |
| 18:55.46 | *** join/#oe Foolean (n=emil@foolean.ros.sgsnet.se) |
| 18:56.02 | *** join/#oe Gnutoo (n=gnutoo@host253-186-dynamic.37-79-r.retail.telecomitalia.it) |
| 18:56.40 | *** part/#oe angom (n=angom@201.170.65.143) |
| 18:57.08 | *** join/#oe dipro (n=Miranda@hunter.netmodule.com) |
| 19:03.03 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
| 19:06.22 | *** join/#oe infernix (i=nix@unaffiliated/infernix) |
| 19:18.39 | *** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) |
| 19:21.38 | *** join/#oe BabelO (n=Fabrice@unaffiliated/babelo) |
| 19:27.36 | *** join/#oe rsalveti (n=salveti@200.184.118.132) |
| 19:44.07 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 19:49.14 | *** join/#oe timtimred (n=meh@82-34-50-106.cable.ubr02.chel.blueyonder.co.uk) |
| 19:51.23 | *** join/#oe gnutoo_ (n=gnutoo@host253-186-dynamic.37-79-r.retail.telecomitalia.it) |
| 20:07.20 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 20:08.43 | CIA-24 | 03koen 07org.oe.dev * ra94d96e7... 10/ (1 packages/ffmpeg/ffmpeg_git.bb): ffmpeg git: bump SRCREV |
| 20:10.41 | *** join/#oe josch (n=josch@club.muc.ccc.de) |
| 20:10.48 | *** join/#oe e-ffi (n=cybercom@dslb-088-068-171-219.pools.arcor-ip.net) |
| 20:11.08 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * r8deb60609a 10OE.dev/packages/ffmpeg/ffmpeg_git.bb: ffmpeg git: bump SRCREV |
| 20:11.13 | CIA-24 | 03 <koen@openembedded.org> 07master * r8deb60609a 10OE.dev/packages/ffmpeg/ffmpeg_git.bb: ffmpeg git: bump SRCREV |
| 20:11.59 | cbrake | Laibsch: you find what you need? |
| 20:22.20 | *** join/#oe incandescant (n=incandes@foo.stupids.org) |
| 20:25.07 | *** join/#oe bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 20:29.16 | CIA-24 | 03koen 07org.oe.dev * re70bb851... 10/ (3 files in 2 dirs): firefox 3: fix idl stuff |
| 20:29.41 | *** join/#oe shabble (n=shabble@cowu.be) |
| 20:30.51 | tharvey | mwester, heh... turns out I think all I need is to add '--no-warn-mismatch' to get around the EABI version mismatch issue |
| 20:32.31 | *** join/#oe ribbits (n=bob@82.152.87.189) |
| 20:33.56 | *** join/#oe florian (n=fuchs@f054177206.adsl.alicedsl.de) |
| 20:40.17 | mwester | 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). |
| 20:40.33 | florian | re |
| 20:42.28 | tharvey | mwester, well actually I haven't found/fixed it completely yet... not sure why it isn't getting picked up by ath_hal/Makefile |
| 20:42.43 | tharvey | but I did find that it tells ld to not gripe about the mismatch |
| 20:42.50 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * r539c5483d5 10OE.dev/: |
| 20:42.50 | CIA-24 | merge of 'a94d96e725d7b1b902a9b09b6c9628a3d59d5cf8' |
| 20:42.50 | CIA-24 | <PROTECTED> |
| 20:42.50 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * rd4fa3ae63d 10OE.dev/packages/mozilla/ (3 files in 2 dirs): firefox 3: add patches from mamona |
| 20:42.50 | CIA-24 | 03 <koen@openembedded.org> 07org.openembedded.dev * rccb6a7d7a4 10OE.dev/packages/mozilla/ (firefox.inc firefox_3.0.bb): firefox 3: fix idl stuff |
| 20:42.56 | CIA-24 | 03 <koen@openembedded.org> 07master * rccb6a7d7a4 10OE.dev/packages/mozilla/ (firefox.inc firefox_3.0.bb): firefox 3: fix idl stuff |
| 20:42.58 | CIA-24 | 03 <koen@openembedded.org> 07master * r539c5483d5 10OE.dev/: |
| 20:43.00 | CIA-24 | merge of 'a94d96e725d7b1b902a9b09b6c9628a3d59d5cf8' |
| 20:43.02 | CIA-24 | <PROTECTED> |
| 20:43.04 | CIA-24 | 03 <koen@openembedded.org> 07master * rd4fa3ae63d 10OE.dev/packages/mozilla/ (3 files in 2 dirs): firefox 3: add patches from mamona |
| 20:43.16 | tharvey | 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 |
| 20:44.00 | mwester | Is there a better way we should do this, perhaps? |
| 20:45.39 | tharvey | not sure yet... still trying to get OE to pass in the --no-warn-mismatch |
| 20:45.51 | tharvey | to make sure thats all that's needed |
| 20:46.06 | tharvey | and not sure why this isn't an issue for unslung etc |
| 20:46.45 | tharvey | PACKAGE_LDFLAGS += "--no-warn-mismatch" in the recipe isn't working |
| 20:51.24 | tharvey | hm... how do I add LDFLAGS to a recipe? |
| 20:54.24 | *** join/#oe TheCan (n=thecan@dslb-092-074-091-125.pools.arcor-ip.net) |
| 21:03.04 | tharvey | mwester, ya, its that the toplevel Makefile for madwifi does a '$(MAKE) -C $(KERNELPATH) SUBDIRS=$(shell pwd) modules' which doesn't pass any LDFLAGS |
| 21:08.55 | khem | Tartarus: yes I have run the gdb testsuite in cross env |
| 21:09.08 | Tartarus | Got the dejagnurc magic around by chance? |
| 21:09.26 | khem | Tartarus: hmmm probably not here right now |
| 21:09.30 | khem | but I will have a look |
| 21:09.38 | Tartarus | I found an old ref, but it didn't get far, cross-compiled one of the host programs |
| 21:09.39 | Tartarus | thanks |
| 21:10.18 | khem | Tartarus: yeah I think mostly cross gcc one worked but there are some more quirks |
| 21:10.47 | khem | RP: how should be solve that circular dep problem |
| 21:10.53 | khem | RP: /awa |
| 21:11.58 | khem | Currently I think if we need various utilities from glibc then we need yet another glibc build phase |
| 21:12.24 | khem | like memusage etc. |
| 21:13.27 | khem | thesing: dropping RRECOMMENDS += "libgcc" from glibc.inc should solve the problem you reported |
| 21:14.24 | thesing | khem: that's kind of funny |
| 21:14.38 | khem | thesing: I know |
| 21:14.39 | thesing | but it's also no real option |
| 21:14.58 | thesing | any other ideas? |
| 21:15.00 | khem | or drop BB_STAMP_POLICY for now |
| 21:15.39 | thesing | yeah. But its a neat feature. |
| 21:15.51 | khem | thesing: until we fix it |
| 21:16.01 | khem | then it can be reintroduced |
| 21:16.25 | thesing | I dont use it. I just wanted to try it and it didn't work ;) |
| 21:16.45 | khem | thesing: I see |
| 21:17.05 | thesing | But I think I would use it. |
| 21:18.02 | khem | thesing: I think another method to fix it would be to introduce glibc-intermediate step |
| 21:20.30 | *** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas) |
| 21:20.38 | khem | and build glibc after cross-gcc as we did before |
| 21:24.25 | thesing | there has to be some other way. Doesn't the whitelist stuff help? |
| 21:26.26 | khem | thesing: may be bitbake could do somethign I dont know |
| 21:26.36 | khem | problem is clear to me |
| 21:26.55 | khem | currently cross-gcc depends on glibc |
| 21:27.20 | khem | and by saying RRECOMMEND on libgcc we make glibc depend on cross-gcc |
| 21:27.32 | khem | because libgcc comes from cross-gcc |
| 21:27.41 | khem | hence the problem |
| 21:28.05 | thesing | Do we know if all images need libgcc? |
| 21:28.25 | khem | thesing: in general nptl glibc will need it |
| 21:28.36 | khem | and linuxthreads is thing of past |
| 21:29.19 | thesing | the we could add the "RRECOMMEND libgcc if glibc and nptl" to task-base |
| 21:29.44 | khem | hmmm will that solve the problem |
| 21:30.10 | thesing | maybe we can find some better package that could depend on libgcc |
| 21:30.32 | khem | gcc-intermediate also produces libgcc |
| 21:30.47 | khem | but its a temporary libgcc |
| 21:31.10 | thesing | does it differ from the final one? |
| 21:31.51 | khem | it doesnt |
| 21:32.22 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 21:32.23 | khem | I could make libgcc provided by both gcc-cross and gcc-cross-intermediate |
| 21:32.35 | khem | but that will create duplicate provides |
| 21:32.47 | khem | I think bitbake will not like it |
| 21:36.44 | pb_ | no, that would be a bad idea. gcc-cross-intermediate shouldn't be generating any packages. |
| 21:36.46 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 21:37.04 | pb_ | 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. |
| 21:38.14 | pb_ | 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. |
| 21:39.43 | Crofton | mtn is just getting exponentially slower :( |
| 21:41.13 | khem | pb_: yeah that would be perfect place |
| 21:41.34 | khem | Crofton: I agree with you |
| 21:42.07 | khem | Crofton: I think it heard about getting replaced by git so it has no motivation to impress us anymore :) |
| 21:42.16 | Crofton | yeah |
| 21:43.07 | khem | we should convert the database quickly to git least it should decide to corrupt that too :=) |
| 21:43.52 | khem | thesing: do you remember which package was needing pthread_cancel |
| 21:44.02 | khem | when you did not have libgcc on target |
| 21:45.07 | khem | pb_: I dont think we keep nptl'ness global |
| 21:45.16 | thesing | I don't know. I saw this message several times until the boot finished to a kernel panic |
| 21:46.06 | pb_ | khem: probably not, but glibc could stash some flag in the staging area |
| 21:46.12 | khem | pb_: we poke GLIBC_ADDONS currently to decide if we are compiling nptl |
| 21:47.06 | khem | thesing: do u have log handy ? |
| 21:47.25 | khem | I remember you mentioned it on IRC |
| 21:48.23 | thesing | unfortunatly not. |
| 21:50.24 | pb_ | khem: or, alternatively (less intrusively but perhaps less neatly) examine libc.so.6 to see if it contains the NPTL banner. |
| 21:52.18 | pb_ | 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. |
| 21:54.58 | pb_ | incidentally, I think you also want to be setting RRECOMMENDS_${PN}, not just RRECOMMENDS. |
| 21:55.16 | khem | pb_: yeah |
| 21:55.19 | pb_ | the original change, as currently applied to glibc, will mean that all the subpackages also have a recommendation on libgcc |
| 21:55.54 | khem | pb_: or may be we can do like debian add the NEEDED for nptl unconditionally in the elf header |
| 21:57.32 | pb_ | I'm not sure I follow. What exactly does debian do there? |
| 21:57.55 | khem | I mean in the mklibs code |
| 21:59.12 | khem | I think its /bin/sh thats needing the pthread_cancel so creating RECOMMEND in busybox will be good |
| 21:59.31 | pb_ | really? I find it hard to believe that /bin/sh is really multithreaded. |
| 22:00.56 | pb_ | iirc, neither busybox nor bash links with -lpthread at all |
| 22:02.27 | *** join/#oe CosmicPenguin (n=nobody@163.181.251.103) |
| 22:02.38 | pb_ | 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. |
| 22:09.03 | khem | 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 |
| 22:09.29 | pb_ | khem: what exceptions do you mean? |
| 22:11.02 | pb_ | C++ programs should be getting linked with libgcc anyway, and exception handling in C is pretty much a fringe pursuit. |
| 22:11.29 | pb_ | again I would be quite surprised if either busybox or bash was exception-using. |
| 22:11.45 | khem | unwinding |
| 22:11.56 | pb_ | right, but unwinding triggered by what? |
| 22:12.24 | pb_ | 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. |
| 22:12.51 | pb_ | for all other unwinding scenarios you should already have libgcc present as a hard dependency. |
| 22:14.34 | khem | I dont know if it directly uses it but in past I have seen that on arm the wrapped functions were called more often |
| 22:15.26 | khem | the unwind functions might be called even when exception might be thrown |
| 22:15.39 | khem | not only when exception is really thrown |
| 22:17.32 | pb_ | that sounds bizarre. do you have a test case? |
| 22:18.13 | pb_ | 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? |
| 22:20.17 | khem | yes |
| 22:20.30 | khem | but I might be confusing sjlj model here |
| 22:20.45 | khem | at least that was the case before |
| 22:20.50 | pb_ | yeah, I was about to ask if you were thinking of sjlj-exceptions |
| 22:21.01 | pb_ | in the case of sjlj, there is no unwinding anyway so this is all irrelevant |
| 22:21.24 | pb_ | but you're right, in that case you do end up calling setjmp for any catch block |
| 22:21.37 | pb_ | or, well, __builtin_setjmp anyway |
| 22:21.40 | khem | yeah |
| 22:22.14 | pb_ | so, that's a non-issue in that case. |
| 22:22.41 | khem | hmmm yes unless we are using sjlj which I think for EABI atleast we dont |
| 22:22.53 | pb_ | 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. |
| 22:23.25 | pb_ | 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. |
| 22:24.29 | pb_ | in any case, if this was an issue for sjlj exceptions it would have shown up years ago. |
| 22:25.46 | pb_ | 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. |
| 22:26.55 | khem | hmmm I was think that libgcc needs libc.so |
| 22:27.30 | pb_ | yes, it usually does |
| 22:27.54 | pb_ | that's the whole reason why we (used to) have glibc-intermediate, so that you could build libgcc.so against a correct libc.so |
| 22:28.23 | pb_ | libgcc1 doesn't have any libc.so dependencies but libgcc2 does |
| 22:28.51 | pb_ | or, at least, libgcc1 didn't use to. possibly it does nowadays, I haven't checked. |
| 22:31.28 | khem | pb_: yeah right |
| 22:32.01 | khem | it did not need real libc.so though |
| 22:32.18 | khem | it needed it to be there but did not really use funcitons from libc.so |
| 22:32.59 | khem | but I am thinking about finding the right package to stick in the libgcc RRECOMMEND |
| 22:33.26 | khem | sounds a good solution instead of asking it in glibc |
| 22:33.35 | pb_ | like I said earlier, I am fairly convinced that it would be the packages that call pthread_cancel. |
| 22:33.44 | khem | unless some code in glibc is invoking these routines which need libgcc |
| 22:34.00 | pb_ | I have yet to be persuaded that there are any other circumstances where libgcc is required but not already present. |
| 22:34.42 | khem | some code flow inside libc itself that invokes libgcc ? maybe |
| 22:34.50 | pb_ | inside nptl, yes |
| 22:35.12 | pb_ | see unwind-forceunwind.c for example |
| 22:35.42 | pb_ | <PROTECTED> |
| 22:35.54 | pb_ | <PROTECTED> |
| 22:35.57 | pb_ | <PROTECTED> |
| 22:36.04 | pb_ | <PROTECTED> |
| 22:36.04 | pb_ | <PROTECTED> |
| 22:37.51 | pb_ | linuxthreads doesn't have that requirement, mostly because linuxthreads doesn't make any effort to unwind the thread stack when it's cancelled |
| 22:42.23 | khem | right |
| 22:42.42 | khem | pb_: is there any other path than pthread_cancel that could reach to this point |
| 22:42.48 | pb_ | not that I know of |
| 22:43.07 | pb_ | I don't think there is any other operation that will cause an implicit thread cancellation |
| 22:43.34 | *** join/#oe Gnutoo (n=gnutoo@host253-186-dynamic.37-79-r.retail.telecomitalia.it) |
| 22:44.04 | pb_ | so, I repeat my assertion from earlier on :-} |
| 22:44.06 | pb_ | <pb_> 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. |
| 22:44.18 | pb_ | zzz now |
| 22:44.29 | florian | pb_: good night |
| 22:44.33 | khem | pb_: sleep well |
| 22:44.53 | pb_ | 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 :-) |
| 22:44.56 | *** part/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
| 22:44.57 | pb_ | in that case, send mail to the list |
| 22:44.57 | khem | I will try to find out if thats the only place that can call this |
| 22:44.59 | pb_ | night all |
| 22:52.56 | dcordes | how can I make a "do_configure_prepend() {" function in a recipe $MACHINE specific? |
| 22:53.26 | dcordes | so that it is only ran when I use that $MACHINE |
| 22:57.16 | dcordes | 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 |
| 23:07.44 | *** join/#oe mithro (n=tim@unaffiliated/mithro) |
| 23:07.50 | *** join/#oe aloisiojr (n=aloisio@189.81.153.61) |
| 23:12.17 | florian | good night |