| 03:13.19 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 03:13.19 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: http://gitorious.org/community-ssu/ | Latest version (testing): 21.2011.38-1Tmaemo4.1; (stable): 21.2011.38-1Smaemo3 |
| 03:13.19 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 05:18.19 | *** join/#maemo-ssu zeq1 (~s_j_newbu@2a01:348:1e3:1:e6ec:10ff:fe9a:d418) |
| 05:56.46 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 06:05.18 | 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. |
| 06:06.24 | jonwil | is there a reason why we cant just use a newer version of glibc as-is? |
| 06:06.30 | freemangordon | zeq1: well, it is up to you, but if there is no performance difference, what is the point? |
| 06:06.37 | zeq1 | freemangordon: this will fix ftbfs for quite a few packages |
| 06:06.53 | freemangordon | ~ftbfs |
| 06:06.53 | infobot | hmm... ftbfs is "fails to build from source" |
| 06:07.25 | zeq1 | jonwil: I intend to do that too, but I'm not sure that's even cssu material |
| 06:07.34 | freemangordon | zeq1: it is |
| 06:08.03 | freemangordon | zeq1: but before doing any of these, we must have "go on" from maintainers |
| 06:08.04 | zeq1 | freemangordon: perhaps. cssu-unstable |
| 06:08.15 | jonwil | yeah cssu-testing seems like a good place to go |
| 06:08.21 | jonwil | or cssu-devel |
| 06:08.30 | freemangordon | cssu-devel, for sure |
| 06:08.55 | 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 |
| 06:09.05 | zeq1 | yeah, it would effectively mean forked Maemo, a proper continuation of maemo5 |
| 06:09.38 | freemangordon | zeq1: so far newer toolchain is not discussed with merlin1991, MohammadAG or chem|st |
| 06:09.42 | jonwil | CSSU is already basically a fork with changes |
| 06:09.45 | zeq1 | in itself it doesn't break ABI (backwards) |
| 06:09.45 | jonwil | ... |
| 06:09.51 | freemangordon | AFAIK |
| 06:10.12 | zeq1 | but you know people will start to use the new features... |
| 06:10.19 | freemangordon | zeq1: neither is kernel-cssu, pselect(), etc |
| 06:10.40 | zeq1 | pselect() is actually a very special case |
| 06:10.54 | zeq1 | since it's already littered throughout |
| 06:11.10 | freemangordon | no, it is not |
| 06:11.12 | zeq1 | the only change is how glibc handles it |
| 06:11.34 | zeq1 | freemangordon: honestly, it is :) |
| 06:11.38 | freemangordon | (if i parse correctly your statement) |
| 06:12.08 | zeq1 | lots of packages already in maemo5 use pselect() |
| 06:12.47 | zeq1 | it's just glibc doesn't |
| 06:12.59 | freemangordon | zeq1: maybe you should rephrase, I am not sure I got you "littered" statement correctly :) |
| 06:13.10 | zeq1 | so those packages that think they are aren't |
| 06:13.29 | zeq1 | littered == all over the place |
| 06:13.39 | freemangordon | zeq1: I know the rationale, no need to convince me :P |
| 06:13.45 | freemangordon | aah, ok |
| 06:14.01 | zeq1 | What I mean is it's not a new API |
| 06:14.06 | freemangordon | I was sure I am missing something |
| 06:14.24 | zeq1 | updating glibc to a new version introduces new APIs |
| 06:14.42 | zeq1 | they will get used -> ABI breakage |
| 06:15.09 | freemangordon | well, we already are past that point, Qt 4.7.4 that is |
| 06:15.40 | zeq1 | I'm not arguing against myself, just making sure I'm clear |
| 06:16.28 | freemangordon | yeah :). anyway, a discussion with maintainers and the rest of developers must take place first |
| 06:16.32 | jonwil | yeah |
| 06:16.46 | zeq1 | I think we should get glibc to a state for "stable" where it can take advantage of newer toolchains |
| 06:17.14 | zeq1 | AND update glibc (and other infrastructure) going forwards |
| 06:17.43 | freemangordon | zeq1: my point is that before " ok, guys, lets do it" agreement inside CSSU team, there is no point of doiing it |
| 06:17.48 | jonwil | yeah |
| 06:18.15 | 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) |
| 06:18.25 | jonwil | but bring newer glibc version into cssu-devel |
| 06:18.39 | jonwil | and eventually to cssu-testing and then cssu-stable down the track |
| 06:18.46 | jonwil | same with anything else we can update like glib |
| 06:18.58 | freemangordon | zeq1: so, that is first to do, that way the whole CSSU team will get involved, etc. |
| 06:19.08 | zeq1 | sure |
| 06:19.17 | zeq1 | do we need to call a meeting? |
| 06:19.31 | jonwil | hmm, I wonder what would be standing in the way of updating the kernel to a newer kernel version, if anything |
| 06:19.46 | freemangordon | yes, the problem is there is no established way of doing it :D:D:D |
| 06:20.07 | freemangordon | zeq1: ^^^ |
| 06:20.23 | zeq1 | jonwil: kernel is tricky |
| 06:20.41 | zeq1 | we could look into porting kernel from Nemo? |
| 06:20.42 | jonwil | because? |
| 06:20.47 | freemangordon | but I will try to ping merlin1991 today, how you guys are with your free time this evening? |
| 06:21.12 | freemangordon | or maybe a mail to maemo-developers? |
| 06:21.21 | zeq1 | I'll tell my gf it's important :P |
| 06:21.40 | freemangordon | jonwil: it is tricky. Of course it does not mean it is impossible |
| 06:21.54 | freemangordon | but we need to find a good enough reason to do it |
| 06:22.02 | freemangordon | zeq1: yeah ;) |
| 06:24.04 | freemangordon | jonwil: a kernel upgrade means a lot of stuff won't work anymore, fcam for example |
| 06:24.35 | zeq1 | yes, it *will* break kernel module ABI |
| 06:25.38 | jonwil | stuff can always be ported to the newer kernel without problems AFAIK |
| 06:25.54 | zeq1 | only stuff with sources |
| 06:26.08 | jonwil | there are no binary kernel modules on Maemo |
| 06:26.12 | freemangordon | so, who is to write a mail to maemo-developers? asking CSSU team and whoever is interested to gather this evening. |
| 06:26.28 | freemangordon | jonwil: besides joikuspot, yes |
| 06:26.50 | zeq1 | I'm not offically on-team am I? |
| 06:27.08 | freemangordon | zeq1: well, lets assume you are in |
| 06:27.20 | freemangordon | I don;t think there will be any objections |
| 06:27.34 | freemangordon | new developers are always welcome |
| 06:27.49 | zeq1 | :) |
| 06:28.13 | zeq1 | I actually need to go fix my mail server(!) |
| 06:29.20 | zeq1 | some idiot (me) decided it would be a good idea to rebuild my server with gentoo-portage-multilib! |
| 06:30.42 | 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 |
| 06:31.03 | zeq1 | I need to fix my email server first |
| 06:31.18 | zeq1 | hopefully that won't take long |
| 06:31.20 | zeq1 | ... |
| 06:31.32 | freemangordon | if you wish, send the rationale to me, and I will forward to maemo-developers with request for a meeting |
| 06:32.03 | freemangordon | we are talking about kernel-cssu,pselect and glibc. Do I miss something? |
| 06:32.36 | zeq1 | I suppose it's generally updating the whole distribution |
| 06:33.15 | zeq1 | get it tracking debian again |
| 06:33.28 | freemangordon | well, don't write THAT, there are tender souls around :D:D:D |
| 06:33.30 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 06:33.41 | freemangordon | aah, Pali, good morning |
| 06:33.50 | zeq1 | morning Pali |
| 06:34.09 | freemangordon | Pali: would you read the backscroll for the last ~20 minutes |
| 06:36.01 | freemangordon | in the meantime: libcurl3 in CSSU seems to work, though its packaging needs some tweaking |
| 06:39.56 | Pali | new libc: it should go to cssu-devel and if it does not break apps then it could also go to cssu-stable |
| 06:40.28 | freemangordon | yeah, that is the general idea |
| 06:40.42 | jonwil | there are too many packages that we cant upgrade due to ties to binaries |
| 06:40.49 | jonwil | e.g. we cant upgrade PulseAudio at all |
| 06:41.02 | freemangordon | I suspect gstreamer too |
| 06:41.12 | jonwil | yeah most likely |
| 06:41.21 | 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 |
| 06:41.24 | jonwil | gstreamer because of the binary camera bits |
| 06:41.38 | freemangordon | Pali: are you available this evening? |
| 06:41.45 | 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. |
| 06:42.01 | Pali | I deleted BME + disabled mounting eMMC (eMMC with new kernel and new qemu does not working) |
| 06:42.14 | Pali | but on real n900 meego kernel has no problem with eMMC |
| 06:42.39 | jonwil | I dont think that we need to waste effort backporting stuff to current libc |
| 06:42.46 | jonwil | we should stick with current libc in cssu-stable |
| 06:43.00 | jonwil | and just bring in latest libc into cssu-devel |
| 06:43.21 | Pali | zeq, if new libc does not break anything (or you fix apps which it breaking) I do not care about it |
| 06:43.39 | zeq | jonwil: trouble is we're already building with new toolchains |
| 06:44.00 | freemangordon | well,well, lets organize a meeting and discuss then ;) |
| 06:44.08 | Pali | ok |
| 06:44.17 | zeq | (cssu release for pselect() doesn't have any downside IMO) |
| 06:44.31 | freemangordon | Pali: do you have free time this evening for such a meeting? |
| 06:44.43 | Pali | maybe yes |
| 06:44.55 | Pali | I will try to find time |
| 06:45.28 | freemangordon | 7 UTC? |
| 06:45.32 | Pali | but if it will be only about libc, I'm fine with any solution as written ^^^^ |
| 06:45.57 | Pali | too late |
| 06:46.06 | freemangordon | Pali: it will be about lots of stuff, includeing libc, kernel-cssu, new tollchain, etc |
| 06:46.20 | freemangordon | Pali: when then? |
| 06:46.23 | freemangordon | 6? |
| 06:46.51 | Pali | 18:00 UTC should be ok |
| 06:46.52 | freemangordon | I am ok with 6, but it could be too early for the others. |
| 06:47.16 | freemangordon | zeq1: jonwil: ^^^ ? |
| 06:47.23 | zeq | fine for me |
| 06:47.24 | freemangordon | is that ok for you? |
| 06:48.01 | jonwil | Is there a reason I need to be in on any of this meeting stuff? |
| 06:48.11 | freemangordon | only if you wish |
| 06:48.19 | zeq | jonwil: you seem interested :) |
| 06:48.24 | freemangordon | yeah |
| 06:48.44 | jonwil | How many hours from now would that meeting be? |
| 06:48.45 | 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 |
| 06:48.52 | zeq | you've actually been pushing quite hard for replacing the closed bits, which isn't unrelated |
| 06:49.00 | zeq | jonwil: ^ |
| 06:49.05 | jonwil | yeah thats true |
| 06:49.17 | Pali | I have already program which can extract kernel version from kernel zImage |
| 06:49.26 | jonwil | I am much into closed-bits-repleacement |
| 06:49.39 | jonwil | so how many hours from now would it be? I am not good with timezones :P |
| 06:49.52 | Pali | I can add support to detect uboot version |
| 06:50.08 | freemangordon | Pali: by the time you install u-boot, you will already have at least one kernel-flasher wich provides kernel-feature-... |
| 06:50.40 | freemangordon | jonwil: I thing about 9 hours from now, correct? |
| 06:50.44 | freemangordon | *think |
| 06:50.54 | freemangordon | aah, no, 11 hours |
| 06:51.02 | freemangordon | Pali: ^^^ ? |
| 06:51.09 | freemangordon | I am not good too :) |
| 06:51.12 | zeq | jonwil: UTC is the zero timezone |
| 06:51.20 | jonwil | ok |
| 06:51.23 | zeq | so just use your tz adjustment |
| 06:51.26 | freemangordon | jonwil: which timezone you are |
| 06:51.28 | freemangordon | ? |
| 06:51.36 | freemangordon | WEST? |
| 06:51.39 | Pali | and ask that flashing question only if kernel version string change (eg. from kernel to kernel-power or to kernel-cssu) |
| 06:51.40 | jonwil | yeah Western Australia |
| 06:52.07 | zeq | jonwil: already evening there then? :) |
| 06:52.14 | Pali | my time is: Thu, 02 Aug 2012 08:52:06 +0200 |
| 06:52.59 | freemangordon | jonwil: try that http://www.worldtimeserver.com/ |
| 06:53.05 | jonwil | its currently 2pm here |
| 06:53.19 | Pali | I have some news about lirc kernel driver |
| 06:53.35 | Pali | original nokia dev now rewriting that driver for upstream kernel |
| 06:53.42 | freemangordon | great |
| 06:53.44 | Pali | and he will upstream it |
| 06:53.47 | Pali | git repo: http://git.itanic.dy.fi/?p=linux-stable;a=shortlog;h=refs/heads/rx51_ir |
| 06:53.48 | jonwil | lirc is? |
| 06:53.54 | freemangordon | infrared |
| 06:53.56 | jonwil | ok |
| 06:54.03 | freemangordon | iirc |
| 06:54.11 | jonwil | I didn't know RX-51 had IR |
| 06:54.19 | freemangordon | WHAT?!? |
| 06:54.24 | freemangordon | hehe |
| 06:54.25 | freemangordon | :P |
| 06:54.39 | zeq | jonwil: UTC +0800 |
| 06:54.53 | Pali | one big problem in upstream kernel is that there missing camera code |
| 06:55.02 | freemangordon | too bad, 2 AM |
| 06:55.20 | jonwil | hey, I have no problems being at a 2am meeting :P |
| 06:55.26 | freemangordon | great |
| 06:55.30 | jonwil | I have stayed up to 4am at times doing N900 hacking and work :P |
| 06:55.45 | freemangordon | Pali: but there were some bits upstreamed iirc |
| 06:55.55 | Pali | camera not |
| 06:56.01 | freemangordon | or there was a team preapring it for upstreaming |
| 06:56.09 | freemangordon | hmm |
| 06:56.16 | Pali | yes, code is prepaired for 2.6.37+ |
| 06:56.27 | Pali | but it was not upstreamed |
| 06:56.33 | Pali | http://elinux.org/N900 |
| 06:56.49 | zeq | so where did the code go? |
| 06:57.01 | freemangordon | anyway, zeq, will you write that mail and send it to me, I will forward it to maemo-developers |
| 06:57.23 | freemangordon | zeq: it is there, but never sent for upstreaming |
| 06:57.26 | Pali | zeq, code is in meego/nemo 2.6.37+ kernel |
| 06:57.45 | freemangordon | Pali: btw there was 3.2 branch too iirc |
| 06:57.55 | Pali | ok |
| 06:57.56 | freemangordon | including camera |
| 06:58.34 | Pali | need to ask on omap kernel mailinglist what is problem with upstreaming |
| 06:58.59 | Pali | also still missing omap_ssi driver |
| 06:59.20 | Pali | I'm going to write email what is problem with omap_ssi |
| 06:59.48 | zeq | Pali: is that the only missing driver? |
| 06:59.57 | Pali | no |
| 07:00.04 | Pali | see http://elinux.org/N900 |
| 07:00.13 | freemangordon | GPS too, but there is some code floating over the inet |
| 07:00.31 | freemangordon | Pali: is charger driver upstreamed? |
| 07:00.33 | Pali | gps is userspace |
| 07:00.40 | Pali | not yet |
| 07:00.53 | freemangordon | hmm, but what was that driver then? |
| 07:00.57 | freemangordon | GPS I mean |
| 07:01.04 | jonwil | GPS is all userspace handled through cellular modem |
| 07:01.21 | Pali | gps is implemented via AF_PHONET |
| 07:01.31 | jonwil | I actually have the .h file for communication with the GPS parts of the cellular model |
| 07:01.35 | jonwil | modem |
| 07:01.37 | freemangordon | there was a kernel module a nokian was trying to upstream |
| 07:01.53 | Pali | omap_ssi |
| 07:01.59 | freemangordon | for GPS |
| 07:02.10 | Pali | omap_ssi is needed for modem |
| 07:02.22 | Pali | gps should go to gpsd or ofono |
| 07:02.26 | zeq | no bluetooth? |
| 07:02.29 | Pali | not to kernel |
| 07:02.36 | Pali | yes, bluetooth + fm radio missing to |
| 07:02.51 | zeq | kind of important |
| 07:03.22 | Pali | I asked nokia devs about it, but they told me that they do not want to upstream it |
| 07:03.43 | zeq | great |
| 07:04.08 | zeq | http://svn.jacekowski.org/host_mode/trunk/drivers/media/radio/radio-bcm2048.c |
| 07:04.20 | Pali | zeq, bluetooth is in meego kernel |
| 07:04.37 | Pali | and also in that 3.x |
| 07:04.59 | zeq | ok |
| 07:05.09 | freemangordon | zeq: did you miss my question re email? |
| 07:05.24 | zeq | freemangordon: I'll get onto it :) |
| 07:05.28 | freemangordon | ok |
| 07:06.15 | freemangordon | lets hope merlin1991 and chem|st are available. It will be good if MohammadAG joins too. |
| 07:33.33 | zeq | freemangordon: I need your email address :) |
| 07:33.49 | freemangordon | hmm |
| 07:33.54 | freemangordon | freemangordon@abv.bg |
| 07:34.30 | zeq | I just sent you an email from my gmail account |
| 07:34.34 | freemangordon | ok |
| 07:36.53 | freemangordon | I will forward it (with additional comments if needed) to maemo-developers and maybe to maemo-community mailinglists |
| 07:37.45 | zeq | ok :) |
| 08:29.50 | jon_y | Pali: hey any changes with the uboot/kernel problem last week? |
| 08:30.16 | Pali | jon_y, I do not remember problem |
| 08:31.06 | jon_y | boot problems with different hw revisions? |
| 08:32.08 | jon_y | Pali: wasn't there some sort of off by one issue? |
| 08:32.36 | Pali | ah, problem that uboot cannot boot kernel... |
| 08:32.47 | Pali | problem is that I cannot reproduce this problem |
| 08:32.53 | Pali | so I do not know how to fix it... |
| 08:32.55 | jon_y | :( |
| 08:33.22 | jon_y | it'll be awesome if it was fixed with the kp51 release |
| 08:33.47 | Pali | again, can you describe your problem? |
| 08:34.20 | jon_y | with uboot loading the kernel, iirc it has problems reading the nand block |
| 08:34.42 | jon_y | let me see if I can find the error message |
| 08:35.31 | jon_y | Pali: sorry, pastebin went missing |
| 08:35.58 | jon_y | if I load the kernel with the flasher, it works, sometimes |
| 08:36.41 | jon_y | Pali: reminds you of anything? |
| 08:37.14 | Pali | and only kernel-power not worked or also nokia stock? |
| 08:37.26 | jon_y | same for nokia stock |
| 08:37.29 | Pali | do you mean problem with corrupted ubifs? |
| 08:37.54 | jon_y | well, the ubifs was actually fine if using the recovery image |
| 08:38.14 | jon_y | the uboot from nokia pr1.3 seems to be unaffected |
| 08:40.44 | jon_y | well, the nokia uboot |
| 08:40.51 | freemangordon | ok, mail sent, waiting for the shitstorm :D |
| 08:41.30 | jon_y | freemangordon: appropriate image macro is prudent :) |
| 08:47.48 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 08:49.50 | *** join/#maemo-ssu andre__ (~andre@ip-89-176-24-140.net.upcbroadband.cz) |
| 08:49.50 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
| 08:50.10 | freemangordon | merlin1991: ping |
| 08:54.50 | *** join/#maemo-ssu jonwil (~jonwil@27.33.137.199) |
| 09:17.10 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
| 09:17.10 | *** join/#maemo-ssu povbot (~supybot@office.pov.lt) |
| 09:17.10 | *** join/#maemo-ssu trumee (~parul@188-222-165-248.zone13.bethere.co.uk) |
| 09:17.10 | *** mode/#maemo-ssu [+v povbot] by niven.freenode.net |
| 09:27.09 | *** join/#maemo-ssu ChanServ (ChanServ@services.) |
| 09:27.09 | *** mode/#maemo-ssu [+o ChanServ] by niven.freenode.net |
| 09:28.30 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 09:35.22 | *** join/#maemo-ssu luf (luf@nat/ibm/x-fjdijwxxbvdjsuyv) |
| 09:46.33 | *** join/#maemo-ssu zeq1 (~s_j_newbu@2a01:348:1e3:1:e6ec:10ff:fe9a:d418) |
| 09:54.48 | *** join/#maemo-ssu arcean (~Arcean@aacw38.neoplus.adsl.tpnet.pl) |
| 09:58.51 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 10:09.21 | *** join/#maemo-ssu ivgalvez (~ivgalvez@89.140.113.138.static.user.ono.com) |
| 10:09.34 | ivgalvez | freemangordon ping |
| 10:35.10 | *** join/#maemo-ssu Jaffa (~andrew@Maemo/community/contributor/Jaffa) |
| 10:39.27 | freemangordon | ivgalvez: pong |
| 10:43.56 | *** join/#maemo-ssu freemangordon_ (~freemango@213.226.63.191) |
| 10:51.29 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 10:52.25 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
| 10:56.41 | *** join/#maemo-ssu freemangordon_ (~freemango@213.91.217.232) |
| 11:37.20 | ivgalvez | fremangordon: considering closed source applications that can be potentially broken by system upgrades (kernel, glibc...) |
| 11:37.25 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-maeouzheidphyprz) |
| 11:37.53 | ivgalvez | AFAIK, we only have two of them Joikuspot and BlessN900/A Better Camera |
| 11:38.34 | ivgalvez | the first one has an open source equivalent, in fact a superior solution in Mobile Hotspot |
| 11:38.49 | ivgalvez | and the latter, as you pointed some time ago, might be violating the GPL |
| 11:39.44 | ivgalvez | I'll try to reach BleasN900 developer and ask him for sources |
| 12:05.03 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 12:06.30 | *** join/#maemo-ssu freemangordon_ (~freemango@printec.bg) |
| 12:07.37 | freemangordon | ivgalvez: AFAIK BlessN900/ABC work ok with KP/KCSSU, could you elaborate? |
| 12:09.17 | freemangordon | merlin1991: ping |
| 12:15.27 | ivgalvez | I was referring to the possible case of upgrading KP Mer/Nemo version |
| 12:15.32 | ivgalvez | with ABI break |
| 12:16.34 | freemangordon | aah, ok. well, that will happen last, if ever. That is why some discussion about the future is needed |
| 12:16.52 | freemangordon | aotherwise, besides kernel version upgrade, ABI shouldnot break |
| 12:17.38 | ivgalvez | OK,the question is that there is not much stuff to break |
| 12:20.20 | freemangordon | yeah, that is for sure. |
| 12:20.58 | freemangordon | BTW even BlessN900/ABC should be ok, as (afaik) fcam drivers are foss. are they? |
| 12:21.48 | ivgalvez | yes for Fcam drivers |
| 12:22.19 | ivgalvez | but A Better Camera uses dsp for image processing and I don't know if that could be problematic |
| 12:23.19 | ivgalvez | Do you know if Mer kernel has Vsync support? |
| 12:23.40 | ivgalvez | that would be a single valid reason to upgrade |
| 12:23.40 | freemangordon | ivgalvez: we are already on 2.6.37 re DSP (in KP) ;) |
| 12:23.51 | ivgalvez | great |
| 12:24.02 | ivgalvez | that shouldn't be a problem then |
| 12:24.16 | freemangordon | yes, but that is not so simple, the poblem will come with GLES drivers |
| 12:24.35 | freemangordon | SGX drivers that is |
| 12:24.56 | ivgalvez | but SGX driver from TI is supporting newer Linux versions |
| 12:26.22 | freemangordon | sure, that I am saying is that it is not a trivial task |
| 12:27.56 | freemangordon | s/that I/what I/ |
| 12:30.34 | ivgalvez | you make non trivial tasks quite easily ;-) |
| 12:35.52 | freemangordon | :) |
| 12:39.19 | freemangordon | wow, arcean cloned h-d today |
| 12:39.49 | freemangordon | finally, a saturated thumbnails in tasknav |
| 12:39.54 | freemangordon | is dancing |
| 12:41.09 | kerio | huh? |
| 12:41.17 | kerio | desaturated? |
| 12:45.31 | freemangordon | yep, when closing an application , the thumbnail will become desaturated;) |
| 12:46.02 | kerio | ...i don't get it |
| 12:46.04 | kerio | what? |
| 12:46.09 | freemangordon | you will see it |
| 12:46.17 | kerio | when *closing*? |
| 12:46.24 | freemangordon | it is for good, trust me on that (tm) |
| 12:46.58 | Raimu | Does it desat even when x is hit when fullscreen? |
| 12:47.06 | 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? |
| 12:47.12 | Raimu | And then zoomed back to thumbnails? |
| 12:47.32 | Raimu | freemangordon ^ |
| 12:47.36 | freemangordon | Raimu: NFC how it works, it is only arcean who knows the details. |
| 12:47.47 | freemangordon | But that is waht was agreed |
| 12:48.45 | freemangordon | kerio: all that stuff is handled in h-d and mb2, bot are foss |
| 12:48.53 | freemangordon | *both |
| 12:49.07 | kerio | yay foss ^___^ |
| 12:49.14 | freemangordon | if you think somethng does not behave correctly, file a bug |
| 12:49.18 | freemangordon | ;) |
| 12:50.10 | kerio | well i just assumed it was intended to make stuff lighter |
| 12:51.36 | Raimu | freemangordon: Available soon? |
| 12:53.08 | kerio | Raimu: probably in cssu-freemangordon |
| 12:53.27 | kerio | also known as cssu-thumb |
| 12:53.52 | freemangordon | Raimu: ask arcean, not me :) |
| 12:54.13 | freemangordon | he cloned the repo, does not commit anything ;) |
| 12:55.11 | zeq | freemangordon: I'll need to update my h-d build :) |
| 12:56.42 | 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... |
| 13:24.31 | Raimu | arcean: Are you of the mindset to make the desat Hildon available soon? ^^^ |
| 14:08.10 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 14:09.42 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:28.04 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 14:28.23 | freemangordon | merlin1991: ping |
| 14:39.50 | merlin1991 | freemangordon: pong |
| 15:11.11 | *** join/#maemo-ssu toxaris (~toxaris@90-230-114-186-no34.tbcn.telia.com) |
| 15:13.52 | *** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG) |
| 15:20.49 | *** join/#maemo-ssu kolp (~quassel@212.255.29.21) |
| 15:24.05 | kolp | Hi, just curious, what would be the deal-breaker obstacles when trying to rewrite the N900's phone app? |
| 15:38.26 | *** join/#maemo-ssu Estel_ (~Estel@abrq47.neoplus.adsl.tpnet.pl) |
| 15:47.45 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 15:51.30 | *** join/#maemo-ssu luf (luf@nat/ibm/x-pnukguyztydtknia) |
| 15:55.45 | *** join/#maemo-ssu NIN101 (~NIN@p5DD29797.dip0.t-ipconnect.de) |
| 15:56.21 | jonwil | kolp, the biggest problem is understanding all the external things that the phone app talks to including the nightmare that is Telepathy |
| 15:57.19 | 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 |
| 15:57.59 | 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 |
| 15:58.10 | kolp | jonwil: Does it use telepathy for ordinary (radio) calls, too? Or just SIP/Skype/etc |
| 15:58.18 | kolp | jonwil: Yes, I thought so :) |
| 15:59.03 | jonwil | telepathy for all calls |
| 15:59.11 | kolp | And both are in the "definitely need replacement" category, too :) |
| 15:59.18 | kolp | Ok :/ |
| 15:59.21 | jonwil | The massive binary blob that is Telepathy-Ring is a big part of the problem |
| 15:59.42 | jonwil | its what handles voice and SMS |
| 15:59.48 | jonwil | and what talks to the cellular services daemon |
| 16:01.09 | kolp | re: browser, I'd guess that's just dbus calls to the phone app? |
| 16:04.44 | jonwil | yes I would imagine so |
| 16:06.17 | kolp | Ok, thanks for all the info |
| 16:13.54 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 16:14.50 | *** join/#maemo-ssu arcean (~Arcean@aacz223.neoplus.adsl.tpnet.pl) |
| 16:18.10 | amiconn | freemangordon: I am using ABC on KP. It *sort of* works |
| 16:19.32 | 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 (!)) |
| 16:20.28 | amiconn | Strangely enough this problem vanishes when zooming. I also have fcam drivers installed (and FCamera as well) in case that matters |
| 16:24.03 | freemangordon | merlin1991: MohammadAG: I hope you have some free time at about 18:00 UTC :) |
| 16:24.55 | jonwil | 'I will be around for this meeting even though its 2am my time :) |
| 16:25.03 | freemangordon | yah :) |
| 16:25.26 | jonwil | still cant decide what N900 work to do next |
| 16:25.28 | freemangordon | chem|st: what about you? |
| 16:26.23 | luf | freemangordon: What do you mean with "libcurl3 in CSSU seems to work, though its packaging needs some tweaking" |
| 16:28.20 | jonwil | Already ruled out bootloader, kernel, GPU, cell modem, dialer, browser, messaging, telepathy and skype |
| 16:30.27 | *** join/#maemo-ssu mase76 (~mase76@p5DD3BAB0.dip.t-dialin.net) |
| 16:36.42 | luf | freemangordon: ping |
| 16:37.00 | freemangordon | luf: pong |
| 16:37.26 | luf | Can you answer my question few lines above? |
| 16:37.41 | freemangordon | just a second |
| 16:37.44 | luf | Ok. |
| 16:43.50 | freemangordon | luf: for example it is missing dh_clean -k in clean: section of debian/rules |
| 16:45.06 | freemangordon | also I think source package includes unnecessarry stuff |
| 16:45.51 | freemangordon | the onther thing is the way pathces are applied, why several quilt push commands? |
| 16:46.05 | freemangordon | s/onther/other/ |
| 16:46.26 | amiconn | There are more typos... |
| 16:46.38 | freemangordon | yeah :) |
| 16:46.46 | luf | freemangordon: because as few changes from debian package as possible. |
| 16:46.55 | luf | It's the best way to maintain such package. |
| 16:47.22 | luf | I don't think it's important to have source as small as possible. |
| 16:47.58 | 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 |
| 16:48.19 | merlin1991 | freemangordon: dh_clean is called elsewhere |
| 16:48.43 | merlin1991 | hm it's a part if install |
| 16:48.46 | merlin1991 | this package is weird |
| 16:48.49 | luf | freemangordon: I took debian package from debian wheezy :) |
| 16:49.18 | freemangordon | merlin1991: fakeroot debian/rules clean does not clean debian[package_name] directories, which is very strange |
| 16:49.24 | luf | Ok. debian rulez and so is mix of debian package and original maemo package. |
| 16:50.00 | freemangordon | luf: don't get me wrong, it is not a major problem, that is why i used "tweaking" :) |
| 16:50.43 | luf | I welcome all comments. It's the way I can improve (curl and myself too). I'm very new to debian packaging. |
| 16:51.42 | luf | freemangordon: no dh_clean in clean section (debian wheezy package). |
| 16:52.01 | freemangordon | luf: which debheler version is that? |
| 16:52.04 | freemangordon | 7? |
| 16:52.26 | freemangordon | what is in debian/compat? |
| 16:52.48 | merlin1991 | the wheezy package has debhelper 9 afaik |
| 16:53.01 | freemangordon | well, that could explain it |
| 16:53.07 | luf | Yes. merlin1991 lowered it. |
| 16:53.13 | merlin1991 | luf reworked it for debhelper 7, and I reworked it to debhelper 5 :D |
| 16:53.25 | freemangordon | good :D |
| 16:53.44 | merlin1991 | though I didn't make sure that all the commands do what they should do |
| 16:53.50 | merlin1991 | only that a build is possible :D |
| 16:54.24 | freemangordon | well, it builds and installs and the most important: works :D |
| 16:54.43 | freemangordon | though binary is way bigger than stock |
| 16:55.02 | freemangordon | anyway, i'll look into it these days |
| 16:55.12 | luf | http://anonscm.debian.org/gitweb/?p=collab-maint/curl.git;a=tree;f=debian;h=eb2c116a48d4e881129a96d1564854e0b416b44b;hb=HEAD |
| 16:55.31 | freemangordon | to be the next one to rork on it, who knows, maybe I will rework it for debhelper 4 :D |
| 16:55.45 | jonwil | is bored :( |
| 16:55.56 | luf | No you have to rework to debhelper 3 ... you have too keep the line :D |
| 16:56.05 | zeq | I'm been looking at upgrading debhelper, it's on my TODO list |
| 16:56.16 | zeq | s/I'm/I've/ |
| 16:56.27 | luf | There is debhelper 7 in extras ... |
| 16:56.38 | merlin1991 | zeq: upgrading debhelper is easy |
| 16:56.39 | zeq | I know |
| 16:56.55 | merlin1991 | upgrading all packages to use the new features of a newer debhelper, that is not so easy :D |
| 16:57.09 | luf | freemangordon:what means way bigger? Can you be more precise? |
| 16:57.34 | freemangordon | luf: lemme check the exact values |
| 16:59.06 | zeq | It's quite funny with debhelper from various debian dists, the newer packages tend to be written to use the version they install! |
| 17:01.42 | merlin1991 | afaik debhelper should be backwards compatible |
| 17:02.12 | 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 |
| 17:02.46 | freemangordon | some new functionality included? |
| 17:03.43 | luf | Take a look into change log since 7.18 to 7.26 :D |
| 17:04.21 | freemangordon | yeah, sure :) |
| 17:05.21 | luf | BTW I can base debian dir for curl on maemo package instead of debian one. |
| 17:05.31 | freemangordon | merlin1991: you are here around 18:00 UTC? maybe you missed that, but there will be a meeting :P |
| 17:05.47 | merlin1991 | I'll be here :D |
| 17:06.21 | freemangordon | merlin1991: you receive mails from maemo-developers, correct? |
| 17:06.55 | merlin1991 | yes |
| 17:07.00 | freemangordon | luf: give me a chance to contribute to that, ok? :P |
| 17:07.19 | luf | freemangordon: Ok. as you wish. |
| 17:07.32 | *** join/#maemo-ssu mr_jrt (~j@188-222-192-181.zone13.bethere.co.uk) |
| 17:07.53 | merlin1991 | luf, freemangordon: I think the current debian rules in our curl package is okish |
| 17:08.26 | luf | merlin1991: sure you worked on it :D |
| 17:10.00 | freemangordon | merlin1991: well, ok, if you say so :D |
| 17:10.27 | merlin1991 | but we can ofc work on it to be better :D |
| 17:12.36 | freemangordon | BTW does curl use any FP? |
| 17:14.22 | freemangordon | luf: ^^^ ? |
| 17:18.09 | merlin1991 | what's the highest signal for kill? |
| 17:18.18 | merlin1991 | got a rogue java process on my server THAT WON'T DIE |
| 17:19.10 | zeq | KILL == 9 |
| 17:19.20 | luf | freemangordon: what is FP? |
| 17:19.27 | merlin1991 | floating point |
| 17:20.08 | luf | freemangordon: I have no idea. I didn't study the curl so deep. |
| 17:22.24 | kerio | merlin1991: define highest |
| 17:22.51 | kerio | sigusr2 is pretty high, but it's probably not what you want |
| 17:22.54 | merlin1991 | kerio: something that cannot be caught and equals the kernel using the banhammer |
| 17:23.14 | kerio | sigkill can't be caught unless you're init |
| 17:23.20 | kerio | even then, it's just ignored |
| 17:23.29 | kerio | not exactly caught |
| 17:23.45 | kerio | surprisingly enough, sigstop also can't be catched |
| 17:23.57 | kerio | or, rather, you can but only after you cont |
| 17:23.59 | merlin1991 | and what is sigterm? |
| 17:24.32 | luf | sigterm is for graceful termination of process. |
| 17:24.49 | luf | So it should be handled by the process. |
| 17:25.42 | luf | Process is able to run all atexit function (see man atexit). |
| 17:26.36 | kerio | <merlin1991> kerio: something that cannot be caught and equals the kernel using the banhammer |
| 17:26.44 | kerio | sigterm is definetely not that |
| 17:26.55 | *** join/#maemo-ssu javispedro (~javier@Maemo/community/contributor/javispedro) |
| 17:27.12 | merlin1991 | so sigkill is the highest option? |
| 17:27.31 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 17:27.59 | luf | merlin1991: yes. It's the highest option to kill the process. |
| 17:29.37 | freemangordon | luf, we should check that, as if it uses floating point, the compiler option -mfpu=vfp/neon is missing |
| 17:30.02 | freemangordon | and AFAIK gcc defaults to -mfpu=none |
| 17:30.36 | zeq | unless you're using my linaro toolchain |
| 17:31.04 | luf | freemangordon: I didn't take into my mind to use the best options as N900 has the same HW for everyone. |
| 17:31.08 | freemangordon | well, afaik it is not CSSU "official" toolchain :P |
| 17:31.37 | luf | Is there some wiki page with gcc options for N900? |
| 17:32.14 | freemangordon | luf: those are not n900 options, but Cortex-A8 with vfp and neon |
| 17:32.24 | freemangordon | luf: nevermind, I will check that |
| 17:33.45 | luf | freemangordon: can you then send me the result so I can do it better next time? |
| 17:34.57 | 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. |
| 17:35.20 | freemangordon | *hurt |
| 17:35.27 | freemangordon | damn typos |
| 17:35.29 | luf | I think you know more such flags ... |
| 17:35.45 | freemangordon | you will see the commit ;) |
| 17:35.58 | luf | Ah sure. |
| 17:36.30 | freemangordon | BTW ARM options are described in gcc documentation |
| 17:37.28 | freemangordon | luf: and that was not meant to be "RTFM: :D |
| 17:38.14 | luf | To be honest I don't want invest my life to reading gcc docs :) |
| 17:38.28 | zeq | My N900 has taken to forgetting the time on reboot! O_o |
| 17:39.06 | zeq | The battery was loose previously (that's why I had some trouble the other day) |
| 17:39.56 | freemangordon | zeq: you have the same problem everyone has (excluding those who changed clock battery with a capacitor) ;) |
| 17:40.32 | zeq | it used to be okay as long as the battery wasn't removed, now not even that. |
| 17:41.52 | zeq | I wonder if it's because I pressed the power button in the backupmenu menu? |
| 17:44.32 | *** join/#maemo-ssu ivgalvez (5531c703@gateway/web/freenode/ip.85.49.199.3) |
| 17:46.01 | jonwil | When does this meeting start? |
| 17:47.51 | merlin1991 | 15 mins I guess |
| 17:48.04 | jonwil | ok |
| 17:49.10 | jonwil | I will be there to put forward my point of view :) |
| 17:50.22 | kerio | meeting regarding what? |
| 17:50.26 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
| 17:50.39 | zeq | the future |
| 17:51.04 | freemangordon | the question to the 42 answer ;) |
| 17:51.13 | kerio | thumb+kernel-power+linaro |
| 17:51.28 | freemangordon | you're missing glibc |
| 17:51.44 | jonwil | maybe I can finally find out if anyone actually cares about my work to e.g. replace wl1251-cal |
| 17:51.55 | kerio | oh right |
| 17:52.27 | kerio | thumb+kernel-power+linaro+glibc+openmediaplayer |
| 17:52.34 | kerio | my .02 on that |
| 17:52.50 | freemangordon | no OMP, it is a different kind of beer |
| 17:52.50 | ivgalvez | +worldclock replacement |
| 17:52.57 | kerio | freemangordon: it's really nice beer! |
| 17:53.00 | freemangordon | this one too :P |
| 17:53.05 | freemangordon | ivgalvez: ^^^ |
| 17:53.23 | kerio | also flash 10 from the internal nokia repo |
| 17:53.30 | kerio | which i still don't have, btw :( |
| 17:53.34 | ivgalvez | shhh |
| 17:54.17 | *** part/#maemo-ssu luf (luf@nat/ibm/x-pnukguyztydtknia) |
| 17:56.05 | zeq | flash replacement would be better through a FOSS implementation |
| 17:56.36 | kerio | ...no it wouldn't |
| 17:56.38 | freemangordon | zeq: forget about flash, lets make webm work in fennec :P |
| 17:56.39 | kerio | gnash only gets so far |
| 17:56.40 | jonwil | if FOSS flash replacements were good enough, everyone would be using Gnash |
| 17:57.12 | zeq | lightspark exists too... although I do of course agree with freemangordon |
| 17:57.24 | zeq | :) |
| 17:58.57 | *** join/#maemo-ssu _rd (~rd@p57B497F2.dip0.t-ipconnect.de) |
| 17:58.59 | kerio | could we ship jacekowski's modified fmtxd? |
| 18:01.08 | freemangordon | hmm , where is Pali? |
| 18:01.36 | zeq | missing :( |
| 18:02.01 | freemangordon | well, I think he'll join. Soon or later :) |
| 18:02.20 | zeq | good news is I've build libc now with working inline support |
| 18:02.35 | zeq | s/build/built/ |
| 18:02.43 | freemangordon | inline support? |
| 18:03.11 | freemangordon | you mean libc functions to be inlined? |
| 18:03.41 | zeq | c89/c99 std inlines |
| 18:03.46 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 18:03.46 | freemangordon | aah, ok |
| 18:03.55 | kerio | Pali! |
| 18:03.57 | kerio | ^_^ |
| 18:03.58 | freemangordon | zeq: toldya :D |
| 18:04.05 | zeq | :) |
| 18:04.07 | kerio | shame, i gotta go in a bit |
| 18:04.08 | zeq | hi Pali |
| 18:04.11 | Pali | hi |
| 18:04.18 | freemangordon | merlin1991: here? |
| 18:04.22 | merlin1991 | is here |
| 18:04.36 | kerio | anyway, my worthless 0.02 on kernel-power+thumb+glibc+linaro sdk+bme replacement |
| 18:04.39 | kerio | cya guys |
| 18:04.52 | zeq | bye kerio |
| 18:05.09 | freemangordon | MohammadAG: arcean: chem|st: DocScrutinizer05: whoever wants: here? |
| 18:05.56 | freemangordon | aah, doc is on holiday :( |
| 18:06.02 | freemangordon | now I remember |
| 18:06.20 | zeq | he said he's keeping his N900 connected ;) |
| 18:06.21 | freemangordon | merlin1991: shall we start? |
| 18:06.41 | freemangordon | well, lets try then |
| 18:06.45 | freemangordon | DocScrutinizer: ping |
| 18:06.49 | freemangordon | DocScrutinizer51: ping |
| 18:07.03 | *** join/#maemo-ssu Estel_ (~Estel@Maemo/Community/council/Estel-) |
| 18:07.04 | zeq | DocScrutinizer05: ping |
| 18:07.30 | Pali | try number 42 :-) |
| 18:07.34 | zeq | It's a shame he isn't here :( |
| 18:07.39 | Estel_ | hello, is meeting ongoing? |
| 18:07.50 | zeq | Estel_: just about to start |
| 18:08.07 | Estel_ | freemangordon, honestly, you could send invitation at least 2 days before ;) |
| 18:08.20 | Estel_ | DocScrutinizer is on vacation for a week |
| 18:08.37 | freemangordon | Estel_: usual suspect are here, and I just forgot doc is on a vacation |
| 18:08.49 | freemangordon | s/suspect/suspects/ |
| 18:08.50 | Estel_ | nod |
| 18:09.06 | Estel_ | I know it wouldn't be much of a loss, but I was able to read invitation 30 seconds ago |
| 18:09.08 | Estel_ | ;p |
| 18:09.19 | freemangordon | ususlly he is available all the time, but anyweay we know his position |
| 18:09.20 | zeq | Glad you made it |
| 18:09.29 | 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 |
| 18:09.30 | Estel_ | thanks, zeq :) |
| 18:09.43 | Estel_ | agree with freemangordon. DocScrutinizer position is quite clear, to say at least |
| 18:10.02 | zeq | yes, certainly regarding -stable |
| 18:10.27 | zeq | Shall we begin |
| 18:10.30 | zeq | ? |
| 18:10.41 | freemangordon | why not |
| 18:10.43 | ivgalvez | just in case, I support absolutely all opinions from freemangordon |
| 18:10.52 | ivgalvez | see you |
| 18:10.53 | freemangordon | ivgalvez: yeah, right :D |
| 18:10.57 | freemangordon | bb |
| 18:10.59 | zeq | by ivgalvez |
| 18:11.03 | zeq | bye |
| 18:11.16 | freemangordon | merlin1991: here? shall we start? |
| 18:11.18 | Estel_ | hi ivgalvez |
| 18:11.21 | Estel_ | bye ivgalvez, lol |
| 18:11.21 | merlin1991 | still here |
| 18:11.41 | zeq | shall I start? |
| 18:11.48 | jonwil | yes lets start |
| 18:11.50 | freemangordon | ok, I hope everyone has received a mail from maemo-developers |
| 18:12.17 | freemangordon | with a description of why this meeting is needed/wanted/whatever |
| 18:12.27 | freemangordon | anyone unaware? |
| 18:12.54 | merlin1991 | I'll just paste in the points from the mail here: |
| 18:12.54 | merlin1991 | 1. Inclusion of kernel replacement in CSSU (community kernel) and possibilities of a kernel upgrade to a newer version. |
| 18:12.54 | merlin1991 | 2. Upgrade of toolchain used to build CSSU stuff. |
| 18:12.54 | merlin1991 | 3. glibc/kernel pselect() fix and evaluation/planning of glibc upgrade to a newer version. |
| 18:13.14 | freemangordon | yep |
| 18:13.27 | freemangordon | now, point one |
| 18:13.44 | freemangordon | (which is coupled with point 3) |
| 18:13.52 | Estel_ | it seems to me, that point 3 require point 1 anyway? |
| 18:13.54 | Estel_ | nods |
| 18:14.01 | zeq | yes, kernel must come first |
| 18:14.32 | Estel_ | in case someone is unaware, zeq, could You explain in "regular folk understandable language" what is the deal with pselect? |
| 18:14.47 | freemangordon | merlin1991: do you know the pselect() bug we have in libc? |
| 18:15.17 | merlin1991 | I skimmed the bugreport you posted some time ago, but I'd like a refresh |
| 18:15.22 | freemangordon | zeq: yeah, could you make a summary? |
| 18:15.25 | zeq | sure |
| 18:15.32 | freemangordon | you know that way better than me :) |
| 18:16.35 | zeq | pselect() is the solution POSIX came up with to implement event loops using select() without races. |
| 18:16.56 | zeq | it's described here in detail: http://en.wikipedia.org/wiki/Event_loop |
| 18:17.39 | zeq | the problem is glibc decided, for reasons of POSIX.1 compliance to implement pselect() emulation by using select() |
| 18:18.53 | zeq | unfortunately this just prevents safe event loops, since the emulation has the same problem that pselect() was intended to fix |
| 18:19.11 | zeq | once it appeared in glibc, people started using it |
| 18:19.28 | zeq | even though it was unsafe and relatively low performance |
| 18:20.10 | Estel_ | it's worth to mention, that zeq was author of ARM patch for it... something like 5 years ago? I'm right, zeq? |
| 18:20.21 | Estel_ | Am I right, even |
| 18:20.32 | zeq | Yes, I adapted the support from the other arches |
| 18:20.39 | zeq | and posted the patch for inclusion |
| 18:20.48 | zeq | unfortunately it didn't get picked up |
| 18:20.58 | zeq | but this is getting slightly ahead |
| 18:21.31 | zeq | the kernel pselect() was the solution intended by POSIX, but the glibc broken implementation forced the kernel devs hand |
| 18:21.50 | zeq | and they quickly patched most of the arches |
| 18:22.30 | zeq | ARM got forgotten, the syscalls were allocated but never wired up |
| 18:22.47 | zeq | at least until recently |
| 18:22.48 | *** join/#maemo-ssu ivgalvez-N900 (~ivgalvez-@31.4.241.70) |
| 18:22.58 | 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? |
| 18:23.21 | Estel_ | sorry fro broken order of "could You" :) |
| 18:23.25 | zeq | I've back ported the code from upstream, it applied pretty cleanly |
| 18:23.27 | freemangordon | zeq: do you hav elink to the bugreport? |
| 18:23.54 | zeq | I'll have a look |
| 18:24.15 | Estel_ | hello ivgalvez-N900, nice that You've made it :) |
| 18:24.19 | freemangordon | it does noty make sense to repeat it here |
| 18:24.31 | zeq | "pselect() arm missing" gives lots of hits on google |
| 18:24.52 | merlin1991 | zeq: so we have a possible race condition in every eventloop we have? |
| 18:24.53 | jonwil | feels like he has nothing to contribute... |
| 18:24.54 | ivgalvez-N900 | I'm on the move.... But trying |
| 18:24.56 | zeq | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 |
| 18:25.13 | zeq | merlin1991: yes, that's the bug |
| 18:25.28 | 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) |
| 18:25.34 | zeq | It's unknown how often it happens though |
| 18:25.36 | freemangordon | merlin1991: ...that uses pselect() |
| 18:26.15 | zeq | Estel_: anything that uses pselect() is at risk of a race condition |
| 18:26.20 | zeq | this means it can miss signals |
| 18:26.26 | Estel_ | nods |
| 18:26.36 | freemangordon | or deadlock (i.e. hang) |
| 18:26.54 | Estel_ | claims, like one made by teotwaki, few days ago, that this is ultra-rare possibility of happening, are unjustified? |
| 18:27.02 | merlin1991 | and in our case where is this broken, the kernel / glibc, both? |
| 18:27.03 | Estel_ | (it's worth to clear miss-conceptions like that) |
| 18:27.13 | zeq | it depends how often it's called |
| 18:27.16 | freemangordon | merlin1991: AIUI both |
| 18:27.17 | zeq | dbus calls it quite a lot |
| 18:27.49 | 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) |
| 18:27.49 | merlin1991 | Estel_: even if it has a tiny tiny chance of happening, race conditions should *ALWAYS* be fixed |
| 18:27.58 | Estel_ | merlin1991, agree |
| 18:28.31 | freemangordon | Estel_: there is another example in the bugreport: udev. Don;t know if it is applicable to maemo udev though |
| 18:28.39 | 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. |
| 18:29.02 | Estel_ | (like teotwaki did few days ago) |
| 18:29.13 | Estel_ | I think it's important to lert "common folk" know why they need community kernel, too |
| 18:29.21 | merlin1991 | zeq: what changes are needed to get this fixed? |
| 18:29.37 | jonwil | ok, so am I needed here or not? :P |
| 18:29.48 | zeq | merlin1991: I've patched the kernel with missing syscalls (there are two other related syscalls) |
| 18:30.02 | zeq | and glibc needs to be built with a higher min kernel version |
| 18:30.14 | zeq | (currently it's built for 2.6.0) |
| 18:30.25 | freemangordon | jonwil: what? of course you are :). |
| 18:30.28 | jonwil | ok |
| 18:30.34 | merlin1991 | so glibc decides to use the workaround at compiletime? |
| 18:30.35 | jonwil | will hang around then |
| 18:31.08 | jonwil | for a while anyway |
| 18:31.13 | zeq | glibc will always use emulation if the min kernel version is below where it *expected* support to appear |
| 18:31.28 | merlin1991 | and what's that for glibc? |
| 18:31.30 | zeq | unfortunately it gets that wrong for ARM |
| 18:31.33 | jonwil | maybe something relevant to me will be discussed :P |
| 18:32.06 | zeq | jonwil: it will :) |
| 18:32.30 | zeq | glibc also needs the kernel headers with the syscalls enabled |
| 18:32.40 | 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 |
| 18:32.45 | zeq | otherwise it silently fails to provide any pselect() at all |
| 18:32.50 | jonwil | :) |
| 18:33.02 | freemangordon | jonwil: yes |
| 18:33.44 | zeq | running a glibc compiled for a supporting kernel on a kernel without the syscalls will fail |
| 18:34.20 | zeq | so like thumb there is a hard userspace requirement on the kernel version |
| 18:34.44 | zeq | although it doesn't in anyway affect userspace API |
| 18:34.54 | zeq | just glibc |
| 18:35.14 | merlin1991 | so basically we need a patched kernel + recompiled glibc? |
| 18:35.19 | zeq | yes |
| 18:35.34 | zeq | patched kernel works fine with unrecompiled glibc though |
| 18:35.46 | merlin1991 | ofc since it still has select calls |
| 18:35.47 | zeq | or as well as it ever has |
| 18:36.01 | kerio | freemangordon: can that be delivered with minor changes to omap1 and abi compatibility with everything else? |
| 18:36.02 | merlin1991 | glibc is build out of which source package? |
| 18:36.30 | kerio | if we need to break compat, i vote to do that in the most outrageous way |
| 18:36.43 | zeq | glibc-2.5.1-1eglibc27+0m6 |
| 18:37.21 | freemangordon | kerio: we have ABI compatibility in mind |
| 18:37.57 | freemangordon | kerio: though, could you define ABI compatibility |
| 18:38.00 | zeq | kerio: ABI breakage is at least limited to glibc |
| 18:38.02 | Estel_ | kerio, if "will it work with modules from stock, if one flash kernel only" is Your question, then, probably, not |
| 18:38.15 | Estel_ | of course I mean kernel modules from stock, not 3rd party ones |
| 18:38.27 | zeq | DocScrutinizer would possibly argue that point |
| 18:38.58 | freemangordon | well, we have enough expertise here to evaluate |
| 18:38.59 | Estel_ | although, it's worht to mention that no real-life usage, in any case, include flashing new kernel without installing it's modules |
| 18:39.22 | Estel_ | i.e. such situation is purely theoretical, just for sake of doing so, no practical problems risk, ever. 0% chance. |
| 18:39.31 | 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? |
| 18:39.36 | Estel_ | (from my limited knowledge common folk POV, feel free to correct) |
| 18:39.40 | ivgalvez-N900 | Estel_ that's right |
| 18:39.54 | zeq | merlin1991: it doesn't break ABI |
| 18:40.01 | zeq | since the syscalls are reserved |
| 18:40.05 | Pali | merlin1991, depends on what you change... |
| 18:40.10 | Estel_ | merlin1991, agaik, even latest kernel-power-thumb can load 3rd party modules, like fcam or joikuspot |
| 18:40.10 | freemangordon | :nod: |
| 18:40.25 | Estel_ | we're not aware of other such modules in existence |
| 18:40.44 | merlin1991 | well i'm thinkin in terms of -stable atm where if anything we apply a small patchset ontop of the stock kernel |
| 18:41.00 | 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..." |
| 18:41.14 | freemangordon | merlin1991: CSSU did it once |
| 18:41.37 | merlin1991 | freemangordon: I'm not sure I know what you mean |
| 18:41.48 | freemangordon | Qt, remember? It was upgraded for good |
| 18:41.55 | 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... |
| 18:42.10 | Pali | but I think gcc is deterministic |
| 18:42.24 | freemangordon | Pali: yeah, but we know gcc does not do that. at least in SB |
| 18:43.13 | freemangordon | BTW if we don't change exported symbols (or just add new), we should be safe |
| 18:43.37 | 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) |
| 18:43.58 | Pali | if 3rd modules using symbols and not direct address, then it should be ok |
| 18:44.15 | merlin1991 | Estel_: quite simply, because thumb2 requires an upgraded toolchain which is a nogo |
| 18:44.19 | 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. |
| 18:44.20 | zeq | upgraded compiler implication we'll be getting to |
| 18:44.31 | ivgalvez-N900 | Well the upgrade of Qt broke LinkedUp (focus lost) and it was never fixed |
| 18:44.41 | Pali | but other question is: how many 3rd kernel modules we have on maemo? |
| 18:44.41 | ivgalvez-N900 | Not a big deal |
| 18:44.52 | Estel_ | Pali, namely, two modules :P |
| 18:44.57 | freemangordon | Estel_: thats next point in agende, lets move on with the current |
| 18:45.00 | Pali | and how many kernel modules are closed? |
| 18:45.11 | Estel_ | joikuspot, that have BETTER FOSS replacement qtmobilehotspot (and joikuspot works anyway, even with kernel-power)... |
| 18:45.14 | Estel_ | closed one |
| 18:45.19 | freemangordon | ABC has one |
| 18:45.22 | merlin1991 | zeq: what kind of patch for the kernel do you have currently? |
| 18:45.26 | Estel_ | and fcam, which works, even with KP, and is open |
| 18:45.34 | Pali | joikuspot kernel module is GPL - it can be recompiled |
| 18:45.39 | Estel_ | oh, sorry then |
| 18:45.45 | merlin1991 | zeq: meaning based on which version? |
| 18:45.50 | Pali | and fcam is also open (correct me if not) |
| 18:45.54 | Estel_ | freemangordon, zeq, understood (about next point) |
| 18:46.03 | freemangordon | Pali: yes, afaik |
| 18:46.04 | zeq | merlin1991: I directly applied the version that went upstream |
| 18:46.08 | Estel_ | Pali, fcam is absolutely open |
| 18:46.13 | zeq | straight from git |
| 18:46.29 | freemangordon | zeq: so it is upstreamed after all? |
| 18:46.47 | zeq | long after 2.6.28 though |
| 18:47.07 | freemangordon | aah, yes, noe I remember, it was 2.6.30 or something |
| 18:47.13 | freemangordon | now even |
| 18:48.11 | Estel_ | ...which is another argument confirming it's importance (inclusion in upstream) |
| 18:48.36 | freemangordon | Estel_: I don;t think anyone argues whether it is important or not ;) |
| 18:48.40 | 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? |
| 18:49.02 | zeq | yes, or whatever virtual dep we choose |
| 18:49.20 | 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. |
| 18:49.23 | Estel_ | most of the times |
| 18:49.35 | zeq | calling it pselect is probably misleading since it provides 3 syscalls - somthing for later |
| 18:50.12 | merlin1991 | well as far as I see glibc depends only on pselect, the kernel ofc can provide a feature for each syscall |
| 18:50.21 | 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? :) |
| 18:50.54 | freemangordon | Estel_: it is discussion if how to be done AIUI |
| 18:51.04 | freemangordon | *if and how |
| 18:51.24 | zeq | One issue is risk of somebody upgrading userspace without kernel |
| 18:51.48 | freemangordon | zeq: would you elaborate? |
| 18:51.52 | zeq | or without flashing kernel |
| 18:52.15 | freemangordon | zeq: no way if it comes as part of CSSU |
| 18:52.16 | zeq | booting on stock kernel with new glibc would have *really* broken pselect()! |
| 18:52.28 | zeq | true, as long as people use HAM |
| 18:52.33 | zeq | :) |
| 18:52.33 | merlin1991 | well the only way this can happen is with uboot / multiboot |
| 18:52.36 | Estel_ | or FAM with brain |
| 18:52.41 | Estel_ | but it was always thing about CSSU |
| 18:52.46 | merlin1991 | zeq even with fam / apt-get the dependency should be resolved |
| 18:52.48 | Estel_ | i.e. "use ham" rule |
| 18:52.58 | merlin1991 | the only thing we can't do is have the provides on the bootimg |
| 18:53.09 | zeq | I'm just playing devils advocate :) |
| 18:53.11 | freemangordon | :nod: |
| 18:53.36 | Estel_ | merlin1991, could you elaborate? I use multiboot kernel-power, which provides thumb-errata-workarounds, and it's "provides" satisfied cssu-thumb fork |
| 18:53.48 | Estel_ | i.e. I don't have kernel-power-flasher installed at all |
| 18:53.56 | Estel_ | what's the deal about "Provides" in bootimg? |
| 18:54.02 | merlin1991 | Estel_: the problem is that ham fam and apt-get decide multiboot img is enough EVEN if you're not using multiboot |
| 18:54.09 | Pali | we can create (static linked) program which will be called in /sbin/preinit to show dangerous message |
| 18:54.28 | merlin1991 | so you end up with a binary for the right kernel on your fs, but still the wrong kernel flashed as regular user |
| 18:54.29 | Estel_ | merlin1991, understood, but deleting "provides" won't break compatibility for people like me? |
| 18:54.36 | freemangordon | Pali: if we put a kernel in cssu, it MUST be called just that, "kernel" |
| 18:54.57 | merlin1991 | Estel_: *people like you* will have to go deeper to run this |
| 18:55.06 | freemangordon | merlin1991: I don;t think a regular user can downgrade the kernel |
| 18:55.06 | Pali | so it will not be kernel-cssu but kernel package? |
| 18:55.08 | Estel_ | merlin1991, i.e. in my case, what should "Provide" kernel-feature-errata-workaround", if not bootimg? |
| 18:55.28 | freemangordon | Pali: I am starting to think that way will be best |
| 18:55.29 | merlin1991 | an extra package that is empty that you install via dpkg because you know what you do |
| 18:55.34 | Pali | we must remove all Provides from bootimg packages |
| 18:55.36 | 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 |
| 18:56.08 | Estel_ | merlin1991, as long as such extra empty package will be available from repositories, i'm ok with it |
| 18:56.26 | Estel_ | (not that I can't install it manually, but why create PITA for multiboot/u-boot users :) ) |
| 18:56.29 | merlin1991 | Estel_: again it can't be in the repositories becaus then apt/fam/ham will again pick it up |
| 18:56.34 | Pali | with uboot I have one problem: if I have uboot installed and want to update kernel-flasher it will remove uboot from nand |
| 18:56.53 | 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 |
| 18:57.08 | freemangordon | Estel_: no, because apt is FUBAR |
| 18:57.11 | 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) |
| 18:57.38 | freemangordon | Pali: but then you risk to boot u-boot default image without modules |
| 18:57.43 | 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 |
| 18:58.09 | 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 |
| 18:58.22 | Pali | freemangordon, if you have uboot you have also bootimg packages |
| 18:58.28 | Estel_ | merlin1991, could You elaborate hyphotetical situation, when someone could be affected? |
| 18:58.31 | Estel_ | you know, real life one? |
| 18:58.35 | Pali | and is better to not overwrite uboot |
| 18:58.36 | merlin1991 | quite easy |
| 18:58.41 | Estel_ | not theoretical as in theoretical 3rd party module incompatible? |
| 18:58.48 | merlin1991 | we create the fancy kernel + glibc in stable |
| 18:58.53 | Estel_ | nods |
| 18:59.20 | 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 |
| 18:59.30 | freemangordon | :nod: |
| 18:59.37 | Estel_ | ok, but why assuming someone have bootimg without multiboot/u-boot? |
| 18:59.41 | Estel_ | any other use for bootimg? |
| 18:59.45 | merlin1991 | nope |
| 18:59.49 | merlin1991 | but that's what you get |
| 18:59.50 | freemangordon | Estel_: HAM pulls it |
| 18:59.54 | merlin1991 | 10 times out of 10 |
| 18:59.59 | Estel_ | I see. |
| 19:00.12 | freemangordon | and that is what happened in early cssu-thumb days |
| 19:00.19 | freemangordon | yoiu may want to check the thread |
| 19:00.32 | Estel_ | ok, so why it doesn't happen now, when someone installs cssu-thumb? |
| 19:00.41 | Estel_ | kernel-cssu is pulled, not kernel-power-bootimg |
| 19:00.43 | merlin1991 | I think atm cssu-thumb depends on the flasher |
| 19:00.49 | Estel_ | no, it doesn't |
| 19:00.50 | freemangordon | because you have a hard dependency to flasher |
| 19:00.53 | Pali | because cssu-thumb depends on -flasher package |
| 19:00.54 | Estel_ | I have cssu-thumb and no flasher |
| 19:00.57 | Estel_ | wut? |
| 19:01.00 | freemangordon | and provides: is remnoved from bootimage |
| 19:01.13 | freemangordon | you have KP 51 flasher |
| 19:01.21 | Estel_ | i have bootimage, latest, that still provides, and i don't have flasher. Used fapman |
| 19:01.25 | Estel_ | ok |
| 19:01.27 | Estel_ | understood |
| 19:01.37 | Estel_ | I know how it happened, and agree to Your rational;e |
| 19:01.39 | freemangordon | Estel_: does not matter what you have, I think me and merlin1991make it clear |
| 19:01.46 | Pali | kp51 bootimg still provides thumb |
| 19:01.49 | freemangordon | *made |
| 19:02.01 | Estel_ | freemangordon, see ^^ :) |
| 19:02.07 | Estel_ | but anyway, I understand rationale |
| 19:02.14 | Estel_ | not convenient, but understood why needed. |
| 19:02.17 | freemangordon | Pali: I know, that is why I followed your advise |
| 19:02.37 | freemangordon | (cssu-flasher || power-flasher) :P |
| 19:02.44 | Estel_ | last question - so can't next cssu that will contain community kernel have hard dependency to flasher, too? |
| 19:02.47 | freemangordon | s/||/|/ |
| 19:02.49 | Pali | yes, I will remove all provides from -bootimg package, but first maemo.org must working... |
| 19:03.47 | 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 |
| 19:03.52 | freemangordon | Estel_: no, as we'll not be able to flash KP, without removing -mp |
| 19:04.06 | Estel_ | freemangordon, good point. Everything understood now. |
| 19:04.20 | freemangordon | so, back to topick |
| 19:04.21 | Pali | Estel_, If you want that package I can create it and send you by email... |
| 19:04.31 | Estel_ | Pali, I'm not thinking about myself only |
| 19:04.37 | Estel_ | I think about multiboot users as whole |
| 19:04.47 | Estel_ | would be nice to provide them package as downloadable link, at least |
| 19:05.10 | Pali | multiboot does not have problem with -flasher packages |
| 19:05.15 | 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 |
| 19:05.21 | freemangordon | Estel_: lets get back to kernel/glibc,ok? |
| 19:05.21 | Pali | multiboot flashing kernel when n900 starting |
| 19:05.43 | Estel_ | freemangordon, sure, but I think we're talking about practical outcome too, yep? |
| 19:05.48 | zeq | anybody else have objections, comments questions? |
| 19:06.20 | Estel_ | Pali, sure, but we need to have something that provides, for example, kernel-feature-thumb-errata, to satisfy dependencies. |
| 19:06.50 | freemangordon | Estel_: and that is the flasher, no matter what is currently flashed on NAND |
| 19:06.52 | Pali | Estel_, provides are still in -flasher package |
| 19:07.04 | 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? |
| 19:07.12 | Estel_ | freemangordon, understood |
| 19:07.15 | Pali | and you can install both bootimg and flasher without problem |
| 19:07.20 | Estel_ | I though empty package, as mentioned by merlin1991 is mandatory |
| 19:07.27 | Estel_ | ok, ok ,everything clear now |
| 19:07.31 | Estel_ | so it's not PITA after all |
| 19:07.43 | freemangordon | Estel_: we'll find a way to do it, breath |
| 19:08.10 | 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 |
| 19:08.37 | freemangordon | merlin1991: now the hard part. I assume you want omap1 with just a minimum pathces, right? |
| 19:08.49 | freemangordon | *patches |
| 19:08.58 | merlin1991 | yes |
| 19:09.12 | merlin1991 | for -stable at least |
| 19:09.39 | zeq | merlin1991: so just the syscalls patch? |
| 19:09.50 | merlin1991 | basically yes |
| 19:09.54 | freemangordon | merlin1991: hmm, am I missing something? not 1 but 2 kernels? |
| 19:10.09 | freemangordon | zeq: merlin1991 has a point here |
| 19:10.20 | merlin1991 | unless we find some other really important patch for the stock kernel |
| 19:10.28 | zeq | other than thumb :P |
| 19:10.31 | freemangordon | merlin1991: we already have a CVE |
| 19:10.33 | Estel_ | also called thumb :) BTw, why upgraded toolchain is a no-go? |
| 19:10.49 | freemangordon | Estel_: please, hold on for a while |
| 19:11.02 | Estel_ | no problem |
| 19:11.30 | freemangordon | merlin1991: there is a CVE to be fixed in omap1, and we have a bug report for it |
| 19:11.39 | merlin1991 | that one would be valid |
| 19:11.56 | freemangordon | yeah, we have it in the tasklist :P |
| 19:12.05 | freemangordon | lemme find it |
| 19:12.46 | freemangordon | https://bugs.maemo.org/12558 |
| 19:12.47 | povbot | Bug 12558: kernel/bluetooth: CVE-2010-1084: potential bad memory access with sysfs files |
| 19:14.12 | 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? |
| 19:15.20 | 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 |
| 19:15.27 | merlin1991 | s/going/going over/ |
| 19:16.09 | freemangordon | hmm, KP has about 20-30 .patch files, I don;t think it is so hard to check them. Pali, agree? |
| 19:16.45 | 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. |
| 19:17.04 | Pali | 85 patches are in kernel-power |
| 19:17.10 | freemangordon | wow |
| 19:17.18 | Estel_ | most of them upstream fixes/backports ;) |
| 19:17.54 | Pali | s/85/85-9/ |
| 19:18.31 | freemangordon | well, some of them like compcache are easy to be decided. And well quite lot are upstream backports |
| 19:19.06 | merlin1991 | well we have the option to go over all the patches aswell but I probably wont have the time for that till |
| 19:19.15 | merlin1991 | +september |
| 19:19.31 | freemangordon | merlin1991: the reason KP exists is that omap1 is not enough |
| 19:20.03 | jonwil | can't stay much longer, too tired. Plus, nothing interesting is being discussed :P |
| 19:20.05 | freemangordon | if we decide to not use KP, most of the CSSU users (testing) will just flash KP right after CSSU update |
| 19:20.06 | merlin1991 | lemme rephrase that, kp exists because omap1 is not enough for everyone |
| 19:20.13 | Estel_ | merlin1991, do you have lack of trust in Pali or freemangordon, that You need to go through every patch yourself? |
| 19:20.32 | freemangordon | Estel_: not all of the patches are made by me and Pali |
| 19:20.37 | Estel_ | merlin1991, let me rephrase it - kp exist, because omap1 is not enough for 99,99% of users |
| 19:21.02 | freemangordon | Pali: what do you think? |
| 19:21.05 | Estel_ | freemangordon, yes, but they're reviewed by kp maintainers (who are also part of cSSU team) and constantly tested by dozens of users |
| 19:21.42 | Estel_ | and by dozens I mean at least same ammount that test CSSU, if not more |
| 19:21.45 | freemangordon | Estel_: it has nothing to do with the trust |
| 19:22.01 | Pali | I do not know what should go to -stable... I'm not user of cssu-stable and I will still use kernel-power... |
| 19:22.05 | Estel_ | freemangordon, you missed my point. I mean that merlin1991 doesn't need to be sole person going through patches |
| 19:22.13 | merlin1991 | Estel_: I have no trust issues, I run KP myself on a few devices |
| 19:22.17 | Estel_ | I think that you or Pali or other knowledgeable cssu team people casn help him |
| 19:22.27 | Estel_ | no, no, you got me wrong |
| 19:22.29 | Estel_ | see ^^ |
| 19:22.44 | merlin1991 | well I don't mean go through them from a technical perspective |
| 19:22.45 | Estel_ | it's overkill to have 1 person going through ~90 patches |
| 19:23.05 | Estel_ | sure, but Your concern was a time required - I think teams are to make that easier :) |
| 19:23.15 | freemangordon | merlin1991: see? which kernel you will use on your "production" device? |
| 19:23.33 | freemangordon | (assuming you still use n900 as everyday device) |
| 19:24.11 | merlin1991 | my production device is a n9 |
| 19:24.16 | 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? |
| 19:24.25 | merlin1991 | jonwil: I fear not |
| 19:25.46 | freemangordon | merlin1991: well, go back to the days n900 was your everyday device and answer the question, please. |
| 19:25.46 | zeq | so is anything decided? |
| 19:25.52 | Pali | I'm going away for 10-20 minutes |
| 19:25.58 | merlin1991 | back then it was stock kernel on my main device |
| 19:26.05 | merlin1991 | and kp on my backup because I wanted iptables |
| 19:26.40 | 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-* |
| 19:26.56 | merlin1991 | everyone else can stay where they are + have stuff fixed that needs to be fixed |
| 19:27.15 | merlin1991 | ofc assuming that fsckd autobuilder stops to act up |
| 19:27.36 | freemangordon | merlin1991: people who don't know all the KP goodness will not even care which exactly kernel they have flashed |
| 19:27.52 | freemangordon | it is for those who know and care |
| 19:28.34 | merlin1991 | well from kp days I remember issues with rebotos when usb was connected and other fun |
| 19:28.51 | freemangordon | well, those days are gone, for good |
| 19:29.01 | merlin1991 | if everything in kp works as on stock then I'm happy to pull it into cssu |
| 19:29.09 | merlin1991 | Doc is going to kill me right now xD |
| 19:29.13 | Estel_ | :) |
| 19:29.20 | zeq | lol |
| 19:29.28 | 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 |
| 19:29.35 | Estel_ | I think You will have sound sleep nevertheless. BTw, freemangordon fixed the very issue You mentioned (reboot on usb cable) |
| 19:30.04 | merlin1991 | but I would still review the patches and maybe strip stuff that is on the "experimental" side |
| 19:30.14 | Estel_ | sounds ok. |
| 19:30.21 | zeq | jonwil: this is taking a while... I guess we're not going to get onto those subjects specifically |
| 19:30.23 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 19:30.25 | freemangordon | jonwil: well, it seems if that discussion happen it won;t be anytime soon, maybe it is better to have some rest. Sorry :( |
| 19:30.32 | Estel_ | this way cssu suers will benefit from upstream patches and fixes, and everyone wanting even more will be able to install kernel-power |
| 19:30.48 | Estel_ | merlin1991, agree? |
| 19:30.53 | merlin1991 | yes |
| 19:30.54 | Estel_ | s/suers/users |
| 19:31.05 | freemangordon | merlin1991: the idea is: KP used as lab, the stuff that is stable goes to CSSU |
| 19:31.24 | jonwil | hmmm, will stay a little bit, looks like discussion of KP/KCSSU is almost over |
| 19:31.31 | merlin1991 | freemangordon: yep |
| 19:31.37 | Estel_ | so, can we mark this as "agreed", kernel-power stripped of experimental stuff goes as community kernel |
| 19:31.45 | Estel_ | my thumbs are waiting nervously :) |
| 19:31.50 | Estel_ | for next points |
| 19:32.27 | 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. |
| 19:32.47 | freemangordon | merlin1991: agree? ^^^ |
| 19:33.10 | merlin1991 | yes |
| 19:33.29 | freemangordon | ok, we have a deal :). |
| 19:33.32 | freemangordon | anyone? |
| 19:33.39 | Estel_ | *fanfares* |
| 19:33.41 | zeq | I'm happy :) |
| 19:34.13 | Estel_ | it's a small step for kernel-power, but big step for cssu... or something like that |
| 19:34.17 | Estel_ | ;) |
| 19:34.19 | freemangordon | ok, I think Pali will be happy too, will ask him when he is back |
| 19:34.31 | jonwil | ok, next point? :P |
| 19:34.36 | merlin1991 | so basically point 1 and 3 are done then |
| 19:34.45 | merlin1991 | which leads us to point 2 |
| 19:34.53 | freemangordon | zeq: are they? |
| 19:35.01 | zeq | yup |
| 19:35.03 | freemangordon | ok |
| 19:35.05 | freemangordon | merlin1991: yes |
| 19:35.22 | freemangordon | lemme see |
| 19:35.42 | freemangordon | ok, we have a descent gcc 4.7.2 for SB |
| 19:36.08 | freemangordon | the only thing that needs to be changed on the device is libgcc1 and libstdc++ |
| 19:36.23 | Estel_ | which proved to produce results making Maemo *much* snappier for real use, by 100% of people, many of them placebo-prone |
| 19:36.43 | freemangordon | which are almost 100% ABI compatible with those coming with 4.2.1 |
| 19:36.59 | zeq | freemangordon: should be 100%..? |
| 19:37.08 | merlin1991 | freemangordon: what are the advantages besides being able to compile the thumb stuff (and possibly better optimization)? |
| 19:37.27 | freemangordon | we can compile lots more upstream stuff |
| 19:37.27 | zeq | merlin1991: *much* better optimization :P |
| 19:37.32 | zeq | that too |
| 19:37.39 | zeq | better standards compliance |
| 19:37.51 | merlin1991 | any regressions? |
| 19:38.23 | zeq | merlin1991: there are a couple of known bugs, and I've failed to build a fully working glibc-2.5 with it |
| 19:38.35 | freemangordon | there is an ABI break between 4.3 and 4.4. That can be workarounded very easily |
| 19:39.08 | freemangordon | merlin1991: having in mind stuff in -thumb repo, I would say there are no regressions |
| 19:39.10 | zeq | on there other hand the bugs get fixed, and I'm keeping up to date with Linaro releases |
| 19:39.26 | merlin1991 | if we want to use this upgraded toolchain it has to be able to compile everything we currently have in cssu |
| 19:39.33 | freemangordon | it is |
| 19:39.41 | freemangordon | the first was Qt |
| 19:39.57 | freemangordon | next come gtk, xserver, etc |
| 19:40.17 | freemangordon | aah, not to forget microb-engine |
| 19:40.32 | zeq | There are a number of things that try to use gnu89 inlines with new toolchian, but fail due to glibc |
| 19:40.47 | freemangordon | zeq: example? |
| 19:40.49 | zeq | s/toolchian/toolchain/ |
| 19:41.12 | merlin1991 | freemangordon: did you try if this enables us to use -O3 on qt again? |
| 19:41.13 | zeq | I hit it building a new cpio, but there are more reports on tmo |
| 19:41.46 | freemangordon | merlin1991: yes, it works ok, but because the binary was way bigger then with -O2, I kept it that way |
| 19:42.09 | zeq | this thread: http://talk.maemo.org/showthread.php?p=1164057 |
| 19:42.24 | zeq | I have patched glibc to support it though |
| 19:42.34 | zeq | backported from glibc-2.6 |
| 19:42.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 |
| 19:43.23 | Estel_ | so why You've said earlier, that better toolchain is a no-go? merlin1991? |
| 19:43.28 | freemangordon | and AFAIK loop enrolling is inefficient on ARM anyway |
| 19:43.50 | zeq | graphites -floop-strip-mine is potentially interesting though |
| 19:43.51 | merlin1991 | Estel_: because of all the stuff like sudden use of inlines which are not in our core c lib ... |
| 19:44.06 | merlin1991 | usually you do a toolchain upgrade when you swap everything to newer stuff |
| 19:44.18 | merlin1991 | ie a new debian release |
| 19:44.33 | freemangordon | well, we cannot do that, but on the other hand 4.2.1 is ancient |
| 19:44.44 | zeq | the glibc backport doesn't affect ABI |
| 19:44.46 | freemangordon | aah, LTO too |
| 19:45.14 | zeq | merlin1991: the only ABI requirements are libgcc1 and libstdc++ |
| 19:45.21 | freemangordon | well, lets not try to decide anything now, ok? |
| 19:45.55 | 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? |
| 19:46.11 | Pali | I'm here, kernel with non experimental kernel-power patches is ok |
| 19:46.15 | zeq | ideally I would like to have the inline support along with pselect() |
| 19:46.31 | freemangordon | well, thumb was/as a good proof there is no break |
| 19:46.59 | zeq | glibc ABI is always backward compatible, all new symbols are versioned |
| 19:47.10 | freemangordon | :nod: |
| 19:47.44 | zeq | the inline changes mostly relates to headers |
| 19:47.45 | merlin1991 | zeq: what happens if you add the inline support to glibc but stay with the old compiler? |
| 19:47.55 | zeq | that works too |
| 19:48.03 | merlin1991 | then I'd prefer that for now |
| 19:48.34 | zeq | there is no benefit from using the old compiler *except* not upgrading libgcc1 and libstdc++ |
| 19:49.12 | merlin1991 | there's the benefit of sleeping well based on the it worked untill now facts ;) |
| 19:49.55 | merlin1991 | and also the benefit of using the normal scratchbox installer and wiki to get everything in place to start working |
| 19:50.11 | merlin1991 | not to mention already configured scratchboxes |
| 19:50.14 | *** join/#maemo-ssu javispedro (~javier@Maemo/community/contributor/javispedro) |
| 19:50.15 | zeq | merlin1991: it's not hard to install the new toolchain |
| 19:50.20 | Estel_ | ^+1 |
| 19:50.28 | freemangordon | merlin1991: you can check my latest commits in modest. |
| 19:50.34 | freemangordon | re good compiler |
| 19:50.35 | Estel_ | also, wiki will be nuked soon, anyway, and rebuild in hildon foundation |
| 19:50.47 | merlin1991 | do we have a scratchbox-* package for the host system by now? |
| 19:50.58 | Estel_ | also, there is 0 reports of things from extras (any flavour) broken, by dozens of cssu-thumb users |
| 19:51.04 | Estel_ | despite new compiler |
| 19:51.07 | freemangordon | no, but that could be done easily |
| 19:51.16 | freemangordon | merlin1991: ^^^ |
| 19:51.40 | zeq | Actually, I do have a i486 cross |
| 19:51.48 | freemangordon | .deb? |
| 19:51.51 | zeq | I may not have released it.. ;) |
| 19:52.14 | zeq | no, but I think I can say make deb or something |
| 19:52.38 | 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 |
| 19:52.53 | freemangordon | zeq: well, even that is not needed, once we have tar.gz |
| 19:53.13 | freemangordon | merlin1991: :nod: |
| 19:53.16 | zeq | except for ease of management on dpkg based systems |
| 19:53.24 | zeq | (host system I mean) |
| 19:53.38 | freemangordon | yeah |
| 19:53.57 | zeq | not that tar xf is that tricky :) |
| 19:54.25 | freemangordon | well, lets leave that one to rest in our heads for a while |
| 19:54.33 | merlin1991 | but it breaks the flow when install 90% of a scratchbox via apt and the tar some stuff |
| 19:54.46 | merlin1991 | god typos ftw |
| 19:54.48 | zeq | it's not a problem to package it |
| 19:55.00 | merlin1991 | then do it :D |
| 19:55.08 | zeq | okay will do |
| 19:55.31 | freemangordon | :D |
| 19:55.34 | zeq | mostly I haven't because I don't have a dpkg host system :P |
| 19:55.49 | zeq | laziness |
| 19:55.51 | freemangordon | zeq: get vmware image from nokia |
| 19:56.13 | zeq | My SB is working ok :) |
| 19:56.15 | 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? |
| 19:56.20 | freemangordon | it already has SB installed, not sure which debian it is |
| 19:56.21 | Estel_ | like things for toolchain |
| 19:56.39 | Estel_ | I agree with merlin1991, that no much reasons to *not* do it |
| 19:56.40 | Estel_ | then |
| 19:56.43 | zeq | what other requirements are there? |
| 19:56.46 | Estel_ | release early, release often ;) |
| 19:56.52 | freemangordon | Estel_: because it won't happen aver the night anyway |
| 19:56.59 | freemangordon | *over |
| 19:57.04 | merlin1991 | zeq: the requirements are works and is feature complete |
| 19:57.14 | Estel_ | but deciding that we want to do it, will boost creating things like easy-=to-install toolchain |
| 19:57.15 | Estel_ | and so goes on |
| 19:57.22 | zeq | we've already made sure the generated target .debs are conforming with the maemo versioning |
| 19:57.43 | freemangordon | and if merlin1991 has some concerns, I would prefer tho clean them up before continuing |
| 19:57.48 | zeq | merlin1991: just wanted to know what feature complete is |
| 19:57.59 | zeq | right now it has many more features |
| 19:58.20 | zeq | not aware of anything missing |
| 19:58.29 | merlin1991 | host debs are the only things missing afaik |
| 19:58.48 | merlin1991 | and ofc i386 |
| 19:58.49 | freemangordon | zeq: maybe you'll need to rebuild it, and make some warnings/errors disabled by default |
| 19:59.02 | zeq | target native compiler is something I haven't done |
| 19:59.02 | freemangordon | merlin1991: 486 ;) |
| 19:59.28 | merlin1991 | ah yeah true, 486 |
| 19:59.29 | zeq | freemangordon: The warning/errors are an upstream policy |
| 19:59.43 | freemangordon | zeq: there should be no need, I don;t think you can install 4.2.1 on n900 anyway |
| 19:59.55 | zeq | determined by conforming more closely to standards |
| 20:00.14 | freemangordon | zeq: yes, but we can disable some of them in our build. I guess. |
| 20:00.28 | freemangordon | on the other hand, it is better to have them |
| 20:00.44 | merlin1991 | anyhting else you guys need me for? Family dinner is happening since an hour already :D |
| 20:00.50 | zeq | you can always use -Wno-error=bla-bla |
| 20:00.53 | freemangordon | one can alwasy pass -Wno-shit |
| 20:01.01 | zeq | :) |
| 20:01.15 | freemangordon | merlin1991: well, I think no |
| 20:01.23 | zeq | was there anything else on the list |
| 20:01.26 | zeq | ? |
| 20:01.27 | merlin1991 | nope |
| 20:01.38 | freemangordon | no, and jonwil is sleeping |
| 20:01.50 | jonwil | no I am not :P |
| 20:01.51 | zeq | upgrading glibc going forwards... |
| 20:02.08 | freemangordon | merlin1991: could you discuss that with MohammadAG and chem|st? |
| 20:02.20 | zeq | jonwil's binary blob replacement strategy |
| 20:02.26 | merlin1991 | freemangordon, Pali can you guys write me a list on what you've worked on / pushed to gitorious since the last -testing release? |
| 20:02.35 | freemangordon | And come with some more "official" statement? |
| 20:02.44 | merlin1991 | freemangordon: I will |
| 20:02.53 | freemangordon | merlin1991: unfortunately I won't be able to do that till Sunday |
| 20:03.00 | merlin1991 | no rush |
| 20:03.06 | freemangordon | yeah, I know :) |
| 20:03.26 | merlin1991 | it's just that I kinda lost track on what's happening on gitorious, now that we have that many packages :D |
| 20:03.41 | zeq | I think we're going to need another meeting :D |
| 20:03.44 | merlin1991 | and I think it's about time we do a new release to include ie lufs changes to obexd |
| 20:03.45 | freemangordon | but basically I have touched tinymail only, most of my commits are related to thumb stuff |
| 20:04.09 | freemangordon | merlin1991: deffinitely. and libcurl3 too |
| 20:04.49 | freemangordon | merlin1991: tuesday? |
| 20:04.52 | Estel_ | Pali, abusing fact that You're her,e could You check my psots @ kp51r1 thread? |
| 20:05.01 | freemangordon | WOW |
| 20:05.05 | Estel_ | I've included irc logs from talking with DocScrutinizer about bugs in bq2415x_charger |
| 20:05.05 | merlin1991 | send it per email when you have it ready |
| 20:05.15 | Estel_ | and it seems that there are bugs, definitelly |
| 20:05.32 | Estel_ | I need to be off, now :) |
| 20:05.36 | Estel_ | See ya, guys |
| 20:05.38 | freemangordon | bb |
| 20:06.05 | zeq | bb Estel_ |
| 20:07.06 | jonwil | anything else on the agenda? |
| 20:07.16 | freemangordon | jonwil: your turn :) |
| 20:07.20 | jonwil | ok |
| 20:07.50 | jonwil | ok, so my work to replace the bluetooth and WiFi cal stuff... |
| 20:07.59 | jonwil | Is that something people actually care about? |
| 20:08.29 | merlin1991 | jonwil: in general everyone in here is happy about each and every closed bit that gets a replacement |
| 20:08.38 | freemangordon | jonwil: I see it like Pali's work re bq |
| 20:08.40 | zeq | absolutely |
| 20:09.00 | freemangordon | and mine on hald-addon-bme and libbmeipc |
| 20:09.10 | zeq | do we intend to keep functionality as-is? |
| 20:09.40 | 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 |
| 20:10.24 | zeq | what does the Nemo kernel use for kernel<->userspace re. wifi and bluetooth? |
| 20:10.51 | jonwil | well MeeGo/Mer/Nemo still has the same binary bits for N900 WiFi and Bluetooth |
| 20:10.57 | jonwil | so it must have the same kernel interfaces |
| 20:11.21 | freemangordon | and what evel it does (besides being closed source)? |
| 20:11.26 | freemangordon | *evil |
| 20:11.49 | zeq | but according to earlier discussion there are open drivers for most devices |
| 20:11.59 | Pali | going offline, bye |
| 20:12.05 | zeq | see ya Pali |
| 20:12.08 | freemangordon | bye Pali |
| 20:12.25 | jonwil | the question is not what it does, the question is, is removing the crappy non-standard interfaces from the kernel worthwhile or not |
| 20:12.26 | freemangordon | zeq: but userspace is not |
| 20:12.39 | jonwil | and if its worthwhile, is there someone with the skills to actually do the work? |
| 20:12.50 | freemangordon | merlin1991: ^^^ ? |
| 20:13.33 | freemangordon | jonwil: we'll find the skills, I think the resource situation is way better now that it was an year ago |
| 20:14.27 | 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 |
| 20:14.41 | jonwil | then someone else can take that code and make it work with something standard |
| 20:14.50 | jonwil | whatever the appropriate interfaces are |
| 20:15.33 | freemangordon | jonwil: whatever netlink-send-to-kernel is :D |
| 20:16.20 | *** join/#maemo-ssu toxaris (~toxaris@90-230-114-186-no34.tbcn.telia.com) |
| 20:16.24 | freemangordon | jonwil: wl1251-cal is .so? |
| 20:16.58 | jonwil | no its binary |
| 20:17.08 | freemangordon | executable? aah, ok |
| 20:17.20 | jonwil | it runs at startup and sends stuff (including MAC address) to kernel |
| 20:17.22 | jonwil | over netlink |
| 20:17.32 | jonwil | point is, netlink is non-standard (or so I have been told) |
| 20:17.45 | freemangordon | and gets it from CAL. ok, got it. |
| 20:17.48 | jonwil | and we should be doing things in way that follows proper standards |
| 20:17.55 | freemangordon | yep |
| 20:18.09 | jonwil | ok, so yeah I will produce wl1251-cal clone then |
| 20:18.21 | zeq | netlink is a standard interface |
| 20:18.29 | freemangordon | but, wl1251 kernel driver is upstreamed, ain't? |
| 20:18.36 | zeq | whether it's the usual or best one for that purpose...? |
| 20:19.09 | freemangordon | how it comes it does not use a standard iface? |
| 20:19.20 | jonwil | I dont know, ask Nokia |
| 20:19.22 | jonwil | :P |
| 20:19.42 | zeq | I suspect it is a standard interface, just the specifics are poorly (or un-)documented |
| 20:20.03 | 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 |
| 20:20.09 | jonwil | as those are too hard for me |
| 20:20.26 | freemangordon | http://en.wikipedia.org/wiki/Netlink |
| 20:20.57 | freemangordon | jonwil: you mean RE? |
| 20:21.03 | jonwil | yes |
| 20:21.16 | zeq | freemangordon: as I said it is standard |
| 20:21.39 | freemangordon | the only thing I can think of right now if him |
| 20:21.50 | freemangordon | s/if/is/ |
| 20:22.11 | freemangordon | I am already on vkbrenderer |
| 20:22.25 | freemangordon | but there is other closed stuf too |
| 20:22.27 | jonwil | yeah h-i-m closed bits are complex too |
| 20:22.40 | zeq | new open dialler would be nice |
| 20:22.51 | freemangordon | jonwil: well, 386 binaries are 20-30 k eash |
| 20:22.58 | freemangordon | each |
| 20:23.04 | freemangordon | why hard? |
| 20:23.20 | jonwil | GUI stuff is generally complex |
| 20:23.29 | jonwil | just because of how GTK is :) |
| 20:23.36 | freemangordon | and there are enough headers to grok the interfaces |
| 20:23.40 | zeq | you can code GUI in qt* |
| 20:23.43 | freemangordon | aah, yes |
| 20:23.55 | jonwil | And I already said dialer is FAR too complex to reverse engineer |
| 20:24.03 | freemangordon | zeq: well, it is not so simple to miz qt and gtk |
| 20:24.17 | freemangordon | jonwil: yes, dialer is very very complex |
| 20:24.36 | freemangordon | s/miz/mix/ |
| 20:24.52 | zeq | because of address0book etc? |
| 20:25.03 | zeq | s/address0book/address-book/ |
| 20:25.11 | jonwil | because of the mess that is telepathy for one thing |
| 20:25.12 | freemangordon | zeq: not only, it deals with mode, battery, sim, etc |
| 20:25.27 | freemangordon | s/mode/modem/ |
| 20:26.13 | freemangordon | if we have foss dialer one day, it should be complete rewrite or backport from somewhere |
| 20:26.13 | zeq | are those not provided/handled by external daemons etc |
| 20:26.45 | jonwil | dialer has to talk to external things like telepathy, telepathy-ring, cellular services daemon etc |
| 20:26.45 | zeq | what's the Nemo dialler like? |
| 20:26.49 | jonwil | all of which are mostly undocumented |
| 20:26.55 | jonwil | and difficult to figure out |
| 20:27.07 | freemangordon | well, I don't know that much about dialer, but ^^^ |
| 20:27.15 | jonwil | well cellular services daemon is definitely undocumented |
| 20:27.47 | freemangordon | zeq: and it does not make sense to RE it, when there is ofono |
| 20:27.48 | zeq | telepathy should be documented even if not the ring plugin |
| 20:27.58 | jonwil | yeah telepathy is documented |
| 20:28.00 | zeq | telepathy is F/OSS |
| 20:28.06 | jonwil | yeah most of it is |
| 20:28.07 | freemangordon | zeq: ever seen telepathy documentation? |
| 20:28.18 | jonwil | but not the interesting parts :) |
| 20:28.27 | jonwil | and yes telepathy documentation is a mess |
| 20:28.38 | jonwil | so yeah dialer replacement is off the table |
| 20:28.52 | freemangordon | zeq: I've tried to read it once, got a headache after a while |
| 20:29.14 | zeq | ~ofono |
| 20:29.16 | zeq | no infobot? |
| 20:29.16 | zeq | what's ofono? |
| 20:29.31 | jonwil | ofono is NOT something we can use in Fremantle |
| 20:29.39 | freemangordon | http://en.wikipedia.org/wiki/OFono |
| 20:29.40 | jonwil | That I can say for sture |
| 20:29.44 | freemangordon | jonwil: why? |
| 20:30.07 | 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 |
| 20:30.07 | freemangordon | afaik it works in ubuntu |
| 20:30.30 | freemangordon | hmm, couldn;t we RE that? |
| 20:30.33 | jonwil | everything from bluetooth to GPRS |
| 20:31.07 | jonwil | I have been trying to figure out the CSD dbus interfaces for ages now without much luck (com.nokia.phone.sim specifically) |
| 20:31.25 | freemangordon | after all dbus should be pretty much easy to sniff |
| 20:31.32 | jonwil | yes its easy to sniff |
| 20:31.39 | jonwil | but figuring out what you are looking at is hard |
| 20:31.45 | jonwil | when all you see is a bunch of numbers |
| 20:31.56 | freemangordon | hehe |
| 20:32.46 | freemangordon | jonwil: BTW is it possible it is just a transparent transport to sim? |
| 20:33.06 | freemangordon | maybe I should look at it some day |
| 20:33.13 | jonwil | it doesn't appear to be that simple |
| 20:33.25 | freemangordon | and those numbers are APDUs? |
| 20:33.37 | freemangordon | possible? |
| 20:33.44 | zeq | some documentation on the wiki: http://wiki.maemo.org/Phone_control |
| 20:34.10 | jonwil | yeah a couple pieces of documentation around but not for the good bits (the bits I need) |
| 20:34.13 | Estel_ | zeq, this one is about calls as whole, notm sim related. yuep? (i'm back for a while, listening quietly) |
| 20:35.08 | 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 |
| 20:35.10 | freemangordon | jonwil: and which part is missing? |
| 20:35.21 | jonwil | most of com.nokia.phone.sim is undocumented |
| 20:35.39 | freemangordon | hmm, can't we just guess from the names? |
| 20:35.40 | zeq | phonet is in the upstream kernel |
| 20:35.51 | zeq | maybe some documentation in the kernel sources? |
| 20:35.56 | jonwil | nope, there is not |
| 20:36.04 | jonwil | phonet is just a transport method |
| 20:36.20 | jonwil | the actual packets are only dealt with by the cellular services daemon (or by ofono) |
| 20:36.35 | jonwil | and yes I checked ofono source but its not sending the packets I care about |
| 20:36.40 | jonwil | so that doesn't help for documentation |
| 20:37.13 | jonwil | we can sort of guess from the names but com.nokia.phone.sim.get_service_provider_info doesnt tell us much |
| 20:37.24 | jonwil | nor does com.nokia.phone.sim.get_sim_status tell us what the status number(s) actually mean |
| 20:38.23 | freemangordon | jonwil: we can get that from other sources, after all those should come directly from the card |
| 20:38.38 | freemangordon | I don;t think the modem translates those |
| 20:38.40 | zeq | I wonder if it would be a valid guess that nokia use the same structures as with their older devices? |
| 20:39.09 | jonwil | I did a lot of digging and I cant find anything useful |
| 20:39.17 | zeq | gnokki? |
| 20:39.18 | jonwil | including looking at SIM related specs |
| 20:40.02 | jonwil | its pretty clear though that the cellmo is definatly the one dealing with these packets |
| 20:40.09 | jonwil | and that they arent just being passed to the SIM |
| 20:40.10 | freemangordon | jonwil: ever heard about globalplatform? |
| 20:40.22 | jonwil | haven't heard of globalplatform |
| 20:40.39 | freemangordon | there is lots of stuff there for OTA update and such |
| 20:40.42 | zeq | I'd be willing to bet there is a standard hiding here |
| 20:41.20 | zeq | as in a specification for cellular communications |
| 20:41.39 | 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) |
| 20:41.46 | freemangordon | jonwil: it is the latest standard most of vendors comply with |
| 20:42.04 | jonwil | yes the modem probably complies with all sorts of SIM related standards |
| 20:42.18 | jonwil | but the interface to the main CPU is definitely 100% Nokia |
| 20:42.28 | freemangordon | hmm, bad |
| 20:42.39 | jonwil | I have some totally undocumented .h files for a couple of other parts of the cellmo (like GPS) |
| 20:42.41 | zeq | jonwil: I still think it's probably worth looking at the gnokki codebase |
| 20:43.01 | zeq | I remember they had various protocol handlers |
| 20:43.40 | freemangordon | that is used to talk through rs/usb/whatever iface with the modem? |
| 20:44.03 | freemangordon | zeq: ^^^ |
| 20:44.15 | zeq | yes, whatever bus was available on various phones |
| 20:44.16 | jonwil | I dont think gnokki talks to the cellular modem much, it probably just uses the same interfaces as the official Nokia software |
| 20:44.45 | jonwil | I doubt gnokki codebase is going to have any low-level details of Nokia modems (especially not the N900 modem) |
| 20:45.21 | jonwil | gnokki may use AT commands to talk to the phone in some cases |
| 20:45.29 | zeq | but is the interface really low-level? |
| 20:45.31 | jonwil | if the phone exposes AT commands to the outside world |
| 20:45.37 | jonwil | and yes the modem interface is quite low level |
| 20:45.46 | jonwil | Reading the ofono source has shown me that |
| 20:46.05 | zeq | doesn't it run a firmware? |
| 20:46.12 | jonwil | yes the cellular modem does run a firmware |
| 20:46.23 | jonwil | but reverse engineering that would be nigh-on impossible |
| 20:46.36 | freemangordon | but, but , why AT commands don;t work then? |
| 20:46.44 | jonwil | since there is basically zero information on that firmware or the hardware that it runs on |
| 20:47.04 | jonwil | I dont know a thing about AT commands on n900 |
| 20:47.10 | jonwil | just that the cellmo doesn't use em |
| 20:48.30 | freemangordon | http://git.savannah.gnu.org/cgit/gnokii.git/tree/include/phones/nk6510.h |
| 20:49.08 | jonwil | ok, that looks nothing like the n900 cellmo interface |
| 20:49.09 | zeq | Looks interesting :) |
| 20:49.17 | jonwil | the isi/phonet stuff |
| 20:49.24 | zeq | oh well :) |
| 20:49.32 | DocScrutinizer05 | who says I'm not here? |
| 20:49.42 | zeq | Hi DocScrutinizer |
| 20:49.50 | freemangordon | you WERE not here :P |
| 20:49.52 | freemangordon | hi |
| 20:49.58 | jonwil | ok, so any more discussion to have on the n900 cell modem or can we move on? |
| 20:50.20 | freemangordon | i guess we can |
| 20:50.46 | DocScrutinizer05 | dafaq that scollback will take hours to read |
| 20:51.04 | DocScrutinizer05 | you guys been pretty busy last 3 hours, eh? |
| 20:51.15 | freemangordon | yeah |
| 20:51.35 | 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 |
| 20:51.53 | DocScrutinizer05 | you thought "fine, DocScrutinizer isn't around, so finally we get things done without tedious discussions" |
| 20:52.06 | jonwil | although I am definatly open to suggestions that I haven't already ruled out :) |
| 20:52.49 | freemangordon | jonwil: well, I can't think of anything else now, but will keep it in my mind while using the device ;) |
| 20:52.53 | jonwil | ok |
| 20:52.54 | zeq | jonwil: I'm not sure what's left? |
| 20:53.08 | jonwil | I am not sure off the top of my head either |
| 20:53.23 | jonwil | but I guess bluetooth and wifi CAL is a good place to start |
| 20:53.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 |
| 20:54.12 | freemangordon | jonwil: but it is standard |
| 20:54.19 | jonwil | well netlink may be standard but someone (I forget who) said that its not ideal |
| 20:54.22 | zeq | jonwil: I think the netlink interface just needs documenting |
| 20:54.27 | jonwil | i.e. that there are benefits to replacing netlink |
| 20:54.42 | 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 |
| 20:54.42 | jonwil | might have been pali |
| 20:54.57 | jonwil | yeah doc, I know that :) |
| 20:55.16 | freemangordon | http://tools.ietf.org/html/rfc3549 |
| 20:55.20 | DocScrutinizer05 | and there's basically ZARRO use in REing cmt FW |
| 20:55.58 | zeq | Unless you want to be banned from telcos ;) |
| 20:56.01 | DocScrutinizer05 | since, while it's still ARM according to jacekowski, it is signed and thus not patchable |
| 20:56.22 | DocScrutinizer05 | zeq: nope, you simply CAN NOT mess with it |
| 20:56.45 | DocScrutinizer05 | cmt simply will refuse to flash any patched version |
| 20:56.53 | zeq | unless you zap it with a STM |
| 20:56.53 | Estel_ | hello rider of the Storm :) |
| 20:57.00 | freemangordon | yeah, at least until we find a way to steal Nokia's private keys ;) |
| 20:57.18 | jonwil | btw, I found this quote earlier on google |
| 20:57.18 | DocScrutinizer05 | freemangordon: exactly |
| 20:57.21 | Estel_ | freemangordon, tolda ya that hiring mercaneries to scavenge what we can now from nokia's offices is a way to go |
| 20:57.37 | jonwil | "Commit "wl1251: add wl1251 prefix to all 1251 files" accidentally added wl1251_netlink.c which contains a private netlink interface." |
| 20:57.44 | Estel_ | we can start fundrising right now |
| 20:57.44 | zeq | Estel_: shhh |
| 20:57.58 | jonwil | so that implies that even though netlink itself is standard, the specific interface to wl1251 driver is 100% Nokia |
| 20:58.23 | jonwil | and may not be the way that mainline kernel would implement interface to wl1251 chip if they were doing it |
| 20:58.45 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 20:59.01 | freemangordon | well, if it is upstreamed, it should be following some rules |
| 20:59.12 | freemangordon | and it is upstreamed afaik |
| 20:59.19 | jonwil | yes I think so |
| 21:00.05 | freemangordon | jonwil: maybe if you look what is upstream and compare it with what is in maemo will give us a clue. |
| 21:00.14 | jonwil | ok |
| 21:00.43 | freemangordon | if it is the same, then iface replacement does not make sense |
| 21:00.43 | DocScrutinizer05 | struct wl1251_magic {int magic1; int magic2; int magic3} wl1251; |
| 21:01.03 | zeq | O_o |
| 21:01.09 | DocScrutinizer05 | hehehe |
| 21:01.14 | freemangordon | DocScrutinizer05: where did you get that from? |
| 21:01.20 | DocScrutinizer05 | made it up |
| 21:01.34 | zeq | :) |
| 21:01.45 | freemangordon | aah, I was thinking that you found it in upstreamed driver :D |
| 21:01.46 | DocScrutinizer05 | but I bet that's about what you'll find in any 'FOSS' driver |
| 21:02.39 | kerio | goddammit my 0.02 were useless :( |
| 21:03.04 | freemangordon | http://www.valot.fi/kalle/tmp/wl12xx/wl12xx-2.6.28-1.patch |
| 21:03.13 | freemangordon | http://markmail.org/thread/xummknezx5r66fha |
| 21:03.24 | zeq | kerio: didn't cover as much as we hoped |
| 21:03.41 | kerio | you guys ended up compromising! |
| 21:03.48 | Estel_ | shhh |
| 21:03.52 | Estel_ | DocScrutinizer, doesn't know yet |
| 21:03.56 | freemangordon | DocScrutinizer05: does not look like that |
| 21:03.59 | Estel_ | enjoy peace before storm |
| 21:04.03 | kerio | now i'll have to flash the compromising kernel and then kernel-power again |
| 21:04.10 | zeq | looks quite well documented ^^^ |
| 21:04.42 | freemangordon | yeah, no magic so far in the patch |
| 21:05.49 | DocScrutinizer05 | meh, which storm. If you think you don't need my advice, I'll simply beat up each single one of you separately if ever there's any problem arising that I could've warned you about |
| 21:06.43 | zeq | sounds fair :) |
| 21:07.34 | DocScrutinizer05 | my spiders already collecting your N900's IMEI, ser#, MAC, ip-route etc |
| 21:07.59 | freemangordon | wl12xx_op_add_interface(struct ieee80211_hw *hw, |
| 21:07.59 | freemangordon | + struct ieee80211_if_init_conf *conf) |
| 21:08.14 | freemangordon | well, that looks pretty much coming from upper layers |
| 21:08.31 | freemangordon | not something specific to wl1251 |
| 21:09.05 | DocScrutinizer05 | and one "thumbs down" from me will probably cost CSSU 80% of users |
| 21:09.24 | DocScrutinizer05 | so you better keep me happy ;-P |
| 21:09.53 | freemangordon | sends DocScrutinizer05 a beer |
| 21:09.56 | Estel_ | You think that CSSu is used by 5 people only? |
| 21:10.03 | Estel_ | send DocScrutinizer a kiss ;) |
| 21:10.10 | DocScrutinizer05 | unless you want CSSU for your own proivate idaho, in which case you better fork anyway |
| 21:11.06 | freemangordon | anyway, I am out of cigarettes, so better have some sleep |
| 21:11.13 | Estel_ | :) |
| 21:11.36 | Estel_ | DocScrutinizer, I'm positively surprised by your sense of humour - it's due to vacations? |
| 21:11.40 | zeq | goodnight freemangordon |
| 21:11.55 | Estel_ | I hope that this remakr about thumb down and 805 of cssu users was also part of this nice humour (no irony) |
| 21:12.01 | Estel_ | night, free |
| 21:12.03 | freemangordon | night guys |
| 21:12.12 | Estel_ | s/805/80%/ |
| 21:12.19 | zeq | I'm sure there was irony :) |
| 21:12.44 | Estel_ | no, it's just "people mean well" :D |
| 21:13.13 | Estel_ | I don't suspect DocScrutinizer of being THAT kind of self-convince one. |
| 21:13.25 | Estel_ | and bashing, if problems arise, seems fair to me too |
| 21:13.33 | DocScrutinizer05 | Estel_: you already should've learnt that none of my posts consists of 0% or 100% humor |
| 21:13.36 | jonwil | ok, its definatly zzz time now |
| 21:13.41 | jonwil | Looks like we had a good meeting |
| 21:13.49 | Estel_ | DocScrutinizer, exactly my thoughts :) |
| 21:13.53 | jonwil | and I know now that wl1251-cal and bluetooth-cal stuff |
| 21:13.56 | zeq | yeah, jonwil, what time is it there?!? |
| 21:13.57 | jonwil | stuff IS worth working on |
| 21:14.03 | jonwil | its 5am :P |
| 21:14.07 | Estel_ | ouh |
| 21:14.12 | zeq | yeah, ouch |
| 21:14.22 | zeq | get some good rest |
| 21:14.24 | jonwil | good to be there for the important stuff though |
| 21:14.26 | jonwil | cya |
| 21:14.27 | Estel_ | then I understand Your repeated questions about "I'm i really needed here?" |
| 21:14.35 | zeq | night |
| 21:14.36 | Estel_ | see ya! |
| 21:14.52 | DocScrutinizer05 | and particularly my statement about a *lot* of users pinging me in PM to keep on struggling for a sane CSSU is not any joke |
| 21:14.52 | zeq | I'd better be off too.... |
| 21:15.09 | DocScrutinizer05 | just the 80% is merely made up |
| 21:15.27 | DocScrutinizer05 | maybe it's 4% or 97% |
| 21:15.52 | zeq | Good night DocScrutinizer05, Estel_ |
| 21:16.01 | Estel_ | Good night! |
| 21:16.22 | DocScrutinizer05 | cya zeq |
| 21:16.22 | Estel_ | DocScrutinizer, but they're same users using different names ;P |
| 21:16.40 | DocScrutinizer05 | Estel_: I'm not an idiot, even when you don't believe that |
| 21:17.02 | Estel_ | but, seriously this time, just read backlogs, I think you will be satisfied by outcome too :) |
| 21:17.08 | DocScrutinizer05 | and my post about spiders also wadsn't 100% joke |
| 21:17.12 | Estel_ | especially, that You were sympathetic to fixing pselect bug |
| 21:17.42 | Estel_ | No worries, my cat eats spiders. |
| 21:17.58 | DocScrutinizer05 | pselect bug is a valid reason to get CSSU kernel, IF and ONLY IF we can demonstrate the issue on stock kernel |
| 21:18.21 | Estel_ | well, d-bus seems to use pselect quite often |
| 21:18.39 | Estel_ | which arises both performance concerns, and possibility of race, which should be avoided at all cost |
| 21:18.39 | DocScrutinizer05 | I would believe that in 0.0001 second |
| 21:19.01 | DocScrutinizer05 | d-bus is so fubar ther HAS TO be some massive bug sleeping in it |
| 21:19.05 | merlin1991 | Estel_: Doc is talking about showing the bug, which basically means someone has to write a really nasty testcase that manages to show the race condition |
| 21:19.05 | Estel_ | also, upstream adopted this fix in kernel 2.6.30 for reason, too |
| 21:19.24 | DocScrutinizer05 | merlin1991: exactly |
| 21:19.33 | Estel_ | merlin1991, there was one, zeq presented it to DocScrutinizer, but DocScrutinizer wasn't satisfied by aesthetic side of this |
| 21:19.40 | merlin1991 | basically a lop of some pselect calls that make sense together with a signal sender |
| 21:19.43 | merlin1991 | and ofc madness |
| 21:19.51 | DocScrutinizer05 | almost correct, Estel_ |
| 21:19.52 | Estel_ | also, I still think that in our little world (N900) case, arguing with upstream is quite silly |
| 21:20.04 | DocScrutinizer05 | merlin1991: there's such code already |
| 21:20.30 | merlin1991 | DocScrutinizer05: what's keeping you unconvinced then? |
| 21:20.56 | merlin1991 | btw I made a really nasty mistake here |
| 21:21.01 | DocScrutinizer05 | missing post to ML, showing a scientific review and the results of this test |
| 21:21.15 | merlin1991 | flashed only rootfs when I had a quite different kernel flashed |
| 21:21.28 | kerio | merlin1991: D: |
| 21:21.36 | kerio | well |
| 21:21.39 | kerio | flash the kernel |
| 21:21.43 | Estel_ | DocScrutinizer, last time you were not satisfied by this code displaying stats, and stoppind when encounter bug - you wanted it to display info on encountering bug, instead of stoppiong doing so. IIRC |
| 21:21.47 | Estel_ | that's why I called it aesthetic |
| 21:21.54 | Estel_ | concern. May be wrong, though |
| 21:21.55 | kerio | and then install backupmenu and unpack the backup you have |
| 21:21.59 | merlin1991 | kerio: did it already, but I spend a few minutes wondering why I'm having a silly reboot loop |
| 21:22.21 | kerio | reflash *all* the things! _ò/ |
| 21:22.45 | Estel_ | well, once I recovered old backup, because I realized 5 minutes too late, that hanging on reboot was caused by typo in rcS_late |
| 21:22.45 | DocScrutinizer05 | Estel_: incorrect, I asked to point me to the quote that explains what this code is supposed to do, freemangordon(?) pointed me to comment#6 which provides exactly what I asked for |
| 21:23.06 | Estel_ | DocScrutinizer, I see. so, after all, you're satisfied with it? |
| 21:23.23 | DocScrutinizer05 | I'd be if I'd see the results posted somewhere |
| 21:23.37 | Estel_ | somewhere = mailing list? Why so? |
| 21:24.07 | merlin1991 | btw DocScrutinizer05 the possible race condition is even on wikipedia :D |
| 21:24.07 | merlin1991 | http://en.wikipedia.org/wiki/Event_loop#Handling_signals |
| 21:25.28 | DocScrutinizer05 | merlin1991: I know |
| 21:26.34 | DocScrutinizer05 | merlin1991: does that wiki also say 2.6.28-omap1 #1 PREEMPT Fri Aug 6 11:50:00 EEST 2010 armv7l unknown does NOT have any fix for it? |
| 21:27.37 | merlin1991 | DocScrutinizer05: that part is what we have zeq for ;) |
| 21:30.06 | DocScrutinizer05 | well, that's what I ask for. DEMONSTRATE we got a problem on stock kernel, so *everybody* noob can read it, and I'll support a fix. No discussion about that |
| 21:30.14 | DocScrutinizer05 | CSSU is about fixing problems |
| 21:30.42 | DocScrutinizer05 | getting a new kernel for 10% performance increase is *creating new* problems, not fixing any |
| 21:30.55 | DocScrutinizer05 | fixing pselect IF WE CAN |
| 21:31.06 | DocScrutinizer05 | DEMONSTRATE |
| 21:32.01 | DocScrutinizer05 | it bites us on stock kernel, is absolutely in line with CSSU (given the negative aspects of bug are way more severe than the negative aspects of the fix) |
| 21:32.25 | merlin1991 | DocScrutinizer05: do you have a link to the sample code? |
| 21:32.39 | DocScrutinizer05 | leem check if I still got the window open |
| 21:33.26 | DocScrutinizer05 | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 |
| 21:33.36 | DocScrutinizer05 | is the comment#6 I mentioned above |
| 21:34.20 | merlin1991 | arf it's 404 |
| 21:34.39 | merlin1991 | hm how does one use the google cache again? |
| 21:34.49 | DocScrutinizer05 | http://people.canonical.com/~scott/childspin.c is dead |
| 21:34.51 | DocScrutinizer05 | :-/ |
| 21:34.58 | kerio | is that like meatspin? |
| 21:35.25 | Estel_ | DocScrutinizer, actually, 10% performance would be worth it :) |
| 21:35.32 | Estel_ | not to mention, that it's not only about it |
| 21:35.37 | DocScrutinizer05 | no, definitely not |
| 21:35.51 | Estel_ | yes, definitelly yes, in device that have such potential, but so scarce resources. |
| 21:36.06 | DocScrutinizer05 | no normal user gives a fuck about 10% performance boost |
| 21:36.15 | kerio | the n900 has no normal users, realistically |
| 21:36.17 | Estel_ | 10% substitutes for 100 mhz oveclock, in most devices, without drawbacks. |
| 21:36.23 | DocScrutinizer05 | kerio: wrong |
| 21:36.31 | Estel_ | normal suers doesn't use cssu |
| 21:36.35 | Estel_ | users, ffs |
| 21:36.41 | Estel_ | what I have with this "sue" thing :p |
| 21:36.42 | DocScrutinizer05 | Estel_: wrong |
| 21:36.58 | Estel_ | DocScrutinizer, I buy n900 from "normal users" few times a month |
| 21:37.05 | DocScrutinizer05 | see? |
| 21:37.11 | Estel_ | they don't have rootsh, cssu, but, suprisingly, the have kernel-power |
| 21:37.11 | merlin1991 | DocScrutinizer05: found the source somewhere else https://launchpadlibrarian.net/34502840/childspin.c |
| 21:37.22 | DocScrutinizer05 | and those are only the ones that sell their device |
| 21:37.37 | Estel_ | DocScrutinizer, because majority of normal users never heard of maemo.org website? |
| 21:37.44 | Estel_ | anyone else isn't normal user anymore |
| 21:37.51 | DocScrutinizer05 | Estel_: CSSU is for normal users BY DEFINITION |
| 21:38.08 | DocScrutinizer05 | it's the founding preamble of CSSU |
| 21:38.15 | Estel_ | so missed target group, as users of custom-installable repo, TMO, and other resources like that isn't normal anymore |
| 21:38.22 | Estel_ | normal guy buy phone to make phone calls and sms'es |
| 21:38.47 | DocScrutinizer05 | your definition of 'normal' is flawed |
| 21:38.48 | Estel_ | Youcould target "normal users" if Nokia would make PR out of cssu, otherwis,e it require custom actions |
| 21:38.51 | Estel_ | to install |
| 21:39.01 | Estel_ | well, normal as in % of n900 owners? |
| 21:39.11 | Estel_ | I suspect no more than 305 of them have been to TMO, even once |
| 21:39.30 | Estel_ | 30% |
| 21:39.36 | Estel_ | s/305/30%/ |
| 21:39.36 | DocScrutinizer05 | I knew about that flawed concept when I seen you thinking that every "normal N900 user" is supposed to read tmo |
| 21:39.59 | Estel_ | TMO OR wiki |
| 21:40.10 | Estel_ | well, you need to know about things from somewhere, yep? |
| 21:40.13 | Estel_ | or mailing list |
| 21:40.16 | Estel_ | any of those |
| 21:40.20 | Estel_ | not necessary all of them |
| 21:40.43 | DocScrutinizer05 | 90% of N900 (or any other device) users won't give a fuck about wiki, fora, IRC whatever |
| 21:40.43 | Estel_ | sadly, people doing so are far from normal phone users, anyway |
| 21:40.50 | Estel_ | and they don't use cssu |
| 21:40.55 | DocScrutinizer05 | CSSU is for them, as well |
| 21:40.56 | Estel_ | cause how they can know about it, without doing so? |
| 21:41.17 | DocScrutinizer05 | that's a good questions, and a problem you should tackle |
| 21:41.24 | Estel_ | also, if they don't give a fuck, but use cssu, they don't give a fuck about kernel used, too |
| 21:41.35 | Estel_ | as long as it works |
| 21:41.42 | DocScrutinizer05 | rather than thinking of CSSU as the geeks' breeding-edge distro |
| 21:41.50 | DocScrutinizer05 | bleeding even |
| 21:41.51 | Estel_ | where we comes to situation, where you're right about beating everyone involved if serious problems arise |
| 21:41.55 | Estel_ | no no |
| 21:42.00 | Estel_ | kernel-power is for bleeding-edge |
| 21:42.15 | Estel_ | no one said kernel in cssu will contain bq2415x_charger and such things, before proven stable |
| 21:42.27 | Estel_ | after proven stable, though, no reasons why not. |
| 21:42.33 | DocScrutinizer05 | Estel_: let's say I managed a product, while you obviously didn't yet |
| 21:42.48 | Estel_ | sure. which doesn't make you better suited to discuss it :) |
| 21:42.55 | Estel_ | it's just equal |
| 21:43.03 | DocScrutinizer05 | and let's assume it's true that I get private mail asking me to not stop with what i'm doing for CSSU |
| 21:43.07 | merlin1991 | hm compiled the sample code, and it's still running |
| 21:43.27 | Estel_ | DocScrutinizer, irrelevant, You imagine how many mails and psots cssu team get about including various features? |
| 21:43.33 | Estel_ | even ones that shouldn't get into cssu? |
| 21:43.43 | Estel_ | usually 1 feature request per day ;P |
| 21:43.54 | Estel_ | negatrons are not better in any way than those people |
| 21:44.15 | Estel_ | cssu need to follow common sense and logic - it works -> it gives benefits - > it doesn't cause regression - > include |
| 21:44.30 | DocScrutinizer05 | well, the difference is, my requests are in line with CSSU foundation manifest, while yours are noobs who didn't get the idea of CSSU |
| 21:44.30 | Estel_ | of course it mean core system components, like kernel |
| 21:44.32 | Estel_ | or toolchain |
| 21:44.51 | Estel_ | DocScrutinizer, sophism and demagogic approach. "Mine are better than yours" |
| 21:45.07 | DocScrutinizer05 | if you want sometjing that CSSU definitely is NOT, you're free to fork |
| 21:45.20 | Estel_ | it's jsut about interpretation of CSSU manifest, and merlin1991 seems to share "common sense" way of looking at it. Last time I checked, he and MohammadAG were maintainers |
| 21:45.35 | merlin1991 | srly Estel_ relax |
| 21:45.35 | Estel_ | same apply in reverse - if You want cssu-lite to contain less, You're free to fork |
| 21:45.42 | Estel_ | merlin1991, why so? i'm relaxed |
| 21:45.42 | DocScrutinizer05 | it's however bad habit to try and redefine a project on the fly, just because you're too lazy to fork |
| 21:45.56 | Estel_ | we're discussing, in civil way, i suppose, no anger here from any party (I hope) for sure not from my side |
| 21:46.06 | DocScrutinizer05 | or have even worse reasons to try and change CSSU to something differnet |
| 21:46.26 | merlin1991 | hm this testhtingy is still running |
| 21:46.40 | Estel_ | DocScrutinizer, the main questions always remain - IMO - a) does it work well b) does it give benefits c) does it cause regression d) how much time we need to work on it |
| 21:46.44 | Estel_ | aka feasiobility |
| 21:46.49 | kerio | i propose changing cssu-thumb in cssu-leet |
| 21:47.00 | Estel_ | + minor but important aspects, like maintainability, etc |
| 21:47.09 | Estel_ | every thing discussed today have allo of them fullfiled |
| 21:47.30 | Estel_ | fix included in upstream, well documented, people interested to work on it and maintain it, benefits, no regressions. |
| 21:47.43 | Estel_ | it's about practice > ideology. |
| 21:48.01 | Estel_ | You're free to beat anyone involved if it cause serious problems, but not before, just "to be on safe side" |
| 21:48.19 | DocScrutinizer05 | a) it works well for those who use it b) it has benefits for them, without any changes of the policies c) the point is it mustn't have regressions that are not inevitable and d) it's your time. don't worry about our time! |
| 21:48.33 | Estel_ | merlin1991, about testhingy - no idea, You're better asking zeq about it |
| 21:49.43 | Estel_ | well, future will tell - I'm sure it will end like thumb thing after all, i.e. perfectly doable and benefitable, without regressions |
| 21:49.51 | Estel_ | lets see what future will bring :) |
| 21:50.04 | Estel_ | atfer all, nothing is un-rollback-able |
| 21:50.30 | DocScrutinizer05 | Estel_: that's a BS statement, sorry. CSSU policy and manifest will not 'end' anywhere - it IS |
| 21:50.31 | Estel_ | in worst case scenario, which isn't going to come, in my humble opinion. |
| 21:51.05 | Estel_ | DocScrutinizer, and what you will do? Lie in the path of train as act of protest? last time you've said "well, if You think like that it's ok, i'll beat You if something goes wrong" |
| 21:51.06 | Estel_ | which is fair |
| 21:51.40 | Estel_ | I'm also eager to see what future will bring |
| 21:51.45 | Estel_ | and it seems to be best conclusion |
| 21:52.06 | DocScrutinizer05 | Estel_: you're again short of arguments and thus starting to use your annoying tedious style which I'll ignore like I always do. cya |
| 21:52.43 | Estel_ | no worries, if this makes you happy during this pleasant summer time, we may agree that i'm short of arguments :) |
| 21:52.45 | Estel_ | see ya. |
| 21:54.43 | javispedro | ah, the winds of maemo never change. |
| 21:55.04 | DocScrutinizer05 | javispedro: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! yeeeeehaaaaaa! hello ol'fart! |
| 21:55.20 | javispedro | :D hello! |
| 21:55.33 | merlin1991 | javispedro: any idea why tracker indexers like the flc ones are missing if you udpate the core tracker package? |
| 21:56.04 | merlin1991 | s/flc/flac/ |
| 21:56.17 | javispedro | you get me thinking when did tracker gain fuzzy logic capabilities... |
| 21:56.26 | javispedro | *got |
| 21:57.12 | javispedro | last time the flac indexers stopped working, they were horribly packaged/optified, linking to non-existing libraries. |
| 21:57.19 | javispedro | since then they have always worked for me. |
| 21:57.48 | javispedro | there was this big libFLAC/pulseaudio/maemo-optify triangle of DOOM. |
| 21:58.03 | merlin1991 | well since we updated tracker in -testing users have been claiming that tracker did not index ogg / flac / whatever fancy extra codec anymore if the support was installed prior to the update |
| 21:58.10 | Estel_ | javispedro, hi there :) abusing Your presence - could You, please, link me to your latest, unreleased in repos version of radio program for N900? |
| 21:58.20 | merlin1991 | playback from filemanager still works though |
| 21:58.32 | javispedro | merlin1991: maybe ABI change? |
| 21:58.44 | merlin1991 | and I found out that by reinstalling ogg-support (it does ogg and flac) tracker suddenly indexed again |
| 21:58.54 | merlin1991 | and abi change, well all we did was apply your patches :D |
| 21:58.55 | javispedro | Estel_: https://github.com/javispedro/cfmradio.git |
| 21:58.55 | Estel_ | javispedro, any concerns if I would put it to the repos, of course crediting You properly? |
| 21:58.59 | Estel_ | thanks |
| 21:59.07 | javispedro | Estel_: not much difference I think from what was packaged |
| 21:59.13 | javispedro | Estel_: most of it was just testing stuff |
| 21:59.19 | Estel_ | I see |
| 21:59.44 | javispedro | (iirc there were some additional nonsense buttons in the appmenu for changing audio routes) |
| 21:59.55 | Estel_ | I remember something about possibility ot define output for audio, and it's volume |
| 21:59.59 | Estel_ | which was lacking in released version |
| 22:00.01 | Estel_ | or smth like that |
| 22:00.06 | javispedro | did not play with volume |
| 22:00.10 | javispedro | but you can trigger the analog bypass |
| 22:00.16 | javispedro | so that radio uses 0% cpu time |
| 22:00.21 | javispedro | but then you might fry your speakers |
| 22:00.27 | javispedro | choice is yours! ;) |
| 22:00.33 | Estel_ | It's possible to use analog bypass with this radio? 0_o? |
| 22:00.37 | Estel_ | awesome |
| 22:00.51 | Estel_ | someone told me long time ago, that it's almsot undoable in N900 :) |
| 22:01.07 | Estel_ | javispedro, we have (currently not included in our upstream) kernel-module for filtering output for speakers |
| 22:01.16 | Estel_ | maybe it would be good reason to revive it |
| 22:01.20 | javispedro | Estel_: analog will bypass that too. |
| 22:01.25 | Estel_ | I see |
| 22:01.37 | Estel_ | any way to put lowpass filter alongside analog output? |
| 22:01.49 | Estel_ | or it's just so 1337 that it will bypass everything? |
| 22:02.08 | Estel_ | stupid android uses analog bypass, and somehow, they don't blow up speakers |
| 22:02.10 | javispedro | there were some talks about implementing the filters on the audio chip itself (forgot the name :/) |
| 22:02.35 | javispedro | maybe that's what the kernel module does? I have no idea which kernel module are you talking about btw. |
| 22:02.52 | Estel_ | javispedro, yeah, isn't that related to kernel module talking with that chip? |
| 22:03.01 | Estel_ | yea, it was this thing |
| 22:03.07 | Estel_ | on audio chip, can't recall name though |
| 22:03.30 | Estel_ | so, analog bypass is available on git versin only, not in the pre-compiled one? |
| 22:03.40 | javispedro | only git |
| 22:03.50 | javispedro | also you need to #define sth, lemme check |
| 22:04.14 | Estel_ | why the hell haven't You released it? It's awesome, for us, radio fans |
| 22:04.18 | Estel_ | :) |
| 22:04.52 | javispedro | https://github.com/javispedro/cfmradio/blob/510f98cf1749ddae72aebf1d9f8561ebff56831f/cfmradio.c#L11 |
| 22:05.01 | javispedro | #define ADV_AUDIO_ROUTING 1 there |
| 22:05.18 | Estel_ | nods |
| 22:05.38 | Estel_ | is switching this from gui implemented, or is it decided on compile time (bypassing or not) |
| 22:05.43 | javispedro | gui |
| 22:05.53 | Estel_ | great, thanks a lot |
| 22:06.11 | javispedro | hit the menu and you'll see some extra buttons |
| 22:06.47 | Estel_ | And I suppose that you had it ready for ages, just not released? And we struggled with FM Radio for years? You cruel one :) |
| 22:06.55 | javispedro | struggled? |
| 22:07.07 | javispedro | it's just some mixer setting |
| 22:07.08 | Estel_ | it's irritating as hell, the msot popular FM Radio |
| 22:07.19 | Estel_ | when it crashes, N900 microphone stop working |
| 22:07.33 | Estel_ | wise heads were shaking at it, without finding out "why" |
| 22:07.37 | Estel_ | only reboot solve it |
| 22:07.53 | javispedro | same would happen to mine |
| 22:07.59 | Estel_ | OTOh, CFM Radio is great, just lacked few things sitting in your git for ages :) |
| 22:08.16 | Estel_ | no idea why, but CFM radio *never* resulted in such weirdness for me |
| 22:08.17 | javispedro | (but I guess mine crashes slightly less often, being so simple and everything) |
| 22:08.22 | Estel_ | or any other radio program, other than fm radio |
| 22:08.28 | Estel_ | nods |
| 22:08.44 | *** join/#maemo-ssu taziff1 (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 22:09.05 | javispedro | I prefer the N950/N9 radio hardware, despite the fact you'll never get 0% cpu usage playing there. |
| 22:09.25 | Estel_ | whats ie better there, then? |
| 22:09.25 | javispedro | faster tuning and digital audio output |
| 22:09.39 | javispedro | and you don't even need to turn bt on |
| 22:09.41 | Estel_ | well, on N900 we also have digital audio output, just not connected anywhere... like fmtx in N950/N9 :P |
| 22:09.55 | Estel_ | I see |
| 22:10.02 | javispedro | I still don't know if fmtx is connected or not on n9. |
| 22:10.16 | Estel_ | reportedly, isn't, but it may be urban legend. On N950, it seems that it isn't for sure |
| 22:10.30 | javispedro | On N950 it's the actual tx hardware missing. |
| 22:10.35 | Estel_ | I wonder, if on N950 it is modable? I wasn't able top trace visible track |
| 22:10.36 | javispedro | the wl127x variant used just doesn't have it. |
| 22:10.54 | Estel_ | hm, reportedly, it was present, but not connected, although, I have no idea how reliable this info is |
| 22:11.12 | Estel_ | so is this whole "unconnected fmtx" a urban myth, then? |
| 22:11.16 | javispedro | no one really seems to know the n950 hardware for certain around. |
| 22:11.27 | Estel_ | need X-ray'ing it :) |
| 22:11.31 | Estel_ | at least for patches |
| 22:11.35 | Estel_ | path* |
| 22:11.37 | Estel_ | cooper ones |
| 22:11.49 | javispedro | Estel_: I like to think that if noone made it yet means it is not connected. |
| 22:11.58 | kerio | are the alsa mixers saved somewhere, or can you reset them by rebooting if you fear you screwed up something? |
| 22:12.35 | Estel_ | javispedro, probably yes, and people talking about unconnected fmtx were quite certain about it |
| 22:12.49 | javispedro | kerio: you can definitely mess stuff up to the point you need to remove batteries |
| 22:13.00 | javispedro | I don't remember if maemo saves alsa mixer values though. I think not. |
| 22:13.22 | javispedro | (plus the entire "burn the speakers" thing, of course) |
| 22:17.06 | javispedro | my holidays started, hope to be more often around here. For a few days at least ;P |
| 22:18.59 | DocScrutinizer05 | (there were some talks about implementing the filters on the audio chip itself (forgot the name :/) ) /me and this eastern guy HNZ or whatever |
| 22:21.35 | javispedro | DocScrutinizer05: you know if that's what "the kernel module" mentioned above does? |
| 22:22.01 | DocScrutinizer05 | nfc what's this "the kernel module" mentioned above ;-) |
| 22:22.18 | DocScrutinizer05 | got as few context as javispedro |
| 22:22.45 | DocScrutinizer05 | javispedro: holidays? congrats, me too :-D |
| 22:22.59 | DocScrutinizer05 | so I will rethink my planning |
| 22:23.26 | DocScrutinizer05 | you being around changes weights between IRC/maemo and going to camp in the woods |
| 22:23.37 | javispedro | heh |
| 22:23.43 | merlin1991 | the gentoo guy dunno his name wrote something for the kernel |
| 22:23.50 | Estel_ | luke_jr |
| 22:23.54 | Estel_ | although, he didn't wrote it |
| 22:23.58 | DocScrutinizer05 | ooh luke |
| 22:23.59 | Estel_ | just send :P |
| 22:24.01 | merlin1991 | or adapt it, or whatever |
| 22:24.03 | Estel_ | yea |
| 22:24.17 | merlin1991 | I think the patch was in kp for some time but got removed again |
| 22:24.24 | Estel_ | it was for a 5 mijnutes in non-repo version of kp, but got kicked out, as he was not interested in maintaining it |
| 22:24.24 | merlin1991 | you'd have to ask Pali for the details |
| 22:24.32 | Estel_ | and fixing to apply only for speaker output, not all output |
| 22:24.39 | javispedro | Support-for-tlv320aic3x-codec-highpass-filter-needed.diff |
| 22:24.44 | javispedro | ^^ found it |
| 22:24.52 | Estel_ | yea, I'm collecting irc log and will pester Pali about usability of properly integrating it |
| 22:24.56 | DocScrutinizer05 | that's it |
| 22:24.59 | Estel_ | yea |
| 22:24.59 | Estel_ | it is it |
| 22:25.05 | DocScrutinizer05 | that's the codec hw filter |
| 22:25.39 | javispedro | so you should fetch the tlv320 datasheet and read whether the filtering applies to the 2nd analog bypass |
| 22:25.51 | DocScrutinizer05 | hehehe |
| 22:25.56 | DocScrutinizer05 | HF |
| 22:26.11 | javispedro | I think that means "probably not" ;) |
| 22:26.12 | DocScrutinizer05 | the datasheet is BS |
| 22:26.40 | DocScrutinizer05 | I got severe headache and left me as wise as before more often than not |
| 22:27.20 | javispedro | https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/Support-for-tlv320aic3x-codec-highpass-filter-needed.diff;h=962061affdbff324d640a6edf3b5fd17889b74e7;hb=HEAD |
| 22:27.23 | javispedro | from reading the patch, MNZ did it. |
| 22:27.35 | DocScrutinizer05 | so dunno, afaik the filter is a part of digital domain, so if your bypass is mere analog domain, it obviosuly won't get any filtering |
| 22:28.03 | DocScrutinizer05 | MNZ was the name |
| 22:28.04 | DocScrutinizer05 | yep |
| 22:28.11 | DocScrutinizer05 | I guided him |
| 22:28.24 | javispedro | it seems to be right before the DAC, so digital domain. |
| 22:28.33 | DocScrutinizer05 | yep, sure |
| 22:28.37 | javispedro | well, you can't have everything |
| 22:28.47 | javispedro | at least you can now safely use alsa directly |
| 22:28.59 | DocScrutinizer05 | :nod: |
| 22:29.47 | DocScrutinizer05 | if only @¼¼³&§%##!!”ĸµ̣Nokia would bother to tell about the *parameters* of their friggin XPROT |
| 22:29.52 | Estel_ | so, this path doesn't have anything to do with our analog bypass, hm |
| 22:30.00 | Estel_ | no idea to re-implement it for analog too? |
| 22:30.11 | DocScrutinizer05 | not feasible |
| 22:30.33 | DocScrutinizer05 | there are no analog filters |
| 22:30.42 | Estel_ | fun mod - hardware highpass filter connected before speaker's springs |
| 22:30.53 | javispedro | also, the patch will add some new 3d effects to alsamixer |
| 22:31.02 | DocScrutinizer05 | well, THAT was feaqsible, in theory |
| 22:31.10 | Estel_ | 0_o 3d effects is something i react allergically to |
| 22:31.30 | DocScrutinizer05 | so you'll appreciate you now can turn them off ;-P |
| 22:31.40 | javispedro | hah |
| 22:31.48 | javispedro | you could probably implement a hardware equalizer |
| 22:31.49 | Estel_ | DocScrutinizer, thin plate with cooper, to be placed between motherboard and speakers, that lead to one highpass hardware filter :P |
| 22:32.07 | DocScrutinizer05 | javispedro: that's what MNZ actually planned to do |
| 22:32.13 | Estel_ | hardware equalizer, hujh |
| 22:32.14 | javispedro | very nice |
| 22:32.16 | Estel_ | interesting |
| 22:32.22 | javispedro | I used to have a hweq with my creative card |
| 22:32.31 | DocScrutinizer05 | he gave up when he realized complexity to calculate the coefficients of digital filter |
| 22:32.39 | Estel_ | Audigy 2ZS video editor gold, here ;) |
| 22:32.56 | javispedro | yeah, I had 2ZS too |
| 22:33.06 | javispedro | best Linux sound card ever imho, hwmixing, sf2. |
| 22:33.08 | Estel_ | pity that they have castrated X-fi and later ones |
| 22:33.11 | Estel_ | yes |
| 22:33.18 | javispedro | X-Fi is not castrated, driver just does not support anything |
| 22:33.24 | javispedro | the new ones ARE castrated. |
| 22:33.26 | DocScrutinizer05 | this didital filter in codec is a biatch, regarding handling |
| 22:33.30 | Estel_ | this oen i'm talking about is external usb one, works even with N900 via already build in modules (!) |
| 22:33.41 | Estel_ | IOI also have PCI one lying in drawer, also gold |
| 22:34.11 | Estel_ | sad fact - despite the usb one being video editor, I can't seem to utilize video part of it, even on windoze, LOL. Pity, as it's video part was decent |
| 22:34.29 | DocScrutinizer05 | you got like 8 32bit coefficients, and none of them is exactly trivial to calculate |
| 22:34.34 | Estel_ | hardware mpeg2 compression with very high output quality... eh |
| 22:34.57 | Estel_ | javispedro, wasn't X-fi lacking sound processor on card?> |
| 22:35.01 | Estel_ | off-loading it to CPU? |
| 22:35.32 | Estel_ | it was quite... smalll, light (as per weight), and seemed to contain small ammount of components |
| 22:35.37 | javispedro | Estel_: emu20kx ones don't |
| 22:35.40 | Estel_ | or I mistaked it with next one |
| 22:35.46 | Estel_ | I see |
| 22:36.23 | javispedro | on my todo list there's an item "buy titanitum card and figure out how to get emux synthesizer working" =) |
| 22:36.31 | Estel_ | I used to have this big desk thing, from audigy 2zs, from "pro" version, with big jacks... |
| 22:37.12 | Estel_ | but 2zs video editor is even better, all kind of audio output and imputs, including optical ones and midi. + built in powered 4 port usb hub :P |
| 22:37.15 | Estel_ | javispedro, :) |
| 22:37.27 | Estel_ | isn't it better to just use old good 2zs? |
| 22:37.32 | Estel_ | what titanium offer over it? |
| 22:37.37 | javispedro | pciexpress |
| 22:37.46 | Estel_ | yes, and it's required for? |
| 22:38.02 | merlin1991 | low latency? |
| 22:38.04 | javispedro | in two years you won't be able to find motherboards with pci |
| 22:38.10 | merlin1991 | and that :D |
| 22:38.14 | Estel_ | merlin1991, would need implementation in card for that |
| 22:38.15 | javispedro | _good_ ones I mean |
| 22:38.20 | Estel_ | javispedro, pci to usb adaptors? |
| 22:38.22 | Estel_ | + DIY case |
| 22:38.28 | Estel_ | and You have desktop external card :) |
| 22:38.33 | javispedro | pci to usb adaptor? :P |
| 22:38.42 | Estel_ | may be BS, heard somewhere about it |
| 22:39.08 | Estel_ | anyway, it's good argument - I have notebook acting as desktop, it was another reason why audigy 2zs video editor (it's USB) |
| 22:39.49 | Estel_ | there was also some kind of notebook-friendly one, powered from USDB, but it was fubar - advertised as 24 bit one, it did internal downsampling to 16 bi for processing, then, upsampling to 24 bit on exit |
| 22:39.54 | javispedro | also, pci 2zs usually die of the "crackling" problem |
| 22:39.59 | Estel_ | Creative never was very reliable partner :P |
| 22:40.04 | javispedro | they are harder to get every day :( |
| 22:40.18 | Estel_ | good to know, my gold one bought for 30 dollars may be worth more now :p |
| 22:41.04 | Estel_ | but this usb external one (requiring another power source from mains) zs video editor is really state of art |
| 22:41.21 | Estel_ | for both audio and video. If it would only work for me re video part... :P |
| 22:41.34 | Estel_ | never needed to use it, so noticed that video isn't working 2 years after purchase |
| 22:41.52 | Estel_ | oddly, video processing part is visible from operating system as working ok, it just refuses to work in practice |
| 22:42.19 | Estel_ | every video capturing thing just hangs out, when card's imput is selected |
| 22:42.24 | Estel_ | odd as hell |
| 22:42.37 | Estel_ | and of course only windoze drivers for video part, say hi to creative |
| 22:42.51 | Estel_ | notg popular one enough to have linux Re drivers |
| 22:43.19 | Estel_ | although I was surprised as hell, when noticing that I may connect it to N900 via hostmode, and enjoy 7.1 audio output (5.1 in practice) |
| 22:43.33 | Estel_ | only through mplayer, though, of course |
| 22:43.39 | Estel_ | say hi to N900's pulseaudio :P |
| 22:44.03 | Estel_ | (every attempt to redirect mafw output to usb sound card failed msierably) javispedro, You even were in this thread |
| 22:44.39 | javispedro | I remember the last consensus was "kernel bug" |
| 22:46.05 | Estel_ | wut? |
| 22:46.28 | Estel_ | either I remember it wrong way, or it was something different - I would be pestering Pali to fix it in KP |
| 22:47.05 | javispedro | meh, my memory is quite hazy |
| 22:51.47 | Estel_ | javispedro, http://http://talk.maemo.org/showthread.php?t=83270 |
| 22:52.03 | Estel_ | consensus was that You haven't had USB card/speaker :) |
| 22:52.13 | Estel_ | and were wondering about emulating it |
| 22:52.27 | javispedro | and I don't, you got me interested in the video capture + audio card thing though |
| 22:52.38 | Estel_ | see: http://talk.maemo.org/showpost.php?p=1191590&postcount=77 |
| 22:52.53 | Estel_ | and this: |
| 22:52.54 | Estel_ | http://talk.maemo.org/showpost.php?p=1191583&postcount=75 |
| 22:53.03 | Estel_ | hm, audio and video thing>? ncie to hear, i though you've bored You :) |
| 22:53.05 | Estel_ | well, it is |
| 22:53.07 | Estel_ | lemme search |
| 22:53.47 | Estel_ | http://www.google.pl/search?q=audigy+2zs+video+editor&hl=pl&prmd=imvns&tbm=isch&tbo=u&source=univ&sa=X&ei=3wQbUPXUN62N4gTZ24H4Dg&ved=0CGUQsAQ&biw=1540&bih=773 |
| 22:54.19 | Estel_ | it's lovely external USB card, this time not fake'ing anything, and being real 24bit/96khz one |
| 22:54.35 | Estel_ | (up to, you may use real-life values of 16bit 48 khz too) |
| 22:55.03 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 22:55.14 | Estel_ | it have hardware control over imput level via gauge, and gauge for outpout, hoever, the latter is mixed with OS control |
| 22:55.28 | Estel_ | inas and outs visible in photos |
| 22:55.54 | Estel_ | + 4HUB usb 2.0 active hub (to the point of requiring external power to have even only hub working) |
| 22:56.20 | javispedro | are you sure it is a emu10k1 card? |
| 22:56.31 | javispedro | which ALSA driver are you using? |
| 22:56.39 | Estel_ | erm, in fact I'm not sure at all, but for sure it works with alsa... |
| 22:56.40 | Estel_ | hmmm |
| 22:56.45 | Estel_ | which ones we have in N900? :D |
| 22:56.50 | Estel_ | that's the oldest I've tried |
| 22:57.00 | javispedro | just lsmod and grep for emu10k1 |
| 22:57.26 | Estel_ | gimme a second, I'm on windoze actually (i know, shame...), it should work when i connect it to n900 too? |
| 22:57.48 | Estel_ | (emu10k1) |
| 22:57.52 | Estel_ | (not card itself) |
| 22:58.49 | javispedro | http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs |
| 22:58.54 | javispedro | they don't seem to know anything about it |
| 22:59.02 | javispedro | I bet it is probably not emu10k1 and just USB sound card ;P |
| 23:00.55 | javispedro | also, kernel bug here: http://talk.maemo.org/showpost.php?p=1193473&postcount=80 |
| 23:04.00 | Estel_ | javispedro, tried it and no emu10k1 |
| 23:04.08 | Estel_ | what drawbacks it does mean? |
| 23:04.16 | javispedro | no hw equalizer |
| 23:04.26 | javispedro | and no hw mixing I think |
| 23:04.35 | Estel_ | strange, I can definitely mix in hw |
| 23:04.47 | Estel_ | maybe it require custom drivers, though |
| 23:04.49 | javispedro | not dmix? :) |
| 23:04.56 | Estel_ | definitely not dmix |
| 23:05.21 | Estel_ | no much experience with using it under linux, sadly, for any advanced things, thanks to it being very niche |
| 23:05.33 | Estel_ | so under linux I use it for... well, normal audio output :P |
| 23:05.52 | Estel_ | under windoze it definitely have hardware mixing and hardware equalizer, but it's thing of propertiary drivers, probably |
| 23:06.14 | Estel_ | because, upon connection it's recognized (under linux) ass usb hub first, then, card is connected to internal ports... |
| 23:06.19 | Estel_ | on windows, You see more components |
| 23:06.26 | Estel_ | i.e. more devices detected |
| 23:06.33 | Estel_ | probably, under linux it works as normal USB card |
| 23:06.50 | Estel_ | so no rela 5.1 for me, then, from N900? :) |
| 23:07.17 | Estel_ | continuation - I think that under windoze another device is detected, as one talking with hardware mjxing parts |
| 23:07.19 | Estel_ | mixing* |
| 23:07.32 | Estel_ | probably even Hw equalizer, although I don't use equalizers at all, so hard to tell |
| 23:07.39 | Estel_ | definitely no video device detected under linux, too |
| 23:07.41 | javispedro | I am reading the alsa snd-usb driver and they only do 1 substream, so no hw mixing |
| 23:07.51 | RST38h | moos at javispedro evilly |
| 23:08.04 | Estel_ | nods at javispedro |
| 23:08.12 | javispedro | moo RST38h |
| 23:08.21 | Estel_ | pity :D |
| 23:08.34 | Estel_ | hey, so no multi-channel recording too? |
| 23:08.40 | Estel_ | :((( |
| 23:08.52 | javispedro | it might have multichannel recording, dunno about that |
| 23:08.59 | Estel_ | it's pity that RE things (as under windozxe it works, definitely) isn't ferasible |
| 23:09.03 | Estel_ | feasible, lol |
| 23:09.05 | Estel_ | sorry for typos |
| 23:09.09 | RST38h | runs out with a pitchfork |
| 23:10.08 | javispedro | Estel_: CT is not very friendly any longer either |
| 23:10.12 | Estel_ | I just suspect that my video processing part is faulty, which is strange, as it's bundled on 1 board, and as said, drivers report hardware detected properly (on windoze) |
| 23:10.19 | javispedro | previously they would even submit research papers frm time to time. |
| 23:10.26 | Estel_ | Creative was friendly anytime?:p |
| 23:10.32 | Estel_ | ah, I see |
| 23:10.43 | Estel_ | I remember them as asshats from the beginning, though. |
| 23:10.54 | javispedro | well, I might be confusing EMU with CT ;P |
| 23:10.58 | Estel_ | I wonder what bite them |
| 23:19.40 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 23:35.53 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 23:38.36 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |