**** BEGIN LOGGING AT Mon Jan 03 02:59:58 2011 Jan 03 04:41:04 hello Jan 03 04:41:56 how about switching to n900 ? Jan 03 08:06:20 m Jan 03 08:06:24 oin Jan 03 09:40:23 morning Jan 03 10:54:53 morning morphis Jan 03 10:55:03 mickey|office: heyho Jan 03 10:56:30 mickey|office: you tried again using fsogsmd/msmcommd tonight? Jan 03 10:56:39 s/tonight/last night/ Jan 03 10:56:39 morphis meant: mickey|office: you tried again using fsogsmd/msmcommd last night? Jan 03 10:57:13 only shortly, but yes. init worked, however Register and GetStatus didn't Jan 03 10:57:25 after seeing the #if 0 in the code, it's not surprising though :) Jan 03 10:57:32 in GetStatus? Jan 03 10:57:37 yep Jan 03 10:57:46 Register should be implemented Jan 03 10:57:51 and working Jan 03 10:58:21 ok, perhaps it did, but i didn't receive and status updates Jan 03 10:58:30 so i tried to use get, which wasn't implemented Jan 03 10:58:36 s/and/any/ Jan 03 10:59:48 ok Jan 03 11:01:05 in general it looks a bit more complicated than i would have thought Jan 03 11:01:27 it's not very stable Jan 03 11:01:37 and far away from complete Jan 03 11:01:39 i thought now that we have a dbus API, all we have to do is call the commands in the mediators and collect them to create the responses Jan 03 11:02:15 right Jan 03 11:02:34 i.e. all the command queue stuff we used before should be obsolete now, no? Jan 03 11:02:45 right Jan 03 11:02:52 good Jan 03 11:03:06 then we can move from here Jan 03 11:04:44 hm maybe I should fully concentrate now on fsogsmd/msmcommd/libmsmcomm and don't do any rootfs stuff Jan 03 11:04:59 as it is not like I/we want it to be Jan 03 11:05:53 yeah, might be wise Jan 03 11:06:31 hm Jan 03 11:07:50 it's a question of what you want to achieve Jan 03 11:08:07 rootfs is nice, but if telephony doesn't work, noone will be happy withit Jan 03 11:09:25 right Jan 03 11:10:03 but it is quite demotivating when even rootfs is not working after one year now Jan 03 11:10:16 I am feeling a little bit alone Jan 03 11:10:35 but thats maybe something I have to accept in this business Jan 03 11:11:18 tell me about it .) Jan 03 11:11:57 where is the base problem with the rootfs? Jan 03 11:12:19 integration Jan 03 11:12:32 fsodevice should handle tsmd start and stop correctly Jan 03 11:12:40 audio routing needs testing and buf fixing Jan 03 11:12:50 suspend/resume should work right Jan 03 11:13:00 keyboard Jan 03 11:13:14 palmpre2 support Jan 03 11:15:04 all not very complicated but they need time Jan 03 11:16:56 yep Jan 03 11:17:30 anyway ... maybe we will find someone when telephony is working better Jan 03 11:17:39 btw. my Pre Plus from Palm is on the road Jan 03 11:17:51 nice. after the initial communication i didn't hear anymore from them Jan 03 11:17:52 I got a letter from UPS about tax Jan 03 11:18:02 you got mail from them? Jan 03 11:18:14 yeah, we talked a bit about Jan 03 11:18:23 what we are going to do with the device Jan 03 11:18:28 ah ok Jan 03 11:18:35 and they quailified you for the device? Jan 03 11:18:41 it sounded like that Jan 03 11:18:56 but it's ok anyways... i really don't need another one Jan 03 11:19:08 since i'm not using the one i have for anything but developing Jan 03 11:19:29 ok, but it's maybe an option for another developer who got no one Jan 03 11:19:32 at least until we have the critical functionality done Jan 03 11:19:34 and need one for development Jan 03 11:19:38 ok Jan 03 11:22:26 where did all the other potential interested folks go? Jan 03 11:22:33 are they back to webos? Jan 03 11:43:59 mickey|office: how about the modem resource request in fsogsmd, shoudl fsogsmd request the modem resource from start on without being self requested by anyone? Jan 03 11:44:13 actually it needs to Jan 03 11:44:17 the semantics is like that: Jan 03 11:44:23 fsogsmd turns off the modem when it starts Jan 03 11:44:40 it can only do that once it established a communication with msmcommd Jan 03 11:45:15 ok but it have the modem resource ready all time, right? Jan 03 11:45:31 or only when itself is requested by someone else? Jan 03 11:46:10 that's up to us. I'd say hold the resource all the time, if turning on/off are seperate Jan 03 11:47:15 turing on/off is separate Jan 03 11:47:31 then I will register the modem resource on channel startup Jan 03 11:49:32 yep Jan 03 11:58:16 i'll try booting from NFS Jan 03 11:58:25 if that works, i'll have a look at some of the issues Jan 03 11:58:40 can I build from OE or do i need the FSO repo? Jan 03 12:00:17 use the fso repo Jan 03 12:00:24 hmm Jan 03 12:00:25 I need to push the patches I have there upstream Jan 03 12:00:26 ok Jan 03 12:00:32 yes Jan 03 12:00:57 but I rebase the palmpre/snapshot-2010.12 branch very often Jan 03 12:01:06 I hope I can push them today or tomorrow Jan 03 12:04:43 should I rely on the modemagent to have the modem resource ready when channel initialization is running or should I check for it? Jan 03 12:05:42 i'm not sure. the split between the main channel and the modemagent looked a bit arbitrary to me Jan 03 12:06:00 how would you solve it? Jan 03 12:06:13 i would consider the main channel being the modem agent Jan 03 12:06:51 and request the resource on creation Jan 03 12:06:58 release on destruction Jan 03 12:07:42 if it'S not possible to request at creation time, then deferring to opening time Jan 03 12:07:46 sounds better than the current solution Jan 03 12:08:14 even as we don't have another singleton object then Jan 03 12:08:21 yep Jan 03 12:10:50 will do that Jan 03 12:13:27 cool Jan 03 12:13:58 msmcommd is quite amazing actually Jan 03 12:14:08 it's great that you took the pain to rewrite it in vala Jan 03 12:14:38 :) Jan 03 12:15:07 thanks for laudation Jan 03 12:15:18 I am even planning to rewrite libmsmcomm in vala Jan 03 12:15:27 you looked at the msmcommd code? Jan 03 12:17:34 not at the classes in particular, but at the overall separation Jan 03 12:17:38 i.e. the architecture Jan 03 12:17:39 ok Jan 03 12:17:44 which i liked Jan 03 12:18:02 I adopted your channel/commndqueue implementation from the old modem_qualcomm_palm plugin Jan 03 13:55:38 morphis: hi I read your discution with mickey|office about palm pre and msmcommd. just to tell you that i will try to help as much I will be able. hoping it will let you fell a bit less alone. fisrt i will take care about fso installer Jan 03 14:25:35 is mrmoku back? Jan 03 14:26:11 JaMa, hi Jan 03 14:26:33 JaMa, what do you think about going back to 2.6.28 for the nokia n900? Jan 03 14:27:21 http://wiki.freesmartphone.org/index.php/Nokia900_Kernels Jan 03 14:30:07 depends on mickey who pushed it.. I'll stay with 2.6.35 in my images because of btrfs, but I'm ok with 2.6.28 back as default Jan 03 14:30:20 ok Jan 03 14:30:26 I'll have to ask mrmoku too Jan 03 14:30:43 I think mickeyl doesn't like 2.6.28 because it doesn't have devtmpfs Jan 03 14:30:58 what's the real advantage of devtmpfs? apart boot speed Jan 03 14:31:14 the nokia900 is fast enough at boot Jan 03 14:31:31 one process less, no bogus devices in /dev/ Jan 03 14:31:39 ok Jan 03 14:31:56 I know that can be annoying for you Jan 03 14:31:59 but what's best? Jan 03 14:32:07 bluetooth coexistance Jan 03 14:32:08 camera Jan 03 14:32:12 dvfs Jan 03 14:32:22 charger detection Jan 03 14:32:24 usb host Jan 03 14:32:27 or... Jan 03 14:32:30 devtmpfs Jan 03 14:32:36 gpio buttons working in xorg Jan 03 14:32:45 input node for accelerometers Jan 03 14:32:58 don't worry about me Jan 03 14:33:10 i'll not be using the n900 in native mode for a long while Jan 03 14:33:15 ah ok Jan 03 14:33:18 s/native/non-maemo/ Jan 03 14:33:19 mickey|office meant: i'll not be using the n900 in non-maemo mode for a long while Jan 03 14:33:21 there is also old modem activation Jan 03 14:33:25 in 2.6.28 Jan 03 14:33:53 so I have your ack Jan 03 14:33:59 Jama ack Jan 03 14:34:01 i don't like it Jan 03 14:34:06 but if you want to, do it Jan 03 14:34:07 I'll wait for mrmoku ack Jan 03 14:34:16 although i still suggest doing it in a branch Jan 03 14:34:19 so we don't have to revert Jan 03 14:34:22 but can instead move to .37 soon Jan 03 14:34:26 mickey|office, maybe when you'll use it with shr we will have switched to 2.6.37 Jan 03 14:34:44 I would have to maintain that branch Jan 03 14:34:49 I don't have time for that Jan 03 14:34:54 hmm Jan 03 14:34:57 i say it saves you time Jan 03 14:35:08 remember about keeping the number of variables low? Jan 03 14:35:14 yes Jan 03 14:35:18 that's exactly what you would do with a branch Jan 03 14:35:23 getting your working environment Jan 03 14:35:25 :( Jan 03 14:35:47 why not the countrary Jan 03 14:35:53 2.6.35/37 in a branch Jan 03 14:36:01 we will need them later Jan 03 14:36:06 else there is a third solution Jan 03 14:36:09 I work on kernel Jan 03 14:36:38 I add camera, bluetooth coexistance, findout how to detect charger Jan 03 14:36:40 etc... Jan 03 14:36:48 we already have devtmpfs... Jan 03 14:37:03 s/devtmpfs/dvfs/ Jan 03 14:37:03 GNUtoo|laptop meant: we already have dvfs... Jan 03 14:37:20 and I started for camera Jan 03 14:37:28 we don't need every camera chip Jan 03 14:37:39 just the SOC link and the sensor Jan 03 14:38:02 for instance flash etc... are not needed yet Jan 03 14:38:06 as there are no apps to use them Jan 03 14:39:27 altough we have to use the multimedia framework for camera Jan 03 14:39:41 for instance for hardware processing etc... Jan 03 14:39:50 maybe I'll do that Jan 03 14:39:53 work on 37 Jan 03 14:39:58 if I succeed Jan 03 14:40:03 everybody is happy Jan 03 14:40:20 indeed Jan 03 14:40:27 and as it's not crucial.... Jan 03 14:40:30 I can do it Jan 03 14:40:43 I hope I'll find the force to do it Jan 03 15:14:40 larsc: hi, how .37 is going? :) Jan 03 15:28:00 gena2x: good. i think the only thing left to do are new defconfigs Jan 03 15:47:00 ffalarms were fixed, nice now only 3 packages/recipes/software are left: Jan 03 15:47:09 *was fixed Jan 03 15:47:19 recipes/openmoko-3rdparty/iliwi_git.bb' failed Jan 03 15:47:25 recipes/shr/libphone-ui_git.bb' failed Jan 03 15:47:30 recipes/shr/phonefsod_git.bb' failed Jan 03 15:47:42 yup same here Jan 03 16:05:13 * pespin looking at Iliwi code now Jan 03 16:13:44 JaMa, I have Iliwi working :) Jan 03 16:13:53 shall I send a patch somewhere? Jan 03 16:14:51 pespin: shr-devel ML Jan 03 16:16:15 JaMa, I had to change another thing apart from the error you had. I had another error about using a disconnect() method which was overriding the superclass method Jan 03 16:16:36 I did s/disconnect/disconnectt Jan 03 16:21:08 sent Jan 03 16:22:37 maybe use better name then disconnectt? this way it looks like typo Jan 03 16:23:05 maybe disconnect_t? Jan 03 16:23:32 or disconnect_theread? Jan 03 16:26:36 pespin: bounced to ebbe too Jan 03 16:26:54 JaMa, ebbe? Jan 03 16:30:16 iliwi author listed in github Jan 03 16:30:58 ok Jan 03 16:31:36 JaMa, will you push the patch in OE or you will wait for it to be pushed upstream? Jan 03 16:40:12 pespin: if ebbe doesn't include it before mrmoku fixes libphone-ui and phonefsod, I'll apply it in OE Jan 03 16:42:51 ok Jan 03 16:43:34 JaMa, how can I remove from image the packages failing to build? I'd like to build a new image for my htc artemis Jan 03 16:48:47 pespin: if you have testlab files from some older images check which recipes (mostly task-) pulls them in and rebuild those without it in (R)DEPENDS Jan 03 16:49:29 but without libphone-ui phonefsod, you can almost build just e-image instead Jan 03 16:49:57 ok Jan 03 16:52:36 GarthPS: ping Jan 03 16:58:47 hm. interesting, does the kernel support suspending usb/turning UPLL off? this may save power... Jan 03 16:59:14 morphis: yopong Jan 03 17:00:24 GarthPS: read your offer about testing Jan 03 17:00:46 GarthPS: fso-installer would be really great Jan 03 17:01:23 as we need it for anybody else to have a quick and positive start with SHR/FSO on the palmpre Jan 03 17:01:54 btw. do you have any special interests on what to work? Jan 03 17:04:28 morphis: sorry I did not understand your last phrase. Jan 03 17:04:59 do you have any preference on what to work on beside the fso-installer? Jan 03 17:05:05 morphis: I want to put my hands in fso-install this week. did not have the time during hollydays Jan 03 17:05:21 ok Jan 03 17:05:38 if you have patches ready send them to the fso-userland mailing list Jan 03 17:06:48 morphis: I thinks where I can help is test/repport logs bugs and tweak a bit . for the moment I do not have any experience in distribution building so I will learn Jan 03 17:07:05 ok Jan 03 17:07:11 but I think more in the integration part of fso/shr to palm Jan 03 17:07:54 about fso-installer I though iw ill show/ask you before sending any patches. Jan 03 17:09:29 ok Jan 03 17:10:14 so what are you gonna change now in fso-installer (I forgot about our last discussion on it)? Jan 03 17:30:26 freesmartphone.org: 03mickey 07cornucopia * r5a298f934a40 10/fsotdld/ (4 files in 3 dirs): fsotdld: add build skeleton for provider_location_cellidwifi plugin Jan 03 17:34:40 GNUtoo|laptop: back now :-) Jan 03 17:34:52 ok nice Jan 03 17:38:18 mrmoku, hi! :) Jan 03 17:38:45 hi pespin Jan 03 17:39:51 morphis: wget all needed stuff, restore data after partitionning, setup-init,install-all,switch-boot, something else ? Jan 03 17:41:22 daniele_athome: ping Jan 03 18:04:07 mrmoku, !!! Jan 03 18:04:09 mrmoku, here? Jan 03 18:04:37 yes, he came back Jan 03 18:04:55 for good? Jan 03 18:04:58 :P Jan 03 18:06:43 yes Jan 03 18:06:50 i think so Jan 03 18:07:14 maybe he's eating currently Jan 03 18:07:32 it's just a guess...as I am eating... Jan 03 18:07:49 TAsn: yup, here Jan 03 18:08:13 and no... he's converting libphone-ui to gdbus Jan 03 18:08:43 :P Jan 03 18:09:24 nice!!! Jan 03 18:12:34 gdbus == GDB us? Jan 03 18:12:56 hehe, I'm debugging us Jan 03 18:12:59 brb Jan 03 18:13:13 lol ok Jan 03 18:13:21 hmm, anyone used libsoup w/ vala before? Jan 03 18:14:28 no Jan 03 18:23:30 mrmoku, what do you think of going back to 2.6.28: http://wiki.freesmartphone.org/index.php/Nokia900_Kernels Jan 03 18:26:27 GNUtoo|laptop: no idea yet Jan 03 18:27:29 ok Jan 03 18:27:53 mickeyl want me to branch because I want 2.6.28 back Jan 03 18:28:40 GNUtoo|laptop: I will look at kernel situation after fixing gdbus Jan 03 18:28:47 that is the most important thing now Jan 03 18:28:48 ok Jan 03 18:28:51 yes Jan 03 18:29:13 gdbus prevent build, and worse...for all devices Jan 03 18:29:21 not only n900 Jan 03 18:29:41 yup Jan 03 18:58:59 GNUtoo|htcdream, lol -> checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool Jan 03 18:59:41 I think I'll wait to buy a new computer before rebuilding from scratch -.- Jan 03 19:00:07 I'll probalby buy an Intel i5 in the next days Jan 03 19:00:57 OE pushes semiconductor industry forward, heh! Jan 03 19:01:39 xDDDD Jan 03 19:05:35 pespin,devshell the perl call Jan 03 19:06:26 perl -e "require ... Jan 03 19:06:34 fails in devshell Jan 03 19:06:50 alternatively you xould fix it... Jan 03 19:07:55 GNUtoo|htcdream, yep I saw that. I'm trying to symlink the oe perl-native binary to my sys perl :P Jan 03 19:08:40 let's see if it can build fine with that perl :D Jan 03 19:17:11 yeah, it worked! :P Jan 03 19:18:57 ok Jan 03 19:19:31 oe stands for obfuscated embedded? Jan 03 19:38:50 freesmartphone.org: 03mickey 07cornucopia * rfed5109c1172 10/fsotdld/ (3 files in 2 dirs): Jan 03 19:38:50 freesmartphone.org: fsotdld: provider_location_cellidwifi: implement cell id lookup Jan 03 19:38:50 freesmartphone.org: NOTE: we require libsoup-2.4 and json-glib-1.0 now Jan 03 19:51:33 uhm here OE is building libisi, but I thought that was needed only for nokia n900 right? Jan 03 19:53:21 yes Jan 03 19:53:32 it's needed only for nokia900 Jan 03 19:53:40 or should at least Jan 03 19:54:54 pespin ask mickeyl to correct that. Jan 03 19:59:01 FSO stuff gets built even for "minimal" distro with "console-image" Jan 03 19:59:05 So i'm not surprised :) Jan 03 19:59:10 :P Jan 03 19:59:16 PaulFertser: btw. not much snow in italy :) Jan 03 19:59:28 mrmoku: you should have come here to Russia. Jan 03 19:59:35 mrmoku: it's absolutely marvelous/insane here. Jan 03 19:59:53 mrmoku: after the ice shower every signle branch of every tree is covered in thick ice. Jan 03 19:59:54 yeah, believe that Jan 03 20:00:05 mrmoku: same about cars of course, i had hard time trying to open mine. Jan 03 20:00:14 and no thanks :P Jan 03 20:01:26 mrmoku: plenty of snow, one can make snowmen and play snowballs all day long. Jan 03 20:03:02 mrmoku, at what point are you? Jan 03 20:03:18 for the iliwi,libphone-ui,phonefsod Jan 03 20:03:51 mickeyl, recipes/freesmartphone/fsotdld_git.bb' failed Jan 03 20:04:19 GNUtoo|laptop: in the middle of libphone-ui Jan 03 20:04:23 ok Jan 03 20:04:27 then I let you work Jan 03 20:04:29 should be the most intensive part Jan 03 20:04:36 heh snowman. it is possible to build snowelephants army this year... Jan 03 20:05:08 PaulFertser: my kids would very much enjoy that indeed :) Jan 03 20:05:44 mrmoku: so prepare you van and plan the next vacation ;) Jan 03 20:07:35 | checking for SOUP... configure: error: Package requirements (libsoup-2.4 >= 2.30) were not met: Jan 03 20:14:40 | Requested 'libsoup-2.4 >= 2.30' but version of libsoup is 2.29.91 Jan 03 20:14:44 hmmm Jan 03 20:14:56 do you really need 2.30? Jan 03 20:29:43 Round up and it's 2.30, GNUtoo|laptop . Jan 03 20:29:47 :p Jan 03 20:29:59 ok Jan 03 20:30:16 mwester: you know some OE-foo for sure ;) Jan 03 20:30:46 Really, I have no idea. Sometimes the dependencies are real, other times they are just what somebody tested and found to work (which is to say that something earlier might work but it was just never tested). Jan 03 20:30:49 round up is a mathematic operation? Jan 03 20:31:09 No, no operation of that sort is available in OE. :( Jan 03 20:32:16 What package is it that is requiring libsoup 2.30? Jan 03 20:32:42 fsotldt Jan 03 20:33:01 that's why I pinged mickeyl Jan 03 20:33:38 Ah, ok - I missed the pinging part -- mickeyl would be the best person to know. Jan 03 20:47:07 mwester: so many people are unhappy about OE that they choose other cross-compiling environments. That's actually a strange thing given that OE is quite consistent in its purposes and implemntation. I'm used to the thought that consistent things work well. But for he purpose. Like gentoo. Gentoo is a really nice distro but only for a gentoo-lover. :) Jan 03 20:48:53 Most of the "alternatives" are really only partial alternatives -- there are other cross-compilation environments that are much easier. I'm partial to optware, for instance -- far simpler, far easier. Jan 03 20:49:55 But optware doesn't do what OE does -- you can't bootstrap an entire distro from source code, building your toolchain, apps, and rootfs, and package feeds from the same environment. But the cost of being able to do that (build everything) is complexity. Jan 03 20:50:20 (BTW, if openmoko had ever really taken off in a huge way, we would have an optware feed for it.) Jan 03 20:50:57 mwester: but is OE really needed nowadays? One can use something like OpenSUSE build service or just build native Debian on a sheevaplug. And for the less capable targets OpenWRT suits quite well. Jan 03 20:51:32 Yes, something like OE is needed. Jan 03 20:52:03 The only thing building natively on a sheevaplug does for you is enable you to build a binary that *might* run on a very small subset of other devices. Jan 03 20:52:43 And other services also assume that there exists a fully-capable toolchain, and that they have a copy of the pertinent host libs to like against (SDK). Jan 03 20:53:06 How's so? I thought one can build full debian distro on a sheevaplug and that'll work on every armv4 out there. Jan 03 20:53:26 OpenWRTworks very well, and is one of the alternatives to OE -- but it too has some assumptions that are not inherent in OE. (althought those assumptions might actualy work for more devices than not). Jan 03 20:55:59 What you can target on a sheevaplug depends on the toolchain that's installed, and on the host libs that you link against. It might be the case that your target is not optimally supported by the toolchain on the sheevaplug -- you'd have to settle for less than optimal, or you would need to build your own new toolchain. The new toolchain MIGHT be easier to build since it MIGHT be native, but it's not too much of a stretch to get into a case Jan 03 20:55:59 where the toolchain you build can't work for the host -- in which case you are in cross-compilation again. Jan 03 20:56:58 True, true. Jan 03 20:58:22 I expect that's unlikely to occur for the stated use-case -- because the distro generated by OE for the GTA0x devices is basically Debian-like, as is the distro for the Sheeva. I'd suggest that one consider a less congruent set of devices -- how about building apps for SHR using OpenWRT on the Sheeva? Jan 03 20:58:29 That'd be a bit harder. Jan 03 21:00:27 But is there a niche for the specialised distros even? I run mainline debian on my freerunner and it fits just fine. More modern devices will be even more powerful, so why not use mainline right from the beginning? Jan 03 21:01:01 But all that aside, I am in favor of using OE only to build a stable core image and the toolchain/SDK required to build apps for that image -- and then switch to something simpler, that doesn't require GB of downloads and days of compilation on the part of end users who just want to contribute. I think OE has proven to be an inhibitor in that way. Jan 03 21:03:25 Re: niche -- I think so, but I am partial -- I love to experiment by cracking open all sorts of devices and getting a linux distro of some sort booting up. But in general, it is fair to say that the small-distro world is becoming more defined in addition to the devices becoming more capable. The need for specialized distros will continue but like Ham Radio has changed to "operator" from "builder", we'll see hobbyists becoming "loaders" of Jan 03 21:03:25 precanned distros, instead ob "builders" of distros. Jan 03 21:03:30 mwester: i think toolchain/SDK doesn't work usually because of the dependencies. When you are compiling the kernel, it depends on nothing, you need only the toolchain. But the more complicated the software gets, the more dependecies needed. And you come to the same system as OE. A packaged snapshot of OE would help of course. Jan 03 21:05:03 Exactly -- an early failing for all the distros on the gtra0x devices was that nobody standardized on a single stable core rootfs. As a result, we ended up asking every user to build the world. And things broke. BTW - OE has introducted the concept of "OE releases" -- so going forward, you CAN base an image on a single stable OE version. Jan 03 21:05:32 mwester: for me (as a user) the main problem with OE is not traffic or disk space, but obscure compilation faults. Of course an experienced dev can gradually learn how to deal with that. But it's still a pain. And for a newcomer compiling the .dev OE branch is almost impossible. Jan 03 21:06:14 I've used it for years, and find the .dev branch to be an exercise in frustration. I competely agree with you! Jan 03 21:07:38 And the casual redefinition of how it works by the core developers has been a source of frustration as well. At any time, without warning, someone can check in something that can change the entire structure of the build! The "release" model should help that a lot. Jan 03 21:08:50 Indeed. Now they seem to have only "tested" tags which you can use as a base for some work, but then you'll need to forward-port your work anyway, going through all the hurdles again and again. Jan 03 21:11:17 I've been meaning to look into the "layers" functionality to see if that might allow me to "overlay" my set of recipes more easily; would at least save the chore of doing the git work to forward-port all my changes. But of course, the bulk of the work is in testing each time there is a change, and that's the part that suffers. Jan 03 21:20:13 Hello :-) - I am trying to build qtmoko from git and followed the tutorial on the official website. However, when I try to run "../qtmoko/configure -device neo" the "qt"-directory can't be found. It is searching in "qtmoko/qtopiacore/qt" which is a symlink pointing to "../../qt" which is not there. Where does the symlink have to point to? I have a "qt"-directory within my qtcreator-directory which I have installed before. Jan 03 21:43:48 the idea of nessesrity to rebuild world for each induvidual developer suck by design Jan 03 21:44:03 except something really small Jan 03 21:44:21 s/something/for something/ Jan 03 21:44:22 gena2x meant: except for something really small Jan 03 21:45:22 it should be possible to just build package you need, not rebuilding world. everything else should be provided by binaries Jan 03 21:46:01 overwise you just getting into situation where you need to solve build problems for world Jan 03 21:46:12 and waste time rebuilding Jan 03 21:46:30 that's all, simple and easy. Jan 03 21:46:57 If there was stable release of OE one wouldn't have problems building. Jan 03 21:47:21 building is always problem, cause it takes time Jan 03 21:47:38 Come on, even 2 days is ok, who's in a hurry? ;) Jan 03 21:47:46 heh :) Jan 03 21:48:28 OE is not environment friendly :) Jan 03 21:48:48 i mean power consumtion Jan 03 21:55:29 * mwester agrees. Let's all start doing "green coding"., Jan 03 21:55:52 Where's the "rolling my eyes" emoticon? Jan 03 21:56:02 :)) Jan 03 21:56:22 oh, guys working on OE, don't take my words too close. this is not grave problem. i were thinking how it should be ideally done for a while Jan 03 21:56:34 and didn't came to conclusion Jan 03 21:57:27 You're right, though. In general, there's no reason to build all that stuff. I wish the core devs could at least have put up a VMware image of a pre-build OE environment for download. Jan 03 21:57:53 * mwester is planning to do that for the next SlugOS release, which is also an OE-based distro. Jan 03 21:57:56 why vmware? just tar.gz may be ok Jan 03 21:58:14 so at least, you get it, extract and do what you want. Jan 03 21:58:23 VMware eliminates even the problems caused by different host distros and release levels. Jan 03 21:58:42 nonono, vmware is evil Jan 03 21:58:48 Plus, it allows those who are Windows-only to participate. Jan 03 21:59:02 ah Jan 03 21:59:03 Ok, so virtualBox instead of vmware... no diff. Jan 03 21:59:33 no i not mean vmware itself, i mean really virtualisation Jan 03 21:59:44 cause it is just huge dublication of everything Jan 03 22:00:08 need to ssh to it, etc, etc Jan 03 22:00:28 just tar.gz. embedded thing doesn't really need much from host system Jan 03 22:00:45 Ah. So, if I told you that you must use the same distro I develop with in order to participate, you'd be ok with that? (I'm always one or two versions behind on Fedora -- and will NEVER do ubuntu or debian on my desktop because I just don't have the time) Jan 03 22:01:07 of course for guys with windows, just add vmware :) Jan 03 22:01:24 is it really depends so much on host system? Jan 03 22:01:31 I think you might be surprised just how much adverse impact the host can have. Jan 03 22:01:32 what does it need from host? Jan 03 22:02:20 Then chroot should work. Jan 03 22:02:25 ok, may be full chroot for worst cases Jan 03 22:02:30 the biggest problem seems to be auto* tools -- that can kill the build in a hurry. There were some serious disruptions when distros went from gcc3 to gcc4, although that was usually easy to fix -- you had to know to install the gcc3 or various *-compat pacakgtes. Jan 03 22:03:04 A chroot would work, but it's not much smaller than a VM image, and it doesn't work on Windows... Jan 03 22:03:18 I think you can't please everyone. Jan 03 22:03:27 mwester: another problem is programmers who include parts of autofoo in their sources, so instead of working with "autoreconf -i" one has to clean all the unnecessary stuff first. Jan 03 22:03:34 Yep. Jan 03 22:04:04 why host autotools need for devices buildscripts at all? Jan 03 22:04:05 And if you miss some detail by occassion, you end up with strange libtool or whatever problems. :( Jan 03 22:04:19 s/devices/target/ Jan 03 22:04:19 gena2x meant: why host autotools need for target buildscripts at all? Jan 03 22:04:27 So, unclean sources from the devs is the plague of cross-compiling. Jan 03 22:04:41