**** BEGIN LOGGING AT Fri Feb 26 02:59:57 2010 Feb 26 06:32:14 TAsn: seems like newer efl doesn't show keyboard even on terminal window focus :/ Feb 26 06:32:21 TAsn: but building it for you atm.. Feb 26 07:39:26 moin Feb 26 08:13:35 JaMa: moin Feb 26 08:13:53 JaMa: I would like to bump FSO2 stuff to current HEAD... what do you think? Feb 26 08:14:39 mrmoku: be carefull with that libfsotransport thing.. but I've already built fso-autorev locally so I'll be glad to see it in sane-srcrevs-fso :) Feb 26 08:15:25 JaMa: what's that libfsotransport thing? Feb 26 08:15:33 mrmoku: but with mickey in gta timeslot, there is a chance to resolve libfsotransport better Feb 26 08:16:36 mrmoku: http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=49742ce6ddca78ad8bc05dfd722c4ba2e017fadb Feb 26 08:17:00 mrmoku: before this I had 100% reproducible no-registration Feb 26 08:17:36 mrmoku: after this downgrade I got registration afaik always, but users are still complaining it's not registering for them Feb 26 08:18:13 mrmoku: so I guess it's that timing issue somewhere and this downgrade changes it only partially Feb 26 08:18:44 JaMa: I tried autorev yesterday... and it still has that registration issue Feb 26 08:18:52 but it registers allways with DEBUG for frameworkd Feb 26 08:19:51 ah so maybe it's different again.. because without this patch I never got registration even with all fso stuff on DEBUG (with that screenrc thingie I use) Feb 26 08:20:26 I just turn on DEBUG in /etc/frameworkd.conf Feb 26 08:33:43 JaMa, testing efl Feb 26 08:36:39 JaMa, no efl in feeds, just phoneuid and libpixman Feb 26 08:40:32 TAsn: NOTE: Running task 7482 of 13430 Feb 26 08:41:05 TAsn: that's why I said in MY feeds, and then building atm (and still building now) Feb 26 08:42:31 and I didn't push it yet.. (its only in checkout in shr buildhost and here locally), so mrmoku, please if you're building on buildhost ping me before and I'll push it after tasn's test Feb 26 08:43:15 oops, just noticed the messages was from two hours ago Feb 26 08:43:25 I thought it was from last night ;P Feb 26 08:44:26 sigh next shr-t snapshot fails to compile in yet another package. Feb 26 08:44:53 will provide compile log today and try to fix it. Feb 26 08:46:16 spaetz: ie webkit-efl will fail there because of incompatible efl :/ Feb 26 08:46:57 nahh, it was a different pkg, and it was part of shr-lite-image :-( Feb 26 08:47:13 something x related, i think. Feb 26 08:52:02 hmm that worked in my rebuild from scratch 2 days ago in shr-u Feb 26 08:52:33 ah but I'm using newer xorg-xserver here.. Feb 26 08:56:48 JaMa: I pushed the fso bump and will wait with building Feb 26 08:57:34 ok I'll run build after I push my :) Feb 26 08:58:56 I will have a look at webkit source, if i can patch it because upstream doesn't react Feb 26 08:59:45 mrmoku: I don't see FSO_CORNUCOPIA_SRCREV change in that commit Feb 26 08:59:53 mrmoku: aren't you going backwards? Feb 26 09:00:20 question: I am using latest shr testing but everytime I set my clock, when I reboot it displays the previous hour (correct hour: 10:00am, after reboot it is 9:00am, always one hour back), any ideas? Feb 26 09:00:41 mrmoku: also libfso-glib rev seems shorter than expected Feb 26 09:04:41 JaMa: he :( Feb 26 09:06:57 JaMa: what would I do without you :) Feb 26 09:07:19 :) Feb 26 09:07:54 you would build it backwards, happily upgrade to new older versions and then be confused for few secs :) Feb 26 09:08:29 of some days :P Feb 26 09:08:33 s/of/or Feb 26 09:09:26 TAsn: rsync is running you can start "opkg update" typing :) Feb 26 09:10:04 JaMa: this should be enough for webkit: http://shr.pastebin.com/UXfppmmG Feb 26 09:12:21 Heinervdm: ah, it was the same struct as evas is defining :) Feb 26 09:12:35 s/ :)/? :)/ Feb 26 09:12:36 JaMa meant: Heinervdm: ah, it was the same struct as evas is defining? :) Feb 26 09:12:42 JaMa: evas is defining the same strct? Feb 26 09:12:49 then we can just remove it from the code Feb 26 09:12:58 i will try to build it now Feb 26 09:13:23 the build error was about first definition of that name in evas.h, wasn't it? Feb 26 09:14:06 JaMa: it said that it was defined before when parsing evas.h Feb 26 09:15:01 JaMa: it's exactly the same definition Feb 26 09:17:53 JaMa: i will now build with that http://shr.pastebin.com/fXG1vnQw Feb 26 09:19:06 Heinervdm: yes this one looks better to me :) Feb 26 09:20:44 JaMa: else we would redefine Evas_Point and we would get a similar error... Feb 26 10:05:19 larsc: hi. Are you going to push my ar6000 patch to your topic branch? Feb 26 10:05:36 PaulFertser: feel free to do it yourself Feb 26 10:06:33 larsc: ok, thanks, will do it later today/tomorrow. Feb 26 10:18:54 JaMa: hmm, i can't install my webkit-efl because of smaller gitr Feb 26 10:19:23 Heinervdm: you have image from shr buildhost right? Feb 26 10:19:29 yes Feb 26 10:19:51 it compiles now, should i just commit the patch? Feb 26 10:20:24 than it's normal behavior.. if you want to use feeds/image from shr and your buildhost then you have to sync your persist with http://build.shr-project.org/shr-unstable/cache/ Feb 26 10:20:35 Heinervdm: yes, please Feb 26 10:21:07 will just check the E rev for the commit message Feb 26 10:24:11 http://trac.enlightenment.org/e/changeset/46211 Feb 26 10:24:22 yes found it too Feb 26 10:24:28 :) Feb 26 10:24:59 Can i make it conditionally depending on EFL_SRCREV ? Feb 26 10:27:15 imho no.. but i think that whoever is building webkit-efl is also using latest EFL.. Feb 26 10:40:01 JaMa: ok, i managed to commit it :) Feb 26 10:43:39 Heinervdm: congratz :) Feb 26 10:44:03 Heinervdm: I'll push mine as soon as tasn report efl testing Feb 26 10:44:25 JaMa: ok Feb 26 10:48:35 Heinervdm: or you can upgrade from shr feeds and report :) Feb 26 10:49:14 JaMa: normal feeds? Feb 26 10:49:33 Heinervdm: yep Feb 26 10:49:39 46504 rev Feb 26 10:50:32 ok is running Feb 26 10:53:21 will reboot now, and then i will report Feb 26 10:56:56 JaMa: should i try sth special? Feb 26 11:01:59 JaMa: found 1 thing till now: Keyboard doesn't popup in gtk apps Feb 26 11:02:13 everything else seems to work Feb 26 11:23:01 Heinervdm: so quite the same as I noticed in the morning.. Feb 26 11:23:40 Heinervdm: but I had a bit older rev.. so I'll push it Feb 26 11:24:24 JaMa: but i don't understand why the keyboard doesn't popup Feb 26 11:24:35 matchbox-keyboard-im wasn't updated... Feb 26 11:26:41 just FYI, I installed omnewrotate and I found out shr testing fails to show the illume keyboard when in landscape mode (instead it displays that part of the home screen with the icons) Feb 26 11:26:53 Heinervdm: I've seen efl commit about that, mmt Feb 26 11:27:03 I don't know if this can be of some help Feb 26 11:27:16 http://trac.enlightenment.org/e/changeset/46446 Feb 26 11:27:27 Heinervdm: ^ that's the one tasn reported Feb 26 11:28:17 maybe it fixed something tasn needed and broken focus from gtk apps Feb 26 11:35:19 JaMa, ok, sec upgrading Feb 26 11:35:23 is there anything I need to know? Feb 26 11:36:05 and what bug are you talking about? Feb 26 11:37:38 keyboard is not shown on focus in same apps (i noticed in terminal, Heinervdm said in gtk apps) Feb 26 11:38:12 now there are 2 more commits from devilhorns about keyb Feb 26 11:38:27 lol :P Feb 26 11:38:31 but imho not changing this (on quick glance) Feb 26 11:39:18 and another one! :) Feb 26 11:42:22 wait before you upgrade efl Feb 26 11:42:26 there's a patch I need to send first Feb 26 11:42:27 :P Feb 26 11:42:36 ok Feb 26 11:42:49 and I will only be able to send it in the evening Feb 26 11:43:43 building mrmoku's and Heinervdm's upgrades.. and ping me when you have some nice efl srcrev :) Feb 26 11:43:54 :P Feb 26 11:47:39 mrmoku|away, remidnd me, I'll hopefully fix dialer to be resize friendly today Feb 26 11:53:07 TAsn: if you have a moment of time... please make the dialer resizable ;) Feb 26 11:53:51 :P not now Feb 26 11:53:56 now I'm working on an e patch Feb 26 11:54:00 :P Feb 26 12:01:03 JaMa, ok, testing my patch works Feb 26 12:01:17 (will take hours, rebuilding all of e) Feb 26 12:03:45 TAsn: it does change whole e? :) Feb 26 12:04:02 no Feb 26 12:04:07 I just didn't have Feb 26 12:04:10 new e compiled Feb 26 12:04:14 and they are deps Feb 26 12:04:22 I could probably just not compile them Feb 26 12:04:29 as they are binary compatible Feb 26 12:04:36 and probably nothing really big changed Feb 26 12:04:41 but wth :P Feb 26 12:04:49 :) Feb 26 12:07:48 bah it's poorly written :( Feb 26 12:07:54 (Keypad) Feb 26 12:26:59 hehe interesting Removing package udev from root... Feb 26 12:26:59 Starting udev Feb 26 12:41:48 JaMa, http://scap.linuxtogo.org/files/8d409e44de5ffd57771d1d6ded61cc8b.png Feb 26 12:41:54 a little more work is needed Feb 26 12:42:01 though it's fully resizable Feb 26 12:42:19 ciao for the meanwhile Feb 26 13:05:47 hi all Feb 26 13:16:33 moin Feb 26 13:19:57 hi Feb 26 13:33:38 I have an old gta01 device borrowed from friend. Was try to install roofs image for shr on it. But every time I do I get Starting download: [###############################dfu_download error -84 Feb 26 13:33:39 Error during download Feb 26 13:33:43 Any pointers ? Feb 26 13:34:11 Command I am using is 'dfu-util -d 0x1457:0x5119 -a rootfs -R -D shr-full-eglibc-ipk--20100209-om-gta01.rootfs.jffs2' Feb 26 13:35:53 rakesh: installing SHR to flash on gta01 is a pain :/ Feb 26 13:37:05 mrmoku: what works best for gta01? Feb 26 13:37:18 rakesh: install it to SD Feb 26 13:37:18 wasnt -84 'too big to fit into mtd' or so? Feb 26 13:37:25 rakesh: it's not a pain, it's mere impossible Feb 26 13:37:36 image doesn't fit to gta01 NAND Feb 26 13:37:48 okz Feb 26 13:38:17 DocScrutinizer51: hey.. another documentation bug found! ;) Feb 26 13:38:17 rakesh: ahh... the full one is no go anyway :P Feb 26 13:38:33 roh: eh? Feb 26 13:38:37 What would work best for gta01 .. I just want to make calls with device ? :) Feb 26 13:38:42 using GSM Feb 26 13:38:47 DocScrutinizer51: well.. -84 isnt much explaining ;) Feb 26 13:38:53 yep Feb 26 13:39:01 rakesh: just install it to SD Feb 26 13:39:13 dfu-util acually *is* a PITA in itself Feb 26 13:39:26 DocScrutinizer51: well.. you know the story? Feb 26 13:39:37 mrmoku: ok thanks .. do you have some pointer to SD installation ? Feb 26 13:39:44 of dfu-util? no I don't Feb 26 13:39:47 rakesh: do you have a card reader? Feb 26 13:39:54 mrmoku: yep Feb 26 13:40:08 just extract the tar.gz one there then Feb 26 13:40:23 DocScrutinizer51: harald hacked it up since we wanted speak real dfu and all other implementations spoke some weird dialect depending on which hw used with and which tool. there was no tool which adhered to the usb if spec Feb 26 13:40:34 * JaMa removing all shr .jffs2 .ubi for om-gta01 now.. Feb 26 13:40:34 mrmoku: rakesh: you'll need FAT for kernel!! Feb 26 13:40:46 rakesh: http://wiki.openmoko.org/wiki/Booting_from_SD#Prepare_the_SD_card Feb 26 13:40:47 but since the moko uboot adheres dfu spec afaik... we needed a tool. Feb 26 13:41:07 DocScrutinizer: really? Feb 26 13:41:37 mrmoku: how would you boot otherwise? Feb 26 13:41:53 dfu is also used for example in csr bluetooth thingies (different tool used by bluez afaik) and atmel (diverse stuff, e.g. the at90usb stuff does dfu like stuff) Feb 26 13:41:59 atmel also has its own tool Feb 26 13:42:01 DocScrutinizer: for uboot then? Feb 26 13:42:18 is it self-explanatory? :) http://build.shr-project.org/shr-unstable/images/om-gta01/bigger-than-nand/ Feb 26 13:42:20 mrmoku: you can only use uboot on gta01 Feb 26 13:42:29 mrmoku: I'd guess gta01 *has* uBoot -except for most daring individuals Feb 26 13:42:44 JaMa: then remove Qi from there too ;) Feb 26 13:42:52 LOL Feb 26 13:43:07 mrmoku: already moved Feb 26 13:43:11 :) Feb 26 13:43:28 rakesh: so format your SD as fat and just extract the tarball there Feb 26 13:43:36 mrmoku: you mean from bigger, right? or is there any problem with qi on gta01 in general? Feb 26 13:44:01 mrmoku: rakesh no, make 2 partions as discribed in om wiki Feb 26 13:44:11 mrmoku: nah :-/// Feb 26 13:44:30 JaMa: qi has no dfu-util support i think Feb 26 13:44:32 * mrmoku stops talking about things he does not know :P Feb 26 13:44:40 JaMa: and gta01 has only 1 boot loader Feb 26 13:44:56 rakesh: you need a first partition fat16, 16MB. A secont large üpartition ext2/3. maybe a 3rd partitioon swap Feb 26 13:45:20 DocScrutinizer: ok Feb 26 13:46:00 then extract the tarball to 2. partition, and copy the uImage in /boot to first FAT partition Feb 26 13:47:13 rakesh: OR you are venturous and try to format whole uSD with ext2-inode-size:128 Feb 26 13:47:16 Heinervdm: but qi-s3c2410-1.0.2-r0+gitr0+c38b062a609f1442e6a9e13005cfbdfd59a5ac0d.udfu should be still the right one for gta01 if someone expirienced enough to know about missing dfu-util support and no fail-safe u-boot in NOR Feb 26 13:47:29 so should I remove it or no? Feb 26 13:47:37 possibly the old uBoot can boot from that small inode ext2 as well Feb 26 13:48:06 DocScrutinizer: will go with former Feb 26 13:48:16 the proven way Feb 26 13:48:28 JaMa: i think qi is dangorus for gta01, no idea if it is possible to remove it Feb 26 13:48:32 (no for gta01 by me though) Feb 26 13:48:35 and our -lite*jffs2 image will be small enough if someone find way to not-generate /boot in jffs2 images :) Feb 26 13:48:58 rakesh: still I guess it should work for gta01 same way as for 02 Feb 26 13:49:24 Heinervdm: imho you can always replace it if you have running system on it with nandwrite or with debug board, DocScrutinizer is it right? Feb 26 13:49:31 JaMa: we can add a prepend to image creation, that just deletes it :) Feb 26 13:50:16 Heinervdm: but imho rootfs is created just once and than all FS_TYPES are created from the same "source", but I haven't checked it properly Feb 26 13:50:23 JaMa: that's right, but extremely dangerous (except with debubo) Feb 26 13:51:51 consider gta01 without debug board as a latently bricked device Feb 26 13:51:56 any time Feb 26 13:53:29 and honestly, there is *NO* reason to go for Qi. Neither gta01 nor gta02 Feb 26 13:54:20 I seriously dislike this qi hype more and more each week Feb 26 13:55:37 friggin shit, it's almost as bad as KDE4 Feb 26 13:56:06 Heinervdm: maybe we can add it to EXTRA_IMAGECMD_jffs2, but we should copy whole rootfs to another location, then remove boot and make image from it, instead of removing boot in "shared" rootfs dir Feb 26 13:56:16 imature buggy crap full of regressions, but hey IT'S NEW Feb 26 13:56:46 (that's for KDE4 :-P ) Feb 26 13:57:12 Heinervdm: or better replace IMAGE_CMD_jffs2 with our version Feb 26 13:57:13 JaMa: i just had a look at it, there is no chance to add sth before the image creation. only afterwards Feb 26 13:57:28 DocScrutinizer, thanks cya .. need to catch a bus and will be back :) Feb 26 13:57:29 JaMa: yes that can be possible Feb 26 13:57:38 mmt testing it now ;) Feb 26 14:00:28 DocScrutinizer: you don't agree with the principle of the bootloader doing the minimum of screwing with the hardware? (and the consequent resume speed improvement) Feb 26 14:00:59 Weiss: I do. But life always is a tradeoff Feb 26 14:01:30 Weiss i think we all do, but sometimes there is a tradeoff between practical and idealism Feb 26 14:01:42 and the increase in resume speed is really minor Feb 26 14:02:08 for example: i agree that it needs to be simple and basically need only minimal shared code (same goes for duplicated code) Feb 26 14:02:30 otoh all noobs tend to *start* with flashing Qi now, even before they learn how to create a bootable uSD Feb 26 14:02:31 but it needs to be able to read and boot mtd aswell as some other medium like sdcards. Feb 26 14:02:33 :-S Feb 26 14:03:02 i agree that it doesnt need a (real?) display driver Feb 26 14:04:12 a "doesn't need" *never* was a good point to discard a proven-to-work sw and go for a new different one Feb 26 14:04:15 imho it shouldnt even touch registers of stuff it doesnt absolutely need to to reach the goal of (multi) booting Feb 26 14:05:03 the kernel itself should be able to do full hardware bringup from the first execution it can do. means it needs to know how to initialize cold hw Feb 26 14:05:25 which is making suspend easier btw Feb 26 14:05:58 roh: we all agree upon that Feb 26 14:06:20 DocScrutinizer51: the bootloader needs 'some ui' to signal states/ which kernel is booted, but thats archievable with a led for example Feb 26 14:07:01 or if it needs to, enable the lcm, program some static timings and fill some memory with one value pattern... green is kernel on mtd1, red is sdcard or so Feb 26 14:07:10 roh: yep. And we planned to go exactly this path FOR GTA03 Feb 26 14:07:10 KISS applies. Feb 26 14:07:45 qi never was intended to replace uBoot on gta02. (And FOR SURE not on gta01 :-P ) Feb 26 14:07:47 all this hacking on calypso (osmocom-bb) made clear whats 'essential' to get the job done Feb 26 14:08:11 Heinervdm: hmm this is not really good solution for that problem :/ Feb 26 14:08:21 DocScrutinizer51: but it could, give someone is up for the task of making it a) work b) provide some sane migration path Feb 26 14:08:33 Heinervdm: with next PR bump in kernel recipe it will install kernel-image to /boot on that installed system Feb 26 14:08:40 JaMa: we need some IMAGE_FILES_jffs2 :) Feb 26 14:08:49 NOTE: Running task 406 of 3058 :( ffs Feb 26 14:09:06 Heinervdm: or modify kernel_install for devices where is kernel ususally in different partition Feb 26 14:09:47 JaMa, what do you think about my scalable screenshot? Feb 26 14:09:48 Heinervdm: ah no.. because that would be damn hard to do it only for jffs2 :) Feb 26 14:09:59 TAsn: beautiful! :) Feb 26 14:09:59 JaMa: we already have a function to find out, if image is in nand or on sd Feb 26 14:10:04 for real? Feb 26 14:10:08 do you want me to commit it? Feb 26 14:10:16 Heinervdm: hmm my fault.. Feb 26 14:10:26 Heinervdm: we can remove it from all FSTYPES for gta01 :) Feb 26 14:10:43 JaMa: for gta01 yes :) Feb 26 14:10:48 fsck. /me is out of boxes Feb 26 14:10:52 Heinervdm: because even uSD can be booted with kernel from nand, or no? Feb 26 14:11:15 JaMa: you need kernel on different partition with uboot Feb 26 14:11:16 Heinervdm: even when default u-boot env uses by default layout on uSD where is kernel also on uSD Feb 26 14:11:25 * roh misses the times of weird booting Feb 26 14:12:10 guys, what's missing is a *decent* tool to edit uboot env from within a normal system Feb 26 14:12:13 like on prep ppc... you had a dos partition table, and the second partition was type 0x41.. and there you dd'ed in your kernel with some magic header Feb 26 14:12:13 Heinervdm: yeah FAT on first uSD partition was default env, wasn't it? Feb 26 14:12:18 JaMa: hmm, now i'm confused how does a kernel update work with on usd and uboot? Feb 26 14:12:27 JaMa: yes Feb 26 14:12:50 Heinervdm: if you mount /boot to that fat partition then i guess flawlessly :) Feb 26 14:13:09 but our image doesn't do that and users probably also don't Feb 26 14:13:10 JaMa: yes but our image doesn't do that by default Feb 26 14:13:16 :) Feb 26 14:13:55 but gta02 is for average devels, gta01 for gurus.. so I guess they are able to solve it :) Feb 26 14:14:10 yes Feb 26 14:14:18 JaMa, please build libphone-ui-shr :P Feb 26 14:14:27 but we're having the same problem on gta02 Feb 26 14:14:28 SHR: 03tom 07libphone-ui-shr * r37470e9ff3d8 10/data/keypad.edc: Changed the keypad to support resizing Feb 26 14:14:28 TAsn: NOTE: Running task 9685 of 13446 Feb 26 14:14:38 shit :P Feb 26 14:14:38 TAsn: but queued Feb 26 14:14:57 Heinervdm: only with u-boot you mean right? Feb 26 14:15:04 JaMa: yes Feb 26 14:15:41 support 2 bootloaders with optimal images is quite pita :) Feb 26 14:15:45 Someone knows if kernelupgrade works on SHR with uboot and image on SD card? Feb 26 14:16:05 I gues that image-u-boot and image-qi would be much worse confusing :) Feb 26 14:16:16 JaMa: so WHY are you doing it? Feb 26 14:16:22 I'm not Feb 26 14:16:58 Heinervdm: 95% it will only update image in /boot and user have to update the image u-boot actually uses by hand Feb 26 14:17:17 Heinervdm: I always did that when using image on nand and seen that something new landed in /boot Feb 26 14:17:24 JaMa: i think so too, but then an kernelupgrade will break the phone Feb 26 14:17:46 Heinervdm: you mean if incompatible modules are installed? Feb 26 14:17:55 JaMa: with image in nand kernel is flashed automatically with nandwirte Feb 26 14:18:03 JaMa: yes Feb 26 14:18:08 that's what I wondered for "years" now Feb 26 14:18:21 Heinervdm: now yes.. but when I was using image in nand it doesn't do that automaticaly :) Feb 26 14:18:31 didn't Feb 26 14:18:53 hmm for me it alwasy worked :) Feb 26 14:18:56 because it was about >1,5y ago Feb 26 14:19:49 or just very long ago if >1,5y is too much :) Feb 26 14:20:53 how about fsckng check how to make a wrking envedit? then get rid of 256byte-inode flaw i uBoot, either by fixing uBoot or by using 128-inodes. Then u can get rid of all that nasty FAT partion "needed" now to boot from uSD Feb 26 14:21:21 and probably discard / retire the kernel partition in NANd as well Feb 26 14:21:55 Debian folks have a working envedit i think. Feb 26 14:22:13 DocScrutinizer: so you prefer u-boot over qi or you mean to do it just because of gta01? Feb 26 14:22:26 I tried it with few success. Maybe due to pebkac Feb 26 14:23:36 JaMa: I prefer to support a infra *every* user has to use occasionally, as device is shipped with uBoot Feb 26 14:24:32 if you manage to find a *automagic* way to migrate to qi sanely, I'd probably not jump in to stop you Feb 26 14:25:31 * JaMa installed qi long ago and booted u-boot from nor just once since then to replace qi with qi-ubi Feb 26 14:25:33 but that way had to comprise of a decent bootmeny for multiboot as well, generated automatically from uBoot envs Feb 26 14:26:06 so I'm not the one to who would like to mess with user's bootloaders.. Feb 26 14:26:09 JaMa: why not simply not care about bootloader and just place the kernel image on update to /boot/uImage-GTA02.bin to make it automagically compatible with Qi? Those who boot from NAND will flash the image themselves. Feb 26 14:26:54 PaulFertser: we already do that Feb 26 14:26:58 PaulFertser: that's how it works now.. we're thinking about how to remove this behavior in "already too big" jffs/ubi images for gta01 Feb 26 14:27:10 JaMa: oh Feb 26 14:27:13 PaulFertser: and we flash the kernel to nand, if image was installed to nand Feb 26 14:27:42 PaulFertser: as I have patch to remove it in built images, but then it will be installed automaticaly with first kernel upgrades user get with opkg upgrade Feb 26 14:27:56 PaulFertser: which will probably fail due to lack of free space Feb 26 14:28:29 PaulFertser: one thing we realized now is, what if you use uboot and boot from uSD? then kernel wouldn't be flashed to the FAT partition automatically Feb 26 14:29:02 JaMa: i see. But kernel upgrade is just that, you initiate it and a new kernel should be stored somewhere as a result. If you booted from NAND you can't assume there's additional storage somewhere else except in the kernel NAND partition. Feb 26 14:29:22 Heinervdm: i think one shouldn't care, it's up to the user to configure his u-boot the way he wants it. Feb 26 14:29:47 Heinervdm: and he can configure his system to mount that fat partition as /boot. Feb 26 14:30:32 JaMa: how do you detect if a new kernel should be flashed to NAND currently? Feb 26 14:30:49 PaulFertser: by some parameters from /proc/cmdline Feb 26 14:30:57 JaMa: i guess if it should -> do it, if it shouldn't -> you booted from uSD and can assume enough free space in /. Feb 26 14:30:59 PaulFertser: yes but not it imho works, that it stores image in /boot and then if "detect if running from nand" flash it also to nand partition Feb 26 14:31:04 i thing by the root parameter Feb 26 14:31:34 JaMa: but is there any other way to directly nandwrite the image without storing it somewhere firts? Feb 26 14:31:46 s/not/now/ Feb 26 14:31:46 JaMa meant: PaulFertser: yes but now it imho works, that it stores image in /boot and then if "detect if running from nand" flash it also to nand partition Feb 26 14:32:31 PaulFertser: I just changed opkg behavior to not unpack .ipks to tmpfs in ram but to /var/lib/opkg/tmp instead (due to lack of mem with bigger upgrades) Feb 26 14:32:57 PaulFertser: so it will need few MB free at least for temporary storage Feb 26 14:33:48 JaMa: so you inevitably need free space in / Feb 26 14:34:39 JaMa: are there many users that really want to run their gta01 from NAND? I guess you can through out all but the most essential packages for them. Feb 26 14:34:48 And let others have rootfs on uSD Feb 26 14:35:47 boot_arg=`cat /proc/cmdline |tr " " "\n"|grep "root=" |tail -n 1` Feb 26 14:35:47 has_mtdblock=`echo $boot_arg |grep mtdblock` Feb 26 14:36:11 JaMa: ^ from postinst in linux-openmoko.inc Feb 26 14:36:14 PaulFertser: that's why started with stripping -lite image Feb 26 14:36:36 PaulFertser: but seen already 3 reports that dfu-util failed Feb 26 14:36:55 PaulFertser: last time today.. so I removed all bigger images.. and I'm building one without /boot now Feb 26 14:38:03 mrmoku: fso upgrade in feeds Feb 26 14:39:01 TAsn: c2f0a610cef21d3538620dd064118baa0bbf835d is what you wanted for libphone-ui-shr? Feb 26 14:39:28 no Feb 26 14:39:35

SHR: tom libphone-ui-shr * r37470e9ff3d8 /data/keypad.edc: Changed the keypad to support resizing Feb 26 14:40:30 TAsn: we're already in contacts branch? Feb 26 14:40:50 shit Feb 26 14:40:52 nvm Feb 26 14:40:54 TAsn: because you pushed it there :) Feb 26 14:40:55 don't build Feb 26 14:40:57 I'm an idiot :P Feb 26 14:41:02 * JaMa waiting for repush Feb 26 14:41:08 will take a sec Feb 26 14:41:14 cause I'm doing something else as well Feb 26 14:41:15 so later Feb 26 14:41:17 no rush :P Feb 26 14:41:19 ok Feb 26 14:43:15 JaMa: great thanks Feb 26 14:45:03 Deubeuliou: btw hackable build seems hanging on "git-fetch --update-head-ok" (in /bin/sh ./package.sh DEBUG=1 -> git pull) for last day or more (or maybe it's coincidence everytime when I looked) Feb 26 14:45:30 * JaMa hopes that Deubeuliou is that hackable guy here :) Feb 26 14:45:51 hi JaMa Feb 26 14:45:59 mmmh Feb 26 14:46:20 lemm check Feb 26 14:54:35 mrmoku: shouldn't be freesmartphone/libgsm0710mux/om-gta02/abyss.conf updated somehow? Feb 26 14:54:52 mrmoku: or maybe it's addept for git repo inclusion Feb 26 14:55:09 mrmoku: new opimd in feeds? Feb 26 14:55:23 Q-Master: no Feb 26 14:55:39 JaMa: hmm... dunno Feb 26 14:56:04 JaMa: I cleaned h1's seemingly dead processes Feb 26 14:56:36 mrmoku: from quick glance on mickey's commits it will look for abyss.conf in the same way as ie fsodeviced is.. Feb 26 14:57:18 Deubeuliou: thanks (it wasn't problem.. as it didn't use any resources) Feb 26 14:59:09 JaMa: let me upgrade and check :) Feb 26 15:30:05 hm. no GSM at all after upgrade Feb 26 15:30:31 * mrmoku has gsm after upgrade Feb 26 15:31:37 mrmoku: any config changes since last week? Feb 26 15:32:28 mrmoku: 2010.02.26 18:31:58.710 dbus.connection ERROR Unable to set arguments (True, 98, '/dev/ttySAC0', 115200) according to signature u'bissi': : Expected a string or unicode object Feb 26 15:32:45 wtf? Feb 26 15:32:51 Q-Master: hmm... what does opkg files libgsm0710mux-config say? Feb 26 15:33:24 only /etc/abyss.conf Feb 26 15:33:38 fine then Feb 26 15:33:56 from which log is that? Feb 26 15:34:18 frameworkd Feb 26 15:34:36 * mrmoku is retrying _without_ DEBUG now Feb 26 15:35:10 JaMa, any idea how can I hand pick commits from a branch to master? Feb 26 15:35:12 SHR: 03tom 07libphone-ui-shr * rf3e9b4e58497 10/data/quick-settings.edc: Added quick-settings.edc Feb 26 15:35:27 http://pastebin.com/d6VGGQ8g Feb 26 15:35:45 mrmoku, BEHOLD THE EDJE MASTER! Feb 26 15:35:53 (j/k, though I'm not a complete noob anymore) Feb 26 15:38:28 mrmoku: look at pastebin Feb 26 15:40:08 Q-Master: hmm Feb 26 15:40:20 TAsn: just cherry-pick hash should work Feb 26 15:40:36 vanous123: new fso is there Feb 26 15:40:44 mrmoku: check if you have latest.. Feb 26 15:40:57 mrmoku: some parts were upgraded about 10 mins ago.. Feb 26 15:40:58 JaMa: yeah... difficult though :/ Feb 26 15:41:11 as I had my local builds installed... Feb 26 15:41:14 mrmoku: because it's not part of task-shr-minimal :/ Feb 26 15:41:24 ah I see.. Feb 26 15:42:00 4741640d49705129fcb82a2f6126abcc305462c9 Feb 26 15:42:05 SHR: 03tom 07libphone-ui-shr * ra3e523463d92 10/data/quick-settings.edc: Added quick-settings.edc Feb 26 15:42:05 JaMa, ^ Feb 26 15:42:06 SHR: 03tom 07libphone-ui-shr * r4741640d4970 10/data/keypad.edc: Changed the keypad to support resizing Feb 26 15:42:06 :P Feb 26 15:42:10 mrmoku: btw I have commit for moving everything needed only to task-shr task-shr-minimal (no aditional deps in image as I often want to rebuild everything needed for image without building rootfs (time) Feb 26 15:42:24 JaMa: go ahead Feb 26 15:43:15 TAsn: ok.. Feb 26 15:43:27 thakns :P Feb 26 15:44:18 mrmoku: and there is something more strange in shr builds.. that libsyncml issue in pisi was resolved in my localbuilds with -O2 but when I flash image from shr buildhost it fails with Illegal instruction :/ Feb 26 15:44:58 mrmoku: after last gcc-4.4.3 upgrade I'm tempted to rebuild from scratch on buildhost (but waiting if I find more time to check that qtxml gcc-4.4 issue first) Feb 26 15:45:26 JaMa: ok Feb 26 15:46:54 pkg_get_installed_files: Failed to open //usr/lib/opkg/info/libimlib2-1.list: No such file or directory. Feb 26 15:46:56 hm. Feb 26 15:46:59 what's that? Feb 26 15:47:02