| 19:45.31 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 19:45.31 | *** 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 |
| 19:45.31 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 19:54.51 | *** join/#maemo-ssu _rd (~rd@p57B498F6.dip0.t-ipconnect.de) |
| 20:09.50 | DocScrutinizer05 | (([2012-08-06 20:48:50] <freemangordon> .ko sitting in /lib/modules does not limit your freedom)) bq27200.ko was a first example why we don't want an arbitrary collection of untested *.ko sitting in /lib/modules of CSSU kernel. Of course you can crowd the /lib/modules with all you like as long as you blacklist it, and as long as core kernel code isn't affected, the possible risk is limited to filling filesystem with all that stuff. |
| 20:09.52 | DocScrutinizer05 | But why would we want to do that? |
| 20:13.11 | *** join/#maemo-ssu _rd (~rd@p57B498F6.dip0.t-ipconnect.de) |
| 20:24.15 | DocScrutinizer05 | merlin1991: could we try to approach the cssu kernel definition from a conservative direction, enumerating the patches we need or like to go in, rtaher than those in KP we need to exclude? I start with pselect() and probably that age old mcc driver patch intel eventually published |
| 20:25.34 | merlin1991 | DocScrutinizer05: the problem is we need a kernel dev who is willing todo that, I can't and pali/freemangordon are not interested when it isn't at least a bit geared towards kp, so unless you feel like hacking and supporting a kernel or have some hidden ressources we'll have to compromise here |
| 20:27.15 | DocScrutinizer05 | well, I was just about to continue with what we might include, but when that's the deal then yes I will build and maintain a kernel for CSSU that has *only* pselect() patch |
| 20:27.49 | merlin1991 | and any other security / bugfix patch that comes along in the future? |
| 20:28.15 | DocScrutinizer05 | since I don't see pali/fmg review all those 887 basically untested patches that KP comes with |
| 20:28.35 | DocScrutinizer05 | see bq27200.ko desaster |
| 20:28.58 | DocScrutinizer05 | and we're about to do all the same again, just this time for CSSU |
| 20:30.13 | DocScrutinizer05 | based on some personal preferences of two devels who think a separate optional KP isn't a bearable alternative to forcefeeding stuff to CSSU users |
| 20:31.38 | merlin1991 | the rant doesn't answer my question though ;) |
| 20:31.51 | DocScrutinizer05 | maintenance effort of minimalistic kernel as perferred by you and me is obviously less than effort for a 50% stripped-down KP as suggested by Woody14619 and/or fmg |
| 20:32.20 | DocScrutinizer05 | I'm not giving answers I can't keep later on |
| 20:33.13 | kerio | DocScrutinizer05: ooh, what's the bq27200.ko disaster? |
| 20:33.21 | merlin1991 | well unless you say you're going to maintain this kernel with pselect and future patches I'm not going for this, pselect fix only is as bad as pushing too much kp into cssu |
| 20:33.44 | DocScrutinizer05 | and since KP is a mess regarding quilt on top of git on top of dunno what - at least it was last time PaulFertser and me checked - I can't promise anything right now |
| 20:35.20 | merlin1991 | well quilt on top of git is not that bad, it seperates you changes nicely in the tarball (since that one shouldn't contain .git ever) |
| 20:35.59 | DocScrutinizer05 | and since pali and fmg have no sound reasons why they'd be willing to maintain a 50% KP for cssu but refuse to maintain a less-effort minimalistic cssu kernel, I'm rather reluctant to discuss stuff based on this |
| 20:36.34 | merlin1991 | I don't know where you're going atm, but I asked you about stock + patches |
| 20:37.23 | DocScrutinizer05 | I answered your question: I can't state anything as I don't even know the challenge yet |
| 20:37.53 | merlin1991 | and then I tried to nudge you to say yes anyway ;) |
| 20:38.53 | DocScrutinizer05 | last time I built a kernel been 2 years ago, and we based that either on stock or on complete KP of that time, and Paul bitched to Titan about WTF this whole KP is such an unmaintainable mess rather than a manageable normal git setup |
| 20:40.18 | jon_y | is switching from cssu-testing to -thumb pain free? |
| 20:40.36 | DocScrutinizer05 | Paul even semi-sanitized stuff back when, and I have NFC if titan adoped it or continue3d to mess up stuff like applying patches on top of patches on top of patches without any versioning or other sane maintenance tools |
| 20:41.12 | merlin1991 | jon_y: it's rather straight forward, swap the url in the ham repo list and update |
| 20:41.34 | jon_y | ok, I suppose it's more painful to do it the other way around |
| 20:41.47 | DocScrutinizer05 | hah, you bet |
| 20:41.50 | merlin1991 | though I don't know if the -thumb repo is still in maintanance meaning if freemangordon fixed the problem that was there |
| 20:42.17 | merlin1991 | (he posted on tmo some time ago not to update because the repo is bad) |
| 20:42.27 | merlin1991 | and I didn't follow what happened afterwards :D |
| 20:42.27 | jon_y | bad? |
| 20:42.44 | kerio | wait, what |
| 20:42.45 | kerio | no |
| 20:42.48 | kerio | that's wrong |
| 20:43.01 | kerio | -thumb is in addition to -testing |
| 20:43.30 | kerio | http://maemo.merlin1991.at/cssu/community-thumb/community-thumb-fremantle.install |
| 20:43.36 | merlin1991 | kerio: well with the current state of -testing he can just enable the thumb repo instead for the first update, true though that he'd miss future stuff in -testing |
| 20:43.42 | jon_y | how do you make -thumb prefered over -testing? |
| 20:43.52 | kerio | or, if you want to be l33t and stuff, add http://maemo.merlin1991.at/cssu/community-thumb/ as a repo and upgrade |
| 20:43.59 | merlin1991 | jon_y: the versions in -thumb are crafted specially in order to be prefereed over testing |
| 20:44.04 | kerio | jon_y: -cssu0 is less than -cssu0-thumb |
| 20:44.05 | DocScrutinizer05 | jon_y: version afaik |
| 20:44.13 | jon_y | aha |
| 20:44.35 | merlin1991 | but yeah, follow the first link kerio gave tof install it, that's the safest way |
| 20:44.45 | merlin1991 | (by follow I mean open on the n900) |
| 20:44.50 | jon_y | ok, thanks |
| 20:44.53 | kerio | jon_y: i'd install kp51r1 first, though |
| 20:44.57 | kerio | otherwise you end up with kernel-cssu |
| 20:45.03 | kerio | which is the same, but with a different name |
| 20:45.04 | jon_y | is it possible to patch up the stock 1.3 for thumb, just as a backup to kp51? |
| 20:45.12 | jon_y | I already have kp51 |
| 20:45.15 | jon_y | r1 |
| 20:45.15 | kerio | jon_y: "meh" |
| 20:45.15 | DocScrutinizer05 | kerio: you dunno the bq27200.ko desaster? gawd, just read comments on it, and why it's blacklisted in current KP |
| 20:45.30 | kerio | oh, the current module? |
| 20:45.37 | kerio | idk, i don't really follow TMO |
| 20:45.42 | merlin1991 | jon_y: what do you mean by "as a backup to kp51" |
| 20:45.48 | jon_y | DocScrutinizer05: it reboot the system if unloaded? |
| 20:46.01 | kerio | jon_y: no, that's fixed in r1 |
| 20:46.19 | jon_y | merlin1991: with uboot and all, its nice to fall back to a working kernel if say kp upgrade got botched |
| 20:46.30 | kerio | jon_y: no, there's no thumb-enabled kernel compatible with the stock modules |
| 20:46.39 | jon_y | ok |
| 20:46.44 | kerio | so you'd still have to install the correct modules |
| 20:46.53 | kerio | at that point you might as well manually install KP/KCSSU |
| 20:46.54 | DocScrutinizer05 | kerio: the short sory: somebody built that .ko in a semi-sane way, but it conflicted with bme since both use i2c and expect to have exclusive access. So some "brilliant" hacker removed locking from whole kernel, according to "wtf do we need that anyway?" |
| 20:46.56 | merlin1991 | is kp51 tumb enabled? |
| 20:47.04 | kerio | DocScrutinizer05: ...wat |
| 20:47.13 | kerio | like... every lock? |
| 20:47.15 | kerio | merlin1991: it is |
| 20:47.23 | DocScrutinizer05 | every lock on I2C bus, yes |
| 20:47.26 | kerio | oh |
| 20:47.34 | jon_y | uh what |
| 20:47.34 | kerio | meh, wtf do we need that anyway? :P |
| 20:47.44 | kerio | merlin1991: in fact, it could be considered a bug |
| 20:47.58 | merlin1991 | jon_y: if kerio is right, then yes you can use the -thumb kernel as a backup to kp51 (if you have all modules installed) |
| 20:48.07 | kerio | because the errata workaround is enabled by default |
| 20:48.11 | kerio | even when it's not needed |
| 20:48.18 | kerio | merlin1991: the -thumb kernel is the exact same thing as KP51 |
| 20:48.23 | kerio | except with a different name |
| 20:48.25 | kerio | and no uninstaller |
| 20:48.29 | merlin1991 | not 100% afaik |
| 20:48.30 | jon_y | merlin1991: awesome, just some fidling with the uboot scripts |
| 20:48.34 | jon_y | btw, why does kp51 install the wifi injection drivers into /opt instead of /lib/modules? |
| 20:48.44 | kerio | jon_y: what do you need uboot for? |
| 20:49.06 | jon_y | nitdroid? |
| 20:49.10 | kerio | PFFFFFFFFF |
| 20:49.14 | jon_y | for kicks? :) |
| 20:50.03 | kerio | is the graphics card accelerated, actually? |
| 20:50.08 | kerio | android games could be neat |
| 20:50.28 | merlin1991 | kerio: I think in the case of the n900 graphics "card" is kind athe wrong term |
| 20:50.39 | kerio | well, whatever does polygons in the n900 |
| 20:50.42 | merlin1991 | also you never ever accelerate your grahpics "card" |
| 20:50.47 | jon_y | no idea, I may need to get into android development, so poking about without buying new hardware might be cool |
| 20:51.00 | merlin1991 | ususally you accelerate the rendering of grahpics using the gpu instead of the cpu |
| 20:51.02 | jon_y | graphic card accelerate your 3D games |
| 20:51.17 | merlin1991 | but you don't accelerate the "card" :D |
| 20:51.30 | kerio | well you definetely accelerate it from a stop |
| 20:51.37 | jon_y | overclocking might count, but its a different story :) |
| 20:51.38 | kerio | not using it -> using it |
| 20:51.43 | kerio | >:) |
| 20:51.51 | DocScrutinizer05 | merlin1991: yep, afaik KP51 is thumb-enabled |
| 20:51.52 | merlin1991 | well I do can throw my n900 into the air to accelerate the gpu inside the arm ;) |
| 20:52.45 | Woody14619 | DocScrutinizer05: On your earlier comment, yes, a minimalistic kernel could be less effort than a 50% stripped-down KP. But when you compair anything with >0 effort and nobody wanting to do it, vs more effort with someone volunteering to take it on, the one with a worker generally will win. |
| 20:53.31 | DocScrutinizer05 | unless the work done is not what you really want to get in the end |
| 20:55.07 | DocScrutinizer05 | you remove a small plate on your house front. You look for somebody to paint that 10*10cm patch. Somebody is willing to do it but only when he also may paint your whole house front, incl windows glass and roof. What will you choose? |
| 20:55.13 | merlin1991 | DocScrutinizer05: well freemangordon volunteered todo a proper review of all kp patches to get rid of the bad ones |
| 20:55.29 | Woody14619 | Define "you". You as in DocScrutinizer? Maybe. You as in the whole community? Most with CSSU already have KP installed. |
| 20:55.47 | merlin1991 | Woody14619: that argument is invalid from a cssu perspective |
| 20:56.06 | DocScrutinizer05 | merlin1991: proper review done by a single devel is a paradoxon |
| 20:56.27 | Woody14619 | I agree merlin, in the long term, as CSSU will see expanded usage. |
| 20:56.49 | Woody14619 | Which is why I'm not for just packaging KP into CSSU as a requirement. |
| 20:58.42 | Woody14619 | A proper review by anyone is a good step when the alternative is no review. |
| 20:58.48 | DocScrutinizer05 | merlin1991: that's the whole point this annoying debate spins around |
| 20:59.13 | DocScrutinizer05 | definition of "proper review" |
| 20:59.57 | Woody14619 | But let's use your analogy... You've removed the plate, and now have a house with a hole in it. The only carpenter you have wants to patch it and paint the whole front of the house. |
| 21:00.31 | Woody14619 | Your options are: Live with a house with a hole in it, or hire the carpenter and the "undo" the paint on the windows by removing it. |
| 21:00.35 | DocScrutinizer05 | according to fmg's definition of "proper review" nothing in KP needs further review since every single patch already been 'reviewed' by the one who merged it to KP |
| 21:01.04 | Woody14619 | Both are undesirable, I understand that... But if the hole is more significant than removing the paint on the window... |
| 21:01.07 | merlin1991 | DocScrutinizer05: that's not true, freemangordon even named a few things he would remove |
| 21:01.18 | DocScrutinizer05 | oooh, a few? |
| 21:01.25 | DocScrutinizer05 | sounds sane |
| 21:02.13 | merlin1991 | DocScrutinizer05: well a few he would remove because he already knows their not "stable", but back than it wasn't a definite "x and y have to go" but a "x has to go but there might be others" |
| 21:02.14 | Woody14619 | Especially when half the houses on the block already have painted windows from the same carpenter... |
| 21:02.20 | DocScrutinizer05 | sounds like "lemme rethink! I added A B C D E F G. Maybe for F I was a tad keen. So let's keep that out" |
| 21:03.08 | merlin1991 | DocScrutinizer05: you're argumenting on a silly level |
| 21:03.51 | DocScrutinizer05 | we shouldn't find what has to go due to us knowing it's bad, we should find what's already *proven* by proper *public* review and can safely get included |
| 21:04.37 | Woody14619 | If another (or you) is willing to fix/maintain it in another way, that's great. The option would be well enjoyed. But lots of people say things and then don't follow through. |
| 21:05.33 | DocScrutinizer05 | Woody14619: KP is not fixed in any way, it's a huge pile of untested patches that just got as much testing as "WFM" |
| 21:05.38 | Woody14619 | A good first step: Do it. Make a patched kernel. Give us that option. That in itself is time better spent then arguing with those willing to put in the effort to do other thing. |
| 21:05.40 | merlin1991 | DocScrutinizer05: whilst your statement is correct atm we only have volunteers for way #1, and untill that changes it's the lesser evil compared to bugs like pselect |
| 21:05.58 | DocScrutinizer05 | no way |
| 21:06.18 | DocScrutinizer05 | I buy pselect() bug over unknown 50 bugs in KP every day |
| 21:07.00 | Woody14619 | doc: Lots of things in KP are tested in the fact that people have been running it for over a year. By your logic the open wifi drivers would be totally untested, because it didn't get a formal review. Reality is, lots of people use it every day, and have for close to a year. |
| 21:07.09 | DocScrutinizer05 | IOW rather stay with stock kernel than introduce huge unknown number of new bugs just because somebody refuses to do less |
| 21:07.28 | Woody14619 | And you have that option.... |
| 21:07.50 | merlin1991 | DocScrutinizer05: if you apply that to cssu as a whole then you should have never installed |
| 21:08.01 | DocScrutinizer05 | Woody14619: and yet those drivers are considered unstable and not ready for prime time even by original author |
| 21:08.10 | merlin1991 | ie ke-recv changes, hildon-desktop changes all have been "verified" by beeing used |
| 21:08.30 | DocScrutinizer05 | merlin1991: that's again userland |
| 21:08.35 | merlin1991 | we never had a *public* review of the modified hildon desktop changes that got merged |
| 21:09.16 | merlin1991 | DocScrutinizer05: there's userland and userland, a rock stable kernel is never going to help you if your window manager is foobar |
| 21:09.18 | Woody14619 | Agreed... But to say they shouldn't be made an option, and installed as a loadable module? |
| 21:09.40 | DocScrutinizer05 | you spot a bug in a userland process blindly, while you're fsckd when some idiot thought I2C doesn't neede any locking |
| 21:11.00 | DocScrutinizer05 | Woody14619: [2012-08-06 22:09:50] <DocScrutinizer05> (([2012-08-06 20:48:50] <freemangordon> .ko sitting in /lib/modules does not limit your freedom)) bq27200.ko was a first example why we don't want an arbitrary collection of untested *.ko sitting in /lib/modules of CSSU kernel. Of course you can crowd the /lib/modules with all you like as long as you blacklist it, and as long as core kernel code isn't affected, the possible risk |
| 21:11.02 | DocScrutinizer05 | is limited to filling filesystem with all that stuff. |
| 21:11.18 | DocScrutinizer05 | but again, why would we want to do THAT |
| 21:11.19 | DocScrutinizer05 | ? |
| 21:11.39 | Woody14619 | bw27200 wasn't "just sitting in /lib/modules". It was also included as a default loadable. That's different and you know it. |
| 21:11.47 | merlin1991 | why do we fill filesystem with other stuff we add that are only an option? |
| 21:12.09 | DocScrutinizer05 | Woody14619: that's what except a dark accusation now? |
| 21:12.34 | Woody14619 | And even now, it's still there, just black listed, since SOME users want that option. |
| 21:12.53 | DocScrutinizer05 | Woody14619: would you please re-read my post? |
| 21:13.44 | *** join/#maemo-ssu _rd (~rd@p57B498F6.dip0.t-ipconnect.de) |
| 21:14.14 | Woody14619 | I did... You show fmg basically saying what I've said. |
| 21:14.31 | DocScrutinizer05 | stock kernel + a + b + a-blacklist + b-blacklist == stock kernel |
| 21:14.52 | Woody14619 | Close, but no, it's not.. |
| 21:15.03 | DocScrutinizer05 | ooh |
| 21:15.14 | Woody14619 | Because stock kernel can't load a and b. You need stock kernel + ability to load a & b. |
| 21:15.31 | DocScrutinizer05 | and I'm not sure you git it right what fmg said and what *I* added |
| 21:16.55 | Woody14619 | My ability to comprehend is limited by several factors, one of them being the ability of the other party to express things. What I read looked to be a quote from fgm. If you added to it, there's no way for me to know where his input ended and yours started. |
| 21:17.29 | DocScrutinizer05 | so why exactly do we need a KP-based cssu kernel with 678 additional modules that all are blacklisted? when everybody can as well just install KP-original? |
| 21:17.39 | Woody14619 | An again, we're at some level in violent agreeement on this... |
| 21:18.04 | DocScrutinizer05 | Woody14619: the fmg qiote been the one in (( )) |
| 21:18.41 | Woody14619 | Ah, I see. :) Thank you for that clarification. Now that I see that, it's much clearer. |
| 21:20.29 | amiconn | wonder what percentage of users would run cssu without kp |
| 21:20.36 | amiconn | *wonders |
| 21:20.49 | DocScrutinizer05 | I'm off for another start of my day - if nothing holds me back once more |
| 21:20.52 | DocScrutinizer05 | o/ |
| 21:21.10 | Woody14619 | The advantage to having KP is that it does include patches to critical items, not in stock. And it's being maintained. |
| 21:21.21 | DocScrutinizer05 | amiconn: that's so completely absolutely irrelevant |
| 21:21.28 | Woody14619 | Albiet, not to the strict standards everyone would like. |
| 21:21.42 | amiconn | Why is wondering irrelevant?@;) |
| 21:21.54 | DocScrutinizer05 | the answer is |
| 21:21.57 | Woody14619 | Let's face it: stock is no longer maintained. If something is broken, it's going to stay that way. |
| 21:22.24 | DocScrutinizer05 | that's why we need a replacement for STOCK, not a new KP |
| 21:22.50 | DocScrutinizer05 | and that's what CSSU is all about, first take |
| 21:23.03 | Woody14619 | At this point, I can say with some certainty that Nokia no longer even has people employed that are capable of doing a kernel fix IF they wanted to. |
| 21:23.26 | DocScrutinizer05 | that's why CSSU exists |
| 21:23.32 | Woody14619 | Yet alone to roll a new release, or to have the desire to do so. |
| 21:23.43 | DocScrutinizer05 | anyway o/ o/ o/ o/ o/ o/ o/ o/ o/ o/ o/ o/ o/ |
| 21:23.46 | Woody14619 | Yes... And the first letter of CSSU is what? Community. |
| 21:24.11 | Woody14619 | Community requires volunteers to make and maintain things. |
| 21:25.40 | Woody14619 | Right now, in our community, we have someone willing to do things. If we have a choice of people willing to do things, all the better. Again: I would love a stock+patch kernel. But one is not available or forthcoming. If it were, and someone were willing to maintain that, even at a minimal level, I would consider that option (as would others, I'm sure). |
| 21:26.00 | Woody14619 | But lacking that option, and faced with a "hole in the house" or a fully painted house.... |
| 21:28.35 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 21:29.11 | DocScrutinizer05 | you forget the panter will leave your house with 100 new holes, for the nails he mounted his scaffold to |
| 21:29.16 | DocScrutinizer05 | painter* |
| 21:29.47 | DocScrutinizer05 | while we lived with that now known hole since 3 years and nobody even noticed |
| 21:30.14 | Woody14619 | Again, when you live in Arizona, and he's the only painter willing to come to your house... Those are your options. |
| 21:30.26 | DocScrutinizer05 | and you won't tell me more users "tested" KP by using it than did with stock kernel? do you, did you already? |
| 21:31.59 | Woody14619 | This isn't about testing stock kernel... And to be fair, even a stock device has it's issues. The number of times a go "Application X has closed" as a yellow pop-up before I updated to CSSU/KP vs after? |
| 21:32.38 | DocScrutinizer05 | you're arguing we should fix one hole by applying a massive overkill of measures nobody really knows how many new holes you'll face later, and do all this based on the rationeale "but there's somebody willing to do it" ? |
| 21:33.07 | Woody14619 | This is about Community. Community is what you make it. You can wish it to be something else all you want, but unless you put in the effort to actually make the change you seek... |
| 21:33.10 | Woody14619 | No... I'm not |
| 21:33.23 | Woody14619 | YOU keep saying I am. But then you're not listening to what I say anyway. |
| 21:33.35 | Woody14619 | I've never advocated for simply tossing KP in. |
| 21:33.48 | Woody14619 | But you're so wrapped up in your own opinion that you keep missing that point. |
| 21:34.00 | DocScrutinizer05 | mhm |
| 21:34.24 | DocScrutinizer05 | I'm actually wrapped up in being afk since 3h and still got nothing done |
| 21:34.37 | Woody14619 | Join the club... :P :) |
| 21:34.59 | DocScrutinizer05 | instead I ponder how "C" and community is any relevant for basic principles of risk management |
| 21:35.20 | DocScrutinizer05 | but I stop that now and here, or rather in the bathroom |
| 21:35.22 | Woody14619 | I'm saying, I'd love to see alternatives... But to have those, we need more people in "C" |
| 21:37.39 | Woody14619 | Frankly, offering a "Community" update that's the same as the SSU for lack of community to maintain it? Why bother with a CSSU at all. Yes, I'd love a stable environment. Give the choice of KP or stock for CSSU-S, right now I'd go for stock. But I'd prefer a 3rd choice. |
| 21:38.42 | Woody14619 | And if we have someone willing to make a 3rd choice, even if he's starting from the "wrong end" in your view (whittling down KP vs building from stock), I'd still rather at least see the fruit of that effort as an option vs discouraging it from occuring at all. |
| 21:39.20 | DocScrutinizer05 | we can agree on that 100 |
| 21:39.22 | DocScrutinizer05 | % |
| 21:39.41 | Woody14619 | I'd be equally happy with another choice of stock+patch, if someone was willing to submit it. More options (within limits) = better results. |
| 21:41.05 | Woody14619 | As I noted, we're in violent agreement on this. The difference is, I'm not complaining to fmg that he's "doing it wrong" and discouraging his efforts to build that 3rd option. You have been. That's the reason I chimed in when I did... |
| 21:41.15 | jon_y | ~scratchbox |
| 21:41.16 | infobot | well, scratchbox is a cross-compiling system that uses binfmt_misc, rpc calls, and an nfs mount to make a cross-build appear to be 100% native, and is found at http://www.scratchbox.org/ |
| 21:42.20 | jon_y | is this the guide to setting up a dev environment? http://wiki.maemo.org/Documentation/Maemo_5_Final_SDK_Installation |
| 21:42.32 | Woody14619 | Anyway, we both have stuff to get to... Have a nice night! |
| 21:44.11 | Woody14619 | For general app building? I believe so jon_y. There is another made by pali for kernel building. FWIW, you may want to do a power-search on TMO to see if there are threads about setup. |
| 21:44.43 | jon_y | Woody14619: well, yes, I want to stick framebuffer into kp51 |
| 21:44.53 | Woody14619 | I now there are at least a couple VM images out there that are pre-built. |
| 21:45.03 | jon_y | such as? |
| 21:45.10 | Woody14619 | Then you really want to look for Pali's version. |
| 21:45.34 | jon_y | what do I look for? |
| 21:45.39 | Woody14619 | AFAIK there already is a framebuffer mode in KP (and stock for that matter) |
| 21:45.57 | jon_y | hmm ok, its not enabled on boot for some reason |
| 21:46.41 | Woody14619 | Do a power search on TMO for "kernel power". I know that backupmenu uses the FB in it's boot work. May be worth looking at the code for that to see how he's doing it as well. |
| 21:47.36 | Woody14619 | robbie & pali are both still quite active, here, on TMO and in general. |
| 21:47.56 | jon_y | "power search"? |
| 21:48.33 | Woody14619 | Yup, on TMO, it's in the right bar, top option |
| 21:48.49 | Woody14619 | ~tmo |
| 21:48.49 | infobot | i guess tmo is http://en.wikipedia.org/wiki/TMO, or http://talk.maemo.org, or http://de.wikipedia.org/wiki/Terrestrial_Trunked_Radio#TMO. It's *not* T-MO (see ~T-MO) or trolls, morons, oxen. |
| 21:49.16 | jon_y | oh, I thought it was a username |
| 21:49.31 | Woody14619 | forum. :) |
| 21:49.43 | Woody14619 | Enjoy! I'm afk for a bit. |
| 22:22.24 | DocScrutinizer05 | anyway, taking the approach of "we can blacklist" we need two things done: 1) review every single patch simply for changes to core kernel code (which, in case, would need further review to make 100% sure those minimalistic changes can no way ever introduce issues to core), same for other unrelated *.ko that wouldn't get blacklisted with the blacklist entry fro the .ko under review. -- And 2) after we're thru with that for .ko |
| 22:22.24 | DocScrutinizer05 | creating patches, we need to review all the remaining stuff that isn't meant to create an additional .ko but rather belongs to a functon that will get monolithic to kernel, or even affect core kernel itself (example: scheduler) |
| 22:25.35 | DocScrutinizer05 | ps for 1) (other unrelated .ko): example: the I2C 'module' getting patched to make bq27200.ko work. When reviewing bq27200 we need to notice it touches I2C as well, and thus introduces changes to parts of kernel that won't 'vanish' by blacklisting bq27200.ko |
| 22:28.15 | DocScrutinizer05 | h-e-n is monolithic and thus can't get blacklisted. No question it goes to the group of patches that either need further review and industry-grade tests, or simply stays out of cssu-kernel until those tests/reviews can be done |
| 22:28.35 | DocScrutinizer05 | ^^h-e-n again just an example |
| 22:28.48 | jon_y | h-e-n patches is in kp too? |
| 22:28.54 | DocScrutinizer05 | yep |
| 22:29.17 | jon_y | kp seems to be the super-everything-omnibus kernel |
| 22:29.21 | DocScrutinizer05 | h-e-n basically *is* kernel patches |
| 22:29.41 | jon_y | ok, I thought it does that host mode usb |
| 22:29.56 | DocScrutinizer05 | sure, we didn't feel like rolling specific kernels for everything |
| 22:30.16 | jon_y | kp superseded it? |
| 22:30.39 | DocScrutinizer05 | h-e-n is 99% kernel patches, plus 1% userland GUI and scripts to operate the patched kernel |
| 22:31.21 | jon_y | how does it differ from kp? |
| 22:31.34 | DocScrutinizer05 | MohammadAG wrote the 0.5% GUI, I wrote the 0.5% scripts. kernel patches done by h-e-n team |
| 22:32.13 | DocScrutinizer05 | jon_y: sorry, your question makes no sense |
| 22:32.43 | jon_y | I'm under the impression h-e-n is another kernel image |
| 22:32.51 | DocScrutinizer05 | the h-e-n hostmode package, on installation, pulls KP and GUI and scripts |
| 22:32.52 | jon_y | oh h-e-n team |
| 22:33.19 | jon_y | ~h-e-n |
| 22:33.19 | infobot | methinks hen is hostmode-easy-now, or http://talk.maemo.org/showthread.php?t=65232 |
| 22:33.44 | DocScrutinizer05 | we decided very early we don't want to roll outr own h-e-n kernel, and unified it with KP |
| 22:34.58 | DocScrutinizer05 | esp since for h-e-n you usually want other functions too that are not provided by stock kernel |
| 22:35.10 | DocScrutinizer05 | like support for various filesystems |
| 22:43.12 | DocScrutinizer05 | (approach of blacklisting) then there's a bunch of bugfix patches from upstream, that are already well understood in their general operation principles and need only relaxed testing and review regarding possible specific problems they might exhibit on N900. Example: the mmc driver patch |
| 22:45.54 | DocScrutinizer05 | depending on severity of the bug they are fixing, we need to decide on each single one if it's worth taking it in and doing the evaluation, or if we think it's too risky to have them in with relaxed testing |
| 22:47.33 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:52.41 | DocScrutinizer05 | if anybody was willing to prepare a table listing all the patches we have in KP and which cathegory they're in (clean .ko can get blacklisted | unclean .ko or monolithic | upstream patches not blacklistable | 'own' patches that need very close review and tests) we can cary on and have public review of the interesting ones and of the corecode |