**** BEGIN LOGGING AT Sat Jan 28 02:59:58 2006 Jan 28 03:00:22 so again .. i get the oe.db snapshot then run monotone checkout and then monotone pull . right ? Jan 28 03:11:13 morning all Jan 28 03:12:56 morning RP Jan 28 03:15:45 RP: any advice on how to get gpe-image to build, if any packages are missing then it fails the task-whatever and thus fails the rootfs part. it doesn't seem to want to build the missing packages and then create the rootfs Jan 28 03:16:35 bitbake is 337 Jan 28 03:17:20 ade|desk: gpe-image works here so I suspect something on your system isn't up to date? Jan 28 03:17:47 ade|desk: Are you sure its the right version of bitbake - look in lib/bb/utils.py for a function called explode_deps.,. Jan 28 03:19:06 good morning RP ! :) Jan 28 03:19:31 def explode_deps(s): ....... etc yup Jan 28 03:20:00 ade|desk: and you're building gpe-image? Jan 28 03:20:08 yup Jan 28 03:20:30 Which packages isn't it building exactly? Jan 28 03:21:36 xstroke was a 404 not a gz that killed it, then when i rerun gpe-image it skips the other packages that didn't get build either Jan 28 03:22:48 So what you're saying is that if part of the build chain fails, it doesn't rerun that part of the chain? Jan 28 03:23:01 indeed Jan 28 03:23:41 same if i try building the individual task-blobs Jan 28 03:24:07 Building the individual task packages won't build the runtime dependencies Jan 28 03:24:23 You'd want something like meta-blob for that Jan 28 03:24:33 Can you do a "bitbake -n -D -D -D gpe-image" and post the log somewhere. It will be large Jan 28 03:24:57 sure Jan 28 03:27:03 RP: this may take some time ... its a slow machine at work Jan 28 03:28:45 i am doing a complete fresh build on my laptop at the same time but not with the debug bits as i had started it before hand. i may quit it though Jan 28 03:29:38 monotone: already up to date .-- is what i want , right ? Jan 28 03:29:57 plop Jan 28 03:34:53 ade|desk: The log will just do a dry run - it won't actually build anything Jan 28 03:36:40 RP: doing it now on the laptop Jan 28 03:37:32 ade|desk: Is this against the tmp dir of the build that failed? If not, I'm not sure if the problem is going to show up :-/ Jan 28 03:38:49 RP: i'll start the build on the laptop, wait til it cocks up then do it again with dry run Jan 28 03:39:05 ade|desk: ok Jan 28 03:39:27 ade|desk: Or just log the build - add the debug flags Jan 28 03:41:28 will come back to it ~ 3 hours Jan 28 03:42:51 time to get on with putting shelves up Jan 28 03:53:47 RP: I have noticed the same thing as ade|desk said when build x86 images Jan 28 03:54:42 Ifaistos: The dependencies handling changed a lot recently and I suspect there is a bug somewhere in bitbake... Jan 28 03:57:27 RP: It's rather strange. If no .bb files are added/removed the way the bitbake generates the scripts should not have changed Jan 28 03:58:07 Ifaistos: The generated scripts changed? or the build order? Jan 28 03:58:27 RP: The build order Jan 28 03:59:01 Ifaistos: The build order can depend on what was already built Jan 28 04:00:13 RP: From what i understood these past few days, is that if one .bb file is not set up correctly you are in for some serius debugging Jan 28 04:01:02 RP: Especially if DEPENDS and friends are not set up correclty Jan 28 04:01:14 Ifaistos: You get to have a feel for how bitbake does things Jan 28 04:01:42 Ifaistos: Most packages don't have extra PROVIDES in the way the python .bb file you had problems with does Jan 28 04:02:41 RP: Now i am faced with a new problem... Jan 28 04:03:13 RP: I am trying to build libxml as native and "normal" Jan 28 04:03:38 RP: The bb is the same in both cases (only the name changes) Jan 28 04:03:59 RP: But the native one does not even make configure Jan 28 04:04:49 Ifaistos: Did you inherit native? Jan 28 04:05:00 RP: yes Jan 28 04:05:20 Ifaistos: Then the bb is not the same in both cases... Jan 28 04:06:48 RP: I though that the diffeence between inherit autotools and native would be where the final results ends Jan 28 04:07:13 RP: But eitherwise they are the same Jan 28 04:07:27 Did you just inherit autotools or both autotools and native? Jan 28 04:07:28 RP: Or so i thought :/ Jan 28 04:07:45 RP:Only native Jan 28 04:08:04 I suspect you want both. Note that order is important Jan 28 04:08:22 Have a look at some of the other -native .bb files Jan 28 04:08:35 They usually include the normal one, then tweak a few things Jan 28 04:08:56 For instance DEPENDS might need to be -native ones rather than "normal" ones Jan 28 04:09:22 This is what i did Jan 28 04:09:24 SECTION = "libs" Jan 28 04:09:24 include libxml2_${PV}.bb Jan 28 04:09:24 inherit native Jan 28 04:09:24 FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libxml2-${PV}" Jan 28 04:10:34 RP:libxml2 gets compiled fine but libxml2-native fails Jan 28 04:12:47 I'd have expected that to work... Jan 28 04:13:44 Ifaistos: I suspect its not including the file - Did you make sure your PV matched an existing package? Jan 28 04:13:58 s/include/require/ to check Jan 28 04:14:23 RP: have you experimented with dyntick lately? Jan 28 04:14:41 er, require might not work in .bb files if I remember what zecke said rightly though :-/ Jan 28 04:14:53 koen: Its running as default in Zaurus images now Jan 28 04:15:21 RP: Here is what the result is from a bitbake libxml2-common -> http://pastebin.com/527088 Jan 28 04:16:37 Ifaistos: Does a version 2.6.8 exist locally? It doesn't in OE... Jan 28 04:17:49 RP: Yes it does Jan 28 04:18:27 RP: -> http://pastebin.com/527092 Jan 28 04:18:39 03koen 07org.oe.dev * r4ed28ef3... 10/packages/linux/handhelds-pxa-2.6_cvs.bb: handhelds.org 2.6: update PV to 2.6.15-hh0 Jan 28 04:19:07 RP: ah cool Jan 28 04:19:22 RP: do you see any noticable effect yet? Jan 28 04:20:05 koen: I think there are bigger power drains on a handheld which drown out its savings Jan 28 04:21:18 RP: libxml2 compiled -> http://pastebin.com/527095 Jan 28 04:24:30 RP: I wonder what those power drains are Jan 28 04:24:42 RP: you and lrg got sound under control now Jan 28 04:27:52 obergix[home]: nice to hear that you will be attending FOSDEM Jan 28 04:27:59 koen: backlight Jan 28 04:28:27 RP: some aggressive dimming would fix that, right? Jan 28 04:28:34 Ifaistos: I've just tried a libxml2-native_2.6.9.bb as you described above and it worked (up to installing) Jan 28 04:28:37 koen: yes Jan 28 04:28:45 koen: Just wifi to then consider Jan 28 04:29:48 yeah Jan 28 04:29:57 good thing that almost no zaurus has wifi ;) Jan 28 04:30:11 Ifaistos: Actually, it didn't - you need to change WORKDIR Jan 28 04:31:41 RP: Isn;t this supposed to be handled by the inherit native ? Jan 28 04:33:46 Ifaistos: You need something like S = "${WORKDIR}/libxml2-${PV}" Jan 28 04:34:22 Ifaistos: inherit native doesn't always cover everything Jan 28 04:34:41 koen: Most Zaurus owners have CF wifi cards though ;-) Jan 28 04:35:16 NOTE: package libxml2-native-2.6.9-r0: task do_build: completed Jan 28 04:35:25 RP: what sort of power saving do you actually see from dyntick? Jan 28 04:36:37 fwiw, the ipaq backlight on moderate brightness seems to consume about 400mW; maybe twice that at full brightness. Jan 28 04:38:09 pb__: I've not measured any change in the power consumption. I guess if I turned off the backlight, cpufreq and the wifi card I might but I wasn't particularly interested in doing so at the time Jan 28 04:38:29 pb__: 400mW sounds similar to the Zaurus backlight Jan 28 04:39:11 Upon startup the device can use up to 2W of power :-/ Jan 28 04:39:16 mm, right. it sounds like the dyntick code still leaves something to be desired then. I think you ought to be able to get at least a measurable improvement that way. Jan 28 04:39:47 maybe userspace is being to un-idle Jan 28 04:39:56 The pxa code might not be complete - I couldn't work out exctly what it was doing when I looked breifly at it... Jan 28 04:40:27 yeah, it's also possible that userspace is screwing it up. matchbox-panel, for example, certainly used to do that. Jan 28 04:40:45 Does it have any instrumentation to tell you how long it's actually sleeping for between ticks? Jan 28 04:41:01 Not that I saw Jan 28 04:41:17 is pxa cpufreq into mainline yet? Jan 28 04:41:21 that is unfortunate Jan 28 04:41:24 koen: no Jan 28 04:41:43 koen: The Zaurus implementation has bugs as well :-( Jan 28 04:43:00 The total power consumption on an h3900 when it's sitting quietly is about 1W (including about 400mW for the backlight as above). Out of the remaining 600mW, I imagine the majority is being used by the CPU and RAM. Jan 28 04:44:08 pb__: The Zaurus uses much less than that. When sitting idle, it uses about 500mW or which 400mW is the backlight Jan 28 04:44:34 The CPU/memory don't appear to use much at all. This could be cpufreq of course... Jan 28 04:44:48 ah, that's interesting. Jan 28 04:44:51 what RAM is in the zaurus? Jan 28 04:46:51 RP: Yes that did the trick. Thanks :) btw is there a reason that most of the libs in oe don't have a lib*-native.bb ? Jan 28 04:46:59 actually, that 1W figure was a bit inaccurate. having actually looked at my h3900 now, the real number is more like 700mW. Jan 28 04:48:34 pb__: At somepoint I'll have a go at optimising the zaurus a bit more. I did have a look at its sleep power consumption and have that equivalent between 2.4 and 2.6 kernels now (for c7x0). I still see differences with cards inserted/removed though which worries me... Jan 28 04:48:50 Ifaistos: Nobody has needed them I expect? Jan 28 04:50:44 RP: The code used to make the native libs can be used to make other *native.bb ? apps etc ? Jan 28 04:50:55 * obergix[home] is away: going to general assembly of april.org Jan 28 04:53:24 Ifaistos: How many native apps do you need though? Jan 28 04:54:08 RP: I am just asking so i can clear up in my mind how things work :) Jan 28 04:55:26 Ifaistos: We've found we only need a very small number of native apps, hence not that many packages have native .bb files Jan 28 04:56:30 hi folks Jan 28 04:57:09 do you know if there is a special bug reporting system for oz354fam085 branch ? Jan 28 05:01:29 03koen 07org.oe.dev * rd10318ef... 10/packages/cbrpager/cbrpager_0.9.14.bb: cbrpager: add 0.9.14 as requested by Alan|home on #oe :) Jan 28 05:06:48 koen: i love you :) Jan 28 05:07:51 koen: did you test it ? Jan 28 05:08:17 it ran on my hx, but I don't have any cbz/cbr files Jan 28 05:09:48 koen: http://www.stanleylieber.com/cbz/Apophenia_01.cbz Jan 28 05:12:07 Looking through the files i saw there was an xclient image. has anyone build it for x86 ? Jan 28 05:12:10 alright, let's re-configure my build machine... Jan 28 05:27:54 what does this error mean ? "monotone: warning: discarding revision cert packet fbc22e245906dac5ce180f67a0c62 1f7a2db1a28 with unmet dependencies" Jan 28 05:28:09 i have several of them Jan 28 05:31:30 alan|home: http://handhelds.org/scap/port.29306.png Jan 28 05:31:49 the big buttonbox is a bit annoying, but that a matchbox 'feature' Jan 28 05:33:34 koen: great ! Jan 28 05:33:40 thanks a lot ! Jan 28 05:33:55 you also need the real unzip, not the busybox one Jan 28 05:34:36 mmm... do we have this in OE ? Jan 28 05:34:45 yes Jan 28 05:34:58 ok, so that is alright... Jan 28 05:35:55 we may need unrar for cbr files, though... Jan 28 05:36:11 cbz are zipped, cbr are rared. :/ Jan 28 05:38:48 koen: according to this screenshot, buttons should be on the side of the screen ( http://www.jcoppens.com/soft/cbrpager/img/snap.jpeg ). Is there really nothing we can do about it ? Jan 28 05:39:14 03koen 07org.oe.dev * r304e4930... 10/packages/cbrpager/cbrpager_0.9.14.bb: add RDEPEND on the real unzip Jan 28 05:39:28 1) don't use matchbox or 2) add some window hints to the toolbar Jan 28 05:40:18 ok, then i guess i may have to contact cbrpager author Jan 28 05:40:55 a preference to have a horizontal bar would work as well Jan 28 05:41:40 yah, horizontal bar would probably work better on a portrait screen anyway Jan 28 05:50:10 03koen 07org.oe.oz354fam083 * rbda4787c... 10/packages/kbdd/kbdd_cvs.bb: kbdd: update PV Jan 28 05:50:15 03koen 07org.oe.dev * rabb0e960... 10/packages/kbdd/kbdd_cvs.bb: kbdd: bump PR of cvs version Jan 28 06:21:01 koen ... 0.8.3 RC2 (or more) exist as a feed ? Jan 28 06:25:42 stupid livebox (France Telecom modem/router...) Jan 28 06:26:19 what did i miss ? Jan 28 06:28:33 rien Jan 28 06:29:08 hhhhcz: french ? Jan 28 06:29:34 yes Jan 28 06:29:43 sorry for the fench word :) Jan 28 06:29:51 +r Jan 28 06:30:02 i'm french too :) from Rouen Jan 28 06:30:31 i see :) Jan 28 06:30:35 ^^ Jan 28 06:46:39 hi Jan 28 06:50:59 hey CoreDump|home Jan 28 06:55:36 koen|away: hey Jan 28 07:01:04 re Jan 28 07:01:47 hey Jan 28 07:01:56 koen: can a NSLU2 run in Little Endian Mode? Jan 28 07:01:56 gremlin[it]: the feeds configured in the RC rootfs work Jan 28 07:02:00 zecke: yes Jan 28 07:02:21 and since a few weeks even the builtin ethernet works in LE modus Jan 28 07:02:30 koen i asked to to a live update 0.8.2 -> 0.8.3-RC Jan 28 07:02:30 okay I will get one then Jan 28 07:02:56 03coredump 07org.oe.dev * r19acbe30... 10/packages/altboot/files/init.altboot: altboot: Sync with .dev branch, no notable changes. Jan 28 07:03:01 zecke: not to sure on the details, but you might have to flash a new bootloader Jan 28 07:03:20 Am I right to assume that 'BOOTSTRAP_EXTRA_DEPENDS ?= ""' would set that variable to "" if it isn't set already, but leave it alone otherwise? Jan 28 07:03:39 koen: the perspective of running it the in the same byte order as my PDA is good enought Jan 28 07:04:00 zecke: I ordered a loft last week :) Jan 28 07:04:09 * zecke started a emerge system on his schark Jan 28 07:04:14 koen: a loft? what is that? Jan 28 07:04:20 http://www.giantshoulderinc.com/hardware.html Jan 28 07:04:34 533MHz/64MB board that [g2] designed Jan 28 07:04:52 hmm he wanted to mail me when it is done :} Jan 28 07:05:53 koen: are these generally available? Jan 28 07:06:04 they are Jan 28 07:06:16 $350 for board + case + PSU Jan 28 07:06:37 + shipping Jan 28 07:07:07 yes Jan 28 07:07:26 he lives in the US? Jan 28 07:07:28 [g2] is looking at how to handle VAT Jan 28 07:07:34 yes, in the US Jan 28 07:22:27 * koen looks at his OE dir Jan 28 07:22:56 git/ hg/ monotone/ svn/ Jan 28 07:34:48 morning Jan 28 07:41:33 ~lart Debian SID for breaking KDE apps YET AGAIN Jan 28 07:41:34 * ibot whacks Debian SID with a giant beaver's tail for breaking KDE apps YET AGAIN Jan 28 07:42:30 CoreDump|home: again? wow Jan 28 07:43:14 yeah, every KDE app is bitching about missing "mime types". Which breaks konq and every darn file selector Jan 28 07:44:40 lets see if todays updates fix it .... Jan 28 07:44:52 CoreDump|home: that's debian as usual :) Jan 28 07:45:24 no, before sarge went stable, there were *never* any such problems with SID Jan 28 07:45:40 maybe for_one_ day at most. Jan 28 07:52:26 http://www.fosdem.org/2006/index/dev_room_embedded Jan 28 07:53:52 * zecke hates wireless technology Jan 28 07:59:53 this wireless stuff will never catch on Jan 28 08:00:50 Crofton: I wasted thursaday and friday on configuring a IP Encapsulator... Jan 28 08:01:48 I work for the Mobile and Portable Radio Research Group :) Jan 28 08:02:23 I'm a intern at a DVB-H research facility :} Jan 28 08:02:51 neat Jan 28 08:03:16 Crofton: yeah neat technologies but not if nothing works Jan 28 08:03:49 as an academic, working is not important Jan 28 08:03:52 publishing is Jan 28 08:03:55 hehe Jan 28 08:04:06 I am a failed academic, I wold ratther stuff work than publish Jan 28 08:04:25 I hope I will publish my first work within the next three month... Jan 28 08:04:29 cool Jan 28 08:04:47 optimising bandwith usage for interfactive tv programs... Jan 28 08:04:48 publishing is overrated Jan 28 08:04:53 heh Jan 28 08:05:12 koen: hehe Jan 28 08:05:13 it is hard to publish software defined radio stuff Jan 28 08:05:18 not enough equations Jan 28 08:08:08 koen: When is your presentation on FOSDEM ? Jan 28 08:08:21 RP: the nokia people are having a talk at fosdem about powermanagement Jan 28 08:08:32 Ifaistos: saturday or sunday Jan 28 08:12:25 koen: That's what i am asking.... I am thinking for flying over that day Jan 28 08:12:47 koen: return back in the evening the same day Jan 28 08:13:31 Ifaistos: I have no idea, the fosdem people are still working on the schedule Jan 28 08:21:37 does anyone know when task-xterminal is build the xserver and company have to be installed from packages or it boots directly on X ? Jan 28 08:52:35 a bitbake autoconf-native, just failed here. Jan 28 08:52:43 the temp/run.do_configure file has this line: "meta-gpe.bb_do_configure" instead of "autotools_do_configure". Jan 28 08:52:52 building directly via bitbake -b autoconf-native_2.59.bb works. Jan 28 08:52:59 any hints what I should look for? Jan 28 08:53:15 ouch Jan 28 08:55:23 try blowing away the cache Jan 28 08:56:24 koen: thanks for the hint, but I just started this with rm -rf tmp :-/ Jan 28 08:56:46 s/with/after/ Jan 28 08:56:46 pH5 meant: koen: thanks for the hint, but I just started this after rm -rf tmp :-/ Jan 28 09:00:26 zecke: did you see http://article.gmane.org/gmane.comp.version-control.monotone.devel/5831 ? Jan 28 09:01:46 I will reply Jan 28 09:04:30 We should score the various scm products on how much they care about OE Jan 28 09:06:50 koen: can I reply somehow using gmame? Jan 28 09:06:53 we seem to be the largest project using monotone: http://venge.net/monotone/wiki/ProjectsUsingMonotone Jan 28 09:07:03 zecke: no idea, I have tried that before, but it didn't work Jan 28 09:07:26 yeah, I've seen that Jan 28 09:08:06 in terms of volume, I suspect OE scores high on the list of projects using any scm Jan 28 09:11:55 testing OZ 3.5.4RC : Gdk-Warning **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) Jan 28 09:12:15 alan|home: I'm seeing that a lot here too Jan 28 09:16:26 http://article.gmane.org/gmane.comp.version-control.monotone.devel/5812 looks neat as well Jan 28 09:30:58 zecke: could you cc: me on that monotone message? Jan 28 09:31:23 koen: sadly not, I will give you a gmame url (if it works) Jan 28 09:43:26 JustinP: any news on e? Jan 28 09:50:24 damn gmame Jan 28 09:57:23 i notice an error on bitbake manual ... ch02 , "Appending (.=) and prepending (=.) without spaces" paragraph Jan 28 10:19:38 zecke: I take gmane isn't working as expected? Jan 28 10:20:52 koen: I wait for a confirmation mail :} Jan 28 10:21:29 hmmm Jan 28 10:21:38 can anyone reach http://lists.gnu.org/archive/html/monotone-devel/2006-01/ ? Jan 28 10:22:02 cya later Jan 28 10:22:34 My doctor has free wireless Jan 28 10:23:11 heh Jan 28 10:23:22 This is something iwould rather not have discovered Jan 28 10:50:39 yay, found a compile-bug in the 3.5.4 branch with orinoco-modules_0.13e.bb Jan 28 10:51:36 * koen will yay if it has a fix ;) Jan 28 10:51:48 * kergoth_ does an svk mi of oe, then apt-get installs mercurial and git Jan 28 10:52:54 http://pastebin.ca/38915 Jan 28 10:53:06 building for collie btw Jan 28 10:53:42 3014 .bb files now? sheesh :) Jan 28 10:54:04 CoreDump|home: ah, it seem 2.95.3 doesn't like the CC_ARCH flags Jan 28 10:54:06 indeed Jan 28 10:55:01 sooo, what can I do about it? Jan 28 10:55:24 try blowing away HOST_CC_ARCH for that package Jan 28 10:55:36 I suspect http://ewi546.ewi.utwente.nl/tmp/viewmtn/getdiff.py?id1=e5947ae8248c8fd093e1c7c0584bc013dc8839d8&id2=b96c823512e3b9ff9ed51afd16fa04da0842e38c&fname=classes/module-base.bbclass is causing the problems Jan 28 10:57:33 * CoreDump|home tries reverting the patch and checks Jan 28 10:59:23 NOTE: package orinoco-modules-0.13e: completed Jan 28 10:59:30 yep, that's the cause Jan 28 11:00:54 * koen taps foot Jan 28 11:01:06 svk sync //oe-crofton-upstream is taking it's time... Jan 28 11:02:45 mine timed out multiple times, had to restart it Jan 28 11:02:48 pretty odd Jan 28 11:02:56 like theres a network connectivity issue with the server ors omething Jan 28 11:03:09 * kergoth_ shrugs Jan 28 11:03:25 Current RX Speed: 272.90 KB/s Jan 28 11:03:35 so it's doing something Jan 28 11:03:50 a welcome change from gits chattiness Jan 28 11:05:38 ah, it's giving me some output Jan 28 11:05:43 Committed revision 27 from revision 26. Jan 28 11:25:00 how do you guys test your X apps? i remember there is a command to open a custom size X window Jan 28 11:26:32 Hi, I managed to get anthy to compile. Now, I was wondering how to actually integrate it as an input method. In case anyone is interested, the bb file in the form of a diff is available either from bugs.openembedded.org or gakusei.sf.net Jan 28 11:26:45 how would i switch inside a disto.conf different preferred gcc`s based on the MACHINE used ? Jan 28 11:28:38 PREFERRED_VERSION_gcc-cross_death = "2.95.3" Jan 28 11:29:00 would give you gcc 2.95.3 for MACHINE="death" Jan 28 11:30:19 if scary Jan 28 11:31:07 so that will then also override declarations with _death or similar ? Jan 28 11:31:17 of course, doing this for c++ packages would destroy binary compatibility, so extreme caution is advisable Jan 28 11:31:18 i mean without Jan 28 11:31:21 yes Jan 28 11:31:54 _death will prevail if both are defined Jan 28 11:32:19 even more scary Jan 28 11:32:30 :-) Thanks Jan 28 11:33:23 i need this for the alchemy based stuff Jan 28 11:33:42 ah, right Jan 28 11:34:08 if your situation is actually generic to mips, rather than being truly machine specific, you probably want to use an override on TARGET_ARCH instead. Jan 28 11:34:34 to put in familiar.conf ? Jan 28 11:35:45 i.e. PREFERRED_VERSION_gcc-cross_mips or something Jan 28 11:35:46 but i cant say if this apply`s for all mips ,.. but it works for AMD alchemy based ones ( so far ) Jan 28 11:36:24 okay Jan 28 11:36:44 ok , i wll go for a try wth mipsel Jan 28 11:39:29 where can i learn about the hirarchey of packages overriding ? Jan 28 11:42:36 evening Jan 28 11:43:13 hi reenoo Jan 28 11:43:27 hey pH5 Jan 28 11:43:48 rob_w|skywatch: it's pretty easy, overrides go from right to left Jan 28 11:50:32 ah ,, nice Jan 28 11:51:02 but something is still overriding me something coming from familiar.conf n friends .. Jan 28 11:54:09 bah , the sky is actually too bad Jan 28 12:21:50 Can someone take a look at this and apply? Jan 28 12:21:51 http://bugs.treke.net/show_bug.cgi?id=635 Jan 28 13:01:56 hi guys. so i'm building this OpenZaurus image on amd64 host, and the resultant kernel 2.6 is too large for my target platform; there is a script which checks the size of the image and halts the build process if size exceeds a predetermined number. this process thus fails on my amd64 host machine. Jan 28 13:02:24 however, it does NOT fail on another OZ user's host machine when building from the same source branch, and same OZ target Jan 28 13:02:57 what might cause this to be different, when supposedly myself and the other user are building with the bootstrap compiler? Jan 28 13:05:10 Is it "fairly safe" to use the most current OE now or is breakage still likely for very basic stuff? Jan 28 13:24:55 i don't understand exactly a thing about COLLECTIONS Jan 28 13:26:20 when the same packege (foo.bb) exist in both reposotory which win ??? the one with highest or lower PRIORITY NUMBER ? Jan 28 13:27:11 gremlin[it]: highest Jan 28 13:27:28 bigger is better in terms of priority Jan 28 13:28:21 thanks pb__ ... i'm trying to use this fearure to build sa ipaq with kernel 2.6 without touch the original repo :) Jan 28 13:28:50 right, yeah, that's basically the kind of thing it's intended for Jan 28 13:32:19 when i change something in config/*.conf i have to clean something in build/tmp ? Jan 28 13:32:46 generally, yeah Jan 28 13:32:59 what ? Jan 28 13:38:02 surelly build/tmp/cache ... but what else ? Jan 28 13:38:23 depends what you change Jan 28 13:38:37 given a sufficiently wide-reaching change to a .conf file, you might potentially have to remove all of tmp/ Jan 28 13:39:51 mhhh but usually tmp/*/x86_64-linux isn't affected ... cross tools mainly Jan 28 13:53:54 mhhh maybe this morning i wasn't abe to compile alsa-driver (familiar-unstable kernel 2.4) cause i had libc compiled with linux-libc-headers-2.6.11.1-r1 ... probably not sure ... Jan 28 14:05:34 CoreDump|home: not as yet Jan 28 14:05:53 JustinP: :( Jan 28 14:06:03 CoreDump|home: strangely, even updating everything to CVS versions still causes strange errors with e-wm and entrance with edje_cc Jan 28 14:06:25 tried trashing /tmp? Jan 28 14:06:31 even though latest CVS versions compile fine on my desktop... Jan 28 14:06:33 oh yes Jan 28 14:06:58 hmm sounds nasty Jan 28 14:07:04 yeah... Jan 28 14:07:30 got a diff against .dev or branch? Jan 28 14:07:36 and it's harder to deal with as it says it's expecting a certain amount of args, but got another, but doesn't say what command is the problem... Jan 28 14:07:45 CoreDump|home: it's all checked in ;-) Jan 28 14:07:49 in dev Jan 28 14:07:58 ahh, I didn't notice heh. Jan 28 14:08:09 will try it first thing tomorrow Jan 28 14:08:13 ok Jan 28 14:13:52 whoo! i got my adapter from serialio! Jan 28 14:14:02 USB A female to USB mini A male Jan 28 14:14:06 it's a short little pigtail Jan 28 14:14:07 ten bucks Jan 28 14:14:09 it's perfect Jan 28 14:14:13 =) Jan 28 14:14:28 anyone who wants this adapter, it is nolonger hard to find Jan 28 14:14:32 buy it from serialio Jan 28 14:14:41 got mine with my Z Jan 28 14:14:49 USB host and client cables Jan 28 14:14:54 ~hug trisoft Jan 28 14:14:56 * ibot hugs trisoft Jan 28 14:15:07 i should have, but hose-head who sold me the Z forgot them Jan 28 14:15:16 then promised screen protectors, never sent those eitehr Jan 28 14:15:34 heh Jan 28 14:15:43 i got a lot of his kit though (usb keyboard, mini mouse, hub, other cables, 100/120 adapter) for total $500usd Jan 28 14:15:48 no complaints there Jan 28 14:16:28 USB host on Z rocks Jan 28 14:16:47 2.6.16-rc1-git4 works on the Z :) Jan 28 14:16:50 it's neat to have that, i wish the USB host port was in a different physical orientation Jan 28 14:17:04 RP: what do you mean, a stock kernel? Jan 28 14:17:25 RP: way to go Jan 28 14:17:43 shadows: Mine is heavily patches but you need about two bytes of changes to make a stock one work Jan 28 14:17:50 RP: the keyboard with the 2.6 kernel on the C3000 is very non-usable.... Jan 28 14:18:00 JustinP: In what way? Jan 28 14:18:04 RP: very nice, congrats on the payoff of much hard work Jan 28 14:18:20 JustinP: arrrrrrrrrre you ssssssuure? Jan 28 14:18:24 Jan 28 14:18:25 RP: I had assumed from previous e-mails and such I'd read that it just had a high repeat rate Jan 28 14:18:32 RP: but I'm not really seeing that Jan 28 14:18:48 It sometimes repeat a char many times even though I pressed it only quickly Jan 28 14:18:49 This kernel is actually testing a fix for that... Jan 28 14:18:53 and it often misses my key presses Jan 28 14:19:05 yes Jan 28 14:19:08 I'm either using r0 or r1, not sure which Jan 28 14:19:35 I'm altering the scan delay from 100ms to 50ms. It appears to fix the errors I sometimes see Jan 28 14:19:38 RP: hey, while you're here, i want to ask what might result in the kernel 2.6 building too big for c3000 on amd64 host A, when amd64 host B builds it fine. .dev branch. Jan 28 14:20:09 i asked in #oe but that isn't the very chatty channel Jan 28 14:20:19 that coupled with USB client not working with Windows and my wireless card not turning on (I may be doing it wrong, of course) make the 2.6 kernel still unusable for me :-( Jan 28 14:20:21 shadows: That sounds very bad :-/ Jan 28 14:20:30 shadows: This is #oe btw ;-) Jan 28 14:20:31 RP: yes. it is hard for me to think, what might be the cause Jan 28 14:20:35 * shadows blinks Jan 28 14:20:49 shadows: just fyi, this is in fact #oe. Jan 28 14:20:53 i am just too excited by receiving a package in the mail Jan 28 14:20:56 thanks guys Jan 28 14:20:59 mea culpa Jan 28 14:20:59 okay Jan 28 14:21:03 not to complain, of course, the 2.6 kernel is runing otherwise quite smoothly :-) Jan 28 14:21:04 so where to begin finding out what is wrong? Jan 28 14:21:24 i want very much to build the kernel 2.6 and help test Jan 28 14:21:24 JustinP: I have some comments in my inbox which might lead to working RNDIS for cxx00... Jan 28 14:21:39 RP: I see Jan 28 14:21:51 shadows: Compare the two kernels with objdump and see which bit of it changed size so much... Jan 28 14:22:16 RP: in the case of both g_ether and g_file_storage windows seems to see it pretty much right but it never finishes installing Jan 28 14:22:19 JustinP: I did try very hard to make it work. It looks like some problem with zero length packets... Jan 28 14:22:20 RP: oh okay Jan 28 14:22:25 RP: (of course you may know all this already...) Jan 28 14:22:40 g_ether starts installing the driver and never stops Jan 28 14:22:44 JustinP: I can tell you exactly where it stops working ;-) Jan 28 14:23:08 JustinP: down to the line of code - see my post to linux-usb-devel Jan 28 14:23:49 g_file_storage has parts recognized by Windows ever so slowly and gets a disk drive installed, but it never shows up anywhere but in the device manager Jan 28 14:23:55 hmmm...not on that list.... Jan 28 14:24:47 JustinP: Just be thankfully we have usb client for now :) Jan 28 14:25:48 you mean with a Linux host? Jan 28 14:27:21 JustinP: Yes. Its a little worrying g_file_storage doesn't work though. I never tested that mind :) Jan 28 15:02:08 is there a way to stop bitbake from building python-native? ASSUME_PROVIDED doesn't work anymore as it's built via RDEPENDS from ipkg-utils-native. Jan 28 15:02:19 there isa limit to the length of a string in the .bb .conf files when VARIABLE=" val1 val2 val3" is done ? Jan 28 15:06:46 pH5: Assume provided should work. The answer might be to remove python-native from ipkg-utils-native thought... Jan 28 15:10:47 RP: the ignored_dependencies list (aka ASSUME_PROVIDED) is only checked against depends_list (DEPENDS). Jan 28 15:12:17 RP: hm. but since python is needed for bitbake anyway, who needs a local python-native build? Jan 28 15:15:12 pH5: iirc, the native python build is necessary to build the cross python, but nothing else Jan 28 15:17:14 kergoth_: thanks. I'll just remove the python-native RDEPEND from ipkg-utils-native, then. Jan 28 15:18:04 good plan Jan 28 15:23:06 Is the pocketop foldable IR keyboard supported in OE/OZ? Jan 28 15:24:29 03pH5 07org.oe.dev * r2ec495c6... 10/packages/ipkg-utils/ipkg-utils-native_1.6+cvs20050404.bb: ipkg-utils-native: don't RDEPEND on python-native Jan 28 15:27:19 pH5: You did make sure ipkg-utils-naitve still says RDEPENDS = ""? Jan 28 15:28:05 um, not yet. why is that important? Jan 28 15:28:33 pH5: It will now RDEPENDS = "python" Jan 28 15:28:39 silly me Jan 28 15:28:53 Back where we started :) Jan 28 15:29:03 This was what triggered the whole cycle... Jan 28 15:33:27 03pH5 07org.oe.dev * r520f026b... 10/packages/ipkg-utils/ipkg-utils-native_1.6+cvs20050404.bb: ipkg-utils-native: don't RDEPEND on python Jan 28 15:38:01 i have a problem with bitbake parsing a .conf file ... it seem correct to me can someone check ? i paste the output of bitbake and the h3600.conf file i'm working on ... http://pastebin.com/527966 thanks Jan 28 15:50:38 problably i found .... grrr i hate when the same thing is defined in many places >:( Jan 28 15:55:57 good night i'll continue tomorrow Jan 28 15:56:05 gremlin[it]: good night Jan 28 15:56:23 thanks pH5 :) Jan 28 16:11:37 ~lart hh.org CVS Jan 28 16:11:38 * ibot stabs hh.org CVS Jan 28 17:10:31 03xora 07org.oe.dev * rdf87e4e2... 10/packages/gpdf/gpdf_2.10.0.bb: gpdf_2.10.0.bb : Newer version of gpdf, this one seems to be less prone to crashing. Jan 28 17:25:16 03xora 07org.oe.dev * r81f8348c... 10/packages/poppler/poppler_0.5.0.bb: poppler_0.5.0.bb : New version of poppler, required for new version of evince Jan 28 18:38:49 how to pick which compiler executable is used? Jan 28 18:39:18 in the context of building on a given host, the host computer has gcc-4.0, gcc (link to gcc-4.0), gcc-3.4, gcc-3.3 Jan 28 18:39:22 how to pick gcc-3.4 Jan 28 19:30:47 JustinP: e-image in .dev fails on evas 0.0.22. if 0.0.23 is used, the .bb fails on staging Jan 28 20:06:12 CoreDump|afk: no it doesn't.....dev is set to use CVS, not "release".... Jan 28 20:11:39 JustinP: DISTRO=openzaurus-unstable Jan 28 20:11:57 yes....me too.... Jan 28 20:13:35 JustinP: could you tell me which compiler versions you have installed on the host machine? Jan 28 20:13:46 well dunno then, it's a .dev tree for sure Jan 28 20:13:55 versions? Jan 28 20:13:57 only one... Jan 28 20:14:08 CoreDump|afk: do you have some preferred versions set? Jan 28 20:14:13 nope Jan 28 20:14:17 my host has gcc-3.4, gcc-3.3, gcc-4.0 Jan 28 20:14:17 .... Jan 28 20:14:42 don't really know why you'd want to do that.... Jan 28 20:14:55 the default is gcc-4.0 Jan 28 20:15:09 i think this might be one possible cause of the kernel output being too big Jan 28 20:15:20 could be Jan 28 20:15:23 I have 3.4.4 Jan 28 20:15:29 i build .dev for openzaurus/spitz and it is kernel 2.6 being too big Jan 28 20:15:33 okay Jan 28 20:15:45 know of a way to tell the OE environment to use a different compiler? Jan 28 20:15:59 i.e. tell it which path to the compiler Jan 28 20:16:04 try looking at the native class Jan 28 20:16:10 hm Jan 28 20:16:44 what distro are you using? Jan 28 20:16:54 GCC 4 is deinfately not default for me... Jan 28 20:17:11 debian etch here Jan 28 20:25:05 JustinP: what i meant is the host compiler Jan 28 20:25:19 could that somehow mess up the bootstrap compiler? Jan 28 20:25:47 yes Jan 28 20:26:00 I meant that GCC4 is not the default for my distro Jan 28 20:26:02 like would bootstrapping an gcc 3.4.4oe sources compiler using an gcc 4.0 host compiler be any different than doing the same using a host compiler gcc 3.4.4 Jan 28 20:26:06 ah okay Jan 28 20:26:16 it could be Jan 28 20:26:18 this is making me crazy, what would produce such difference in kernels Jan 28 20:26:38 oh! would you be willing to do a build of an image so we can compare objdump output of kernel? Jan 28 20:26:40 shadows: BUILD_CC = "gcc-3.4" Jan 28 20:26:43 you're not setting inhibit strip or anything are you? Jan 28 20:26:44 hmm Jan 28 20:26:46 kergoth: thanks! Jan 28 20:26:50 np Jan 28 20:28:15 JustinP: not that i know of Jan 28 20:28:30 JustinP: i'm just following the directions at http://oe.handhelds.org/cgi-bin/moin.cgi/GettingStarted Jan 28 20:28:55 probably the compiler then Jan 28 20:29:14 unless you're setting it to build debug..... Jan 28 20:30:48 it seems strange though Jan 28 20:31:02 like of course, "bitbake nano" works Jan 28 20:31:54 would "bitbake linux" be the same as the dependency brought in by doing "bitbake gpe-image" for OZ? Jan 28 20:32:52 you probably want bitbake virtual/kernel Jan 28 20:33:01 but if you want to see waht gpe-image does, read meta/gpe-image.bb Jan 28 20:33:08 okay Jan 28 20:33:15 awesome Jan 28 20:35:27 how do i check the legitimacy of the cross-compiler being built (armv5te-linux/gcc-cross-3.4.4-r3) Jan 28 20:37:09 i dont understand the question Jan 28 20:37:14 check it in what way? Jan 28 20:37:14 shadows: uh, gcc -v? Jan 28 20:37:34 oh Jan 28 20:37:39 NAbyss: how's it going :) Jan 28 20:37:57 kergoth: i think that whatever is going on, makes the kernel 2.6 output too big Jan 28 20:38:12 it is somehow different from other users, though i am not 100% certain Jan 28 20:38:25 shadows: are you setting your machine and distro right? Jan 28 20:38:36 shadows: Not bad, yourself? Jan 28 20:38:37 JustinP: yes, quite sure. spitz and openzaurus-unstable Jan 28 20:38:53 :-) Jan 28 20:38:54 NAbyss: pretty mellow. stoked about starting my job w/ Google Jan 28 20:38:55 mine worked fine Jan 28 20:39:03 although kernel 2.6 still has some rought edges Jan 28 20:39:14 the worst of which is the strangely acting keyboard Jan 28 20:39:15 shadows: Sounds like fun.. what kinda work are you doing for them? Jan 28 20:39:18 JustinP: i'm thinking maybe it's my amd64 host and/or host distro Jan 28 20:39:24 could be Jan 28 20:39:33 I did compiles fine on an AMD64 a while ago Jan 28 20:39:38 NAbyss: "technician assistant" at data centers in Chicago Jan 28 20:39:40 never did 2.6 on it, though Jan 28 20:39:42 NAbyss: starting next month Jan 28 20:39:48 JustinP: uh Jan 28 20:39:54 JustinP: how, did you compile anything other than 2.6 Jan 28 20:39:59 or did you not do the kernel? Jan 28 20:40:09 2.4, of course Jan 28 20:40:10 gcc 2.95 does not work on amd64 Jan 28 20:40:12 nice one :) Jan 28 20:40:25 it was a hybrid system Jan 28 20:40:27 oh Jan 28 20:40:44 still had amd64 issues I had to fix, though Jan 28 20:40:50 i had bad luck with chroot. chroot works fine, but when doing the OE build, it caused segfaults in the compiler Jan 28 20:40:53 aye Jan 28 20:41:06 why would you need a chroot....? Jan 28 20:41:09 ohhhh Jan 28 20:41:18 no this is a pure64 distro Jan 28 20:41:27 making me a big headache :) Jan 28 20:41:51 NAbyss: i got my cable from serialio.com today, it is perfect Jan 28 20:42:10 I got mine with my USB drive ^_ Jan 28 20:42:11 ^_^ Jan 28 20:42:12 USB OTG host pigtail. now USA residents have an easy source and reasonable price for the cable Jan 28 20:42:15 aye Jan 28 20:42:21 USB OTG Cutie Jan 28 20:42:33 great that there's a place selling them for a decent amount Jan 28 20:42:37 yes Jan 28 20:42:40 it was a nice find Jan 28 20:42:43 $50-$60 for that stupid cable is insane Jan 28 20:42:51 shadows: How much for? I've yet to find a supplier in oz Jan 28 20:42:51 oh, no, mine was ten bucks shipped Jan 28 20:43:11 it's not well advertised Jan 28 20:43:20 but it is definitely in stock and available to buy Jan 28 20:43:23 I actually also got the GoldX cable for $20 or so, which is also very useful Jan 28 20:43:26 yes Jan 28 20:43:31 i have the GoldX, it is clunky Jan 28 20:43:35 =) Jan 28 20:43:46 yes, definately Jan 28 20:43:48 but useful Jan 28 20:44:15 also i picked up an PS/2 keyboard to USB adapter. it supports the IBM model "M" Jan 28 20:44:20 i will use that keyboard with my Z Jan 28 20:44:33 not many adapters support old keyboards Jan 28 20:45:06 JustinP, and NAbyss, you two have C3000 yes? Jan 28 20:45:12 I do Jan 28 20:45:45 shadows: C3100 here Jan 28 20:45:54 oh, okay that's right Jan 28 20:46:11 are either of you on amd64 host computers? Jan 28 20:46:33 * shadows notes the oncomming paste Jan 28 20:46:34 | Size is 1327208 Jan 28 20:46:34 | FATAL: This kernel is too big for your PXA Zaurus and will destroy data if you flash it. Please reduce the size of the kernel by making more of it modular. Jan 28 20:46:35 I have one to test on....if it's been updated.... Jan 28 20:46:37 NOTE: Task failed: /home/jnc/opensource/openzaurus/build/oetmp/work/spitz-linux/ Jan 28 20:46:51 shadows: IA32 host Jan 28 20:46:56 hm Jan 28 20:47:23 JustinP: could you try a build of the 2.6 kernel and spitz target, on amd64 host please? i want to know if my message is atypical. Jan 28 20:47:39 I can try...as I said it's hybrid Jan 28 20:47:44 oh Jan 28 20:47:48 and I'm not sure if the owner has updated monotone yet... Jan 28 20:47:54 that's okay Jan 28 20:48:00 i mean, not necessary to try Jan 28 20:48:02 bah Jan 28 20:48:04 he hasn't Jan 28 20:48:06 monotone 0.22 Jan 28 20:48:16 slow? Jan 28 20:48:27 no, too old to pull from OE servers Jan 28 20:48:39 oh okay, yes i see here now i have version 0.24 Jan 28 20:49:34 um Jan 28 20:49:46 why would OE build not be using a bootstrapped compiler Jan 28 20:49:51 is it defaulting to native compiler? Jan 28 20:50:17 oe only uses BUILD_CC for -native and -cross packages, not the rest Jan 28 20:50:19 (could i figure out what happened from looking at build/oetmp/staging/* ?) Jan 28 20:51:12 jnc@baker:~/opensource/openzaurus/build/oetmp/cross$ file arm-linux/bin/gcc Jan 28 20:51:12 arm-linux/bin/gcc: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped Jan 28 20:51:45 running that binary with -v says it's version 3.4.4 Jan 28 20:51:50 shadows: Gotta love shipping.. looked at that USB OTG cable.. shipping's 2.6x the price of the cable Jan 28 20:52:05 NAbyss: oh. what country? Jan 28 20:52:19 shadows: Oz Jan 28 20:52:29 oh! the Oz. not OpenZaurus Jan 28 20:52:30 hah Jan 28 20:52:46 Uh, yeah, never thought about that :) Jan 28 20:52:56 surrre you 'idn't Jan 28 20:53:39 so um Jan 28 20:53:42 is this a bug in the... Jan 28 20:54:27 there's no defconfig-spitz Jan 28 20:54:35 there's one for cxx00 oh Jan 28 20:55:11 excuse my verbosity, gentlemen and ladies, i'm running my mind in circles to figure out why building kernel 2.6 works for everyone but me Jan 28 20:55:40 I assume you've updated OE? Jan 28 20:55:56 ah, yes it is current as of 3 hours ago, presume Jan 28 20:56:04 i may have updated more recently Jan 28 20:56:22 ok Jan 28 20:56:42 i cleaned out everything except my oe.db, checked out, then updated oe.db and then did monotone update inside the org.openembedded.dev Jan 28 20:56:59 per the GettingStarted guide. i used dominion server Jan 28 20:59:42 actually Jan 28 21:01:39 objdump of kernel image http://oe.pastebin.com/528294 Jan 28 21:07:50 i'm so confused by this :( Jan 28 21:16:27 kergoth: any suggestions as to how this might be happening? Jan 28 21:17:22 nope Jan 28 21:18:26 is it as bad as i think it is Jan 28 21:18:39 or not important Jan 28 21:22:51 Hmm, anyone had any success building gcc-4.0.2 (native for target)? Jan 28 21:33:49 built fine here Jan 28 21:33:52 GCC, that is... Jan 28 21:33:55 the image didn't Jan 28 21:33:56 mmhm Jan 28 21:34:13 luke-jr_: I get a problem.. "configure: error: GMP with MPFR support is required to build f95" Jan 28 21:34:14 what format is spitz arch/arm/boot/zImage ? Jan 28 21:34:28 how would i get useful info using objdump from that Jan 28 21:34:32 shadows: file arch/arm/boot/zImage Jan 28 21:34:36 data Jan 28 21:34:39 O.o Jan 28 21:34:42 hm Jan 28 21:35:10 oh! Jan 28 21:35:13 i have modified the bbscript to not rm the file when it detects the file is too big Jan 28 21:35:15 zImage is compressed, isn't it? Jan 28 21:35:21 yes Jan 28 21:35:26 so it's zlib data Jan 28 21:35:30 decompress it first Jan 28 21:35:30 oh okay Jan 28 21:35:45 RP said i should be using objdump to compare two kernels Jan 28 21:36:00 there should be a vmlinuz file or something, I think Jan 28 21:36:01 the one i'm building, which is too big for apparently no obvious reason, and someone else's zImage Jan 28 21:36:04 that is not compressed Jan 28 21:36:20 I thought zImage was zlib data + executable header (to decompress)? Jan 28 21:36:22 or if you only have the zImage, you'll need to decompress it Jan 28 21:36:32 NAbyss: maybe Jan 28 21:36:43 luke-jr_: i don't know what's wrong, my zImage is too big for no apparently good reason Jan 28 21:36:46 ideas? Jan 28 21:36:48 shadows: what did you change? Jan 28 21:36:51 nothing Jan 28 21:36:54 i'm using stock everything Jan 28 21:36:56 ... Jan 28 21:36:57 it's just too big Jan 28 21:36:59 he Jan 28 21:37:01 heh. Jan 28 21:37:12 people have built this stuff on ia32 without trouble Jan 28 21:37:16 i'm on amd64 debian etch host Jan 28 21:37:19 I build on x86_64 Jan 28 21:37:21 Gentoo Jan 28 21:37:27 yes Jan 28 21:37:35 no problems here building cxx0 Jan 28 21:37:35 could you build 2.6 kernel for spitz target, tell me if it works? Jan 28 21:37:42 if it does we need to figure out why this doesn't work Jan 28 21:37:42 What is spitz? Jan 28 21:37:46 spitz is c3000 Jan 28 21:37:49 zaurus Jan 28 21:38:00 openzaurus-unstable distro Jan 28 21:38:01 hm, shouldn't mess up my cxx0 stuff then I guess? Jan 28 21:38:21 i don't know Jan 28 21:38:30 shadows: I can build 2.6 for spitz on unstable (IA32).. upto you Jan 28 21:38:49 NAbyss: if you can, that would be great. i would like to determine which part of the kernel image is too large Jan 28 21:38:57 okies, shall do Jan 28 21:39:06 shadows: what do I build? Jan 28 21:39:13 i will upload my config Jan 28 21:39:16 one second please Jan 28 21:39:23 shadows: Oh, do you still need the oz354 stuff? Jan 28 21:39:32 you changed the config...? Jan 28 21:39:37 NAbyss: i think no, i have everything downloaded for it Jan 28 21:39:52 okies Jan 28 21:39:58 luke-jr_: per the GettingStarted instructions Jan 28 21:40:09 shadows: ah, ok... not the kernel config, then? Jan 28 21:40:16 correct Jan 28 21:40:17 shadows: what do I build for spitz kernel? Jan 28 21:40:22 kernel config is defconfig-cxxx0 Jan 28 21:40:23 or whatever Jan 28 21:40:33 luke-jr_: i will have a config for you, hang on Jan 28 21:40:42 I have a config... :\ Jan 28 21:40:50 just tell me what providee to build =p Jan 28 21:41:11 http://jnc.pimpcat.org/files/local.conf~jnc_oz Jan 28 21:42:04 this was the .dev branch Jan 28 21:42:15 build *what*? Jan 28 21:42:18 err Jan 28 21:42:28 i may not know how to say Jan 28 21:42:37 NAbyss: what should i be asking luke to do? Jan 28 21:42:52 ... Jan 28 21:42:55 bitbake@Schala:~$ bitbake linux-openzaurus Jan 28 21:42:56 shadows: just build one of the XYZ-image targets Jan 28 21:43:01 oh okay Jan 28 21:43:05 bitbake virtual/linux Jan 28 21:45:36 this must be a bug of some kind Jan 28 21:45:50 even if i wanted to work around it, how would i shave off 25208 bytes compressed? Jan 28 21:46:00 that is a lot to ask, from changing kernel config Jan 28 21:46:11 shadows: Modules for a few things? Jan 28 21:46:26 everything is built as a module that can be, in defconfig, i think Jan 28 21:46:43 unless i missed some things. i read the defconfig and it is quite skinny Jan 28 23:06:58 ....the hell? Jan 28 23:07:08 ERROR: Cannot satisfy the following dependencies for gpe-task-base: libmimedir-0.3-0 (>= 0.3.1+cvs-20060102) Jan 28 23:07:25 this is in oz354fam083 for gpe-image... Jan 28 23:07:41 o_O Jan 28 23:09:09 grrrr...looks like it's the feed updater Jan 28 23:28:49 JustinP: how could i reduce the size of the defconfig? Jan 28 23:29:00 i need to cut out about 20kb compressed Jan 28 23:34:45 umm....just remove some stuff..... Jan 28 23:34:59 I'm not an expert on the kernel modules Jan 28 23:35:08 like what? give me an example... most of this stuff is *required* Jan 28 23:35:12 or the thing won't boot Jan 28 23:35:37 that's besides the point that it's big for no known reason Jan 28 23:35:56 i want to help fix this and i don't know what the next step is Jan 28 23:36:14 I don't know Jan 28 23:38:44 maybe it's the libc? Jan 28 23:38:53 NOTE: multiple providers are available (glibc, glibc-intermediate); Jan 28 23:38:53 NOTE: consider defining PREFERRED_PROVIDER_virtual/arm-linux-libc-for-gcc Jan 28 23:38:53 NOTE: package linux-openzaurus-2.6.15: started Jan 28 23:40:34 no, that's normal Jan 28 23:40:49 I suggest trying to make the inet stuff m instead of y Jan 28 23:42:00 hmm Jan 28 23:42:34 just edit the defconfig and then do i need to do anything to clear out the working directory Jan 28 23:42:37 just to see if this "too big kernel" boots Jan 28 23:42:43 mmhm Jan 28 23:42:48 you need to clean the kernel Jan 28 23:43:01 did you ever respond to the requests on the list? Jan 28 23:43:29 list o_O ? where to sign up Jan 28 23:43:32 i would go do that Jan 28 23:44:06 someone else was complaining about a too big kernel...someone said to check the objdump diffs Jan 28 23:44:31 RP suggested this. i await someone to provide me with data to compare to Jan 28 23:44:42 ah Jan 28 23:44:42 or a command i should run to generate data reflecting my kernel Jan 28 23:45:06 there's the openzaurus-users list and an openembedded list Jan 28 23:45:36 hooray for gmail Jan 28 23:45:41 :-) Jan 28 23:46:22 I'm going to try a 2.6 compile on am amd64 but I have to do a pretty much fresh pull...will take a while Jan 28 23:46:35 do you want my oe.db ? Jan 28 23:46:49 I'd use a snapshot but I can't use it Jan 28 23:46:56 can't ... ? Jan 28 23:46:57 oh Jan 28 23:46:59 too old monotone Jan 28 23:47:02 yeah Jan 28 23:47:03 :( Jan 28 23:47:20 what about using a tarball of the checked out sources Jan 28 23:47:45 why the hell didn't I think of that? Jan 28 23:47:49 bad idea maybe for the long term, but would be useful to bugtest Jan 28 23:47:52 I'll get it Jan 28 23:48:05 I have another computer with an up to date db Jan 28 23:48:16 heh Jan 28 23:48:27 dev? Jan 28 23:48:29 yes Jan 28 23:48:44 http://jnc.pimpcat.org/files/local.conf~jnc_oz Jan 28 23:49:38 spitz, right? Jan 28 23:49:48 yep. see config i just posted above Jan 28 23:50:06 yeah, just checked it Jan 28 23:50:29 looks about like mine Jan 28 23:52:07 ah....you're jnc? Jan 28 23:52:15 I didn't realize that... Jan 28 23:52:16 oh, yes i failed to mention that Jan 28 23:52:20 sorry for the confusion Jan 28 23:52:30 np, no confusion Jan 28 23:53:18 i'm spending less time as Joe No Castle radio name for Freematrix project these days, so it's back to my old trusty nickname =) Jan 28 23:55:19 I never knew what jnc stood for Jan 28 23:56:33 and I never got OE to build a kernel that works on my Z Jan 28 23:56:40 isn't life funny like that? Jan 28 23:56:48 hehe Jan 28 23:58:40 'bitbake virtual/linux' is the objective Jan 28 23:58:50 i'm trying it here with INET as a module Jan 28 23:59:09 virtual/kernel? Jan 28 23:59:30 mmhm Jan 28 23:59:39 gpe-image and opie-image depend on that Jan 28 23:59:55 which ends up checking the setting in the conf, which is linux-2.6 Jan 29 00:00:03 so that works out to build the appropriate kernel Jan 29 00:03:55 err Jan 29 00:04:01 virtual/linux didn't work Jan 29 00:04:03 weird Jan 29 00:04:56 virtual/kernel Jan 29 00:05:01 not linux Jan 29 00:06:01 that's the it Jan 29 00:29:59 shadows: I got a compile started on an amd64, but I had to start from scratch, so it will take a bit Jan 29 00:30:09 not too long, though, I think, this computer's pretty fast Jan 29 00:30:19 JustinP: thanks, i do appreciate your time Jan 29 00:30:28 i'm doing the same here, a build from scratch Jan 29 00:30:47 just to be sure it's not god herself smiting me Jan 29 00:30:59 we will see. Jan 29 00:33:13 up to gcc initial Jan 29 00:37:00 moo Jan 29 00:37:08 emte: hi Jan 29 00:37:15 emte: yo Jan 29 00:37:18 hey Jan 29 00:37:44 JustinP, still fighting with e17? Jan 29 00:38:58 i figure this week i'll need to start compiling the libraries Jan 29 00:39:14 jnc@baker:~/opensource/openzaurus/org.openembedded.dev$ monotone update Jan 29 00:39:14 monotone: already up to date at 81f8348c2be8fb48b7daf115d0524d004d939cc2 Jan 29 00:39:20 emte: yes, e-wm and entrance now have edje_cc problems.... Jan 29 00:39:30 need to figure out how to write the tslib callback Jan 29 00:39:44 JustinP, not supprising Jan 29 00:39:51 emte: but only in OE, not on my host system Jan 29 00:39:56 the cvs rss has been pretty busy Jan 29 00:40:17 in other words, it doesn't seem to be a problem with the actual code, but in OE....which is a pain Jan 29 00:41:10 yeah Jan 29 00:41:27 good morning to all :) Jan 29 00:41:36 on a side note, you dont really need to compile edje_cc Jan 29 00:41:48 huh? Jan 29 00:42:00 i dont think there is a binary issue with the edje themes Jan 29 00:42:01 the themes have to be compiled Jan 29 00:42:10 .... Jan 29 00:42:18 the libs have to be compiled Jan 29 00:42:19 i could be wrtong tho Jan 29 00:42:29 and you have to have a native edje_cc in order to compile the themes Jan 29 00:42:36 correct Jan 29 00:42:43 the edje_cc binary isn't *installed* on devices by default Jan 29 00:42:47 it's part of the dev package Jan 29 00:42:55 yeah Jan 29 00:43:09 so what are you talking about? Jan 29 00:43:15 it's not compiling edje that's the issue Jan 29 00:43:18 i was thinking more that you could just provide them as oppsed to compiling every time Jan 29 00:43:21 it's edje having an issue with the themes Jan 29 00:43:25 ah Jan 29 00:43:26 ah Jan 29 00:43:33 I suppose....it's not a great solution, though Jan 29 00:43:34 opposed* Jan 29 00:43:50 true Jan 29 00:44:35 i need to finish figuring out how to use the transparancy stuff with edje yet Jan 29 00:45:10 all fun fun Jan 29 00:49:56 whee...one computer compiling glibc and the other compiling uicmoc-native Jan 29 00:50:03 time to watch a movie Jan 29 00:50:58 lol Jan 29 00:51:23 JustinP: mine is compiling also Jan 29 00:51:34 may one of these great machines succeed at its task Jan 29 00:51:58 heh Jan 29 00:52:09 the answer, to the ultimate question of life, the universe, will kernel 2.6 compile in its expected limitation of size! Jan 29 00:52:09 my local linux box is only a <1Ghz celeron Jan 29 00:52:22 poor thing Jan 29 00:57:35 for me .. kernel 2.6 compile more fast than 2.4 ... Jan 29 01:08:48 gremlin[it]: i notice this also Jan 29 01:09:24 shadows: linux-oz 2.6 compiled.. Jan 29 01:09:41 grrr...orinoco modules in dev are failing now.... Jan 29 01:09:56 at least is the combo of kernel + gcc ... but for 2.4 it take few less than 3 hours ... for 2.6 less than an hour ! Jan 29 01:10:46 NAbyss: you bastard! it doesn't work here. heh. thanks Jan 29 01:10:56 NAbyss: what's the size (ls -l) on your kernel Jan 29 01:12:24 i should say an ls -l on the zImage Jan 29 01:12:28 if you can find it Jan 29 01:12:34 -rw-r--r-- 1 1000 1000 1285484 2006-01-29 19:06 staging/spitz-linux/kernel/zImage Jan 29 01:13:34 oh for cryin' out loud. Jan 29 01:13:38 hi all Jan 29 01:14:02 hi Mardy Jan 29 01:14:27 NAbyss: so yours is less than 1302000 Jan 29 01:14:35 shadows: Apparently so Jan 29 01:14:40 NAbyss: which revision is that tree? Jan 29 01:15:04 mine is 81f8348c2be8fb48b7daf115d0524d004d939cc2 Jan 29 01:15:27 (monotone update in the org.openembedded.dev dir should spit out a revision) Jan 29 01:15:53 3c8d4c49c9ebd7fb6d1f241d381d9b404d0efb7e Jan 29 01:16:13 err. is it possible for the revisions to match Jan 29 01:18:43 NAbyss: hey, here's an idea Jan 29 01:18:51 do you have log output from the build? Jan 29 01:20:19 shadows: Probably.. Jan 29 01:20:21 maybe we can compare logs for the build Jan 29 01:20:27 see if there is a difference Jan 29 01:20:36 like opt flags or something funky Jan 29 01:21:30 shadows: where are the logs kept? Jan 29 01:21:57 i'm looking Jan 29 01:22:22 tmp/work/arch/package/temp Jan 29 01:22:24 work/(packagename)/(packagename-version)/.... Jan 29 01:22:39 http://zaurus.tucuxi.org/c3000/tmp/work/spitz-linux/linux-openzaurus-2.6.15-r0/temp/ Jan 29 01:23:32 * shadows lftp mget's * Jan 29 01:25:17 okay, grabbed. Jan 29 01:30:30 shadows: 2.6 kernel fetching on amd64 :-) Jan 29 01:31:17 sweet. with a variety of logs, it will be certain on what the trouble may not be Jan 29 01:32:42 is the .dev HEAD/trunk/whatever of OE supposed to be building ok now in principle, i.e. all reorgs finished until next time ? Jan 29 01:32:52 I'm not sure I've seen a complete report about that in oe list Jan 29 01:32:54 which version did you compile? Jan 29 01:33:15 I've got 2.6.15-r1 compiling Jan 29 01:36:43 yes Jan 29 01:37:09 i think NAbyss did 2.6.15-r0 Jan 29 01:37:15 i am going to do 2.6.15-r1 Jan 29 01:45:04 shadows: hey I got a "too big" message Jan 29 01:45:18 holy crap Jan 29 01:45:19 Size is 1327216 Jan 29 01:45:30 hey, thanks for taking the cputime to do that Jan 29 01:45:34 * shadows scratches head Jan 29 01:45:35 np Jan 29 01:45:37 so what the fark Jan 29 01:45:41 it's someone else's anyway ;-) Jan 29 01:45:47 but he lets me use it for OE work Jan 29 01:46:05 could we try r0 on the same machine? Jan 29 01:46:26 see if the changes between r0 and r1 cause it or if it's just the ia32/amd64 difference Jan 29 01:46:32 how to procede, suggestions? Jan 29 01:46:41 yeah...I need to get that r0 bb file, though... Jan 29 01:47:48 NAbyss: can you post the bb please? Jan 29 01:47:58 hehe Jan 29 01:48:01 http://zaurus.tucuxi.org/c3000/org.openembedded.dev/packages/linux/linux-openzaurus_2.6.15.bb Jan 29 01:48:04 shadows: It's on that web address.. Jan 29 01:48:07 he already did Jan 29 01:49:00 oh okay Jan 29 01:49:06 man am i slow Jan 29 01:49:32 well, he didn't technically post it, but I figured he may have that dir on his website Jan 29 01:51:07 hmmm...maybe not Jan 29 01:51:24 oh...stupid me Jan 29 01:52:35 okay, my build is getting a start on linux-openzaurus-2.6.15-r1 again Jan 29 01:52:43 though i guess we can presume this will fail Jan 29 01:52:57 what we need maybe is an ia32 user to compile the r1 bb Jan 29 01:53:01 NAbyss: pssssst Jan 29 01:53:06 shadows: hm? Jan 29 01:53:08 wink wink nudge nudge Jan 29 01:53:51 NAbyss: JustinP building the linux-openzaurus-2.6.15-r1 on amd64 confirms the size-too-big trouble i mentioned Jan 29 01:54:08 NAbyss: could you try out building linux-openzaurus-2.6.15-r1 on ia32? Jan 29 01:54:26 shadows: what machine do you want the kernel for? Jan 29 01:54:26 what do you mean by ia32? Jan 29 01:54:28 shadows: Sure, got a revision number that builds nicely? Jan 29 01:54:35 johnX: target is spitz Jan 29 01:54:45 I can build it here Jan 29 01:54:49 okay Jan 29 01:55:12 i'm going crazy trying to determine if this is a build host problem, or something to be expected Jan 29 01:55:47 i know that amd64 gcc has extra flags that are defaults Jan 29 01:56:05 maybe this is why? would like to find and fix Jan 29 01:59:06 NAbyss: what sort of revision number are you looking for, i am not understanding Jan 29 01:59:46 shadows: revision number from monotone Jan 29 01:59:51 Unless the head is safe to build.. Jan 29 02:00:10 head Jan 29 02:00:11 oh! 81f8348c2be8fb48b7daf115d0524d004d939cc2 Jan 29 02:00:15 that is what i have Jan 29 02:00:25 it is head, i think Jan 29 02:00:38 as of late saturday here in usa Jan 29 02:00:55 building r0 Jan 29 02:01:00 | Size is 1327208 Jan 29 02:01:01 | FATAL: This kernel is t.... Jan 29 02:01:31 JustinP: why would yours be different by 8 bytes Jan 29 02:01:35 or mine different Jan 29 02:01:42 does that make sense? Jan 29 02:01:59 Weird... mine's head.. well, no updates from vanille.de at least.. Jan 29 02:02:20 don't know.... Jan 29 02:02:37 Ah, crap.. never mind. Jan 29 02:02:54 Bloody monotone doesn't say if the branch doesn't exist.. keep saying openzaurus.dev instead of oe.dev Jan 29 02:03:30 I use a shell alias Jan 29 02:04:38 shadows: r0 is also too big Jan 29 02:04:43 Size is 1327224 Jan 29 02:04:47 oh ffs Jan 29 02:07:09 I haven't tried a clean build, of course.... Jan 29 02:07:49 hey, 8b different than r1 Jan 29 02:09:22 03koen 07org.oe.oz354fam083 * ra2e3bdde... 10/conf/distro/familiar.conf: familiar.conf: RDEPEND on libgcc1 to work around a stupid OE bug Jan 29 02:10:05 goodmorning ! Jan 29 02:12:52 JustinP: so what say ye Jan 29 02:12:54 heh Jan 29 02:13:06 is this a bug in the gcc-3.4.4 cross compiler? Jan 29 02:15:03 shadows: did you still want that spitz kernel image? Jan 29 02:15:14 johnX: did it build? Jan 29 02:15:25 i'm interested in nailing this bug Jan 29 02:15:29 yup, I'm on an IA32 system Jan 29 02:15:39 * shadows swears at the wall Jan 29 02:15:53 okay Jan 29 02:16:12 possibilities for size differences on amd64 versus ia32 within context of OE Jan 29 02:16:34 1) compilers are buggy and generate different output depending on arch being run on Jan 29 02:17:21 2) opimization flags are defaulting to different arrangements, resulting in an non-explicit increase in object size for amd64 versus ia32 Jan 29 02:18:38 any other possibilities you guys can think of? Jan 29 02:25:48 bugs.openembedded.org down, i was going to report this Jan 29 02:25:49 but um Jan 29 02:26:21 use http://bugs.treke.net Jan 29 02:26:46 'k Jan 29 02:27:09 shadows: The difference you mention is only at the kernel lever or at packages also ? Jan 29 02:27:38 Ifaistos: i don't know about packages yet Jan 29 02:27:43 it is a good point Jan 29 02:28:05 shadows: want me to build nano and you can try as well on AMD64? Jan 29 02:28:11 ah, yes Jan 29 02:28:19 i will start the build Jan 29 02:28:50 we working on amd64/ubuntu 1.05 , never tried intel to see if there were difference Jan 29 02:36:31 shadows: ok, built Jan 29 02:36:45 ditto Jan 29 02:36:49 how shall we do this? Jan 29 02:37:46 jnc@baker:~/opensource/openzaurus/build/oetmp/deploy/ipk$ ls -l nano_1.3.9-r0_armv5te.ipk Jan 29 02:37:49 -rw-r--r-- 1 jnc jnc 56028 2006-01-29 03:36 nano_1.3.9-r0_armv5te.ipk Jan 29 02:38:47 bitbake@Schala:~/tmp/deploy/ipk$ ls -l nano_1.3.9-r0_armv5te.ipk Jan 29 02:38:51 -rw-r--r-- 1 bitbake bitbake 56022 2006-01-29 01:35 nano_1.3.9-r0_armv5te.ipk Jan 29 02:39:12 jnc@baker:~/opensource/openzaurus/build/oetmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9$ ls -l src/nano Jan 29 02:39:15 -rwxr-xr-x 1 jnc jnc 133806 2006-01-29 03:36 src/nano Jan 29 02:39:40 bitbake@Schala:~/tmp/work/armv5te-linux/nano-1.3.9-r0/nano-1.3.9$ ls -l src/nano Jan 29 02:39:42 -rwxr-xr-x 1 bitbake bitbake 133172 2006-01-29 01:34 src/nano Jan 29 02:39:57 03koen 07org.oe.oz354fam083 * rb9d75d30... 10/contrib/buildscripts/familiar/build-fam.sh: familiar buildscript: build SDK as well Jan 29 02:39:57 o-kay. Jan 29 02:40:40 i wonder if objdump could illuminate more info Jan 29 02:40:46 i don't know how to use it Jan 29 02:40:55 neither do I Jan 29 02:41:15 johnX: please do the output of objdump -x nano into a file and upload Jan 29 02:41:25 i will do the same and make a diff Jan 29 02:42:11 uhm, where should I upload it to? Jan 29 02:42:16 oh Jan 29 02:43:03 if you could make it available, otherwise as an attachment to lucent@gmail.com Jan 29 02:43:18 I can put it on anonymous ftp on my machine Jan 29 02:43:21 i would like the output of objdump -x nano, and also objdump -p nano Jan 29 02:43:22 hang on a second Jan 29 02:43:24 that'd work Jan 29 02:44:35 and actually, the output of objdump -d nano, as a third file Jan 29 02:44:54 if this is a gcc bug, it would be helpful to know what instructions are going bogus Jan 29 02:45:07 * johnX configures his ftp daemon Jan 29 02:46:38 03koen 07org.oe.oz354fam083 * r2171768a... 10/conf/local.conf.familiar-0.8.3: local.conf.familiar-0.8.3: add local.conf for building familiar 0.8.3 Jan 29 02:46:42 Ifaistos: okay Jan 29 02:50:24 objdump -d fails Jan 29 02:50:27 objdump: Can't disassemble for architecture UNKNOWN! Jan 29 02:53:39 hah, what the hell Jan 29 02:53:41 http://bugs.treke.net/show_bug.cgi?id=637 Jan 29 02:54:01 you may need updated objdump utils Jan 29 02:54:20 ftp://bloom.jads.com for the ones that worked Jan 29 02:56:52 thanks again Jan 29 02:59:57 what the hell **** ENDING LOGGING AT Sun Jan 29 02:59:57 2006