**** BEGIN LOGGING AT Tue Jan 03 03:00:01 2017
Jan 03 03:11:12 <buZz> ~lazyflashing
Jan 03 03:11:12 <infobot> [lazyflashing] http://wiki.maemo.org/Updating_the_tablet_firmware#The_Lazy_Approach
Jan 03 03:57:44 <DocScrutinizer05> ~tabletsdev
Jan 03 03:57:45 <infobot> rumour has it, tabletsdev is http://tablets-dev.nokia.com/  http://wiki.maemo.org/Tabletsdev ,  http://tabletsdev.maemo.org (all defunct, thanks Nokia) or the nice site http://www.fladnag.net/downloads/telephone/n900/tools/, or http://www.mmnt.net/db/0/0/93.81.63.203/repositories/skeiron.org/skeiron.org/tablets-dev/maemo_dev_env_downloads, or http://maemo.muarf.org/tablets-dev/maemo_dev_env_downloads/
Jan 03 12:29:16 <KotCzarny> random rant: ca-certificates package is incompatible with 'find' 4.1, installing findutils-gnu and making it default made it install
Jan 03 12:31:56 <Oksanaa> Random find: if Telepathy doesn't wish to load backlog from el-v1.db in ~/.rtcom-eventlogger directory, it may help to .dump the sqlite3 database into an sql file, and then -init from the sql file into new database file.
Jan 03 12:32:11 <bencoh> hm, interesting
Jan 03 12:36:13 <Oksanaa> In my case, the problem was because of a block of several hundreds of NULL everything events. Vacuum; said that constraint failed, so instead of vacuuming, did sqlite3 el-v1.db and .output db.sql .dump .exit and sqlite3 -init db.sql el-v1.db . Of course, anything and everything capable of editing el-v1.db has to be taken down while tampering. And always make backups!
Jan 03 12:37:57 <Oksanaa> Like a line goes VALUES( NULL, NULL, NULL, ... NULL, NULL ) and so on; 88 identical useless lines.
Jan 03 12:39:00 <Oksanaa> When I was init-ing from db.sql, got SQL error near line 83046-83134: Events.service_id may not be NULL
Jan 03 12:56:01 <DocScrutinizer05> ls -l 
Jan 03 12:56:45 <DocScrutinizer05> du -sh ~/.rtcom-eventlogger   should be < 1MB
Jan 03 12:57:36 <DocScrutinizer05> mine already is 1.6MB again :-/
Jan 03 13:01:02 <Oksanaa> 14.5MB lol
Jan 03 13:01:57 <Oksanaa> And yes, it works, but backscrolls can be trouble
Jan 03 13:02:12 <Oksanaa> As in, too much to scroll through 
Jan 03 13:05:41 <DocScrutinizer05> the problem is those 14MB can give the device swap hell for (my guess) up to 20s on every event
Jan 03 13:06:27 <DocScrutinizer05> it needs to swap out 14MB of other stuff and read in 14MB of sql db
Jan 03 13:06:49 <DocScrutinizer05> so odds are your call has finished when you get along to answer it
Jan 03 13:07:52 <DocScrutinizer05> tbh I'm surprised you still consider the device operable
Jan 03 13:16:26 <DocScrutinizer05> make a printout or whatever of your precious historical SMS etc, then simply delete the complete content of ~user/.rtcom-eventlogger -- it will be a shock how different the device suddenly feels
Jan 03 13:17:19 <DocScrutinizer05> don't forget to re-install the call duration SQL functions!
Jan 03 13:17:36 <DocScrutinizer05> ~jrtools
Jan 03 13:17:37 <infobot> extra, extra, read all about it, jrtools is http://wiki.maemo.org/User:Joerg_rw/tools
Jan 03 13:18:52 <DocScrutinizer05> >># execute or source this to fix the missing end-times in eventslogger db<<
Jan 03 13:19:37 <DocScrutinizer05> ## find original at http://maemo.cloud-7.de/maemo5/patches_n_tools/eventsdb_calllog_triggers.sh
Jan 03 13:20:27 <DocScrutinizer05> hint: I copied that shellscropt to my /usr/local/bin
Jan 03 13:22:58 * DocScrutinizer05 idly wonders if this shouldn't go into CSSU, with an init script to execute it during each boot
Jan 03 13:25:22 <DocScrutinizer05> IroN900:~# time /usr/local/bin/eventsdb_calllog_triggers.sh
Jan 03 13:25:23 <DocScrutinizer05> real    0m0.827s
Jan 03 13:25:25 <DocScrutinizer05> user    0m0.031s
Jan 03 13:25:26 <DocScrutinizer05> sys     0m0.023s
Jan 03 13:32:33 <DocScrutinizer05> after all it's a glaring bug in ... whatever Nokia core function, maybe caller-ui, maybe telepathy-foo, maybe csd or whatever
**** BEGIN LOGGING AT Tue Jan 03 13:47:11 2017
Jan 03 13:56:36 <sicelo-> DocScrutinizer05: after running that, it is needed to reboot the device? or there can be other way?
Jan 03 13:59:08 <KotCzarny> do lsof to see if anything is using that file, then kill those apps, otherwise no need, i guess
Jan 03 14:01:31 <DocScrutinizer05> sicelo-: what? the sql script? it 'just works'
Jan 03 14:02:36 <DocScrutinizer05> I'm not 100% sure the triggers will be live for all apps using the db
Jan 03 14:03:07 <DocScrutinizer05> but they will not cause any trouble and after next boot for sure everything 100% OK
Jan 03 14:03:19 <sicelo-> what is the purpose of the script exactly? :)  .. i remember reading about it years ago, but at the time i didn't feel like using it
Jan 03 14:04:23 <sicelo-> iow, what's the bug we're working around?
Jan 03 14:04:41 <KotCzarny> mem hog on every call history open?
Jan 03 14:05:01 <KotCzarny> assuming that db has grown too much
Jan 03 14:05:18 <sicelo-> i don't ever remember having that .. just checked now my db is 2MB+
Jan 03 14:06:40 <sicelo-> i'll use it and see if it improves anything
Jan 03 14:08:41 <sicelo-> my N900 seems to have problem with 3G/GPRS now .. i can't tell if my providers are using frequency bands N900 does not support, or what. The problem is only with Internet use, not calls, so I don't think i have the dreaded SIM issue yet
Jan 03 14:17:14 <bencoh> data doesn't work with either of them?
Jan 03 14:22:51 <sicelo-> yes, now i've just done a test, and i'm absolutely sure that the SIM is fine on SGS4. N900 activates the connection just fine, but no data flows :-/
Jan 03 14:23:31 <KotCzarny> but you get ip or not even that?
Jan 03 14:23:49 <bencoh> mtr, proxy stuff ?
Jan 03 14:24:16 <bencoh> (I mean, did you try mtr some destination ? did you check proxy config on the samsung?)
Jan 03 14:24:39 <sicelo-> no. the SIM has always worked before. and yes, i get IP
Jan 03 14:25:04 <KotCzarny> they try tcpdump and pinging 8.8.8.8 for example (google's ns)
Jan 03 14:25:13 <sicelo-> no dice :)
Jan 03 14:25:31 <KotCzarny> pastebin your ifconfig/route
Jan 03 14:25:31 <sicelo-> works on 2G, but not 3G
Jan 03 14:26:52 <bencoh> fun ... first time I tried using data on my n900 / provider, 2G didn't work
Jan 03 14:27:21 <bencoh> I had to switch to 3g and open a data connect, then switch back to 2g
Jan 03 14:27:21 <sicelo-> problem is that no providers here tell you what frequencies they use .. need voodoo to know
Jan 03 14:27:53 <sicelo-> is there a way to find this on N900? although i doubt ..
Jan 03 14:28:57 <sicelo-> but, if it was frequencies, then i don't understand why they connection gets established and then no data :-/
Jan 03 14:29:05 <KotCzarny> https://en.wikipedia.org/wiki/Nokia_N900
Jan 03 14:29:12 <sicelo-> 2G only seems fine, but not so nice
Jan 03 14:29:15 <KotCzarny> see connectivity in the table on the right
Jan 03 14:29:27 <bencoh> sicelo-: I mainly use 2G here
Jan 03 14:29:29 <sicelo-> yes KotCzarny ... i meant - can i see what frequency i'm connecting with?
Jan 03 14:29:29 <bencoh> but still :)
Jan 03 14:29:39 <KotCzarny> it should be automatic
Jan 03 14:29:48 <KotCzarny> but they might do as you suspect
Jan 03 14:29:48 <sicelo-> :)
Jan 03 14:29:56 <KotCzarny> for example 2100 for umts
Jan 03 14:30:10 <KotCzarny> oh, its supported
Jan 03 14:30:12 <KotCzarny> :)
Jan 03 14:30:32 <KotCzarny> https://en.wikipedia.org/wiki/UMTS_frequency_bands
Jan 03 14:30:34 <sicelo-> yes, i think one of them uses 850 UMTS .. which we definitely don't support on N900 
Jan 03 14:30:38 <KotCzarny> but there is plenty of them
Jan 03 14:31:23 <KotCzarny> but that table lists only 2100 and 900 for africa
Jan 03 14:31:52 <sicelo-> i don't think all of them are accurate in that table
Jan 03 14:32:05 <KotCzarny> https://en.wikipedia.org/wiki/List_of_UMTS_networks
Jan 03 14:32:09 <KotCzarny> another nice table
Jan 03 14:33:42 <KotCzarny> they might've moved to lte too, thought its unlikely
Jan 03 14:34:39 <KotCzarny> The Cell C network operates on three key bands 900 MHz, 1800 MHz and 2100 MHz.
Jan 03 14:36:08 <sicelo-> i don't use that .. i've been using Telkom, and VodaCom, plus FNB (which is an MNVO) .. i wanted to port the FNB number to Telkom as well (telkom has the best prepaid deals for data) .. but it is telkom that has 850MHz for UMTS .. talk about perfect conditions
Jan 03 14:37:00 <bencoh> huhu
Jan 03 14:38:16 <Vajb> hmm 6.3mb file, maybe i'll try the medicine doc suggested
Jan 03 14:41:10 <sicelo-> KotCzarny: https://mybroadband.co.za/vb/showthread.php/863350-Telkom-3G-850MHz-Band-Only  ... the other guy thinks Telkom uses same bands as everyone else ... looks like he's just guessing though, as N900 definitely does not even attempt a UMTS connection on that network
Jan 03 14:41:14 <sicelo-> :(
Jan 03 14:41:24 <KotCzarny> https://www.frequencycheck.com/carriers/vodacom-south-africa
Jan 03 14:41:37 <KotCzarny> according to that they should have umts on 2100
Jan 03 14:42:18 <sicelo-> yes VodaCom is the best network here :) most expensive too
Jan 03 14:43:14 <sicelo-> anyway, i think i'll have to get a good battery on the SGS4 or power bank .. put the Telkom in it, and use WiFi hotspot 
Jan 03 14:46:24 <bencoh> oO
Jan 03 14:47:12 <bencoh> sicelo-: does it even open the umts data session?
Jan 03 14:47:45 <sicelo-> on the telkom, no. on the fnb it does, but for a weird reason no data flows
Jan 03 14:47:55 <KotCzarny> sicelo: what ip do you have?
Jan 03 14:47:59 <KotCzarny> on n900?
Jan 03 14:49:12 <sicelo-> the telkom causes N900 to prompt for roaming if you insist on 3G ... telkom has roaming agreement with MTN .. so you can have 3G when it connects to that .. but the switchover has not been stable lately (prompting me to even check this)
Jan 03 14:49:52 <sicelo-> KotCzarny: regular NATted IP, 10.43.208.150/32 currently
Jan 03 14:50:04 <bencoh> sicelo-: data is shown as roaming here as well
Jan 03 14:50:09 <KotCzarny> try pinging the gateway?
Jan 03 14:50:54 <sicelo-> bencoh: but on the FNB, no need to roam for 3G (except no data flows, haha)
Jan 03 14:51:13 <bencoh> sicelo-: misconfig on their side maybe?
Jan 03 14:51:35 <sicelo-> possible... no idea. the SGS4 has no problem with that SIM however
Jan 03 14:51:49 <KotCzarny> maybe they've changed apn settings, compare with sgs4?
Jan 03 14:52:18 <sicelo-> APN is correct .. they autosend you each time you swap SIM
Jan 03 14:52:52 <bencoh> or unsupported carrier frequency for their home network as you suggested
Jan 03 14:53:22 <sicelo-> that's what it really looks like to me
Jan 03 14:53:36 <KotCzarny> http://android.stackexchange.com/questions/23572/how-to-tell-current-frequency-band
Jan 03 14:55:12 <sicelo-> nice one .. brings me back to  .. i wonder if we can figure that out on N900
Jan 03 14:55:58 <bencoh> I think we can
Jan 03 14:56:03 <bencoh> did you try cellnet-info?
Jan 03 14:56:04 <sicelo-> at least i have a Plan B
Jan 03 14:56:10 <sicelo-> yes, i have it
Jan 03 14:56:27 <sicelo-> doesn't show frequencies however
Jan 03 14:56:49 <sicelo-> maybe i should look for other similar applications
Jan 03 15:27:43 <DocScrutinizer05> sicelo-: ((what is the purpose of the script exactly?)) the involved processes fail to fill in the "end of call" timestamp to the database. The script adds a few stored procedures (a SQL thing) that fix this 
Jan 03 15:28:06 <DocScrutinizer05> it's not related to size of database at all
Jan 03 15:29:26 <DocScrutinizer05> sicelo-: (data) check your APN settings
Jan 03 15:31:31 <DocScrutinizer05> ooh you had that already
Jan 03 15:33:48 <DocScrutinizer05> sicelo-: please consider to doublecheck APN against a working phone, it's possible N900 doesn't correctly use the >>autosend you each time you swap SIM<< data
Jan 03 15:34:43 <DocScrutinizer05> for checking frequency band please install and start netmon app
Jan 03 15:35:21 <DocScrutinizer05> no idea about sgs4 and similar apps there
Jan 03 15:37:52 <DocScrutinizer05> sicelo-: braindead providers may opt out of UMTS completely, to re-use same band for LTE
Jan 03 15:38:23 <sicelo-> KotCzarny: that last link is helpful, and unearthing interesting information.
Jan 03 15:38:54 <DocScrutinizer05> the SGS4 is LTE
Jan 03 15:38:59 <sicelo-> no
Jan 03 15:39:12 <sicelo-> at least not mine, i9500
Jan 03 15:39:20 <sicelo-> i'm instaling netmon on N900
Jan 03 15:40:04 <DocScrutinizer05> www.gsmarena.com/samsung_i9505_galaxy_s4-5371.php
Jan 03 15:40:29 <KotCzarny> i9505 != i9500
Jan 03 15:40:35 <DocScrutinizer05> oh wait, 9505
Jan 03 15:41:12 <DocScrutinizer05> http://www.gsmarena.com/samsung_i9500_galaxy_s4-5125.php yeah no LTE
Jan 03 15:41:46 <sicelo-> yes
Jan 03 15:42:45 <sicelo-> netmon gives same info as cellnet-info (a bit less actually)
Jan 03 15:44:57 <sicelo-> funny enough, looks like most of the providers here support CSD according to N900 ... i wonder if they would give me settings for that (not that N900 supports it though .. i think symbian 9500 supported it)
Jan 03 15:45:25 <KotCzarny> csd is net over gsm, are you really sure you want it?
Jan 03 15:45:49 <sicelo-> no. just interesting that it is still enabled/available
Jan 03 15:46:20 <sicelo-> i doubt anyone at the telco would even know the settings :p
Jan 03 15:47:38 <sicelo-> DocScrutinizer05: maybe pnatd could reveal freq. band?
Jan 03 15:49:15 <DocScrutinizer05> I think pnatd is *very* limited/crippled subset of even the minimal mandatory commandset according to 3GPP. So no
Jan 03 15:49:42 <DocScrutinizer05> but netmon shows the band, you just need to look up the channel number
Jan 03 15:49:57 <DocScrutinizer05> channel numbers are unique
Jan 03 15:50:09 * sicelo- looks again
Jan 03 15:51:19 <DocScrutinizer05> ugh, I dreamt that up
Jan 03 15:52:40 <DocScrutinizer05> TNC ID is freq encoded iirc, but RNC is only defined for 3G
Jan 03 15:52:54 <DocScrutinizer05> s/TN/RN/
Jan 03 15:52:54 <infobot> DocScrutinizer05 meant: RNC ID is freq encoded iirc, but RNC is only defined for 3G
Jan 03 15:55:33 <DocScrutinizer05> nope, neither
Jan 03 16:06:00 <DocScrutinizer05> http://wstaw.org/m/2017/01/03/plasma-desktopS17764.png  http://wstaw.org/m/2017/01/03/plasma-desktopS17764_1.png
Jan 03 16:06:17 <DocScrutinizer05> I'm pretty sure pnatd doesn't know either of those
Jan 03 16:06:44 <DocScrutinizer05> prolly ^SCFG isn't even 3GPP
Jan 03 16:06:55 <DocScrutinizer05> but ptoprietary
Jan 03 16:08:07 <DocScrutinizer05> anyway FWIW  http://wstaw.org/m/2017/01/03/plasma-desktopE17764.png
Jan 03 16:11:58 <DocScrutinizer05> sicelo-: maybe from cellid you can conclude band via http://wiki.opencellid.org/wiki/View_the_data
Jan 03 16:44:04 <Vajb> DocScrutinizer05: should ur call log script provide some output or not?
Jan 03 16:44:27 <KotCzarny> vajb: in sql no output is usually good sign
Jan 03 16:44:29 <KotCzarny> ;)
Jan 03 16:44:54 <Vajb> well for me it gives output
Jan 03 16:45:19 <Vajb> Incomplete SQL: ETX
Jan 03 16:45:31 <KotCzarny> bad paste?
Jan 03 16:46:05 <Vajb> hmm lemme check how it looks in my file
Jan 03 16:47:03 <Vajb> seems complete to me
Jan 03 16:47:44 <Vajb> and as i copy pasted it, it is kinda impossible for something to be missed inbetween.
Jan 03 16:48:39 <KotCzarny> well, web browser suck sometimes
Jan 03 16:48:52 <KotCzarny> try wget http://maemo.cloud-7.de/maemo5/patches_n_tools/eventsdb_calllog_triggers.sh then diff both files
Jan 03 16:49:40 <KotCzarny> that etx is part of the bash and should go into sql , so you definitely pasted wrong
Jan 03 16:50:37 <KotCzarny> yup, just tried, no output
Jan 03 16:51:30 <Vajb> well i'll be darned if i know what i missed, but with wget'ed file no output
Jan 03 16:51:56 <KotCzarny> just hope you didnt f*cked something :>
Jan 03 16:52:11 <KotCzarny> but script should work around that with dropping funcs first
Jan 03 16:52:31 <KotCzarny> vajb: do diff command on both files
Jan 03 16:52:36 <KotCzarny> ie. diff -u file1 file2
Jan 03 16:52:41 <KotCzarny> you will see the difference
Jan 03 16:53:01 <Vajb> hmm need to install diff first it seems
Jan 03 16:56:28 <Vajb> hmm now im missing something
Jan 03 16:57:02 <Vajb> it says that diff is included in bash3 but when i try to run it in bash it says it is not found
Jan 03 16:57:10 <Vajb> i'll look by eye
Jan 03 16:57:26 <KotCzarny> try gdiff
Jan 03 16:57:35 <KotCzarny> if you installed diffutils-gnu or something
Jan 03 16:59:51 <Vajb> i think only difference is that my paste didn't have empty line after last line
Jan 03 17:00:16 <KotCzarny> apparently those file endings are importantes ;)
Jan 03 17:01:13 <Vajb> wellll for me empty line is like empty line :)
Jan 03 17:05:24 <Vajb> gdiff did the trick \ No newline at end of file
Jan 03 17:15:08 <sicelo-> you could have used wget on the N900 (that's what i did) 
Jan 03 17:36:51 <Vajb> sicelo-: well i did at the second run
Jan 03 17:37:19 <Vajb> wget is something which doesn't just pop in to my mind :)
Jan 03 17:37:42 <KotCzarny> its one of those most-required tools for me
Jan 03 17:38:10 <KotCzarny> and copy pasting from browser usually breaks things
Jan 03 17:39:21 <Vajb> i'll try to keep that in mind
Jan 03 19:25:34 <sicelo-> i think this is not optified - http://maemo.org/packages/view/python-matplotlib/ .. any way to be absolutely sure without installing?
Jan 03 19:25:55 <KotCzarny> run mc then just enter the archive
Jan 03 19:26:01 <KotCzarny> and check what is in contents
Jan 03 19:27:40 <sicelo-> no mc here :)
Jan 03 19:27:55 <sicelo-> but i'm looking for /opt directories inside?
Jan 03 19:27:56 <KotCzarny> it's another one-of-those-essential-tools of mine
Jan 03 19:28:15 <KotCzarny> you are looking what goes NOT in /opt
Jan 03 19:28:21 <KotCzarny> if its <200kB then its fine
Jan 03 19:28:33 <KotCzarny> you can unpack debs by ar x some.deb
Jan 03 19:28:45 <KotCzarny> then unpacking tar.gz inside
Jan 03 19:28:56 <KotCzarny> do it in subdir for cleanliness
Jan 03 19:29:31 <sicelo-> no /opt directories in that :(
Jan 03 19:29:42 <KotCzarny> you can also check scripts in debian subdir
Jan 03 19:29:50 <KotCzarny> maybe they move data around
Jan 03 19:29:56 <KotCzarny> or make symlinks
Jan 03 19:32:00 <sicelo-> no dice .. this sucks .. apt calculates that installing it will use 40.1MB
Jan 03 19:32:14 <KotCzarny> definitely a bug then
Jan 03 19:32:29 <KotCzarny> if you have 40MB spare on rootfs you can check by installing anyway
Jan 03 19:33:25 <sicelo-> last check i had only 19MB :p
Jan 03 19:33:38 <KotCzarny> rootfs                  233344    172668     56396  75% /
Jan 03 19:33:40 <KotCzarny> hah :P
Jan 03 19:34:12 <KotCzarny> and i even have gcc on device
Jan 03 19:35:28 <sicelo-> actually shows 17.2MB at this moment
Jan 03 19:35:48 <sicelo-> lots of cruft i have collected over the years
Jan 03 19:36:21 <KotCzarny> you can check my slimming recipe https://wiki.maemo.org/Slimming_OS
Jan 03 19:36:54 <sicelo-> ~seen lardman
Jan 03 19:36:57 <infobot> lardman <~Simon@81.145.107.243> was last seen on IRC in channel #maemo, 516d 20h 55m 23s ago, saying: 'night all'.
Jan 03 19:37:19 <sicelo-> i believe i've done most of that
Jan 03 19:39:41 <KotCzarny> i have 1906 packages installed
Jan 03 19:40:05 <sicelo-> 2239 for me
Jan 03 19:40:18 <KotCzarny> you might consider uninstalling some
Jan 03 19:40:32 <KotCzarny> and dont forget to purge while uninstalling
Jan 03 19:40:46 <KotCzarny> also check dpkg -l|grep ^rc
Jan 03 19:41:04 <KotCzarny> that cruft can sometimes stay behind
Jan 03 19:42:25 <sicelo-> i think i use most of them ;)
Jan 03 19:42:30 <sicelo-> will check again
Jan 03 19:44:51 <sicelo-> there were some python scripts on tmo to audit roofs usage .. will rerun that too
Jan 03 19:45:41 <sicelo-> but i've generally had no issue with the amount of space on my rootfs
Jan 03 19:47:17 <sicelo-> i also have syslog, but i have a daily job (runs at midnight) that rotates the logs and deletes old ones
Jan 03 19:47:32 <KotCzarny> um, logs?
Jan 03 19:48:13 <KotCzarny> if you want logs symlink /var/log onto /opt or somewhere in mydocs
Jan 03 19:48:13 <sicelo-> yes .. they can get large sometimes
Jan 03 19:55:16 <sicelo-> my 2nd N900 has 74MB free, 67% use
Jan 03 20:08:07 <enyc> hrrm, Is there any cure//workaround for n900-maemo taking ages to get to the point of mounting /media/mmc1 and /home/user/MyDocs ?  -- could be fixing symtomn rather than cause etc...??
Jan 03 20:08:29 <KotCzarny> what filesystems?
Jan 03 20:08:46 <enyc> ext4 and vfat
Jan 03 20:08:47 <KotCzarny> if you converted them to ext2 it could be fsck
Jan 03 20:09:02 <KotCzarny> vfat should mount quick
Jan 03 20:09:10 <enyc> It consistently takes ages...
Jan 03 20:09:37 <KotCzarny> pastebin output of mount and dmesg -s 999999
Jan 03 20:09:46 <enyc> ext4 fsck isn't slow and journal recovery normaly makes unnecessary...
Jan 03 20:09:52 <sicelo-> what are your reasons for rebooting by the way?
Jan 03 20:11:13 <enyc> sicelo-: changing batteries?   not been on for ages and turning on...?   I'm not a person for constantly having phone-type-things......
Jan 03 20:12:20 <sicelo-> you might actually find that you remove the battery before N900 is really off .. therefore as KotCzarny, your fs is considered dirty and a fsck ensues
Jan 03 20:13:00 <KotCzarny> cssu feature request: make led code for 'shutting down'
Jan 03 20:13:12 <sicelo-> +1
Jan 03 20:14:08 <KotCzarny> maybe steady pink?
Jan 03 20:15:17 <sicelo-> there is led for that, but it doesn't last long enough  ..
Jan 03 20:15:30 <KotCzarny> wonder what turns it off
Jan 03 20:15:55 <enyc> sicelo-: i can doublecheck but this seems ffairly consistent reg,ardless
Jan 03 20:16:05 <sicelo-> it's how the pattern is defined .. you can extend the time in LED Patterns
Jan 03 20:16:52 <sicelo-> enyc: i once had that situation actually .. what was happening was - n900 fsck could not repair my system, so each time i had an fsck on reboot
Jan 03 20:17:11 <sicelo-> check in (h)top and see if that's not your problem
Jan 03 20:17:23 <KotCzarny> enyc: mount and dmesg after reboot
Jan 03 20:24:39 <Oksanaa> About fsck : auto-done fsck seems to miss one of flags, and hence redo " let's repair MyDocs " on each startup, till user does fsck manually ( and then fs will be right as rain, and need not an fsck on startup ). At least, that's my impression.
Jan 03 20:25:15 <Oksanaa> Does app manager purge packages when uninstalling them?
Jan 03 20:25:39 <KotCzarny> im only using app manager to install root and ssh
Jan 03 21:07:48 <sicelo-> which one is better/recommended - rootsh or sudo?
Jan 03 21:07:51 <sicelo-> or both
Jan 03 21:08:00 <KotCzarny> i prefer rootsh
Jan 03 21:08:15 <KotCzarny> but that's personal, if you tend to do stupid mistakes, go for sudo
Jan 03 21:09:19 <sicelo-> i've now freed almost 10MB rootfs
Jan 03 21:09:41 <DocScrutinizer05> huh?? shutdown LED?
Jan 03 21:11:17 <Oksanaa> Shutdown LED pattern is important, yes.
Jan 03 21:15:04 <DocScrutinizer05> Python-Matplotlib 1.0.0-1 os _not_ optified
Jan 03 21:16:09 <DocScrutinizer05> ((sicelo-> it's how the pattern is defined .. you can extend the time in LED Patterns)) yes exactly. As straight forward and simple as it possibly gets
Jan 03 21:16:48 <DocScrutinizer05> I changed the pattern (with LED pattern editor) to simply not fade all the way down to off
Jan 03 21:17:03 <DocScrutinizer05> *very* handy
Jan 03 21:17:16 <KotCzarny> it might be last command that switches led color from red to greenish after all fs' are umounted/ro
Jan 03 21:17:21 <KotCzarny> why is this not in cssu?
Jan 03 21:18:20 <DocScrutinizer05> PatternPowerOff=10;3;0;rgb;9d80400001ff439e7f007e00c000;9d800000
Jan 03 21:18:56 <DocScrutinizer05> grep PatternPowerOff /etc/mce/mce.ini
Jan 03 21:20:44 <KotCzarny> hmm
Jan 03 21:20:56 <KotCzarny> there are multiple sections with that string
Jan 03 21:21:14 <KotCzarny> its lystirx51 ?
Jan 03 21:21:20 <DocScrutinizer05> yes
Jan 03 21:21:45 <DocScrutinizer05> sorry I forgot I cleaned my mce.ini from that legacy cruft
Jan 03 21:22:33 <DocScrutinizer05> [LEDPatternLystiRX51]
Jan 03 21:24:04 <DocScrutinizer05> wtf is PatternInhibit
Jan 03 21:24:30 <DocScrutinizer05> # Added on 2011-02-15T18:03:44.231080Z by mceledpattern
Jan 03 21:24:31 <DocScrutinizer05> PatternInhibit=0;5;0;r;9d8040007f007f0040ff7f007f000000;9d800000
Jan 03 21:30:37 <DocScrutinizer05> http://maemo.cloud-7.de/maemo5/etc/mce/
Jan 03 21:34:13 <DocScrutinizer05> for rootsh (and sudo) see ~jrtools to sanitize the password config
Jan 03 21:35:30 <DocScrutinizer05> or, if you wanna go leete hax0r, use ssh root@localhist
Jan 03 21:35:44 <DocScrutinizer05> *host even
Jan 03 21:36:57 <DocScrutinizer05> Oksanaa: HAM doesn't purge
Jan 03 21:37:14 <DocScrutinizer05> at least afaik, in default settings
Jan 03 21:40:32 <DocScrutinizer05> enyc, check fs with fsck
Jan 03 21:40:50 <DocScrutinizer05> see what's the initial state and what's the result
Jan 03 21:49:35 <DocScrutinizer05> enyc: often it's smarter (and waaaaaaaaay faster) to reflash emmc than to try and fix a corrupted fs via fschk
Jan 03 21:49:56 <DocScrutinizer05> I heard of instances where fsck literally took several days
Jan 03 21:50:26 <DocScrutinizer05> and even more often it never manages to fix a corruption
Jan 03 21:51:41 <DocScrutinizer05> still a rarge occurance compared to the usually flawless fixing of an unclean umount, but... when it happens to you, you're prolly better off just backup your data and reflash (or mkfs.vfat)
Jan 03 21:53:12 <DocScrutinizer05> Oksanaa: ((auto-done fsck seems to miss one of flags)) wouldn't feel too surprised to learn that's true
Jan 03 21:53:39 <DocScrutinizer05> Nokia and CSSU messed a lot with fsck
Jan 03 21:54:42 <DocScrutinizer05> and for very sound reasons, no thorough check ever been done as to how effective the fsck implementation actually is for fixing a corrupted fs
Jan 03 21:55:29 <DocScrutinizer05> just nobody really wants to deliberately fuckup their fs just to test if fsck can fix it ;-)
Jan 03 21:56:15 <DocScrutinizer05> ask Pali, iirc he was last one to touch that stuff, in CSSU
**** ENDING LOGGING AT Wed Jan 04 03:00:01 2017