**** BEGIN LOGGING AT Mon May 02 02:59:57 2011 May 02 05:34:26 mickey|zzZZzz: great, thanks May 02 05:39:28 mickey|zzZZzz: hmm... I need it in gisicomm though :) May 02 05:39:55 anyway... daywork first May 02 06:43:52 If i buy a car worth $2000 off japanese auction (2004 make, 650cc), i'm to pay $3000 to our stupid russian customs! FUCK this world :/ May 02 06:45:27 heh :/ May 02 06:49:01 It's a shame, Japan has plenty of very neat "kei-car" class cars (perfect for a crowded city). May 02 06:54:12 DocScrutinizer: the problem is that if Nokia simply freed up Maemo, it would have required a *lot* of effort to get others on board. with Meego, they got some kind of multi-vendor ecosystem from day one... it's not all about technology, unfortunately May 02 06:55:43 BTW, I don't think it's fair to call Meego a "laptop centric OS". AIUI Intel created Moblin to promote their idea of "mobile internet devices" -- something quite similar to the various "tablet" devices we see today... May 02 06:55:51 it's true though that it wasn't intended for phones May 02 06:56:07 not sure how much of a problem that is May 02 07:05:06 dcordes: lack of professional CS background is not really relevant :-) many good hackers don't have one, or got it only later... May 02 07:44:31 heyho May 02 07:52:45 hey May 02 07:58:23 there is nightly build of SHR images somewhere ? May 02 07:58:44 or recent builds May 02 07:58:53 captainigloo: should be on build.shr-project.org May 02 07:59:50 morphis: thanks :) May 02 08:24:01 SHR: 03Martin.Jansa 07shr-chroot * rbfbd3d121edc 10/ (594 files in 69 dirs): system upgrade May 02 10:22:07 antrik: maybe you and Nokia got a point there, but that would have required way more manpower from Nokia then, not like it's now. And also they effectively managed to leave behind and let down the whole maemo community. Basically Nokia did all they possibly could to kill maemo May 02 10:22:18 and meego May 02 10:25:29 and for Nokia's core competence, I.E. dialer, I still don't see them even give a requirement spec May 02 10:27:22 damn, we don't need Nokia and meego to port a proper linux to any device. We'd need them to contribute with their experience from maemo, which is hildon, dialer, some middleware stuff May 02 10:31:07 honestly what makes meego better than the arm/n900 flavour of errr ubuntu for example May 02 10:31:17 but we need the stuff they freed for meego May 02 10:31:28 for instance ofono May 02 10:31:37 they should have freed that for maemo May 02 10:31:43 we don't need to import them, but we need them as a reference May 02 10:31:44 yes May 02 10:31:58 and ofono is exactly the best example where meego sucks May 02 10:32:13 yes, fsogsmd is better May 02 10:32:44 else we may have migrated to ofono May 02 10:33:07 whole fso is a way better concept May 02 10:33:41 indeed, it "just" need supported hardware to run on May 02 10:33:48 while the middleware of meego is exactly why I call it laptop-centric May 02 10:34:00 indeed May 02 10:34:34 no proper resouce management at all, for instance May 02 10:35:13 lol ouch May 02 10:35:58 again friggin unmanageable pukeaudio which evidently claims to do one thing better than alsa: audio via IP - darn WHF needs that on a phone?? May 02 10:36:19 lol May 02 10:36:40 poettering manages it just fine :) May 02 10:37:06 what does debian use? May 02 10:37:15 fsckng moron lennart manages his own ego just fine May 02 10:37:17 pulse or alsa? May 02 10:37:37 GNUtoo|laptop: in what context? May 02 10:37:52 on om-gta02 May 02 10:38:02 aiui nowadays everbody jumped on the friggin PA train May 02 10:38:27 hehe not on om-gta02 May 02 10:38:32 GNUtoo|laptop: well 'install.sh' does not install pulseaudio but I'm not sure if this is a good indication of anything really May 02 10:38:45 ok May 02 10:38:52 DocScrutinizer: qubes uses pulseaudio too :) May 02 10:39:01 it's an indication for PA not really running on gta0x May 02 10:40:10 DocScrutinizer: qubes has this cool module-vchan-sink that sinks audio over Xen shared memory virtual channel :) May 02 10:40:42 I guess you could implement it with alsa too but it's probably easier in pulseaudio since you only need one virtual channel May 02 10:41:13 wha'ts qubes May 02 10:41:22 this new secure OS that I hype everwhere :P May 02 10:41:39 ah? I never eared of it May 02 10:41:45 GNUtoo|laptop: http://qubes-os.org/ May 02 10:42:11 (beware though, it still has some non-free bits in the default installation) May 02 10:42:20 ouch May 02 10:42:39 but they are not relavant to the core idea so they can easily be removed May 02 10:42:48 ok May 02 10:43:10 why not selinux instead? May 02 10:43:13 (mainly, it has adobe flash as a showcase of how good performance it can offer even though it is secure(TM)(R)) May 02 10:43:20 too much policies to write? May 02 10:43:23 GNUtoo|laptop: selinux does not help against bugs in linux May 02 10:43:35 yes May 02 10:43:42 but it helps with bugs in apps May 02 10:44:12 GNUtoo|laptop: sure but if you control one application you can usually exploit a bug in linux easily May 02 10:44:31 hmmm May 02 10:44:51 GNUtoo|laptop: the core idea of qubes is that they assume that there is always a local root hole in linux that hasn't been patched and/or found yet May 02 10:45:02 ah ok May 02 10:45:16 so it runs a kenrel per vm? May 02 10:45:20 GNUtoo|laptop: yep May 02 10:45:25 ok May 02 10:45:45 and vm per domain ("work", "personal", "random") May 02 10:45:53 ok May 02 10:48:44 well, haha, err, SHR probably still runs *everything* as root May 02 10:49:12 and that will bite your arse one day May 02 10:49:41 indeed but.... May 02 10:49:51 we are now focussing to make it run somewhere recent May 02 10:49:55 qubes does not run everything as root but it has no root password so you can get root easily with su :) May 02 10:49:59 else it would run nowhere May 02 10:50:20 I'm unsure about qubes May 02 10:50:30 I'm sure I don't like either May 02 10:50:31 freedom wise May 02 10:50:54 GNUtoo|laptop: well I'm hyping the concepts and what I see in git May 02 10:51:03 that would make people think: May 02 10:51:13 running flash is not problematic since it runs in a vm May 02 10:52:08 same for s/flash/replace_with_another_proprietary_software/ May 02 10:52:21 GNUtoo|laptop: that thought crossed my mind too May 02 10:53:10 GNUtoo|laptop: but some people already think that May 02 10:53:19 yeah, plus discarding a lower level proven concept for user security for a higher vm concept to make it run. so what protects me *inside* this particular vm? May 02 10:53:32 GNUtoo|laptop: I don't think you should dismiss the whole idea because of what these users of non-free people think May 02 10:54:14 yes it could save us if threats increase but it's dangerous freedom wise May 02 10:54:18 DocScrutinizer: protects what from what? ;) May 02 10:54:43 protects my "private" contact from the flash virus May 02 10:55:19 my "business" contacts are safe, but what with the CURRENT machine, when everybody can gain root easily May 02 10:55:56 DocScrutinizer: you keep your private contacts in a socialVM and run flash in a randomVM :) May 02 10:56:06 lol May 02 10:56:22 DocScrutinizer: everybody can gain root easily? who do you mean? coworkers? May 02 10:56:35 viruses May 02 10:57:19 DocScrutinizer: how does getting root access help the viruses here? May 02 10:57:32 DocScrutinizer: they can read your $HOME as non-root just as well May 02 10:57:39 this concept assumes every OS has security flaws so offensively opens up the hugest hole as an invitation for any malware to infect the particular machine May 02 10:58:51 DocScrutinizer: you might be misunderstanding something, qubes architecture is quite unique May 02 10:58:57 lindi-: a malware can of course access the user files of the user it had infected, but only as root it can do so without you even noticing May 02 10:59:19 DocScrutinizer: you mean hide from process list with kernel module type tricks? May 02 11:00:09 or modify system binaries? May 02 11:01:05 I'm not going to defend the idea of user/root separation here by trying to sketch a working scenario. I'm fine with my knowledge it's a proven concept and I don't want to discard it for a new abstract vm concept May 02 11:02:08 I for one am happy with some of my files are 744 root May 02 11:02:54 and I don't think a virus should have write access to /etc/hosts May 02 11:03:03 DocScrutinizer: well you can add a root password to qubes. they are not changing anything there. they just removed it to state that they don't believe it helps much since linux has these bugs :) May 02 11:03:35 it's pretty unmodified fedora 14 May 02 11:04:38 they also don't offer any support for having more than one user in the system for the same reasons. they target to make it as safe as possible for a single desktop user :) May 02 11:05:11 maemo as well had that idiotic sudo gainroot thing, and first bit I changed been /etc/sudoers to ask for ROOT password May 02 11:05:54 DocScrutinizer: it's trivial to just as an alias for "sudo" that emails me your password :) May 02 11:06:02 s/as/add/ May 02 11:06:02 lindi- meant: DocScrutinizer: it's trivial to just add an alias for "sudo" that emails me your password :) May 02 11:06:05 I'm actually pretty happy with that, as my system now is the only one with that, so no virus will ever have a chance here ;-D May 02 11:06:54 DocScrutinizer: sure. I'm just trying to point out that sudo is pretty bad idea in many usage scenarios May 02 11:07:04 sure May 02 11:07:05 since you can't know what sees your password May 02 11:07:15 i'm never using sudo May 02 11:07:31 you just switch to another virtual console and login as root? May 02 11:08:53 I'm using a script called root that runs on messybox, so it's quite hard for a non-root to fake anything there May 02 11:09:17 your term for scratchbox? May 02 11:09:28 ~messybox May 02 11:09:29 messy... err busybox is meant for lean scripting. Regarding all the missing options and immanent limitations (see su) it's not really the interactive shell of choice. A lot of people hate busybox because a lot of system integrators don't understand the difference between busybox and a decent user interactive shell plus unix utils May 02 11:10:05 DocScrutinizer: how is it difficult for non-root to fake it? May 02 11:11:07 well, I never did a penetration test, but I guess the relevant pathes and files are mostly hardcoded and/or set 744 root May 02 11:11:23 DocScrutinizer: but ptrace can see what you type? May 02 11:11:30 or any x client? May 02 11:11:47 and ptrace can also change PATH of a process on the fly May 02 11:11:50 you'd have to install ptrace first May 02 11:11:55 it's a syscall May 02 11:12:11 errm, you win May 02 11:12:14 yes busybox has some security issues with applets May 02 11:12:22 * DocScrutinizer sips on his first coffee May 02 11:12:48 no separation between applets combined to chmod +s May 02 11:13:10 GNUtoo|laptop: also, I think qubes is one of the first projects that use trusted computing in a nice way :) May 02 11:13:20 ok May 02 11:13:29 still no virus will ever appear to penetrate my unusual system, while there are 10^5..10^6 similar but OPEN systems that don't need such tricks May 02 11:13:50 DocScrutinizer: sure. qubes pretty much assumes a targeted attack against you May 02 11:14:13 it doesn't play with probabilities of an automated attack hitting you specifically May 02 11:14:21 yay, how rogue, and what a honour May 02 11:14:36 heh May 02 11:14:47 but there was a remote root hole in the dhcp client recently May 02 11:15:01 and I think that was the second remote root hole in dhcp client in 5 years May 02 11:15:14 :-o May 02 12:27:10 mrmoku: were my commits to any help of you? May 02 12:27:35 mickey|office: the vapi I added to libgisi (where I need it :) May 02 12:27:48 oh, k May 02 12:27:54 mickey|office: the Pdp.NokiaIsi symbol not known problem still persists May 02 12:28:11 or was the shared data commit about that? May 02 12:28:14 yes May 02 12:28:23 ahh ,ok May 02 12:28:32 ahh... now Ic May 02 12:28:34 :) May 02 12:28:45 I just push the GPDS to the shared data hashtable and can get it from there :) May 02 12:28:47 i did not consider that if A can't see B, then B can't see A either May 02 12:28:55 yeah :) May 02 12:28:56 so we have to do it another way May 02 12:29:01 which is exactly that May 02 12:31:06 mickey|office: for inet_ntop I was wondering what the 3rd parameter is about? May 02 12:33:39 mickey|office: hmm... does it really solve our problem (data sharing) ? May 02 12:34:02 i think so, yes May 02 12:34:06 I can now get a void* from the hashtable but still have no correct type available... May 02 12:34:19 it's a gisicomm type, no? May 02 12:34:30 ahh, right you are :) May 02 12:34:45 the last parameter for inet_ntop is the length of the array May 02 12:35:17 and for convenience the return parameter is exactly what you give as dst May 02 12:35:18 HeinervdmWork: Hi, sflphone-pjproject is still breaking sysroot (changing standard headers originally staged by eglibc), I've found you in git log and also that you talked about the same problem here on IRC, was it resolved somehow or is it known to be broken? May 02 12:35:48 ok May 02 12:36:05 that's why i bound it as a uint8[] May 02 12:45:12 mickey|office: have to pass it with 'out' then? May 02 12:50:26 i don't think so May 02 12:50:43 the caller seems to be responsible for creating the array May 02 12:50:54 that's why you pass the length May 02 12:51:37 (which makes it effectively an in-param) May 02 12:59:19 mickey|office: cmake drives me crazy ... May 02 12:59:47 morphis: welcome to the club... May 02 13:01:22 I can't understand why they make everything so complicated .... all this Find*.cmake scripts ... May 02 13:02:26 morphis: it is not complicated ;) May 02 13:02:37 :) May 02 13:02:49 I am now working on it about 5h ... May 02 13:03:01 just ask me :) May 02 13:03:35 darkh: I am using your cmake files but it don't work as I want it to May 02 13:04:05 what's wrong with it? what doesn't it do what it should? May 02 13:04:42 one moment May 02 13:04:57 it does not detect the qt version correctly May 02 13:06:00 what version does it detect and what should it detect? May 02 13:07:21 note the the Find*.cmake can be rm-ed May 02 13:07:30 in order to make it use the system ones May 02 13:07:38 that is to say the ones that are staged May 02 13:07:44 if I remember well May 02 13:07:46 if those would work May 02 13:08:14 but the ones shipped with cmake does not do the job when used with OE/bitbake May 02 13:09:03 at least they did not for me. seems to be a problem of qmake which is asked by the findqt4.cmake for information about the qt stuff May 02 13:09:34 but qmake seems to point to the native stuff, but we need the target ones May 02 13:10:26 thats why i commented those calls to qmake out May 02 13:12:16 morphis: please more details about the version problems May 02 13:15:48 darkh: you are available late today? May 02 13:15:58 i guess so May 02 13:16:11 why? May 02 13:16:13 as I have to leave now May 02 13:16:20 and catch my train May 02 13:16:52 ok May 02 13:17:41 | -- libshiboken built for Release May 02 13:17:41 | CMake Error at cmake/Macros/FindQt4.cmake:1295 (MESSAGE): May 02 13:17:41 | Qt qmake not found! May 02 13:17:43 so I am off May 02 13:17:45 cya May 02 13:18:02 see you May 02 14:06:20 JaMa: i couldn't find a point in the makefile where those headers are installed May 02 14:06:32 is there a way to remove them after do_install? May 02 14:07:08 like rm in do_install_append() ? May 02 14:07:16 yes May 02 14:07:21 does it work? May 02 14:07:27 yes it should May 02 14:07:49 if you're sure that projects depending on it doesn't need those headers staged May 02 14:08:11 shouldn't do_post_install work too? May 02 14:08:21 otherwise you should move them ie to /usr/include/pjproject and all extra -I to depending packages May 02 14:08:40 * JaMa never heard about do_post_install May 02 14:08:48 i looked into all the makefiles and they aren't installed anywhere... May 02 14:09:12 so i don't know why they are installed May 02 14:10:01 hmm recipe also doesn't seem to install them explicitely, so it has to be from autotools inherit somehow May 02 14:10:04 do_install_append.... had no coffee today -.- May 02 14:10:16 some black magic... May 02 14:10:29 automagic May 02 14:11:17 do you know which files should be removed? because i have no shr-u tree May 02 14:11:30 and in shr-t to many packages are missing May 02 14:16:16 isn't same sflphone-pjproject in shr-t? I'll build it without rm_work on buildhost after current build finishes May 02 14:16:44 no i made the recipe after branching shr-t May 02 14:18:58 ah, right it's not failing in shr-t like it does in shr-u, I thought I've seen it there too May 02 14:39:07 darkh: so I am back May 02 14:39:15 let's see how stable the connection is May 02 14:39:24 darkh: you saw the last lines I wrote? May 02 14:41:51 yes but had no time yet to figure out what the reason is. May 02 14:42:30 I have two recipes May 02 14:42:31 qmake ist not found but i guess you have the native version where it should be May 02 14:42:51 libshiboken_1.0.2.bb and python-pyside_1.0.2.bb May 02 14:43:07 will paste both in a minute May 02 14:43:41 libshiboken_1.0.2.bb: http://pastie.org/1856877 May 02 14:44:13 python-pyside_1.0.2.bb: http://pastie.org/1856879 May 02 14:44:20 both using the same FindQt4.cmake May 02 14:44:29 it's yours May 02 14:44:56 libshiboken compiles fine May 02 14:45:02 python-pyside not May 02 14:45:18 it fails with the error I pasted above May 02 14:45:49 python-pyside has a REQUIRED in the find_package(Qt4 ...), maybe that makes the difference? May 02 14:45:59 cp ${WORKDIR}/MacroPushRequiredVars.cmake ${S}/cmake/Modules/MacroPushRequiredVars.cmake <- how does the cmake files get into the WORKDIR? May 02 14:46:41 with SRC_URI May 02 14:46:43 REQUIRED should not be the problem May 02 14:47:43 ah SRC_URI i see... i usually directly copy those from FILE_DIRNAME May 02 14:49:57 can't see any problems in the recipe yet. i need some coffee and try to get those recipes working on my system in about half an our May 02 14:50:31 but the qmake not found is not completly unkown problem to me May 02 15:11:09 mickey|office: all builds now... but segfaults May 02 15:11:16 #0 0x406d81c4 in g_isi_pep_get_object () from /usr/lib/libgisi.so.0 May 02 15:11:36 will find out a bit later... need a break now :) May 02 15:43:55 hi May 02 15:43:58 root@nokia900 ~ # fsogsmd May 02 15:43:58 Segmentation fault May 02 15:44:51 GNUtoo|laptop: freshly built? May 02 15:45:02 ahh no, did not push yet :P May 02 15:45:22 hmm May 02 15:45:42 yes less than 1 hour ago May 02 15:47:21 GNUtoo|laptop: does your fsogsmd.conf have pdp_type = nokia_isi ? May 02 15:48:07 pdp_type = nokia_isi May 02 15:48:36 I comment it then May 02 15:50:11 still segfaults May 02 15:52:06 HeinervdmOff: here is the list from pjproject http://paste.pocoo.org/show/381608/ May 02 15:53:49 and the ifconfig wlan0 up doesn't work anymore either May 02 15:53:55 on n900 May 02 15:54:01 iliwi and it cannot scan May 02 15:54:01 HeinervdmOff: or in shorter form http://paste.pocoo.org/show/381609/ May 02 16:01:00 GNUtoo|laptop: hmm... strange May 02 16:01:00 GNUtoo|laptop: bt ? May 02 16:02:06 give me some minutes first May 02 16:02:21 ok May 02 16:02:48 JaMa|Off: with new shr-core ist there some variable defined containing the path to kernel build directory or what ever is needed to get modules compiling. In classic OE KERNELDIR did work. May 02 16:11:05 mrmoku, make[1]: Verlasse Verzeichnis '/home/playya/src/git/shr-makefile' May 02 16:11:05 make: *** Keine Regel vorhanden, um das Target »build«, May 02 16:11:18 benötigt von »all«, zu erstellen. Schluss. May 02 16:11:28 darkh: don't know, I was trying to find out while building klibc, but failed to find proper way May 02 16:12:00 :( May 02 16:12:03 mickey|office: it's the first thing it tries to do that fails :P May 02 16:12:04 playya__: use bitbake calls May 02 16:12:27 mickey|office: gdb tells me that fd = socket(PF_PHONET, SOCK_SEQPACKET, 0); does not work out May 02 16:12:29 playya__: if I did understand that LANG=de right :) May 02 16:12:36 yes May 02 16:12:48 i'm on the way home, bbl May 02 16:12:54 i set LANG=c but no success :( May 02 16:13:01 * mrmoku tries to create the PEP later to see if that helps May 02 16:13:52 playya__: http://git.shr-project.org/git/?p=shr-makefile.git;a=commit;h=7bb9ed3d2232a3dddb3626e11ea7c61a3714fb10 May 02 16:14:15 ah. ok May 02 16:16:02 is it possible to get a console without the debug board? May 02 16:16:13 morphis: welcome back May 02 16:19:15 darkh: thx May 02 16:19:25 darkh: I got one step further May 02 16:19:31 really May 02 16:19:44 yes May 02 16:19:56 does the pyqt thing compile? May 02 16:19:57 I added some export and EXTRA_OECMAKE stuff May 02 16:20:05 pyside, not pyqt May 02 16:20:21 (but it's qt for python, yes :) May 02 16:20:56 GNUtoo|laptop: dinner now... bbl May 02 16:21:05 well could you check the pyside recipe... and outcomment those do_generate_toolchain_file_append thing May 02 16:21:14 ok May 02 16:21:39 it prepends the search patch for modules and let cmake probably look for the wrong upatched findqt4.cmake May 02 16:21:59 ah wait it doesn't May 02 16:23:05 morphis: what is still missing now May 02 16:23:37 ok, the current state is: libshiboken compiles fine and don't need qt4 May 02 16:23:44 only python-pyside needs it May 02 16:24:28 thats the current recipe: http://pastie.org/1857196 May 02 16:24:29 and python-pyside does compile now too? May 02 16:24:35 no May 02 16:24:51 it fails within configuration May 02 16:25:00 ah... you did not inherit qt4x11 May 02 16:25:26 this one sets those extra OE_CMAKE stuff May 02 16:25:35 no I don't May 02 16:26:08 but maybe I should do that May 02 16:26:10 so you just copied over the exports from there May 02 16:27:05 well the qt4x11.bbclass sets the path to qmake as you did manually now... should work both May 02 16:27:24 jepp, but then I have to differ between qt4x11 and qt4e May 02 16:27:35 | CMake Error at cmake/Modules/FindQt4.cmake:907 (MESSAGE): May 02 16:27:35 | Could NOT find QtCore. Check May 02 16:27:38 thats what I get now May 02 16:27:42 hm May 02 16:28:06 ah wait i look at my kde4.bblcass May 02 16:28:55 ok May 02 16:30:09 kde4.bbclass defines also some QT variables try these May 02 16:30:23 instead of those you are using now May 02 16:30:52 -DQT_LIBRARY_DIR=${STAGING_TARGET_LIBDIR} <-- especially this one could make a difference May 02 16:31:14 ok, will do that May 02 16:32:09 it seems to be somehow that qmake that tells cmake the wrong paths.. that's why i let cmake look on its own or directly tell cmake where to look May 02 16:32:40 I copied the lines and started a new build .... May 02 16:32:56 * darkh hoping it works now May 02 16:33:53 ok, configuration works now May 02 16:34:00 but compilation fails due to: May 02 16:34:01 | CMake Error at cmake/Modules/FindQt4.cmake:907 (MESSAGE): May 02 16:34:01 | Could NOT find QtCore. Check May 02 16:34:03 äh May 02 16:34:07 | 7a-oe-linux-gnueabi/python-pyside-1.0.2-r0/pyside-qt4.7+1.0.2/libpyside/dynamicqmetaobject.h:27:20: fatal error: Python.h: No such file or directory May 02 16:34:17 so the python deps are missing May 02 16:34:59 hm seems to be a different problem... FindPython.cmake? May 02 16:35:02 jepp May 02 16:35:21 let me take a look at the CMakeLists.txt of pyside May 02 16:36:16 it only checks for the python interperter May 02 16:37:18 "-I/usr/include/shiboken -I/usr/include/python2.6" ... that seems to be wrong too May 02 16:38:24 is this from CMakeLists.txt May 02 16:38:26 ? May 02 16:38:40 it's part of the compilation output May 02 16:39:11 ok... but what does CMakeLists.txt and FindPython.cmake set May 02 16:40:10 I really wonder....maybe we could implement non-root on device where there is a keyboard easily May 02 16:40:12 we need slim May 02 16:40:19 and setting it right May 02 16:40:36 I wonder why shr-settings fails tough May 02 16:40:38 mdbus2 works May 02 16:40:45 *mdbus2 -s May 02 16:42:05 phoneui also doesn't come up May 02 16:42:17 darkh: as far as I understand the build system of pyside it works like the following: libshiboken is build with python as dependency and installs a /usr/lib/cmake/Shiboken*/Shiboken-python26.cmake file which contains the python lib and inc dir May 02 16:42:28 that one is then read by python-pyside May 02 16:42:29 aha was because of enlightenment_start.oe May 02 16:42:41 GNUtoo|laptop: phoneuid needs to get on the system bus and might be configured to not be allowed as non-root May 02 16:42:42 -.- May 02 16:43:08 phoneuid was not laucnhed automatically May 02 16:43:10 that's all May 02 16:43:16 Shiboken-python26.cmake is created by configure_file from Shiboken-python26.cmake.in or similar i guess May 02 16:43:16 launching it manually makes it work May 02 16:43:28 because I bypassed Xsession stuff May 02 16:43:43 the only problem is shr-settings then May 02 16:59:27 * ChristW needs another reboot, but the code seems to work - ish. One bug left. May 02 16:59:34 See ya soon again! May 02 16:59:56 Also, extra rehearsal tonight, so no time tonight to hack :-( May 02 17:00:01 Bye! May 02 17:00:11 bye May 02 17:51:40 mrmoku, is the segfault fixed or do you want a trace? May 02 17:59:41 mrmoku, http://pastie.org/1857488 May 02 18:01:08 http://pastie.org/1857492 May 02 18:02:13 GNUtoo|laptop: ok, then let me push May 02 18:10:09 GNUtoo|laptop: might be enough to rebuild libgisi May 02 18:10:10 freesmartphone.org: 03mok 07libgisi * ra80a25faf37d 10/ (gisicomm/Makefile.am vapi/posix-ext.vapi): May 02 18:10:10 freesmartphone.org: add vapi to extend Posix with inet_ntop May 02 18:10:10 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:10:11 freesmartphone.org: 03mok 07libgisi * rda5153e2743c 10/gisicomm/gisicomm.vala: May 02 18:10:11 freesmartphone.org: gisicomm: GPDP handle context activate indication to get ip/dns May 02 18:10:11 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:10:15 freesmartphone.org: 03mok 07libgisi * rd5ea2c061d62 10/gisicomm/gisicomm.vala: May 02 18:10:15 freesmartphone.org: gisicomm: move creating pep/pipe to GPDS.activate May 02 18:10:15 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:12:30 uint8[Posix.INET_ADDRSTRLEN] dst = null will not work May 02 18:12:59 afaiui the caller is supposed to allocate the buffer May 02 18:13:13 ahh May 02 18:13:26 so how to tell it the length with an uint8[] ? May 02 18:14:00 var foo = new uint8[Posix.INET_ADDRSTRLEN]; May 02 18:14:07 yes May 02 18:14:18 hmm May 02 18:14:42 but maybe the .data trick is more comfortable? May 02 18:15:13 char *addr = alloca(INET_ADDRSTRLEN); May 02 18:15:19 inet_ntop(AF_INET, (const void *)addr_value, addr, INET_ADDRSTRLEN); May 02 18:15:23 is what ofono does in c May 02 18:15:50 mickeyl: btw. there is another missing thing... got register the pdp mediators May 02 18:15:54 +to May 02 18:16:37 looking at the PdpGet/SetCredentials from Msm... that would be what I need for the credentials May 02 18:16:53 reusing those two is name-dirtiness though May 02 18:17:16 ahh... I misread May 02 18:17:26 yeah, the _caller_ is supposed to allocate May 02 18:17:39 ok, will change that to new May 02 18:17:48 playya__: .data trick? May 02 18:18:24 struct foo {int bar; public uint8[] data get {...} May 02 18:19:18 mrmoku: why do you need special set/getcredentials? May 02 18:19:19 use a property as a "cast" May 02 18:19:22 the stock ones should be ok May 02 18:19:33 mickeyl: well it tells me I don't have any May 02 18:19:49 MDBUS2> org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.PDP.GetCredentials May 02 18:19:52 org.freesmartphone.InternalError: Not implemented (yet) for this modem (M:FsoGsmPdpGetCredentials) May 02 18:20:17 so maybe something else is wrong May 02 18:20:41 mickeyl: heyho May 02 18:20:48 playya__: hmm... guess I prefer the 'new' for now :P May 02 18:20:50 no, i think we're zapping the standard mediators May 02 18:20:57 you can reset them May 02 18:20:58 ahh, right May 02 18:21:08 mickeyl: python-pyside is halfway done ... currently trying to fix the last errors together with darkh May 02 18:21:09 i.e. just set the GSM mediators again May 02 18:21:13 morphis: cool May 02 18:21:21 mickeyl: it starts already to compile May 02 18:21:47 nice. still struggling with pyqt here May 02 18:21:50 they changed a ton May 02 18:22:53 ok May 02 18:23:14 just linking fails currerntly due to a wrong path May 02 18:26:19 almost there then May 02 18:32:01 freesmartphone.org: 03mok 07libgisi * r761623803173 10/gisicomm/gisicomm.vala: May 02 18:32:01 freesmartphone.org: gisicomm: allocate dst for inet_ntop with new May 02 18:32:01 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:36:18 freesmartphone.org: 03mok 07cornucopia * rd383773f1d85 10/fsogsmd/src/plugins/modem_nokia_isi/mediators.vala: May 02 18:36:18 freesmartphone.org: fsogsmd: modem_nokia_isi: restore the default mediators for Pdp May 02 18:36:18 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:36:25 freesmartphone.org: 03mok 07cornucopia * rf7b13d4b1ae4 10/fsogsmd/src/plugins/pdp_nokia_isi/ (Makefile.am plugin.vala): May 02 18:36:25 freesmartphone.org: fsogsmd: pdp_nokia_isi: actually activate/deactivate the context via gisicomm May 02 18:36:25 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:36:29 freesmartphone.org: 03mok 07cornucopia * rb3f214a781e9 10/fsogsmd/src/plugins/modem_nokia_isi/channel.vala: May 02 18:36:29 freesmartphone.org: fsogsmd: modem_nokia_isi: use the new DataSharing to deposit the isimodem May 02 18:36:29 freesmartphone.org: This will be used by the pdp plugin to get access to it. May 02 18:36:29 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 18:37:38 good May 02 18:38:08 drumroll now? :) May 02 18:39:24 btw. is it ok if I commit the systemd files to cornucopia? May 02 18:39:27 in moments like this i think Andy Green was right May 02 18:39:42 playya__: init scripts? sure, just put them into appropriate dirs May 02 18:39:51 use fedora? May 02 18:39:51 "you're all nuts, cross compiling is braindead" May 02 18:40:06 ok May 02 18:40:16 considering that i struggled for about 15 hours now w/ the newest PyQt he has a point May 02 18:40:56 yes. but do you have a fast ARM machine for native builds? May 02 18:41:04 yes, my n900 *cough* May 02 18:41:20 pandoboard :) May 02 18:41:28 s/pando/panda/ May 02 18:41:30 playya__ meant: pandaboard :) May 02 18:41:53 we're abandonning oe? May 02 18:42:08 no May 02 18:42:12 ah ok May 02 18:45:35 i wish i could just use the handcrafted configure.py, but that is detecting all those false paths as well so that i can just not use the buildsystem in the first place May 02 18:45:46 mickeyl: what are your problems with pyqt? anything cmake related? May 02 18:46:02 pyqt is not using cmake May 02 18:46:14 it uses qmake with some metabuildsystem on top May 02 18:46:19 crazy stuff May 02 18:46:23 in that case i guess i can't help you :/ May 02 18:46:38 i'm getting along, thanks, it just takes ages since i need full turnarounds May 02 18:46:52 change on variable, recompile everything to see whether it works now. May 02 18:46:56 s/on/one/ May 02 18:46:56 mickeyl meant: change one variable, recompile everything to see whether it works now. May 02 18:47:13 don't ask how long it took to get kde compiling... and all its dependencies May 02 18:47:17 hehe May 02 18:47:17 *nod* May 02 18:47:24 and then on the target funny things like May 02 18:47:26 ImportError: /usr/lib/python2.6/site-packages/PyQt4/QtGui.so: undefined symbol: _ZTI13QPyTextObject May 02 18:47:35 oO May 02 18:47:37 :) May 02 18:48:54 after all it's all just libraries, so i will not see missing code unless i actually try to import it May 02 18:49:18 bbl, tv May 02 18:49:29 monty python? May 02 18:52:45 mickeyl: (drumroll) not yet... building index and wifey just came home May 02 18:52:52 will ping you for the drumroll :) May 02 18:53:29 cat openembedded.bb May 02 18:53:38 RCONFLICTS += "wifey" May 02 18:53:39 ? May 02 18:54:23 more like do_install_append() = { greet wifey } :) May 02 18:54:41 No provider for wifey May 02 18:54:58 yeah... that provider is in my local tree... and will stay there ;) May 02 18:55:17 * mrmoku refuses to push wifey :P May 02 18:56:32 ok May 02 18:56:58 echo *wifey.bb >> .gitignore May 02 18:57:24 lol May 02 18:58:15 I think you can't ignore wifey May 02 18:58:42 but you can prevent to share it with the whole world May 02 19:05:04 "BUENOS AIRES, Argentina - Angry mobs in Argentina have burned train cars in at least three stations after a derailment caused long delays in Monday's commute." :-O May 02 19:14:20 no, ignoring wifey is not possible :P May 02 19:14:27 * mrmoku installs May 02 19:15:39 mickeyl: root@nokia900 ~ # fsogsmd May 02 19:15:40 Aborting due to critical error: May 02 19:15:40 'GLib : fso_framework_abstract_command_queue_enqueueCommand: assertion `self != NULL' failed' May 02 19:15:45 on SetCredentials May 02 19:18:05 ahh... tv May 02 19:19:59 morphis: guess that's why you implemented them for the palm? ^^ May 02 19:24:49 what's the state of 2.6.37 for om-gta02? May 02 19:36:49 gsm does not work iirc (new changes in sysfs paths or wrong kernel config) May 02 19:37:29 * JaMa hoping for smaller patchset for 2.6.39 as some larsc's patches are upstream now May 02 19:37:34 ok :( May 02 19:37:52 but 2.6.39-rc5 doesn't work here May 02 19:38:15 but systemd requires .35 with cgroups, autofs, ... May 02 19:38:19 and no way to debug that without FB driver and debug board May 02 19:39:01 yes May 02 19:42:16 Linux kernel >= 2.6.30 yay. my fault :) May 02 19:58:37 ok, me implements those mediators then... May 02 20:02:00 mv: can't create symlink '/var/volatile/appshadow/0000.desktop': Permission denied May 02 20:02:05 hmmm May 02 20:02:16 it has moved from .e ??? May 02 20:04:50 ahh... it's just the SetCredentials one that is doing var cmd = theModem.createAtCommand( "+CGDCONT" ); May 02 20:04:58 ok, just one to do then :) May 02 20:29:15 mickeyl, did you already started working on cmtspeech alsa backend? May 02 20:37:15 freesmartphone.org: 03mok 07cornucopia * r2d7ffb516c91 10/fsogsmd/src/plugins/modem_nokia_isi/mediators.vala: May 02 20:37:15 freesmartphone.org: fsogsmd: implement IsiPdpSetCredentials May 02 20:37:15 freesmartphone.org: Signed-off-by: Klaus Kurzmann May 02 21:05:37 GNUtoo|laptop: segfault is fixed? May 02 21:05:46 I think so May 02 21:05:51 good May 02 21:06:27 yes it is May 02 21:14:25 * mrmoku off to bed May 02 21:14:27 gnight all May 02 21:49:36 hmm..i need remember to put this channel on auto-login channels :D May 02 22:29:26 lindi-: the concept of qubes is not really all that unique. it's essentially nothing else than the microkernel approach applied consequently. the only difference is that the hypervisor takes extra effort to make the subenvironment look more like a "real" machine... and the virtualisation hype making it look more attractive :-) May 02 22:29:59 there is no reason to believe the isolation offered by the hypervisor is any more robust than that offered by a microkernel; and it's plagued by the same issues that prevented microkernel systems from entering mainstream outside the embedded market May 02 22:30:40 antrik: sure but they already run on real hardware with support for almost all hardware that "normal" gnu/linux supports May 02 22:30:43 having said that, the virtualisation hype *is* a good thing, as after more than a decade of dark ages, finally there is serious interest in operating system research again :-) May 02 22:31:28 antrik: in gnu/hurd I still have the same problem that firefox can see my sudo password if I use sudo from gnome-terminal :) May 02 22:47:25 lindi-: not sure how firefox can see your sudo password; but yes, the Hurd offers a pretty traditional UNIX environment by default. but the mechanisms are there to run more or less isolated subenvironments. it wouldn't take too much effort to add some tools for doing this automatically similar to qubes, if anyone was interested May 02 22:47:50 some other microkernel systems (such as EROS) offer very isolated environments by default May 02 22:48:23 (though at the expense of being very different from a familiar UNIX environment...) **** ENDING LOGGING AT Tue May 03 02:59:58 2011