IRC log for #maemo-ssu on 20130920

00:06.35*** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua)
01:51.41*** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz)
02:12.06*** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au)
02:12.48jonwilhi
02:14.05jonwil~seen nicolai
02:14.06infobotjonwil: i haven't seen 'nicolai'
02:55.08*** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn)
03:15.46*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
03:20.42*** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:a026:47f2:13f0:39a6)
03:23.01DocScrutinizer05moin jonwil
03:23.15jonwilhi
03:25.42DocScrutinizer05jonwil: you need to log in to nickserv, otherwise some IRC functions will not work for you
03:26.38DocScrutinizer05/ns info jonwil
03:26.41DocScrutinizer05:-o
03:26.49DocScrutinizer05[2013-09-20 05:26:02] [Notice] -NickServ- Last seen  : Oct 03 15:38:15 2012 (50 weeks, 1 day, 11:47:47 ago)
03:27.37DocScrutinizer05/ns help identify
03:28.05DocScrutinizer05/msg nickserv help identify
03:28.19DocScrutinizer05if your client doesn't support the /ns shortcut
03:28.56DocScrutinizer05/msg nickserv help password
03:29.57DocScrutinizer05/msg nickserv help setpass
03:30.07DocScrutinizer05scrap the line befor that
03:30.37jonwilI just ifentified
03:30.39jonwilidentified
03:30.44DocScrutinizer05good
03:31.03DocScrutinizer05then e.g. invite-exempts will apply
03:31.08DocScrutinizer05;-)
03:31.55jonwilstill waiting for my Gentoo box to finish compiling :)
03:32.01jonwilfinish updating :)
03:34.01DocScrutinizer05hah
03:35.16DocScrutinizer05~listkeys cssu
03:35.37DocScrutinizer05~cssu-optional
03:35.37infobotextra, extra, read all about it, cssu-optional is http://maemo.org/community/maemo-developers/how_to_include_rewrites_of_closed_blobs/
03:39.58DocScrutinizer05~cssu-optional is also http://maemo.merlin1991.at/cssu/meetings/2012-05-14.txt
03:39.58infobotDocScrutinizer05: okay
03:41.12DocScrutinizer05ponders to set up an autoresponder for regex along the line "why .* not goes into CSSU"
03:41.45DocScrutinizer05especially for freemangordon and e*_
03:42.53DocScrutinizer05this constant bitching and spreading of FUD and made-up facts starts to seriously annoy me
03:43.34DocScrutinizer05http://talk.maemo.org/showpost.php?p=1375494&postcount=6
03:46.04DocScrutinizer05extremely annoying example, filled with ~85% made-up and erratic assumptions: ivgalvez' rant in http://talk.maemo.org/showthread.php?t=91308 - now moved to another thread I can't locate
03:46.25*** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode)
03:46.35*** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn)
03:54.00DocScrutinizer05I mean, we have public meetings and policies decided upon during such meetings for some reason, eh?
03:55.21DocScrutinizer05not for some guys to wait until those who proposed and drafted the policy are annoyed to a degree where they leave, by constant ignorance, and then those guys try to push their way
03:56.36DocScrutinizer05that's an extremely rude behaviour against all those who took the time to come up with a *solutions* for itches that those ignorant guys uttered the loudest
03:58.24DocScrutinizer05or - to put it plain and straight - we have a policy how to include arbitrary packages into CSSU. If that policy doesn't meet your ideal, then too bad. It been set up for the benefit of all of us, incl users. You can't ignore it just for your own convenience
03:59.48DocScrutinizer05and for sure it's silly to try and convince the "distro" maintainer to ignore that policy, when it's been him who introduced it
04:00.07DocScrutinizer05merlin1991: ^^^ right?
04:03.05jonwilis http://talk.maemo.org/showthread.php?t=91399&highlight=ivgalvez the thread you wanted (re the rant from ivgalvez)?
04:03.54DocScrutinizer05YES! :-)) many thanks
04:05.37DocScrutinizer05>>First of all is lack of manpower<< so what? Ivgalvez to do the scheduler and tell devels what to work on?
04:06.54DocScrutinizer05>>Currently, the only development on Maemo OS is being done inside CSSU with a very small team of developers<< yep, but unrelated to FPTF  >>and it's difficult to think that they will be able to maintain both CSSU for N900 and a new port for the Neo900 at the same time.<< who says they shall or will do? Nobody suggested that
04:08.51DocScrutinizer05[removing redundant bits] >>But also there will be a clash of interests regarding development for N900 and Neo900<< UHUH! >>For example, open source replacements for closed applications are not entering CSSU<< well, see *my* rant above   >>we see that improved/upstream versions of packages are not allowed to be part of it<< ditto
04:09.24DocScrutinizer05>>but a port to a different hardware will require to rewrite as many closed source components as possible.<< says who?
04:09.56DocScrutinizer05>>Because it's not just enough to run an unmodified Fremantle image on the Neo900 with a shiny new kernel.<< again, says who?
04:10.13DocScrutinizer05>>Using closed source applications from Nokia in a non Nokia device, would be illegal<< bullshit
04:10.48DocScrutinizer05>>and even if Nokia might not care about it now, it's a clear risk to the project as a C&D could be received at any moment<< and here it starts to get bizarre
04:11.31DocScrutinizer05I'll rather stop my review, or some chanop might kick me for extreme spamming and ranting
04:16.55jonwilI see no reason why replacement work cant be done in a way that benefits both CSSU and Neo900
04:18.45jonwilfor example any MCE replacement that may show up could go into CSSU AND be changed for any changes hardware on Neo900
04:19.27DocScrutinizer05jonwil: absolutely my (even initial) idea
04:20.29DocScrutinizer05but some guys take _everything_ they can use to pervert and invert it to the opposite and use it against something unrelated, just because it can get used this way, after transmutation
04:20.55jonwilI would even say that we could potentially make ofono or fsogsmd talk the right dbus interfaces for replacing the cellular services daemon (like we talked about before) but make it support both an Option backend (for the Neo900) and the existing ISI backend (for the N900) so it too could be used in CSSU
04:21.37DocScrutinizer05of course, I thought we already made clear we'll do exactly that ;-)
04:22.12jonwilThe hard part there is figuring out all the DBUS interfaces
04:22.24DocScrutinizer05but that doesn't matter to ivgalvez who is pissed about CSSU not forcefeeding new alternative distro to all users
04:23.06DocScrutinizer05when it was for ivgalvez, even the wallpaper was nailed down in MP
04:23.36DocScrutinizer05"hey, let's introduce our own Non-Nokia theme!"
04:23.50DocScrutinizer05"let's ship it via CSSU!"
04:24.58DocScrutinizer05instead of fixing the idiocy of MP, those guys plan to exploit the concept for their own purposes, doing exactly same like Nokia did, just in the opposite direction
04:25.54DocScrutinizer05"Nokia foced chess-game onto all users' devices - new CSSU will delete it from all isers' devices" SUUUURE!
04:26.18wmaroneboy, you jumped down his throat
04:26.40jonwilhey, I like the chess game (except for the fact that it shows just how much I SUCK at chess when even the easy setting is far too hard for me to beat :)
04:26.44DocScrutinizer05"Nokia forced camera-ui onto user, CSSU now forces camera-ui2 onto all users" SUUUUURE
04:27.21jonwilso yeah today I plan to work on playing with pulseaudio-module-nokia-voice and on MCE stuff (mce stuff will need to wait for my Gentoo box to finish updating :)
04:27.26DocScrutinizer05FIX DAT MP, FINALLY! nuff said
04:28.02DocScrutinizer05idiotic bitching about "what goes into CSSU MP, and what doesn't"
04:28.12jonwilI wonder why Nokia went with the mp-blah concept in the first place
04:28.35DocScrutinizer05easier for them
04:28.40DocScrutinizer05they sold a product
04:28.50DocScrutinizer05no idea about FOSS concepts and spirit
04:29.22jonwilyeah they wanted a fixed "firmware" that contain a fixed set of packages with updates just pulling in a new mp-blah package
04:29.35DocScrutinizer05basically Nokia exploited and abused linux as much as they legally could
04:33.30jonwilCompared to how it is on some phones running a Linux kernel (like my old Motorola Z6) we have it so good on the N900.
04:33.54jonwilThe Z6 only ran Motorola signed kernels
04:34.17DocScrutinizer05:nod: sure
04:34.53jonwilwell until someone found an exploit in the bootloader that is :)
04:35.05DocScrutinizer05but that doesn't make MP concept any better or any more worthy to be kept and possibly even augmented, instead of finally fixed
04:35.18jonwilnope
04:35.22jonwilwe should definatly fix it
04:35.25DocScrutinizer05yes
04:35.26jonwiland get rid of it for good
04:35.29DocScrutinizer05yes
04:37.17DocScrutinizer05paricularly since I'm fed up with taking the flames for allegedly "not letting in" alternative FOSS replacements "into CSSU", when in fact I'm only defending user from augmenting resp perpetuating MP concept
04:38.10jonwilall of the bits related to package management and installing are 100% FOSS so there is nothing standing in the way of replacing that crap
04:38.38DocScrutinizer05it fells like me standing at a illegal landfill and getting bashed by those who don't understand why they can't dump their trash there as well
04:39.14DocScrutinizer05feels* even
04:44.59freemangordonDocScrutinizer05: morning. do you have time, oscilloscope and a spare n900 you can disassemble? I am out of ideas what to do with SSI/ISP, I think both suffer from the same problem
04:45.23freemangordonIt is either lack of some power supply or some clock
04:45.54DocScrutinizer05jonwil: what do you think about radically removing all DEPENDS in MP, and instead using pre/post-install script of MP to run apt-get install commands?
04:46.05DocScrutinizer05freemangordon: sorry, no scope
04:46.05freemangordonbut I just can't figure out what exactly is missing :(
04:46.10freemangordondammit
04:46.52freemangordonI have a 10MHz 20 years old russian one :D
04:47.10DocScrutinizer05freemangordon: I wound up my lab some 6 years ago
04:47.49DocScrutinizer05technology moved too fast for my lab to keep pace with it, thus it became more and more obsolete
04:47.58freemangordonwe'll have to find someone who can trace what is going on in the real life (HW level that is)
04:48.29DocScrutinizer05and in the end I agreed with Werner Almesberger and Andy Green that human brain is the best lab tool of all
04:48.32freemangordonesp when it comes to battery usage optimizations
04:48.52DocScrutinizer05ETM
04:49.05freemangordon~etm
04:49.19DocScrutinizer05and patched kernel drivers, with lots of kprintf
04:49.31DocScrutinizer05embedded trace macrocell, see OMAP
04:50.24freemangordonDocScrutinizer05: hmm, no, I want to see what comes in and goes out of the peripherals, not OMAP
04:50.32DocScrutinizer05a nifty little ARM IP block
04:50.46freemangordonfor example - is camera mux really in high when it should be
04:51.05DocScrutinizer05err wut? isn't it like 2what goes out there comes in here" and vice versa?
04:51.36freemangordonis anything flowing through SSI bus and what is the frequency?
04:51.42freemangordonetc
04:51.59DocScrutinizer05well, I bet the frequency is what it got set to
04:52.14freemangordonOMAP can't be used to monitor RAPU<->GAZOO for example
04:52.17DocScrutinizer05and what's flowing thru it shows up in the buffer
04:52.42DocScrutinizer05err, actually the APE OMAP can't, that's true
04:52.46freemangordonDocScrutinizer05: The point is that IMO everything is set up correctly
04:53.01freemangordonbut the shit still don;t work
04:53.11DocScrutinizer05well, then what's missing is the right initialization sequence
04:53.33freemangordonwhich is done by the drivers, that work with older kernels
04:53.52DocScrutinizer05no, init isn't done by the kernel drivers for all I know
04:53.54freemangordonso it must be something in that new facny hwmod and/or clock framework
04:54.03freemangordonfancy even
04:54.08DocScrutinizer05it's a complex thing done in higher level daemons
04:54.40DocScrutinizer05as well you could assume DHCP is done by the NIC kernel driver
04:54.42freemangordonDocScrutinizer05: it looks like the whole power domains are shut down when they should not be
04:55.28freemangordonanyway, attachig a scope will be much easier/faster than that ETM IMO
04:55.32DocScrutinizer05ISI is a rather complex multichannel protocol afaik
04:56.01freemangordonDocScrutinizer05: I am not getting interrupts from the SSI module, what has ISI to do with that
04:56.09freemangordonthe same for ISP
04:57.03freemangordonit is like saying that it is libdigicam to blame for no interrupts from ISP :P
04:57.37DocScrutinizer05well
04:57.47freemangordonthink who could have a scope and spare device to play with...
04:57.52freemangordonthinks*
04:58.15DocScrutinizer05patch the SSI driver in fremantle 2.6.28 and trace the first action it is doing
04:58.50freemangordonDocScrutinizer05: the driver that doesn't work in 3.10 works in 3.5
04:59.03DocScrutinizer05(scope) have you even checked if there are any accessible contact points to attach a probe to?
04:59.07freemangordon(SSI that is)
04:59.29freemangordonsee the bottom of rx51 schematics
05:00.08jonwilTime to have some food then work on pulseaudio-module-nokia-voice stuff :)
05:00.15DocScrutinizer05I don't even know what you would want to verify or log, on SSI, with a scope
05:01.15freemangordonpower supplies and clocks
05:01.30freemangordonthe usual stuff
05:01.50freemangordonDocScrutinizer05: I feel stuck, can;t think of any other way to continue
05:01.50DocScrutinizer05ok, so let's assume I did, and i'm telling you "clock is there"
05:02.06freemangordonwhat frequency it is?
05:02.11DocScrutinizer05AHA
05:02.17DocScrutinizer05does that matter?
05:02.22freemangordonyes
05:02.26DocScrutinizer05why?
05:02.52freemangordonbecause (in case of SSI) we talk at 55Mbs for example
05:03.07freemangordonis if we have iface cclock at 110, it won;t work
05:03.12DocScrutinizer05as long as it's not way too high, it shouldn't make a lot of difference, except for max bandwidth
05:04.04freemangordonsame for the cameras, they expect 9.6 Mhz
05:04.20freemangordon(programmed to do so)
05:04.29DocScrutinizer05when you're afraid that clock is not N but 2*N, then set clock to N/16 for a start, and see if it works then
05:04.41freemangordonalready did :(
05:05.23freemangordonI am afraid that either plls are incorrectly programmed or powered down
05:05.42DocScrutinizer05that should be able to get checked
05:05.51freemangordonboth ssi and ISP use their own pll/divider noone else uses
05:06.00DocScrutinizer05PLLs have some registers where you can check if they are locked for example
05:06.04freemangordonor rather divider chain
05:06.31DocScrutinizer05seems you have a clue, a trace to follow, already
05:06.34freemangordonDocScrutinizer05: sure, but attaching a scope is faster way to check what is wring/missing
05:06.44DocScrutinizer05no
05:07.05DocScrutinizer05it only shows you THAT *sth* is missing (or not)
05:07.18DocScrutinizer05it doesn't reveal WHAT is missing
05:07.45DocScrutinizer05how about JTAG?
05:07.49freemangordonwell, if a power supply is missing, it will show which power supply is that
05:08.18freemangordonDocScrutinizer05: would'n jtag require a special SW?
05:08.24DocScrutinizer05err
05:08.33freemangordonI know what jtag is
05:08.36DocScrutinizer05on your JTAG probe, sure
05:08.49freemangordon:nod:
05:08.54freemangordonwhich I don;t have :)
05:08.55DocScrutinizer05just thinking aloud
05:08.58freemangordonah
05:09.21DocScrutinizer05also iirc you *always* can _read_ GPIO
05:09.28DocScrutinizer05even when not in GPIO mode
05:09.58freemangordonyes, but is that really propagated to the outside world? is output buffer enabled? etc...
05:10.05DocScrutinizer05yes
05:10.28freemangordonanyway, have to run
05:10.37freemangordonwill think about what to do
05:10.38DocScrutinizer05the GPIO input afaik is always connected to the pin, and reading the register always shows the actual state of the pin
05:11.02freemangordonhmm, iirc it is connected through a buffer
05:11.09DocScrutinizer05not input
05:11.17freemangordonwill check in trmo
05:11.21freemangordon*trm
05:11.22DocScrutinizer05:nod:
05:11.37freemangordonhowever, gpios won;t help for the power supplies
05:11.57DocScrutinizer05check in RL as well, with sth simple like e.g. some UART CTS or RTS or whatever
05:12.18freemangordonbtw I can always read /dev/mem for mux and gpios
05:12.25freemangordonno need to do it in the kernel
05:12.32DocScrutinizer05:nod:
05:13.03freemangordonhmm, maybe I should do it, while searching for a girl with a washing machine :)
05:13.11freemangordon(someone with a scope)
05:13.16freemangordonanyway, bye
05:13.40DocScrutinizer05why would you need a scope for power lines?
05:14.20DocScrutinizer05also, which power lines would that be?
05:18.44DocScrutinizer05honestly, when some LDO isn't powered up I'd expect that to a) show immediately since every single one powers quite a number of components, and b) you should be able to easily tell the fact from reading the config of the LDO directly from LDO's config registers, and see if those values suggest it's powered or not
05:19.35DocScrutinizer05I'd rather trust in that than in any clumsy probing of a impossible to reach trace on the PCB with a scope
05:30.22*** join/#maemo-ssu luf (~luf@ip-89-103-184-55.net.upcbroadband.cz)
06:47.07*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@14.115.30.60)
06:51.02*** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode)
07:42.37*** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz)
07:43.27*** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa)
07:58.04*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
08:11.37*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
08:12.32*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
08:14.08*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
08:17.19*** join/#maemo-ssu FReaper (~assassin@203.106.65.176)
08:21.56*** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172)
08:31.00jonwilok, investigating module-nokia-voice didn't get me anywhere
08:33.45*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
08:37.39*** join/#maemo-ssu FReaper (~assassin@183.171.160.129)
08:44.34*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
08:54.50jonwilanyone here any good with debian packaging?
09:12.08*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
09:13.57*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.176)
09:24.42*** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu)
10:18.25Palijonwil: me?
10:19.42jonwil:P
10:19.52jonwilwrong channel :P
10:36.37*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
10:43.01*** join/#maemo-ssu discopig (~discopig@modemcable076.197-131-66.mc.videotron.ca)
10:51.00*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
11:21.37*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
11:29.19*** join/#maemo-ssu arcean (~arcean@aafs46.neoplus.adsl.tpnet.pl)
11:50.24dos1<DocScrutinizer05> jonwil: what do you think about radically removing all DEPENDS in MP, and instead using pre/post-install script of MP to run apt-get install commands?
11:50.46dos1it's not as simple as that, you can't run another apt-get/dpkg when one instance is running
11:52.04dos1I think the correct way to go would be chaging dependencies to recommendations, or something like that
11:53.30dos1but it might be necessary to check and maybe fix apt configuration (dunno about HAM) and checking it's impact on other packages
11:53.38dos1s/it's/its/
11:53.44Palinot possible
11:53.54Paliyou cannot run dpkg/apt from pre/post scripts
11:54.13dos1Pali: just said that :P
11:54.43Palithe only one way to deal with dependences is metapackage
11:55.39dos1yes, that's for sure
11:55.50dos1but some dependencies shouldn't be hard ones
11:56.04dos1I guess everything is now in DEPENDS?
11:57.08jonwilThe right way is to fix H-A-M and apt-get and dpkg and etc so that we can do things the way Debian proper does it
11:57.16jonwilthey dont have metapackages or other crap
11:57.47dos1in Debian, there's no "one set of complete system"
11:58.24dos1Ubuntu is actually a bit closer to Maemo in this regard, with their ubuntu-desktop, kubuntu-desktop, xubuntu-desktop etc. metapackages
11:59.16dos1but well, maybe it's possible to use tasksel somehow
11:59.56dos1err, those ubuntu metapkgs are provided by tasksel :)
12:00.44dos1so I quess that's the answer - it's as close to Debian as we can get
12:01.02jonwilwhat we really need is some way to say "this package is sticky and shouldn't be uninstalled automatically" (IIRC apt-get/dpkg/etc supports that but the Maemo version is missing that functionality)
12:01.30jonwilThat way we can mark packages are "must keep" and stop them from being uninstalled unless the user asks for them to be uninstalled...
12:01.31dos1this "stickiness" is meant to be used by user, not by distro maintainers
12:01.47jonwilno, there is some other feature that lets you mark something as "system" or something
12:02.03dos1oh, that one
12:02.39dos1it's for showing big warning "you're trying to remove essential package, type 'Yes I know what I'm doing' to continue" :P
12:03.14jonwilyes, the one that makes sure that whatever the apt-get command for removing unnecessary packages is wont remove them automatically
12:03.40dos1autoremove is actually another thing
12:03.46jonwiloh ok
12:03.54dos1proper dependencies alone should do it just fine
12:06.11dos1the proper way to handle current metapkg mess would be to use tasks together with package priorities
12:06.13dos1https://wiki.debian.org/tasksel
12:06.18*** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru)
12:06.43jonwilok, be back soon, need to go get some food before the shops shut :)
12:07.27jonwilwill stay idle in IRC and read scrollback when I get back :P
12:07.30dos1this way you're free to replace any package you want, for instance with its free replacement
12:08.21dos1and still you have control under dependences of whole system and you can bring back original state with few commands
12:11.08*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
12:17.43*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
12:22.55*** join/#maemo-ssu Mihanizat0r (~MirandaLS@170.133-224-87.telenet.ru)
12:40.55*** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa)
13:00.53jonwilok, back
13:03.32jonwiltime to cook some Nachos then get into MCE work :)
13:11.34DocScrutinizer05meh, c'mon
13:12.15*** join/#maemo-ssu kolp (~quassel@212.255.21.58)
13:13.05jonwilmeh what?
13:13.14dos1meh, nachos
13:13.19dos1;)
13:13.26DocScrutinizer05I can't run apt from within apt? Oh! then how about exec, or about shell scripts, or about batch, or about "echo $cmd > /etc/crontab" Ooops we got no cron, but we got alarmd
13:14.26DocScrutinizer05afk for coffee
13:14.37dos1IMO that would be worse than what's there at the moment
13:15.55DocScrutinizer05nothing can be worse than nokia/cssu MP
13:16.47dos1even if it's not worse, then for sure it's not better either :P
13:17.28DocScrutinizer05it has one killer feature, it doesn't create hard dependencies that forbid uninstalling of packages
13:18.01DocScrutinizer05resp uninstall MP when e.g. installing procps
13:18.03dos1I'm for doing it "the debian way", with tasksel and/or metapackages done properly
13:18.18dos1which doesn't create hard dependencies either
13:18.36DocScrutinizer05the OK all for it, grat!
13:18.41DocScrutinizer05great even
13:19.12DocScrutinizer05we just finally MUST sanitize that shit that Nokia inherited to us
13:19.43DocScrutinizer05it's like a psycho virus
13:20.12DocScrutinizer05needs to get nuked from God's great earth
13:20.40*** join/#maemo-ssu dhbiker (~dhbiker@193.2.218.150)
13:20.40DocScrutinizer05since everybody has another notion what needs wnd what mustn't get into the MP
13:21.36dos1actually, it shouldn't be hard to modify current metapkgs to behave correctly
13:21.44dos1what's more challenging is proper upgrade path
13:22.30dos1it may or may not be a bit harder, it needs evaluating
13:23.32DocScrutinizer05first things first. Please come up with a proper sanitized MP
13:24.39DocScrutinizer05since obviously nobody likes the concept merlin1991 and me introduced how to maybe live *with* the old MP
13:24.57jonwilI think the idea that a metapackage forces exactly one and only one specific version of <package> is a very bad idea going forward
13:25.12DocScrutinizer05ergo we need to nuke MP completely, or transform it into something bearable
13:25.58dos1MP shouldn't depend on specific versions
13:26.00jonwilDebian packaging is something I know nothing about so I will let the gurus nut it out :)
13:26.07dos1that's right
13:26.21dos1and it should depend on as little as possible to get bare system working
13:26.37DocScrutinizer05*nokia* could do that MP shite, but a *community* impossibly can prosper with that abomination
13:26.41dos1the rest should be in recommends, which is installed by default anyway
13:26.45dos1but it's not hard dependency
13:27.11dos1exactly like tasks are done in Debian
13:27.31dos1actually, I've googled a bit and it turns out that tasksel now is implemented using nothing else than metapackages :P
13:27.44jonwilWe have 100% source code to all things that matter for package management on N900 Fremantle
13:27.50jonwiland we can change it any way we like
13:29.19DocScrutinizer05or maybe let's think why we need MP. Fix the crap that depends on it?
13:29.37DocScrutinizer05so we actually *can* purge the MP and still everybody happy
13:30.03dos1yup, deleting mp should be possible
13:30.41jonwilAnyone know if there are any packages on Fremantle that relate to cryptography and security (in particular, to encryption for internet traffic like SSL) that are currently closed source?
13:30.48dos1depending on mp is very lazy way to depend on particular version of system
13:31.20DocScrutinizer05I mean, one big problem always been: apt-get upgrade could create inconsistencies. But that been just because packages that depend on each other had no such dependencies declared in their .deb
13:31.20dos1you know, needs PR1.2 or greater - depends on mp version 1.2 or later
13:31.50dos1we shouldn't need to modify anything in package management, maybe except of HAM
13:31.55jonwilWith all the noise about security and cryptography lately (especially the whole NSA leaks thing) I dont want to have important-for-security-but-closed-source packages on my device, things I cant audit or play with or update to a later version with fixes for security issues...
13:32.15dos1rather packages are to be fixed
13:32.38dos1even closed ones can still be repackaged, so that shouldn't be a big issue
13:32.44DocScrutinizer05jonwil: I don't think we got such pkgs
13:32.58DocScrutinizer05dos1: exactly
13:33.24DocScrutinizer05but THAT is really a bit of work, I guess
13:33.26jonwilwifi security bits are closed but WiFi security is so weak anyway that you shouldn't be relying on it for actual security
13:33.54DocScrutinizer05jonwil: particularly you couldn't fix it
13:33.55jonwilmight take a look at the list of closed pkgs and look for anything that might be security-sensitive :)
13:34.29DocScrutinizer05nice plan
13:34.34DocScrutinizer05go ahead!
13:35.27DocScrutinizer05dos1: then otoh, how many packages might be there on maemo that have no big sister on debian, with proper dependencies?
13:35.51dos1I have no idea
13:36.10DocScrutinizer05wouldn't cloning the debian dependencies be pretty simple
13:37.05DocScrutinizer05we still can keep the friggin MP for the core system, the real *core*
13:37.17DocScrutinizer05like d-bus, alarmd, etc
13:37.37dos1those should be hard depends in MP IMO
13:37.42dos1and soft ones for the rest
13:38.12DocScrutinizer05I dunno if our apt supports that
13:38.30dos1unless it's very clippled down, it should
13:38.33DocScrutinizer05I mean, it doesn't even support "CONFLICTS"
13:38.41dos1crippled*
13:38.50DocScrutinizer05or is that just HAM?
13:38.56dos1I think it's just HAM
13:39.11DocScrutinizer05I think that's just HAM that blows chunks
13:39.25dos1I never noticed any symptoms of apt being dumbed down on Maemo
13:39.29DocScrutinizer05Nokia crippled apt and mohammadag reverted it ;-P
13:40.09DocScrutinizer05Nokia forgot that apt is FOSS when designing their ovi store
13:40.28DocScrutinizer05;-P
13:41.41dos1well, apt (proper, debian one :P) is pretty flexible
13:42.06dos1you can configure it to treat recommends as dependences, or suggestions, or whatever
13:42.07DocScrutinizer05prolly one of the reasons for dropping maemo and doing all things completely different in meego/harm
13:42.51DocScrutinizer05Nokia hoped to sanitize themselves from ovi-store
13:43.24DocScrutinizer05on fremantle they realized that they fscked up
13:43.48dos1what was so fscked up with it?
13:43.52*** join/#maemo-ssu arcean_ (~arcean@aaen248.neoplus.adsl.tpnet.pl)
13:45.36*** join/#maemo-ssu DocScrutinizer06 (~saturn@ppp-88-217-55-165.dynamic.mnet-online.de)
13:45.40*** join/#maemo-ssu DocScrutinizer06 (~saturn@openmoko/engineers/joerg)
13:46.32DocScrutinizer05what been my last post that made it?
13:47.30DocScrutinizer05~ping
13:47.30infobot~pong
13:48.46dos1[15:43] <DocScrutinizer05> on fremantle they realized that they fscked up
13:48.47dos1[15:43] <dos1> what was so fscked up with it?
13:48.49*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
13:49.15*** join/#maemo-ssu FatPhil (~pcarmody@87-119-183-129.tll.elisa.ee)
13:49.16dos1and then joins, leaves and your question :P
13:49.54jonwildid we find a solution to the problem of the kernel maintainer who insists that only Nokia can change Nokia drivers even though Nokia have long abandoned Linux and probably dont even care that the driver in question still exists?
13:50.25dos1let's send them copy of g_nokia with our patches named g_maemo
13:50.48dos1so only maemo devs will be able to change it :P
13:51.33*** join/#maemo-ssu oldtopman (~oldtopman@unaffiliated/oldtopman)
13:53.30DocScrutinizer05that's why they *had* to come up with aegis, and HARM
13:54.52DocScrutinizer05since when are packages owned by one maintainer, in kernel upstream?
13:55.46DocScrutinizer05dos1' idea sounds a feasible approach indeed
13:56.13jonwilIts not that they are owned by one maintainer, its that the lead developer (Nokia in this case) gets to decide how "their" driver works and that making wholesale changes without buy-in from the lead developer isn't acceptable
13:57.20dos1well, Nokia is not g_nokia maintainer nor lead developer anymore
13:57.33jonwilOne needs to convince the kernel guys of that
13:57.45jonwilconvince them that Nokia have abandoned g_nokia
13:57.52DocScrutinizer05well, it's not the first nor the only case where more than one driver mutually exclusive service the same resource
13:58.29DocScrutinizer05CSSU happily can switch to g_maemo
13:59.26DocScrutinizer05and g_maemo can coexist upstream alongside g_nokia
14:00.00DocScrutinizer05or did I miss sth?
14:02.40DocScrutinizer05while g_nokia bitrots and g_maemo obviously serves same purpose but gets constant maintenance, upstream maintainers eventually will drop g_nokia
14:03.08DocScrutinizer05dispute aolved
14:03.13DocScrutinizer05solved even
14:04.08DocScrutinizer05particularly when no freak on this planet is using g_nokia in any bew distro/release
14:04.12DocScrutinizer05new*
14:04.51DocScrutinizer05isn't that how FOSS and linux works?
14:06.00DocScrutinizer05I think upstream not allowing somebody $random-hacker to wreck g_nokia is a sane thing
14:06.32DocScrutinizer05we would get into endless battles
14:06.44DocScrutinizer05ruining linux at large
14:07.31DocScrutinizer05but just like nobody may wreck g_nokia, nobody may forbid a concurrent g_maemo
14:07.37DocScrutinizer05that's the FOSS way
14:09.57DocScrutinizer05wonders why he didn't think that way when bitching against lis302 brainfxored upstream drivers
14:13.36*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
14:20.50*** join/#maemo-ssu cybertheque (~chatzilla@77.160.251.216.lan.static.cptelecom.net)
14:21.44cyberthequePerhaps what I want is SSU related...
14:22.04cyberthequeNokia-N900:/# /usr/bin/flasher --query-rd-mode --local
14:22.06cyberthequeflasher v2.8.2 (Jan  8 2010)
14:22.08cyberthequeUsing flashing protocol Mk II.
14:22.09cyberthequeFound device RX-51, hardware revision 2101
14:22.11cyberthequeMethod is not supported in the current mode
14:22.13cyberthequeHow to enable 'update' mode in the shell?
14:22.14cyberthequeThanks...
14:23.52*** join/#maemo-ssu discopig (~discopig@2001:5c0:1400:a::1381)
14:23.59*** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig)
14:28.03*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
14:29.00*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
14:33.09DocScrutinizer05you might try to start softupd
14:34.19DocScrutinizer05I dunno exactly but something is needed in addition to flasher to access the local NAND/CAL. However there are more direct simple ways to check for rd-mode than via flasher
14:34.36DocScrutinizer05NOT for setting R&D mode though
14:35.44DocScrutinizer05anyway check out KP package and how it manages to flash new kernel locally
14:35.53*** join/#maemo-ssu FlameReaper (~assassin@203.106.65.160)
14:36.29DocScrutinizer05you need to do similar "tricks" to get flasher --query-rd-mode --local working
14:36.38cyberthequek - will investigate.  my intention is to  hopefully enter the usb update mode from a shell command while logged in without needing to press the 'u' key and power cycle.  the mainboard is wired up on a test bench (no display) to a serial port interface so it is dangerous to physically manipulate it for flashing...
14:37.46jonwilQuestion, is there a reason why libc6 is not in CSSU?
14:38.07DocScrutinizer05you don't need to press the "U" key, NOLO will check for (external USB-attached) flasher to send a "Hello, here I am!" and that will serve as well for entering flashing mode
14:38.49cyberthequek - i will plug in the usb and see -- thanks
14:38.52DocScrutinizer05jonwil: well, prolly becasue it's considered high risk
14:39.09DocScrutinizer05~tell cyberthequeabout flashing
14:39.21DocScrutinizer05~tell cybertheque about flashing
14:40.31DocScrutinizer05cybertheque: there's a reason why the howto says "start flasher, *then* plug in USB to N900"
14:41.26DocScrutinizer05both ROMBL and NOLO will check for a fraction of a second if a "hello" message comes in via USB
14:42.01DocScrutinizer05if there does, they will enter flashing mode, just as if "U" been pressed
14:42.38DocScrutinizer05actually ROMBL not even checks for "U" (in case you want / need to do coldflash)
14:42.50cyberthequethanks, works
14:42.59cyberthequeConsole message seen is:
14:43.01cyberthequeNokia-N900:/# [44798.477172] g_nokia gadget: high speed config #1: nokia1
14:43.06DocScrutinizer05btw your description of what you do sounds intriguing. May I ask...?
14:43.09dos1~rombl
14:43.14cyberthequeflasher-3.5 connects
14:43.23DocScrutinizer05ROM base BOOTLOADER
14:43.39DocScrutinizer05or stage-0 bootloader
14:43.56dos1thx
14:44.06DocScrutinizer05the only bootloader you impossibly can ruin or mess up
14:44.42DocScrutinizer05it supports coldflashing to flash a new XLOADER and NOLO, if you ever manage to break them
14:45.39cyberthequei have a series of tests using the stock kernel with initrd on boot - need to load (not flash) these and view console messages.  At some point I will need to thoroughly understand the bootloader however and appreciate your comments.
14:45.53DocScrutinizer05dos1: check your PC's syslog, when plugging in a powered-down N900 to USB. First thing you see is ROMBL greeting
14:46.03*** join/#maemo-ssu FReaper (~assassin@183.171.169.249)
14:46.14cyberthequeexactly - i have installed a libusb dummy for ROMBL
14:46.22dos1I have to trust your words :)
14:47.37DocScrutinizer05second must be NOLO then, then 3rd which is linux kernel
14:48.52dos1xloader and nolo have to be signed, I guess?
14:49.45Palionly xloader is signed
14:49.50Palinolo is not signed on n900
14:50.30*** join/#maemo-ssu arcean_ (~arcean@aaen248.neoplus.adsl.tpnet.pl)
14:50.48DocScrutinizer05xloader
14:50.53DocScrutinizer05NOLO not
14:51.24DocScrutinizer05it would be xloader to check NOLO signature - it doesn't
14:51.44DocScrutinizer05ROMBL however checks xloader's signature
14:51.59dos1interesting
14:52.22DocScrutinizer05particularly interesting if N900 xloader could boot up N9
14:52.49Palino, because n9 has another signature
14:53.05Palialso different n9 hw revs have different signature
14:54.39DocScrutinizer05oooh right :-/
14:55.18Palimaybe different n900 hw revs have different signing key?
14:55.46DocScrutinizer05well, I doubt they have different ROMBL signature, since frequently you don't change ROMBL at all. But for sure 3630 SoC has a different ROMBL than 3430
14:56.23DocScrutinizer05the key is 2hardcoded" to the ROMBL
14:57.09DocScrutinizer05and I doubt N900 hw revs have changed ROMBL though they *may* have done this
14:57.36Palijonwil: if you have patches for libc6 which should be in CSSU, ask merlin for new repo and push changes
14:57.48cyberthequeI can query the device and reboot it but not load to it in this state. i don't suppose the ssu ever needs to simply load images rather than flashing them...
14:57.52DocScrutinizer05you could test by coldflashing with overriding hw code to another version
14:58.22Palicybertheque: I did not read full backlog, but do you want to boot n900 into "update" emmc mode?
14:58.37jonwilThe CSSU libc thing was in reference to things Nokia bundled with libc i.e. timezones
14:58.55cyberthequei just need to load images, not update (flash) them, without pressing the 'u' key and plugging/unpluggin the usb cable
14:58.58jonwili.e. the idea was to put Fremantle libc with newest timezone files in CSSU
14:59.20DocScrutinizer05cybertheque: loading images to RAM can be done by NOLO only, you need to physically reboot the system to give NOLO full control over the hw
14:59.46DocScrutinizer05in linux you'd do same via e.g. kexec
15:00.04DocScrutinizer05_not_ via NOLO load-to-ram mechanism
15:00.53cyberthequewhat do you suggest?  short of wiring a momentary contact switch to the 'u' key on the keyboard that i can press at a distance, is there a chance of doing it in software?
15:01.35DocScrutinizer05I elaborated on it some lines above - you don't need the 'U' key
15:02.11cyberthequei will re-read, but i believe that i did what you said, and i cannot load, only flash or query
15:02.16DocScrutinizer05you just need to make sure you _first_ start flasher, only _then_ plug N900 USB to PC
15:02.22Palicybertheque: if you want to load images, you need to connect n900 via usb
15:02.30cyberthequeit is connected by usb
15:02.40Paliand then use desktop flasher-3.5
15:02.53cyberthequedid that - start flasher-3.5 and then plug in the usb
15:03.02Paliflasher-3.5 -k <kernel_image> -l -b
15:03.03cyberthequewhile the n900 is booted into the o/s
15:03.22Palicybertheque: use linux version, open keyboard and press U
15:03.33Paliand after that connect usb
15:03.34DocScrutinizer05DAMN Pali ;-P
15:03.36cyberthequewhole idea is to avoid the need to press 'u'
15:03.42DocScrutinizer05^^^
15:03.56Paliok, then you need to start flasher and insert usb cable
15:04.02Paliand use linux version of flasher
15:04.19Paliand make sure that your battery is charged to full
15:04.45cyberthequeindeed - is the linux version different in capabilities then?  btw, the mainboard is powered externally (not depending on a battery)
15:04.52DocScrutinizer05or simply, read *full*
15:04.54DocScrutinizer05~flash
15:04.54infobotextra, extra, read all about it, maemo-flashing is http://wiki.maemo.org/Updating_the_tablet_firmware
15:05.34Paliwindows and mac systems has very slow usb enumeration, so you need to press U because win/mac does not see device on usb
15:05.46DocScrutinizer05yes, the linux version runs in an environment that's better understood
15:07.26DocScrutinizer05Pali: I don't even know if flasher relies on ENUM or just sends a hello-sequence to all USB endpoints all the time, to detect device
15:07.50cyberthequeok - linux flasher is next then.  so to clarify, while booted into the running o/s on the n900, i will be able to enter the loader's usb 'flashing' or 'update' mode, load images and reboot into them?  or can i perhaps simply switch the n900 to the 'update' mode while in the booted o/s, reboot, and have it talk to the external flasher to permit loading images at that point?
15:08.06DocScrutinizer05no
15:08.12Paliit doing infinite loop with some sleep() and asking kernel for enumerate devices and read usb device list
15:08.25DocScrutinizer05Pali: mhm, thanks
15:08.34Palimy 0xFFFF flasher doing same
15:08.40DocScrutinizer05:-)
15:08.56Palithere is no way to tell kernel: sleep process until device with this device id is present in usb...
15:10.22DocScrutinizer05cybertheque: for the 5th time: start flasher on PC, then plug in the powered down(!!!) N900, so it runs NOLO which will check for any hello-msg on USB sent by flasher. When such msg is detected during the sub-second time window, it enters flashing mode (resp "load-to-ram" mode)
15:10.34DocScrutinizer05no matter if U pressed or not
15:10.53cyberthequeok - powered down state - that was the missing ingredient.  thanks
15:11.08Palicybertheque: if host (desktop computer) send some hello message to n900, it will enter into NOLO flashing mode
15:11.23cyberthequegot it - was confused that it could do it while in the running state
15:12.02Palibut, there is "update" userspace mode
15:12.25Paliand in this runlevel you can flash eMMC
15:12.26DocScrutinizer05yes, but that probably can't load to RAM and boot that kernel
15:12.34Palino
15:12.42Paliin "update" mode is kernel already running
15:12.48DocScrutinizer05exactly
15:12.54Paliit is just classic linux runlevel
15:13.09DocScrutinizer05thus: use kexec when you plan to do such tricks from running system
15:13.24PaliI was just confused about "update" mode...
15:13.31DocScrutinizer05yeah
15:13.40DocScrutinizer05~xyawn
15:13.40infobothmm... xyawn is nap
15:13.45DocScrutinizer05DANG!!
15:13.52DocScrutinizer05~xyawn
15:13.52infoboti guess xyawn is big coffee
15:13.56DocScrutinizer05better
15:13.57Palithere is also "test" and "normal" runlevel modes
15:14.01cyberthequeok, did not work with the windows flasher, so will try with linux flasher next (just for the record)
15:14.28Palicybertheque: you can try my 0xFFFF flasher on linux (if flasher-3.5 will not work)
15:14.28DocScrutinizer05yeah, we toldya it will most likely not work with windows flasher
15:15.10cyberthequeok, thanks Pali - will try both
15:15.16Pali~0xFFFF
15:15.32DocScrutinizer05if it would work on all platforms, Nokia hadn't invented that clumsy "press and hold 'U'" trick
15:15.53Paliinfobot: 0xFFFF is https://gitorious.org/0xffff/
15:15.54infobotPali: okay
15:22.52cyberthequeok (don't flame me for using windows yet again) but i found a trick that worked.  1. start flasher-3.5 on windows (usb unplugged); 2. plug in usb with n900 in powerd down state; 3: n900 boots to o/s; 4: use power switch to power cycle n900; 5. n900 boots into a mode (have a complete console trace of it) that accepts the loading of the images
15:23.57cyberthequeand now i know from viewing the console log why my initrd didn't work before -- too large
15:24.50dos1I guess you could make a shortcut from 2 to 4
15:25.04dos1plug usb to already powered on n900 and then power cycle
15:25.19cyberthequewill try
15:25.59*** join/#maemo-ssu NIN101 (~NIN@p5DD28EC9.dip0.t-ipconnect.de)
15:33.06cyberthequedos1: required two power cycles with the shortcut and the device usb is enumerated in pc-suite mode on first power cycle so i guess the five step procedure is easier for me
15:33.15*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
15:33.19dos1strange
15:37.08cyberthequetried the 5 step procedure a few more times - works every time for me.  good to know - will save a lot of wear and tear on 30 ga wire harness to the board.
15:40.06*** join/#maemo-ssu freemangordon (~freemango@213.137.35.49)
15:40.42*** part/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net)
15:40.43cyberthequeBTW, for the record, running the stock o/s there is a time-out on the serial port of about five seconds after which the first input character is not recognized; i have gotten into the habit of typing the backspace key prior to any text input delayed more than five seconds.
15:42.41*** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net)
15:44.03DocScrutinizer05known issue, UART power-down timer
15:44.44DocScrutinizer05you can change the power-down timeout by writing to /sys/*/*/*/usart/power/timeout or similar sysnode
15:44.51cyberthequek - tnx
15:45.21*** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro)
15:52.14*** join/#maemo-ssu arcean_ (~arcean@aaen248.neoplus.adsl.tpnet.pl)
15:52.37cyberthequefor the record: Nokia-N900:~# cat /sys/devices/platform/serial8250.0/sleep_timeout
15:52.38cybertheque10
15:52.40cyberthequeNokia-N900:~# echo "20" > /sys/devices/platform/serial8250.0/sleep_timeout
15:52.41cyberthequeNokia-N900:~# cat /sys/devices/platform/serial8250.0/sleep_timeout
15:52.43cybertheque20
17:16.31*** join/#maemo-ssu arcean_ (~arcean@aaen248.neoplus.adsl.tpnet.pl)
17:28.29*** join/#maemo-ssu arcean_ (~arcean@aaen248.neoplus.adsl.tpnet.pl)
17:33.03*** join/#maemo-ssu xes (~xes@unaffiliated/xes)
18:07.49*** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr)
19:05.08*** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua)
19:14.30*** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua)
19:27.49*** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr)
19:36.56*** join/#maemo-ssu _rd (~rd@p5088F360.dip0.t-ipconnect.de)
20:11.28*** join/#maemo-ssu sunny_s (~sunny_s@178.124.152.19)
20:22.36*** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG)
20:48.01*** join/#maemo-ssu xes_ (~xes@unaffiliated/xes)
20:50.51*** join/#maemo-ssu xes (~xes@unaffiliated/xes)
21:11.04*** join/#maemo-ssu nox- (noident@freebsd/developer/nox)
21:17.14sixwheeledbeast~seen Pali
21:17.21infobotpali is currently on #maemo (12h 32m 47s) #harmattan (12h 32m 47s) #maemo-ssu (12h 32m 47s). Has said a total of 49 messages. Is idling for 2h 6m 52s, last said: 'DocScrutinizer05 ^^^^'.
21:17.59PaliI'm here
21:24.33sixwheeledbeasthi
21:28.42sixwheeledbeastso I have been fixing flopswap to use blkid and mount-ops-overwrite. works great on cssu-devel but I am not sure how to support older versions that don't support new mount-ops.
21:34.23DocScrutinizer05haha
21:35.07DocScrutinizer05clearly fell for the convenience trap
21:48.21sixwheeledbeastmhm
21:57.33sixwheeledbeastwhen I say "support", I mean how to tell flopswap to do "something else" because mount-ops-overwrite is not supported on this device.
22:01.35sixwheeledbeast"something else" being fallback to "$swap0" (device swap in blkid) at boot.
22:23.49*** join/#maemo-ssu xes_ (~xes@unaffiliated/xes)
22:29.51DocScrutinizer05err, cehck for presence of some unique file?
22:32.09DocScrutinizer05if CSSU doesn't support a way to detect presence of the feature, I'd honestly open a ticket against that
22:32.51*** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz)
22:35.44*** join/#maemo-ssu xes (~xes@unaffiliated/xes)
22:36.06*** join/#maemo-ssu dhbiker (~dhbiker@193.2.218.150)
22:44.16DocScrutinizer05I mean, what worth is a feature when you don't provide a method to check for its presence
22:44.40DocScrutinizer05hostmode kernel exports a feature "hostmode"
22:45.17DocScrutinizer05I honestly hope thumb enabled kernel provides a feature "thumbified"
23:52.22FatPhilpali: (and yes, I know you're not online right now) - I vaguely remember some failure-to-wake-up bug to do with the crypto accelleration, but that was probably in a n950 context
23:55.10FatPhiland I presume the slowness was due to things being chopped into too many too-small chunks, so that the overhead communicating with the security subsystem was too high. THat's just a guess.
23:56.00freemangordonDocScrutinizer05: for sure it does, kernel-errata-xxx-workaround
23:56.22DocScrutinizer05:-)
23:56.29FatPhilI think they got it working on the n9 eventually. (I seem to remember the patches went physically through my hands, and I'm pretty sure I remember who wrote them, and I sit at a desk next to him for 2 more weeks)
23:57.11DocScrutinizer05failure-to-wake-up? sounds like the secret SiErr in IMAP4
23:57.21DocScrutinizer05OMAP even
23:58.02*** join/#maemo-ssu n900-dk (~kgu@freebox.dk)
23:58.36freemangordonguys, any idea what to check for if I get wake-up events on gpois, but no irqs?
23:58.57freemangordons/irqs/interrupts
23:59.00DocScrutinizer05what means "wake-up event"?
23:59.55freemangordon"WAKEUPEVENT: Wake-up event status for the pin."

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.