IRC log of #maemo for Monday, 2017-07-17

*** xy2_ has quit IRC00:29
*** xy2_ has joined #maemo00:29
*** geaaru has quit IRC00:32
*** louisdk has quit IRC01:09
*** xes_ is now known as xes01:13
*** xy2_ has quit IRC01:46
*** Pali has quit IRC01:58
*** xorly has quit IRC02:12
*** valdyn has quit IRC02:21
*** valdyn has joined #maemo02:21
*** Kilroo has quit IRC02:27
*** valdyn has quit IRC02:27
*** valdyn has joined #maemo02:33
*** Kilroo has joined #maemo02:37
*** Kilroo has quit IRC02:42
*** florian has quit IRC02:45
*** Kilroo has joined #maemo02:57
*** atk has quit IRC03:00
*** atk has joined #maemo03:00
*** CrKit has joined #maemo03:16
*** infobot has quit IRC03:18
*** infobot has joined #maemo03:19
*** dreamer has quit IRC03:34
*** dreamer has joined #maemo03:36
*** Kabouik has joined #maemo04:01
*** Kabouik_ has joined #maemo04:29
*** Kabouik has quit IRC04:32
*** CrKit has quit IRC04:39
*** keithzg_ has joined #maemo05:03
*** cyteen has quit IRC05:18
*** KotCzarny has quit IRC06:13
*** mike727 has joined #maemo06:17
*** pagurus` has joined #maemo06:23
*** pagurus has quit IRC06:24
*** KotCzarny has joined #maemo06:27
mike727Anyone tried "shake to wake" ( I guess it would exhaust resources/battery?06:29
*** Oksana has quit IRC07:39
*** Oksana has joined #maemo07:42
*** kalin has joined #maemo08:11
*** dafox has joined #maemo08:55
*** florian has joined #maemo09:25
*** dmth|intevation has joined #maemo09:30
*** dafox has quit IRC09:40
*** florian has quit IRC09:55
*** louisdk has joined #maemo10:02
*** xorly has joined #maemo10:04
*** geaaru has joined #maemo10:30
*** jskarvad has joined #maemo10:46
*** jskarvad has quit IRC10:46
*** jskarvad has joined #maemo10:46
*** jskarvad has joined #maemo10:46
*** florian has joined #maemo10:48
*** eMHa has quit IRC10:52
*** NeKit has joined #maemo10:54
*** hurrian_ has quit IRC10:58
*** hurrian has joined #maemo10:59
*** NeKit has quit IRC11:03
*** hurrian has quit IRC11:04
*** eMHa has joined #maemo11:08
*** Maxdamantus has quit IRC11:24
*** Maxdamantus has joined #maemo11:25
*** louisdk has quit IRC11:56
*** Kabouik has joined #maemo12:15
*** Kabouik_ has quit IRC12:18
*** Kabouik has quit IRC12:23
*** xorly has quit IRC12:28
*** mike727 has quit IRC12:29
*** capitanocrunch has joined #maemo12:42
sixwheeledbeast^yes and yes12:52
*** capitanocrunch has quit IRC12:57
*** qwazix has quit IRC13:07
*** zGrr has joined #maemo13:07
zGrrmoin :)13:11
*** qwazix has joined #maemo13:14
*** NeKit has joined #maemo13:29
*** TheKit has quit IRC13:32
*** err0r3o3 has joined #maemo13:51
*** Konsieur has joined #maemo13:55
*** auenf has quit IRC14:36
*** auenf has joined #maemo14:36
*** qwazix has quit IRC14:39
*** qwazix has joined #maemo14:43
*** xorly has joined #maemo14:50
*** Konsieur has quit IRC15:00
*** xy2_ has joined #maemo15:33
*** at1as has joined #maemo15:33
*** louisdk has joined #maemo15:35
*** err0r3o3 has quit IRC15:37
*** xy2_ has quit IRC15:42
*** xy2_ has joined #maemo16:05
*** ss942 has joined #maemo16:51
*** L29Ah has left #maemo16:56
ss942My last phone got broken and I'm using n900 again from now. But as far as I can see repos are not working any longer.17:00
ss942I know that I have to replace repos with community ones17:01
ss942but I'm prrety exhausted because I installed fremantle from as interned said me to do17:02
ss942and it's still not working.17:02
ss942could anyone link me a working repos catalogue?17:02
*** eMHa has quit IRC17:12
infobotrumour has it, maemo-repos is
*** frals has quit IRC17:15
*** RedW has quit IRC17:15
*** frals has joined #maemo17:15
*** frals has quit IRC17:17
*** frals has joined #maemo17:17
*** frals has joined #maemo17:17
siceloss942: ^^17:21
ss942sicelo: thanks17:23
*** louisdk has quit IRC17:23
*** RedW has joined #maemo17:34
*** frals has quit IRC17:35
*** frals has joined #maemo17:35
*** frals has joined #maemo17:35
*** ss942 has quit IRC17:42
*** L29Ah has joined #maemo18:06
*** heroux has quit IRC18:16
*** dmth|intevation has quit IRC18:17
*** heroux has joined #maemo18:17
*** xy2_ has quit IRC18:22
*** eMHa has joined #maemo18:26
*** Pali has joined #maemo18:27
*** xy2_ has joined #maemo18:28
DocScrutinizer05shake to wake - drains battery only when implemented without a clue18:28
DocScrutinizer05this is exactly the point how embedded differs massively from coding for a standard desktop PC18:29
DocScrutinizer05it's a pity not even the maemo lis302 kernel driver is really a comprehensive decent implementation18:30
DocScrutinizer05for "shake to wake" you'd basically need to use your own kernel driver or go for I2C plus your own IRQ handler18:31
DocScrutinizer05correct way to implement: set up the filters and thresholds in LIS302 so it triggers IRQ on shake (use high pass filter to detect fast movements rest changes in orientation), set up an IRQ handler that reads out LIS302 (to filter out false positives) and wakes the device. For this you need to tell MCE to keep its fingers off the LIS30218:35
DocScrutinizer05what MCE does to LIS302 filters is total brainfart18:36
DocScrutinizer05s/MCE/MCE and lis302dl.ko kernel driver/18:38
infobotDocScrutinizer05 meant: what MCE and lis302dl.ko kernel driver does to LIS302 filters is total brainfart18:38
DocScrutinizer05~tell sicelo about jrrepos18:39
*** florian has quit IRC18:44
infobotfrom memory, jrrepos is
* DocScrutinizer05 seems to still have to learn "you NEVER must change a URL on your server"18:50
sixwheeledbeast^It's python so basically has a loop polling the accel while locked. I tested it but cannot justify the battery drain.18:55
DocScrutinizer05loops and polling are both absolute nogo on embedded18:56
*** err0r3o3 has joined #maemo18:56
bencohsixwheeledbeast^: it means core keeps exiting sleep / low power states18:57
DocScrutinizer05you *always* have to use event driven design, here event=IRQ18:57
*** L29Ah has left #maemo18:57
DocScrutinizer05actually _always_ event=IRQ18:58
DocScrutinizer05even on touch events and keypress events18:58
DocScrutinizer05that's embedded programming18:58
DocScrutinizer05it SHOULD be generic concept for all platforms/environment. But on desktop often developers get away with crappy polling18:59
DocScrutinizer05a busy loop should throw an error in compiler already ;-P - A fat WARNING if the loop event is a timer (with less than 5 seconds interval)19:01
DocScrutinizer05on kernel level in maemo, processes that don't stop on a IRQ for at least 99% of time during one minute should get terminated hard with BUSERR or somesuch19:03
DocScrutinizer05OHM should take care19:05
DocScrutinizer05you know those "the program is not responding within time, do you want to wait longer or terminate it?" requesters (KDE for example)? Similar requester on maemo Hildon should be "the process is using more than 50% of time slots available to it, during last 60s. Do you want to stop the process, or allow for another minute, or allow permanently for all processes with this name?"19:08
DocScrutinizer05#s/permanently/for one week/19:09
DocScrutinizer05s/stop/stop, or kill/19:12
*** louisdk has joined #maemo19:12
DocScrutinizer05prolly a selection offering 1, 5, 60 minutes, 6h, 24h, 1 month (, forever with root password) - should be sufficiently versatile19:14
DocScrutinizer05plus "[_] apply to whole process group"  and "[_] apply to all processes with name regex '_________' " with the regex already preset to the process name of the triggering process, but editable19:17
*** dafox has joined #maemo19:19
DocScrutinizer05*might* need patches to scheduler19:19
DocScrutinizer05well, you _could_ check CPU-time elabsed for all processes every minute and compare to last check, to detect those processes that together consumed more than 30s CPU time and blame the one of them with highest CPU time increase19:21
DocScrutinizer05problem arises when one or more of those processes are already whitelisted for high CPU usage19:23
DocScrutinizer05it's tricky to handle the situation where 4 processes hog the CPU 100% and one of them is whitelisted19:24
DocScrutinizer05the other three might actually be humble and only use all their available CPU time because there isn't much CPU time left for them due to the whiteliszed hog process19:25
DocScrutinizer05btw it's one of the major tasks in maemo-testing evaluation to check for those CPU hogs and kick their ass19:30
infobotpkg is, like,
DocScrutinizer05no freking f*ing clue how made it into extras19:32
DocScrutinizer05would be council's duty to remove it from maemo-extras19:33
DocScrutinizer05  even ivgalvez OMG19:34
DocScrutinizer05>>There have been no comments so far.<< tells a story19:34
DocScrutinizer05people think testing evaluation is a sympathy contest19:35
DocScrutinizer05@council: please consider removing since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app19:36
KotCzarnydidnt he say he reduced cpu usage?19:37
DocScrutinizer05from 100% to 50% ? ;-P19:38
KotCzarnybetter than original, so that's improvement?19:38
KotCzarnyanyway, 2011, seems to be long time ago19:38
DocScrutinizer05that's no argument19:39
KotCzarnywonder if maintainer is still alive in maemo19:39
DocScrutinizer05all packages in maemo-extras are supposed to be safe to use, not cause any issues like massive battery drain19:39
DocScrutinizer05unless obvious, like in games etc19:39
KotCzarnyor audio player :P19:40
DocScrutinizer05the average user has no means to find out why their phone only stays as short as 10h with one battery charge, after they installed a dozen packages19:40
DocScrutinizer05audio player must at least provide a maybe 10h19:41
KotCzarnyyeah, and no resource drain when paused/idle19:41
DocScrutinizer05this is the basic rule for ALL apps19:42
KotCzarnywhich means keeping evilaudio in the kennel when not playing anything, as i've found out few years ago19:42
DocScrutinizer05shake2waje violates it19:42
KotCzarnymaybe there should be a page with violators19:43
*** L29Ah has joined #maemo19:43
KotCzarnyand versions tested19:43
KotCzarnyeasier than contacting authors purging packages (that might be useful otherwise)19:43
DocScrutinizer05this page is "testing", basically19:43
* DocScrutinizer05 ponders a generic patch to preinstall script that opens up a requester with bold fat "WARNING! this app is not recommended to use, since it has the following issues: ....*)...."19:45
DocScrutinizer05easy to add to existing packages19:45
DocScrutinizer05though I actually would prefer that stuff getting purged from maemo-extras. Back to maemo-extras-testing19:46
KotCzarnyi would vote for warning with a list of pkg-ver19:49
KotCzarnyas long user knows what drains the battery he/she might choose it consciously19:50
KotCzarnyor even fix19:50
DocScrutinizer05huh? the warning requester is bound to the particular version's pre-install script19:50
DocScrutinizer05when user want to "choose conciously" they are free to use the package from maemo-extras-devel or -testing19:51
DocScrutinizer05such package has no place in maemo-extras (plain)19:51
DocScrutinizer05I'm not going to fix a package that is broken by design19:52
DocScrutinizer05particularly this package that's basically impossible to fix without massive fixes/improvements to the kernel driver for lis30219:53
DocScrutinizer05juiceme: ^^^^19:57
DocScrutinizer05sicelo: ^^^^19:57
DocScrutinizer05@council: please consider removing since evaluation in testing (see above) failed to detect a major flaw - CPU hogging - in this app19:57
DocScrutinizer05should go back to maemo-extras-testing, with comment "promoted based on flawed evaluation, please fix CPU hogging"19:58
* DocScrutinizer05 is temped to take adminustrative measures already, on the packages web20:02
*** jskarvad has quit IRC20:05
*** dafox has quit IRC20:05
DocScrutinizer05  def get_rotation(self, widget=None):20:07
DocScrutinizer05f=os.popen('cat /sys/class/i2c-adapter/i2c-3/3-001d/coord').read()20:07
DocScrutinizer05now WHAT THE FUCK?!?
*** chfoo[m] has quit IRC20:11
*** vahe[m] has quit IRC20:11
DocScrutinizer05this is so terribly wrong, I have no wards for it. Best part: it actually doubles what mce already does, just waaaay inferior20:11
DocScrutinizer05coor = self.get_rotation()20:13
DocScrutinizer05       y = coor[1]20:13
DocScrutinizer05       if y<-1300 or y>1300 :20:13
DocScrutinizer05                   state = self.get_proximity()  .......20:13
*** xorly has quit IRC20:13
DocScrutinizer05THIS is something you get from MCE already, and MCE at least does The Right Thing[TM] which is: set uf filters in lis302 exactly like that (y<-1300 or y>1300) and waiting for IRQ from the filters20:14
DocScrutinizer05set up*20:15
DocScrutinizer05well, almost exactly like that20:17
*** louisdk has quit IRC20:17
DocScrutinizer05this isn't very smart in MCE, but it's totally braindead in the way shake2wake does it by *polling* the accel and then only checking for Y axis20:19
DocScrutinizer05hint: iirc 1000 is 1g aka "device has no other acceleration than gravity"20:20
DocScrutinizer05MCE uses static threshold of iirc 900 somesuch on Y - without any highpass filters - to detect if device is facing up (>900) or down (<900)20:21
DocScrutinizer05actually the kernel driver does that20:22
*** vahe[m] has joined #maemo20:22
DocScrutinizer05should have used highpass filters and same threshold (like 100/s) on two axes to trigger the IRQ20:23
infobotDocScrutinizer05 meant: should have used highpass filters and sane threshold (like 100/s) on two axes to trigger the IRQ20:23
*** chfoo[m] has joined #maemo20:25
DocScrutinizer05plus MCE and kernel driver should have API to modify the filters. MCE must keep a list of requests for filter settings from userland and choose the most sensitive one. Much like liblocation20:26
*** louisdk has joined #maemo20:35
DocScrutinizer05>>Location resources are shared between applications, and applications can request different location methods. Fixes for all requested methods are sent for all applications listening to GPSDevice's "changed" signal, therefore application should judge whether fix it is receiving, is one that it needs. See GPSDeviceFix section for discussion.<<  and   >>An application receiving a fix cannot know if the fix is a result from location method20:37
DocScrutinizer05it requested. Therefore application should study whether fix is accurate enough to satisfy application's needs.<<  s/fix/acceleration event/  s/location method/lis302 filter/20:37
*** florian has joined #maemo20:47
*** florian has joined #maemo20:47
DocScrutinizer05the kernel driver must expose the filter settings, the middleware (MCE) must have an API with abstract filer settings for the userland to register for an event based on those filters. The middleware will keep a list of those registrations and adjust the filers in kernel driver to the most sensible ones. with no active registrations the middleware will disable the accel sensor20:57
*** LjL has quit IRC21:00
*** mavhc has quit IRC21:01
DocScrutinizer05if a userland process requests filer settings that collide with the ones in effect, the response from middleware will notify to the userland process which filter setting are in effect and which failed on the request. For example LIS302 has only two engines to monitor sensors and trigger IRQ, so only 2 of the XYZ axes can get monitored. If filers monitor X,Y then a request for X,Z will return with "Z ignored, resouce occupied"21:01
DocScrutinizer05logical consequence: the API in middleware allows to request the theoretical maximum for filters/triggers, I.E "Xmin,max,hp_parameters Ymin,max,hp_parameters Zmin,max,hp_parameters Xclick Xdoubleclick Yclick Ydoubleclick Zclick Zdoubleclick "21:06
*** mavhc has joined #maemo21:07
*** cyteen has joined #maemo21:07
DocScrutinizer05obviously some sort of plaintext interface is best suited for that, to have the most generic interface design suitable for other sensors as well21:08
*** __LauRoman has quit IRC21:08
DocScrutinizer05X triggers when value outside the interval -1300..+1300;  Y triggers when value change is >30 in 2 seconds; Z triggers when value inside interval -5..+521:17
DocScrutinizer05parameters in request are satisfied from left to right. so for the lis302 the response from middleware could be "X*:>50,hpwindow=10s;Y:>30,hpwindow=2s;Z:EAVAIL"21:20
*** LauRoman has joined #maemo21:21
*** geaaru has quit IRC21:21
DocScrutinizer05this is due to existing filter for X from another app, which overrides the mere left to right. a request "X:<-1300,>1300,abs" might get response "X*:>50,hpwindow=10s;X:<-1300,>1300,abs" however, when the resource "2nd engine" wasn't occupied previously21:23
sixwheeledbeast^There is no requirement for packages to be tested for CPU usage. As a package tester you QA to the guidelines set.21:24
DocScrutinizer05I thought the guidlines explicitly mention excessive resource usage21:25
sixwheeledbeast^Not that I recall, also define excessive.21:25
DocScrutinizer05I even thought this was first prio for test evaluation21:25
DocScrutinizer05  just to refer to what we're talking about. Now reading...21:27
DocScrutinizer058. [ ] No power management issues.21:28
DocScrutinizer057. [ ] No performance problems.21:28
DocScrutinizer05Power management issues21:30
DocScrutinizer05Battery life is diminished beyond acceptable standards by having the application running in the background21:30
sixwheeledbeast^But still it's in the package testers opinion. It's not a set amount like say 0.3MB of root space.21:31
DocScrutinizer05this is pretty much common sense21:31
KotCzarnybut did anyone measured battery drain of it?21:31
sixwheeledbeast^As long as the package does not cause the battery to drain within a day, it could be seen as a pass but not ideal.21:31
DocScrutinizer05also you got >>The use case of a full day without charging should not be compromised.<<21:32
KotCzarnybut that system('cat') instead of read is fubar21:32
sixwheeledbeast^I noticed a drop in battery life when I tested it but never did my full package test procedure on it to rate the package. This was several years ago.21:34
* sixwheeledbeast^ has to run bbl21:34
DocScrutinizer05shake2wake polls accel with a 1s period aiui and it does a lot of nonsense with a 0.05s period during each cycle
*** LauRoman has quit IRC21:35
DocScrutinizer05honestly for such code you should get banned from civilized world, to an island what only has a ZX81 and an old b&w TV, and an ergometer dynamo to power it21:36
DocScrutinizer05for at least one year21:36
KotCzarnynah, zx81 has basic, not a good educational example21:36
DocScrutinizer05anyway for 'cat /sys/class/i2c-adapter/i2c-3/3-001d/coord' alone, it should get rated down due to risks in that21:38
DocScrutinizer05if not for risks then for ugliness despite gaving better alternative21:40
*** LauRoman has joined #maemo21:41
*** zGrr has quit IRC21:41
*** xy2_ has quit IRC21:49
DocScrutinizer05what the....21:49
*** pagurus` has quit IRC21:49
DocScrutinizer05# Regular cron jobs for the stow2-2.2.2 package21:49
DocScrutinizer050 4* * *rootstow2-2.2.2_maintenance21:49
*** xy2_ has joined #maemo21:55
*** louisdk has quit IRC21:56
*** Kabouik has joined #maemo22:01
*** Kabouik has joined #maemo22:02
DocScrutinizer05I should eventually create that sanity checker I planned for so long. One of the checks would look at CPU time total of all processes and check the topmost 2 or 3 that are not whitelisted, then notify user about them22:05
DocScrutinizer05the problem with shake2wake: it's an applet so won't even show up in there >:-(22:07
* DocScrutinizer05 idly wonders if sleep() is allowed at all in applets22:09
DocScrutinizer05that's prolly the reason for that >> while gtk.events_pending():    gtk.main_iteration(False) time.sleep(0.05)<< madness22:11
DocScrutinizer05so hildon desktop gets a chance to axt on a (me counts)... 10 events during 0.5s22:15
*** ravelo__ is now known as ravelo22:15
*** Vajb_ has joined #maemo22:28
*** Vajb has quit IRC22:28
*** clopez has joined #maemo23:07
*** dafox has joined #maemo23:27

Generated by 2.15.1 by Marius Gedminas - find it at!