panzeroceania has quit [Read error: Connection reset by peer]
nohit has quit [Ping timeout: 268 seconds]
Pali has quit [Ping timeout: 256 seconds]
nohit has joined #maemo-leste
panzeroceania has joined #maemo-leste
xmn has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Guest3 has joined #maemo-leste
Guest3 has quit [Client Quit]
mardy has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
<mighty17[m]> freemangordon: weston 9 is fine? :P
<freemangordon> what do you mean "fine"?
<mighty17[m]> well will it work with your mesa?
<mighty17[m]> freemangordon: weston 9 works with your mesa :o
<freemangordon> ah
<freemangordon> good
<freemangordon> so, there is some issue with sway?
<mighty17[m]> sway? i've been using phosh xD
<freemangordon> ah, yeah
<mighty17[m]> weston logs https://paste.debian.net/1219109/
<mighty17[m]> freemangordon: actually, its using llvm
<mighty17[m]> or how do i confirm that?
<mighty17[m]> s/1219109/1219111/
<mighty17[m]> freemangordon: looks like only weston works
<mighty17[m]> can you give phosh a try?
<mighty17[m]> or or I'll use xc-racer's mesa but apply your commits on top?
<mighty17[m]> i suppose i dont need to leste changes as well
<freemangordon> mighty17[m]: ok, I can give ti a try, but, care to link to a repo to use?
<freemangordon> or, it should be pre-build?
<freemangordon> "E: Unable to locate package phosh"
<mighty17[m]> freemangordon: It's in debian
<freemangordon> it is not
<freemangordon> at least not in devuan we use
<mighty17[m]> In sid and bullseye
<freemangordon> good, but we are on older distro, iiuc
<freemangordon> anyway, will look at it when I have time
<mighty17[m]> Sure, till then I'll try getting your commits on xc racer's tree
<mighty17[m]> Idk which are important tho, probably not the rebases and leste ones for me
<freemangordon> I think it will be easier to merge xc racer's commits
<freemangordon> because my changes are based not his tree
<freemangordon> so there should be only few commits missing
pere has quit [Ping timeout: 268 seconds]
<mighty17[m]> I know, but what if some commit breaks stuff for me, that's why I'd probably cherry pick
Pali has joined #maemo-leste
pere has joined #maemo-leste
Pali has quit [Ping timeout: 264 seconds]
<mighty17[m]> freemangordon: basically all commits by you since `Oct 29, 2021`
akossh has joined #maemo-leste
xmn has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> hi
<uvos> looks like i got baned again on libera chat
<uvos> <bencoh> funnily enough, pvr_dri points to nouveau_vieux.so btw" that cant be right
<uvos> build system must be confused somehow
<Wizzup> uvos: ugh @ ban
<bencoh> uvos: well, feel free to check http://muarf.org/~bencoh/maemo/leste/mesa-pvr-ti/
Langoor has joined #maemo-leste
<bencoh> may I ask why the Status tables on the n900/droid4 pages were renamed to "old status"?
<bencoh> is there a new per-device status table?
<Wizzup> the old status can go basically
<Wizzup> the new status is on the top right of the page
<bencoh> the "Software features"?
<Wizzup> yeah
xmn has quit [Ping timeout: 250 seconds]
pere has quit [Ping timeout: 245 seconds]
<Wizzup> probably the old status can go
pere has joined #maemo-leste
panzeroceania has quit [Ping timeout: 264 seconds]
nohit_ has joined #maemo-leste
nohit has quit [Ping timeout: 268 seconds]
nohit_ is now known as nohit
panzeroceania has joined #maemo-leste
<uvos> new sphone: storage plugin api implemented via rtcom and used for call history (not sms/messages yet) by gui, various small improvements
<uvos> it uses local-uid as /sphone/$(BACKEND)/%(LINE_ID)
<uvos> it absoulty needs to know the backend a call/msg was made on
<uvos> but im open to alternative routes for storing this
<uvos> not sure what the HEADERS are for/should contain so sphone ignores this, Wizzup if you figure this out pleas do tell
<dsc__> inside the VM, with Dorian, when you click this button: https://i.imgur.com/ED3wWiP.png
<Wizzup> what is line-id?
<dsc__> screen will go all-black, and only option is to reset
<dsc__> afterwards; every time you open Dorian, it will go all-black
<Wizzup> dsc__: hm sounds like your VM has trouble with rotated screens
<dsc__> unless you remove /home/user/.config/Pipacs/Dorian.conf
<dsc__> ah
<Wizzup> dsc__: let me try it in my vm momentarily
<uvos> Wizzup: sphones internal name for phone number or user name or whatever the $(BACKEND) needs to connect to this person.
Danct12 has quit [Remote host closed the connection]
<Wizzup> what phone number is that? the person that calls you?
<uvos> same as remote-uid i rtcom (and sphone sets it here to)
<uvos> yes the id of the remote party
dsc__ is now known as dsc_
<Wizzup> that's wrong
<Wizzup> sqlite> select distinct local_uid from events;
<Wizzup> sofiasip/sip/merlijnwajer_40ekiga_2enet0
<Wizzup> ring/tel/ring
<Wizzup> spirit/skype/wizzy_2e_2e0
<uvos> in backend dependant form
Danct12 has joined #maemo-leste
<Wizzup> remote_uid is the other party
<Wizzup> local_uid is just you
<uvos> ok
<uvos> so where shal i shove the backend?
<Wizzup> this should be apparement from fremantle db
<Wizzup> apparent
<Wizzup> typically it goes in remote_uid, but I cannot comment on the exact form
<Wizzup> it looks like for tp-ring the remote_uid is just the number that calls you, for sip it's the sip:foo number that calls you
<Wizzup> and for irc etc it's the irc nick that chats (not sure how that works in groups atm)
<Wizzup> all of this can be set up on fremantle with ease fwiw
<uvos> well problem is this is all very ill defined
<Wizzup> (and yeah I've been overloaded with real life work so didn't get much further yet :-))
<uvos> seams like they just have backends randomly insert different strings
<Wizzup> from my notes:
<Wizzup> local_uid TEXT, -- plugin local uid ('account' on a plugin/protocol)
<Wizzup> local_name TEXT, -- seems to own irc nickname, etc <SelfHandle> for telepathy-ring
<uvos> so local_uid should just be sphone/something then?
<Wizzup> remote_uid TEXT,
<Wizzup> channel TEXT, -- channel for an event
<Wizzup> yes, but this must also be registered as service I think
<uvos> no
<uvos> servcies are seperate
<Wizzup> right, yeah
<Wizzup> just checked with sql
<uvos> so how about local_uid: sphone/sphone remote_uid: %(BACKEND):(%LINE_ID), local_name: unix username
<Wizzup> well, I gave you an example for telepathy-ring, the remote_uid is just the phone number
<Wizzup> I don't see the point of the unix username, but for telepathy-ring the local_name is not too relevant anyway
<Wizzup> (in empathy it's also '<SelfHandle>')
<uvos> Wizzup: right except the example is ill defined for modem calls its just the number and for sip is the protcoll (sip) and then the number
<uvos> sphone dosent/ dosent want to treat ofono calls as special somehow
<Wizzup> I don't understand
<uvos> if i place just the number into remote-uid and have an entry for +4945487125457
<uvos> how is sphone supposed to know this was a telegram call and calling back on this event shal use that backend instead of ofono
<Wizzup> the local_uid indicates the plugin used
<Wizzup> there's also the event type
<Wizzup> the event type is normal call, or sip call, etc, afaik
<Wizzup> so that way you could know
<uvos> no
<uvos> those dont exist in the plugins we have atleast
<uvos> you could define those sure
<Wizzup> 'those'?
<uvos> more event types
<uvos> "the local_uid indicates the plugin used" no it dosent
<Wizzup> 2|RTCOM_EL_EVENTTYPE_CALL_MISSED|1|Missed call
<Wizzup> sqlite> select * from eventtypes;
<Wizzup> 1|RTCOM_EL_EVENTTYPE_CALL|1|Call
<Wizzup> 3|RTCOM_EL_EVENTTYPE_CALL_VOICEMAIL|1|Voicemail message
<uvos> its just a phone number
<Wizzup> uvos: no, local_uid is not a phone number
<Wizzup> local_uid is ring/tel/ring for example
<Wizzup> remote_uid is the phone number
<uvos> er right
<uvos> so have local_uid as sphone/$(BACKEND)
<uvos> and remote_uid as just the line_id
<Wizzup> that's how fremantle does it it looks like
<Wizzup> there might be more to it and in particular the chat types and stuff I haven't grasped fully
<uvos> well thats not terribly important rn
<uvos> for sphone at least
<Wizzup> example for sip calls:
<Wizzup> 33771|1|1|1629194398|1629194396|0|0|1|0|0|0|sofiasip/sip/sip_2exs4all_2enl0||sip:+3161xxxxxxx@sip.xs4all.nl|||
<uvos> anyhow the functions to translate sphones internal reprisentation -> rtcom and back are here in this plugin: https://github.com/maemo-leste/sphone/blob/f1881b09c414835f5ed061c2b7a751ee4c14932b/src/modules/store-rtcom.c#L129
<uvos> rtcom_el_iter_get_values is fun
<uvos> because the values of the entrys just randomly change (not defined anywhere) names
<Wizzup> I don't understand what you mean
nohit has quit [Ping timeout: 260 seconds]
panzeroceania has quit [Ping timeout: 264 seconds]
<uvos> im just harping on the api
<uvos> you RTCOM_EL_EVENT_SET_FIELD(ev, event_type, g_strdup("RTCOM_EL_EVENTTYPE_CALL_MISSED"));
<uvos> (with RTCOM_EL_EVENTTYPE_CALL_MISSED being a magic string)
<Wizzup> like I said, those need to be defined in some headers
<Wizzup> parts of this were closed source, and we probably lack those headers
<uvos> then you cant get event_type
<Wizzup> ?
<uvos> because its event-type-id now and magicly became a int
<uvos> but if you add start_time it gets translated to start-time
<uvos> and stays an int
<Wizzup> of course the database uses ints
<Wizzup> you can probably set the "event-type-id" properly
<Wizzup> property*
<Wizzup> (I haven't checked, just a guess)
<uvos> Wizzup: right but the api just randomly translates some strings to ints and not others
<uvos> and your suposed to just now
<uvos> it also translates the field names
<uvos> and your suposed to just know that the input field name free_text becomes free-text when you need the field again
<uvos> its a mess
<Wizzup> I never used RTCOM_EL_EVENT_SET_FIELD
<Wizzup> I used the gobject properties
<Wizzup> which seemed like how they want it to be used
<Wizzup> but again I cannot attack or defend the API
<uvos> i kind of doubt that they have that macro and use it in the unit test beacuse they dont want it used but ok
panzeroceania has joined #maemo-leste
<Wizzup> uvos: the unit test might not be the best example of public api
<Wizzup> did you look at code of rtcom-eventlogger-ui as well?
<Wizzup> I don't know if it is any different
<uvos> its N/A since it dosent add any events
<Wizzup> I think it had code to add events actually
<Wizzup> which is commented in the main()
<Wizzup> in the example
<Wizzup> see log_some_stuff
<uvos> RTCOM_EL_EVENT_SET_FIELD
<Wizzup> look that uses the string api
<uvos> so yeah
<Wizzup> looks like*
<Wizzup> in any case what I still want to clear up how we can efficiently separate out different protocols
<Wizzup> I'd like to split sip/telegram/signal/ring/xmpp or at least filter by them
<Wizzup> but in the current plugins xmpp/telegram/signal are all the same rtcom plugin
<Wizzup> and the same event types
<Wizzup> so I guess there's just local_uid for that
<Wizzup> but the local_uid is a string and we'd have to match a part of the string or something, which is yuck
<uvos> yeah right
<Wizzup> since they all use service_id RTCOM_EL_SERVICE_CHAT
<uvos> thats what sphone dose rn
<uvos> ie match sphone/ofono
<uvos> and call with ofono
<Wizzup> I don't want to do that really
<uvos> right
<uvos> also same problem with RTCOM_EL_SERVICE_CALL
<Wizzup> but I will worry about this once the telepathy logging works
<Wizzup> wrt call, you mean sip vs ring?
<uvos> i assumed RTCOM_EL_SERVICE_CHAT was for messages
<Wizzup> oh, good point
<uvos> or telegram whatsapp whatever
<Wizzup> I'd have to check skype calls
<uvos> not just "sip"
<Wizzup> I can check that actually
<Wizzup> sec
<Wizzup> sqlite> select distinct event_type_id from events where local_uid='spirit/skype/wizzy_2e_2e0';
<Wizzup> 1
<Wizzup> and:
<Wizzup> sqlite> select * from eventtypes where id=1;
<Wizzup> 4
<Wizzup> 6
<Wizzup> 1|RTCOM_EL_EVENTTYPE_CALL|1|Call
<Wizzup> sqlite> select * from eventtypes where id=4;
<Wizzup> 4|RTCOM_EL_EVENTTYPE_CHAT_MESSAGE|2|Normal message
<Wizzup> sqlite> select * from eventtypes where id=6;
<Wizzup> 6|RTCOM_EL_EVENTTYPE_CHAT_ACTION|2|Action message
<Wizzup> looks like you're correct
nohit has joined #maemo-leste
<Wizzup> uvos: got any idea on how to solve above problem?
<Wizzup> apart from string-matching local_uid
<Wizzup> we could make it different services with shared event types
<Wizzup> although I am not sure if that breaks the model somehow
<Wizzup> uvos: potentially flags.... somehow
<Wizzup> or we could change the database model.
<Wizzup> and provide a migration tool
<uvos> downside to different services is that you need a plugin for it
<uvos> so everything needs to register a plugin for dubious benefit
<uvos> sure we could add a packend field that gets filled with a uuid
<Wizzup> well I don't see why all chat really fits in one plugin though
<uvos> no idea what the flags are for
<Wizzup> by that logic I think sms and chat should be the same plugin
<uvos> the question is what is the point of the plugins even
<Wizzup> they offer helper functions for plugin specific code
<uvos> "the plugins exist to offer helper functions to the plugins"
<uvos> heh
<uvos> no seriously i dont know what the benefit of having the plugins is over RTCOM_EL_SERVICE_CALL just being a enum
<Wizzup> uvos: did you look at the plugin code?
<uvos> i did
<Wizzup> btw, the remotes table might also be relevant somehow, but IDK who writes to it
<Wizzup> I think it maps local_uid, remote_uid to remote_name and osso abook id
<uvos> the plugins really just seam like a half implemented idea that dident go anywhere
<uvos> like they where supposed to have wrappers for adding new events in an easy way without the insane RTCOM_EL_EVENT api
<uvos> and sutch
<uvos> ie abstract the database more, rn rtcom-eventlogger is a farily thin wrapper around the raw sql database
<Wizzup> well, we can do that
<uvos> not sure we want tho
<uvos> since then you need to maintain a rtcom plugin for every protocoll
<Wizzup> why is that?
<uvos> seams not sufficantly benifical
<Wizzup> ok so what about another table protocol and give events a protocol_id ?
<uvos> sure
<uvos> how is protocol_id generated?
<uvos> just have the issuer generate a uuid?
<Wizzup> well I would suggest it gets inserted once and doesn't change - i.e. you can't delete it
<Wizzup> no, I would suggest the protocol table is basically (1, 'telepathy-ring'), (2, 'telepathy-morse'), etc
<uvos> ok so you want to add a function to eventlogger that inserts a new protocol
<Wizzup> yes, probably to the plugins ;)
<Wizzup> since we have no other way of adding things to the db
<uvos> ie int add_some_protocol(const char *name);
<Wizzup> (upon init)
<Wizzup> I wouldn't suggest random applications add a protocol
<Wizzup> I would suggest that's a well controlled and defined list
<uvos> hmm
<uvos> not sure its great that there is then a defined list of protocols you cant change as an app developer
<uvos> like i implement $(SHINY_NEW_PROTOCOL)
<uvos> and then i cant log its events
<Wizzup> and then you get it packaged for maemo/telepathy
<uvos> without submitting a pr etc
<Wizzup> and then we add it :)
<uvos> yeah
<Wizzup> as a dev you can do one INSERT INTO into db the for testing probably
<uvos> but thats not whats gona happen in practice
<uvos> in practice the person with $(SHINY_NEW_PROTOCOL) is gonig to just go
<uvos> oh my protocol is kinda like xmpp so lets just log events like that instead of this headace of geting a patch upstream somewhere
<Wizzup> I think the one detail you are omitting is that when someone implements a tp plugin
<Wizzup> they don't need to take care of the logging
<Wizzup> we have a program that logs tp channels to the db
<uvos> the world dosent nessecarly revolve around tp
<Wizzup> and that is abstracted no matter the protocol
<Wizzup> well rtcom kinda does
<Wizzup> at least in maemo fremantle
<uvos> not at the moment
<uvos> not really
<Wizzup> I haven't discovered anything in there that is not TP
<Wizzup> with ~10 years of usage and events
<uvos> rtcom-eventlogger currently dosent care mutch about where the events come from
<uvos> lets not fix it to tp
<Wizzup> it is not, but our UI code will be
<Wizzup> otherwise we will need to add random plugins for every protocol
<Wizzup> to the UI as well
<Wizzup> which is not scalable
<uvos> no you makeing the assumption that your ui and stack will be the only thing running
<Wizzup> I am assuming that that is the maemo chat integration and other things that don't integrate won't use rtcom :P
<uvos> but people will not like you ui and want to run $(RANDOM_MATRIX_CLIENT) instead
<Wizzup> yeah but I don't think that would log to rtcom
<uvos> and maybe they want to hildonize $(RANDOM_MATRIX_CLIENT)
<uvos> we should allow it
<Wizzup> it could, but I don't understand why they would
<Wizzup> since telepathy already does it
<Wizzup> (telepathy-tank, iiuc)
<Wizzup> supporting libpurple next to tp on the other hand seems interesting to eventually try
<uvos> point is if you dont allow a ecosystem of $(RANDOM_MATRIX_CLIENTS) ported from elsewere to exist on our OS by forceing everyting through tp
<uvos> they wont
<Wizzup> they can exist, but I am not sure why they would log to rtcom?
<Wizzup> they're probably happier using whatever existing logging they have
<uvos> why not? better integraion
<uvos> maybe so, but closing the door is unwise
<Wizzup> slightly better integration, proper integration is in conversations :P
<Wizzup> I'm not really closing the door at all I think
<Wizzup> it's an open platform and people can do what they want
<uvos> conversations can not and will never fit all needs
<Wizzup> I was just trying to figure out a way to make the db schema more amendable to many different tp plugins
<uvos> and this way
<uvos> is bad
<Wizzup> what's bad about it?
<uvos> we just discused that
<Wizzup> I don't see it
<uvos> "adding a proctocoll requires a patch upstream"
<uvos> to the table
<Wizzup> I would say proper integration requires working with upstream, which is common in FOSS
<Wizzup> doesn't stop anyone from just doing INSERT () from their application
<Wizzup> but sure it could a call that does the ~5 line insert code
<Wizzup> I think it's mostly a non-issue
<uvos> we definatly dont want people doing sql calls directly.
<uvos> i think its very mutch an issue
<uvos> compeard to what you suggest i very mutch prefer fremantle status quo even
<Wizzup> only tp?
<Wizzup> (that's fremantle status quo)
<Wizzup> even skype went through TP on fremantle
<Wizzup> they just didn't let you filter on telepathy plugin (protocol) in the UI
<Wizzup> which is what this is mostly about
<Wizzup> at least that's my understanding
<uvos> well they have to strcmp local_uid somewhere
<uvos> to figure out what protocol to use
<uvos> for reply etc
<Wizzup> I don't think they need
<Wizzup> I don't think they need to*
<Wizzup> conversations all revolves around contacts mostly
<Wizzup> and for calls you get the option to use sip (accounts) or regular
<Wizzup> but yeah there must be some way they do that
<Wizzup> in any case I'm more worried about storing plugin specific stuff through tp to begin with
<uvos> ok
<uvos> well youll figure something out
<Wizzup> hopefully :P
<uvos> ill continue to do my thing, adding conversation a thread view to sphones sms-history is next
<uvos> oh btw the dialer
<uvos> dosent force portrait anymore
<Wizzup> <3
<uvos> instead the keypad is hidden
<Wizzup> I'll try it on my n900 momentarily :-p
<uvos> when in landscape
<Wizzup> do you know what it looks like in fremantle btw?
<Wizzup> I can make a screenshot now if you want
<uvos> yes i do
<Wizzup> it's basically split in half
<uvos> i know
<Wizzup> right half is the dialer numbers
<Wizzup> ok ok
<Wizzup> :)
<uvos> i honsely i think its fine rn
<uvos> without the numbers
<Wizzup> I'll check it out
<uvos> hmm maybe on n900 its less fine
<uvos> (no number hwkeys)
<Wizzup> it does support that
<Wizzup> I just tried it
<Wizzup> the input field is set to a special input mode
<uvos> support what?
<Wizzup> so 's' is automatically '+'
<uvos> yeah that
<Wizzup> and 'w' is automatically '2'
<uvos> ok
<uvos> ok
<uvos> btw the hildon opening animation is really janky for sphone
<uvos> because it launches and then infroms the primary instance and then exits immitaly
<uvos> and then the window pops up
<uvos> modest also has this problem
<uvos> not sure if there is a solution to tell hildon to keep the rectangle even if the process exits
<Wizzup> what should I see with modest?
<uvos> with both sphone and modest the rectangle/screenshot spawns then hangs while the new window appears then the new window appears
<uvos> looks janky
<Wizzup> hm I am not sure if I see it with modest
<Wizzup> let me upgrade sphone
<uvos> probubly cant see it on n900 (its to slow)
<Wizzup> I see it on d4 I think
<Wizzup> kind of a minor detail but yeah :p
<uvos> maybe a .desktop key that tells hildon: this launches really fast dont bother with the animation
<uvos> is in order
<Wizzup> that could be a solution yeah
<Wizzup> I think the phone app on fremantle has the same problem
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
elastic_dog has quit [Ping timeout: 268 seconds]
elastic_dog has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
_inky has joined #maemo-leste
Twig has joined #maemo-leste
Pali has joined #maemo-leste
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 240 seconds]
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 250 seconds]
uvos has quit [Read error: Connection reset by peer]
uvos has joined #maemo-leste
Wikiwide has quit [Ping timeout: 240 seconds]
mardy has quit [Quit: WeeChat 2.8]
xmn has joined #maemo-leste
Twig has quit [Ping timeout: 256 seconds]
Wikiwide_ has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
akossh has quit [Quit: Leaving.]
uvos has quit [Ping timeout: 245 seconds]
uvos has joined #maemo-leste
uvos has quit [Ping timeout: 260 seconds]