| *** ChanServ sets mode: +v T4 | 05:43 | |
| *** greguu1 is now known as greguu | 07:32 | |
| *** ChanServ sets mode: +v T4 | 10:32 | |
| spiiroin | review/testing appreciated: https://git.merproject.org/mer-core/mce/merge_requests/94 | 10:36 |
|---|---|---|
| spiiroin | ^ get battery / charger info directly from udev | 10:36 |
| Mister_Magister | spiiroin: forget to ping me? :P | 10:58 |
| Mister_Magister | spiiroin: hi have you seen my feedback? | 10:58 |
| spiiroin | Mister_Magister: consider yourself pinged ;-) | 11:24 |
| Mister_Magister | spiiroin :P | 11:25 |
| Mister_Magister | spiiroin: have you seen my feedback in past? | 11:25 |
| spiiroin | Mister_Magister: I recall you saying that the earlier quick fix did not work, but have not seen anything since that | 11:25 |
| Mister_Magister | spiiroin: so you missed it | 11:25 |
| Mister_Magister | it worked after second reboot | 11:25 |
| Mister_Magister | i dont get that freeze anymoar | 11:25 |
| Mister_Magister | should i test this merge aswell for ya? | 11:26 |
| spiiroin | please do, as this replaces all of that statefs plugin we tried to patch earlier | 11:26 |
| Mister_Magister | spiiroin: so it should work even better? | 11:28 |
| Mister_Magister | no statefs poop anymore? | 11:28 |
| spiiroin | Mister_Magister: the problem was that sometimes under some circumstances mce does not see statefs props changing. now we go directly to udev -> should avoid that statefs+fuse issue altogether | 11:29 |
| Mister_Magister | so we dont use statefs anymoar? | 11:29 |
| spiiroin | it is used elsewhere for other purposes, but this virtual fs thing is problematic | 11:30 |
| spiiroin | but new impl = possibly have room for some hiccups that statefs did handle -> testing would be nice | 11:31 |
| Mister_Magister | spiiroin: anyway it should be better now right? ill test it once i come back | 11:31 |
| spiiroin | Mister_Magister: quick sanity check would be: 1) boot to act dead with charger connected; 2) wait a minute, should stay in act dead 3) detach cable, should shutdown after ~15 seconds | 11:32 |
| spiiroin | Mister_Magister: if that works, then just use the device and see if you spot any problems | 11:32 |
| Mister_Magister | spiiroin: will do! | 11:32 |
| r0kk3rz | spiiroin: was mce using inotify to watch for statefs events? | 11:33 |
| spiiroin | r0kk3rz: nope, epoll + glib io watch | 11:37 |
| *** sydney_u1tangle is now known as sydney_untanble | 13:58 | |
| *** sydney_untanble is now known as sydney_untangle | 13:58 | |
| vknecht | if your device is 64bits, and your kernel > 3.10.68, could you tell me if your /proc/cpuinfo looks like the 1st or the 2nd format in https://pastebin.com/8Yb7pFah ? | 17:17 |
| vknecht | tia :) | 17:18 |
| vknecht | I guess the first, like on X, but still... | 17:22 |
| mal | it looks like the latter on a 64-bit device | 17:26 |
| vknecht | and you have BogoMips value ? | 17:27 |
| mal | yes | 17:28 |
| vknecht | hmmm | 17:29 |
| mal | so when do you get the first output? | 17:29 |
| vknecht | with 3.10.68, and second when merged 3.10.69 which should have https://github.com/nathanchance/linux-stable/commit/72684eae7b0acf2d085e1e878caa44b5e0219b24 | 17:30 |
| vknecht | but I must have fumbled something, maybe because of CAF updates | 17:31 |
| vknecht | X with 3.10.84 has first format | 17:31 |
| vknecht | which if I understand correctly is how it should be | 17:31 |
| mal | the first format looks like it's missing most things | 17:32 |
| vknecht | with the second, in SFOS' Aida64 can't get "core architecture" correctly ; in LOS, CPU-Z even reports 15 cores instead of 8 | 17:37 |
| mal | vknecht: what should core architecture show? | 17:40 |
| vknecht | too bad I might have to backtrack, got a record suspend time of 17 minutes and 35s in CSD with 3.10.75 :) | 17:41 |
| vknecht | don't have noted previous result, but now as it is with 3.10.75 and second format, it says "Unknown Vendor (id=0x00) 0x0000 @ 1497MHz 7xARM Cortex A-53 @ 1113MHz" | 17:44 |
| vknecht | (in SFOS' Aida64) | 17:45 |
| mal | on my device it looks ok, not x | 17:45 |
| *** ChanServ sets mode: +v T4 | 19:12 | |
| piggz | evening | 19:13 |
| vknecht | good evening piggz :) | 19:30 |
| piggz | think i'll do a littel amazfish development | 19:46 |
| vknecht | piggz, bored by the cam stuff ? :) | 19:52 |
| piggz | vknecht: no, but im tired and cant think too hard! | 19:53 |
| piggz | and got various issues opened on amazfish recently, so, it means I have users.... | 19:53 |
| vknecht | eh | 19:54 |
| piggz | also, someone bricked their device ... kind of their own stupidity, but my app alloed them too! | 19:54 |
| vknecht | please fix it before I get one ;-) | 19:54 |
| piggz | well, just done try and flash a Bip firmware to a Cor! | 19:55 |
| piggz | 1) i only officially support Bip, 2) know what youre flashing, to what, before flashing! | 19:56 |
| vknecht | ... or crash and burn ... | 19:58 |
| vknecht | not having to think too hard, esp. this late, I can relate to that... I should let this kernel update with cpuinfo mess aside for now, and let the brain work on it this night... | 20:04 |
| vknecht | and magically fix it in 5 minutes tomorrow ;-) | 20:04 |
| piggz | what am i missing ... just opened project in sailfish ide, but qt creator cant run it ... project run settings says 'remote path bot set' | 20:19 |
| vknecht | target.path in .pro ? http://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html | 20:31 |
| piggz | vknecht: what the issue seems to be, in the run settings, the 'files to deploy' list is empty | 21:02 |
| piggz | on a new project, that is populated | 21:02 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!