*** NIN102 has quit IRC | 00:05 | |
*** Pali has joined #maemo-ssu | 00:10 | |
*** trbs has quit IRC | 00:23 | |
*** javispedro has joined #maemo-ssu | 00:40 | |
*** Pali has quit IRC | 00:42 | |
*** LaoLang_cool has joined #maemo-ssu | 01:24 | |
*** M4rtinK has joined #maemo-ssu | 01:41 | |
*** LaoLang_cool has quit IRC | 01:59 | |
*** LaoLang_cool has joined #maemo-ssu | 02:19 | |
*** BCMM has quit IRC | 02:28 | |
*** LaoLang_cool has quit IRC | 02:56 | |
*** arcean has quit IRC | 03:39 | |
*** M4rtinK has quit IRC | 03:51 | |
*** LaoLang_cool has joined #maemo-ssu | 03:58 | |
*** LaoLang_cool has quit IRC | 04:00 | |
*** LaoLang_cool has joined #maemo-ssu | 04:01 | |
*** macmaN has quit IRC | 04:03 | |
*** M4rtinK has joined #maemo-ssu | 04:10 | |
*** macmaN has joined #maemo-ssu | 04:11 | |
*** M4rtinK has quit IRC | 04:17 | |
*** javispedro has quit IRC | 04:28 | |
*** psycho_oreos has joined #maemo-ssu | 04:42 | |
*** psycho_oreos has quit IRC | 04:50 | |
*** amiconn has quit IRC | 05:10 | |
*** amiconn_ has joined #maemo-ssu | 05:10 | |
*** amiconn_ is now known as amiconn | 05:11 | |
*** xnt14 has quit IRC | 05:12 | |
*** MohammadAG has quit IRC | 05:13 | |
*** psycho_oreos has joined #maemo-ssu | 05:14 | |
*** psycho_oreos has quit IRC | 05:16 | |
*** psycho_oreos has joined #maemo-ssu | 05:17 | |
*** LaoLang_cool has quit IRC | 05:24 | |
*** wmarone__ is now known as wmarone | 05:47 | |
*** wmarone_ has joined #maemo-ssu | 06:26 | |
*** wmarone has quit IRC | 06:27 | |
*** LaoLang_cool has joined #maemo-ssu | 07:21 | |
*** LaoLang_cool_ has joined #maemo-ssu | 08:09 | |
*** LaoLang_cool has quit IRC | 08:09 | |
*** neal has quit IRC | 08:40 | |
DocScrutinizer | hah | 08:56 |
---|---|---|
DocScrutinizer | honestly, useless effort. There's nothing you could do different when knowing what kernel user flashed | 08:59 |
DocScrutinizer | not asking user if he wants kernel to be updated "from your current version XY?" BAD idea | 08:59 |
DocScrutinizer | no matter what kernel flavour is currently on device, you *always* have to ask user what she wants to do about it. That's another reason why including kernel into CSSU is not going to happen when the more reasonable guys have to also give a vote | 09:02 |
DocScrutinizer | as a mandatory question "dear user, do you want to install a)PK49 b)PK50 c)PK49 with uBoot d)PK50 with uBoot e)stock kernel latest f)your own flavour ? you currently seem to have installed: kernel-foobar-201147999_with_multiboothack".... errr. What's THAT worth? | 09:04 |
DocScrutinizer | when extras-infra is borked, goddamn pester xfade to finally do sth about it. The fact that it's broken since months in repo is NO SOUND RATIONALE to get it into CSSU as a mandatory "optional on interactive question" package - and even less you can forcefeed PK to all CSSU users without "optional on interactive question" | 09:08 |
DocScrutinizer | why the hack can't you see it as a great opportunity to fix PK to base on git rather than a convoluted patchset, fix some long pending issues, and roll it out under pkgname Kernel-Power-Improved | 09:10 |
DocScrutinizer | btw to determine content of mtd3, the only working method is to calculate a md5sum and compare that against what you expect to find. All other tags you look for may as well show up in a user custom kernel that is different to what you *think* it was judging by such tag | 09:27 |
DocScrutinizer | then you need to evaluate if whatever method you chose to find out about kernel also works when there are bad blocks in that section of NAND | 09:31 |
DocScrutinizer | which is an extremely tedious thing to do on RE basis, as we don't really know how NOLO handles bad blocks in mtd3 | 09:32 |
DocScrutinizer | anyway keep in mind that, other than mmc mtd has no transparent bad block management. It's done in upper layer whatever that is for particular partition, for rootfs it's done in filesystem | 09:34 |
DocScrutinizer | afaik there's no such filesystem on mtd3 | 09:35 |
DocScrutinizer | so there has to be some other means to cope with bad blocks in mtd3, probably buried deep in NOLO | 09:36 |
freemangordon | DocScrutinizer, seems you missed something, the idea behind what Pali is coding re mtd3 is to ASK user "You have kernel xyz installed, do you want to upgrade it to CSSU one?". | 09:36 |
DocScrutinizer | exactly that is nonsense | 09:37 |
DocScrutinizer | reread my posts, I commented on exactly that | 09:37 |
freemangordon | I reread them several times, maybe it is my English, but AIUI you want exactly the same thing | 09:39 |
freemangordon | User to be able to opt-out | 09:39 |
DocScrutinizer | of course you can host as many powerkernel pkgs as you like, in a way analog to what we got for orientation-lock applet in S now | 09:39 |
DocScrutinizer | I.E. as a loosely attached optional pkg that incidentally lives on CSSU | 09:40 |
freemangordon | aah, you don't like the name change or what? | 09:40 |
DocScrutinizer | I don't like the idea to taint CSSU with a nagging of user about installing any of a ever growing selection of pkgs (here for kernel) that are not even depending on CSSU, not to discuss how CSSU depends on those pkgs which it *obviously* doesn't | 09:41 |
DocScrutinizer | CSSU and kernel are obviously orthogonal | 09:42 |
freemangordon | DocScrutinizer, "community kernel" is aiming 2 things: 1 - the place where reported kernel bugs are fixed. 2 - imrovements(in kernel) which has happend since last Nokia omap kernel was released | 09:43 |
freemangordon | It just does not make sense CSSU to depend on an external package, i.e. kernel-power in extras-devel | 09:44 |
DocScrutinizer | exactly, and it doesn't and never will do | 09:45 |
freemangordon | well, I think that maybe you still misunderstand the idea | 09:46 |
DocScrutinizer | not at all | 09:46 |
DocScrutinizer | it seems you misunderstand the fact that PK has done for kernel since ages what CSSU is now doing for *rootfs*/system | 09:47 |
DocScrutinizer | PK *is* the CSSU for kernel, and it's orthogonal to rootfs | 09:47 |
DocScrutinizer | thus has to stay a indeoendent part not attached to / included in CSSU | 09:48 |
freemangordon | the "community kernel" will be a part of CSSU, on CSSU upgrade if the user has flashed other than Nokia omap kernel there will be a question "do you want your kernel zapped". Otherwise community kernel will live in CSSU repos. And we will take KP50 as base. | 09:48 |
DocScrutinizer | and there are a plethora of possible configs regarding kernel, which CSSU impossibly can handle. Plus most users of CSSU are not interested in PK and even despise it getting shipped with CSSU | 09:49 |
DocScrutinizer | uhuh, says who | 09:50 |
freemangordon | If by KP you mean OC, that is not mandatory for at all | 09:50 |
DocScrutinizer | BS I'm not an idiot | 09:50 |
freemangordon | Well, I am not too. Seems still I am short on coffee, lets continue the discussion on the matter when there are more CSSU devs here | 09:52 |
freemangordon | DocScrutinizer, if memory serves me well, it was you to say "don't fork KP, put it in CSSU". But still, lets discuss community-kernel next time there are more people active here that just me and you | 09:54 |
freemangordon | bb | 09:54 |
*** LaoLang_cool_ has quit IRC | 10:05 | |
*** andre__ has joined #maemo-ssu | 10:18 | |
*** andre__ has joined #maemo-ssu | 10:18 | |
DocScrutinizer | well, please don't start quoting me on fake staements now. I definitely can't recall ever having been in a mood so I might even consider saying such thing | 10:23 |
*** dafox has joined #maemo-ssu | 10:26 | |
DocScrutinizer | I might have suggested (and did again some lines above) to *host* PK on CSSU repo, just like we do with orientation-lock applet pkg now. This isn't exactly nice as this repo is meant for things that can work and thus get installed under CSSU *only*, but it doesn't hurt THAT much if we get one or two pkgs there as well that could also work under stock PR1.3.1 | 10:27 |
DocScrutinizer | though clearly our "manifest" says "CSSU is *not* about anything that can get deployed via normal repo" - PK obviously can and has been since ages | 10:28 |
*** Pali has joined #maemo-ssu | 10:34 | |
*** freemangordon_ has joined #maemo-ssu | 10:35 | |
DocScrutinizer | anyway even hosting PK on CSSU repo would basically mean users need to install CSSU to be able to get it (unless they do in a way not supposed to be "the starndard way", like adding CSSU manually to catalogs of their stocl PR1.3.1, or using wget or whatever) | 10:37 |
*** neal has joined #maemo-ssu | 10:49 | |
*** ivgalvez has joined #maemo-ssu | 10:53 | |
*** Pali has quit IRC | 10:55 | |
ivgalvez | Wow, latest discussions around introducing KP in CSSU are useless!! | 11:01 |
ivgalvez | It's up to the developers that are actually doing the job | 11:01 |
ivgalvez | DocScrutinizer: how can you argue with freemangordon in that way? | 11:02 |
ivgalvez | It seems very unpolite and nonsense | 11:02 |
*** dafox has quit IRC | 11:03 | |
ivgalvez | And there is a clear reason to have a community kernel, if it's finally possible to move to introduce errata for thumb2 in kernel, building the CSSU with thumb2 would requiere that kernel, wouldn't it? | 11:04 |
*** dafox has joined #maemo-ssu | 11:05 | |
ivgalvez | not to mention the possibility to move to newer gcc or glibc | 11:05 |
*** freemangordon_ has quit IRC | 11:28 | |
*** Sicelo has quit IRC | 11:29 | |
*** Sicelo has joined #maemo-ssu | 11:30 | |
*** M4rtinK has joined #maemo-ssu | 11:32 | |
andre__ | PK = packagekit? | 11:35 |
ivgalvez | He meant Kernel Power | 11:37 |
andre__ | ahaha. okay. | 11:37 |
andre__ | so much for abbreviations. | 11:38 |
*** neal has quit IRC | 11:58 | |
*** BCMM has joined #maemo-ssu | 12:00 | |
*** andre__ has quit IRC | 12:05 | |
*** freemangordon_ has joined #maemo-ssu | 12:28 | |
*** andre__ has joined #maemo-ssu | 12:30 | |
*** andre__ has joined #maemo-ssu | 12:30 | |
*** MohammadAG has joined #maemo-ssu | 12:32 | |
*** xnt14 has joined #maemo-ssu | 12:33 | |
*** DocScrutinizer has quit IRC | 12:34 | |
*** DocScrutinizer has joined #maemo-ssu | 12:35 | |
*** lizardo has joined #maemo-ssu | 12:40 | |
*** M4rtinK has quit IRC | 12:56 | |
*** ivgalvez has quit IRC | 13:17 | |
*** freemangordon_ has left #maemo-ssu | 13:20 | |
*** FireFly has quit IRC | 14:11 | |
*** FireFly has joined #maemo-ssu | 14:11 | |
*** neal has joined #maemo-ssu | 14:51 | |
*** LinuxCode has joined #maemo-ssu | 15:17 | |
Lava_Croft | meh | 15:26 |
Lava_Croft | https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-ash4/422005_379468958743709_100000418249745_1336895_1361373448_n.jpg | 15:26 |
Lava_Croft | shitty official nokia case dies so fast | 15:26 |
merlin1991 | Lava_Croft: WTF? | 15:26 |
merlin1991 | why is there this leather abdomination on top of the n900? :D | 15:27 |
Lava_Croft | to protect it | 15:27 |
Lava_Croft | also makes the device way less 'smooth' and 'slippery' | 15:27 |
Lava_Croft | so it dont drop from breastpockets, or from tables that easily | 15:27 |
merlin1991 | ruins all the fun :D | 15:28 |
Lava_Croft | too bad this 20e case is still rather cheap | 15:28 |
Lava_Croft | there's probably about 50+ times a day that the n900 gets removed and put back in clothing pockets, seems the case dont like it | 15:28 |
Lava_Croft | pretty bad construction with leather, carton and some rubbery black shit on the sides to close off the layers of carton and leather | 15:28 |
Lava_Croft | i need something like this, only made from a proper material | 15:29 |
freemangordon | merlin1991, you said MohammadAG is going to build new CSSU update, but it was on Wednesday. Any news? | 15:29 |
Lava_Croft | yes, i thought about just ductaping the entire device | 15:29 |
merlin1991 | yesterday around 21 Cet he was still on it | 15:30 |
merlin1991 | since then no reply | 15:30 |
freemangordon | still on it as in? because most of the packages are built and are on your server. What exactly MohammadAG is doing re new update? | 15:31 |
merlin1991 | there was a slight issue with the camera-ui l10n packages | 15:32 |
freemangordon | what issue? | 15:32 |
freemangordon | is it in logs? | 15:32 |
freemangordon | so I won;t waste your time | 15:32 |
freemangordon | *won't | 15:33 |
merlin1991 | nah it isn't but it's going to be resolved by mag anyway :D | 15:33 |
*** LinuxCode has quit IRC | 15:33 | |
freemangordon | what was the issue, as I have never had an issue building tohse, last build was on 12th of march | 15:33 |
merlin1991 | it's not a build issue but a maintaining issue | 15:34 |
freemangordon | aaah, ok | 15:34 |
merlin1991 | has todo with the way the mr0 depends on the other packages | 15:34 |
merlin1991 | and how we want to depend on that from our mp | 15:34 |
freemangordon | ok | 15:34 |
Raimu | "My n900 loves to wear leather." | 15:35 |
Raimu | "Nothing but" | 15:35 |
Lava_Croft | leather can be taken loosely here | 15:36 |
Lava_Croft | its leather, but its more carton | 15:36 |
Raimu | freemangordon: Is the KP50 that's trying to be repoed now the same build as the latest one in your dox.abv.bg, BTW? | 15:37 |
freemangordon | Raimu, yes, absolutely the same | 15:39 |
freemangordon | merlin1991, I think to put a link to the "devel repo URL" on TMO, I know I was agains it, but... What do you think? | 15:40 |
merlin1991 | I suggest you wait untill the T release | 15:41 |
freemangordon | well, ok :) | 15:41 |
freemangordon | Raimu, any problemswith KP50? | 15:41 |
merlin1991 | because then I'll update the repo to that and import the stuff that would go on top | 15:41 |
freemangordon | merlin1991, ok | 15:41 |
Raimu | freemangordon, ever run into trouble with fcam-drivers -using applications with modern KPs? I mean, sometimes they just crash out randomly and blurt out weird things into dmesg. | 15:41 |
merlin1991 | + it would be a real repo then :) | 15:42 |
merlin1991 | freemangordon: I've got a repo with incoming dir set up already | 15:43 |
Raimu | freemangordon: I can't think of anything problematic and KP50-related. Fcam-driver apps like hdrsomething and lowlight have always been kind of randomly unusable on my n900, so I doubt it relates to KP. Some dspbridge warnings show up on dmesg on the occasion. | 15:43 |
merlin1991 | just need to symlink the pool and dists dir in the webserver and it will be avaiable | 15:43 |
Raimu | But that could be due to many things like the Harmattan-nicked 720p hack. | 15:44 |
Raimu | AIUI | 15:45 |
freemangordon | Raimu, dspbridge "deprecated ioctl" messages are absolutely normal if that is what you mean | 15:45 |
freemangordon | merlin1991, great, will wait "cssu-devel" repo to be announced | 15:48 |
Raimu | freemangordon: I think that's what I remembered. | 15:48 |
freemangordon | Raimu, just ignore them, it is a real warning from dspbridge driver when some application issues "CLOSE" ioctl. it is deprecated, but all of the applications in Maemo are build using older DSP API. | 15:50 |
Raimu | Okay, hdrcamera blew up again and started spitting out sbl overflow errors... | 15:51 |
Lava_Croft | hdr thingy never has crashed here in nearly 2y of usage | 15:51 |
Lava_Croft | and been on CSSU since quite a while | 15:52 |
Lava_Croft | and kp | 15:52 |
Raimu | Ah, yeah. Figures. | 15:52 |
Lava_Croft | i use it quite a lot too:\ | 15:52 |
Raimu | I remember fcam-drivers apps being unstable from the start. | 15:52 |
Lava_Croft | lowlight does crash sometimes | 15:52 |
freemangordon | Now the only thing that "CLOSE" ioctl handler in dspbridge driver does is to issue the warning in wuestion end to return :) | 15:52 |
freemangordon | *question | 15:52 |
Raimu | These days, though, hdrcamera crashes make it so I can't use any fcamd apps before a reboot. It buggers them or something. | 15:53 |
Raimu | freemangordon: Ha, OK. | 15:53 |
Raimu | freemangordon, anyway, no problems attributable to KP50 on my n900. | 15:54 |
Lava_Croft | oh, i know this is probably wait off topic | 16:01 |
Lava_Croft | http://www.ted.com/talks/rob_reid_the_8_billion_ipod.html | 16:01 |
Lava_Croft | but enjoy Copyright Math | 16:01 |
*** Pali has joined #maemo-ssu | 16:01 | |
*** LinuxCode has joined #maemo-ssu | 16:17 | |
amiconn | Raimu: Are you overclocking and/or undervolting your N900? If so, that's most probably the root cause of those crashes | 16:27 |
amiconn | The fact that the cpu runs stable at a certain clock and voltage doesn't mean the dsp will. And if the dsp crashes, apps using the dsp, like cameras, video players etc will experience all sorts of weird crashes | 16:29 |
* amiconn learned that from his own N900 | 16:29 | |
freemangordon | ...and that is why KP50 has additional /sy/power entry to tweak DSP voltage when SR is enabled ;) | 16:33 |
freemangordon | “/sys/power” | 16:34 |
Raimu | amiconn: Yeah, I've looked into it but it seems they do the same crash dance on stock values. Video players work fine on the "dsp" profile. | 16:35 |
DocScrutinizer51 | and this is also why it's generally strongly recommended to not mess with voltages at all, as TI and Nokia incvested quite a chunk of work to find optimum settings that guarantee errorfree operation while conserving as much power as possible | 16:35 |
Raimu | Yup, aware of this. | 16:38 |
Lava_Croft | but the amount of time they spent on it is probably nothing compared to the time that users of the device spend on that subject | 16:39 |
DocScrutinizer51 | haha | 16:40 |
DocScrutinizer51 | you have no idea, honestly | 16:40 |
Raimu | Although the engineers' target was to get a compromise that will be guaranteed to work on every piece of hardware they put out. | 16:40 |
Raimu | Reading the forums users easily tend to veer for the "works for me" approach. | 16:41 |
Raimu | Which is, I guess, fine and OK if they're willing to take the blame when it goes awry. | 16:42 |
Raimu | I'm probably talking out of my ass again, so silence I shall resume. :P | 16:43 |
DocScrutinizer51 | well, as long as you don't think either of the two applies to you, you're better off not even bothering about 'optimizing' such stuff: 1) your usage pattern or requirements are so etremely different to average as evaluated by Nokia that you need to change system to accomodate. 2) you're willing to throw more manpower and lab equipment on a particular detail than those who do this for their makking-money, and we're talking bout nnn | 16:44 |
DocScrutinizer51 | millions here | 16:44 |
DocScrutinizer51 | neither Nokia nor TI optimize for a "works under all circumstances for 9999/10000 of devices. They *always* optimize for maximum customer satisfaction | 16:46 |
DocScrutinizer51 | basically not even that, they optimize for bargain, but that's mostly the same | 16:47 |
DocScrutinizer51 | IOW regarding voltage: TI&Nokia optimized for a sweetspot between power conservation and stability already. Unless you're willing like whatever accept 10 timesw more random crashes for 4% increased standby time, it'snot worth looking into it again | 16:52 |
freemangordon | DocScrutinizer51, if that was the case (i.e. Ti and Nokia spending all the night in the lab, trying to squeeze every bit of stability against power), could you tell me why the hell SR is not wotking out of the box on N900? | 16:54 |
DocScrutinizer51 | because there been a ticket against SR that suggested random crashes go thru the roof when activated | 16:55 |
freemangordon | And calibration values look like some marketing guy put them in efuse | 16:55 |
DocScrutinizer51 | investigation on that takes time | 16:55 |
DocScrutinizer51 | muuuch time | 16:55 |
freemangordon | ticket? on Nokia bugtracker? | 16:56 |
DocScrutinizer51 | eventually somebody finds the full story incl root cause, and when you're lucky they even find a SW 'fix' | 16:57 |
DocScrutinizer51 | ticken on internal tracker, yes. Ask andre__ - I bet hecan look up such ticket | 16:57 |
DocScrutinizer51 | I dunno if he may disclose details | 16:58 |
freemangordon | Well, Nokia can do absolutely nothing about the fact that the whole batch of omaps they’ve received from TI had fcked efuse SR calibration. | 16:58 |
DocScrutinizer51 | :nod: quite possible | 16:59 |
Raimu | DocScrutinizer51, thanks for the clarif. | 16:59 |
DocScrutinizer51 | YW | 16:59 |
DocScrutinizer51 | bbl, daywork | 17:00 |
Raimu | To be honest I'm often quite guilty on fiddling on things that needn't fiddling. | 17:02 |
*** infobot has joined #maemo-ssu | 17:02 | |
*** ChanServ sets mode: +v infobot | 17:02 | |
*** LinuxCode has quit IRC | 17:18 | |
*** Sicelo has quit IRC | 17:22 | |
*** Sicelo has joined #maemo-ssu | 17:23 | |
*** Sicelo has joined #maemo-ssu | 17:23 | |
*** Sicelo has quit IRC | 17:26 | |
amiconn | DocScrutinizer51: There's an important difference between manufacturer and user optimisation though. | 17:28 |
amiconn | The manufacturer needs to optimise in a way that it works for *all* devices. The user can optimise for a single device | 17:29 |
*** Sicelo has joined #maemo-ssu | 17:39 | |
*** Sicelo has quit IRC | 17:48 | |
Pali | ping merlin1991, freemangordon | 17:49 |
merlin1991 | ping Pali | 17:49 |
Pali | merlin1991, I updated my program kernel-version | 17:49 |
Pali | now it use malloc() + read() | 17:49 |
Pali | instead mmap | 17:50 |
Pali | mtd kernel partition is 2MB, so it can be aloocated and readed by one read() call | 17:50 |
merlin1991 | what does it report in case of installed uboot? | 17:52 |
Pali | Version string not found | 17:52 |
Pali | it ignore attached kernels to the end of some image | 17:52 |
Pali | correctly, program try to find that kernel gz archive in first 2^16 bytes | 17:53 |
Pali | and attached kernel to u-boot binary is at the end | 17:53 |
merlin1991 | sure that's ok, but can we detect IF uboot is installed? | 17:54 |
*** Sicelo has joined #maemo-ssu | 17:54 | |
Pali | This program detect if zImage kernel is installed | 17:54 |
Pali | so if not then some other bootloader is installed... | 17:55 |
Pali | do we need to specify name of other image (e.g. u-boot)? | 17:55 |
amiconn | To me that doesn't sound logical. If you only check the first 2^16 bytes, you only need to read those, not the whole 2^21 | 17:55 |
merlin1991 | My idea of the cssu kernel flasher is a check if it is the right stock kernel or older cssu version --> flash cssu kernel, if not ask | 17:55 |
merlin1991 | but if possible I'd like the ask part to be able to use an existing uboot in mtd3 and flash with that | 17:56 |
merlin1991 | something along the lines of: we detected you have uboot installed, do you want to flash the cssu kernel or flash the cssu kernel with your uboot image or not flash at all | 17:57 |
*** andre__ has quit IRC | 17:57 | |
Pali | merlin1991, flashing u-boot with kernel is not simple... | 17:57 |
merlin1991 | it's damn easy | 17:57 |
Pali | you need to build compined u-boot image | 17:57 |
Pali | and that is different as fiasco... | 17:57 |
Pali | and we have more u-boot version | 17:58 |
merlin1991 | you can go from fiasco to u-boot image | 17:58 |
merlin1991 | and you can read the existing uboot and attach a new kernel | 17:58 |
Pali | so we cannot prepaire 2 versions (one zImage and one uboot+zimage) | 17:58 |
Pali | and for flashing: you cannot flash zImage | 17:58 |
Pali | in mtd3 is some NOLO header (maybe with checksum) | 17:59 |
merlin1991 | ffs | 17:59 |
Pali | so you need to flash fiasco image | 17:59 |
merlin1991 | I thought we have more in mtd3 | 17:59 |
merlin1991 | damn | 17:59 |
merlin1991 | ah well then it's a do you want to or not? question :D | 17:59 |
*** Sicelo has quit IRC | 17:59 | |
Pali | and generating fiasco image is possible ony with SDK repo (with fiasco-gen package) | 17:59 |
*** Sicelo has joined #maemo-ssu | 18:00 | |
Pali | so dumping u-boot somehow from mtd3 attach to that new zImage, creating new fiasco image and flashing is hard and possible only in scratchbox with SDK repo | 18:01 |
Pali | only we can do is ask question: do you want to flash new kernel image? | 18:02 |
merlin1991 | yeah | 18:02 |
merlin1991 | well better than flashing without asking | 18:02 |
Pali | and for cssu kernel I suggest NOT to change version string | 18:02 |
Pali | we have more kernel packages in extras-devel repo (also joikuspot) which has modules agains default kernel | 18:03 |
Pali | and if we does not change kernel interface (only bugfix patches) there will be no compatibility problem | 18:03 |
Pali | merlin1991, I suggest to create $PACKAGE which dpkg-divert /sbin/fiasco-image-update | 18:05 |
Pali | and use some new wrapper for that fiasco-* binary which will ask if you want to flash kernel if new version is not same (or similar) as old | 18:05 |
Pali | this will also ask for any kernel updates (not only cssu), so users will see if some package will want to flash kernel | 18:06 |
merlin1991 | can we do it somehow to only have it with cssu updates? | 18:06 |
Pali | we can include that $PACKAGE as predepends for cssu kernel | 18:06 |
Pali | and package can go to cssu repo | 18:07 |
*** lardman has joined #maemo-ssu | 18:09 | |
*** ekze has quit IRC | 18:11 | |
*** ekze has joined #maemo-ssu | 18:11 | |
*** Sicelo has quit IRC | 18:11 | |
*** Sicelo has joined #maemo-ssu | 18:14 | |
freemangordon | merlin1991, the tool to create .po files from .mo file (l10n) is called msgunfmt, please remember that :D. | 18:33 |
merlin1991 | noting it down :) | 18:34 |
Pali | stored in IRC log :-) | 18:34 |
merlin1991 | is it a simple tool as in can anybody do it? | 18:34 |
freemangordon | going to RE osso-pdfviewerv l10n | 18:34 |
merlin1991 | because then I can just do it, and leave you the more interesting tasks ;) | 18:34 |
Pali | freemangordon, if you have time, can you also RE tvout l10n? | 18:34 |
freemangordon | you have it in every distribution, gettext tool | 18:34 |
Pali | we have some new untranslated strings in cssu tvout control panel | 18:35 |
freemangordon | at least it is I have it in scratchbox | 18:35 |
freemangordon | and in ubuntu too | 18:35 |
freemangordon | pretty damn standatr tool | 18:35 |
Pali | merlin1991, did you check if new version of kernel-version.c program get correct version of yours kernels? | 18:36 |
freemangordon | merlin1991, http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/msgunfmt-Invocation.html | 18:36 |
merlin1991 | freemangordon: that looks quite straightforward | 18:37 |
merlin1991 | Pali: no I didn't find the time yet | 18:37 |
merlin1991 | Pali: did you update the armel build? | 18:37 |
Pali | yes | 18:38 |
freemangordon | merlin1991, if you can do l10n instead of me, I will really appreciate that, I am running out of time now and tomorrow will travel to countryside. On the other hand I almost made a promise on TMO to do it for the next update | 18:38 |
merlin1991 | I can do it | 18:39 |
freemangordon | I know you can :p | 18:39 |
freemangordon | The question is will you :) | 18:39 |
merlin1991 | okay I WILL do it :D | 18:39 |
freemangordon | :D | 18:39 |
freemangordon | great | 18:39 |
merlin1991 | Pali I can check tomorrow morning, gotta leave now :/ | 18:42 |
Pali | ok | 18:42 |
Pali | let me know if it working fine with wifi kp version... | 18:43 |
freemangordon | Pali, why the hell kernel-power 50 .deb is missing in autobuilder? | 18:43 |
freemangordon | but all other packages are there | 18:43 |
Pali | fucking extras and autobuilder | 18:43 |
freemangordon | man, thats insane | 18:43 |
freemangordon | Pali, any sign of X-Fade? | 18:46 |
Pali | I tried ping him today again | 18:46 |
freemangordon | I’ll do that now | 18:46 |
*** M4rtinK has joined #maemo-ssu | 19:03 | |
*** NIN101 has joined #maemo-ssu | 19:05 | |
*** M4rtinK has quit IRC | 19:19 | |
merlin1991 | damn you should have said that 3 hours ago | 19:26 |
merlin1991 | I had him fix the -testing repo | 19:26 |
merlin1991 | (there was a bogus entry in Sources.gz) | 19:26 |
*** arcean has joined #maemo-ssu | 19:34 | |
*** M4rtinK has joined #maemo-ssu | 19:44 | |
*** dafox has quit IRC | 20:05 | |
*** BCMM has quit IRC | 20:10 | |
*** M4rtinK has quit IRC | 20:26 | |
*** M4rtinK has joined #maemo-ssu | 20:30 | |
*** arcean_ has joined #maemo-ssu | 20:39 | |
*** M4rtinK has quit IRC | 20:42 | |
*** arcean has quit IRC | 20:42 | |
*** arcean_ is now known as arcean | 20:43 | |
*** Sicelo- has joined #maemo-ssu | 21:23 | |
DocScrutinizer | ok, seems you all decided to go the mad hackers way and by all means force kernel into CSSU | 21:28 |
Sicelo- | latest cssu comes with kernel? | 21:29 |
DocScrutinizer | I'm afraid it will | 21:29 |
DocScrutinizer | no really, I'm fine with that, if anybody could explain to me how that fits into CSSU manifest concept | 21:30 |
*** LinuxCode has joined #maemo-ssu | 21:30 | |
DocScrutinizer | CSSU has no dependencies on kernel. KErnel has no dependencies on any CSSU patch. And PK got published via extras repo since ages. 3 times no check, no argument why we want that stuff in CSSU | 21:31 |
DocScrutinizer | but obviously it's again en vogue to forcefeed another unrelated stuff to users of CSSU | 21:32 |
NIN101 | forcing kernels? sucks. | 21:34 |
DocScrutinizer | yeah, and when we get some security patch to kernel, will we force a NIL update of CSSU to those that opted out of CSSU-kernel? | 21:40 |
DocScrutinizer | or will that kernel patch only ship with next stable? | 21:40 |
DocScrutinizer | and what we gonna do about the 57 flavours of uBoot-kernels? | 21:41 |
Pali | DocScrutinizer, see log | 21:42 |
DocScrutinizer | I had a cursory look at log and threw up | 21:42 |
Pali | I'm writing program which ask user which has non nokia kernel flashed if he want to flash new version | 21:42 |
Pali | now it write current version flashed in mtd3 | 21:43 |
DocScrutinizer | uhuh, and those who got Nokia kernel? those have no choice or what? | 21:43 |
Pali | we should not change kernel string | 21:43 |
DocScrutinizer | you should not touch kernel at all | 21:44 |
Pali | and we include bugfixes, so reason why to flash it | 21:44 |
DocScrutinizer | I come over anybody touching my kernel without me asking for it, with fire | 21:44 |
NIN101 | yep. | 21:45 |
DocScrutinizer | NO MATTER which kernel I decided to use that very minute | 21:45 |
DocScrutinizer | my daily phone actually *is* running stock kernel, and I damn well know why | 21:47 |
DocScrutinizer | you can't even know if the system which is running CSSU been actually booted from kernel in mtd3 | 21:49 |
DocScrutinizer | could have been booted from a kernel via vlasher&ramload, could be booted from mmc via kexec, with kernel God-knows-where | 21:50 |
DocScrutinizer | s/vlasher/flasher/ | 21:50 |
infobot | DocScrutinizer meant: could have been booted from a kernel via flasher&ramload, could be booted from mmc via kexec, with kernel God-knows-where | 21:50 |
DocScrutinizer | maybe some cool haxor patches his NOLO to make it boot from mtd4 | 21:51 |
Pali | but old version of nokia kernel in mtd3 can be updated to one which will have fixed security bugs | 21:52 |
DocScrutinizer | honestly keep your fingers from mandatory kernel updates unless you want a shitsorm hitting your inbox | 21:52 |
DocScrutinizer | who verified that "bugfixed" version, who audited it, who signed it off? | 21:53 |
DocScrutinizer | who tested it still works with e.g. uBoot, if only for mere limitaions of available free space in mtd3? | 21:54 |
DocScrutinizer | sorry, but in my book kernel is clearly where CSSU leaves own terrain and goes hamuk abroad - IOW there's a clear red line which CSSU mustn't cross | 21:57 |
DocScrutinizer | I'm all happy with a CSSU-kernel as a associated but independent project | 21:58 |
DocScrutinizer | but CSSU as we know it is about userland, not kernel domain | 22:00 |
DocScrutinizer | even flasher has an option to not flash kernel, or only flash kernel | 22:01 |
DocScrutinizer | kernel is not userland, and userland is not kernel. full stop. | 22:02 |
DocScrutinizer | users don't appreciate kernel updates, unless they do it all under their own control, at the time they like, to the kernel they carefully picked or even built themselves | 22:04 |
DocScrutinizer | and let's look at it from the diametrically other side: are you maintaining two locations for powerkernel then, or will CSSU refer tpo stuff outside CSSU repo, or will all the OC fanbois be forced to switch to CSSU then? If the latter, have fun with bugtrac! :-/ | 22:06 |
LinuxCode | I agree with the kernel update statement | 22:07 |
LinuxCode | statement | 22:07 |
* LinuxCode wouldnt mind a userland tool, that informs me of an update though | 22:08 | |
DocScrutinizer | sure, nothing against such a tool | 22:08 |
LinuxCode | maybe informing of the security issues/other bug fixes | 22:08 |
DocScrutinizer | :nod: | 22:09 |
DocScrutinizer | if it wasn't such unbearable crap regarding usability, that tool already had a name though: HAM | 22:10 |
Raimu | DocScrutinizer: Your argument on keeping KP outta mainline CSSU is very, very convincing. | 22:11 |
DocScrutinizer | and if Pali could get a hold of x-fade, to fix the lockup in extras repo, then nobody was *that* eager to get powerkernel into CSSU | 22:12 |
*** NIN101 has quit IRC | 22:28 | |
DocScrutinizer | ( [2012-03-16 16:29:21] <amiconn> The manufacturer needs to optimise in a way that it works for *all* devices. The user can optimise for a single device ) sure, but the problem with user "optimizing" is your device won't differ that much from average due to immutable properties (there are no golden devices that are 3 times as fast as the worst case) - what manuf optimizes for is operation in a wide range of "environmental" conditions, | 22:35 |
DocScrutinizer | like extreme heat, cold, low battery, fresh battery, different GSM network peculiarities in different countries etc pp. The problem with user trying to compete against that is mainly that the user regularly only has limited knowledge about the fringe cases where the optimization actually needs to grip | 22:35 |
DocScrutinizer | very usually that user "optimization" is done on a WFM basis, without *any* proper evaluation of even yield on the primary optimization goal (is it *really* faster / more power economic / whatever?) In 99.9% of cases this "optimization" is based on perceived 1337ness of doing such things on your own, plus a placebo effect that frequently comes in when testing stuff like standby times or performance without proper tools | 22:38 |
*** NIN101 has joined #maemo-ssu | 22:42 | |
DocScrutinizer | a simple analogy: you might want to 'optimize' an electric motor. You reduce voltage so it consumes less power. All fine, it gets less warm, less wear, consumes less power. But what if the motor is regulated to keep a certain rotations per minute? you still can reduce voltage, but that will cause rotation speed to go down, and the regulation kicks in making the motor draw more electric current to compensate. Result: the consumed energy | 22:47 |
DocScrutinizer | is probably higher due to motor not operation at optimum conditions, plus the higher current drawn will cause increased wear on the collector & brushes | 22:47 |
*** trbs has joined #maemo-ssu | 22:48 | |
DocScrutinizer | IOW: it's hard to do a proper optimization when you have no complete knowledge of how the system works. On a system complex as a SoC only the chip manufacturer has sufficient knowledge | 22:49 |
*** lizardo has quit IRC | 23:01 | |
*** Sicelo has quit IRC | 23:09 | |
*** Sicelo has joined #maemo-ssu | 23:10 | |
*** Sicelo has joined #maemo-ssu | 23:10 | |
*** dafox has joined #maemo-ssu | 23:10 | |
*** bsdmaniak has joined #maemo-ssu | 23:13 | |
*** Sicelo has quit IRC | 23:16 | |
*** Sicelo- is now known as Sicelo | 23:17 | |
*** dafox has quit IRC | 23:31 | |
*** bsdmaniak has quit IRC | 23:36 | |
*** nox- has joined #maemo-ssu | 23:47 | |
*** nox- has joined #maemo-ssu | 23:47 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!