| *** taziff has quit IRC | 00:03 | |
| *** taziff has joined #maemo-ssu | 00:10 | |
| *** taziff has quit IRC | 00:15 | |
| *** Estel_ is now known as sdffdsfs | 00:24 | |
| *** sdffdsfs is now known as dgfsdgsdgsd | 00:24 | |
| *** dgfsdgsdgsd is now known as Estel_ | 00:24 | |
| *** taziff has joined #maemo-ssu | 00:27 | |
| *** zeq1 has joined #maemo-ssu | 00:45 | |
| *** arcean_ has joined #maemo-ssu | 00:59 | |
| *** arcean has quit IRC | 01:01 | |
| *** arcean_ is now known as arcean | 01:03 | |
| *** MohammadAG has quit IRC | 01:18 | |
| *** _xnt14 has quit IRC | 01:18 | |
| *** _xnt14 has joined #maemo-ssu | 01:19 | |
| *** taziff1 has joined #maemo-ssu | 01:22 | |
| *** taziff has quit IRC | 01:24 | |
| *** nox- has joined #maemo-ssu | 01:32 | |
| *** zeq1 has quit IRC | 01:50 | |
| *** jonwil has joined #maemo-ssu | 02:20 | |
| *** LaoLang_cool has joined #maemo-ssu | 03:58 | |
| *** amiconn has quit IRC | 04:02 | |
| *** amiconn_ has joined #maemo-ssu | 04:02 | |
| *** amiconn_ is now known as amiconn | 04:02 | |
| *** chem|st has quit IRC | 04:04 | |
| *** chem|st has joined #maemo-ssu | 04:04 | |
| *** LaoLang_coo_ has joined #maemo-ssu | 04:08 | |
| *** LaoLang_cool has quit IRC | 04:11 | |
| *** LinuxCode has quit IRC | 04:14 | |
| *** freemangordon has quit IRC | 04:41 | |
| *** arcean has quit IRC | 04:46 | |
| *** LaoLang_coo_ has quit IRC | 05:18 | |
| *** amiconn has quit IRC | 05:31 | |
| *** amiconn_ has joined #maemo-ssu | 05:31 | |
| *** amiconn_ is now known as amiconn | 05:31 | |
| *** ChanServ has quit IRC | 05:33 | |
| *** ChanServ has joined #maemo-ssu | 05:50 | |
| *** sendak.freenode.net sets mode: +o ChanServ | 05:50 | |
| *** nox- has quit IRC | 06:08 | |
| *** jessi3k3 has joined #maemo-ssu | 06:09 | |
| *** infobot has joined #maemo-ssu | 06:13 | |
| *** ChanServ sets mode: +v infobot | 06:13 | |
| *** taziff1 has quit IRC | 08:07 | |
| *** zeq1 has joined #maemo-ssu | 08:18 | |
| *** freemangordon has joined #maemo-ssu | 08:56 | |
| zeq1 | freemangordon: I've been tracking down the inlines changes that went in for glibc-2.6 to support newer compilers. I'm going to backport the patches. | 09:05 |
|---|---|---|
| jonwil | is there a reason why we cant just use a newer version of glibc as-is? | 09:06 |
| freemangordon | zeq1: well, it is up to you, but if there is no performance difference, what is the point? | 09:06 |
| zeq1 | freemangordon: this will fix ftbfs for quite a few packages | 09:06 |
| freemangordon | ~ftbfs | 09:06 |
| infobot | hmm... ftbfs is "fails to build from source" | 09:06 |
| zeq1 | jonwil: I intend to do that too, but I'm not sure that's even cssu material | 09:07 |
| freemangordon | zeq1: it is | 09:07 |
| freemangordon | zeq1: but before doing any of these, we must have "go on" from maintainers | 09:08 |
| zeq1 | freemangordon: perhaps. cssu-unstable | 09:08 |
| jonwil | yeah cssu-testing seems like a good place to go | 09:08 |
| jonwil | or cssu-devel | 09:08 |
| freemangordon | cssu-devel, for sure | 09:08 |
| jonwil | updating to more recent versions of Maemo packages where it can be done without breaking the binary bits should definatly be a target for cssu IMO | 09:08 |
| zeq1 | yeah, it would effectively mean forked Maemo, a proper continuation of maemo5 | 09:09 |
| freemangordon | zeq1: so far newer toolchain is not discussed with merlin1991, MohammadAG or chem|st | 09:09 |
| jonwil | CSSU is already basically a fork with changes | 09:09 |
| zeq1 | in itself it doesn't break ABI (backwards) | 09:09 |
| jonwil | ... | 09:09 |
| freemangordon | AFAIK | 09:09 |
| zeq1 | but you know people will start to use the new features... | 09:10 |
| freemangordon | zeq1: neither is kernel-cssu, pselect(), etc | 09:10 |
| zeq1 | pselect() is actually a very special case | 09:10 |
| zeq1 | since it's already littered throughout | 09:10 |
| freemangordon | no, it is not | 09:11 |
| zeq1 | the only change is how glibc handles it | 09:11 |
| zeq1 | freemangordon: honestly, it is :) | 09:11 |
| freemangordon | (if i parse correctly your statement) | 09:11 |
| zeq1 | lots of packages already in maemo5 use pselect() | 09:12 |
| zeq1 | it's just glibc doesn't | 09:12 |
| freemangordon | zeq1: maybe you should rephrase, I am not sure I got you "littered" statement correctly :) | 09:12 |
| zeq1 | so those packages that think they are aren't | 09:13 |
| zeq1 | littered == all over the place | 09:13 |
| freemangordon | zeq1: I know the rationale, no need to convince me :P | 09:13 |
| freemangordon | aah, ok | 09:13 |
| zeq1 | What I mean is it's not a new API | 09:14 |
| freemangordon | I was sure I am missing something | 09:14 |
| zeq1 | updating glibc to a new version introduces new APIs | 09:14 |
| zeq1 | they will get used -> ABI breakage | 09:14 |
| freemangordon | well, we already are past that point, Qt 4.7.4 that is | 09:15 |
| zeq1 | I'm not arguing against myself, just making sure I'm clear | 09:15 |
| freemangordon | yeah :). anyway, a discussion with maintainers and the rest of developers must take place first | 09:16 |
| jonwil | yeah | 09:16 |
| zeq1 | I think we should get glibc to a state for "stable" where it can take advantage of newer toolchains | 09:16 |
| zeq1 | AND update glibc (and other infrastructure) going forwards | 09:17 |
| freemangordon | zeq1: my point is that before " ok, guys, lets do it" agreement inside CSSU team, there is no point of doiing it | 09:17 |
| jonwil | yeah | 09:17 |
| jonwil | Lets get agreement from CSSU team and if there is agreement, we keep glibc in stable as is (i.e. dont ship a new glibc in stable) | 09:18 |
| jonwil | but bring newer glibc version into cssu-devel | 09:18 |
| jonwil | and eventually to cssu-testing and then cssu-stable down the track | 09:18 |
| jonwil | same with anything else we can update like glib | 09:18 |
| freemangordon | zeq1: so, that is first to do, that way the whole CSSU team will get involved, etc. | 09:18 |
| zeq1 | sure | 09:19 |
| zeq1 | do we need to call a meeting? | 09:19 |
| jonwil | hmm, I wonder what would be standing in the way of updating the kernel to a newer kernel version, if anything | 09:19 |
| freemangordon | yes, the problem is there is no established way of doing it :D:D:D | 09:19 |
| freemangordon | zeq1: ^^^ | 09:20 |
| zeq1 | jonwil: kernel is tricky | 09:20 |
| zeq1 | we could look into porting kernel from Nemo? | 09:20 |
| jonwil | because? | 09:20 |
| freemangordon | but I will try to ping merlin1991 today, how you guys are with your free time this evening? | 09:20 |
| freemangordon | or maybe a mail to maemo-developers? | 09:21 |
| zeq1 | I'll tell my gf it's important :P | 09:21 |
| freemangordon | jonwil: it is tricky. Of course it does not mean it is impossible | 09:21 |
| freemangordon | but we need to find a good enough reason to do it | 09:21 |
| freemangordon | zeq1: yeah ;) | 09:22 |
| freemangordon | jonwil: a kernel upgrade means a lot of stuff won't work anymore, fcam for example | 09:24 |
| zeq1 | yes, it *will* break kernel module ABI | 09:24 |
| jonwil | stuff can always be ported to the newer kernel without problems AFAIK | 09:25 |
| zeq1 | only stuff with sources | 09:25 |
| jonwil | there are no binary kernel modules on Maemo | 09:26 |
| freemangordon | so, who is to write a mail to maemo-developers? asking CSSU team and whoever is interested to gather this evening. | 09:26 |
| freemangordon | jonwil: besides joikuspot, yes | 09:26 |
| zeq1 | I'm not offically on-team am I? | 09:26 |
| freemangordon | zeq1: well, lets assume you are in | 09:27 |
| freemangordon | I don;t think there will be any objections | 09:27 |
| freemangordon | new developers are always welcome | 09:27 |
| zeq1 | :) | 09:27 |
| zeq1 | I actually need to go fix my mail server(!) | 09:28 |
| zeq1 | some idiot (me) decided it would be a good idea to rebuild my server with gentoo-portage-multilib! | 09:29 |
| freemangordon | zeq1: it should be either me or you, but TBH I would prefer latter, as I am famous with my soft skills and English :D | 09:30 |
| zeq1 | I need to fix my email server first | 09:31 |
| zeq1 | hopefully that won't take long | 09:31 |
| zeq1 | ... | 09:31 |
| freemangordon | if you wish, send the rationale to me, and I will forward to maemo-developers with request for a meeting | 09:31 |
| freemangordon | we are talking about kernel-cssu,pselect and glibc. Do I miss something? | 09:32 |
| zeq1 | I suppose it's generally updating the whole distribution | 09:32 |
| zeq1 | get it tracking debian again | 09:33 |
| freemangordon | well, don't write THAT, there are tender souls around :D:D:D | 09:33 |
| *** Pali has joined #maemo-ssu | 09:33 | |
| freemangordon | aah, Pali, good morning | 09:33 |
| zeq1 | morning Pali | 09:33 |
| freemangordon | Pali: would you read the backscroll for the last ~20 minutes | 09:34 |
| freemangordon | in the meantime: libcurl3 in CSSU seems to work, though its packaging needs some tweaking | 09:36 |
| Pali | new libc: it should go to cssu-devel and if it does not break apps then it could also go to cssu-stable | 09:39 |
| freemangordon | yeah, that is the general idea | 09:40 |
| jonwil | there are too many packages that we cant upgrade due to ties to binaries | 09:40 |
| jonwil | e.g. we cant upgrade PulseAudio at all | 09:40 |
| freemangordon | I suspect gstreamer too | 09:41 |
| jonwil | yeah most likely | 09:41 |
| Pali | for new kernel: I have patches for meego kernel (last from git) to add some maemo specific files... last month I was able to boot it under qemu with maemo image | 09:41 |
| jonwil | gstreamer because of the binary camera bits | 09:41 |
| freemangordon | Pali: are you available this evening? | 09:41 |
| zeq | Pali: I may have not been clear above, to restate: I'm proposing a new cssu glibc with the pselect() kernel support + fixes for building against it with newer toolchains. Separately, updating to new glibc going forwards. | 09:41 |
| Pali | I deleted BME + disabled mounting eMMC (eMMC with new kernel and new qemu does not working) | 09:42 |
| Pali | but on real n900 meego kernel has no problem with eMMC | 09:42 |
| jonwil | I dont think that we need to waste effort backporting stuff to current libc | 09:42 |
| jonwil | we should stick with current libc in cssu-stable | 09:42 |
| jonwil | and just bring in latest libc into cssu-devel | 09:43 |
| Pali | zeq, if new libc does not break anything (or you fix apps which it breaking) I do not care about it | 09:43 |
| zeq | jonwil: trouble is we're already building with new toolchains | 09:43 |
| freemangordon | well,well, lets organize a meeting and discuss then ;) | 09:44 |
| Pali | ok | 09:44 |
| zeq | (cssu release for pselect() doesn't have any downside IMO) | 09:44 |
| freemangordon | Pali: do you have free time this evening for such a meeting? | 09:44 |
| Pali | maybe yes | 09:44 |
| Pali | I will try to find time | 09:44 |
| freemangordon | 7 UTC? | 09:45 |
| Pali | but if it will be only about libc, I'm fine with any solution as written ^^^^ | 09:45 |
| Pali | too late | 09:45 |
| freemangordon | Pali: it will be about lots of stuff, includeing libc, kernel-cssu, new tollchain, etc | 09:46 |
| freemangordon | Pali: when then? | 09:46 |
| freemangordon | 6? | 09:46 |
| Pali | 18:00 UTC should be ok | 09:46 |
| freemangordon | I am ok with 6, but it could be too early for the others. | 09:46 |
| freemangordon | zeq1: jonwil: ^^^ ? | 09:47 |
| zeq | fine for me | 09:47 |
| freemangordon | is that ok for you? | 09:47 |
| jonwil | Is there a reason I need to be in on any of this meeting stuff? | 09:48 |
| freemangordon | only if you wish | 09:48 |
| zeq | jonwil: you seem interested :) | 09:48 |
| freemangordon | yeah | 09:48 |
| jonwil | How many hours from now would that meeting be? | 09:48 |
| Pali | some info about more kernels: we must delete provides from -bootimg packages (bue to apt and HAM), but this brings one problem: if you want to install only u-boot + bootimg package you are not able to install cssu-thumb. My suggestion is to patch flashing scripts which ask if you really want to flash other version of kernel | 09:48 |
| zeq | you've actually been pushing quite hard for replacing the closed bits, which isn't unrelated | 09:48 |
| zeq | jonwil: ^ | 09:49 |
| jonwil | yeah thats true | 09:49 |
| Pali | I have already program which can extract kernel version from kernel zImage | 09:49 |
| jonwil | I am much into closed-bits-repleacement | 09:49 |
| jonwil | so how many hours from now would it be? I am not good with timezones :P | 09:49 |
| Pali | I can add support to detect uboot version | 09:49 |
| freemangordon | Pali: by the time you install u-boot, you will already have at least one kernel-flasher wich provides kernel-feature-... | 09:50 |
| freemangordon | jonwil: I thing about 9 hours from now, correct? | 09:50 |
| freemangordon | *think | 09:50 |
| freemangordon | aah, no, 11 hours | 09:50 |
| freemangordon | Pali: ^^^ ? | 09:51 |
| freemangordon | I am not good too :) | 09:51 |
| zeq | jonwil: UTC is the zero timezone | 09:51 |
| jonwil | ok | 09:51 |
| zeq | so just use your tz adjustment | 09:51 |
| freemangordon | jonwil: which timezone you are | 09:51 |
| freemangordon | ? | 09:51 |
| freemangordon | WEST? | 09:51 |
| Pali | and ask that flashing question only if kernel version string change (eg. from kernel to kernel-power or to kernel-cssu) | 09:51 |
| jonwil | yeah Western Australia | 09:51 |
| zeq | jonwil: already evening there then? :) | 09:52 |
| Pali | my time is: Thu, 02 Aug 2012 08:52:06 +0200 | 09:52 |
| freemangordon | jonwil: try that http://www.worldtimeserver.com/ | 09:52 |
| jonwil | its currently 2pm here | 09:53 |
| Pali | I have some news about lirc kernel driver | 09:53 |
| Pali | original nokia dev now rewriting that driver for upstream kernel | 09:53 |
| freemangordon | great | 09:53 |
| Pali | and he will upstream it | 09:53 |
| Pali | git repo: http://git.itanic.dy.fi/?p=linux-stable;a=shortlog;h=refs/heads/rx51_ir | 09:53 |
| jonwil | lirc is? | 09:53 |
| freemangordon | infrared | 09:53 |
| jonwil | ok | 09:53 |
| freemangordon | iirc | 09:54 |
| jonwil | I didn't know RX-51 had IR | 09:54 |
| freemangordon | WHAT?!? | 09:54 |
| freemangordon | hehe | 09:54 |
| freemangordon | :P | 09:54 |
| zeq | jonwil: UTC +0800 | 09:54 |
| Pali | one big problem in upstream kernel is that there missing camera code | 09:54 |
| freemangordon | too bad, 2 AM | 09:55 |
| jonwil | hey, I have no problems being at a 2am meeting :P | 09:55 |
| freemangordon | great | 09:55 |
| jonwil | I have stayed up to 4am at times doing N900 hacking and work :P | 09:55 |
| freemangordon | Pali: but there were some bits upstreamed iirc | 09:55 |
| Pali | camera not | 09:55 |
| freemangordon | or there was a team preapring it for upstreaming | 09:56 |
| freemangordon | hmm | 09:56 |
| Pali | yes, code is prepaired for 2.6.37+ | 09:56 |
| Pali | but it was not upstreamed | 09:56 |
| Pali | http://elinux.org/N900 | 09:56 |
| zeq | so where did the code go? | 09:56 |
| freemangordon | anyway, zeq, will you write that mail and send it to me, I will forward it to maemo-developers | 09:57 |
| freemangordon | zeq: it is there, but never sent for upstreaming | 09:57 |
| Pali | zeq, code is in meego/nemo 2.6.37+ kernel | 09:57 |
| freemangordon | Pali: btw there was 3.2 branch too iirc | 09:57 |
| Pali | ok | 09:57 |
| freemangordon | including camera | 09:57 |
| Pali | need to ask on omap kernel mailinglist what is problem with upstreaming | 09:58 |
| Pali | also still missing omap_ssi driver | 09:58 |
| Pali | I'm going to write email what is problem with omap_ssi | 09:59 |
| zeq | Pali: is that the only missing driver? | 09:59 |
| Pali | no | 09:59 |
| Pali | see http://elinux.org/N900 | 10:00 |
| freemangordon | GPS too, but there is some code floating over the inet | 10:00 |
| freemangordon | Pali: is charger driver upstreamed? | 10:00 |
| Pali | gps is userspace | 10:00 |
| Pali | not yet | 10:00 |
| freemangordon | hmm, but what was that driver then? | 10:00 |
| freemangordon | GPS I mean | 10:00 |
| jonwil | GPS is all userspace handled through cellular modem | 10:01 |
| Pali | gps is implemented via AF_PHONET | 10:01 |
| jonwil | I actually have the .h file for communication with the GPS parts of the cellular model | 10:01 |
| jonwil | modem | 10:01 |
| freemangordon | there was a kernel module a nokian was trying to upstream | 10:01 |
| Pali | omap_ssi | 10:01 |
| freemangordon | for GPS | 10:01 |
| Pali | omap_ssi is needed for modem | 10:02 |
| Pali | gps should go to gpsd or ofono | 10:02 |
| zeq | no bluetooth? | 10:02 |
| Pali | not to kernel | 10:02 |
| Pali | yes, bluetooth + fm radio missing to | 10:02 |
| zeq | kind of important | 10:02 |
| Pali | I asked nokia devs about it, but they told me that they do not want to upstream it | 10:03 |
| zeq | great | 10:03 |
| zeq | http://svn.jacekowski.org/host_mode/trunk/drivers/media/radio/radio-bcm2048.c | 10:04 |
| Pali | zeq, bluetooth is in meego kernel | 10:04 |
| Pali | and also in that 3.x | 10:04 |
| zeq | ok | 10:04 |
| freemangordon | zeq: did you miss my question re email? | 10:05 |
| zeq | freemangordon: I'll get onto it :) | 10:05 |
| freemangordon | ok | 10:05 |
| freemangordon | lets hope merlin1991 and chem|st are available. It will be good if MohammadAG joins too. | 10:06 |
| zeq | freemangordon: I need your email address :) | 10:33 |
| freemangordon | hmm | 10:33 |
| freemangordon | freemangordon@abv.bg | 10:33 |
| zeq | I just sent you an email from my gmail account | 10:34 |
| freemangordon | ok | 10:34 |
| freemangordon | I will forward it (with additional comments if needed) to maemo-developers and maybe to maemo-community mailinglists | 10:36 |
| zeq | ok :) | 10:37 |
| *** zeq1 has quit IRC | 10:50 | |
| *** jessi3k3 has quit IRC | 11:22 | |
| jon_y | Pali: hey any changes with the uboot/kernel problem last week? | 11:29 |
| Pali | jon_y, I do not remember problem | 11:30 |
| jon_y | boot problems with different hw revisions? | 11:31 |
| jon_y | Pali: wasn't there some sort of off by one issue? | 11:32 |
| Pali | ah, problem that uboot cannot boot kernel... | 11:32 |
| Pali | problem is that I cannot reproduce this problem | 11:32 |
| Pali | so I do not know how to fix it... | 11:32 |
| jon_y | :( | 11:32 |
| jon_y | it'll be awesome if it was fixed with the kp51 release | 11:33 |
| Pali | again, can you describe your problem? | 11:33 |
| jon_y | with uboot loading the kernel, iirc it has problems reading the nand block | 11:34 |
| jon_y | let me see if I can find the error message | 11:34 |
| jon_y | Pali: sorry, pastebin went missing | 11:35 |
| jon_y | if I load the kernel with the flasher, it works, sometimes | 11:35 |
| jon_y | Pali: reminds you of anything? | 11:36 |
| Pali | and only kernel-power not worked or also nokia stock? | 11:37 |
| jon_y | same for nokia stock | 11:37 |
| Pali | do you mean problem with corrupted ubifs? | 11:37 |
| jon_y | well, the ubifs was actually fine if using the recovery image | 11:37 |
| jon_y | the uboot from nokia pr1.3 seems to be unaffected | 11:38 |
| jon_y | well, the nokia uboot | 11:40 |
| freemangordon | ok, mail sent, waiting for the shitstorm :D | 11:40 |
| jon_y | freemangordon: appropriate image macro is prudent :) | 11:41 |
| *** LaoLang_cool has joined #maemo-ssu | 11:47 | |
| *** andre__ has joined #maemo-ssu | 11:49 | |
| *** andre__ has joined #maemo-ssu | 11:49 | |
| freemangordon | merlin1991: ping | 11:50 |
| *** jonwil has quit IRC | 11:53 | |
| *** jonwil has joined #maemo-ssu | 11:54 | |
| *** ChanServ has quit IRC | 12:15 | |
| *** infobot has quit IRC | 12:15 | |
| *** EdLin has quit IRC | 12:15 | |
| *** jonwil has quit IRC | 12:15 | |
| *** LaoLang_cool has quit IRC | 12:15 | |
| *** freemangordon has quit IRC | 12:15 | |
| *** RST38h has quit IRC | 12:15 | |
| *** Estel_ has quit IRC | 12:15 | |
| *** DocScrutinizer has quit IRC | 12:15 | |
| *** ThreeM has quit IRC | 12:15 | |
| *** guly has quit IRC | 12:15 | |
| *** ShadowJK has quit IRC | 12:15 | |
| *** zeq has quit IRC | 12:15 | |
| *** FireFly has quit IRC | 12:15 | |
| *** IronLegend has quit IRC | 12:15 | |
| *** Milhouse has quit IRC | 12:15 | |
| *** Kamping_Kaiser has quit IRC | 12:15 | |
| *** macmaN has quit IRC | 12:15 | |
| *** Sc0rpius has quit IRC | 12:15 | |
| *** tadzik has quit IRC | 12:15 | |
| *** Sicelo has quit IRC | 12:15 | |
| *** amiconn has quit IRC | 12:15 | |
| *** chem|st has quit IRC | 12:15 | |
| *** DocScrutinizer51 has quit IRC | 12:15 | |
| *** ruskie has quit IRC | 12:15 | |
| *** Raimu-Z has quit IRC | 12:15 | |
| *** peetah has quit IRC | 12:15 | |
| *** gregoa has quit IRC | 12:15 | |
| *** Pali has quit IRC | 12:15 | |
| *** wmarone__ has quit IRC | 12:15 | |
| *** jon_y has quit IRC | 12:15 | |
| *** bb8 has quit IRC | 12:15 | |
| *** ZogG has quit IRC | 12:15 | |
| *** _xnt14 has quit IRC | 12:15 | |
| *** chainsawbike has quit IRC | 12:15 | |
| *** xmlich02 has quit IRC | 12:15 | |
| *** jon-kha has quit IRC | 12:15 | |
| *** merlin1991 has quit IRC | 12:15 | |
| *** Raimu has quit IRC | 12:15 | |
| *** X-Fade has quit IRC | 12:15 | |
| *** fisubar has quit IRC | 12:15 | |
| *** rhaamo has quit IRC | 12:15 | |
| *** Lava_Croft has quit IRC | 12:15 | |
| *** kerio has quit IRC | 12:15 | |
| *** DocScrutinizer05 has quit IRC | 12:15 | |
| *** jonwil has joined #maemo-ssu | 12:17 | |
| *** LaoLang_cool has joined #maemo-ssu | 12:17 | |
| *** Pali has joined #maemo-ssu | 12:17 | |
| *** freemangordon has joined #maemo-ssu | 12:17 | |
| *** infobot has joined #maemo-ssu | 12:17 | |
| *** amiconn has joined #maemo-ssu | 12:17 | |
| *** chem|st has joined #maemo-ssu | 12:17 | |
| *** _xnt14 has joined #maemo-ssu | 12:17 | |
| *** Estel_ has joined #maemo-ssu | 12:17 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 12:17 | |
| *** DocScrutinizer has joined #maemo-ssu | 12:17 | |
| *** macmaN has joined #maemo-ssu | 12:17 | |
| *** zeq has joined #maemo-ssu | 12:17 | |
| *** wmarone__ has joined #maemo-ssu | 12:17 | |
| *** Sc0rpius has joined #maemo-ssu | 12:17 | |
| *** jon_y has joined #maemo-ssu | 12:17 | |
| *** EdLin has joined #maemo-ssu | 12:17 | |
| *** tadzik has joined #maemo-ssu | 12:17 | |
| *** ThreeM has joined #maemo-ssu | 12:17 | |
| *** bb8 has joined #maemo-ssu | 12:17 | |
| *** Sicelo has joined #maemo-ssu | 12:17 | |
| *** ZogG has joined #maemo-ssu | 12:17 | |
| *** kerio has joined #maemo-ssu | 12:17 | |
| *** ruskie has joined #maemo-ssu | 12:17 | |
| *** chainsawbike has joined #maemo-ssu | 12:17 | |
| *** IronLegend has joined #maemo-ssu | 12:17 | |
| *** peetah has joined #maemo-ssu | 12:17 | |
| *** xmlich02 has joined #maemo-ssu | 12:17 | |
| *** FireFly has joined #maemo-ssu | 12:17 | |
| *** Kamping_Kaiser has joined #maemo-ssu | 12:17 | |
| *** Milhouse has joined #maemo-ssu | 12:17 | |
| *** DocScrutinizer51 has joined #maemo-ssu | 12:17 | |
| *** Raimu-Z has joined #maemo-ssu | 12:17 | |
| *** gregoa has joined #maemo-ssu | 12:17 | |
| *** Raimu has joined #maemo-ssu | 12:17 | |
| *** merlin1991 has joined #maemo-ssu | 12:17 | |
| *** jon-kha has joined #maemo-ssu | 12:17 | |
| *** Lava_Croft has joined #maemo-ssu | 12:17 | |
| *** rhaamo has joined #maemo-ssu | 12:17 | |
| *** fisubar has joined #maemo-ssu | 12:17 | |
| *** X-Fade has joined #maemo-ssu | 12:17 | |
| *** RST38h has joined #maemo-ssu | 12:17 | |
| *** guly has joined #maemo-ssu | 12:17 | |
| *** ShadowJK has joined #maemo-ssu | 12:17 | |
| *** sendak.freenode.net sets mode: +v infobot | 12:17 | |
| *** LaoLang_cool has quit IRC | 12:26 | |
| *** ChanServ has joined #maemo-ssu | 12:27 | |
| *** sendak.freenode.net sets mode: +o ChanServ | 12:27 | |
| *** LaoLang_cool has joined #maemo-ssu | 12:28 | |
| *** luf has joined #maemo-ssu | 12:35 | |
| *** zeq1 has joined #maemo-ssu | 12:46 | |
| *** arcean has joined #maemo-ssu | 12:54 | |
| *** LaoLang_cool has quit IRC | 12:58 | |
| *** LaoLang_cool has joined #maemo-ssu | 12:58 | |
| *** Pali has quit IRC | 13:00 | |
| *** ivgalvez has joined #maemo-ssu | 13:09 | |
| ivgalvez | freemangordon ping | 13:09 |
| *** Jaffa has joined #maemo-ssu | 13:35 | |
| *** andre__ has quit IRC | 13:37 | |
| freemangordon | ivgalvez: pong | 13:39 |
| *** freemangordon_ has joined #maemo-ssu | 13:43 | |
| *** Pali has joined #maemo-ssu | 13:51 | |
| *** andre__ has joined #maemo-ssu | 13:52 | |
| *** freemangordon_ has quit IRC | 13:54 | |
| *** freemangordon_ has joined #maemo-ssu | 13:56 | |
| *** jonwil has quit IRC | 14:21 | |
| ivgalvez | fremangordon: considering closed source applications that can be potentially broken by system upgrades (kernel, glibc...) | 14:37 |
| *** lizardo has joined #maemo-ssu | 14:37 | |
| ivgalvez | AFAIK, we only have two of them Joikuspot and BlessN900/A Better Camera | 14:37 |
| ivgalvez | the first one has an open source equivalent, in fact a superior solution in Mobile Hotspot | 14:38 |
| ivgalvez | and the latter, as you pointed some time ago, might be violating the GPL | 14:38 |
| ivgalvez | I'll try to reach BleasN900 developer and ask him for sources | 14:39 |
| *** freemangordon_ has quit IRC | 15:03 | |
| *** jonwil has joined #maemo-ssu | 15:05 | |
| *** freemangordon_ has joined #maemo-ssu | 15:06 | |
| freemangordon | ivgalvez: AFAIK BlessN900/ABC work ok with KP/KCSSU, could you elaborate? | 15:07 |
| *** luf has quit IRC | 15:08 | |
| freemangordon | merlin1991: ping | 15:09 |
| ivgalvez | I was referring to the possible case of upgrading KP Mer/Nemo version | 15:15 |
| ivgalvez | with ABI break | 15:15 |
| freemangordon | aah, ok. well, that will happen last, if ever. That is why some discussion about the future is needed | 15:16 |
| freemangordon | aotherwise, besides kernel version upgrade, ABI shouldnot break | 15:16 |
| ivgalvez | OK,the question is that there is not much stuff to break | 15:17 |
| freemangordon | yeah, that is for sure. | 15:20 |
| freemangordon | BTW even BlessN900/ABC should be ok, as (afaik) fcam drivers are foss. are they? | 15:20 |
| ivgalvez | yes for Fcam drivers | 15:21 |
| ivgalvez | but A Better Camera uses dsp for image processing and I don't know if that could be problematic | 15:22 |
| ivgalvez | Do you know if Mer kernel has Vsync support? | 15:23 |
| ivgalvez | that would be a single valid reason to upgrade | 15:23 |
| freemangordon | ivgalvez: we are already on 2.6.37 re DSP (in KP) ;) | 15:23 |
| ivgalvez | great | 15:23 |
| ivgalvez | that shouldn't be a problem then | 15:24 |
| freemangordon | yes, but that is not so simple, the poblem will come with GLES drivers | 15:24 |
| freemangordon | SGX drivers that is | 15:24 |
| ivgalvez | but SGX driver from TI is supporting newer Linux versions | 15:24 |
| *** freemangordon_ has quit IRC | 15:25 | |
| freemangordon | sure, that I am saying is that it is not a trivial task | 15:26 |
| freemangordon | s/that I/what I/ | 15:27 |
| infobot | freemangordon meant: sure, what I am saying is that it is not a trivial task | 15:27 |
| ivgalvez | you make non trivial tasks quite easily ;-) | 15:30 |
| freemangordon | :) | 15:35 |
| freemangordon | wow, arcean cloned h-d today | 15:39 |
| freemangordon | finally, a saturated thumbnails in tasknav | 15:39 |
| * freemangordon is dancing | 15:39 | |
| kerio | huh? | 15:41 |
| kerio | desaturated? | 15:41 |
| freemangordon | yep, when closing an application , the thumbnail will become desaturated;) | 15:45 |
| kerio | ...i don't get it | 15:46 |
| kerio | what? | 15:46 |
| freemangordon | you will see it | 15:46 |
| kerio | when *closing*? | 15:46 |
| freemangordon | it is for good, trust me on that (tm) | 15:46 |
| Raimu | Does it desat even when x is hit when fullscreen? | 15:46 |
| kerio | what about the fact that thumbnails don't respect the blur/desaturation of the rest of the window if you have a dialog window open? | 15:47 |
| Raimu | And then zoomed back to thumbnails? | 15:47 |
| Raimu | freemangordon ^ | 15:47 |
| freemangordon | Raimu: NFC how it works, it is only arcean who knows the details. | 15:47 |
| freemangordon | But that is waht was agreed | 15:47 |
| *** LaoLang_cool has quit IRC | 15:47 | |
| freemangordon | kerio: all that stuff is handled in h-d and mb2, bot are foss | 15:48 |
| freemangordon | *both | 15:48 |
| kerio | yay foss ^___^ | 15:49 |
| freemangordon | if you think somethng does not behave correctly, file a bug | 15:49 |
| freemangordon | ;) | 15:49 |
| kerio | well i just assumed it was intended to make stuff lighter | 15:50 |
| Raimu | freemangordon: Available soon? | 15:51 |
| kerio | Raimu: probably in cssu-freemangordon | 15:53 |
| kerio | also known as cssu-thumb | 15:53 |
| freemangordon | Raimu: ask arcean, not me :) | 15:53 |
| freemangordon | he cloned the repo, does not commit anything ;) | 15:54 |
| zeq | freemangordon: I'll need to update my h-d build :) | 15:55 |
| zeq | btw I've so far had more success building eglibc-2.15 from ubuntu than backporting the needed changes into 2.5. The glibc headers are quite complex... | 15:56 |
| *** freemangordon has quit IRC | 16:20 | |
| Raimu | arcean: Are you of the mindset to make the desat Hildon available soon? ^^^ | 16:24 |
| *** Pali has quit IRC | 17:01 | |
| *** DocScrutinizer05 has quit IRC | 17:08 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 17:08 | |
| *** DocScrutinizer has quit IRC | 17:09 | |
| *** DocScrutinizer has joined #maemo-ssu | 17:09 | |
| *** freemangordon has joined #maemo-ssu | 17:28 | |
| freemangordon | merlin1991: ping | 17:28 |
| *** zeq1 has quit IRC | 17:33 | |
| merlin1991 | freemangordon: pong | 17:39 |
| *** toxaris has joined #maemo-ssu | 18:11 | |
| *** MohammadAG has joined #maemo-ssu | 18:13 | |
| *** toxaris has quit IRC | 18:14 | |
| *** kolp has joined #maemo-ssu | 18:20 | |
| kolp | Hi, just curious, what would be the deal-breaker obstacles when trying to rewrite the N900's phone app? | 18:24 |
| *** Estel_ has quit IRC | 18:29 | |
| *** Estel_ has joined #maemo-ssu | 18:38 | |
| *** taziff has joined #maemo-ssu | 18:47 | |
| *** ivgalvez has quit IRC | 18:51 | |
| *** luf has joined #maemo-ssu | 18:51 | |
| *** NIN101 has joined #maemo-ssu | 18:55 | |
| jonwil | kolp, the biggest problem is understanding all the external things that the phone app talks to including the nightmare that is Telepathy | 18:56 |
| jonwil | The phone app talks to a lot of things on the system, for example there are links I have seen in the browser that I can click on that will open the phone dialer so I can dial that number | 18:57 |
| jonwil | of all the things on the N900, the phone app (and messaging app) are up there on the "this is hard to rewrite" scale | 18:57 |
| kolp | jonwil: Does it use telepathy for ordinary (radio) calls, too? Or just SIP/Skype/etc | 18:58 |
| kolp | jonwil: Yes, I thought so :) | 18:58 |
| jonwil | telepathy for all calls | 18:59 |
| kolp | And both are in the "definitely need replacement" category, too :) | 18:59 |
| kolp | Ok :/ | 18:59 |
| jonwil | The massive binary blob that is Telepathy-Ring is a big part of the problem | 18:59 |
| jonwil | its what handles voice and SMS | 18:59 |
| jonwil | and what talks to the cellular services daemon | 18:59 |
| kolp | re: browser, I'd guess that's just dbus calls to the phone app? | 19:01 |
| jonwil | yes I would imagine so | 19:04 |
| kolp | Ok, thanks for all the info | 19:06 |
| *** arcean has quit IRC | 19:06 | |
| *** andre__ has quit IRC | 19:06 | |
| *** Pali has joined #maemo-ssu | 19:13 | |
| *** Pali has quit IRC | 19:14 | |
| *** arcean has joined #maemo-ssu | 19:14 | |
| amiconn | freemangordon: I am using ABC on KP. It *sort of* works | 19:18 |
| amiconn | First problem is that I sometimes have to start it two or three times until it stays open. Second problem is that in HQ mode and x1 zoom level, trigger delay can be extremely high (about 20..30 seconds (!)) | 19:19 |
| amiconn | Strangely enough this problem vanishes when zooming. I also have fcam drivers installed (and FCamera as well) in case that matters | 19:20 |
| freemangordon | merlin1991: MohammadAG: I hope you have some free time at about 18:00 UTC :) | 19:24 |
| jonwil | 'I will be around for this meeting even though its 2am my time :) | 19:24 |
| freemangordon | yah :) | 19:25 |
| * jonwil still cant decide what N900 work to do next | 19:25 | |
| freemangordon | chem|st: what about you? | 19:25 |
| luf | freemangordon: What do you mean with "libcurl3 in CSSU seems to work, though its packaging needs some tweaking" | 19:26 |
| jonwil | Already ruled out bootloader, kernel, GPU, cell modem, dialer, browser, messaging, telepathy and skype | 19:28 |
| *** mase76 has joined #maemo-ssu | 19:30 | |
| luf | freemangordon: ping | 19:36 |
| freemangordon | luf: pong | 19:36 |
| luf | Can you answer my question few lines above? | 19:37 |
| freemangordon | just a second | 19:37 |
| luf | Ok. | 19:37 |
| freemangordon | luf: for example it is missing dh_clean -k in clean: section of debian/rules | 19:43 |
| freemangordon | also I think source package includes unnecessarry stuff | 19:45 |
| freemangordon | the onther thing is the way pathces are applied, why several quilt push commands? | 19:45 |
| freemangordon | s/onther/other/ | 19:46 |
| infobot | freemangordon meant: the other thing is the way pathces are applied, why several quilt push commands? | 19:46 |
| amiconn | There are more typos... | 19:46 |
| freemangordon | yeah :) | 19:46 |
| luf | freemangordon: because as few changes from debian package as possible. | 19:46 |
| luf | It's the best way to maintain such package. | 19:46 |
| *** mase76 has quit IRC | 19:47 | |
| luf | I don't think it's important to have source as small as possible. | 19:47 |
| freemangordon | luf: I don't know where did you get that debian/ from, but I don't think a missing dh_clean is a good thing | 19:47 |
| merlin1991 | freemangordon: dh_clean is called elsewhere | 19:48 |
| merlin1991 | hm it's a part if install | 19:48 |
| merlin1991 | this package is weird | 19:48 |
| luf | freemangordon: I took debian package from debian wheezy :) | 19:48 |
| freemangordon | merlin1991: fakeroot debian/rules clean does not clean debian[package_name] directories, which is very strange | 19:49 |
| luf | Ok. debian rulez and so is mix of debian package and original maemo package. | 19:49 |
| freemangordon | luf: don't get me wrong, it is not a major problem, that is why i used "tweaking" :) | 19:50 |
| luf | I welcome all comments. It's the way I can improve (curl and myself too). I'm very new to debian packaging. | 19:50 |
| luf | freemangordon: no dh_clean in clean section (debian wheezy package). | 19:51 |
| freemangordon | luf: which debheler version is that? | 19:52 |
| freemangordon | 7? | 19:52 |
| freemangordon | what is in debian/compat? | 19:52 |
| merlin1991 | the wheezy package has debhelper 9 afaik | 19:52 |
| freemangordon | well, that could explain it | 19:53 |
| luf | Yes. merlin1991 lowered it. | 19:53 |
| merlin1991 | luf reworked it for debhelper 7, and I reworked it to debhelper 5 :D | 19:53 |
| freemangordon | good :D | 19:53 |
| merlin1991 | though I didn't make sure that all the commands do what they should do | 19:53 |
| merlin1991 | only that a build is possible :D | 19:53 |
| freemangordon | well, it builds and installs and the most important: works :D | 19:54 |
| freemangordon | though binary is way bigger than stock | 19:54 |
| freemangordon | anyway, i'll look into it these days | 19:55 |
| luf | http://anonscm.debian.org/gitweb/?p=collab-maint/curl.git;a=tree;f=debian;h=eb2c116a48d4e881129a96d1564854e0b416b44b;hb=HEAD | 19:55 |
| freemangordon | to be the next one to rork on it, who knows, maybe I will rework it for debhelper 4 :D | 19:55 |
| * jonwil is bored :( | 19:55 | |
| luf | No you have to rework to debhelper 3 ... you have too keep the line :D | 19:55 |
| zeq | I'm been looking at upgrading debhelper, it's on my TODO list | 19:56 |
| zeq | s/I'm/I've/ | 19:56 |
| infobot | zeq meant: I've been looking at upgrading debhelper, it's on my TODO list | 19:56 |
| luf | There is debhelper 7 in extras ... | 19:56 |
| merlin1991 | zeq: upgrading debhelper is easy | 19:56 |
| zeq | I know | 19:56 |
| merlin1991 | upgrading all packages to use the new features of a newer debhelper, that is not so easy :D | 19:56 |
| luf | freemangordon:what means way bigger? Can you be more precise? | 19:57 |
| freemangordon | luf: lemme check the exact values | 19:57 |
| zeq | It's quite funny with debhelper from various debian dists, the newer packages tend to be written to use the version they install! | 19:59 |
| merlin1991 | afaik debhelper should be backwards compatible | 20:01 |
| freemangordon | luf, cannot get the exact size for stock libcurl3 right now, but from my memory it is about 200k. The one in CSSU when thumb-compiled with gcc 4.7.2 is 220k, which means that ARM-compiled it will be around 280k-300k | 20:02 |
| freemangordon | some new functionality included? | 20:02 |
| luf | Take a look into change log since 7.18 to 7.26 :D | 20:03 |
| freemangordon | yeah, sure :) | 20:04 |
| luf | BTW I can base debian dir for curl on maemo package instead of debian one. | 20:05 |
| freemangordon | merlin1991: you are here around 18:00 UTC? maybe you missed that, but there will be a meeting :P | 20:05 |
| merlin1991 | I'll be here :D | 20:05 |
| freemangordon | merlin1991: you receive mails from maemo-developers, correct? | 20:06 |
| merlin1991 | yes | 20:06 |
| freemangordon | luf: give me a chance to contribute to that, ok? :P | 20:07 |
| luf | freemangordon: Ok. as you wish. | 20:07 |
| *** mr_jrt has joined #maemo-ssu | 20:07 | |
| merlin1991 | luf, freemangordon: I think the current debian rules in our curl package is okish | 20:07 |
| luf | merlin1991: sure you worked on it :D | 20:08 |
| freemangordon | merlin1991: well, ok, if you say so :D | 20:10 |
| merlin1991 | but we can ofc work on it to be better :D | 20:10 |
| freemangordon | BTW does curl use any FP? | 20:12 |
| freemangordon | luf: ^^^ ? | 20:14 |
| merlin1991 | what's the highest signal for kill? | 20:18 |
| merlin1991 | got a rogue java process on my server THAT WON'T DIE | 20:18 |
| zeq | KILL == 9 | 20:19 |
| luf | freemangordon: what is FP? | 20:19 |
| merlin1991 | floating point | 20:19 |
| luf | freemangordon: I have no idea. I didn't study the curl so deep. | 20:20 |
| *** mr_jrt has quit IRC | 20:20 | |
| kerio | merlin1991: define highest | 20:22 |
| kerio | sigusr2 is pretty high, but it's probably not what you want | 20:22 |
| merlin1991 | kerio: something that cannot be caught and equals the kernel using the banhammer | 20:22 |
| kerio | sigkill can't be caught unless you're init | 20:23 |
| kerio | even then, it's just ignored | 20:23 |
| kerio | not exactly caught | 20:23 |
| kerio | surprisingly enough, sigstop also can't be catched | 20:23 |
| kerio | or, rather, you can but only after you cont | 20:23 |
| merlin1991 | and what is sigterm? | 20:23 |
| *** freemangordon has quit IRC | 20:24 | |
| luf | sigterm is for graceful termination of process. | 20:24 |
| luf | So it should be handled by the process. | 20:24 |
| luf | Process is able to run all atexit function (see man atexit). | 20:25 |
| kerio | <merlin1991> kerio: something that cannot be caught and equals the kernel using the banhammer | 20:26 |
| kerio | sigterm is definetely not that | 20:26 |
| *** javispedro has joined #maemo-ssu | 20:26 | |
| merlin1991 | so sigkill is the highest option? | 20:27 |
| *** freemangordon has joined #maemo-ssu | 20:27 | |
| luf | merlin1991: yes. It's the highest option to kill the process. | 20:27 |
| freemangordon | luf, we should check that, as if it uses floating point, the compiler option -mfpu=vfp/neon is missing | 20:29 |
| freemangordon | and AFAIK gcc defaults to -mfpu=none | 20:30 |
| zeq | unless you're using my linaro toolchain | 20:30 |
| luf | freemangordon: I didn't take into my mind to use the best options as N900 has the same HW for everyone. | 20:31 |
| freemangordon | well, afaik it is not CSSU "official" toolchain :P | 20:31 |
| luf | Is there some wiki page with gcc options for N900? | 20:31 |
| freemangordon | luf: those are not n900 options, but Cortex-A8 with vfp and neon | 20:32 |
| freemangordon | luf: nevermind, I will check that | 20:32 |
| luf | freemangordon: can you then send me the result so I can do it better next time? | 20:33 |
| freemangordon | luf: which result? if curl uses FP, then a simple CFLAGS += -mfpu=vfp is pretty enough. But that does not urt even if FP is not usd. | 20:34 |
| freemangordon | *hurt | 20:35 |
| freemangordon | damn typos | 20:35 |
| luf | I think you know more such flags ... | 20:35 |
| freemangordon | you will see the commit ;) | 20:35 |
| luf | Ah sure. | 20:35 |
| freemangordon | BTW ARM options are described in gcc documentation | 20:36 |
| freemangordon | luf: and that was not meant to be "RTFM: :D | 20:37 |
| luf | To be honest I don't want invest my life to reading gcc docs :) | 20:38 |
| zeq | My N900 has taken to forgetting the time on reboot! O_o | 20:38 |
| zeq | The battery was loose previously (that's why I had some trouble the other day) | 20:39 |
| freemangordon | zeq: you have the same problem everyone has (excluding those who changed clock battery with a capacitor) ;) | 20:39 |
| zeq | it used to be okay as long as the battery wasn't removed, now not even that. | 20:40 |
| zeq | I wonder if it's because I pressed the power button in the backupmenu menu? | 20:41 |
| *** ivgalvez has joined #maemo-ssu | 20:44 | |
| jonwil | When does this meeting start? | 20:46 |
| merlin1991 | 15 mins I guess | 20:47 |
| jonwil | ok | 20:48 |
| jonwil | I will be there to put forward my point of view :) | 20:49 |
| kerio | meeting regarding what? | 20:50 |
| *** BCMM has joined #maemo-ssu | 20:50 | |
| zeq | the future | 20:50 |
| freemangordon | the question to the 42 answer ;) | 20:51 |
| *** BCMM has quit IRC | 20:51 | |
| kerio | thumb+kernel-power+linaro | 20:51 |
| freemangordon | you're missing glibc | 20:51 |
| jonwil | maybe I can finally find out if anyone actually cares about my work to e.g. replace wl1251-cal | 20:51 |
| kerio | oh right | 20:51 |
| kerio | thumb+kernel-power+linaro+glibc+openmediaplayer | 20:52 |
| kerio | my .02 on that | 20:52 |
| freemangordon | no OMP, it is a different kind of beer | 20:52 |
| ivgalvez | +worldclock replacement | 20:52 |
| kerio | freemangordon: it's really nice beer! | 20:52 |
| freemangordon | this one too :P | 20:53 |
| freemangordon | ivgalvez: ^^^ | 20:53 |
| kerio | also flash 10 from the internal nokia repo | 20:53 |
| kerio | which i still don't have, btw :( | 20:53 |
| ivgalvez | shhh | 20:53 |
| *** luf has left #maemo-ssu | 20:54 | |
| zeq | flash replacement would be better through a FOSS implementation | 20:56 |
| kerio | ...no it wouldn't | 20:56 |
| freemangordon | zeq: forget about flash, lets make webm work in fennec :P | 20:56 |
| kerio | gnash only gets so far | 20:56 |
| jonwil | if FOSS flash replacements were good enough, everyone would be using Gnash | 20:56 |
| zeq | lightspark exists too... although I do of course agree with freemangordon | 20:57 |
| zeq | :) | 20:57 |
| *** _rd has joined #maemo-ssu | 20:58 | |
| kerio | could we ship jacekowski's modified fmtxd? | 20:58 |
| freemangordon | hmm , where is Pali? | 21:01 |
| zeq | missing :( | 21:01 |
| freemangordon | well, I think he'll join. Soon or later :) | 21:02 |
| zeq | good news is I've build libc now with working inline support | 21:02 |
| zeq | s/build/built/ | 21:02 |
| infobot | zeq meant: good news is I've built libc now with working inline support | 21:02 |
| freemangordon | inline support? | 21:02 |
| freemangordon | you mean libc functions to be inlined? | 21:03 |
| zeq | c89/c99 std inlines | 21:03 |
| *** Pali has joined #maemo-ssu | 21:03 | |
| freemangordon | aah, ok | 21:03 |
| kerio | Pali! | 21:03 |
| kerio | ^_^ | 21:03 |
| freemangordon | zeq: toldya :D | 21:03 |
| zeq | :) | 21:04 |
| kerio | shame, i gotta go in a bit | 21:04 |
| zeq | hi Pali | 21:04 |
| Pali | hi | 21:04 |
| freemangordon | merlin1991: here? | 21:04 |
| * merlin1991 is here | 21:04 | |
| kerio | anyway, my worthless 0.02 on kernel-power+thumb+glibc+linaro sdk+bme replacement | 21:04 |
| kerio | cya guys | 21:04 |
| zeq | bye kerio | 21:04 |
| freemangordon | MohammadAG: arcean: chem|st: DocScrutinizer05: whoever wants: here? | 21:05 |
| freemangordon | aah, doc is on holiday :( | 21:05 |
| freemangordon | now I remember | 21:06 |
| zeq | he said he's keeping his N900 connected ;) | 21:06 |
| freemangordon | merlin1991: shall we start? | 21:06 |
| freemangordon | well, lets try then | 21:06 |
| freemangordon | DocScrutinizer: ping | 21:06 |
| freemangordon | DocScrutinizer51: ping | 21:06 |
| *** Estel_ has quit IRC | 21:07 | |
| *** Estel_ has joined #maemo-ssu | 21:07 | |
| zeq | DocScrutinizer05: ping | 21:07 |
| Pali | try number 42 :-) | 21:07 |
| zeq | It's a shame he isn't here :( | 21:07 |
| Estel_ | hello, is meeting ongoing? | 21:07 |
| zeq | Estel_: just about to start | 21:07 |
| Estel_ | freemangordon, honestly, you could send invitation at least 2 days before ;) | 21:08 |
| Estel_ | DocScrutinizer is on vacation for a week | 21:08 |
| freemangordon | Estel_: usual suspect are here, and I just forgot doc is on a vacation | 21:08 |
| freemangordon | s/suspect/suspects/ | 21:08 |
| infobot | freemangordon meant: Estel_: usual suspects are here, and I just forgot doc is on a vacation | 21:08 |
| * Estel_ nod | 21:08 | |
| Estel_ | I know it wouldn't be much of a loss, but I was able to read invitation 30 seconds ago | 21:09 |
| *** _rd has quit IRC | 21:09 | |
| Estel_ | ;p | 21:09 |
| freemangordon | ususlly he is available all the time, but anyweay we know his position | 21:09 |
| zeq | Glad you made it | 21:09 |
| ivgalvez | unfortunately I'm not going to be able to attend the meeting, but my best wishes are with you all. I'll check the logs later | 21:09 |
| Estel_ | thanks, zeq :) | 21:09 |
| Estel_ | agree with freemangordon. DocScrutinizer position is quite clear, to say at least | 21:09 |
| zeq | yes, certainly regarding -stable | 21:10 |
| zeq | Shall we begin | 21:10 |
| zeq | ? | 21:10 |
| freemangordon | why not | 21:10 |
| ivgalvez | just in case, I support absolutely all opinions from freemangordon | 21:10 |
| ivgalvez | see you | 21:10 |
| freemangordon | ivgalvez: yeah, right :D | 21:10 |
| freemangordon | bb | 21:10 |
| zeq | by ivgalvez | 21:10 |
| zeq | bye | 21:11 |
| *** ivgalvez has quit IRC | 21:11 | |
| freemangordon | merlin1991: here? shall we start? | 21:11 |
| Estel_ | hi ivgalvez | 21:11 |
| Estel_ | bye ivgalvez, lol | 21:11 |
| merlin1991 | still here | 21:11 |
| zeq | shall I start? | 21:11 |
| jonwil | yes lets start | 21:11 |
| freemangordon | ok, I hope everyone has received a mail from maemo-developers | 21:11 |
| freemangordon | with a description of why this meeting is needed/wanted/whatever | 21:12 |
| freemangordon | anyone unaware? | 21:12 |
| merlin1991 | I'll just paste in the points from the mail here: | 21:12 |
| merlin1991 | 1. Inclusion of kernel replacement in CSSU (community kernel) and possibilities of a kernel upgrade to a newer version. | 21:12 |
| merlin1991 | 2. Upgrade of toolchain used to build CSSU stuff. | 21:12 |
| merlin1991 | 3. glibc/kernel pselect() fix and evaluation/planning of glibc upgrade to a newer version. | 21:12 |
| freemangordon | yep | 21:13 |
| freemangordon | now, point one | 21:13 |
| freemangordon | (which is coupled with point 3) | 21:13 |
| Estel_ | it seems to me, that point 3 require point 1 anyway? | 21:13 |
| * Estel_ nods | 21:13 | |
| zeq | yes, kernel must come first | 21:14 |
| Estel_ | in case someone is unaware, zeq, could You explain in "regular folk understandable language" what is the deal with pselect? | 21:14 |
| freemangordon | merlin1991: do you know the pselect() bug we have in libc? | 21:14 |
| merlin1991 | I skimmed the bugreport you posted some time ago, but I'd like a refresh | 21:15 |
| freemangordon | zeq: yeah, could you make a summary? | 21:15 |
| zeq | sure | 21:15 |
| freemangordon | you know that way better than me :) | 21:15 |
| zeq | pselect() is the solution POSIX came up with to implement event loops using select() without races. | 21:16 |
| zeq | it's described here in detail: http://en.wikipedia.org/wiki/Event_loop | 21:16 |
| zeq | the problem is glibc decided, for reasons of POSIX.1 compliance to implement pselect() emulation by using select() | 21:17 |
| zeq | unfortunately this just prevents safe event loops, since the emulation has the same problem that pselect() was intended to fix | 21:18 |
| zeq | once it appeared in glibc, people started using it | 21:19 |
| zeq | even though it was unsafe and relatively low performance | 21:19 |
| Estel_ | it's worth to mention, that zeq was author of ARM patch for it... something like 5 years ago? I'm right, zeq? | 21:20 |
| Estel_ | Am I right, even | 21:20 |
| zeq | Yes, I adapted the support from the other arches | 21:20 |
| zeq | and posted the patch for inclusion | 21:20 |
| zeq | unfortunately it didn't get picked up | 21:20 |
| zeq | but this is getting slightly ahead | 21:20 |
| zeq | the kernel pselect() was the solution intended by POSIX, but the glibc broken implementation forced the kernel devs hand | 21:21 |
| zeq | and they quickly patched most of the arches | 21:21 |
| zeq | ARM got forgotten, the syscalls were allocated but never wired up | 21:22 |
| zeq | at least until recently | 21:22 |
| *** ivgalvez-N900 has joined #maemo-ssu | 21:22 | |
| Estel_ | could You, just for conveinence of everyone reading log afterwards - it means that glibc is using kinda broken emulation, for sake of compliance with *ancient* (as in very ancient) version of posix. zeq, could You explain how this bug affect ends-users? Decreased performance, for sure. Other problems? | 21:22 |
| Estel_ | sorry fro broken order of "could You" :) | 21:23 |
| zeq | I've back ported the code from upstream, it applied pretty cleanly | 21:23 |
| freemangordon | zeq: do you hav elink to the bugreport? | 21:23 |
| zeq | I'll have a look | 21:23 |
| Estel_ | hello ivgalvez-N900, nice that You've made it :) | 21:24 |
| freemangordon | it does noty make sense to repeat it here | 21:24 |
| zeq | "pselect() arm missing" gives lots of hits on google | 21:24 |
| merlin1991 | zeq: so we have a possible race condition in every eventloop we have? | 21:24 |
| ivgalvez-N900 | I'm on the move.... But trying | 21:24 |
| * jonwil feels like he has nothing to contribute... | 21:24 | |
| zeq | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 | 21:24 |
| zeq | merlin1991: yes, that's the bug | 21:25 |
| Estel_ | sure, bug bug report is in technical language (which is ok in itself). Could we just hear a hint about "practical" outcome, re problems, other than decreased performance? (which is huge thing itself, but AFAIK this bug result in other problems too) | 21:25 |
| zeq | It's unknown how often it happens though | 21:25 |
| freemangordon | merlin1991: ...that uses pselect() | 21:25 |
| zeq | Estel_: anything that uses pselect() is at risk of a race condition | 21:26 |
| zeq | this means it can miss signals | 21:26 |
| * Estel_ nods | 21:26 | |
| freemangordon | or deadlock (i.e. hang) | 21:26 |
| Estel_ | claims, like one made by teotwaki, few days ago, that this is ultra-rare possibility of happening, are unjustified? | 21:26 |
| merlin1991 | and in our case where is this broken, the kernel / glibc, both? | 21:27 |
| Estel_ | (it's worth to clear miss-conceptions like that) | 21:27 |
| zeq | it depends how often it's called | 21:27 |
| freemangordon | merlin1991: AIUI both | 21:27 |
| zeq | dbus calls it quite a lot | 21:27 |
| Estel_ | zeq, thanks, this is what I wanted to hear (example of thing used on our devices *very* often, that have high risk of being affected) | 21:27 |
| merlin1991 | Estel_: even if it has a tiny tiny chance of happening, race conditions should *ALWAYS* be fixed | 21:27 |
| Estel_ | merlin1991, agree | 21:27 |
| freemangordon | Estel_: there is another example in the bugreport: udev. Don;t know if it is applicable to maemo udev though | 21:28 |
| Estel_ | I just have in m,ind further readers of logs, and high risk that someone will try to depreciate importance of fix, later, during talks with less experienced users like me. | 21:28 |
| Estel_ | (like teotwaki did few days ago) | 21:29 |
| Estel_ | I think it's important to lert "common folk" know why they need community kernel, too | 21:29 |
| merlin1991 | zeq: what changes are needed to get this fixed? | 21:29 |
| jonwil | ok, so am I needed here or not? :P | 21:29 |
| zeq | merlin1991: I've patched the kernel with missing syscalls (there are two other related syscalls) | 21:29 |
| zeq | and glibc needs to be built with a higher min kernel version | 21:30 |
| zeq | (currently it's built for 2.6.0) | 21:30 |
| freemangordon | jonwil: what? of course you are :). | 21:30 |
| jonwil | ok | 21:30 |
| merlin1991 | so glibc decides to use the workaround at compiletime? | 21:30 |
| jonwil | will hang around then | 21:30 |
| jonwil | for a while anyway | 21:31 |
| zeq | glibc will always use emulation if the min kernel version is below where it *expected* support to appear | 21:31 |
| merlin1991 | and what's that for glibc? | 21:31 |
| zeq | unfortunately it gets that wrong for ARM | 21:31 |
| jonwil | maybe something relevant to me will be discussed :P | 21:31 |
| zeq | jonwil: it will :) | 21:32 |
| zeq | glibc also needs the kernel headers with the syscalls enabled | 21:32 |
| Estel_ | jonwil, your opinion about "what we need to do now" - just like opinion of everyone else interested - is important, even if bug in question isn't thing related to Your expertise | 21:32 |
| zeq | otherwise it silently fails to provide any pselect() at all | 21:32 |
| jonwil | :) | 21:32 |
| freemangordon | jonwil: yes | 21:33 |
| zeq | running a glibc compiled for a supporting kernel on a kernel without the syscalls will fail | 21:33 |
| zeq | so like thumb there is a hard userspace requirement on the kernel version | 21:34 |
| zeq | although it doesn't in anyway affect userspace API | 21:34 |
| zeq | just glibc | 21:34 |
| merlin1991 | so basically we need a patched kernel + recompiled glibc? | 21:35 |
| zeq | yes | 21:35 |
| zeq | patched kernel works fine with unrecompiled glibc though | 21:35 |
| merlin1991 | ofc since it still has select calls | 21:35 |
| zeq | or as well as it ever has | 21:35 |
| kerio | freemangordon: can that be delivered with minor changes to omap1 and abi compatibility with everything else? | 21:36 |
| merlin1991 | glibc is build out of which source package? | 21:36 |
| kerio | if we need to break compat, i vote to do that in the most outrageous way | 21:36 |
| zeq | glibc-2.5.1-1eglibc27+0m6 | 21:36 |
| freemangordon | kerio: we have ABI compatibility in mind | 21:37 |
| freemangordon | kerio: though, could you define ABI compatibility | 21:37 |
| zeq | kerio: ABI breakage is at least limited to glibc | 21:38 |
| Estel_ | kerio, if "will it work with modules from stock, if one flash kernel only" is Your question, then, probably, not | 21:38 |
| Estel_ | of course I mean kernel modules from stock, not 3rd party ones | 21:38 |
| zeq | DocScrutinizer would possibly argue that point | 21:38 |
| freemangordon | well, we have enough expertise here to evaluate | 21:38 |
| Estel_ | although, it's worht to mention that no real-life usage, in any case, include flashing new kernel without installing it's modules | 21:38 |
| Estel_ | i.e. such situation is purely theoretical, just for sake of doing so, no practical problems risk, ever. 0% chance. | 21:39 |
| merlin1991 | zeq: if you backport the kernel changes ontop of the maemo stock kernel can that one still load 3rd party modules compiled for the original kernel? | 21:39 |
| Estel_ | (from my limited knowledge common folk POV, feel free to correct) | 21:39 |
| ivgalvez-N900 | Estel_ that's right | 21:39 |
| zeq | merlin1991: it doesn't break ABI | 21:39 |
| zeq | since the syscalls are reserved | 21:40 |
| Pali | merlin1991, depends on what you change... | 21:40 |
| Estel_ | merlin1991, agaik, even latest kernel-power-thumb can load 3rd party modules, like fcam or joikuspot | 21:40 |
| freemangordon | :nod: | 21:40 |
| Estel_ | we're not aware of other such modules in existence | 21:40 |
| merlin1991 | well i'm thinkin in terms of -stable atm where if anything we apply a small patchset ontop of the stock kernel | 21:40 |
| Estel_ | problem with 3rd party modules was *always* purely theoretical one. I.e. "there may exist, in some ancient vault, a module compiled in 3000 before christ..." | 21:41 |
| freemangordon | merlin1991: CSSU did it once | 21:41 |
| merlin1991 | freemangordon: I'm not sure I know what you mean | 21:41 |
| freemangordon | Qt, remember? It was upgraded for good | 21:41 |
| Pali | also depends on compiler and linker. if they decide to glue object code together with some symbols on other address it can break modules too... | 21:41 |
| Pali | but I think gcc is deterministic | 21:42 |
| freemangordon | Pali: yeah, but we know gcc does not do that. at least in SB | 21:42 |
| freemangordon | BTW if we don't change exported symbols (or just add new), we should be safe | 21:43 |
| Estel_ | now the logical question to merlin1991, if audience doesn't mind. I understand wish to do minimalistic patchset for -stable, and i know rationale behind it. But, considering that we need Community Kernel and upgraded glib anyway, why not benefit from it fully - without drawbacks - by including thumb2 patchset too, and benefit memory + speed advantages? (the latter from upgraded compiler) | 21:43 |
| Pali | if 3rd modules using symbols and not direct address, then it should be ok | 21:43 |
| merlin1991 | Estel_: quite simply, because thumb2 requires an upgraded toolchain which is a nogo | 21:44 |
| Estel_ | for now, few dozens - if not more - users have cssu-thumb on their everyday use devices, without slightest problems. CSSu used to create more glitches in -testing versions, than cssu-thumb ever did. | 21:44 |
| zeq | upgraded compiler implication we'll be getting to | 21:44 |
| ivgalvez-N900 | Well the upgrade of Qt broke LinkedUp (focus lost) and it was never fixed | 21:44 |
| Pali | but other question is: how many 3rd kernel modules we have on maemo? | 21:44 |
| ivgalvez-N900 | Not a big deal | 21:44 |
| Estel_ | Pali, namely, two modules :P | 21:44 |
| freemangordon | Estel_: thats next point in agende, lets move on with the current | 21:44 |
| Pali | and how many kernel modules are closed? | 21:45 |
| Estel_ | joikuspot, that have BETTER FOSS replacement qtmobilehotspot (and joikuspot works anyway, even with kernel-power)... | 21:45 |
| Estel_ | closed one | 21:45 |
| freemangordon | ABC has one | 21:45 |
| merlin1991 | zeq: what kind of patch for the kernel do you have currently? | 21:45 |
| Estel_ | and fcam, which works, even with KP, and is open | 21:45 |
| Pali | joikuspot kernel module is GPL - it can be recompiled | 21:45 |
| Estel_ | oh, sorry then | 21:45 |
| merlin1991 | zeq: meaning based on which version? | 21:45 |
| Pali | and fcam is also open (correct me if not) | 21:45 |
| Estel_ | freemangordon, zeq, understood (about next point) | 21:45 |
| freemangordon | Pali: yes, afaik | 21:46 |
| zeq | merlin1991: I directly applied the version that went upstream | 21:46 |
| Estel_ | Pali, fcam is absolutely open | 21:46 |
| zeq | straight from git | 21:46 |
| freemangordon | zeq: so it is upstreamed after all? | 21:46 |
| zeq | long after 2.6.28 though | 21:46 |
| freemangordon | aah, yes, noe I remember, it was 2.6.30 or something | 21:47 |
| freemangordon | now even | 21:47 |
| Estel_ | ...which is another argument confirming it's importance (inclusion in upstream) | 21:48 |
| freemangordon | Estel_: I don;t think anyone argues whether it is important or not ;) | 21:48 |
| merlin1991 | zeq: so basically we have to recompile glibc with proper kernel headers, have it depend on kernel-feature-pselect and provide a patched kernel? | 21:48 |
| zeq | yes, or whatever virtual dep we choose | 21:49 |
| Estel_ | freemangordon, some people on IRC - otherwise respectable, like teotwaki - tried, that is why i'm highlighting it. It's kinda dumb to argue with upstream. | 21:49 |
| Estel_ | most of the times | 21:49 |
| zeq | calling it pselect is probably misleading since it provides 3 syscalls - somthing for later | 21:49 |
| merlin1991 | well as far as I see glibc depends only on pselect, the kernel ofc can provide a feature for each syscall | 21:50 |
| Estel_ | so, gentlemans, do we have any concerns about this point? someone wantg to present opposite arguments? Or are we trying to convince already convinced people? :) | 21:50 |
| freemangordon | Estel_: it is discussion if how to be done AIUI | 21:50 |
| freemangordon | *if and how | 21:51 |
| zeq | One issue is risk of somebody upgrading userspace without kernel | 21:51 |
| freemangordon | zeq: would you elaborate? | 21:51 |
| zeq | or without flashing kernel | 21:51 |
| freemangordon | zeq: no way if it comes as part of CSSU | 21:52 |
| zeq | booting on stock kernel with new glibc would have *really* broken pselect()! | 21:52 |
| zeq | true, as long as people use HAM | 21:52 |
| zeq | :) | 21:52 |
| merlin1991 | well the only way this can happen is with uboot / multiboot | 21:52 |
| Estel_ | or FAM with brain | 21:52 |
| Estel_ | but it was always thing about CSSU | 21:52 |
| merlin1991 | zeq even with fam / apt-get the dependency should be resolved | 21:52 |
| Estel_ | i.e. "use ham" rule | 21:52 |
| merlin1991 | the only thing we can't do is have the provides on the bootimg | 21:52 |
| zeq | I'm just playing devils advocate :) | 21:53 |
| freemangordon | :nod: | 21:53 |
| Estel_ | merlin1991, could you elaborate? I use multiboot kernel-power, which provides thumb-errata-workarounds, and it's "provides" satisfied cssu-thumb fork | 21:53 |
| Estel_ | i.e. I don't have kernel-power-flasher installed at all | 21:53 |
| Estel_ | what's the deal about "Provides" in bootimg? | 21:53 |
| merlin1991 | Estel_: the problem is that ham fam and apt-get decide multiboot img is enough EVEN if you're not using multiboot | 21:54 |
| Pali | we can create (static linked) program which will be called in /sbin/preinit to show dangerous message | 21:54 |
| merlin1991 | so you end up with a binary for the right kernel on your fs, but still the wrong kernel flashed as regular user | 21:54 |
| Estel_ | merlin1991, understood, but deleting "provides" won't break compatibility for people like me? | 21:54 |
| freemangordon | Pali: if we put a kernel in cssu, it MUST be called just that, "kernel" | 21:54 |
| merlin1991 | Estel_: *people like you* will have to go deeper to run this | 21:54 |
| freemangordon | merlin1991: I don;t think a regular user can downgrade the kernel | 21:55 |
| Pali | so it will not be kernel-cssu but kernel package? | 21:55 |
| Estel_ | merlin1991, i.e. in my case, what should "Provide" kernel-feature-errata-workaround", if not bootimg? | 21:55 |
| merlin1991 | an extra package that is empty that you install via dpkg because you know what you do | 21:55 |
| freemangordon | Pali: I am starting to think that way will be best | 21:55 |
| Pali | we must remove all Provides from bootimg packages | 21:55 |
| Estel_ | merlin1991, honestly, it's kinda creating a PITA situation. If someone use bootimg, he already got "deeper" enough to use multiboot or u-boot | 21:55 |
| Estel_ | merlin1991, as long as such extra empty package will be available from repositories, i'm ok with it | 21:56 |
| Estel_ | (not that I can't install it manually, but why create PITA for multiboot/u-boot users :) ) | 21:56 |
| merlin1991 | Estel_: again it can't be in the repositories becaus then apt/fam/ham will again pick it up | 21:56 |
| Pali | with uboot I have one problem: if I have uboot installed and want to update kernel-flasher it will remove uboot from nand | 21:56 |
| Estel_ | I still think that bootimg "Provides" is msot convenient, and deleting it is overcare, but as said, i'm ok with any way, that have required bits in repos | 21:56 |
| freemangordon | Estel_: no, because apt is FUBAR | 21:57 |
| Pali | I'm suggesting to patch fiasco-image-update to ask if you really want to flash new image (patch will be in new deb package) | 21:57 |
| freemangordon | Pali: but then you risk to boot u-boot default image without modules | 21:57 |
| Estel_ | freemangordon, so IMO best way is to leave Provides in place, and stop treating bootimg users as idiots, that doesn't have multiboot/u-boot | 21:57 |
| merlin1991 | Estel_: I'm prepared to create a PITA for every uboot/multiboot user to fix the 100% chance of fucking up every non users device on upgrade | 21:58 |
| Pali | freemangordon, if you have uboot you have also bootimg packages | 21:58 |
| Estel_ | merlin1991, could You elaborate hyphotetical situation, when someone could be affected? | 21:58 |
| Estel_ | you know, real life one? | 21:58 |
| Pali | and is better to not overwrite uboot | 21:58 |
| merlin1991 | quite easy | 21:58 |
| Estel_ | not theoretical as in theoretical 3rd party module incompatible? | 21:58 |
| merlin1991 | we create the fancy kernel + glibc in stable | 21:58 |
| * Estel_ nods | 21:58 | |
| merlin1991 | $average user does the upgrade -> ham decides uh I need glibc and I need this kernel feature --> bootimg is installed since it provides but stock kernel is still flashed | 21:59 |
| freemangordon | :nod: | 21:59 |
| Estel_ | ok, but why assuming someone have bootimg without multiboot/u-boot? | 21:59 |
| Estel_ | any other use for bootimg? | 21:59 |
| merlin1991 | nope | 21:59 |
| merlin1991 | but that's what you get | 21:59 |
| freemangordon | Estel_: HAM pulls it | 21:59 |
| merlin1991 | 10 times out of 10 | 21:59 |
| Estel_ | I see. | 21:59 |
| freemangordon | and that is what happened in early cssu-thumb days | 22:00 |
| freemangordon | yoiu may want to check the thread | 22:00 |
| Estel_ | ok, so why it doesn't happen now, when someone installs cssu-thumb? | 22:00 |
| Estel_ | kernel-cssu is pulled, not kernel-power-bootimg | 22:00 |
| merlin1991 | I think atm cssu-thumb depends on the flasher | 22:00 |
| Estel_ | no, it doesn't | 22:00 |
| freemangordon | because you have a hard dependency to flasher | 22:00 |
| Pali | because cssu-thumb depends on -flasher package | 22:00 |
| Estel_ | I have cssu-thumb and no flasher | 22:00 |
| Estel_ | wut? | 22:00 |
| freemangordon | and provides: is remnoved from bootimage | 22:01 |
| freemangordon | you have KP 51 flasher | 22:01 |
| Estel_ | i have bootimage, latest, that still provides, and i don't have flasher. Used fapman | 22:01 |
| Estel_ | ok | 22:01 |
| Estel_ | understood | 22:01 |
| Estel_ | I know how it happened, and agree to Your rational;e | 22:01 |
| freemangordon | Estel_: does not matter what you have, I think me and merlin1991make it clear | 22:01 |
| Pali | kp51 bootimg still provides thumb | 22:01 |
| freemangordon | *made | 22:01 |
| Estel_ | freemangordon, see ^^ :) | 22:02 |
| Estel_ | but anyway, I understand rationale | 22:02 |
| Estel_ | not convenient, but understood why needed. | 22:02 |
| freemangordon | Pali: I know, that is why I followed your advise | 22:02 |
| freemangordon | (cssu-flasher || power-flasher) :P | 22:02 |
| Estel_ | last question - so can't next cssu that will contain community kernel have hard dependency to flasher, too? | 22:02 |
| freemangordon | s/||/|/ | 22:02 |
| infobot | freemangordon meant: (cssu-flasher | power-flasher) :P | 22:02 |
| Pali | yes, I will remove all provides from -bootimg package, but first maemo.org must working... | 22:02 |
| Estel_ | Pali, so for bootimg, You will always release also a empty package that provides, available from download link on tmo thread? i'm asking about practical usage | 22:03 |
| freemangordon | Estel_: no, as we'll not be able to flash KP, without removing -mp | 22:03 |
| Estel_ | freemangordon, good point. Everything understood now. | 22:04 |
| freemangordon | so, back to topick | 22:04 |
| Pali | Estel_, If you want that package I can create it and send you by email... | 22:04 |
| Estel_ | Pali, I'm not thinking about myself only | 22:04 |
| Estel_ | I think about multiboot users as whole | 22:04 |
| Estel_ | would be nice to provide them package as downloadable link, at least | 22:04 |
| Pali | multiboot does not have problem with -flasher packages | 22:05 |
| Estel_ | as for me, i can create ampty package which provides what bootimg provides now (not convenient, but doable). There may be some, that don't feel comfortable with it, though | 22:05 |
| freemangordon | Estel_: lets get back to kernel/glibc,ok? | 22:05 |
| Pali | multiboot flashing kernel when n900 starting | 22:05 |
| Estel_ | freemangordon, sure, but I think we're talking about practical outcome too, yep? | 22:05 |
| zeq | anybody else have objections, comments questions? | 22:05 |
| Estel_ | Pali, sure, but we need to have something that provides, for example, kernel-feature-thumb-errata, to satisfy dependencies. | 22:06 |
| freemangordon | Estel_: and that is the flasher, no matter what is currently flashed on NAND | 22:06 |
| Pali | Estel_, provides are still in -flasher package | 22:06 |
| Estel_ | merlin1991 said about need for people like me to install empty package which provides it. Is it a problem to give link for such package, on forum, alongside every new bootimg update? | 22:07 |
| Estel_ | freemangordon, understood | 22:07 |
| Pali | and you can install both bootimg and flasher without problem | 22:07 |
| Estel_ | I though empty package, as mentioned by merlin1991 is mandatory | 22:07 |
| Estel_ | ok, ok ,everything clear now | 22:07 |
| Estel_ | so it's not PITA after all | 22:07 |
| freemangordon | Estel_: we'll find a way to do it, breath | 22:07 |
| Estel_ | yes, it's clear now, and I hope that it's going to give a breath for multiboot users reading logs later :) we can continue now | 22:08 |
| freemangordon | merlin1991: now the hard part. I assume you want omap1 with just a minimum pathces, right? | 22:08 |
| freemangordon | *patches | 22:08 |
| merlin1991 | yes | 22:08 |
| merlin1991 | for -stable at least | 22:09 |
| zeq | merlin1991: so just the syscalls patch? | 22:09 |
| merlin1991 | basically yes | 22:09 |
| freemangordon | merlin1991: hmm, am I missing something? not 1 but 2 kernels? | 22:09 |
| freemangordon | zeq: merlin1991 has a point here | 22:10 |
| merlin1991 | unless we find some other really important patch for the stock kernel | 22:10 |
| zeq | other than thumb :P | 22:10 |
| freemangordon | merlin1991: we already have a CVE | 22:10 |
| Estel_ | also called thumb :) BTw, why upgraded toolchain is a no-go? | 22:10 |
| freemangordon | Estel_: please, hold on for a while | 22:10 |
| Estel_ | no problem | 22:11 |
| freemangordon | merlin1991: there is a CVE to be fixed in omap1, and we have a bug report for it | 22:11 |
| merlin1991 | that one would be valid | 22:11 |
| freemangordon | yeah, we have it in the tasklist :P | 22:11 |
| freemangordon | lemme find it | 22:12 |
| freemangordon | https://bugs.maemo.org/12558 | 22:12 |
| povbot | Bug 12558: kernel/bluetooth: CVE-2010-1084: potential bad memory access with sysfs files | 22:12 |
| *** ivgalvez-N900 has quit IRC | 22:13 | |
| freemangordon | merlin1991: would you elaborate an why kernel in CSSU should be omap1 with some cosmethics instead of KP with some stuf stripped if needed? | 22:14 |
| merlin1991 | the time needed to decide what to strip, I think it's easier if we just backport 1 patch instead of going everything else | 22:15 |
| merlin1991 | s/going/going over/ | 22:15 |
| infobot | merlin1991 meant: the time needed to decide what to strip, I think it's easier if we just backport 1 patch instead of going over everything else | 22:15 |
| freemangordon | hmm, KP has about 20-30 .patch files, I don;t think it is so hard to check them. Pali, agree? | 22:16 |
| Estel_ | and I think that it's worth to use full potential where applicable, instead of going lazy and minimalistic, just for sake of it. | 22:16 |
| Pali | 85 patches are in kernel-power | 22:17 |
| freemangordon | wow | 22:17 |
| Estel_ | most of them upstream fixes/backports ;) | 22:17 |
| Pali | s/85/85-9/ | 22:17 |
| infobot | Pali meant: 85-9 patches are in kernel-power | 22:17 |
| freemangordon | well, some of them like compcache are easy to be decided. And well quite lot are upstream backports | 22:18 |
| merlin1991 | well we have the option to go over all the patches aswell but I probably wont have the time for that till | 22:19 |
| merlin1991 | +september | 22:19 |
| freemangordon | merlin1991: the reason KP exists is that omap1 is not enough | 22:19 |
| jonwil | can't stay much longer, too tired. Plus, nothing interesting is being discussed :P | 22:20 |
| freemangordon | if we decide to not use KP, most of the CSSU users (testing) will just flash KP right after CSSU update | 22:20 |
| merlin1991 | lemme rephrase that, kp exists because omap1 is not enough for everyone | 22:20 |
| Estel_ | merlin1991, do you have lack of trust in Pali or freemangordon, that You need to go through every patch yourself? | 22:20 |
| freemangordon | Estel_: not all of the patches are made by me and Pali | 22:20 |
| Estel_ | merlin1991, let me rephrase it - kp exist, because omap1 is not enough for 99,99% of users | 22:20 |
| freemangordon | Pali: what do you think? | 22:21 |
| Estel_ | freemangordon, yes, but they're reviewed by kp maintainers (who are also part of cSSU team) and constantly tested by dozens of users | 22:21 |
| Estel_ | and by dozens I mean at least same ammount that test CSSU, if not more | 22:21 |
| freemangordon | Estel_: it has nothing to do with the trust | 22:21 |
| Pali | I do not know what should go to -stable... I'm not user of cssu-stable and I will still use kernel-power... | 22:22 |
| Estel_ | freemangordon, you missed my point. I mean that merlin1991 doesn't need to be sole person going through patches | 22:22 |
| merlin1991 | Estel_: I have no trust issues, I run KP myself on a few devices | 22:22 |
| Estel_ | I think that you or Pali or other knowledgeable cssu team people casn help him | 22:22 |
| Estel_ | no, no, you got me wrong | 22:22 |
| Estel_ | see ^^ | 22:22 |
| merlin1991 | well I don't mean go through them from a technical perspective | 22:22 |
| Estel_ | it's overkill to have 1 person going through ~90 patches | 22:22 |
| Estel_ | sure, but Your concern was a time required - I think teams are to make that easier :) | 22:23 |
| freemangordon | merlin1991: see? which kernel you will use on your "production" device? | 22:23 |
| freemangordon | (assuming you still use n900 as everyday device) | 22:23 |
| merlin1991 | my production device is a n9 | 22:24 |
| jonwil | ok, I dont care so much about libc stuff or most of this kernel stuff, do I actually need to be here? Will something more relevant to me be discussed soon? | 22:24 |
| merlin1991 | jonwil: I fear not | 22:24 |
| *** javispedro has quit IRC | 22:25 | |
| zeq | so is anything decided? | 22:25 |
| freemangordon | merlin1991: well, go back to the days n900 was your everyday device and answer the question, please. | 22:25 |
| Pali | I'm going away for 10-20 minutes | 22:25 |
| merlin1991 | back then it was stock kernel on my main device | 22:25 |
| merlin1991 | and kp on my backup because I wanted iptables | 22:26 |
| merlin1991 | but I think it's still a thing of user choice here, if people want all the kp goodness they can install it from extras-* | 22:26 |
| merlin1991 | everyone else can stay where they are + have stuff fixed that needs to be fixed | 22:26 |
| merlin1991 | ofc assuming that fsckd autobuilder stops to act up | 22:27 |
| freemangordon | merlin1991: people who don't know all the KP goodness will not even care which exactly kernel they have flashed | 22:27 |
| freemangordon | it is for those who know and care | 22:27 |
| merlin1991 | well from kp days I remember issues with rebotos when usb was connected and other fun | 22:28 |
| freemangordon | well, those days are gone, for good | 22:28 |
| merlin1991 | if everything in kp works as on stock then I'm happy to pull it into cssu | 22:29 |
| merlin1991 | Doc is going to kill me right now xD | 22:29 |
| Estel_ | :) | 22:29 |
| zeq | lol | 22:29 |
| jonwil | ok, so unless discussion of topics relevant to me like WiFi/wlan, binary blob replacement etc is going to happen, I might as well leave | 22:29 |
| Estel_ | I think You will have sound sleep nevertheless. BTw, freemangordon fixed the very issue You mentioned (reboot on usb cable) | 22:29 |
| merlin1991 | but I would still review the patches and maybe strip stuff that is on the "experimental" side | 22:30 |
| Estel_ | sounds ok. | 22:30 |
| zeq | jonwil: this is taking a while... I guess we're not going to get onto those subjects specifically | 22:30 |
| *** BCMM has joined #maemo-ssu | 22:30 | |
| freemangordon | jonwil: well, it seems if that discussion happen it won;t be anytime soon, maybe it is better to have some rest. Sorry :( | 22:30 |
| Estel_ | this way cssu suers will benefit from upstream patches and fixes, and everyone wanting even more will be able to install kernel-power | 22:30 |
| Estel_ | merlin1991, agree? | 22:30 |
| merlin1991 | yes | 22:30 |
| Estel_ | s/suers/users | 22:30 |
| freemangordon | merlin1991: the idea is: KP used as lab, the stuff that is stable goes to CSSU | 22:31 |
| jonwil | hmmm, will stay a little bit, looks like discussion of KP/KCSSU is almost over | 22:31 |
| merlin1991 | freemangordon: yep | 22:31 |
| Estel_ | so, can we mark this as "agreed", kernel-power stripped of experimental stuff goes as community kernel | 22:31 |
| Estel_ | my thumbs are waiting nervously :) | 22:31 |
| Estel_ | for next points | 22:31 |
| freemangordon | well, I am pretty ok with that. stuff which is still experimental (like bq stuff, etc) will be stripped from kernel until proven stable. | 22:32 |
| freemangordon | merlin1991: agree? ^^^ | 22:32 |
| merlin1991 | yes | 22:33 |
| freemangordon | ok, we have a deal :). | 22:33 |
| freemangordon | anyone? | 22:33 |
| Estel_ | *fanfares* | 22:33 |
| zeq | I'm happy :) | 22:33 |
| Estel_ | it's a small step for kernel-power, but big step for cssu... or something like that | 22:34 |
| Estel_ | ;) | 22:34 |
| freemangordon | ok, I think Pali will be happy too, will ask him when he is back | 22:34 |
| jonwil | ok, next point? :P | 22:34 |
| merlin1991 | so basically point 1 and 3 are done then | 22:34 |
| merlin1991 | which leads us to point 2 | 22:34 |
| freemangordon | zeq: are they? | 22:34 |
| zeq | yup | 22:35 |
| freemangordon | ok | 22:35 |
| freemangordon | merlin1991: yes | 22:35 |
| freemangordon | lemme see | 22:35 |
| freemangordon | ok, we have a descent gcc 4.7.2 for SB | 22:35 |
| freemangordon | the only thing that needs to be changed on the device is libgcc1 and libstdc++ | 22:36 |
| Estel_ | which proved to produce results making Maemo *much* snappier for real use, by 100% of people, many of them placebo-prone | 22:36 |
| freemangordon | which are almost 100% ABI compatible with those coming with 4.2.1 | 22:36 |
| zeq | freemangordon: should be 100%..? | 22:36 |
| merlin1991 | freemangordon: what are the advantages besides being able to compile the thumb stuff (and possibly better optimization)? | 22:37 |
| zeq | merlin1991: *much* better optimization :P | 22:37 |
| freemangordon | we can compile lots more upstream stuff | 22:37 |
| zeq | that too | 22:37 |
| zeq | better standards compliance | 22:37 |
| merlin1991 | any regressions? | 22:37 |
| zeq | merlin1991: there are a couple of known bugs, and I've failed to build a fully working glibc-2.5 with it | 22:38 |
| freemangordon | there is an ABI break between 4.3 and 4.4. That can be workarounded very easily | 22:38 |
| freemangordon | merlin1991: having in mind stuff in -thumb repo, I would say there are no regressions | 22:39 |
| zeq | on there other hand the bugs get fixed, and I'm keeping up to date with Linaro releases | 22:39 |
| merlin1991 | if we want to use this upgraded toolchain it has to be able to compile everything we currently have in cssu | 22:39 |
| freemangordon | it is | 22:39 |
| freemangordon | the first was Qt | 22:39 |
| freemangordon | next come gtk, xserver, etc | 22:39 |
| freemangordon | aah, not to forget microb-engine | 22:40 |
| zeq | There are a number of things that try to use gnu89 inlines with new toolchian, but fail due to glibc | 22:40 |
| freemangordon | zeq: example? | 22:40 |
| zeq | s/toolchian/toolchain/ | 22:40 |
| infobot | zeq meant: There are a number of things that try to use gnu89 inlines with new toolchain, but fail due to glibc | 22:40 |
| merlin1991 | freemangordon: did you try if this enables us to use -O3 on qt again? | 22:41 |
| zeq | I hit it building a new cpio, but there are more reports on tmo | 22:41 |
| freemangordon | merlin1991: yes, it works ok, but because the binary was way bigger then with -O2, I kept it that way | 22:41 |
| zeq | this thread: http://talk.maemo.org/showthread.php?p=1164057 | 22:42 |
| zeq | I have patched glibc to support it though | 22:42 |
| zeq | backported from glibc-2.6 | 22:42 |
| freemangordon | merlin1991: I don't think using -O3 for such a big codebase is a good idea, having in mind the amount of RAM | 22:42 |
| Estel_ | so why You've said earlier, that better toolchain is a no-go? merlin1991? | 22:43 |
| freemangordon | and AFAIK loop enrolling is inefficient on ARM anyway | 22:43 |
| zeq | graphites -floop-strip-mine is potentially interesting though | 22:43 |
| merlin1991 | Estel_: because of all the stuff like sudden use of inlines which are not in our core c lib ... | 22:43 |
| merlin1991 | usually you do a toolchain upgrade when you swap everything to newer stuff | 22:44 |
| merlin1991 | ie a new debian release | 22:44 |
| freemangordon | well, we cannot do that, but on the other hand 4.2.1 is ancient | 22:44 |
| zeq | the glibc backport doesn't affect ABI | 22:44 |
| freemangordon | aah, LTO too | 22:44 |
| zeq | merlin1991: the only ABI requirements are libgcc1 and libstdc++ | 22:45 |
| freemangordon | well, lets not try to decide anything now, ok? | 22:45 |
| merlin1991 | well there's also the problem of backwards compatability, can we be sure that everything from extras still works with the upgraded c libs? | 22:45 |
| Pali | I'm here, kernel with non experimental kernel-power patches is ok | 22:46 |
| zeq | ideally I would like to have the inline support along with pselect() | 22:46 |
| freemangordon | well, thumb was/as a good proof there is no break | 22:46 |
| zeq | glibc ABI is always backward compatible, all new symbols are versioned | 22:46 |
| freemangordon | :nod: | 22:47 |
| zeq | the inline changes mostly relates to headers | 22:47 |
| merlin1991 | zeq: what happens if you add the inline support to glibc but stay with the old compiler? | 22:47 |
| zeq | that works too | 22:47 |
| merlin1991 | then I'd prefer that for now | 22:48 |
| zeq | there is no benefit from using the old compiler *except* not upgrading libgcc1 and libstdc++ | 22:48 |
| merlin1991 | there's the benefit of sleeping well based on the it worked untill now facts ;) | 22:49 |
| merlin1991 | and also the benefit of using the normal scratchbox installer and wiki to get everything in place to start working | 22:49 |
| merlin1991 | not to mention already configured scratchboxes | 22:50 |
| *** javispedro has joined #maemo-ssu | 22:50 | |
| zeq | merlin1991: it's not hard to install the new toolchain | 22:50 |
| Estel_ | ^+1 | 22:50 |
| freemangordon | merlin1991: you can check my latest commits in modest. | 22:50 |
| freemangordon | re good compiler | 22:50 |
| Estel_ | also, wiki will be nuked soon, anyway, and rebuild in hildon foundation | 22:50 |
| merlin1991 | do we have a scratchbox-* package for the host system by now? | 22:50 |
| Estel_ | also, there is 0 reports of things from extras (any flavour) broken, by dozens of cssu-thumb users | 22:50 |
| Estel_ | despite new compiler | 22:51 |
| freemangordon | no, but that could be done easily | 22:51 |
| freemangordon | merlin1991: ^^^ | 22:51 |
| zeq | Actually, I do have a i486 cross | 22:51 |
| freemangordon | .deb? | 22:51 |
| zeq | I may not have released it.. ;) | 22:51 |
| zeq | no, but I think I can say make deb or something | 22:52 |
| merlin1991 | well in order to swap the toolchain we need to have everything that is currently provided by the old one and some reassurance that it won't break a thing, then I see no reason not todo it | 22:52 |
| freemangordon | zeq: well, even that is not needed, once we have tar.gz | 22:52 |
| freemangordon | merlin1991: :nod: | 22:53 |
| zeq | except for ease of management on dpkg based systems | 22:53 |
| zeq | (host system I mean) | 22:53 |
| freemangordon | yeah | 22:53 |
| zeq | not that tar xf is that tricky :) | 22:53 |
| freemangordon | well, lets leave that one to rest in our heads for a while | 22:54 |
| merlin1991 | but it breaks the flow when install 90% of a scratchbox via apt and the tar some stuff | 22:54 |
| merlin1991 | god typos ftw | 22:54 |
| zeq | it's not a problem to package it | 22:54 |
| merlin1991 | then do it :D | 22:55 |
| zeq | okay will do | 22:55 |
| freemangordon | :D | 22:55 |
| zeq | mostly I haven't because I don't have a dpkg host system :P | 22:55 |
| zeq | laziness | 22:55 |
| freemangordon | zeq: get vmware image from nokia | 22:55 |
| zeq | My SB is working ok :) | 22:56 |
| Estel_ | freemangordon, sure, but why should we rest our head, if merlin1991 doesn't see problem as long as all required things are provided BEFORE? | 22:56 |
| freemangordon | it already has SB installed, not sure which debian it is | 22:56 |
| Estel_ | like things for toolchain | 22:56 |
| Estel_ | I agree with merlin1991, that no much reasons to *not* do it | 22:56 |
| Estel_ | then | 22:56 |
| zeq | what other requirements are there? | 22:56 |
| Estel_ | release early, release often ;) | 22:56 |
| freemangordon | Estel_: because it won't happen aver the night anyway | 22:56 |
| freemangordon | *over | 22:56 |
| merlin1991 | zeq: the requirements are works and is feature complete | 22:57 |
| Estel_ | but deciding that we want to do it, will boost creating things like easy-=to-install toolchain | 22:57 |
| Estel_ | and so goes on | 22:57 |
| zeq | we've already made sure the generated target .debs are conforming with the maemo versioning | 22:57 |
| freemangordon | and if merlin1991 has some concerns, I would prefer tho clean them up before continuing | 22:57 |
| zeq | merlin1991: just wanted to know what feature complete is | 22:57 |
| zeq | right now it has many more features | 22:57 |
| zeq | not aware of anything missing | 22:58 |
| merlin1991 | host debs are the only things missing afaik | 22:58 |
| merlin1991 | and ofc i386 | 22:58 |
| freemangordon | zeq: maybe you'll need to rebuild it, and make some warnings/errors disabled by default | 22:58 |
| zeq | target native compiler is something I haven't done | 22:59 |
| freemangordon | merlin1991: 486 ;) | 22:59 |
| merlin1991 | ah yeah true, 486 | 22:59 |
| zeq | freemangordon: The warning/errors are an upstream policy | 22:59 |
| freemangordon | zeq: there should be no need, I don;t think you can install 4.2.1 on n900 anyway | 22:59 |
| zeq | determined by conforming more closely to standards | 22:59 |
| freemangordon | zeq: yes, but we can disable some of them in our build. I guess. | 23:00 |
| freemangordon | on the other hand, it is better to have them | 23:00 |
| merlin1991 | anyhting else you guys need me for? Family dinner is happening since an hour already :D | 23:00 |
| zeq | you can always use -Wno-error=bla-bla | 23:00 |
| freemangordon | one can alwasy pass -Wno-shit | 23:00 |
| zeq | :) | 23:01 |
| freemangordon | merlin1991: well, I think no | 23:01 |
| zeq | was there anything else on the list | 23:01 |
| zeq | ? | 23:01 |
| merlin1991 | nope | 23:01 |
| freemangordon | no, and jonwil is sleeping | 23:01 |
| jonwil | no I am not :P | 23:01 |
| zeq | upgrading glibc going forwards... | 23:01 |
| freemangordon | merlin1991: could you discuss that with MohammadAG and chem|st? | 23:02 |
| zeq | jonwil's binary blob replacement strategy | 23:02 |
| merlin1991 | freemangordon, Pali can you guys write me a list on what you've worked on / pushed to gitorious since the last -testing release? | 23:02 |
| freemangordon | And come with some more "official" statement? | 23:02 |
| merlin1991 | freemangordon: I will | 23:02 |
| freemangordon | merlin1991: unfortunately I won't be able to do that till Sunday | 23:02 |
| merlin1991 | no rush | 23:03 |
| freemangordon | yeah, I know :) | 23:03 |
| merlin1991 | it's just that I kinda lost track on what's happening on gitorious, now that we have that many packages :D | 23:03 |
| zeq | I think we're going to need another meeting :D | 23:03 |
| merlin1991 | and I think it's about time we do a new release to include ie lufs changes to obexd | 23:03 |
| freemangordon | but basically I have touched tinymail only, most of my commits are related to thumb stuff | 23:03 |
| freemangordon | merlin1991: deffinitely. and libcurl3 too | 23:04 |
| freemangordon | merlin1991: tuesday? | 23:04 |
| Estel_ | Pali, abusing fact that You're her,e could You check my psots @ kp51r1 thread? | 23:04 |
| freemangordon | WOW | 23:05 |
| Estel_ | I've included irc logs from talking with DocScrutinizer about bugs in bq2415x_charger | 23:05 |
| merlin1991 | send it per email when you have it ready | 23:05 |
| Estel_ | and it seems that there are bugs, definitelly | 23:05 |
| Estel_ | I need to be off, now :) | 23:05 |
| Estel_ | See ya, guys | 23:05 |
| freemangordon | bb | 23:05 |
| zeq | bb Estel_ | 23:06 |
| jonwil | anything else on the agenda? | 23:07 |
| freemangordon | jonwil: your turn :) | 23:07 |
| jonwil | ok | 23:07 |
| jonwil | ok, so my work to replace the bluetooth and WiFi cal stuff... | 23:07 |
| jonwil | Is that something people actually care about? | 23:07 |
| merlin1991 | jonwil: in general everyone in here is happy about each and every closed bit that gets a replacement | 23:08 |
| freemangordon | jonwil: I see it like Pali's work re bq | 23:08 |
| zeq | absolutely | 23:08 |
| freemangordon | and mine on hald-addon-bme and libbmeipc | 23:09 |
| zeq | do we intend to keep functionality as-is? | 23:09 |
| jonwil | ok, well the real question is, is there any interest in doing kernel changes in conjunction with the bluetooth and WiFi cal stuff so as to replace the funky crappy kernel interfaces (e.g. netlink) with something more standard | 23:09 |
| zeq | what does the Nemo kernel use for kernel<->userspace re. wifi and bluetooth? | 23:10 |
| jonwil | well MeeGo/Mer/Nemo still has the same binary bits for N900 WiFi and Bluetooth | 23:10 |
| jonwil | so it must have the same kernel interfaces | 23:10 |
| freemangordon | and what evel it does (besides being closed source)? | 23:11 |
| freemangordon | *evil | 23:11 |
| zeq | but according to earlier discussion there are open drivers for most devices | 23:11 |
| Pali | going offline, bye | 23:11 |
| zeq | see ya Pali | 23:12 |
| freemangordon | bye Pali | 23:12 |
| jonwil | the question is not what it does, the question is, is removing the crappy non-standard interfaces from the kernel worthwhile or not | 23:12 |
| freemangordon | zeq: but userspace is not | 23:12 |
| jonwil | and if its worthwhile, is there someone with the skills to actually do the work? | 23:12 |
| *** Pali has quit IRC | 23:12 | |
| freemangordon | merlin1991: ^^^ ? | 23:12 |
| freemangordon | jonwil: we'll find the skills, I think the resource situation is way better now that it was an year ago | 23:13 |
| jonwil | ok, in that case I will continue with wl1251-cal and get something going that does all the bits except for the actual netlink-send-to-kernel stuff | 23:14 |
| jonwil | then someone else can take that code and make it work with something standard | 23:14 |
| jonwil | whatever the appropriate interfaces are | 23:14 |
| freemangordon | jonwil: whatever netlink-send-to-kernel is :D | 23:15 |
| *** toxaris has joined #maemo-ssu | 23:16 | |
| freemangordon | jonwil: wl1251-cal is .so? | 23:16 |
| jonwil | no its binary | 23:16 |
| freemangordon | executable? aah, ok | 23:17 |
| jonwil | it runs at startup and sends stuff (including MAC address) to kernel | 23:17 |
| jonwil | over netlink | 23:17 |
| jonwil | point is, netlink is non-standard (or so I have been told) | 23:17 |
| freemangordon | and gets it from CAL. ok, got it. | 23:17 |
| jonwil | and we should be doing things in way that follows proper standards | 23:17 |
| freemangordon | yep | 23:17 |
| jonwil | ok, so yeah I will produce wl1251-cal clone then | 23:18 |
| zeq | netlink is a standard interface | 23:18 |
| freemangordon | but, wl1251 kernel driver is upstreamed, ain't? | 23:18 |
| zeq | whether it's the usual or best one for that purpose...? | 23:18 |
| freemangordon | how it comes it does not use a standard iface? | 23:19 |
| jonwil | I dont know, ask Nokia | 23:19 |
| jonwil | :P | 23:19 |
| zeq | I suspect it is a standard interface, just the specifics are poorly (or un-)documented | 23:19 |
| jonwil | ok, so regarding other binary blobs, are there any targets I should focus on? Already ruled out bootloader, kernel, GPU, cell modem, dialer, browser, messaging, telepathy and MCE | 23:20 |
| jonwil | as those are too hard for me | 23:20 |
| freemangordon | http://en.wikipedia.org/wiki/Netlink | 23:20 |
| freemangordon | jonwil: you mean RE? | 23:20 |
| jonwil | yes | 23:21 |
| zeq | freemangordon: as I said it is standard | 23:21 |
| freemangordon | the only thing I can think of right now if him | 23:21 |
| freemangordon | s/if/is/ | 23:21 |
| infobot | freemangordon meant: the only thing I can think of right now is him | 23:21 |
| freemangordon | I am already on vkbrenderer | 23:22 |
| freemangordon | but there is other closed stuf too | 23:22 |
| jonwil | yeah h-i-m closed bits are complex too | 23:22 |
| zeq | new open dialler would be nice | 23:22 |
| freemangordon | jonwil: well, 386 binaries are 20-30 k eash | 23:22 |
| freemangordon | each | 23:22 |
| freemangordon | why hard? | 23:23 |
| jonwil | GUI stuff is generally complex | 23:23 |
| jonwil | just because of how GTK is :) | 23:23 |
| freemangordon | and there are enough headers to grok the interfaces | 23:23 |
| zeq | you can code GUI in qt* | 23:23 |
| freemangordon | aah, yes | 23:23 |
| jonwil | And I already said dialer is FAR too complex to reverse engineer | 23:23 |
| freemangordon | zeq: well, it is not so simple to miz qt and gtk | 23:24 |
| freemangordon | jonwil: yes, dialer is very very complex | 23:24 |
| freemangordon | s/miz/mix/ | 23:24 |
| zeq | because of address0book etc? | 23:24 |
| zeq | s/address0book/address-book/ | 23:25 |
| infobot | zeq meant: because of address-book etc? | 23:25 |
| jonwil | because of the mess that is telepathy for one thing | 23:25 |
| freemangordon | zeq: not only, it deals with mode, battery, sim, etc | 23:25 |
| freemangordon | s/mode/modem/ | 23:25 |
| infobot | freemangordon meant: zeq: not only, it deals with modem, battery, sim, etc | 23:25 |
| zeq | are those not provided/handled by external daemons etc | 23:26 |
| freemangordon | if we have foss dialer one day, it should be complete rewrite or backport from somewhere | 23:26 |
| zeq | what's the Nemo dialler like? | 23:26 |
| jonwil | dialer has to talk to external things like telepathy, telepathy-ring, cellular services daemon etc | 23:26 |
| jonwil | all of which are mostly undocumented | 23:26 |
| jonwil | and difficult to figure out | 23:26 |
| freemangordon | well, I don't know that much about dialer, but ^^^ | 23:27 |
| jonwil | well cellular services daemon is definitely undocumented | 23:27 |
| zeq | telepathy should be documented even if not the ring plugin | 23:27 |
| freemangordon | zeq: and it does not make sense to RE it, when there is ofono | 23:27 |
| jonwil | yeah telepathy is documented | 23:27 |
| zeq | telepathy is F/OSS | 23:28 |
| jonwil | yeah most of it is | 23:28 |
| freemangordon | zeq: ever seen telepathy documentation? | 23:28 |
| jonwil | but not the interesting parts :) | 23:28 |
| jonwil | and yes telepathy documentation is a mess | 23:28 |
| jonwil | so yeah dialer replacement is off the table | 23:28 |
| freemangordon | zeq: I've tried to read it once, got a headache after a while | 23:28 |
| zeq | ~ofono | 23:29 |
| zeq | no infobot? | 23:29 |
| zeq | what's ofono? | 23:29 |
| jonwil | ofono is NOT something we can use in Fremantle | 23:29 |
| freemangordon | http://en.wikipedia.org/wiki/OFono | 23:29 |
| jonwil | That I can say for sture | 23:29 |
| freemangordon | jonwil: why? | 23:29 |
| jonwil | too many bits of the system will break because they expect to talk to the Cellular Services Daemon and its specific undocumented dbus interfaces | 23:30 |
| freemangordon | afaik it works in ubuntu | 23:30 |
| freemangordon | hmm, couldn;t we RE that? | 23:30 |
| jonwil | everything from bluetooth to GPRS | 23:30 |
| jonwil | I have been trying to figure out the CSD dbus interfaces for ages now without much luck (com.nokia.phone.sim specifically) | 23:31 |
| freemangordon | after all dbus should be pretty much easy to sniff | 23:31 |
| jonwil | yes its easy to sniff | 23:31 |
| jonwil | but figuring out what you are looking at is hard | 23:31 |
| jonwil | when all you see is a bunch of numbers | 23:31 |
| freemangordon | hehe | 23:31 |
| freemangordon | jonwil: BTW is it possible it is just a transparent transport to sim? | 23:32 |
| freemangordon | maybe I should look at it some day | 23:33 |
| jonwil | it doesn't appear to be that simple | 23:33 |
| freemangordon | and those numbers are APDUs? | 23:33 |
| freemangordon | possible? | 23:33 |
| zeq | some documentation on the wiki: http://wiki.maemo.org/Phone_control | 23:33 |
| jonwil | yeah a couple pieces of documentation around but not for the good bits (the bits I need) | 23:34 |
| Estel_ | zeq, this one is about calls as whole, notm sim related. yuep? (i'm back for a while, listening quietly) | 23:34 |
| jonwil | I followed things through the cellular services daemon to find out what happens with those com.nokia.phone.sim dbus calls but those calls just translate into cell modem isi/phonet messages that are just as undocumented as the dbus interfaces | 23:35 |
| freemangordon | jonwil: and which part is missing? | 23:35 |
| jonwil | most of com.nokia.phone.sim is undocumented | 23:35 |
| zeq | phonet is in the upstream kernel | 23:35 |
| freemangordon | hmm, can't we just guess from the names? | 23:35 |
| zeq | maybe some documentation in the kernel sources? | 23:35 |
| jonwil | nope, there is not | 23:35 |
| jonwil | phonet is just a transport method | 23:36 |
| jonwil | the actual packets are only dealt with by the cellular services daemon (or by ofono) | 23:36 |
| jonwil | and yes I checked ofono source but its not sending the packets I care about | 23:36 |
| jonwil | so that doesn't help for documentation | 23:36 |
| jonwil | we can sort of guess from the names but com.nokia.phone.sim.get_service_provider_info doesnt tell us much | 23:37 |
| jonwil | nor does com.nokia.phone.sim.get_sim_status tell us what the status number(s) actually mean | 23:37 |
| freemangordon | jonwil: we can get that from other sources, after all those should come directly from the card | 23:38 |
| freemangordon | I don;t think the modem translates those | 23:38 |
| zeq | I wonder if it would be a valid guess that nokia use the same structures as with their older devices? | 23:38 |
| jonwil | I did a lot of digging and I cant find anything useful | 23:39 |
| zeq | gnokki? | 23:39 |
| jonwil | including looking at SIM related specs | 23:39 |
| jonwil | its pretty clear though that the cellmo is definatly the one dealing with these packets | 23:40 |
| jonwil | and that they arent just being passed to the SIM | 23:40 |
| freemangordon | jonwil: ever heard about globalplatform? | 23:40 |
| jonwil | haven't heard of globalplatform | 23:40 |
| freemangordon | there is lots of stuff there for OTA update and such | 23:40 |
| zeq | I'd be willing to bet there is a standard hiding here | 23:40 |
| zeq | as in a specification for cellular communications | 23:41 |
| jonwil | All the evidence I have suggests that the data comming from the cell modem is totally different to what you see on the SIM itself (and what the SIM passes to the cellmo) | 23:41 |
| freemangordon | jonwil: it is the latest standard most of vendors comply with | 23:41 |
| jonwil | yes the modem probably complies with all sorts of SIM related standards | 23:42 |
| jonwil | but the interface to the main CPU is definitely 100% Nokia | 23:42 |
| freemangordon | hmm, bad | 23:42 |
| jonwil | I have some totally undocumented .h files for a couple of other parts of the cellmo (like GPS) | 23:42 |
| zeq | jonwil: I still think it's probably worth looking at the gnokki codebase | 23:42 |
| *** NIN101 has quit IRC | 23:42 | |
| zeq | I remember they had various protocol handlers | 23:43 |
| freemangordon | that is used to talk through rs/usb/whatever iface with the modem? | 23:43 |
| freemangordon | zeq: ^^^ | 23:44 |
| zeq | yes, whatever bus was available on various phones | 23:44 |
| jonwil | I dont think gnokki talks to the cellular modem much, it probably just uses the same interfaces as the official Nokia software | 23:44 |
| jonwil | I doubt gnokki codebase is going to have any low-level details of Nokia modems (especially not the N900 modem) | 23:44 |
| jonwil | gnokki may use AT commands to talk to the phone in some cases | 23:45 |
| zeq | but is the interface really low-level? | 23:45 |
| jonwil | if the phone exposes AT commands to the outside world | 23:45 |
| jonwil | and yes the modem interface is quite low level | 23:45 |
| jonwil | Reading the ofono source has shown me that | 23:45 |
| zeq | doesn't it run a firmware? | 23:46 |
| jonwil | yes the cellular modem does run a firmware | 23:46 |
| jonwil | but reverse engineering that would be nigh-on impossible | 23:46 |
| freemangordon | but, but , why AT commands don;t work then? | 23:46 |
| jonwil | since there is basically zero information on that firmware or the hardware that it runs on | 23:46 |
| jonwil | I dont know a thing about AT commands on n900 | 23:47 |
| jonwil | just that the cellmo doesn't use em | 23:47 |
| freemangordon | http://git.savannah.gnu.org/cgit/gnokii.git/tree/include/phones/nk6510.h | 23:48 |
| jonwil | ok, that looks nothing like the n900 cellmo interface | 23:49 |
| zeq | Looks interesting :) | 23:49 |
| jonwil | the isi/phonet stuff | 23:49 |
| zeq | oh well :) | 23:49 |
| DocScrutinizer05 | who says I'm not here? | 23:49 |
| zeq | Hi DocScrutinizer | 23:49 |
| freemangordon | you WERE not here :P | 23:49 |
| freemangordon | hi | 23:49 |
| jonwil | ok, so any more discussion to have on the n900 cell modem or can we move on? | 23:49 |
| freemangordon | i guess we can | 23:50 |
| DocScrutinizer05 | dafaq that scollback will take hours to read | 23:50 |
| DocScrutinizer05 | you guys been pretty busy last 3 hours, eh? | 23:51 |
| freemangordon | yeah | 23:51 |
| jonwil | ok, so other than the bluetooth and WiFi cal stuff, we still haven't identified anything that is possible to reverse engineer/clone and where there would be a benefit in doing so | 23:51 |
| DocScrutinizer05 | you thought "fine, DocScrutinizer isn't around, so finally we get things done without tedious discussions" | 23:51 |
| jonwil | although I am definatly open to suggestions that I haven't already ruled out :) | 23:52 |
| freemangordon | jonwil: well, I can't think of anything else now, but will keep it in my mind while using the device ;) | 23:52 |
| jonwil | ok | 23:52 |
| zeq | jonwil: I'm not sure what's left? | 23:52 |
| jonwil | I am not sure off the top of my head either | 23:53 |
| jonwil | but I guess bluetooth and wifi CAL is a good place to start | 23:53 |
| jonwil | but only if someone is willing to do the other parts and make it talk to the kernel using something less non-standard | 23:53 |
| freemangordon | jonwil: but it is standard | 23:54 |
| jonwil | well netlink may be standard but someone (I forget who) said that its not ideal | 23:54 |
| zeq | jonwil: I think the netlink interface just needs documenting | 23:54 |
| jonwil | i.e. that there are benefits to replacing netlink | 23:54 |
| DocScrutinizer05 | jonwil: cmt using ISI interface, aka phonet iirc (or rather phonet using same wireless modem API as well). there's pnatd that converts AT to wireless modem API | 23:54 |
| jonwil | might have been pali | 23:54 |
| jonwil | yeah doc, I know that :) | 23:54 |
| freemangordon | http://tools.ietf.org/html/rfc3549 | 23:55 |
| DocScrutinizer05 | and there's basically ZARRO use in REing cmt FW | 23:55 |
| zeq | Unless you want to be banned from telcos ;) | 23:55 |
| DocScrutinizer05 | since, while it's still ARM according to jacekowski, it is signed and thus not patchable | 23:56 |
| DocScrutinizer05 | zeq: nope, you simply CAN NOT mess with it | 23:56 |
| DocScrutinizer05 | cmt simply will refuse to flash any patched version | 23:56 |
| zeq | unless you zap it with a STM | 23:56 |
| Estel_ | hello rider of the Storm :) | 23:56 |
| freemangordon | yeah, at least until we find a way to steal Nokia's private keys ;) | 23:57 |
| jonwil | btw, I found this quote earlier on google | 23:57 |
| DocScrutinizer05 | freemangordon: exactly | 23:57 |
| Estel_ | freemangordon, tolda ya that hiring mercaneries to scavenge what we can now from nokia's offices is a way to go | 23:57 |
| jonwil | "Commit "wl1251: add wl1251 prefix to all 1251 files" accidentally added wl1251_netlink.c which contains a private netlink interface." | 23:57 |
| Estel_ | we can start fundrising right now | 23:57 |
| zeq | Estel_: shhh | 23:57 |
| jonwil | so that implies that even though netlink itself is standard, the specific interface to wl1251 driver is 100% Nokia | 23:57 |
| jonwil | and may not be the way that mainline kernel would implement interface to wl1251 chip if they were doing it | 23:58 |
| *** nox- has joined #maemo-ssu | 23:58 | |
| freemangordon | well, if it is upstreamed, it should be following some rules | 23:59 |
| freemangordon | and it is upstreamed afaik | 23:59 |
| jonwil | yes I think so | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!