akossh has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
sch has quit [Ping timeout: 252 seconds]
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
ceene has quit [Ping timeout: 276 seconds]
rafael2k has quit [Remote host closed the connection]
rafael2k has joined #maemo-leste
slep has joined #maemo-leste
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
pere has quit [Ping timeout: 240 seconds]
ceene has joined #maemo-leste
arno11 has joined #maemo-leste
akossh has joined #maemo-leste
<arno11>
Wizzup: freemangordon: i found the trick for FB plugin: when you create-disable-enable an account, 'auto-connect' option is not activated so presence-ui returns 'offline' or 'network disconnected'. Adding auto-connect option to the account through mc-tools solve the issue
ceene has quit [Remote host closed the connection]
<arno11>
now FB plugin works normally and survives after reboot, it shows proper contact names in contacts app, notifications seems to work well
<arno11>
'availability' BTN and green icon are still not visible in status menu btw
<arno11>
same with another protocol like sip
pere has joined #maemo-leste
elastic_dog has quit [Ping timeout: 268 seconds]
arno11 has left #maemo-leste [#maemo-leste]
sch has joined #maemo-leste
elastic_dog has joined #maemo-leste
<Wizzup>
ah, interesting @ auto-connect
<Wizzup>
great find
<Wizzup>
I feel stupid as I was doing this manually yesterday for the discord one I set up but didn't think about letting you know or whether it was a bug
mdz has joined #maemo-leste
<freemangordon>
what is "auto-connect"?
<freemangordon>
there is "Connects: automatically"
<freemangordon>
and this is set by rtcom-accounts-ui for sure
dsc_ has quit [Read error: Connection reset by peer]
antranigv has quit [Ping timeout: 240 seconds]
<freemangordon>
or rather - accounts should not connect automatically
<freemangordon>
but presense-ui should tell them to do so
inky has quit [Ping timeout: 240 seconds]
<freemangordon>
if presence-ui does not work properly, then obviously accounts will not connect
<freemangordon>
arno11: Wizzup: ^^^
antranigv has joined #maemo-leste
<freemangordon>
so I would rather appreciate if someone debug what's wrong instead of just hacking around
<freemangordon>
I will help with debugging
<Wizzup>
I think he is saying it's somehow not being set
<Wizzup>
but I'll take a look as well
<freemangordon>
it should *not* be set
<Wizzup>
mhm
<freemangordon>
because presence ui conencts/disconnects as needed
<freemangordon>
based on various conditions, profile, etc
<freemangordon>
so, it seems we have issue in presense-ui
<freemangordon>
hmm, any clue why /home/user/.config/pulse gets filled with files?
<freemangordon>
Wizzup: BTW, do we really want to keep rtcomel around?
<freemangordon>
what is the issue if we create it adhoc?
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
<arno11>
freemangordon: i just checked on an 'old' clone of my install from few months ago and pulse files were already there, same for the syslog errors btw
<freemangordon>
ok, my those get created on every reboot it seems
<freemangordon>
this cannot be normal
<arno11>
ok
pere has quit [Ping timeout: 252 seconds]
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
* freemangordon
thinks auto keyword should have never been introduced in c++
<freemangordon>
every time a developer uses auto for everything else than lambda, a kitten dies
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
elastic_dog has quit [Ping timeout: 240 seconds]
ceene has quit [Client Quit]
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
<arno11>
freemangordon: able to use gdb with hsm: absolutely no error or crash (and presence-ui works well). we need to trace what's happening on startup IMO
elastic_dog has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
<uvos__>
debuing hildon-status-menu has the added wrinkle that the connui plugin throws sigill because it probes for some instruction we dont have by traping sigill
<uvos__>
but you can just ignore this
<Wizzup>
yeah just continue
<Wizzup>
uvos__: this is openssl doing that btw
<uvos__>
yeah, its a bit confusing at first since seeing sigill is usually some invalid jmp so it makes you think there is some reverse heisenbug
dsc_ has joined #maemo-leste
rafael2k has quit [Read error: Connection reset by peer]
ceene has quit [Remote host closed the connection]
<arno11>
indeed i got sigill/sigint stuff, i just ignored it and continued
<arno11>
i'm currently looking @maemo logs, what is inetstate btw ?
<arno11>
there are plenty of error with that in hildon-status-menu logs
<arno11>
no clue what is it (maybe netstat stuff ?)
<freemangordon>
agree, but the end effect is the same
<uvos__>
having seperate processies would be mutch better
<freemangordon>
or almost the same
<uvos__>
anyhow, to mutch work to change
<freemangordon>
as I said - h-h supports separate processes
<uvos__>
h-s-m dosent
<freemangordon>
right
<uvos__>
also porting all the h-h widgets is also alot of work
<freemangordon>
but that's a trade-off for low memory footprint
<uvos__>
not worth the cost on any 512mb+ device
<uvos__>
it wasent an insane choice i just think its dated
<freemangordon>
won't argue
<freemangordon>
but again, see what rafael2k said about comparison between maemo and the other mobile OSes
<freemangordon>
'snappier', 'faster' etc comes at a cost
<freemangordon>
here we talk about 6 cores 4 GB device
<freemangordon>
albeit allwinner
<freemangordon>
so even on such a performant device maemo being optimized makes lots of difference
<gnarface>
i think the allwinner one is only 2GB
<gnarface>
and 4 cores
<gnarface>
the 6-core/4GB one is rockchip
<gnarface>
not that it's super important, sorry, carry on
<freemangordon>
could be, I didn't really check what the SoC is
<gnarface>
pinephone regular is allwinner, pinephone pro is rockchip
<gnarface>
(i'm in their channel too)
<freemangordon>
I just had remote shell for a while :)
<freemangordon>
but in any case, this one is a beast compared to n900
<freemangordon>
and I think GPU is faster than the one on d4
<gnarface>
i don't doubt it, but anyway, the pinephone regular is not known over there for being fast either, so i only meant the correction to support your point
<freemangordon>
yeah
<freemangordon>
actually it is fast
<freemangordon>
there seems to be some kernel bug that affects IO and makes it super slow
<gnarface>
i'm old, so it's fast to me too... but it does objectively struggle with modern phone software
<freemangordon>
well, I am speaking from 'running maemo on it' POV
<gnarface>
heh, yea i hope they fix the bottlenecks in the kernel, but they're still ironing out power management bugs
<freemangordon>
for PP? Is it still supported?
<gnarface>
sure, as supported as it ever was...
<freemangordon>
heh
<freemangordon>
yeah 'supported'
<gnarface>
it's all reverse-engineered community support by one or two ambitious heros
<gnarface>
heroes*
<freemangordon>
mripard and that what-was-the-nick chinese lady I guess
<gnarface>
since i got it, they've increased standby time from 6 hours to almost 3 days just with power management fixes, but there's still some outstanding power management bugs affecting modem stability on both models, audio device stability on the pro
<freemangordon>
what os is that?
<gnarface>
all of them
<freemangordon>
3 days on PP?
<gnarface>
yea
<gnarface>
3 days STANDBY
<gnarface>
as in, not screen-on time
<freemangordon>
yeah
<gnarface>
turn it on and watch video you still burn through the battery in 1-2 hours at most
<freemangordon>
but, but... it does not support DVFS, no?
<freemangordon>
like, maemo does not susped
<gnarface>
uh... sorry, what's DVFS?
<freemangordon>
*suspend
<freemangordon>
frequency scaling and turning various modules off
<gnarface>
oh, dynamic voltage and frequency scaling... uh, i dunno. i'm no kernel dev
<gnarface>
i do suspect it might be missing support for stuff like this still, yes, but not sure
<gnarface>
or maybe only partial support
<freemangordon>
so, afaik (but don;t quote me on that), you can only suspend and run full-power, more or less
<freemangordon>
so haveing 3 days of standby time is great
<gnarface>
a lot of the performance bottlenecks also seem to come from the graphical layer... particularly gtk/qt programs by default seem to miss a key optimization with using the device's ONE hardware plane right (sorry i don't know how to more correctly state it) and the video driver is just... not finished
<gnarface>
i do think you're right, that just implementing basic suspend on idle was what got us those 3 days
<freemangordon>
modesetting adds to that, by not supporting HW rotation :)
arno11 has left #maemo-leste [#maemo-leste]
cockroach has joined #maemo-leste
elastic_dog has quit [Ping timeout: 276 seconds]
elastic_dog has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
Langoor has quit [Quit: No Ping reply in 180 seconds.]