System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
fab_ has joined #maemo-leste
LeePen has quit [Ping timeout: 255 seconds]
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
nmdv has quit [Ping timeout: 252 seconds]
doc has joined #maemo-leste
<freemangordon>
Wizzup: I am starting to think it is not tp plugins that has to be fixed, but rather conversations does not properly ack incomming messages
<freemangordon>
as I see the same issue with tp-haze and FB
<freemangordon>
but yeah, has to debug that
ceene has joined #maemo-leste
<freemangordon>
dsc_: does not seem to work for haze/FB
<freemangordon>
I think I know what happens, but not how to properly fix it :)
<freemangordon>
recently, I implemented chat "seen" support in haze, which relies on chat state. And it does not make messages as seen until chat state is "active" or "typing" etc
<freemangordon>
s/make/mark
<freemangordon>
dsc_: I don;t think your 'duplicates' fix is proper - why do you ignore scrollback messages only?
<freemangordon>
duplicated messages come as new, at least from haze
<freemangordon>
hmm, no idea how to properly fix that
Oksana has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
fab_ has quit [Ping timeout: 240 seconds]
arno11 has joined #maemo-leste
* freemangordon
wonders if we shall move to pidgin 3
<arno11>
freemangordon: hi, i'm a bit confused: you receive duplicate msgs from haze/FB ?
<freemangordon>
yes
<freemangordon>
what happens is:
<freemangordon>
1. couple of messages arrive from FB
<freemangordon>
2. those are send from haze to UI and UI acks them
<freemangordon>
3. internet connection reconnects
<freemangordon>
messages from (1) are received again, as they were not marked as read
<freemangordon>
pidgin has no concept of marking messages as received
<freemangordon>
OTOH, we cannot mark messages as read simply because they were put in the database
<arno11>
ok
Twig has joined #maemo-leste
n900 has quit [Ping timeout: 272 seconds]
<freemangordon>
and purple 2.x has no concept of message id or anything, so we cannot send "received" receipt per message
<freemangordon>
while purple 3.x has
<freemangordon>
it supports message ids and whatnot
<freemangordon>
so I am tempted to try to port haze to libpurple 3
<freemangordon>
though it is way easier to teach UI to just ignore those
LeePen has joined #maemo-leste
<arno11>
indeed, sounds an easier way
arno11 has left #maemo-leste [#maemo-leste]
n900 has joined #maemo-leste
Twig has quit [Remote host closed the connection]
akossh has joined #maemo-leste
fab_ has joined #maemo-leste
parazyd has quit [Ping timeout: 256 seconds]
Livio has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
Cat_ has joined #maemo-leste
Cat_ has quit [Client Quit]
Cat_ has joined #maemo-leste
Cat_ has joined #maemo-leste
Cat_ has quit [Changing host]
<Cat_>
freemangordon i managed to dd the image to the sd card but i dont know how to boot from it
<Cat_>
it seems that samsung devices deprecated booting from sdcards and instead support only booting from recovery/system partitions.
pere has joined #maemo-leste
Cat_ has quit [Ping timeout: 250 seconds]
Cat_ has joined #maemo-leste
Cat_ has quit [Changing host]
Cat_ has joined #maemo-leste
<Cat_>
Wizzup thanks i havent tried the image builder yet and i already have the phone running postmarketOS with 6.8.1 kernel
<Wizzup>
freemangordon: I do not think libpurple3 is ready yet, is it?
<Wizzup>
I am in the pidgin channel and the devs themselves do not seem to be using it yet even
<Wizzup>
Cat_: yeah so try to look at what postmarket os does then, how it boots the sd card and such
<Wizzup>
leste just needs you to load the kernel and a sd card or partition to install leste to
<Cat_>
I think i might be able to boot it from the recovery partition
<Cat_>
if the sdcard option doesnt work
<Wizzup>
well, what does pmos do ?
<Cat_>
i have no idea, it boots from the internal memory
<Wizzup>
ok, this kinds of hits the boundaries of my android knowledge, so it will take some investigation to figure out how to do it
Cat__ has joined #maemo-leste
Cat__ has quit [Quit: Leaving.]
n900 has joined #maemo-leste
Livio has quit [Ping timeout: 240 seconds]
narodnik has quit [Quit: WeeChat 4.3.1]
Cat_1 has joined #maemo-leste
Cat_ has quit [Quit: Client closed]
Cat_1 has left #maemo-leste [#maemo-leste]
Cat_1 has joined #maemo-leste
Cat_1 has left #maemo-leste [#maemo-leste]
Cat_1 has joined #maemo-leste
<freemangordon>
Wizzup: didn't we have some pmos guys in the channel?
<freemangordon>
sicelo: ^^^
n900 has quit [Ping timeout: 255 seconds]
uvos__ has joined #maemo-leste
<uvos__>
They dont boot from recovery
<uvos__>
recovery zips are simply scripts that are executed by the recovery that can do thinks like write new images to partitions
<uvos__>
android bootloaders boot from android boot imgaes off of the boot partition only
<uvos__>
android boot images are a special but well documented/tooled format which packages the kernel, somtimes dts, cdmline etc
<uvos__>
you must simply create a boot image for your device with the kernel source of your device and androids tools and set the cmdline to something apropriate to boot from the sdcard
<uvos__>
flashing your boot.img is easiest via fastboot, for simple cases this makes more sense than to go the whole update.zip route
<freemangordon>
dsc_: I'll push what I think is a proper fix if you don;t object
<freemangordon>
if you object, I'll make a PR, just LMK
<dsc_>
sure :)
<freemangordon>
sure what? puch?
<dsc_>
i think in general you can just push what you want, 9/10 times its good
<freemangordon>
push
<dsc_>
no need to ask
<freemangordon>
well, it is you that maintains that, I prefer to have your opinion anyways
<dsc_>
true
<freemangordon>
but ok
<dsc_>
freemangordon: did you try chat removal yet?
<dsc_>
maybe you have some test channels you can get rido f
<freemangordon>
yes, I did
<freemangordon>
hmm, wait
<freemangordon>
no, I tested chat clear, not removal
<Wizzup>
how is it different
<freemangordon>
I am not sure what chat removal is supposed to do
<dsc_>
with clear the item stays in the overview, albeit empty
<freemangordon>
well, but they are not tehre if you restart conversations
<dsc_>
with clear they will be
<dsc_>
else you wouldnt be able to open a chatwindow of a chat that does not contain any chats yet
<freemangordon>
not really
<freemangordon>
if you want to open a chat, you can always do it from the contact
<freemangordon>
and that's the proper way imo
<Wizzup>
is this true for group chats?
<freemangordon>
no, I guess you have to select it from the (non-existing) list of groups
<freemangordon>
not sure what fremantle conversation do
<freemangordon>
but I would guess they remove group chats from the list
<freemangordon>
dsc_: just tried 'delete chat'
<freemangordon>
did nothing
<freemangordon>
umm...
<freemangordon>
did nothing in the main window
<freemangordon>
the chat remains there, along with the last message
n900 has quit [Ping timeout: 272 seconds]
d4dsc has left #maemo-leste [#maemo-leste]
<dsc_>
^ thats a removal of a groupchat
<dsc_>
freemangordon: what kind of chat did you remove?
d4dsc has joined #maemo-leste
<Wizzup>
I think 'clear chat' should probably just delete it entirely and do the same as delete, I am not sure if we need to differentiate
<freemangordon>
И агрее
<freemangordon>
oops
<freemangordon>
I agree
<dsc_>
that behavior would differ from most chat applications
<freemangordon>
so?
<dsc_>
clearing history versus deletion
<freemangordon>
what exactly is "deletion"?
<freemangordon>
leaving the chat?
<dsc_>
delete is clear + leave + remove from overview
<Wizzup>
imo if the messages are gone, why would it remain in the overview?
<freemangordon>
what doe sit mean to 'leave' a non-group chat?
<freemangordon>
Wizzup: :nod:
<dsc_>
groupchats must be listed in the overview regardless of any associated rtcom db entries
<freemangordon>
why would they, unless set for auto-join?
<dsc_>
if there are no messages, it wouldnt be listed after a conversations restart
<freemangordon>
and that's ok
<freemangordon>
but, it must be consistent
<freemangordon>
so, if after restart, empty conversations are not listed, why would they be listed after clear/delete?
<freemangordon>
this is inconsistent
<dsc_>
no, they are listed
<freemangordon>
if empty?
<dsc_>
yes
<freemangordon>
ok, but not peer-to-peer ones
<freemangordon>
so, I think taht at least person-to-person chats shall be removed from the list
<dsc_>
regarding p2p I'd have to check
<freemangordon>
for group chats not sure
<freemangordon>
well, now I have 2 separate chats with my GF :D
<dsc_>
how?
<freemangordon>
after delete
<Wizzup>
disconnect between rtcom db and our model I guess
<dsc_>
ugh :)
<Wizzup>
this is also what happened/happens with sms
<Wizzup>
(let me upgrade and test)
<freemangordon>
the old one remained and new one appeared :)
<Wizzup>
I think it would be the most simple to stay in sync with rtcom db if we can somehow
<Wizzup>
maybe we even reload overview screen from rtcom after a delete for example
<freemangordon>
yeah, restart does not help
<Wizzup>
oh
<Wizzup>
that means there's something funny in the db then?
<freemangordon>
mhm
<dsc_>
Wizzup: we do all these things
<dsc_>
overview has 3 sources
<dsc_>
rtcom, tp, savedUserCfg
<Wizzup>
what does it get from tp?
<dsc_>
these questions are very hard for me to quickly answer, as it is quite a complex thing
<dsc_>
but in general, I had the situation where you joined a groupchat, exit conversations, open again, and it wouldnt show up
<dsc_>
I think it should always show the groupchat you are in
<dsc_>
regardless of offline/online state
<Wizzup>
maybe there can be a special filter with all (open) group chats
<dsc_>
and regardless of any messages present in rtcom db
<Wizzup>
(not sure)
<dsc_>
so regarding clear/removal
<dsc_>
in irssi its:
<dsc_>
/clear
<dsc_>
/wc
<dsc_>
:D
<dsc_>
thats what I did
<dsc_>
we can decide to can one of those if people dont like it
<dsc_>
I think its quite intuitive
<dsc_>
e.g sometimes you want to get rid of some chat history but stay in the groupchat
<freemangordon>
dsc_: I think group chats shall remain only if auto-join is enabled
<freemangordon>
right
<freemangordon>
so, for group chats maybe you just clear the history
<freemangordon>
but in any case, you dont; close the chat window
<freemangordon>
and for p2p you remove it from the list
<freemangordon>
(and don't close the window)
<dsc_>
freemangordon: yeah, that makes sense
<Wizzup>
btw /clear in irssi doesn't delete anything from logs you might have but yeah
akossh has quit [Ping timeout: 255 seconds]
<dsc_>
freemangordon: so if auto-join is disabled, and you press 'clear', you then close the chatwindow - you are still in the groupchat on Tp, but you wont see it in the overview, correct?
<freemangordon>
no, auto-join idea was bad
<Wizzup>
what do you mean?
<freemangordon>
just leave group chats in the list and remove p2p ones
<Wizzup>
ah ok that was in response to your idea
<freemangordon>
right
<dsc_>
ah ok
<freemangordon>
maybe remove group chats when you leave the group
<freemangordon>
hmm, no
<dsc_>
if we keep groupchats in the overview, how do you get rid of them?
<freemangordon>
only remove group chats if you have left the group and clear the conversations :D
<freemangordon>
s/conversations/history
<dsc_>
right
<freemangordon>
can't think of anything better now
<Wizzup>
so this could rely just on rtcom and tp (for currently active channels) then
<freemangordon>
no, I think this will use the saved config too
<dsc_>
something tells me there will be situations where just relying on those 2 will yield confusing results
<freemangordon>
because on startup you have no other source for group chtas, no?
<dsc_>
right
<Wizzup>
the config will tell you what to join
<Wizzup>
not what to render
<freemangordon>
it will tell you to show empty group chats in the list
<Wizzup>
and if you've ever joined it before it will be in rtcom
<dsc_>
it wont
<freemangordon>
not if you cleared the group chat before restart
<dsc_>
only on messages
<freemangordon>
mhm
<Wizzup>
ok then
<Wizzup>
I'd prefer to have as little source as possible, but if it's not realistically possible to avoid
<freemangordon>
so in order to be able to send a new message on a freshly cleared group chat, you need saved settings, IIUC
<Wizzup>
this seems like a very nice thing I think, but ok :D
<dsc_>
freemangordon: yeah, and we cannot rely on Tp here because IIRC. it will only signal that it is part of channels if the account is online
<Wizzup>
seems like people could just rejoin
<freemangordon>
Wizzup: unless we keep some weird row in rtcom
<freemangordon>
but that'd be a hack I guess
<dsc_>
registering join events is very annoying for my limit/offset queries :P
<dsc_>
can do, but will be less performant
<freemangordon>
I can't comment there, you are the ones who know rtcom
mdz has quit [Ping timeout: 264 seconds]
<dsc_>
not just performance, just annoying
<dsc_>
so in general
<freemangordon>
dsc_: please have a look to what I pushed and perhaps make a new release as there is a fix for a segfault on re-connect
<dsc_>
ok
<dsc_>
freemangordon: I would also like some info about your double-GF situation
<dsc_>
it stays after a restart, yes?
<freemangordon>
yes
<dsc_>
and its p2p
<freemangordon>
but maybe it is a local issue
<freemangordon>
because I was missing part of p2p patch
<freemangordon>
oops
<dsc_>
ok
<freemangordon>
part of event_id patch
<freemangordon>
no idea if that matters
<dsc_>
that patch is irrelevant
<dsc_>
to this problem
<dsc_>
I think
<freemangordon>
ok
<freemangordon>
so, I deleted the chat and then sent a message
<freemangordon>
it was not sent
<freemangordon>
but instead I got an error
<dsc_>
how did you send a new message? via contacts?
<freemangordon>
no, the chat window remained opened I think
<freemangordon>
lemme try to repro
<dsc_>
Wizzup: did you try chat clear/removal yet?
<freemangordon>
dsc_: ok, delete a chat (that closes the chat window, but leaves the chat in the list), then click on the chat in the list
<freemangordon>
ugh, wait
<freemangordon>
I have some issue with git merge it seems
<freemangordon>
lemme see what's going on
pere has joined #maemo-leste
<dsc_>
delete should: clear rtcom by GROUP_UID, leave the channel (if groupchat), close the window, and remove it from the overview
<dsc_>
clear should: clear the chat and keep it in the overview
<freemangordon>
delete does not remove p2p chat from the overview here
<freemangordon>
ok, no issue with git
<freemangordon>
it was an issue on my d4, where I was on a wring branch
<dsc_>
check
<dsc_>
and after a restart, the p2p chat is probably removed from the overview
<dsc_>
let me verify
d4dsc has left #maemo-leste [#maemo-leste]
d4dsc has joined #maemo-leste
<dsc_>
ok yep
amunizp has quit [Quit: Not sure what quit means.]
<freemangordon>
no
<freemangordon>
not here
<dsc_>
it should remove it from the overview, but it does not (for p2p)
<freemangordon>
as the failed message was put in the db
amunizp has joined #maemo-leste
<freemangordon>
ah, yeah
<dsc_>
for groupchats, current master works as I intended
<freemangordon>
ok
<freemangordon>
could be
n900 has joined #maemo-leste
<freemangordon>
dsc_: it is removed after restart only if you didn't abuse it before restart by typing something in the chat window
<dsc_>
right
<dsc_>
yes thats wrong
<dsc_>
will fix
<dsc_>
and also do what you said Re: groupchats
<freemangordon>
ok, cool
<freemangordon>
great
<freemangordon>
perhaps still make a new release before that, because of the segfault fix
<dsc_>
reading the diffs
<freemangordon>
ok
<dsc_>
well, I said I will do what you said Re: groupchats but I have not thought of all the "situations" (states) it could possibly go into
<dsc_>
so will verify we can actually do that
<freemangordon>
yeah, makes sense
<freemangordon>
I think it should be ok, but I could have missed some corner case
<dsc_>
i think so too
<dsc_>
(that it will work)
<freemangordon>
dsc_: one more thing: I am not sure how 'own' scrollback messages are stored in rtcom db, but they appear in addressbook 'recent contacts'
<Wizzup>
this is probably something for us to figure out
<Wizzup>
(fmg)
<freemangordon>
yeah, maybe
<freemangordon>
I'll trace what log_event does
<Wizzup>
this depends on the recent contacts query
<freemangordon>
oh, remote_alias is nullptr for message sent from the device
<dsc_>
sqlite> select * from GroupCache;
<dsc_>
8|3|idle/irc/dscqemu0-##maemotest|8|8|0
<dsc_>
interesting
<freemangordon>
Wizzup: could that remote_alias make the difference
* freemangordon
checks
System_Error has quit [Ping timeout: 260 seconds]
<dsc_>
new build btw
<freemangordon>
dsc_: wait
<freemangordon>
(if not late :) )
<freemangordon>
I have another fix, just have to make the commit
<dsc_>
more contributions are always good :)
<dsc_>
and yes you are too late
<freemangordon>
ok, I have to test it anyways :)
System_Error has joined #maemo-leste
<dsc_>
so we can look into how to get rid of the config stuff in lib/tp.cpp
<dsc_>
its a bit strange to me, pragmatic solution to save persistent data related to TelepathyChannels:
<dsc_>
- auto-join
<dsc_>
- last message received (prevent duplicates)
<dsc_>
- render things in the overview, needed in some situations
<dsc_>
perhaps for all 3 points we can find solutions in favor of getting rid of `AccountChannel*`
<dsc_>
e.g: how to save auto-join in rtcom somehow
<freemangordon>
I don;t think that belongs to rtcom
<freemangordon>
this is application setting
<dsc_>
true
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
Danct12 has quit [Remote host closed the connection]
<dsc_>
what `AccountChannel*` does is create a temp. obj that represents a channel, in the case Tp has not given us this channel yet
Danct12 has joined #maemo-leste
n900 has quit [Ping timeout: 240 seconds]
<dsc_>
architecturally, it is a bit suspicious
<freemangordon>
well, I was wondering why it is needed