| *** smoku has joined #maemo-ssu | 00:04 | |
| *** _rd has quit IRC | 01:10 | |
| *** LaoLang_cool has joined #maemo-ssu | 02:33 | |
| *** smoku has quit IRC | 02:47 | |
| *** smoku has joined #maemo-ssu | 02:47 | |
| *** gri has quit IRC | 03:19 | |
| *** gri has joined #maemo-ssu | 03:25 | |
| *** trbs has quit IRC | 03:26 | |
| *** LaoLang_cool has quit IRC | 03:30 | |
| *** smoku has left #maemo-ssu | 03:57 | |
| *** arcean has quit IRC | 04:15 | |
| *** amiconn has quit IRC | 05:54 | |
| *** amiconn_ has joined #maemo-ssu | 05:54 | |
| *** amiconn_ is now known as amiconn | 05:54 | |
| *** nox- has quit IRC | 06:47 | |
| *** Sc0rpius has quit IRC | 07:31 | |
| *** Sc0rpius has joined #maemo-ssu | 08:12 | |
| *** gri_ has joined #maemo-ssu | 08:15 | |
| *** lartza__ has joined #maemo-ssu | 08:16 | |
| *** lartza_ has quit IRC | 08:21 | |
| *** infobot has quit IRC | 08:21 | |
| *** wmarone_ has quit IRC | 08:21 | |
| *** andre__ has quit IRC | 08:21 | |
| *** ZogG has quit IRC | 08:21 | |
| *** IronLegend has quit IRC | 08:21 | |
| *** gri has quit IRC | 08:21 | |
| *** Raimu-X has quit IRC | 08:21 | |
| *** guly has quit IRC | 08:21 | |
| *** StyXman has quit IRC | 08:21 | |
| *** Raimu has quit IRC | 08:21 | |
| *** RST38h has quit IRC | 08:21 | |
| *** AndrewX192 has quit IRC | 08:21 | |
| *** claw has quit IRC | 08:21 | |
| *** ChanServ has quit IRC | 08:21 | |
| *** wmarone_ has joined #maemo-ssu | 08:22 | |
| *** andre__ has joined #maemo-ssu | 08:22 | |
| *** ZogG has joined #maemo-ssu | 08:22 | |
| *** Raimu has joined #maemo-ssu | 08:22 | |
| *** RST38h has joined #maemo-ssu | 08:22 | |
| *** IronLegend has joined #maemo-ssu | 08:22 | |
| *** AndrewX192 has joined #maemo-ssu | 08:22 | |
| *** claw has joined #maemo-ssu | 08:22 | |
| *** Raimu-X has joined #maemo-ssu | 08:22 | |
| *** guly has joined #maemo-ssu | 08:22 | |
| *** StyXman has joined #maemo-ssu | 08:22 | |
| *** ChanServ has joined #maemo-ssu | 08:22 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 08:22 | |
| *** lartza__ has quit IRC | 08:23 | |
| *** lartza_ has joined #maemo-ssu | 08:23 | |
| *** pabs3 has joined #maemo-ssu | 10:13 | |
| *** pabs3 has left #maemo-ssu | 10:13 | |
| *** dafox has joined #maemo-ssu | 10:16 | |
| *** Pali has joined #maemo-ssu | 10:38 | |
| *** BCMM has joined #maemo-ssu | 11:25 | |
| *** arcean has joined #maemo-ssu | 12:14 | |
| *** BCMM has quit IRC | 12:41 | |
| *** RST38h_ has joined #maemo-ssu | 12:42 | |
| *** wmarone_ has quit IRC | 13:06 | |
| *** RST38h_ has quit IRC | 13:17 | |
| *** RST38h_ has joined #maemo-ssu | 13:23 | |
| *** RST38h_ has quit IRC | 13:31 | |
| *** wmarone_ has joined #maemo-ssu | 13:47 | |
| *** psycho_oreos has joined #maemo-ssu | 13:57 | |
| *** RST38h_ has joined #maemo-ssu | 15:09 | |
| merlin1991 | X-Fade: ping | 15:23 |
|---|---|---|
| DocScrutinizer | merlin1991: seems he's listening on #harmattan | 15:27 |
| DocScrutinizer | or at least did, 20 minutes ago | 15:28 |
| *** DocScrutinizer has quit IRC | 15:56 | |
| *** DocScrutinizer has joined #maemo-ssu | 15:56 | |
| *** RST38h_ has quit IRC | 16:03 | |
| merlin1991 | probably went for lunchbreak | 16:09 |
| merlin1991 | or other stuff :D | 16:09 |
| *** DocScrutinizer has quit IRC | 16:22 | |
| *** DocScrutinizer has joined #maemo-ssu | 16:22 | |
| *** DocScrutinizer has quit IRC | 16:30 | |
| *** DocScrutinizer has joined #maemo-ssu | 16:30 | |
| *** DocScrutinizer has quit IRC | 16:33 | |
| *** DocScrutinizer has joined #maemo-ssu | 16:33 | |
| merlin1991 | DocScrutinizer, MohammadAG name for the rewrites component? | 16:34 |
| DocScrutinizer | merlin1991: name for repo? | 16:40 |
| merlin1991 | nope component inside cssu repo | 16:40 |
| DocScrutinizer | cssu-optional | 16:40 |
| merlin1991 | it went down as "replace" | 16:40 |
| DocScrutinizer | well, more specific | 16:41 |
| merlin1991 | since we have free and non-free | 16:41 |
| DocScrutinizer | where would things like orientation-lock reside? | 16:42 |
| merlin1991 | free as an opt-in | 16:42 |
| merlin1991 | free is for new and already oss packages | 16:42 |
| merlin1991 | non-free is for everything nokia is kind enough to hand over (certman applet) | 16:42 |
| merlin1991 | and replace is for everything that replaces former non-free stuff | 16:43 |
| merlin1991 | and we'll introduce a new metapackage, yay :/ | 16:43 |
| *** kent_autistic has joined #maemo-ssu | 16:43 | |
| DocScrutinizer | aaah | 16:44 |
| DocScrutinizer | :-) | 16:44 |
| merlin1991 | I went for the new component way since with an all new repo we'd have a hard time ensuing cssu is installed aswell (since we do depend on cssu for that optional stuff) | 16:45 |
| merlin1991 | s/ensuing/ensuring/ | 16:46 |
| DocScrutinizer | :nod: | 16:46 |
| DocScrutinizer | I think we should think a few days about it, discuss it | 16:46 |
| merlin1991 | X-Fade: is putting the server side into place as we speak, how we end up using it we can still discuss :) | 16:47 |
| DocScrutinizer | the purpose however should be clear: have a "monolitic" CSSU install that only comes with mandatory stuff, and have a way to allow user to select optional packages in a finegrained though convenient way | 16:47 |
| merlin1991 | yep | 16:48 |
| DocScrutinizer | for optional packages we need to distinguish a few cases: stuff that replaces maemo-mp components, stuff that depends on cssu, ... <other>? | 16:49 |
| merlin1991 | yeah, I suggest we do a proper meeting next week? | 16:49 |
| DocScrutinizer | for each case we have to consider dependencies carefully | 16:50 |
| DocScrutinizer | I'm "free" next week, so why not | 16:50 |
| merlin1991 | "free" ? :D | 16:50 |
| DocScrutinizer | holiday | 16:50 |
| merlin1991 | ah :) | 16:50 |
| DocScrutinizer | another awesome 1.5 weeks | 16:51 |
| merlin1991 | Pali, arcean, MohammadAG: got time next week monday @16 UTC (18 CET) ? | 16:51 |
| DocScrutinizer | merlin1991: I'd like to invite jaffa and a few others to discuss the implications with 'us' | 16:54 |
| merlin1991 | sure | 16:54 |
| DocScrutinizer | X-Fade as well, of course | 16:54 |
| DocScrutinizer | there might be pitfalls at least me doesn't realize | 16:55 |
| DocScrutinizer | there's nothing as annoying as a pitfall you fall in because you haven't anticipated it | 16:56 |
| X-Fade | Well, things might break. But it is hard to predict :) | 16:56 |
| DocScrutinizer | hi X-Fade :-D | 16:57 |
| *** psycho_oreos has quit IRC | 16:57 | |
| merlin1991 | things can't break even more than the ke-recv disaster :D | 16:57 |
| DocScrutinizer | what's you system-architect take on the topic? | 16:57 |
| DocScrutinizer | merlin1991: well, we might see urge to do a full rollback if anything in our design doesn't hold | 16:58 |
| MohammadAG | merlin1991, yes | 16:58 |
| X-Fade | Well, that would involve me deleting some files from the tree and re-indexing the repo. | 16:59 |
| X-Fade | Not that big of a deal. | 16:59 |
| DocScrutinizer | not exactly a big deal, as long as this happens for T | 17:00 |
| DocScrutinizer | for S however it was a mayor PITA, regarding user experience | 17:00 |
| X-Fade | You could push a different meta, just for testing this. | 17:00 |
| DocScrutinizer | simply means early pitfalls aren't as deep and hurting as late ones | 17:01 |
| merlin1991 | no worries I'd leave quite some testing period before this comes anywhere near stable | 17:01 |
| DocScrutinizer | merlin1991: sure thing :-) | 17:01 |
| X-Fade | Hehe, and that too. | 17:02 |
| DocScrutinizer | I never really wrapped my head around that components:free/non-free thingie | 17:02 |
| merlin1991 | it's mainly a policy thing | 17:03 |
| merlin1991 | you could slap everything into 1 component and still run the same project | 17:03 |
| DocScrutinizer | but how does it impact the way e.g. HAM works? | 17:03 |
| merlin1991 | apt doesn't care since we are still in the same repo, only ham might get ideas which is why we have to livetest it :) | 17:04 |
| *** RST38h_ has joined #maemo-ssu | 17:04 | |
| merlin1991 | as far as I see it we have to decide on a policy how we handle replacements and opt-ins from now on and then just try it with the next update | 17:04 |
| DocScrutinizer | my vision is along a new "category" besides "all" and "games" and "$foo", in HAM | 17:04 |
| DocScrutinizer | probably this idea won't fly though | 17:05 |
| merlin1991 | would require as slight update to ham | 17:05 |
| merlin1991 | nothing major though | 17:05 |
| merlin1991 | btw if you go down that path I'd suggest 2 categories for ham | 17:05 |
| merlin1991 | one for "cssu opt ins" and one for "foss replacements" | 17:06 |
| DocScrutinizer | since the new stuff only applies on CSSU systems and those systems are supposed to have patched HAM anyway, it might work | 17:06 |
| merlin1991 | sure patched ham would be part of the core mp | 17:06 |
| DocScrutinizer | sure, 1 new cat, 2, whatever | 17:06 |
| kent_autistic | since it already involves HAM, i hope something is being done about the slowness of HAM. | 17:07 |
| kent_autistic | and forget FAM | 17:07 |
| DocScrutinizer | well, fapman et all is indeed a problem when opting for this path | 17:08 |
| merlin1991 | kent_autistic: Pali did stuff to ham, though last time I tested his patches it didn't work properly, he made some fixes in the meantime so I'll reevaluate his code gain with the coming cssu udpate | 17:08 |
| merlin1991 | DocScrutinizer: I don't see why | 17:08 |
| kent_autistic | nice to know thanks! | 17:08 |
| DocScrutinizer | NFC about how fapman works, but we need to at least consider *if* it would | 17:08 |
| merlin1991 | apt would still work and fapman calls apt | 17:09 |
| merlin1991 | so it is going to still work | 17:09 |
| DocScrutinizer | hmm, ok | 17:09 |
| DocScrutinizer | if fapman doesn't care about categories at all, then fine | 17:09 |
| DocScrutinizer | "fine" | 17:09 |
| DocScrutinizer | :-P | 17:09 |
| merlin1991 | well fapman might not have the category visible in the ui | 17:10 |
| merlin1991 | but why would we care? | 17:10 |
| DocScrutinizer | :shrug: | 17:10 |
| * DocScrutinizer for sure won't | 17:10 | |
| merlin1991 | since we "know" that merely using fapman is bound to fubar your system if you got cssu | 17:10 |
| DocScrutinizer | as long as we are clear about it | 17:10 |
| DocScrutinizer | seems I'm once more guilty to have started something | 17:11 |
| DocScrutinizer | and then leaving for RL ;-D | 17:11 |
| * DocScrutinizer waves | 17:12 | |
| merlin1991 | :D | 17:12 |
| merlin1991 | hf | 17:12 |
| DocScrutinizer | thanks | 17:12 |
| Raimu | :) | 17:12 |
| DocScrutinizer | merlin1991: please don't forget to properly announce meeting | 17:12 |
| merlin1991 | currently trying to find out who's got time | 17:13 |
| merlin1991 | so far only you and mag replied :) | 17:13 |
| DocScrutinizer | and X-Fade | 17:13 |
| DocScrutinizer | I'd also appreciate javispedro joining | 17:14 |
| merlin1991 | phew I remembered my pin | 17:15 |
| X-Fade | Ok, I think I touched every script for it to work with -testing. | 17:15 |
| DocScrutinizer | best practice to announce such stuff by introducing the plan in large picture and asking participation/comments of whom-it-may-concern | 17:15 |
| merlin1991 | I'll post to maemo-devs | 17:16 |
| DocScrutinizer | great | 17:16 |
| DocScrutinizer | o/ | 17:16 |
| merlin1991 | but for now I'll write some emails to find out if people even have time :D | 17:17 |
| X-Fade | So ping me when you pushed something and things break :) | 17:17 |
| merlin1991 | X-Fade: currently we target to have a meeting about this first next monday so first thing pushed probably happening at some point next week :) | 17:17 |
| X-Fade | merlin1991: no problems, we'll see what happens. | 17:18 |
| *** kent_autistic has quit IRC | 17:24 | |
| merlin1991 | X-Fade: still here? | 17:26 |
| X-Fade | merlin1991: Sure | 17:27 |
| merlin1991 | http://maemo.org/packages/view/libxau6/ is still a problem in the repo | 17:27 |
| *** freemangordon has joined #maemo-ssu | 17:27 | |
| merlin1991 | (extras-devel) | 17:28 |
| X-Fade | merlin1991: Yeah, I guess a big cleanup is in order. It is just a massive pain.. | 17:28 |
| MohammadAG | it's more than that, it reboot loops systems | 17:28 |
| freemangordon | merlin1991, MohammadAG, I think we finally have ROCK STABLE thumb2 on n900, what do you think about introducing that in CSSU? | 17:30 |
| merlin1991 | oh hey freemangordon :D | 17:30 |
| freemangordon | :D | 17:30 |
| merlin1991 | read your mail ;) | 17:31 |
| MohammadAG | depends, rocks shatter with rain :P | 17:31 |
| freemangordon | merlin1991, yeah :D | 17:31 |
| merlin1991 | perfect so I only need a yes from arcean and Pali and we're good to go :) | 17:32 |
| freemangordon | well, my question re thumb was "in general", i.e. should i put more time in that or is it a no go | 17:32 |
| freemangordon | just an initial statement :) | 17:33 |
| freemangordon | Pali, BTW how is kubuntu (besides being slow as hell) | 17:33 |
| MohammadAG | if it doesn't break ABI, sure | 17:33 |
| freemangordon | break ABI? I am using it on my primary device | 17:34 |
| merlin1991 | about thumb2, whilst I see the advantages of it I'm not so sure if cssu is really the right target for it, for me it feels more like a thing for seperate repo | 17:34 |
| freemangordon | the only phone I have | 17:34 |
| MohammadAG | freemangordon, kubuntu's good | 17:34 |
| MohammadAG | but needs good resources | 17:34 |
| freemangordon | MohammadAG, 12.04 is hardfp thumb compiled ;) | 17:34 |
| merlin1991 | freemangordon: starting with the fact that you need a different gcc inside scratchbox | 17:34 |
| freemangordon | and before latest thumb2 fixes in uboot was SIGILLing every now and then | 17:35 |
| freemangordon | merlin1991, that is why CSSU is the right place AIUI | 17:35 |
| merlin1991 | freemangordon: does it work only by flashing a different kernel? | 17:35 |
| merlin1991 | s/only by/by only/ | 17:36 |
| freemangordon | yep, we need thumb errata workaround | 17:36 |
| merlin1991 | meaning without uboot? | 17:36 |
| freemangordon | yep | 17:36 |
| freemangordon | there is still no such kernel, nut it is easy to be done. | 17:36 |
| freemangordon | *but | 17:36 |
| freemangordon | it was easyer for me to patch u-boot | 17:37 |
| merlin1991 | if we really go through with that we'd need to provide scratchbox tool packages aswell | 17:37 |
| freemangordon | but the same could be implemented in kernel, it is just a matter of SMC call | 17:37 |
| merlin1991 | since anybody should be able to grap cssu sources compile them and run | 17:37 |
| freemangordon | merlin1991, gcc4.6.2 ready for SB is on your server :P | 17:37 |
| merlin1991 | which isn't the fact anymore if you can't do it with the default maemo scratchbox | 17:37 |
| freemangordon | ^^^ | 17:38 |
| freemangordon | BTW it *might* be possible that we don't need 4.6.2 | 17:38 |
| DocScrutinizer | general procedure to "upstream" kernel patches: spot a problem, understand the problem, REPRODUCE the problem, find a fix, PROVE fix actually id effective on previously demonstrated testscase that reproduces the problem. Mail to LKML with patches, get REVIEW, wait for upstream to include it to master branch, *then* include it to local branch | 17:38 |
| freemangordon | DocScrutinizer, I have only one life to live | 17:39 |
| DocScrutinizer | thumb is not only a kernel patch, it's a system wide issue | 17:39 |
| freemangordon | and the issue has beer reported and fixed back in 2009 | 17:39 |
| freemangordon | *been | 17:39 |
| freemangordon | we are not discovering the hot water here | 17:39 |
| freemangordon | the fix is not mine, but from TI | 17:40 |
| DocScrutinizer | so where's the problem to simply pull the 2009 patches into our local branch? | 17:40 |
| merlin1991 | freemangordon: I do appreciate the effort you put into this, but I'm inclined to think that it is somewhat out of the scope of cssu | 17:40 |
| freemangordon | merlin1991, ok | 17:40 |
| DocScrutinizer | I agree with merlin1991 here | 17:41 |
| merlin1991 | btw MohammadAG what's your take on the whole issue? | 17:42 |
| freemangordon | merlin1991, again, take your time with MohammadAG to discuss it, if you need some info just ask me. | 17:42 |
| merlin1991 | freemangordon: is there anything in maemo thumb2 atm? | 17:43 |
| freemangordon | yep | 17:43 |
| merlin1991 | besides the stuff on your device ;) | 17:43 |
| freemangordon | x-loader and nolo | 17:43 |
| merlin1991 | but nothing in userspace or other parts? | 17:44 |
| freemangordon | no way | 17:44 |
| freemangordon | you remember modest, ain't? | 17:44 |
| freemangordon | :D | 17:44 |
| merlin1991 | hehe | 17:44 |
| merlin1991 | basically my reasoning against this for cssu is, that it's too big of an unkonw / too big of a change to the system to be considered a simple "update" | 17:45 |
| freemangordon | merlin1991, it does not work like that | 17:45 |
| freemangordon | implementing the patch just enables thumb2 compiled binaries to work without crashes | 17:46 |
| freemangordon | it does not turn automagically all binaries to thumb-compiled :D | 17:47 |
| merlin1991 | I know | 17:47 |
| freemangordon | so it could be made st6ep by step | 17:47 |
| merlin1991 | but if you ship the patch I'm sure you want to ship loads of thumb compiled binaries aswell :D | 17:47 |
| freemangordon | no | 17:47 |
| freemangordon | slowly, one after another, first being Qt, as no critical part of the system depends on it | 17:48 |
| DocScrutinizer | so what's the benefit then? | 17:48 |
| freemangordon | and it is HUGE | 17:48 |
| freemangordon | 20-30% less RAM usage for Qt apps | 17:48 |
| freemangordon | and Qt could be moved to NAND(NOR) | 17:48 |
| merlin1991 | freemangordon: the other problem is, that we'd essentially break everything for anybody using a custom kernel | 17:49 |
| freemangordon | giving additional boost to load times | 17:49 |
| freemangordon | merlin1991, what kernel do you think of? | 17:49 |
| DocScrutinizer | look, we need to take responsibility for each single binary we ship. So if you ship a new thumb-enabled Qt, you basically find yourself as co-maintainer of every single Qt-based app on the system, doing triaging on bugtracker, trying to tule out it's your thumb thing that caused that problem | 17:49 |
| merlin1991 | for example I ran power46 for the injection drivers quite long | 17:50 |
| freemangordon | DocScrutinizer, and what is different with the situation as it is now? | 17:50 |
| merlin1991 | there is the btrfs kernel | 17:50 |
| merlin1991 | and other | 17:50 |
| merlin1991 | +üs | 17:50 |
| freemangordon | merlin1991, the only kernel that is still maintained is KP | 17:50 |
| merlin1991 | the problem I see with it, that we can't ship it as a single update | 17:50 |
| merlin1991 | freemangordon: does not mean it is the only one used | 17:50 |
| freemangordon | merlin1991, 20 lines patch could be easyly backported to any custom kernel we might have | 17:51 |
| DocScrutinizer | won't happen | 17:52 |
| merlin1991 | the point is cssu should work for *everyone*, I'm sure we could get another repo in place as "cssu-thumb2" and I'd have no problem adding it there | 17:52 |
| DocScrutinizer | full ack | 17:52 |
| freemangordon | that is a fork | 17:52 |
| merlin1991 | ye | 17:53 |
| DocScrutinizer | and maybe even eventually port that 20liner patch to anything cssu-core, IF we ever would dare to link CSSU to a kernel version | 17:53 |
| merlin1991 | normally you fork stuff when you can't achieve what you want within the bounds of the original project ;) | 17:53 |
| MohammadAG | question | 17:53 |
| merlin1991 | ... | 17:53 |
| MohammadAG | if we simply add the patch to all kernels | 17:53 |
| MohammadAG | and include omap1 patched kernel in CSSU | 17:54 |
| MohammadAG | wouldn't that cover all cases? | 17:54 |
| freemangordon | yep | 17:54 |
| DocScrutinizer | no | 17:54 |
| freemangordon | yes | 17:54 |
| merlin1991 | MohammadAG: anybody with his own kernel flashed is still fubar | 17:54 |
| DocScrutinizer | yep | 17:54 |
| merlin1991 | that's why I'd say have a fork of cssu that is thumb2 | 17:55 |
| DocScrutinizer | it's honestly WAAY beyond the scope of CSSU anyway | 17:55 |
| MohammadAG | sigh | 17:55 |
| freemangordon | guys, all kernels we have are omap1 based, and if you are good enough to build and flash your own kernel, should be able to backport that patch | 17:55 |
| freemangordon | and who we are talking about 5-10 geeks? | 17:55 |
| DocScrutinizer | that's getting quantitative argumentation now | 17:56 |
| DocScrutinizer | CSSU is supposed to be compatible | 17:56 |
| freemangordon | DocScrutinizer, was CSSU compatible when Qt 4.7.4 was brought in? | 17:57 |
| DocScrutinizer | I dunno, but if it wasn't it was a major mistake anyway | 17:57 |
| freemangordon | or it broke a couple of applications and custom setups? | 17:57 |
| MohammadAG | it's like telling Nokia not to have a newer kernel in an update cause custom ones will still be old | 17:57 |
| DocScrutinizer | not the first mistake in CSSU | 17:57 |
| freemangordon | MohammadAG, agree | 17:57 |
| merlin1991 | freemangordon: Qt 4.7.4 broke stuff because if was borken itself | 17:58 |
| merlin1991 | when we fixed that (optimisation flag) everything was compatible | 17:58 |
| MohammadAG | basically, if omap1 is shipped, it'll overwrite any custom kernel in place | 17:58 |
| freemangordon | merlin1991, after that | 17:58 |
| DocScrutinizer | MohammadAG: nope, as Nokia wouldn't come up with an incompatible kernel | 17:58 |
| MohammadAG | we can ship both omap1, and kp can include the patch upstream | 17:58 |
| MohammadAG | DocScrutinizer, this doesn't break anything the way I understand it | 17:58 |
| DocScrutinizer | it does | 17:59 |
| DocScrutinizer | for all those that have any custom built kernel | 17:59 |
| MohammadAG | shipping only the kernel doesn't | 17:59 |
| merlin1991 | btw what's the big deal with doing a fork for thumb2? | 17:59 |
| DocScrutinizer | and honestly why would we want to link CSSU to a new kernel? | 17:59 |
| MohammadAG | too many forks | 17:59 |
| MohammadAG | cause this patch goes to waste without it | 17:59 |
| DocScrutinizer | nonsense | 18:00 |
| freemangordon | yeah, I don't want to be the only developer and maintainer of such a fork. Not that I like the idea of forking | 18:00 |
| MohammadAG | if kp gets the patch, the binaries won't be shipped in extras | 18:00 |
| DocScrutinizer | you can port this patch to PK any time you want | 18:00 |
| MohammadAG | and you can port this patch to your custom kernel too | 18:00 |
| DocScrutinizer | but WHY would we link it to CSSU? | 18:00 |
| merlin1991 | I mean hey, I'd probably swap over to the thumb2 fork and propose to handle the stable branch aswell, but I just see it conflicting with the mission statement of the original cssu | 18:01 |
| DocScrutinizer | yes | 18:01 |
| freemangordon | merlin1991, what is the idea all of us to fork to a new CSSU-thumb leaving non-CSSU thumb to stagnate? | 18:01 |
| merlin1991 | freemangordon: why would non-thumb stagnate | 18:02 |
| freemangordon | what will change by changing the name? | 18:02 |
| merlin1991 | it would be like debian x86 and x64 | 18:02 |
| merlin1991 | essentially just differntly compiled | 18:02 |
| merlin1991 | only that apt does not differ between "armel thumb" "armel non thumb" | 18:02 |
| DocScrutinizer | freemangordon: what's the alternative? | 18:02 |
| merlin1991 | so we have to apply that on a different level | 18:02 |
| merlin1991 | freemangordon: I'd just keep cssu non-thumb in sync with everything not thumb related | 18:03 |
| freemangordon | BTW soon or later we need a kernel in CSSU if we want a bugfixes on kernel level | 18:03 |
| DocScrutinizer | sure | 18:03 |
| freemangordon | and how is that different the? | 18:04 |
| freemangordon | *then | 18:04 |
| DocScrutinizer | and we had to consider *carefully* if we really want to do that | 18:04 |
| DocScrutinizer | for above elaborated reasoning | 18:04 |
| freemangordon | well, there are bug reports against omap1 kernel, should we mark them as WONFIX because someone could have flashed his own kernel? | 18:05 |
| freemangordon | sigh | 18:05 |
| merlin1991 | freemangordon: those are 2 disticnt discussions :D | 18:05 |
| DocScrutinizer | kernel bugs get fixed in kernel. AIUI PK is all about that | 18:05 |
| freemangordon | KP is not omap1 bugfixing cousing, if you don't beleive me, ask Pali | 18:06 |
| merlin1991 | freemangordon: I don't see why you're so against branching off a cssu with thumb that keeps in sync for main cssu and vice versa | 18:06 |
| freemangordon | merlin1991, I don't want forks, that is why. Otherwise I am ok, if you become a maintainer | 18:07 |
| DocScrutinizer | ouch | 18:07 |
| freemangordon | btw apt-get problem could be solved by using epoch? | 18:07 |
| merlin1991 | freemangordon: I meant that with apt a lil different | 18:07 |
| merlin1991 | for me using thumb or not is kinda like running x86 or x64 | 18:08 |
| merlin1991 | it's something the user decides | 18:08 |
| freemangordon | yet another reason - I am just not good enough with debian packaging to become a maintainer of such a fork | 18:08 |
| DocScrutinizer | then you evidently don't have the manpower to pull such project | 18:09 |
| merlin1991 | freemangordon: I'd happly do that for you | 18:09 |
| freemangordon | never pretended I have, that is why I am here | 18:09 |
| DocScrutinizer | as I explained above, you'll need to maintain means triage any bug against your thumb version | 18:09 |
| freemangordon | DocScrutinizer, I think I am good enough on bug-fixing and problem discovering, ain't? | 18:10 |
| DocScrutinizer | for $random-app of extras? | 18:10 |
| freemangordon | sure | 18:11 |
| merlin1991 | DocScrutinizer: your argument is moot anyway | 18:11 |
| merlin1991 | anyhting that breaks due to thumb is surely inside freemangordons scope of interest | 18:11 |
| merlin1991 | and everything else is inside the scope of "main" cssu | 18:11 |
| DocScrutinizer | yeah, but you need to triage | 18:11 |
| merlin1991 | since I guess freemangordon does not plan to move anyhting outside main cssu into his thumb project | 18:12 |
| freemangordon | good gues | 18:12 |
| DocScrutinizer | Qt? | 18:12 |
| freemangordon | *guess | 18:12 |
| merlin1991 | DocScrutinizer: again, if it's qts fault then --> main cssu, if it's thumbs fault --> freemangordon | 18:12 |
| freemangordon | Qt (as everything else) will be just thum-compiled | 18:12 |
| DocScrutinizer | function calls? | 18:12 |
| freemangordon | interworking? | 18:12 |
| DocScrutinizer | [2012-05-08 16:49:56] <DocScrutinizer> look, we need to take responsibility for each single binary we ship. So if you ship a new thumb-enabled Qt, you basically find yourself as co-maintainer of every single Qt-based app on the system, doing triaging on bugtracker, trying to rule out it's your thumb thing that caused that problem | 18:13 |
| freemangordon | [17:48] <freemangordon> DocScrutinizer, and what is different with the situation as it is now? | 18:14 |
| freemangordon | that is not productive | 18:14 |
| merlin1991 | I think we can stop here and say that freemangordon is more than willing to triage anything related to thumb | 18:14 |
| freemangordon | as is with anything non-related | 18:15 |
| merlin1991 | and that we also have a strong concensus against thumb into "main" cssu | 18:15 |
| DocScrutinizer | the triaging is way more complex, compared to a proper bugfix to Qt that maybe ideally even gone upstream and reviewed | 18:15 |
| merlin1991 | complexity is not an argument against it though | 18:15 |
| DocScrutinizer | not an argument against own fork, sure | 18:16 |
| freemangordon | merlin1991, if you and MohammadAG agree on "forking" then someone should do testing-thumb and testing-stable branches on gitorious | 18:16 |
| freemangordon | s/testing-stable/stable-thumg/ | 18:17 |
| DocScrutinizer | \o/ we once more found a common sense | 18:17 |
| DocScrutinizer | :-D | 18:17 |
| merlin1991 | freemangordon: even you could do that | 18:17 |
| merlin1991 | since branches are only realted to being able to push ;) | 18:18 |
| freemangordon | merlin1991, ok, will try :) | 18:18 |
| * DocScrutinizer tries to finally leave for RL now | 18:18 | |
| merlin1991 | freemangordon: as a starter I could set you up with another repo on my server | 18:19 |
| freemangordon | yeah. I know you like that :p | 18:19 |
| merlin1991 | lol | 18:19 |
| merlin1991 | to release this to the general public we'd need that "do I want to flash the kernel" thingy | 18:20 |
| merlin1991 | and a patched omap1 | 18:20 |
| merlin1991 | though ofc the do I really want to flash package in your case only checks against compatible kernels and flashes otherwise | 18:21 |
| freemangordon | merlin1991, I don't think so, after all you should manually add the repo, so you will have that info before installation | 18:21 |
| merlin1991 | freemangordon: you manually add cssu aswell and we still argue about how to ship kernels :D | 18:21 |
| freemangordon | and as the kenel there will be in fact KP there is no point to ask such questions | 18:22 |
| DocScrutinizer | yup | 18:22 |
| DocScrutinizer | just create a dependency in your repo core apps to KP | 18:22 |
| freemangordon | no, kernel-feature-thumb-errata ;) | 18:23 |
| DocScrutinizer | KP on isntallation is asking this chitchat anyway | 18:23 |
| freemangordon | yes | 18:23 |
| DocScrutinizer | freemangordon: ack | 18:23 |
| merlin1991 | basically any thumb app has to have that depends | 18:24 |
| DocScrutinizer | basically you'd need that dependeny in all your thumb-compiled pkgs | 18:24 |
| freemangordon | merlin1991, agree | 18:24 |
| DocScrutinizer | hehe, merlin1991 been faster than me | 18:25 |
| freemangordon | but of course, he is younger :P | 18:25 |
| DocScrutinizer | *sigh* | 18:25 |
| DocScrutinizer | indeed | 18:25 |
| * merlin1991 sometimes wonders how old doc really is | 18:25 | |
| freemangordon | 40? | 18:25 |
| merlin1991 | anyway, kernel-feature-thumb-errata sounds good | 18:26 |
| freemangordon | yeah. Now I just have to convince Pali to fork his own kernel :D | 18:26 |
| DocScrutinizer | err, is that really needed? | 18:27 |
| merlin1991 | freemangordon: why? | 18:27 |
| merlin1991 | doesn't the normal system still work with the errata enabled? | 18:27 |
| DocScrutinizer | AIUI the patch in kernel is compatible? | 18:27 |
| freemangordon | no, I was joking | 18:27 |
| merlin1991 | fu :D | 18:27 |
| freemangordon | yeah, normal system could be a little bit slower, but otherwise it is compatible | 18:28 |
| freemangordon | after all the patch clears BTB on every context switch | 18:28 |
| freemangordon | thumb does not come without cons | 18:29 |
| DocScrutinizer | eeew | 18:29 |
| DocScrutinizer | are there numbers on overhead in uSeconds for one context switch, and an idea how many context switxhes 'usually' happen during normal usage? | 18:31 |
| freemangordon | AFAIK CONFIG_HZ is 128 | 18:31 |
| freemangordon | so that is the absolute maximum | 18:31 |
| DocScrutinizer | sure? | 18:31 |
| DocScrutinizer | aren't here possible contect switches on calling kernel functions as well? | 18:32 |
| freemangordon | but I am not aware of any hard numbers. But the rumors stskeeps spreads that the system becomes very very slow are not true | 18:32 |
| * DocScrutinizer scratches head | 18:33 | |
| freemangordon | DocScrutinizer, I think that is what scheduler uses. Could be wring of course | 18:33 |
| freemangordon | *wrong | 18:33 |
| DocScrutinizer | that's the maximum stay-in-focus time for a particular context, until scheduler will preempt | 18:34 |
| DocScrutinizer | there *could* be way more context switches / second though, if task itself is causing the context switch, buzzword function-call | 18:35 |
| freemangordon | DocScrutinizer, I am not knowledgeable enough, sorry, could only share my end-user experience. and it is that multitasking is better, applications start faster, and the system slowdown is not irritating. | 18:36 |
| DocScrutinizer | fair enough | 18:36 |
| freemangordon | BTW my swap right now (after more than 24hours of usage) with 4 im account online and BT handsfree is 106 MB | 18:37 |
| freemangordon | would you share yours? | 18:38 |
| DocScrutinizer | there however could be particular usecases where this actually hurts a lot - e.g. media playback using the DSP. AIUI each call to DSP functions will cause a context switch. On video playback this might show, on 'normal' system usage you'll never encounter it. Just as an example of a possible scenario | 18:38 |
| freemangordon | DocScrutinizer, no way | 18:39 |
| freemangordon | trust me on that, I spend good enough time playing with DSP | 18:39 |
| DocScrutinizer | it was a (somewhat) made up example | 18:40 |
| freemangordon | I don't argue there is no slowdown, but (in theory) it should be overcompensted by better code density | 18:41 |
| freemangordon | and less memory usage | 18:41 |
| DocScrutinizer | just explaining why it's not exactly easy to estimate the impact | 18:41 |
| freemangordon | agree | 18:41 |
| freemangordon | anyway, the major slowdown factor now is swapping, agree? | 18:41 |
| DocScrutinizer | yes | 18:41 |
| DocScrutinizer | usually | 18:41 |
| freemangordon | so, you can imagine the impact of having 30-40 MB more free RAM | 18:42 |
| freemangordon | and even if you have to discard the executable page, by the time you will need it again, you will have to read 30-40 % less data from the disk | 18:43 |
| freemangordon | (nand, flash, whatever) | 18:43 |
| freemangordon | sounds good (at least in theory) :) | 18:44 |
| Pali | hi | 18:45 |
| freemangordon | hi | 18:45 |
| Pali | first, merlin1991 monday I can be online after 18:00 UTC | 18:46 |
| merlin1991 | damn | 18:47 |
| freemangordon | merlin1991, BTW isn't 16 UTC == 19 CET? | 18:47 |
| freemangordon | summer time? | 18:48 |
| freemangordon | nah, scratch that | 18:48 |
| freemangordon | it is 19 here | 18:48 |
| freemangordon | :) | 18:48 |
| merlin1991 | yep :D | 18:48 |
| Pali | freemangordon, kubuntu seems be stable, no craches but slow and some problems with touch input (but I did not used special installer, only prepaired image) | 18:48 |
| freemangordon | Pali, it is not slow, it crawls :D. I installed Ubuntu instead of it, it is much faster. No crashes here too. | 18:49 |
| merlin1991 | freemangordon: dunno kubuntu is fast for me | 18:49 |
| freemangordon | if you wish, I can give you xorg.conf, which fixes touch screen ad the keyboard maping | 18:50 |
| Pali | so this is problem with KDE, akonadi, nepomuk, etc kde ... | 18:50 |
| freemangordon | merlin1991, which version? | 18:50 |
| merlin1991 | latest | 18:50 |
| freemangordon | 12.04 on n900? | 18:50 |
| merlin1991 | though I have disabled akonadi | 18:50 |
| Pali | maybe I do not have 3d drivers | 18:50 |
| Pali | I used prepaired image (maybe for beagleboard) | 18:51 |
| freemangordon | merlin1991, we are talking about k/ubuntu 12.04 on n900 | 18:51 |
| merlin1991 | oops :$ | 18:51 |
| Pali | one question, will be obs also for personal repos? or only for central extras? | 18:51 |
| freemangordon | Pali, yes, it is for BB, but runs on n900. Though extremely slow. Ubuntu 12.04 is much much better, though I hate unity desktop | 18:52 |
| freemangordon | and the fact it seems there is no lxde :( | 18:52 |
| merlin1991 | Pali: as far as I understood it the maemo obs should have personal repos aswell | 18:52 |
| Pali | ok | 18:53 |
| freemangordon | Pali, did you read through backscroll? | 18:53 |
| Pali | yes, but there are a lot of lines | 18:53 |
| Pali | but, stable thumb in cssu seems good | 18:53 |
| freemangordon | well, it should be enough if you got the general idea | 18:54 |
| freemangordon | and it is that merlin1991 and DocScrutinizer don't want thumb in CSSU :D | 18:54 |
| freemangordon | instead we will do internal "fork" | 18:54 |
| freemangordon | a repo wich will mirror CSSU state with thumb-compilde binaries | 18:55 |
| freemangordon | and will have KP (under a different name) too | 18:55 |
| merlin1991 | freemangordon: why do you want to put kp in there actually? | 18:56 |
| merlin1991 | why not simply have kp with the errata enabled in extras? | 18:56 |
| * DocScrutinizer hands merlin1991 a cookie | 18:56 | |
| freemangordon | because it does not make sense CSSU (even thumb-forked one) to depend on application in extras. not to mention the problems we have with repos on maemo.org | 18:57 |
| MohammadAG | cross repo depends... | 18:58 |
| freemangordon | i.e. right now Pali cannot promote KP in extras, because DB is crewed as usual | 18:58 |
| freemangordon | *screwed | 18:58 |
| DocScrutinizer | I thought the dependency was kernel-feature-thumb-errata, and no matter where from to pull the pkg providing this property | 19:00 |
| freemangordon | exactly | 19:00 |
| freemangordon | but we should provide the "default" kernel | 19:00 |
| merlin1991 | then I'd put patched omap into the "cssu" repo and have a patched kp in extras | 19:01 |
| DocScrutinizer | I'm all happy with 'default' KP not including this patch, as you yourself elaborated it can slow down 'normal' systems | 19:01 |
| freemangordon | because otherwise we force users to enable -testing or -devel repos enable. merlin1991, why we need omap1 kernel? | 19:01 |
| merlin1991 | because we also like those users who still use omap1 and don't want kp, I dunno | 19:03 |
| DocScrutinizer | freemangordon: I know it's difficult to *set* this "flush cache please" bit, but could it get *cleared*? | 19:04 |
| freemangordon | kp is better, it has bugfixes against CSSU, stuff like that | 19:04 |
| freemangordon | DocScrutinizer, it is equally hard | 19:04 |
| DocScrutinizer | :-/ | 19:04 |
| freemangordon | i.e. you should issue a call to Secure Monitor with the new contents of Aux Control reg. But if I understand your question, it is NP to be doone through sysfs entry | 19:05 |
| DocScrutinizer | could we switch the bit during uptime, at all? I.E. could KP learn to enable/disable thumb-support (and thus remove negative impact of thumb patch for 'normal' systems)? | 19:06 |
| DocScrutinizer | yeah | 19:06 |
| DocScrutinizer | :-D | 19:06 |
| freemangordon | Did I get it correctly, you want that bit enabled by default, and userspace tool to clear it | 19:07 |
| freemangordon | yeah :D | 19:07 |
| *** dafox has quit IRC | 19:07 | |
| freemangordon | that could be done | 19:07 |
| DocScrutinizer | great | 19:07 |
| DocScrutinizer | I'd say this should go into 'standard' | 19:07 |
| DocScrutinizer | KP | 19:07 |
| freemangordon | you'd better tell that to Pali :D | 19:08 |
| DocScrutinizer | I'm just stating my notion, not telling anybody | 19:08 |
| DocScrutinizer | freemangordon: btw this would be a great way to actually do the proof-of-effectiveness of that patch | 19:09 |
| freemangordon | DocScrutinizer, the best way is k/ubuntu, it is thumb compiled all the way | 19:10 |
| freemangordon | and it crashes every now and then without that fix | 19:10 |
| freemangordon | SIGILL every 20-30 seconds | 19:11 |
| DocScrutinizer | you should be able to stop modest from segfaulting (in thumb version), and also see some slight (or huge) slowness when running a benchmark on a ARM binary | 19:11 |
| freemangordon | DocScrutinizer, the whole OS is a better testthan just modest | 19:12 |
| DocScrutinizer | maybe, but I prefer clear small well defined testbeds | 19:12 |
| DocScrutinizer | :-) | 19:12 |
| *** RST38h_ has quit IRC | 19:13 | |
| DocScrutinizer | and after all it's not hard to install one thumb binary (modest or whatever) on top of KP and then run that test for an hour with thumb-patch enabled, then disable the patch and watch it segfault | 19:14 |
| DocScrutinizer | similarly to check impact on performance for normal apps | 19:15 |
| freemangordon | DocScrutinizer, it is no different, the bug is triggered by chance, AIUI only TI could actually do a real test case by playing with only God knows which debug registers in OMAP. But by having all user binaries thumb-compiled the chance is bigger. I told you, ubuntu 12.04 SIGILLs every 2030 seconds without the patch | 19:15 |
| *** NIN101 has joined #maemo-ssu | 19:15 | |
| freemangordon | 20-30 | 19:16 |
| freemangordon | And that could be confirmed by anyone who've tried it on n900 | 19:16 |
| DocScrutinizer | well, I'm not going to install a complete new system, to verify the patch. Too much overhead | 19:17 |
| freemangordon | I did it :) | 19:17 |
| freemangordon | So did Pali | 19:17 |
| DocScrutinizer | you should try to get the patch upstream, and for that you'll need a better (smaller more convenient to use) testbed to allow upstream maintainer to do that test him/herself | 19:18 |
| freemangordon | DocScrutinizer, no way this to go upstream AIUI. It relies in SM call, which is specific for every device AFAIK. Think of it as calling an undocummented BIOS function. | 19:20 |
| DocScrutinizer | anyway, the performance test is quite straightforward without any need for a single thumb binary | 19:20 |
| freemangordon | And TBH I won't go through all that fuss just to see my name in kernel.org contributors list(or whatever it will appear) :P | 19:21 |
| DocScrutinizer | so such sysfs (or proc?) node is for sure more useful than e.g. smartreflex | 19:21 |
| freemangordon | yeah | 19:21 |
| freemangordon | why is that? ever tried SR in KP50? | 19:22 |
| DocScrutinizer | no, just used a well known example | 19:22 |
| freemangordon | well, try it, you'll be surprised. Seriously | 19:23 |
| DocScrutinizer | I'd even dare to suggest the thumb patch should be off by default in KP, and you include a line to system-init to enable it, on cssu-thumb | 19:23 |
| freemangordon | DocScrutinizer, sounds sane | 19:24 |
| DocScrutinizer | your thumb pkgs could even depend on that mini pkg that inserts that line enabling thumb patch | 19:24 |
| DocScrutinizer | which in turn would depend on kernel-feature-thumb-errata | 19:25 |
| freemangordon | yeah | 19:25 |
| freemangordon | ok, time to say bb | 19:26 |
| DocScrutinizer | o/ | 19:26 |
| * freemangordon is afk | 19:26 | |
| *** Pali has quit IRC | 19:43 | |
| *** Pali has joined #maemo-ssu | 19:47 | |
| *** trbs has joined #maemo-ssu | 20:52 | |
| *** NIN101 has quit IRC | 20:56 | |
| *** NIN101 has joined #maemo-ssu | 21:50 | |
| *** _rd has joined #maemo-ssu | 21:56 | |
| *** _rd has quit IRC | 22:28 | |
| *** Pali has quit IRC | 22:40 | |
| *** Pali has joined #maemo-ssu | 22:41 | |
| *** Pali has quit IRC | 22:48 | |
| *** arcean has quit IRC | 23:10 | |
| *** arcean has joined #maemo-ssu | 23:14 | |
| *** _rd has joined #maemo-ssu | 23:32 | |
| *** ekze-nyan has joined #maemo-ssu | 23:54 | |
| *** ekze has quit IRC | 23:54 | |
| *** nox- has joined #maemo-ssu | 23:58 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!