missMyN900 | downloading Devuan Beowulf i386 right now | 03:43 |
---|---|---|
missMyN900 | I will try it on the Atom tablet tomorrow | 03:43 |
missMyN900 | by the way, I did some more research and these Atom tablets may not be such good dev devices after all | 03:44 |
missMyN900 | apparently all these Silvermont-based CPUs are affected by the SD/eMMC/USB degradation issue | 03:44 |
missMyN900 | which is an especially big problem for these tablets as they boot from the eMMC (or perhaps a microSD) | 03:45 |
missMyN900 | I have not found any evidence of it specifically affecting these Z-series but it affects the C-series as well as N and J series so I see no reason why these Z-series CPUs would not be affected | 03:46 |
missMyN900 | when they are from the same era and also Silvermont-based | 03:46 |
missMyN900 | by the way I have read the logs from yesterday | 03:48 |
missMyN900 | also updated my PP to the new kernel | 03:49 |
missMyN900 | actually I think standby battery drain may be less | 03:50 |
missMyN900 | rafael2k: I was actually talking about VoLTE on the DB since I may get one | 03:52 |
missMyN900 | I no longer have a SIM in my PP | 03:52 |
missMyN900 | had to cut some expenses | 03:53 |
uvos__ | missMyN900: you have to install 64bit devuan | 08:12 |
uvos__ | which your cpu supports | 08:13 |
uvos__ | idk how to work around 32bit efi | 08:13 |
uvos__ | but its possible | 08:13 |
rafael2k | missMyN900: good to hear about better battery life in stand-by! Did not know about DB... | 08:27 |
Guest9053 | can anyone kindly tell the use of secure mode from powerkey menu? | 09:58 |
lel | sanderfoobar opened an issue: https://github.com/maemo-leste/conversations/issues/9 (Feature: filter overview) | 10:13 |
uvos__ | Guest9053: this would lock the device, requriering a keycode | 11:03 |
uvos__ | but it cant work on non n900 devices since the backend uses a hardcoded storage location thats n900 only | 11:04 |
uvos__ | it might also not work on n900 yet not sure | 11:04 |
uvos__ | but i think it should | 11:04 |
sicelo | Probably could be ported to use a suitable keyring mechanism (such as the one gnome uses), until such time | 15:36 |
sicelo | Such time that there's FDE support or similar | 15:36 |
sicelo | Of course CAL had the additional usefulness that it persists across flashes, at least to a casual user/thief | 15:37 |
buZz | https://i.imgur.com/I6mJtAr.png <- compiling kernel on the d4 ;) | 20:18 |
buZz | runs pretty warm :) | 20:18 |
lel | sanderfoobar opened an issue: https://github.com/maemo-leste/conversations/issues/10 (Feature: compose a new message) | 20:55 |
dsc_ | Re: conversations & rtcom: it uses rtcom-eventlogger to query the database (el-v1.db) for (historical) messages | 21:02 |
dsc_ | i.e: to display the overview of (SMS/whatever) messages we construct a query via the rtcom lib | 21:04 |
dsc_ | which is fine for simple SELECT + WHERE statements | 21:05 |
dsc_ | but lets say I want to create some search functionality: https://i.imgur.com/QMakXV1.png | 21:05 |
dsc_ | whereby you can search for keywords within messages you previously received | 21:05 |
dsc_ | I'd need to create a query that is able to do a full text search | 21:06 |
dsc_ | with postgres you'd do ILIKE or something with GIN, tsvector | 21:06 |
dsc_ | sqlite only has LIKE, plus rtcom doesnt support that operator at all: https://github.com/maemo-leste/rtcom-eventlogger/blob/master/rtcom-eventlogger/eventlogger-types.h#L71-L79 | 21:06 |
dsc_ | i've written some more info here: https://github.com/maemo-leste/conversations/issues/8#issuecomment-1164699283 | 21:06 |
dsc_ | now, not being able to search within messages is not the end of the world HOWEVER what is also upcoming is the searching of "CONTACTS" (names and/or number(s)) | 21:07 |
dsc_ | and ideally you'd have search functionaltiy where results are progressively updated as you type | 21:08 |
dsc_ | actually... I can solve this by doing a broad SELECT, looping over everything, and doing the post-processing (searching) in C++ | 21:14 |
dsc_ | not great, but, we are iterating over the results, and not fetching them all at once into memory, so I think that could work just fine | 21:15 |
rafael2k | what mapphone is? | 21:17 |
rafael2k | I see some mentions to it in the git repos | 21:17 |
sicelo | rafael2k: the supported motorolas | 21:41 |
buZz | sicelo: map = omap ;) | 21:51 |
missMyN900 | uvos__: is i386 not supported by ML? | 22:53 |
sicelo | I believe I already mentioned there's nothing built for i386. I don't recall if there was a more technical reason for that | 23:09 |
uvos | buZz: im pretty sure the map in mapphone acutally refers to the usage of the "signal map" instead of device tree to define how hardware devices are conected | 23:25 |
uvos | we dont build for i386 there is no reason for this besides resources. | 23:26 |
buZz | oh, i dont know | 23:26 |
buZz | but, we are using device tree? | 23:27 |
uvos | yes we are | 23:27 |
uvos | the signal map is a motorola kernel thing | 23:27 |
uvos | they wrote a parser and everything | 23:28 |
buZz | afaik mapphones = droid 4 , droid bionic , n900 | 23:28 |
uvos | n900? | 23:28 |
uvos | no | 23:28 |
buZz | oh ok | 23:28 |
uvos | http://uvos.xyz/maserati/mapphones.ods | 23:28 |
sicelo | Heh, of course N900 isn't a mapphone. I thought map = omap was a joke | 23:33 |
buZz | ah :) | 23:40 |
buZz | right, make -j1 of the current kernel on droid 4 = 358 minutes | 23:41 |
uvos | why j1? | 23:41 |
* buZz considering doing make clean ; time make -j2 | 23:41 | |
uvos | also why do it on d4 at all | 23:41 |
uvos | since kernel is trivial to cross compile | 23:42 |
buZz | uvos: i imagined it would run out of ram & swap without | 23:42 |
uvos | buZz: ok | 23:42 |
buZz | i left full maemo running | 23:42 |
buZz | also, make -j1 was already taking both cores to 100% ? | 23:42 |
buZz | maybe because of the SD card | 23:43 |
uvos | hmm wierd | 23:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!