| Wizzup | uvos: I don't know if something changed but I just received a message that I sent to someone on telegram earlier using the web interface | 00:16 |
|---|---|---|
| Wizzup | latest tp-haze and conversations | 00:16 |
| Wizzup | it does not seem to have been logged though, I will investigate | 00:18 |
| Wizzup | there is an issue however with telegram logging when you make it a contact I think | 00:21 |
| Wizzup | I see a group_uid like haze/telegram_tdlib/_asdfasf and haze/telegram_tdlib/_asdfasf-ContactName | 00:21 |
| Wizzup | so they do not get grouped well | 00:21 |
| Wizzup | the self messages do not get logged correctly either, they get logged like it is a new contact | 00:31 |
| Wizzup | my last message is incorrect, the group uid was ok | 01:44 |
| freemangordon | Wizzup: yes, something changed: https://github.com/maemo-leste-upstream-forks/telepathy-haze/commits/maemo/chimaera-devel | 07:19 |
| freemangordon | in particular https://github.com/maemo-leste-upstream-forks/telepathy-haze/commit/686e10be593ad757a26728e505ba4747e0e5749f | 07:19 |
| freemangordon | and yes, self messages are incorrectly logged | 07:19 |
| freemangordon | at least with haze/fb remote messages appear in conversations like if they were from the other party | 07:21 |
| freemangordon | dsc_: perhaps valgrind can help | 07:23 |
| freemangordon | or libasan | 07:24 |
| freemangordon | you just need to find a way to make conversations exit properly | 07:25 |
| Wizzup | freemangordon: they do appear like that bad the group_uid is ok, so I will investigate | 11:05 |
| Wizzup | like that but* | 11:06 |
| freemangordon | ok, thanks | 11:08 |
| freemangordon | also, I wonder if we have scrollback support | 11:08 |
| freemangordon | Wizzup: shall I have a look to stop notification being issues for the currently active chat on a new message arrival? | 11:09 |
| freemangordon | we just need a simple 'click' sound or something | 11:09 |
| Wizzup | what do you mean with 'scrollback support' ? | 11:10 |
| freemangordon | when device is not locked that is ;) | 11:10 |
| freemangordon | full history of a chat | 11:10 |
| freemangordon | or partial history | 11:10 |
| Wizzup | that I understand, but this is also telepathy concept so I am trying to understand what you refer to :D | 11:10 |
| freemangordon | yes, that's what I meant - tp concept of scrollback | 11:11 |
| freemangordon | I already added some support for group chats | 11:11 |
| Wizzup | ok, so what we would need for this (ideally) | 11:15 |
| Wizzup | 1. matching scrollback matches to existing history | 11:15 |
| Wizzup | 2. getting the right scrollback that we actually need (optional, requires also protocol specific stuff) | 11:15 |
| Wizzup | right now we get the same scrollback every time you join a channel and we log it | 11:16 |
| Wizzup | so we get ots of double messages | 11:16 |
| freemangordon | umm, how's that (same scrollback)? | 11:20 |
| freemangordon | which proto os that? | 11:21 |
| freemangordon | as I fixed haze (with fb at least) for 'seen' support | 11:21 |
| freemangordon | so no more duplicated messages shall arrive | 11:21 |
| freemangordon | however, now we miss the 'seen on other devices' history | 11:22 |
| freemangordon | BTW, I think TP concept of matching is by message itself | 11:24 |
| freemangordon | like, message ids are not really usefull | 11:24 |
| freemangordon | but I think we can easily implement that by keeping a message text hash in the DB | 11:24 |
| freemangordon | so we can match lists of consecutive hashes, which should be trivial | 11:25 |
| Wizzup | 11:24 < freemangordon> BTW, I think TP concept of matching is by message itself | 11:26 |
| Wizzup | this might be true, but that won't work for some protocols | 11:27 |
| Wizzup | for MAM | 11:27 |
| Wizzup | (in xmpp) | 11:27 |
| freemangordon | https://telepathy.freedesktop.org/doc/telepathy-glib-1/TpMessage.html#tp-message-dup-token | 11:27 |
| Wizzup | but yes, we should try to match scrollback to existing messages as step 1 | 11:27 |
| freemangordon | I don;t think we have any other option | 11:28 |
| freemangordon | see ^^^ | 11:28 |
| Wizzup | yeah so in xmpp when done right I think this will be | 11:28 |
| Wizzup | but for others it might not be | 11:28 |
| freemangordon | sorry, can;t parse | 11:28 |
| freemangordon | xmpp or not, we have TpMessage, period :) | 11:29 |
| Wizzup | the message token can be unique there | 11:29 |
| freemangordon | *can* | 11:29 |
| freemangordon | but is not guaranteed by the specs | 11:29 |
| Wizzup | well if we can't do message archive management and such we will need to extend TP to be able to do it | 11:29 |
| freemangordon | no | 11:29 |
| freemangordon | we just keep hash of the text for every message | 11:29 |
| Wizzup | https://xmpp.org/extensions/xep-0313.html | 11:29 |
| freemangordon | and do 'message window' matching upon scrollback message being received | 11:30 |
| freemangordon | also, I think we have message timestamp | 11:30 |
| freemangordon | hash+ts should be enough to uniwue identify a message | 11:30 |
| Wizzup | ok, I think you may want to reconsider this after some reading | 11:31 |
| freemangordon | mhm | 11:31 |
| Wizzup | if you can for example ask for the latest received message on the client side you can inform the server what to send to you | 11:31 |
| Wizzup | for this some own custom hash won't suffice, you need the protocol specific message id | 11:32 |
| Wizzup | this is the 'right' solution to getting the messages you want, not just the unread ones as facebook does currently for you | 11:32 |
| freemangordon | no, FB can do the full history | 11:32 |
| Wizzup | and this requires storing at least some message ids locally, potentially more, but that is just how this ought to work | 11:32 |
| Wizzup | ok, but I doubt that you want the full history every time, and with message markers as in xmpp I think you have a much cleaner and easier way to get what you need | 11:33 |
| Wizzup | again we don't need this now and gabble can't even do it | 11:33 |
| Wizzup | just things to consider before we start filling db fields :D | 11:33 |
| freemangordon | right | 11:33 |
| Wizzup | (gabble can't even do it -now-) | 11:33 |
| freemangordon | re FB: you request the last N messages | 11:33 |
| freemangordon | or full history | 11:34 |
| freemangordon | not sure how's that supposed to work | 11:34 |
| freemangordon | I guess it is same/similar for xmpp | 11:34 |
| * freemangordon reads the specs again | 11:34 | |
| freemangordon | oh, it seems I misunderstood it | 11:35 |
| freemangordon | "This is not guaranteed to be unique, even within the scope of a single channel or contact: the only guarantee made is that two messages with different non-empty tokens are different messages." | 11:36 |
| freemangordon | I am not sure I can grok the "...he only guarantee made is that two messages with different non-empty tokens are different messages." part | 11:36 |
| Wizzup | It is probably intentionally vague | 11:41 |
| freemangordon | hmm, libpurple does not seem to provide message ids :( | 11:47 |
| Wizzup | https://github.com/petermolnar/awesome-pidgin-plugins | 11:52 |
| Wizzup | https://issues.imfreedom.org/issue/PIDGIN-15653/Support-XEP-0313-aka-MAM-Message-Archive-Mgmt | 11:52 |
| Wizzup | so there's pidgin fork/changes with message markers for example | 11:53 |
| Wizzup | also omemo plugins, would be interesting if we could just load those somehow | 11:54 |
| Wizzup | this would of course be for tp-haze not gabble (these plugins) | 11:57 |
| freemangordon | ok, what is the status of pidgin3? | 11:58 |
| freemangordon | #pidgin | 12:00 |
| freemangordon | maybe join ^^^ | 12:01 |
| Wizzup | k | 12:02 |
| Wizzup | I wouldn't look at that now | 12:02 |
| Wizzup | we have all we need to make this work on pidgin2 I think | 12:02 |
| Wizzup | see my links bove | 12:02 |
| freemangordon | they say they use timestamps, which is not exactly message ids | 12:33 |
| freemangordon | buok, lets not focus on that now, we have more issues | 12:34 |
| arno11 | weird: on my N900 conversations UI is still very slow to launch from hildon icon (around 10 sec, even after the first time). but if i start it from a fb chat or sms notification, it starts in 2 or 4 sec max. | 13:22 |
| arno11 | *2-4 sec max to show UI and chat window | 13:25 |
| Wizzup | this is because the first one launches conversations for conversations to find out it is already running and activating itself | 13:26 |
| Wizzup | the second one I believe just lets conversations know on dbus that it needs to show itself | 13:26 |
| Wizzup | we can probably have the conversations desktop icon also be a similar dbus call | 13:27 |
| dsc_ | 10sec while its already in the background? | 13:31 |
| arno11 | yes | 13:31 |
| arno11 | but not from notifications | 13:31 |
| dsc_ | right | 13:31 |
| dsc_ | its because clicking on a notification will just raise conversations | 13:31 |
| dsc_ | while clicking will actually start a 2nd instance, at which point it finds out that its already running, and exit, and raise the original one | 13:32 |
| Wizzup | dsc_: I think we are in agreement ;) | 13:32 |
| dsc_ | yes | 13:32 |
| Wizzup | but we can have dbus start conversations potentially, and then make the icon just do a dbus call | 13:33 |
| arno11 | lol indeed you are | 13:33 |
| arno11 | makes sense imo | 13:33 |
| dsc_ | is there something in dbus that can prevent running something 2 times? | 13:34 |
| dsc_ | how does it check if it is already running? | 13:34 |
| dsc_ | or do we then just launch a bash script that checks a lockfile | 13:35 |
| uvos | The problem ist that QApplication::QAppilcation() takes way to long | 13:43 |
| uvos | sphone also has this problem, when run with a qt module starting sphone via the icon takes long and i blocks in this call | 13:43 |
| uvos | if no qt module is used with sphone it starts and informs the other instance very fast | 13:44 |
| dsc_ | yes, starting conversations just to check if an instance is already active is wasting resources | 13:44 |
| dsc_ | it can be done with something simple | 13:45 |
| uvos | sure, same with sphone, (well sphone is a lot better, since it loads all the modules after checking if it needs to raise the other instance) | 13:45 |
| uvos | but still QApplication::QAppilcation() takes an unresonable amount of time regardless | 13:45 |
| Wizzup | this we could probably really 'fix' with a maemo-launcher qt booster | 13:52 |
| Wizzup | uvos: so sorry to pester you with this, but what can I do on razr with android to see if we can fix the screen issue? | 13:52 |
| uvos | Wizzup: i mean you could look at /diff the DSS registers see page 2192 in the TRM | 14:27 |
| uvos | but its a shot in the fairly dark | 14:27 |
| Wizzup | ok | 14:27 |
| Wizzup | so we think it's likely not a dts issue but rather a driver issue? | 14:27 |
| uvos | could be either really | 14:28 |
| Wizzup | ok | 14:28 |
| Wizzup | and I think for atrix we made some notes on how to make the dts changes, how it was different from the bionic | 14:34 |
| Wizzup | did you host those somewhere? | 14:34 |
| Wizzup | there is the signal map I see | 14:34 |
| kiva | I was 2 1/2 hour MS Teams meeting with Pinephone Keeyboard thru Firefox 115.1. Mic keeps muted so had to write chat of it, when I wated answer. Mic worked about half yeas ago...I think it was bug in M$-code, it did not understand that mic was allowed by Firefox. | 15:26 |
| kiva | wated=wanted | 15:26 |
| kiva | After that meeting there was stll 39% battery left..thanks for two batteries of PPK. | 15:29 |
| kiva | Anyway it might be also good thing that M$ does not know how to listen mic from Maemo Leste device ;) | 15:31 |
| sicelo | teams meeting via phone (3g/4g)? or how? | 15:37 |
| kiva | 4g | 15:37 |
| kiva | connecting with Firefox with 4G internet connection. | 15:38 |
| sicelo | oh wow. teams web? | 15:39 |
| kiva | yes | 15:40 |
| freemangordon | kiva: on leste? you are my hero :) | 16:03 |
| uvos | Wizzup: afaik as i know there is no difference between the atrix and the bionic | 16:04 |
| uvos | sensors and modems aside | 16:04 |
| uvos | i think it would just boot a bionic image | 16:04 |
| Wizzup | uvos: right, but we need to make a dts for the diff sensors at least | 16:06 |
| Wizzup | iirc we made some list on irc of what was different | 16:06 |
| Wizzup | I g2g | 16:06 |
| kiva | freemangordon: ofcourse with Leste. | 16:07 |
| uvos | Wizzup: de decoded the dtb and the signal map | 16:08 |
| uvos | both of those are on my server | 16:08 |
| uvos | you can diff them with bionic for differences | 16:08 |
| uvos | but iirc there are none besides the mentioned sensors and different modem | 16:08 |
| uvos | setup | 16:08 |
| uvos | the real issue is that it needs clownboot which is annoying | 16:09 |
| uvos | you could add dmesg for mb865 seams we lack it | 16:10 |
| Wizzup | uvos: yeah I checked your server :) | 16:46 |
| Wizzup | I think I already got clownboot sorted? | 16:47 |
| Wizzup | I have a working atris 2 with leste here | 16:47 |
| Wizzup | atrix | 16:47 |
| Wizzup | iirc it was the same | 16:47 |
| Wizzup | (as bionic) | 16:47 |
| dsc_ | clownboot? :P | 16:52 |
| Wizzup | double kexec | 16:58 |
| uvos | silly boot method i devised for devices with locked bootloaders that have no known vunerabilities | 16:59 |
| uvos | that involves kexecing twice | 16:59 |
| inky | kiva: i think with chromium you would not have a mic problem. | 22:23 |
| inky | kiva, also advice from a former corporate employee (and jobless now) - i compiled pidgin's teams plugin and i was able to be always online for them from my droid4 and leste. | 22:25 |
| Wizzup | it would be nice/cool to have that packaged like we packaged the other libraries | 23:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!