**** BEGIN LOGGING AT Fri Nov 23 02:59:57 2007 Nov 23 05:25:42 03xjqian 07org.oe.dev * r26e5f15f... 10/ (1 packages/fftw/fftw.inc): fftw: add RPROVIDES libfftw3 Nov 23 05:25:49 03xjqian 07org.oe.dev * r9c21936e... 10/ (8 files in 3 dirs): octave: add buidable stable 2.1.73 and testing 2.9.17 Nov 23 05:25:56 03xjqian 07org.oe.dev * r90ff90e8... 10/ (4 files in 2 dirs): gcc-(cross)_4.1.2: enable gfortran and gfortran packaging Nov 23 05:26:03 03xjqian 07org.oe.dev * rbc1afd49... 10/ (7 files in 2 dirs): mpfr: add (native)_2.3.0, unify, closes #3339 Nov 23 05:26:09 03xjqian 07org.oe.dev * r90119a69... 10/ (7 files in 2 dirs): disapproval of revision 'bc1afd499eafe3cff3eb38a3d5766aaa0a823536' Nov 23 05:26:15 03xjqian 07org.oe.dev * r37a8c106... 10/ (1 packages/gcc/gcc-package-cross.inc): gcc-package-cross.inc: link gfortran to g77 Nov 23 07:03:05 * * OE Bug 3038 has been RESOLVED (FIXED) by xjqian(AT)gmail.com Nov 23 07:03:07 * *  octave-2.9.14-r0-do_configure Nov 23 07:03:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3038 Nov 23 07:16:29 * welp waves at CoreDump Nov 23 07:16:34 * welp just got up *yawn* Nov 23 07:28:53 good morning Europe :} Nov 23 07:47:17 03xjqian 07org.oe.dev * rec9b4188... 10/ (1 packages/gsl/gsl_1.4.bb packages/gsl/gsl_1.10.bb): gsl: bump to new stable 1.10 version. Nov 23 07:54:56 would someone be kind enough to implement "bitbake -c oldconfig virtual/kernel" ? Nov 23 07:57:27 "bitbake -c menuconfig virtual/kernel" is so nice, but it is missing so many things that a "make oldconfig" would fix... Nov 23 07:58:48 Zero_Chaos: try running bitbake -c conrfigure virtual/kernel first Nov 23 07:59:20 Zero_Chaos: make oldconfig is part of the configure task for kernels Nov 23 07:59:32 k Nov 23 07:59:46 Zero_Chaos: np Nov 23 07:59:53 but since I have already built the kernel, would that not have already happened? Nov 23 08:00:35 Zero_Chaos: it should have... Nov 23 08:01:05 well, um... it appears that either it did not, or someone hacked out a crap lot of wifi drivers. Nov 23 08:01:10 I'm guessing the former Nov 23 08:02:48 I'm presuming that the config it presents is the defconfig-$machine ? because I just edited that file and the things I added did not show up.... Nov 23 08:02:55 so I'm more that slightly confused now. Nov 23 08:04:48 Zero_Chaos: hmm...not sure whats up with that. I ususally copy the .config file from make menuconfig back to the defconfig-$machine file and run bitbake -c rebuild "kernel" Nov 23 08:05:14 Zero_Chaos: you might want to check with RP later when he's up Nov 23 08:05:55 hvontres|home: I didn't realize I had to copy the .config file at all, I would have thought that "bitbake -c menuconfig" would handle all that kind of stuff for me... but, it seems not. well, there are ways to solve it for now ;-) Nov 23 08:06:02 hvontres|home: thanks anyway Nov 23 08:07:18 okay, honestly, now I'm just fscking mad Nov 23 08:07:38 I did a diff of the .config in the kernel build directory against the defconfig-akita and it is not the same Nov 23 08:07:45 I mean seriously, I'm confused Nov 23 08:09:01 * Bernardo was thinking on changing some akita kernel options too, will wait... :) Nov 23 08:09:50 Zero_Chaos: I've still got the whitescreen when I try to use "-vo pxa" with mplayer, and wanted to play around with kernel configuration... Nov 23 08:12:44 and yes, the defconfig-akita and the .config used have diferences Nov 23 08:14:17 besides the date Tue Oct 16 13:20:27 2007 versus Thu Nov 22 19:32:25 2007 (which is the build date), there are some "LOGO" options and the "debug" at the end of the cmdline is replaced by a "quiet" Nov 23 08:14:28 is that what you're seeing? Nov 23 08:15:59 Bernardo: that and the fact that it drops my additions from defconfig-akita, yeah Nov 23 08:16:29 Bernardo: there is a driver that I KNOW is in this kernel version, and when I add the line to build that module, it gets removed. Nov 23 08:19:21 which one? Nov 23 08:20:10 I'll try to build it later... I do need to try some options to see if pxa will work Nov 23 08:20:17 rtl8187 Nov 23 08:25:41 ok, will add it and check what happens, if it gets removed. Nov 23 08:25:43 bbl Nov 23 08:27:10 * Bernardo kicks menuconfig Nov 23 08:27:45 it seems "bitbake -c menuconfig" needs gnome-terminal, which doesn't exist on my system - kde only... Nov 23 08:29:05 and searching defconfig-akita there is no obvious option for RTL8187 Nov 23 08:29:27 Bernardo: org.openembedded.dev/conf/bitbake.conf will allow you to pick a different terminal Nov 23 08:29:40 and I know there is not option for rtl8187, that is why I added it. Nov 23 08:29:54 the kernel version has it, I know this ;-) Nov 23 08:32:22 ok, I've changed local.conf to have TERMCMD = "${KONSOLE_TERMCMD}" and TERMCMDRUN = "${KONSOLE_TERMCMDRUN} Nov 23 08:32:37 that should do it I think Nov 23 08:32:37 really have to run now, will be back in a hour, will try it then Nov 23 08:33:12 gl Nov 23 08:44:00 gm Nov 23 08:45:14 good morning all Nov 23 08:45:40 moin moni Nov 23 08:46:02 or moin lag in my case Nov 23 08:46:19 moin Nov 23 08:52:37 hello Nov 23 08:52:42 I figured out part of the reason why it was not working, and I blame me. Nov 23 08:53:21 hvontres|home: you were right, thanks for the help ;-) oldconfig was run, I missed a config option that the driver depended on so it never showed. Nov 23 08:56:02 I presume that "bitbake -c menuconfig virtual/kernel" does NOT save the config back to defconfig-$machine in the local monotone tree.... is this correct? Nov 23 09:01:27 correct Nov 23 09:01:55 koen: thanks Nov 23 09:03:15 Okay, back to my original question now... akita has 128 megs of flash, and cannot flash a 50mb image, says it is too big. Obviously this is a partitioning issue, if I make the / partition bigger, will the flash then succeed, or is there more in my way? Nov 23 09:03:44 there will be more in your way Nov 23 09:03:51 flash is not a block device Nov 23 09:04:06 so thinking of it as a regular harddisk will only get you in trouble Nov 23 09:04:46 so how big can my image get before it is too big then? Nov 23 09:04:55 any idea for akita? Nov 23 09:06:18 no idea Nov 23 09:06:34 iirc the new updater.sh reports the sizes Nov 23 09:06:53 well, it reported that my image was too big for sure :-) Nov 23 09:08:51 what do I put in conf/local.conf to force it to build certain packages but not ship them with the image? Nov 23 09:09:21 'bitbake foo1 foo2 foo3 bla-image' Nov 23 09:09:25 no need for local.conf Nov 23 09:10:26 well that I know, but I don't want to have to type a huge string every time I build. I just kind of what these things always built when I build an image, but not shipped in the flash due to space concerns. Nov 23 09:15:21 Zero_Chaos: make a shell script ? Nov 23 09:16:11 hvontres|home: there used to be something I put in conf/local.conf, something to the effect of image_rdepends = "foo1 foo2" Nov 23 09:18:51 ok, time to go to bed Nov 23 09:39:16 morning all Nov 23 09:40:19 RP: morning. Nov 23 09:40:20 morning RP Nov 23 09:40:52 RP: I have a defconfig-akita update that likely applies to any device with usb ports. Nov 23 09:41:15 Zero_Chaos: More modules? Nov 23 09:41:46 RP: exactly. now that we are on 2.6.23 a lot of the ugly wifi stuff I was miserably failing to make work... well it all just works now :-) Nov 23 09:42:17 Zero_Chaos: ok. File a bug with the patch and I'll try and look at it Nov 23 09:42:23 RP: I will post the diff after I test it. it is almost 5am so I am not posting anything till after a test :-) Nov 23 09:42:27 I will Nov 23 09:47:16 morning Nov 23 09:50:03 Zero_Chaos: boot akita and paste /proc/mtd please Nov 23 09:50:15 "grep root /proc/mtd" line will be enough Nov 23 09:50:41 hrw: not sure if I have a working system right now, let's find out Nov 23 09:51:52 it will not even turn on after my previous failed flash. Nov 23 09:51:58 so um, gimme a few ;-) Nov 23 09:52:10 ok Nov 23 09:57:51 thank the lord for builtin flashing Nov 23 09:58:17 I press power and the thing blinks then nothing, but the flasher comes up fine Nov 23 09:58:29 morning! Nov 23 09:59:21 greetings Nov 23 09:59:23 hrw: mtd2: 03a00000 00020000 "root" Nov 23 09:59:42 hrw: and I cannot flash the 50mb image I made last night, nor the 34mb image I just tried Nov 23 09:59:45 WTF? Nov 23 10:00:04 * Zero_Chaos is starting to have a bad day... Nov 23 10:01:48 03koen 07org.oe.dev * r4ca8a8b2... 10/ (1 packages/openmoko2/openmoko-dialer2_svn.bb): openmoko-dialer2: depend on libjana, closes #3357 Nov 23 10:08:05 anyone seen something like that before -> http://www.rafb.net/paste/ Nov 23 10:08:50 steliosk: yeah, i see pastebins all the time Nov 23 10:08:57 http://rafb.net/p/rwuUlc25.html Nov 23 10:09:14 Zero_Chaos : heh Nov 23 10:09:33 out of hd space? Nov 23 10:09:55 Zero_Chaos : nop. Nov 23 10:10:05 steliosk: sorry, that was all I had :-) Nov 23 10:12:04 * * OE Bug 3356 has been created by eha(AT)doredevelopment.dk Nov 23 10:12:06 * * U-Boot utils (mkimage) git recipes Nov 23 10:12:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3356 Nov 23 10:12:16 * * OE Bug 3357 has been created by autobuild(AT)openembedded.org Nov 23 10:12:18 * * openmoko-dialer2-0.1.0+svnr3481-r5-do_configure Nov 23 10:12:20 * * http://bugs.openembedded.org/show_bug.cgi?id=3357 Nov 23 10:12:28 * * OE Bug 3358 has been created by eha(AT)doredevelopment.dk Nov 23 10:12:30 * * dtc native and sdk git versions Nov 23 10:12:32 * * http://bugs.openembedded.org/show_bug.cgi?id=3358 Nov 23 10:21:57 Zero_Chaos: look at table file and compare it with others Nov 23 10:23:44 makedevs: /work/oplinux-0.2/tmp/uclibc/rootfs/mpc8323e-rdb/dev/initctl: file can not be created with mknod! Nov 23 10:26:04 hrw: I'm sorry, table file? Nov 23 10:28:09 Zero_Chaos: the changes I made with "bitbake -c menuconfig" stayed Nov 23 10:28:26 koen : Seen that but the question is "why" ? Nov 23 10:28:37 Bernardo: I figured it all out, thanks Nov 23 10:28:53 koen : What efects makedevs not to be able to write to the rootfs dir Nov 23 10:28:56 ok Nov 23 10:29:11 Zero_Chaos: /work/oplinux-0.2/metadata/files/device_table-minimal.txt Nov 23 10:29:15 koen : fakeroot maybe ? Nov 23 10:29:43 steliosk: I read that message as "that's not a devnode, so I'm not going to create it" Nov 23 10:29:50 I could be wrong :) Nov 23 10:30:40 koen : hmmm but i am using the "default" device_table-minimal.txt from OE so it should be the same with angstrom but its not Nov 23 10:31:39 hrw: don't seem to have one of those Nov 23 10:35:00 hrw: found it, but it means nothing to me. It is 5:39am so I'm going to cut my losses and go to sleep. hope to talk to you later Nov 23 10:35:04 g'nite all Nov 23 10:41:04 * * OE Bug 3357 has been RESOLVED (FIXED) by koen(AT)openembedded.org Nov 23 10:41:06 * * openmoko-dialer2-0.1.0+svnr3481-r5-do_configure Nov 23 10:41:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3357 Nov 23 10:53:58 koen_: when you have time, look at http://bugs.openembedded.org/show_bug.cgi?id=3342 since I provided the patch to fix it Nov 23 10:54:07 koen_: and it's really simple :-) Nov 23 10:54:31 Has someone produced a recipe to cmake? Nov 23 11:00:29 i do it when i've a working oe .. Nov 23 11:00:50 Genesis: do what? Nov 23 11:01:09 a cmake recipe , if no one exist ( i'm sure that exists ) Nov 23 11:01:30 do you look on the bugzilla ? Nov 23 11:01:34 I failed to find it Nov 23 11:01:43 I can do Nov 23 11:01:43 a lot of recipe are never commited or 10 months after Nov 23 11:01:52 when package are obsolete Nov 23 11:02:20 Genesis: good, I'll take a look and if it's obsoleted I'll see if I can update it Nov 23 11:03:15 Genesis: do you have commit rights? Nov 23 11:03:26 not yet Nov 23 11:03:29 Genesis: I can provide you the openrdate recipe I've wrote Nov 23 11:04:41 ask for commit rights on the mailing list Nov 23 11:07:36 I doubt I deserve it yet. I'm just starting to contribute to OE Nov 23 11:08:34 oki Nov 23 11:12:01 morning folks Nov 23 11:12:51 hey mickeyl Nov 23 11:12:52 morning Nov 23 11:13:15 morning koen Nov 23 11:13:28 Genesis: no bugs reported about cmake Nov 23 11:14:00 yeap Nov 23 11:14:12 yo koen Nov 23 11:17:49 koen: please copy the packages/mozilla/files/arm to packages/mozilla/files/i[3456]86 otherwise jsautocfg.h isn't found Nov 23 11:23:04 mickeyl: http://www.flickr.com/photos/koenkooi/2057139638/ Nov 23 11:24:12 sweet Nov 23 11:24:27 I'm now playing with the included gps applet Nov 23 11:24:44 it works with bluetooth gps receivers out of the box Nov 23 11:24:52 hmm, cool Nov 23 11:25:35 once i'm done with tools, i'll look more closely to what hildon provides Nov 23 11:25:53 will hopefully have the n810 by then Nov 23 11:26:12 rumour has that it will be released 20071219 Nov 23 11:26:19 ah Nov 23 11:26:26 might make it under the xmas tree then Nov 23 11:27:18 http://scap.linuxtogo.org/ has some more a780 screenshots Nov 23 11:29:20 mickeyl: and it's now safe to do sed -i sed s:kabel.utwente.nl:thruhere.net:g config.ini on the openmoko planet Nov 23 11:40:48 hi all. i just discovered in incompatibility between avahi and libdaemon on xscale pxa270. Nov 23 11:42:01 libdaemon should be version 0.12, but only version 0.11 is in the repository. copying the recipe from libdaemon_0.11.bb to libdaemon_0.12.bb worked for me. maybe someone can include this in the repository? Nov 23 11:42:34 report bug? Nov 23 11:43:08 hrw: the avahi-daemon segfaults with an alignment trap Nov 23 12:02:37 ok, added bug 3359, thanks Nov 23 12:06:01 hmmm Nov 23 12:06:02 linux-2.6.23.8.tar.bz2 Nov 23 12:06:20 I wonder which recipe forced me to download 40MB without a good reason Nov 23 12:10:04 hi Laibsch Nov 23 12:10:19 Hi there Nov 23 12:10:48 moin Laibsch Nov 23 12:14:01 Has anyone seen this? Nov 23 12:14:02 | /home/otavio/hacking/ossystems/osthinclient/oe/org.openembedded.dev/tmp/staging/i586-angstrom-linux/include/pango-1.0/pango/pangocairo.h:71: error: 'cairo_font_type_t' was not declared in this scope Nov 23 12:14:06 | /home/otavio/hacking/ossystems/osthinclient/oe/org.openembedded.dev/tmp/staging/i586-angstrom-linux/include/pango-1.0/pango/pangocairo.h:73: error: 'cairo_font_type_t' does not name a type Nov 23 12:17:06 otavio: is that with angstrom-2007.1? Nov 23 12:19:02 koen: yes Nov 23 12:19:33 koen: I tried to compile firefox 2.0.0.3 (after do the copy on i[3456] I said above) Nov 23 12:19:38 looks like it's missing the cairo cflags Nov 23 12:19:59 koen: I'm now building with 1.18.3 to see if it works and then I'll compare Nov 23 12:20:07 koen: yes, looks to be it Nov 23 12:20:17 koen: will try .3 and then I report Nov 23 12:38:32 03koen 07org.oe.dev * r5032c968... 10/ (1 packages/libdaemon/libdaemon_0.12.bb): libdaemon: add 0.12 Nov 23 12:43:24 CIA-33: thanks. should i mark bug 3359 as resolved? Nov 23 12:44:30 justri: build, test, mark Nov 23 12:50:44 hrw: ok. built, tested, marked ;-) Nov 23 12:58:05 * * OE Bug 3359 has been created by justri(AT)justri.dyndns.org Nov 23 12:58:07 * * libdaemon-0.11 segfaults with avahi-daemon on arm/ xscale pxa270 Nov 23 12:58:09 * * http://bugs.openembedded.org/show_bug.cgi?id=3359 Nov 23 13:01:41 OE packaging suxx Nov 23 13:27:04 * * OE Bug 1538 has been RESOLVED (FIXED) by bluelightning(AT)bluelightning.org Nov 23 13:27:06 * *  allow Opie-PIN to accept input via cursor keys Nov 23 13:27:08 * * http://bugs.openembedded.org/show_bug.cgi?id=1538 Nov 23 13:27:16 * * OE Bug 3359 has been RESOLVED (FIXED) by justri(AT)justri.dyndns.org Nov 23 13:27:18 * *  libdaemon-0.11 segfaults with avahi-daemon on arm/xscale pxa270 Nov 23 13:27:20 * * http://bugs.openembedded.org/show_bug.cgi?id=3359 Nov 23 13:55:04 * * OE Bug 2780 has been marked as DUPLICATE of bug 1866 by Nov 23 13:55:07 * *  mysql-4.1.18-r2-do_compile Nov 23 13:55:09 * * http://bugs.openembedded.org/show_bug.cgi?id=2780 Nov 23 14:28:43 hrw|afk: there're plans to improve OE packaging? Nov 23 14:44:04 * * OE Bug 239 has been RESOLVED (FIXED) by Nov 23 14:44:06 * *  mysql corruption changed my name to the one from #2147 Nov 23 14:44:08 * * http://bugs.openembedded.org/show_bug.cgi?id=239 Nov 23 14:59:28 otavio: no Nov 23 15:05:19 some packages are wrongly packaged so other packages takes lof of unneeded stuff Nov 23 15:05:34 for example: bluez depends on hal instaed of libhal Nov 23 15:05:47 something depends on cups instead of libcups Nov 23 15:05:48 etc Nov 23 15:07:09 by Nov 23 15:19:11 hello! Nov 23 15:19:45 I am trying to build a qemux86/uclibc image, and am running into trouble which seems to come from insane.bbclass Nov 23 15:21:05 insane.bbclass declares package_qa_get_machine_dict(): which returns a dict containing various pieces of information concerning different machine types Nov 23 15:22:34 this dict is missing information for uclibc / i*86. What I don't understand is why there are separate entries for "linux" and "linux-uclibc" Nov 23 15:22:49 any ideas? Nov 23 16:00:51 03jeremy_laine 07org.oe.dev * rf55f637f... 10/ (3 files in 3 dirs): uclibc-0.9.29: add configuration for qemux86 machine Nov 23 16:00:59 Any body with an akita that is of the higher levels? Someone that would know things like max flashable image sizes.... Nov 23 16:02:38 03jeremy_laine 07org.oe.dev * re48283e1... 10/ (1 classes/insane.bbclass): insane.bbclass: add package_qa_get_machine_dict() entries for linux-uclibc / i*86 Nov 23 16:14:27 Wow, I never notice that updater.sh was not a shell script... wonderful name though Nov 23 16:19:22 re Nov 23 16:19:32 Zero_Chaos: updater.sh is shellscript Nov 23 16:19:45 but to flash you need to 'code' it Nov 23 16:19:56 Zero_Chaos: give me /proc/mtd output from akita... Nov 23 16:21:03 hrw: thought I did that last night? Nov 23 16:21:17 (well 5 hours ago anyway) Nov 23 16:21:34 you had to but not given Nov 23 16:21:47 ops. found Nov 23 16:21:49 sorry Nov 23 16:21:51 03a00000 is the root size Nov 23 16:21:53 no worries Nov 23 16:22:05 23 11:01 < Zero_Chaos> hrw: mtd2: 03a00000 00020000 "root" Nov 23 16:22:08 yup Nov 23 16:22:20 where can I read updater.sh.akita in uncoded form? Nov 23 16:22:55 packages/zaurus-updater/zaurus-updater/updater.sh Nov 23 16:23:00 thanks Nov 23 16:23:30 change 0x1900000 to 0x3a00000 and test Nov 23 16:23:56 There's any helper to prepare a flash to be bootable? Nov 23 16:24:03 otavio: ? Nov 23 16:24:14 I found bootimg that produces an iso image but it isn't working (bootimg.class) Nov 23 16:24:27 ZAURUS='akita' Nov 23 16:24:27 - ROOTFS_SIZE=0x1900000 Nov 23 16:24:27 + ROOTFS_SIZE=0x3a00000 Nov 23 16:24:44 Zero_Chaos: thats whole change Nov 23 16:24:57 Zero_Chaos: then rebuild zaurus-updater and test Nov 23 16:24:58 hrw: *-image produce the image but they has the kernel and the filesystem ... to make it be bootable in a single flash I'd need to put a boot loader and like, right? Nov 23 16:25:12 otavio: for which device? Nov 23 16:25:19 i386 Nov 23 16:25:35 otavio: i386 is arch not device Nov 23 16:25:49 hrw: a thinclient .. Nov 23 16:26:01 hrw: we'd like to put an ext2 and it to be bootable Nov 23 16:26:12 hrw: it ought to boot from the flash ... Nov 23 16:26:20 hrw: so I make that change in zaurus updater and it will permit a maximum flashable image of what? (presuming of course that it works Nov 23 16:26:25 ) Nov 23 16:26:40 Zero_Chaos: yes Nov 23 16:26:56 otavio: how that flash appear to bios? Nov 23 16:28:13 hrw: so I edit that file, then -c rebuild zaurus-updater then try to reflash? Nov 23 16:28:16 yes Nov 23 16:28:19 k Nov 23 16:28:32 w8.. Nov 23 16:28:36 you know how big 3a00000 is? Nov 23 16:28:55 first remove akita dir from there Nov 23 16:29:01 hrw: usb Nov 23 16:29:08 /bin/sh: line 0: printf: 3a00000: invalid number Nov 23 16:29:08 hrw: k Nov 23 16:29:09 0 Nov 23 16:29:14 60817408 Nov 23 16:29:27 hrw: i think i would just need to make it a bootable using syslinux or grub or whatever Nov 23 16:29:30 confused (about the error not the size) Nov 23 16:29:37 otavio: so you need syslinux + kernel + image Nov 23 16:29:48 hrw: I'm interested to know if there's something to _help_ to make it on OE Nov 23 16:29:52 Zero_Chaos: ignore - 3a00000h == 60817408 Nov 23 16:30:33 otavio: bootimg generate iso and hddimage Nov 23 16:31:00 hrw: so the directions stand, make the change then try to flash ? Nov 23 16:31:17 yes Nov 23 16:31:23 hrw: can't updater.sh read the /proc/mtd itself? Nov 23 16:31:57 koen: can - but this will be next addon Nov 23 16:32:12 koen: I want to know that we can use this updater safely Nov 23 16:32:24 hrw: bootimg failed to me Nov 23 16:32:39 hrw: when I putted it on the recipe bitbake backtraces Nov 23 16:32:41 koen: it spent over year in bugtracker and no one provided changes to it Nov 23 16:33:24 koen: first version I wrote after oedem2006, second after oedem2007 - and then we got fix for tosa because I asked Dmitriy to look at problem Nov 23 16:33:51 otavio: umbatyr 1.13.5 fails for me Nov 23 16:36:01 ? Nov 23 16:36:11 * otavio still new on the game ;-) Nov 23 16:37:02 otavio: do not tell 'this fails for me' - pastebin error log and then tell Nov 23 16:37:23 hrw: OK Nov 23 16:37:39 hrw: just let the firefox finish building and then I'll put it there Nov 23 16:38:02 koen: found the problem on firefox .. testing the fix and then will report the bug Nov 23 16:38:08 hrw: updater.sh actually does check for the size: RO_MTD_SIZE_HEX Nov 23 16:38:28 it reads size but not use Nov 23 16:38:29 I know Nov 23 16:38:33 heh Nov 23 16:39:22 this code it mess still Nov 23 16:39:29 so for most models you can use ROOTFS_SIZE=${RO_MTD_SIZE_HEX} Nov 23 16:39:36 for all Nov 23 16:39:59 even for c3xxx? Nov 23 16:40:52 even Nov 23 16:41:05 we do not flash rootfs on c3x00 Nov 23 16:41:24 Firefox build failure: http://paste.debian.net/43259 Nov 23 16:41:38 It's caused since it uses the internal copy of cairo.h Nov 23 16:42:02 hrw: ok to commit http://ewi546.ewi.utwente.nl/tmp/rosize.diff.txt ? Nov 23 16:42:39 no Nov 23 16:42:51 what needs changing? Nov 23 16:43:02 you will see in next commits Nov 23 16:43:34 * koen mtn pull Nov 23 16:43:43 first I have to push ;D Nov 23 16:49:56 I got a sort of answer last night, but can someone tell me why I cannot "repartition" my flash? Something a little deeper than "because it is mtd flash" and more useful than "because it is not called repartitioning if you do it to flash" Nov 23 16:51:30 argh.. Nov 23 16:51:50 task-openmoko is c7x0 non-compatible (also other machines) Nov 23 16:52:04 it rdepends on xserver fbdev.... Nov 23 16:56:13 koen: now push Nov 23 16:56:16 koen: now pull Nov 23 16:56:17 bye! Nov 23 17:00:34 hrw: what do you think about making updater deploy a nostamp? Nov 23 17:00:56 03hrw 07org.oe.dev * r42e96a2a... 10/ (3 files in 3 dirs): zaurus-updater: remove logs - added by mistake Nov 23 17:01:00 03hrw 07org.oe.dev * r0b693535... 10/ (3 files in 3 dirs): zaurus-updater: use value from /proc/mtd to get rootfs size Nov 23 17:01:23 hrw: does that last change make the one I am building irrelavant? I'm guessing it does. Nov 23 17:01:24 koen: what for? Nov 23 17:01:29 Zero_Chaos: yes Nov 23 17:01:55 hrw: :-) You know how long it takes this slow things to build? I have not even tested it yet :-) Nov 23 17:01:57 hrw: so it will get into deploy for each machine Nov 23 17:01:58 heh Nov 23 17:02:15 if it isn't machine specific anymore, you will only get one copy in deploy Nov 23 17:04:41 Zero_Chaos: you only need to give clean updater to encoder Nov 23 17:06:13 hrw: I was rebuilding my big image because I had been striping it to fit in 1900000h (which I was failing at) Nov 23 17:11:26 hrw: task-openmoko would also break on gtao2 Nov 23 17:13:16 koen: thats why I know Nov 23 17:28:03 hrw: your new zaurus-updater, can't flash my 50mb image... Nov 23 17:28:44 and it prints hdtop to the screen which doesn't seem very useful (to me) Nov 23 17:33:31 hdtop? Nov 23 17:33:56 yeah, hdtop=125 and a few more numbers that look like the total flash size of my device. Nov 23 17:34:22 but the fact that I still can't flash a 50mb image onto a 60mb partition is more my issue at present than an extra line being shown to me... Nov 23 17:38:06 Zero_Chaos: tried with old updater.sh? Nov 23 17:38:52 I deleted the updater.sh from deploy and rebuilt it. Nov 23 17:39:22 my question is, am I getting the seperate akita updater.sh or "the one updater" Nov 23 17:39:46 that's the only reason I can think it would fail Nov 23 17:42:04 * * OE Bug 3360 has been created by thebohemian(AT)gmx.net Nov 23 17:42:06 * * bbclass to create maemo scratchboc compatible binaries Nov 23 17:42:08 * * http://bugs.openembedded.org/show_bug.cgi?id=3360 Nov 23 17:47:32 hrw: any ideas, or am I not going to flash my Zaurus today unless the image is below 1900000h? Nov 23 17:51:45 03koen 07org.oe.dev * r20cd55d4... 10/ (1 conf/machine/fic-gta01.conf conf/machine/fic-gta02.conf): fic-gta0*: add XSERVER Nov 23 17:51:50 03koen 07org.oe.dev * r576963d8... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko: use xserver specified by machine instead of hardcoding it Nov 23 17:52:14 hrw: there you go Nov 23 17:53:15 who was the maintainer of the opie stuff again? Nov 23 17:53:28 opie stuff in angstrom that is Nov 23 17:59:05 CoreDump: I think it is Paul Eggleton Nov 23 17:59:47 bernard_: thanks, does he hang out on IRC? Do you know his nick? Nov 23 18:00:50 bluelighting Nov 23 18:00:58 +n somewhere Nov 23 18:02:01 I've pointed him to the opie/oe bugs I've opened in OE's bugzilla Nov 23 18:02:23 thnks Nov 23 18:03:02 he doesn't set OPIE_CVS_PV properly in at least one package Nov 23 18:04:55 and some patches are now obsolete... Nov 23 18:06:34 !oebug 1789 Nov 23 18:06:35 * * Bug 1789, Status: RESOLVED (INVALID), Created: 2007-01-14 17:50 Nov 23 18:06:36 * * : libxml2-native fails do_compile Nov 23 18:06:37 * * http://bugs.openembedded.org/show_bug.cgi?id=1789 Nov 23 18:06:45 hrw: something is wrong, I added a few echo's to see why I can't flash, but it has the right sizes being auto-detected but it still says my 50mb image won't fit on my 0x03a00000 partition. Nov 23 18:06:59 !oebug 2721 Nov 23 18:07:00 * * Bug 2721, Status: REOPENED, Created: 2007-08-08 00:09 Nov 23 18:07:01 * * : opie-taskbar-images update for recent cvs Nov 23 18:07:02 * * http://bugs.openembedded.org/show_bug.cgi?id=2721 Nov 23 18:07:26 2721 has a patch against multiple opie bbs Nov 23 18:09:07 Zero_Chaos: can you pastebin the decoded updater.sh? Nov 23 18:09:26 likely Nov 23 18:09:28 one sec Nov 23 18:10:55 and I decode it how exactly? Nov 23 18:11:28 you added echos, you should know that already =D Nov 23 18:12:29 CoreDump: I only added echos to check the auto-detected size. Nov 23 18:12:51 which means you already have updater.sh in plain-text aka decoded Nov 23 18:12:57 usually it is "encrypted" Nov 23 18:15:46 CoreDump: n/m, I figured it all out, and i added a crap load more echos, let me see what happens.... then I'll pastebin my shame Nov 23 18:17:03 bbl Nov 23 18:18:56 ah-ha! Nov 23 18:19:13 it thinks my image is 52297744 Nov 23 18:19:24 which is obviously larger than 03a00000 Nov 23 18:19:47 but in fact, 49.9M is less than 03a00000 if I am not mistaken Nov 23 18:20:00 there is a bug in getting the file size or initrd.bin and comparing it Nov 23 18:20:08 * Zero_Chaos pokes hrw Nov 23 18:21:16 hrw: before updater.sh trys to flash rootfs, it makes a comparasin of the initrd.bin file size in demimal against the available flash partition size in hex. If I am not mistaken. Nov 23 18:21:32 * Zero_Chaos wishes he knew how to fix this... Nov 23 18:26:05 if [ $DATASIZE -gt `printf "%d" $MTD_PART_SIZE` ] Nov 23 18:26:18 DATASIZE is decimal size of file to flash Nov 23 18:26:32 right Nov 23 18:26:34 MTD_PART_SIZE is hex size of flash partition Nov 23 18:26:37 right Nov 23 18:26:47 and printf "%d" do hex -> dec conversion Nov 23 18:27:33 okay, well in that case, I have no fscking idea why it doesn't work, unless 52297744d > 03a00000h Nov 23 18:27:48 Zero_Chaos: insert an echo and dump both values Nov 23 18:27:55 CoreDump: I did Nov 23 18:28:06 /bin/sh: prinf: command not found Nov 23 18:28:10 /bin/sh: line 0: printf: 03a00000: invalid number Nov 23 18:28:11 52297744 0 Nov 23 18:28:13 argh Nov 23 18:28:17 52297744 60817408 Nov 23 18:28:21 hrw: =) I was about to say Nov 23 18:30:12 does this mean someone smarter than me noticed the issue now? Nov 23 18:30:50 CoreDump: has any idea? Nov 23 18:30:55 /bin/sh: prinf: command not found Nov 23 18:31:03 wasn't that it?? Nov 23 18:31:12 I don't get that when flashing Nov 23 18:31:17 printf not being in the shitty rescuefs? Nov 23 18:31:29 at least I don't see that. Nov 23 18:31:58 Zero_Chaos: do an echo " if [ $DATASIZE -gt `printf "%d" $MTD_PART_SIZE` ]" Nov 23 18:32:43 CoreDump: you mean put an echo for that whole line? I already echoed the $DATASIZE and $MTD_PART_SIZE Nov 23 18:33:07 we do not care for $MTD_PART_SIZE, only for `printf "%d" $MTD_PART_SIZE` Nov 23 18:33:30 if something goes wrong, it will show with the above echo Nov 23 18:33:38 so I echo `printf "%d" $MTD_PART_SIZE` or the whole thing? Nov 23 18:34:02 echo " if [ $DATASIZE -gt `printf "%d" $MTD_PART_SIZE` ]" Nov 23 18:34:10 k Nov 23 18:35:04 FWIW printf %d 03a00000 doesn't even work on my desktop... Nov 23 18:35:59 CoreDump: 0x03a00000 Nov 23 18:36:07 printf "%d %d" 52297744 0x03a00000 Nov 23 18:36:23 Works on SlugOS w/busybox 1.2.1 Nov 23 18:36:46 works on sharprom busybox 0.60, debian sarge bash, debian sid bash Nov 23 18:36:47 but there is no 0x in $MTD_PART_SIZE Nov 23 18:37:00 exactly Nov 23 18:37:02 argh then Nov 23 18:37:06 Ah Nov 23 18:37:09 ;) Nov 23 18:38:03 and my c760 is dead as usual Nov 23 18:38:25 if [ $DATASIZE -gt `printf "%d" 0x${MTD_PART_SIZE}` ] Nov 23 18:38:32 Zero_Chaos: try the above Nov 23 18:38:37 hrw: I stayed up till 5 am then woke up at 10 because I wanted to work on this, I'll test ;-) Nov 23 18:40:59 CoreDump: can you pus fix when you both will test it? Nov 23 18:41:09 need to do some non-OE stuff today Nov 23 18:41:09 sure Nov 23 18:41:43 hrw: thanks for the help, have fun Nov 23 18:42:03 Zero_Chaos: I have pile of dishes to wash Nov 23 18:42:06 its not fun Nov 23 18:42:14 hrw: I feel your pain Nov 23 18:42:34 Zero_Chaos: ;D Nov 23 18:47:01 CoreDump: I changed that line as you said and before it even flashes the kernel now it says "Error: File is too big to flash!" then it moves past the kernel and flashes the rootfs Nov 23 18:47:04 hehe Nov 23 18:47:19 so I can revert and flash kernel, then make that change and flash rootfs... Nov 23 18:47:35 seems a bit unusual but it works I guess :-) Nov 23 18:47:45 of course, this has to be fixed properly Nov 23 18:47:56 I think I know how.... Nov 23 18:48:01 I'll test Nov 23 18:56:05 testing now... Nov 23 18:57:01 hmm, something happened, zimage.bin : can't open file Nov 23 18:57:08 Zero_Chaos: http://hentges.net/tmp/updater.sh.gz Nov 23 18:57:10 it is called zImage.bin... Nov 23 18:57:20 CoreDump: what did you change? Nov 23 18:57:41 the above change, also it dumps the sizes on error Nov 23 18:58:05 CoreDump: you had to send the encoded version... doh Nov 23 18:58:39 it should work OOTB Nov 23 18:58:56 CoreDump: yeah, but I like to see what is happening ;-) Nov 23 18:59:13 http://hentges.net/tmp/updater.sh Nov 23 19:00:43 03koen 07org.oe.dev * r5e44ca0f... 10/ (3 files in 3 dirs): Nov 23 19:00:43 xserver-kdrive-common: use Xglamo for gta02, remove some of the bogus Xserver checks Nov 23 19:00:43 * if a Xserver is in /usr/bin doesn't mean the it's the right server for the job Nov 23 19:01:33 CoreDump: out of curiousity, did you fix the bug as well, or just have it dump sizes on error. I only ask because it is obvious that you didn't include the fix that I thought of. (which is still untested due to a different mess up that is currently being fixed) Nov 23 19:02:00 the size check should work now Nov 23 19:02:12 and if it doesn't we get to see why not Nov 23 19:04:41 can you point me to the line that fixes the issue, I don't see how you did it Nov 23 19:05:04 Zero_Chaos: diff the 2 scripts Nov 23 19:05:48 if [ $DATASIZE -gt `printf "%d" 0x${MTD_PART_SIZE}` ] Nov 23 19:05:58 03koen 07org.oe.dev * r3afb6317... 10/ (3 files in 3 dirs): zaurus-updater: have consistent error messages Nov 23 19:06:00 koen: sorry, I didn't have the original at the moment. I'll do that. I've kinda been working on this for 11 hours so I am a little... well... you can guess Nov 23 19:06:13 Zero_Chaos: the original is in OE Nov 23 19:06:15 CoreDump: that doesn't work, if you do that kernel dies Nov 23 19:06:21 koen: I MODIFIED IT Nov 23 19:06:43 CoreDump: that causes the kernel flash to fail and the rootfs flash to work, which is just keen. Nov 23 19:06:52 which doesn't matter as the echo will tell _why_ the kernel fails Nov 23 19:07:12 by looking at it I do not see why it would fail at all Nov 23 19:07:15 CoreDump: I would guess it is because it is 0x0xnumber instead of 0xnumber Nov 23 19:07:53 I've got a hack fix that works (2 bytes and everything flashes fine). I'll test your in a minute and give you the errors and my fix. Nov 23 19:08:23 one bit of odd, why does updater.sh dump me back to a prompt and not reboot anymore? Nov 23 19:09:19 Zero_Chaos: the 0x0x thing was what I didn't see......which is why I entered echos which would have pointed out the obvious... Nov 23 19:09:49 give me a minute, I'll get there. Nov 23 19:10:16 Zero_Chaos: if you look at the script you'll see it execs '/bin/sh' instead of 'reboot' Nov 23 19:10:19 hi ph5 Nov 23 19:10:43 hey woglinde Nov 23 19:10:47 (hey everybody) Nov 23 19:11:07 koen: I appreciate you decoding that for me, but I didn't mean "I can't find that in the code" I meant "Why does it not behave as it used to, as I prefered the previous way" Nov 23 19:11:32 debugging Nov 23 19:12:31 CoreDump: so then I presume that will be reverted to reboot before the proper release? that seems acceptable Nov 23 19:12:55 indeed Nov 23 19:13:07 firing now Nov 23 19:14:07 kernel: [1256936] > [0] Nov 23 19:14:23 kernel fails, rootfs flashes Nov 23 19:14:44 here is my thought, let's keep your nice debugs and my fix, lemme show you Nov 23 19:15:36 Zero_Chaos: any success repartitioning akita flash? I read earlier about your attempts Nov 23 19:15:54 when setting the MTD_PART_SIZE to the value read from MTD, you do this "MTD_PART_SIZE=0x$ROOTFS_SIZE" Nov 23 19:15:57 I added the 0x Nov 23 19:16:17 dcordes: a bit of debugging added, and my fix works if approved. Nov 23 19:16:34 Zero_Chaos: correct Nov 23 19:16:35 dcordes: of course, once it flashes... it fails to turn on so I'm not sure about WTF Nov 23 19:16:53 lol Nov 23 19:17:00 seen you on tv ^^ Nov 23 19:17:03 CoreDump: so remove the one that breaks the kernel, add in the one that only fixes rootfs and keep the pretty debug :-) Nov 23 19:17:10 dcordes: ? Nov 23 19:17:16 dcordes: how you get that? Nov 23 19:17:24 pedro gave me link Nov 23 19:17:31 dcordes: heh, nice Nov 23 19:17:48 more meta seen on tv Nov 23 19:18:03 dcordes: "more meta"? Nov 23 19:18:06 I hope you don't sit in some coffeeshop right now lol Nov 23 19:18:20 I've seen a caputre on some flash video website Nov 23 19:18:22 dcordes: nope, I'm safe here on my WEP encrypted link. Nov 23 19:18:23 heh Nov 23 19:19:35 http://hentges.net/tmp/updater.sh Nov 23 19:20:31 echo "$FLASH_TYPE: [$DATASIZE] > [`printf "%d" 0x${MTD_PART_SIZE}`]" Nov 23 19:20:42 you must remove the 0x from this line, it breaks flashing of the kernel Nov 23 19:20:55 well, technically not I guess Nov 23 19:20:58 but it is just wrong Nov 23 19:21:16 it is no longer there Nov 23 19:21:19 the error will not read if the 0x is there Nov 23 19:21:34 that is the error checking code from the link you just pasted Nov 23 19:21:44 nope Nov 23 19:22:37 * CoreDump believes someone needs to refresh his cache Nov 23 19:23:10 I didn't realize that lynx kept a cache Nov 23 19:23:35 wget too Nov 23 19:23:37 just wget the blasted thin Nov 23 19:23:51 I did, and it still has the 0x in your error check Nov 23 19:24:46 if [ $DATASIZE -gt `printf "%d" $MTD_PART_SIZE` ] Nov 23 19:25:30 CoreDump: hey man, if there is a cache between you and I then so be it, but I see what I see, links lynx and wget Nov 23 19:25:59 CoreDump: but if you did as we discussed then it would be great to commit, because I simply cannot be the only one with the issue Nov 23 19:26:01 links doesn't install on akita for me. lacks libjpeg or so Nov 23 19:26:28 dcordes: I use it on my laptop Nov 23 19:26:33 * Zero_Chaos <- console jockey Nov 23 19:27:29 http://hentges.net/tmp/updater.sh-new renaming should help Nov 23 19:28:49 CoreDump: now I see your debug code and my lame fix. all seems good to me. Nov 23 19:29:20 CoreDump: I must wonder where the caching is done... because it is not on my network.... Nov 23 19:29:35 maybe apache did it? Nov 23 19:30:09 or an isp in between Nov 23 19:30:11 CoreDump: dunno, somewhere between your webserver and my laptop. No matter, solved now. Nov 23 19:30:43 CoreDump: please forgive me for being a bit high strung, I've been looking at this too long. Nov 23 19:31:04 no worries Nov 23 19:31:09 CoreDump: but now it all looks good so I give green light to push, it works for me and shouldn't break anyone else from what I can tell. Nov 23 19:33:01 also another bug, the kernel is supposed to be called "zImage.bin" from what I recall, but if you use a filesystem that is actually case sensative when flashing, it looks for zimage.bin then fails. Nov 23 19:33:27 check the script Nov 23 19:33:31 it catches that Nov 23 19:34:01 # make TARGETFILE lowercase Nov 23 19:34:01 TARGETFILE=`echo $TARGETFILE|tr A-Z a-z` Nov 23 19:34:13 koen: I just said it barfed with an error when I tested. so it must be catching something else, or just fixed in your last push Nov 23 19:35:22 ah, I see the problem Nov 23 19:35:25 also, can we move the size checks up a little bit so we can make sure both parts of the flashing will work before flashing anything? it would seem to make sense to not flash the kernel without rootfs and the other way Nov 23 19:37:05 Zero_Chaos: http://rafb.net/p/5pLV9P38.html ? Nov 23 19:37:49 the switch statement will use the lowercase and the flash statement the non-lowercase Nov 23 19:37:52 koen: to be honest, I don't think I would know the fix if I just saw it :-) Nov 23 19:37:52 hmmm Nov 23 19:38:09 koen: I'm happy to test it though. Nov 23 19:38:20 if that is ready for test Nov 23 19:40:02 Zero_Chaos: mtn pull Nov 23 19:40:28 there's always mtn disapprove if it doesn;t work ;) Nov 23 19:42:03 03koen 07org.oe.dev * ra4c0d8d2... 10/ (1 packages/zaurus-updater/zaurus-updater/updater.sh): zaurus-updater: fix a typo from the last commit Nov 23 19:42:12 03koen 07org.oe.dev * r6ac18f3d... 10/ (3 files in 3 dirs): zaurus-updater: fix flashing from case sensitive filesystems Nov 23 19:43:25 03coredump2 07org.oe.dev * rc1726a91... 10/ (1 packages/zaurus-updater/zaurus-updater/updater.sh): zaurus-updater: Always treat MTD_PART_SIZE as HEX when comparing sizes, thanks to ZeroChaos for debugging Nov 23 19:44:32 okay, everyone done fixing updater.sh now? can I test it? Nov 23 19:44:38 * Zero_Chaos glares at CoreDump and koen Nov 23 19:45:54 well, first to merge the heads I suppose Nov 23 19:49:09 anyone, the two headed beast? Nov 23 19:49:18 * Zero_Chaos pokes CoreDump Nov 23 19:52:46 * CoreDump is too busy for a manual merge ATM Nov 23 19:53:05 * Zero_Chaos glares at koen Nov 23 19:53:15 koen: can you be a pal and fix the two headed monster please Nov 23 19:53:23 koen: should be easy, it is just the updater.sh Nov 23 21:05:36 Has someone compiled firefox 2.0.0.3 lately? Nov 23 21:05:44 It fails to link due X11 lacking Nov 23 21:05:48 re Nov 23 21:05:56 but I have the lib on staging Nov 23 21:55:01 Crofton: did the glibc image for gumstix work? Nov 23 22:27:29 anyone do a pull in the last hour or so? are the heads merged? Nov 23 22:50:47 Zero_Chaos: nope, the two-headed beast is still out there Nov 23 22:51:14 scary monster. Nov 23 22:51:20 Someone should slay the beast **** ENDING LOGGING AT Sat Nov 24 02:59:57 2007