**** BEGIN LOGGING AT Tue Sep 14 02:59:57 2010 Sep 14 10:54:05 hello Sep 14 10:54:14 does Android work well on the Openmoko? Sep 14 10:54:25 the freerunner* Sep 14 10:54:55 I want a functional phone aswell as some of the freerunner's freedom. Is Android a good bet? Sep 14 10:58:46 or QtMoko maybe? I just thought Android sounds fun because of all the apps Sep 14 11:02:08 android works great Sep 14 11:02:32 could you compare it to the others? is it bad at something? Sep 14 11:03:18 qtmoko is stable but a few apps, it is solid if all you want is a phone Sep 14 11:03:56 shr is a good if you want a linux based device with normal linux apps Sep 14 11:04:22 android is good but you do not have market access, there are third party markets and you can download a lot of apk's directly Sep 14 11:05:19 apk? Sep 14 11:05:53 debian is good if you want free software and packages that conform to a well defined policy :) Sep 14 11:07:29 ringve: qtmoko IS debian Sep 14 11:07:41 gena2x: it doesn't follow the debian policy at all Sep 14 11:07:59 yes, it uses the debian package format but also that only for some binaries Sep 14 11:08:03 how are they all for calling and SMS tho? Sep 14 11:08:35 gena2x: maybe it was more debian in the past Sep 14 11:09:15 ringve an apk is a software package for android Sep 14 11:10:11 we viewing it from different points of view. for me debian is just excellent distribution, easy to use understand and install, and free enought to my current criteria. and very important that it is community driven. Sep 14 11:10:13 gena2x: of course there are different definitions I guess but at least one assumes that in a debian system your binaries are part of some package so that they can be upgraded Sep 14 11:10:24 hehe Sep 14 11:10:45 ok, i can say qtmoko is debian + qt Sep 14 11:10:53 s/qt/qtextended/ Sep 14 11:10:54 gena2x meant: ok, i can say qtextendedmoko is debian + qt Sep 14 11:10:55 gena2x: - copyright information Sep 14 11:11:11 i think qt/extended license is ok? Sep 14 11:11:22 gena2x: + omhacks ripped from git.debian.org and built using custom qtextended buildsystem instead of the debian source package :) Sep 14 11:11:45 gena2x: yep but they don't afaik include the licensing information Sep 14 11:11:57 (probably to save space) Sep 14 11:12:43 hmm. i think as it is (l?)gpl, it is stated somewhere and license is also exist somewhere on fs Sep 14 11:13:40 soo Sep 14 11:13:42 which do i want? Sep 14 11:13:51 ringve: just try em Sep 14 11:14:00 it's not hard and interesting Sep 14 11:14:42 gena2x: "find | grep copyright" does not find anything Sep 14 11:14:57 gena2x: debian policy makes it mandatory for a file named "copyright" to exist for every single package Sep 14 11:15:05 i'll boot it for you after i check my patch finally Sep 14 11:15:42 ok. i personlly do not like separate package system of qtmoko too Sep 14 11:15:43 i think qtopia was lgpl but i'm not sure Sep 14 11:16:24 but for me placement of copyright file is not important :) Sep 14 11:16:43 gena2x: yep but calling something debian usually implies something about quality Sep 14 11:17:03 ah, sure. sorry. Sep 14 11:17:04 gena2x: at best I'd call it a debian derivative Sep 14 11:17:08 nono Sep 14 11:17:20 it also implies that i could add a repo and install the desktop or remove it Sep 14 11:17:26 i'll say debian + qt/extended in future :) Sep 14 11:17:38 dns53: ah, wishful thinking :) Sep 14 11:17:46 sorry meant gena2x Sep 14 11:17:49 but I guess it applies to both Sep 14 11:17:58 hehe Sep 14 11:18:09 ok, i've back to damn toolchain Sep 14 11:18:49 gena2x: yeah the omhacks packaging was somewhat shocking to us: http://paste.debian.net/89642/ Sep 14 11:19:17 thanks, gotta go Sep 14 11:21:55 heh interesting. i can understand you but i agree with radek. hope qtmoko will move to unstable soon and omhacks will be installed via dpkg Sep 14 11:22:49 ok, better say - hope new stable will be released soon :) Sep 14 11:23:05 gena2x: using stable is a good thing but they should have created backports for the new packages instead of dropping binaries to /opt Sep 14 11:50:33 lindi-: qtmoko packaging is just lack of time - it's not that i am not wiling to change it, if someone contributes proper deb packages i am all for using it Sep 14 11:52:41 lindi-: i would be more than happy to do apt-get install qtmoko and have working phone on top of debian Sep 14 11:53:16 radekp: I guess we could provide a backport of omhacks for lenny Sep 14 11:53:33 radekp: we just didn't know there was need Sep 14 11:54:09 radekp: qtmoko stuff is bit complex though? it includes the gsm daemon as well as applications that talk to framebuffer? Sep 14 11:54:33 that would be nice, for me it was just fastest to do qbuild package, but i would be happy to switch to debian package Sep 14 11:55:14 wait, wait guys. qtmoko package already exist Sep 14 11:55:23 not in debian Sep 14 11:55:30 sure, but exist Sep 14 11:55:31 lindi-: i dont think it's daemon - it's more set of libraries + program Sep 14 11:56:00 i think package which cannot build from sources is not very debianish - or am i wrong? Sep 14 11:56:02 radekp: what talks to /dev/ttySAC1? Sep 14 11:56:19 lindi-: qpe application Sep 14 11:56:20 radekp: software needs to be built from source code yes Sep 14 11:56:32 radekp: so we'd need to package qpe first? Sep 14 11:56:50 lindi-: no i think first we need qt for framebuffer Sep 14 11:57:17 lindi-: btw does debian support cross compiling well? Sep 14 11:57:43 radekp: packages can optionally support cross-compiling but they don't need to. all official packages must be built natively Sep 14 11:58:19 lindi-: but how do we handle it? It takes 3 hours to build all from scratch on my Core 2 Duo 2.5Ghz Sep 14 11:59:07 radekp: if it is in debian then debian builds it Sep 14 11:59:18 radekp: or do you mean how would you develop it? Sep 14 11:59:27 lindi-: yes Sep 14 12:00:11 lindi-: i cant imagine that i change something and then i will wait 4 days until my freerunner compiles it Sep 14 12:00:33 radekp: well first of all if something takes 3 hours to build on amd64 you probably want to split it to smaller packages Sep 14 12:00:54 radekp: so that you can work only one package at a time Sep 14 12:01:41 lindi-: but i change the package in the bottom layer? e.g. if i upgrade or cherry pick something to qt... Sep 14 12:02:01 radekp: you need a custom qt? Sep 14 12:02:17 radekp: you need to get that done through the qt maintainers in debian Sep 14 12:02:23 lindi-: i think it's same source code as for QT-x11 but with different configure switches Sep 14 12:03:16 radekp: I'm not sure if another copy of the same source tree will be allowed. it's a lot of work for the security team if an issue is found Sep 14 12:04:37 radekp: what's the upstream source tarball for that qt stuff? Sep 14 12:04:47 (so that I can check it against debian) Sep 14 12:05:39 lindi-: i dont use tarball i use git Sep 14 12:05:59 lindi-: http://github.com/radekp/qt Sep 14 12:06:33 lindi-: i use qt 4.5.3 Sep 14 12:06:41 lindi-: http://github.com/radekp/qt/tree/qtmoko-v18 is the correct source treee Sep 14 12:22:04 radekp: hmm, does github need javascript? ;) Sep 14 12:22:43 lindi-: hmm no idea, but it was using flash for the network graph :) Sep 14 12:22:59 I guess 'git clone http://github.com/radekp/qt.git' should work Sep 14 12:23:32 lindi-: yes that should be ok Sep 14 12:24:12 lindi-: but it's just regular qt git Sep 14 12:24:57 radekp: so why can't qtmoko use regular qt from debian? Sep 14 12:24:58 lindi-: +3 small patches Sep 14 12:25:17 lindi-: because qt in debian runs on X11 Sep 14 12:25:30 radekp: so it is a build option? Sep 14 12:25:36 lindi-: i think so Sep 14 12:25:48 radekp: debian could simply build both versions from the same source package? Sep 14 12:26:01 lindi-: yes Sep 14 12:26:41 lindi-: i dont know if there is similar package in debian - which builds two binaries from the same source code Sep 14 12:26:56 radekp: there are many Sep 14 12:26:59 lindi-: but i dont see any problem why it should not be possible Sep 14 12:27:03 radekp: omhacks for example Sep 14 12:27:07 radekp: is three binary packages Sep 14 12:27:18 radekp: library, development headers and the command line tool Sep 14 12:27:30 all built from the same source package Sep 14 12:28:51 radekp: "qt4-x11" source package says "Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies)." says "Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies)." Sep 14 12:29:01 radekp: but your git has "Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies)." Sep 14 12:29:08 radekp: so you are using an older version? Sep 14 12:30:13 lindi-: yes Sep 14 12:30:29 radekp: does qtmoko work with a newer version? Sep 14 12:30:32 lindi-: i tried to upgrade to 4.6 but there were some bugs Sep 14 12:30:42 lindi-: but probably fixable Sep 14 12:30:46 radekp: could qtmoko just use X11? Sep 14 12:31:57 lindi-: that was already here as OM2007.12 or something like that - it was slow crap Sep 14 12:32:08 OM 2008.12 Sep 14 12:32:59 radekp: if it is stable I'd appreciate it Sep 14 12:33:36 lindi-: it was slow, with many QT patches that were not accepted in upstream QT Sep 14 12:35:17 lindi-: it would be nice to have such option, but it's not for production use Sep 14 12:35:32 lindi-: there was mail from raster explaining why it will never be good Sep 14 12:51:08 radekp: if upstream does not want it then it is very possible debian does not want to maintain it either Sep 14 12:57:59 lindi-: ahh sorry i ment it was not accepted in mainstream QtExteneded Sep 14 13:00:10 lindi-: maybe there were also X11-QT patches QtExtended specific, anyway i think porting qtmoko to X11 is waste of time Sep 14 13:01:06 radekp: is it that different? Sep 14 13:01:51 lindi-: from users POV it does not bring any advantages - it will only eat more memory and it will be slow Sep 14 13:02:34 lindi-: Nokia maintains running QT on framebuffer - so qtmoko on framebuffer is supported project Sep 14 13:02:50 hmm, now away.. Sep 14 13:02:58 lindi-: it works and it's supported Sep 14 13:03:07 but you need to get it to debian first Sep 14 13:03:11 lindi-: qtopia on X11 does not work Sep 14 13:03:17 before any applications that use it can be packaged Sep 14 13:04:02 yes, i think we should take a look at libqt4-X11 packages and see what can be done Sep 14 13:04:35 i can dump configure switches that are used to build qt for framebuffer Sep 14 16:06:44 ahoi Sep 14 16:07:11 hey **** ENDING LOGGING AT Wed Sep 15 02:59:57 2010