libera/#maemo-leste/ Sunday, 2021-08-22

WizzupI had a crash+reset (via watchdog?) tonight08:19
Wizzupwas listening to music with mpv and it crashed08:19
Wizzupdidn't get pstore08:19
Wizzup(since the device did something weird in kexecboot and then rebooted again)08:19
tmlindhmm too bad no pstore dump08:32
Wizzupyeah, I'll just listen to more music on it :)08:36
tmlindwas the screen blanked when it happened?08:46
WizzupI think so, yes08:46
Wizzupyeah, pretty sure.08:46
tmlindok08:47
Wizzup(It was late at night and I was up all night in a night bus, but IIRC I ran sleep 120 ; /etc/init.d/droid4-powermanagement status08:47
Wizzup(to see if it would still RET with mpv, which it did)08:47
WizzupI don't know it really happened after those 120s08:47
Wizzupfelt like it, but could be wrong :)08:47
uvosWizzup: where do we want to store ringtones?10:23
uvosso my profiled ini  just contains "ringing.alert.tone = Nokia_tune.aac"10:24
uvosofc that file dosent exist so i cant search for it10:24
uvosand i dont know where it should be10:24
parazydThere's osso-sounds packages10:30
uvoslink?10:31
parazydhttps://parazyd.org/pub/dev/random/osso-sounds-ui_5.6+0m5_all.deb10:32
parazydhttps://parazyd.org/pub/dev/random/osso-sounds-rtc_5.6+0m5_all.deb10:32
parazydNot sure if we have imported them or not10:32
uvosdosent look like we did10:32
parazydAh yeah, we only have the -ui imported as .deb10:32
parazydNot in git yet10:32
uvosthis is not the right pacakge10:33
uvosit dosent contain the ringtones10:33
uvos(neither dose)10:33
parazydWhat about https://parazyd.org/pub/dev/random/maemo-ringtones-mr0_1.1+0m5_all.deb ?10:35
uvosthat contains it yeah11:10
uvosWizzup: so ./configure --enable-libprofile dosent seam to work regarding defineing ENABLE_LIBPROFILE11:37
uvosit never shows up on gcc cmdline11:37
parazyduvos: Shouldn't it be in config.h ?11:46
uvosoh right11:46
parazydThis stuff isn't passed as a param, rather defined in the header11:46
uvosyeah i forgot that config.h is a posibility too, to used to other build systems...11:57
uvosnew sphone version uses profiled now12:38
Wizzupcool14:10
uvosi assume nothing nicer than control pannel profilesx exists to change these things14:12
uvosbecause clicking on that to change the ringtone is realy non-obvious imo14:12
Wizzupuvos: fremantle has a nicer thing but it's not foss14:19
WizzupI just added profilex until we have something nicer14:19
Wizzupok so at least some of the problems bringing up the ofono stuff was also related to the apn not being set14:21
WizzupNot sure how that happens14:22
Wizzupuvos: should we import maemo-ringtones?14:24
uvosWizzup: we should import something as default ringtones14:28
uvosWizzup: not sure we want nokia-tune as the (only) default ringtone as in that package14:28
uvosWizzup: that might be a bridge to far (c) wise14:29
uvosanyhow setting random files in profilex as ringtone works fine14:30
Wizzupwell, we could use the sphone ones too, as long we have some14:31
uvosyeah sure14:31
uvoswe should have some ringtones14:31
uvoswe could also checkout the asop ones14:31
uvosthose have a permisive licesence afaik14:32
Wizzupok14:33
WizzupI'm going to finish this tor stuff and then get back to audio14:34
uvosWizzup: https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/master/data/sounds/14:34
uvosthey are apache 2.014:34
uvosand high quality ofc14:35
WizzupI'd personally rather not use the android ones just because it is android14:38
uvossounds kinda like irrational dislike of android14:39
Wizzupit's also about being different, and then it sounding the same, idk :)14:39
uvoseh android is foss we are foss, the point of foss is shareing, i have no qualms of lifting stuff from it.14:41
uvosbesides most (all?) android vendors dont use the asop sounds14:41
uvosthey will only sound fammilar to los users and sutch14:42
bencohthat part is definitely foss, but there is a point in "sounding different than asop", I would say14:42
uvossure but well we can also add aditional foss sounds later and make sone of those default14:45
uvosthe sphone notifcation sound is suspect imo, its just a recording of some dumb phone with associated background noise14:46
bencohI wonder if this can be used freely: https://tones.wolfram.com14:46
uvosim pretty sure its "autor" acording to the repo lacks copywrigt14:46
uvosthe sphone ringger is fine its just a recording of a model 500 telephone14:46
WizzupI kinda like the sphone ones tbh14:53
uvosright but the notifcation sound we cant use - its copyrighted14:53
uvosthe model 500 recording is fine14:53
Wizzupafaik we can just use the nokia ones, same like themes and everything else14:55
Wizzupas long as it's hosted on maemo.org14:55
uvosok but i dont think thats a solution really14:55
uvosregardless we need some other default than the nokia-tune14:56
uvosusing that is just asking to be scrutinized14:56
uvosanyhow regardless of what we will do, ill create a asop-sounds package14:57
uvoswe can place it into extras as something to be userinstalled if we dont want it later14:57
Wizzupfor audio, I think we'll at least need telepathy-ring running in the background15:12
Wizzup(for the policy to pick up on calls)15:12
WizzupI might try my hand later at porting to telepathy-glib with ring15:12
uvostelephathy must have some interface into puse for the profile no?15:13
Wizzupfor the audio? no15:13
WizzupAll of this is done by ohmd and it's a solved problem if we use telepathy afaik15:13
Wizzupit inspects telepathy dbus15:13
Wizzupbut it doesn't inspect ofono for semi obvious reasons15:13
uvosi think haveing a hard dependancy between telepathy and audio routing is a huge mistake15:14
Wizzuprunning ring does not interfere with sms (gets delivered to both sphone and empathy), and calls not15:14
Wizzupwell it's how sailfish works, and fremantle works15:14
uvosthats nice i still think its a mistake15:14
uvosthose are closed ecosystems15:14
Wizzupseems to make sense to me, ohm can make sure the ringtone you play is on the speakers/hp, whereas the moment you pick up it auto switches for you15:14
Wizzupand suspects and other speakre audio15:14
uvoswhere everything is expected to be written for that platform and that platfrom only15:15
uvossure but ohm should just expose some generic interface that allows you to tell it what is needed right now15:15
uvosand then telepathy uses that15:15
uvossnoopting on telepathy state is not an interface15:15
uvossnooping15:15
WizzupIt's not really snooping, it's how telepathy works (over dbus)15:16
uvosright but its the wrong way around imo15:16
Wizzupplus you can use pulse hints to affect the policy15:16
uvostelepathy should be using a ohmd/pulse audio routing interface15:16
WizzupI don't see how that makes more sense15:16
uvosaudio routing should no be passively following telephathy15:16
uvosit makes more sense because removes telepathy as a hard requirement15:17
Wizzupyou could just change the policy to support other things too, which it might do given the right pulse hints15:17
WizzupI think this is the xpolicy.conf stuff15:17
WizzupI'm just saying that if we use telepathy, everything will work smoothly and it'll be the integration we're aiming for, which is why I'll try my hand at the telepathy-glib when tor/wireguard and audio routing work15:18
bencohdon't we already have tor plugins in fremantle?15:19
uvosok so how this works is telephathy takes a call, and on dbus it has a signal that it did take a call right?15:19
uvosand then ohmd acts on that and switches the route?15:19
uvosam i getting this correctly15:19
Wizzupbencoh: very poorly integrated15:19
Wizzupuvos: yes, that is my understanding, it will switch the right alsa switches15:20
Wizzupmaybe also do some pulse rerouting (not sure, probably depending on the setup)15:20
Wizzupand it'll cork normal streams15:20
uvosright so i honestly think this is horrid15:20
bencohwhat would you do then? have telepathy-ring talk with pulse directly?15:21
uvosno15:21
uvosso id have ohmd have an interface15:21
uvosthat telephathy calls15:21
uvosthat way anyone can cause the audio route to change if it uses the same interface15:21
Wizzupso if I were to make a diagram of what talks to what, it'd get more complicated and we'd have to patch all the mainline stuff to talk to ohmd15:21
uvosso in effect it allows you to replace telephathy15:21
uvosthe current way dosent15:21
Wizzupwhereas here ohm is just clever and does the right thing15:21
uvosbecause only telepathy can own its dbus name15:22
Wizzups/mainline/upstream/15:22
bencohbut, err ... we use telepathy on purpose, don't we?15:22
Wizzupwhy would you want to replace telepathy? you could just edit the policy and support other protocols15:22
Wizzupbencoh: yes, we will15:22
bencohand it *is* supposed to be our middleware communication stack15:22
Wizzup(we don't use it currently for the phone calls, it's purely ofono dbus atm)15:22
bencohunless I missed something15:22
uvosok but then you are createing policys for specific apps15:22
uvosfor no reason15:22
Wizzupuvos: in your example every app has to talk to ohm, I don't see the difference15:23
Wizzupbut the way I see, we will have no communication apps other than our telepathy UIs15:23
WizzupI see it*15:23
Wizzupwhatsapp, signal, whatever, we'll make it work with TP15:23
uvosthe difference is that ohm is lower level15:23
uvosits closer to the hw15:23
uvosthe interface is the wrong way around15:24
Wizzupif people insist on using linphone over sofiasip, then we can have a policy entry for it, but then linphone will also need to know to tell mce to set the phone to call mode, etc etc15:24
Wizzupbencoh: I don't think you missed something15:24
Wizzupwe just don't have it yet15:24
Wizzup:)15:24
bencoh:)15:24
uvosto make a comperasin this is like haveing the kernel inspect what some app is doing and then allocated memory instead of the app calling to the kernel for memory15:25
Wizzupwith osso-abook hopefully ready semi soon another big gap will be filled and then I think we should be able to focus a lot on this stuff15:25
uvosand sure we want tp15:25
Wizzupuvos: I don't see it that way really, telepathy is clear about it's intentions on dbus, and our phone ohmd is clever to set up the audio routing properly, instead of making telepathy do low level stuff it shouldn't do15:25
uvosbut we should make everything as loosly coupled as possible without sacrificing functionality15:26
uvosits just prudent15:26
uvoswhat happens if tp implodes tomorrow15:26
uvosyou want to maintain it15:26
uvosno we should allways think about an out15:26
bencohI'd be honest, I think telepathy is already in a life support mode15:26
uvosand simply reversing the interface reduces the dependancy15:26
WizzupI think it creates reverse dependencies everywhere15:27
bencohand it has been so for ... 5~8 years?15:27
uvosno it really dosent15:27
Wizzuphttps://github.com/maemo-leste/policy-settings-common/blob/common/basic/policy/telephony.pl15:28
Wizzuphttps://github.com/maemo-leste/ohm-plugins-misc/blob/master/plugins/telephony/ohm/telephony.pl15:28
Wizzup+ https://github.com/maemo-leste/ohm-plugins-misc/blob/master/plugins/telephony/ohm/telephony.c15:29
Wizzupthe last one is decent I think to get an appreciation of the amount of work the nokia/mer folks put in to support all the features (I didn't read most of the code.)15:31
sicelobencoh: i am not sure TP is on life support. Plasma Mobile is using it, and, I believe, maintaining it very actively15:31
Wizzupthis might need replacement: https://github.com/maemo-leste/ohm-plugins-misc/blob/master/plugins/telephony/ohm/telephony.c#L220715:31
Wizzupsicelo: as is sfos15:32
Wizzupbut I think not a lot happens in it15:32
Wizzuphttps://telepathy.freedesktop.org/components/telepathy-morse/ hey there is a telegram thing15:32
siceloyes, that's why i said it's actively maintained15:33
siceloi don't see it imploding in our lifetime15:34
Wizzupsure, imploding is basically impossible unless we all decide to stop using dbus15:34
WizzupI think where it lacks is feature richness that other protocols support (weird voice files/messages, etc)15:34
WizzupI'm going to get some rest, didn't get to sleep earlier15:35
siceloiirc it now does support those things. telegram, for example, has them15:35
siceloanyway, i also don't follow this stuff anymore15:36
uvosthis isent about the merrits of telepathy at all per say15:36
uvosand also complexity/ time spent in implementation is hardly something that speaks for some solution15:37
uvosthis is about base os independance from some telephony solution15:37
uvosie i want the base os to be independant from the specifics telephathy15:37
uvosand the audio setup is very mutch part of the base os15:37
Wizzupwell, from a practical point of view it sounds like something that can take many months, and I think walking the known path here makes a lot of sense15:38
Wizzupi.e. re-use the existing stuff15:38
uvosand i very mutch _dont_ see the telephony as part of the base os as leste is usefull on any touchscreen device15:38
sicelowhat's TP got to do with touch :-/15:39
siceloanyway, /me out15:39
uvossicelo: the device might not be a comunication device at all15:39
Wizzupwell, that's fine, then one can try to remove osso-abook and tp and such15:39
Wizzupwe can make that work out with deps15:39
Wizzupand if it is not a communications device, audio routing is mostly not a problem15:40
sicelomaemo has become something else. i thought it was *always* about communication devices15:40
WizzupI think it's a nice tablet os :)15:40
Wizzupregardless of calls15:40
Wizzuplike, a good mobile linux interface15:40
sicelocalls != communication15:40
uvosalso in an ideal world hildon would just be a de15:41
siceloN800 was a communication device ... skype and all15:41
Wizzupwell any computer we really use is communication, so it's, idk, nitpicking15:41
uvosthat you can just install over some linux distro15:41
uvosofc thats currently not possible but idealy15:41
siceloand therefore N8x0 had/used TP15:41
uvosi think thats all it would be15:41
Wizzupin any case I feel like we've had the discussion before, and my opinion is that we can change the inner workings once we have a full featured device and fully understand it all15:41
Wizzupuntil then I am not inclined to think I can think of a better way than the many dedicated nokia engineers at the time for something as complex as audio routing15:42
WizzupI don't even understand all that they did yet15:42
uvosoh btw https://packages.debian.org/source/buster/brainparty works correctly16:55
uvos(ie dosent segfault all over the place, leak memory and input works fine etc)16:55
uvosdosent scale either16:55
uvosis a newer version 0.61 vs 0.5816:56
inkyfolks, i don't use sim cards. first thing i did with pinephone was i disabled its modem before switching the phone on for the first time.17:12
inkybut even i would like to have address book integrated with telepathy.17:12
inkytdats the main yeature of maemo17:12
inkyfor which nokia n900 was called phone 2.0 in one article.17:13
inkyi use audio calls rarely with jabber.17:14
uvosin no way was the above discussion about using telepathy or not17:14
freemangordonaddressbook is integrated with telepathy(once I finish REing it, ofc)17:15
bencohyeah, it was about low/middle-level integration with the rest of the ecosystem17:15
inkywell may be libpurple is better, i don't know. i mean address book integrated with ability to call or message via different means.17:15
inkyokay, yay.17:16
uvostight integration is fundamentaly an evil17:16
uvosits is only good insofar it adds functionality you cant have otherwise17:16
uvosintegration is a method of last resort to gain sutch functionality17:16
inkyhere i can agree. what makes it tight? i utderstood from the discussion it uses dbus only?17:16
uvosthe audio routing system listens for telepathy dbus signals17:17
uvosonly telepathy can own its dbus name17:17
inkyi am always proponent of modularity and extensibility17:17
uvosthus only telepathy can change the audio state17:17
uvosunless you add another parrallel controll method17:17
Wizzupuvos: no, not only telepathy, it can use other info too18:34
uvossure but it uses telepathy info18:36
uvosand anyhow it should use no info18:36
uvosits fundamently wrong for a low-level part of the stack to look at what the higher level parts and do something based on the state18:37
uvosthe directive flow direction from end user application to hardware must be maintained18:38
WizzupI wouldn't argue it's lower part of the stack18:39
uvos? its doing hardware state mangement18:39
uvosthats clearly lower level than what amounts to a fancy dialer18:40
uvosdialer backend rather18:40
Wizzupspecifically it implement hardware state mnagemente based on high-level policies18:50
uvosright18:51
Wizzupafk for the night I think :)18:51
Wizzup\o18:52
uvosi dont think you can convice me that it basing the execution of those policies on information i gathers rather than information it recives is sane18:52
uvosgood night18:52
WizzupTime will tell ;)19:02
WizzupI think there is a lot to be said for services exporting their own information over dbus, which is how it works for pretty much every dbus service, and other programs reading that info to manage the hw state19:02
Wizzupok, actually bbl now19:02
uvos"I think there is a lot to be said for services exporting their own information over dbus, which is how it works for pretty much every dbus service, and other programs reading that info to manage the hw state" where the thing using the interface is higher up the stack sure19:03
uvosthats not the case here19:03
uvoslike (very relevant example) mce gets told by something using its interface that device is now in a call19:05
uvosit dosent go looking around on dbus to look and see if some specific call application is currently running/active19:05
uvosand thats the right way to do it19:05
uvossome thin (also very relevant example) with pa, it gets told by something useing its interfaces what profile to apply to the hw state19:09
uvos*same thing19:09

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