libera/#maemo-leste/ Thursday, 2022-06-23

missMyN900downloading Devuan Beowulf i386 right now03:43
missMyN900I will try it on the Atom tablet tomorrow03:43
missMyN900by the way, I did some more research and these Atom tablets may not be such good dev devices after all03:44
missMyN900apparently all these Silvermont-based CPUs are affected by the SD/eMMC/USB degradation issue03:44
missMyN900which is an especially big problem for these tablets as they boot from the eMMC (or perhaps a microSD)03:45
missMyN900I 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 affected03:46
missMyN900when they are from the same era and also Silvermont-based03:46
missMyN900by the way I have read the logs from yesterday03:48
missMyN900also updated my PP to the new kernel03:49
missMyN900actually I think standby battery drain may be less03:50
missMyN900rafael2k: I was actually talking about VoLTE on the DB since I may get one03:52
missMyN900I no longer have a SIM in my PP03:52
missMyN900had to cut some expenses03:53
uvos__missMyN900: you have to install 64bit devuan08:12
uvos__which your cpu supports08:13
uvos__idk how to work around 32bit efi08:13
uvos__but its possible08:13
rafael2kmissMyN900: good to hear about better battery life in stand-by! Did not know about DB...08:27
Guest9053can anyone kindly tell the use of secure mode from powerkey menu?09:58
lelsanderfoobar 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 keycode11:03
uvos__but it cant work on non n900 devices since the backend uses a hardcoded storage location thats n900 only11:04
uvos__it might also not work on n900 yet not sure11:04
uvos__but i think it should11:04
siceloProbably could be ported to use a suitable keyring mechanism (such as the one gnome uses), until such time15:36
siceloSuch time that there's FDE support or similar15:36
siceloOf course CAL had the additional usefulness that it persists across flashes, at least to a casual user/thief15:37
buZzhttps://i.imgur.com/I6mJtAr.png <- compiling kernel on the d4 ;)20:18
buZzruns pretty warm :)20:18
lelsanderfoobar 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) messages21:02
dsc_i.e: to display the overview of (SMS/whatever) messages we construct a query via the rtcom lib21:04
dsc_which is fine for simple SELECT + WHERE statements21:05
dsc_but lets say I want to create some search functionality: https://i.imgur.com/QMakXV1.png21:05
dsc_whereby you can search for keywords within messages you previously received21:05
dsc_I'd need to create a query that is able to do a full text search21:06
dsc_with postgres you'd do ILIKE or something with GIN, tsvector21: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-L7921:06
dsc_i've written some more info here: https://github.com/maemo-leste/conversations/issues/8#issuecomment-116469928321: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 type21: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 fine21:15
rafael2kwhat mapphone is?21:17
rafael2kI see some mentions to it in the git repos21:17
sicelorafael2k: the supported motorolas21:41
buZzsicelo: map = omap ;)21:51
missMyN900uvos__: is i386 not supported by ML?22:53
siceloI believe I already mentioned there's nothing built for i386. I don't recall if there was a more technical reason for that23:09
uvosbuZz: 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 conected23:25
uvoswe dont build for i386 there is no reason for this besides resources.23:26
buZzoh, i dont know23:26
buZzbut, we are using device tree?23:27
uvosyes we are23:27
uvosthe signal map is a motorola kernel thing23:27
uvosthey wrote a parser and everything23:28
buZzafaik mapphones = droid 4 , droid bionic , n90023:28
uvosn900?23:28
uvosno23:28
buZzoh ok23:28
uvoshttp://uvos.xyz/maserati/mapphones.ods23:28
siceloHeh, of course N900 isn't a mapphone. I thought map = omap was a joke23:33
buZzah :)23:40
buZzright, make -j1 of the current kernel on droid 4 = 358 minutes23:41
uvoswhy j1?23:41
* buZz considering doing make clean ; time make -j223:41
uvosalso why do it on d4 at all23:41
uvossince kernel is trivial to cross compile23:42
buZzuvos: i imagined it would run out of ram & swap without23:42
uvosbuZz: ok23:42
buZzi left full maemo running23:42
buZzalso, make -j1 was already taking both cores to 100% ?23:42
buZzmaybe because of the SD card23:43
uvoshmm wierd23:43

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!