| 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 | 09:58 |
|---|---|---|
| arno11 | now FB plugin works normally and survives after reboot, it shows proper contact names in contacts app, notifications seems to work well | 10:01 |
| arno11 | 'availability' BTN and green icon are still not visible in status menu btw | 10:03 |
| arno11 | same with another protocol like sip | 10:04 |
| Wizzup | ah, interesting @ auto-connect | 11:00 |
| Wizzup | great find | 11:00 |
| 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 | 11:00 |
| freemangordon | what is "auto-connect"? | 11:13 |
| freemangordon | there is "Connects: automatically" | 11:14 |
| freemangordon | and this is set by rtcom-accounts-ui for sure | 11:14 |
| freemangordon | or rather - accounts should not connect automatically | 11:20 |
| freemangordon | but presense-ui should tell them to do so | 11:20 |
| freemangordon | if presence-ui does not work properly, then obviously accounts will not connect | 11:21 |
| freemangordon | arno11: Wizzup: ^^^ | 11:21 |
| freemangordon | so I would rather appreciate if someone debug what's wrong instead of just hacking around | 11:22 |
| freemangordon | I will help with debugging | 11:22 |
| Wizzup | I think he is saying it's somehow not being set | 11:25 |
| Wizzup | but I'll take a look as well | 11:25 |
| freemangordon | it should *not* be set | 11:27 |
| Wizzup | mhm | 11:28 |
| freemangordon | because presence ui conencts/disconnects as needed | 11:28 |
| freemangordon | based on various conditions, profile, etc | 11:28 |
| freemangordon | so, it seems we have issue in presense-ui | 11:29 |
| freemangordon | Wizzup: arno11: https://github.com/maemo-leste/rtcom-presence-ui/blob/master/lib/pui-master.c#L2164 | 11:37 |
| Wizzup | freemangordon: hm? | 11:57 |
| Wizzup | ah, you think they might not have a presence? | 11:57 |
| freemangordon | I am sure presence-ui hsm plugin is not loaded | 12:02 |
| freemangordon | and that's why all the issues | 12:02 |
| Wizzup | freemangordon: hsm? | 12:27 |
| arno11 | indeed accounts must not be auto-connected, otherwise they auto-connect everytime you turn on wifi or gprs (even if you are offline) | 12:29 |
| arno11 | same question with hsm :P | 12:29 |
| freemangordon | hildon-status-menu | 12:32 |
| freemangordon | arno11: so, could you dsmetool kill h-s-m | 12:32 |
| arno11 | ok | 12:33 |
| freemangordon | and then install rtcom-presence-ui-dbgsym | 12:33 |
| freemangordon | and then: | 12:34 |
| freemangordon | G_MESSAGES_DEBUG=all gdb maemo-summoner | 12:34 |
| freemangordon | and in gdb: | 12:34 |
| freemangordon | r /usr/bin/hildon-status-menu.launch | 12:34 |
| freemangordon | arno11: still here? | 12:40 |
| arno11 | yes currently following what you said | 12:41 |
| freemangordon | ok | 12:41 |
| arno11 | need time (kids around atm...) | 12:42 |
| freemangordon | hehe :) | 12:42 |
| arno11 | back. i got 'no debugging symbols found in maemo-summoner' (remember i use a fresh install, gdb and presence-ui-dbgsym are ok) | 12:52 |
| arno11 | ah, looking @irc logs, it seems we can't debug hildon-status-menu with gdb attached | 13:10 |
| uvos__ | hmm you def can | 13:12 |
| uvos__ | i have done so in the past | 13:13 |
| arno11 | btw when i simply run 'maemo-summoner hildon-status-menu.launch', presence-ui starts normally and green icon works | 13:13 |
| arno11 | and availability BTN as well | 13:13 |
| arno11 | uvos__: ok | 13:13 |
| arno11 | now, even if i delete and add again my account in FB plugin, presence-ui works well | 13:19 |
| arno11 | and when i click on 'offline', the account is properly disconnected | 13:20 |
| arno11 | in fact everything is fine once hsm is re-launched | 13:30 |
| arno11 | bbl | 13:31 |
| Wizzup | well, signald currently cannot link devices, so I will give up on that for the moment https://gitlab.com/signald/signald/-/issues/379 | 13:55 |
| freemangordon | arno11: yes, you can debug, exactly as I said ^^^ | 13:59 |
| freemangordon | you don't need maemo-summoner symbols | 13:59 |
| freemangordon | if you wish to debug hildon-status-menu (the executable), then you shoudl install its symbols | 14:00 |
| freemangordon | but we don't need that now | 14:00 |
| Wizzup | arno11: https://leste.maemo.org/Debugging#Dealing_with_Maemo_Launcher_.2F_Maemo_Invoker | 14:00 |
| freemangordon | we only need rtcom-presence-ui symbols | 14:00 |
| freemangordon | because it seem sit is at fault | 14:01 |
| freemangordon | so, the idea is: | 14:01 |
| freemangordon | start h-s-m with gdb, so when it crashes, you get backtrace | 14:01 |
| freemangordon | the other option is to enable coredumps | 14:01 |
| freemangordon | search for "* soft core unlimited" | 14:03 |
| freemangordon | this will help | 14:04 |
| freemangordon | https://www.enterprisedb.com/docs/epas/latest/installing/troubleshooting/linux_troubleshooting/enabling_core_dump/ | 14:04 |
| freemangordon | check "Enabling core dumps on a Debian or Ubuntu host" | 14:04 |
| arno11 | freemangordon: ok | 14:10 |
| arno11 | btw i found weird stuff in syslog: | 14:11 |
| arno11 | localhost pulseaudio[4837]: [pulseaudio] module-augment-properties.c: Failed to parse .desktop file /usr/share/applications/hildon-status-menu/rtcom-presence-ui.desktop. | 14:11 |
| freemangordon | weird | 14:12 |
| freemangordon | I don;t have that here | 14:13 |
| arno11 | ah, weird | 14:13 |
| freemangordon | hmm, any clue why /home/user/.config/pulse gets filled with files? | 14:20 |
| freemangordon | Wizzup: BTW, do we really want to keep rtcomel around? | 14:21 |
| freemangordon | what is the issue if we create it adhoc? | 14:22 |
| 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 | 14:37 |
| freemangordon | ok, my those get created on every reboot it seems | 14:39 |
| freemangordon | this cannot be normal | 14:39 |
| arno11 | ok | 14:40 |
| * freemangordon thinks auto keyword should have never been introduced in c++ | 14:43 | |
| freemangordon | every time a developer uses auto for everything else than lambda, a kitten dies | 14:43 |
| 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 | 14:58 |
| 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 | 15:13 |
| uvos__ | but you can just ignore this | 15:13 |
| Wizzup | yeah just continue | 15:23 |
| Wizzup | uvos__: this is openssl doing that btw | 15:24 |
| 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 | 15:26 |
| arno11 | indeed i got sigill/sigint stuff, i just ignored it and continued | 15:53 |
| arno11 | i'm currently looking @maemo logs, what is inetstate btw ? | 15:54 |
| arno11 | there are plenty of error with that in hildon-status-menu logs | 15:55 |
| arno11 | no clue what is it (maybe netstat stuff ?) | 15:57 |
| arno11 | (/var/log/maemo/hildon-status-menu.log) | 15:59 |
| freemangordon | Wizzup: https://github.com/maemo-leste/conversations/commit/f67ef3d844de55392f6b3e8f470978c1fc6c6df3 | 16:25 |
| freemangordon | arno11: this log spam will be fixed once I finish with connui-cell | 16:26 |
| freemangordon | will take a while though | 16:26 |
| freemangordon | Wizzup: maybe new release of conversations? | 16:26 |
| Wizzup | freemangordon: sure, want to do it? | 16:27 |
| freemangordon | me? | 16:27 |
| freemangordon | no | 16:27 |
| Wizzup | ok, i'll do it in a bit | 16:27 |
| freemangordon | dure, no hurry | 16:27 |
| freemangordon | *sure | 16:27 |
| arno11 | freemangordon: ok, btw how can i trace what's going on on startup with hsm/presence ? | 16:33 |
| freemangordon | enable coredumps | 16:34 |
| arno11 | ah ok | 16:34 |
| arno11 | thx | 16:34 |
| freemangordon | most-probably h-s-m crashes on startup | 16:34 |
| arno11 | yes indeed | 16:34 |
| arno11 | because it works fine once reloaded | 16:35 |
| arno11 | i'll let you know | 16:35 |
| uvos__ | h-s-m and h-h being just one process is an unfortionate ram optimization we are now stuck with | 16:36 |
| freemangordon | great | 16:36 |
| freemangordon | uvos__: hmm? | 16:37 |
| freemangordon | what is the difference if you have 1 or 10 processes if the crash happens on startup? | 16:37 |
| uvos__ | well all the (3rd party) widgets and things running inside the main process can and do break more mission crticall stuff | 16:38 |
| uvos__ | since they lack process isolation | 16:38 |
| freemangordon | well, how many gnome-panel processes you have | 16:38 |
| freemangordon | that's not true | 16:38 |
| uvos__ | lots effectively | 16:38 |
| uvos__ | desktop linux uses statusnotifier items | 16:38 |
| freemangordon | h-h can have another process as widget | 16:39 |
| uvos__ | ie other processies embed images, xwindows into the status area | 16:39 |
| uvos__ | with good isolation | 16:39 |
| freemangordon | example is osso-abook-home-applet | 16:39 |
| uvos__ | sure h-s-m and allowing 3rd party widges in process in h-h is a stability problem | 16:39 |
| freemangordon | that's why crashing applets got disabled ;) | 16:40 |
| uvos__ | crashing disables all applets | 16:40 |
| freemangordon | no | 16:40 |
| uvos__ | except a whitelist | 16:40 |
| freemangordon | well, ok | 16:40 |
| uvos__ | its not nearly the same | 16:40 |
| freemangordon | agree, but the end effect is the same | 16:40 |
| uvos__ | having seperate processies would be mutch better | 16:40 |
| freemangordon | or almost the same | 16:40 |
| uvos__ | anyhow, to mutch work to change | 16:40 |
| freemangordon | as I said - h-h supports separate processes | 16:40 |
| uvos__ | h-s-m dosent | 16:40 |
| freemangordon | right | 16:41 |
| uvos__ | also porting all the h-h widgets is also alot of work | 16:41 |
| freemangordon | but that's a trade-off for low memory footprint | 16:41 |
| uvos__ | not worth the cost on any 512mb+ device | 16:41 |
| uvos__ | it wasent an insane choice i just think its dated | 16:42 |
| freemangordon | won't argue | 16:42 |
| freemangordon | but again, see what rafael2k said about comparison between maemo and the other mobile OSes | 16:43 |
| freemangordon | 'snappier', 'faster' etc comes at a cost | 16:43 |
| freemangordon | here we talk about 6 cores 4 GB device | 16:44 |
| freemangordon | albeit allwinner | 16:44 |
| freemangordon | so even on such a performant device maemo being optimized makes lots of difference | 16:44 |
| gnarface | i think the allwinner one is only 2GB | 16:46 |
| gnarface | and 4 cores | 16:46 |
| gnarface | the 6-core/4GB one is rockchip | 16:46 |
| gnarface | not that it's super important, sorry, carry on | 16:47 |
| freemangordon | could be, I didn't really check what the SoC is | 16:47 |
| gnarface | pinephone regular is allwinner, pinephone pro is rockchip | 16:47 |
| gnarface | (i'm in their channel too) | 16:47 |
| freemangordon | I just had remote shell for a while :) | 16:47 |
| freemangordon | but in any case, this one is a beast compared to n900 | 16:48 |
| freemangordon | and I think GPU is faster than the one on d4 | 16:48 |
| 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 | 16:48 |
| freemangordon | yeah | 16:48 |
| freemangordon | actually it is fast | 16:49 |
| freemangordon | there seems to be some kernel bug that affects IO and makes it super slow | 16:49 |
| gnarface | i'm old, so it's fast to me too... but it does objectively struggle with modern phone software | 16:49 |
| freemangordon | well, I am speaking from 'running maemo on it' POV | 16:49 |
| gnarface | heh, yea i hope they fix the bottlenecks in the kernel, but they're still ironing out power management bugs | 16:50 |
| freemangordon | for PP? Is it still supported? | 16:50 |
| gnarface | sure, as supported as it ever was... | 16:51 |
| freemangordon | heh | 16:51 |
| freemangordon | yeah 'supported' | 16:51 |
| gnarface | it's all reverse-engineered community support by one or two ambitious heros | 16:51 |
| gnarface | heroes* | 16:51 |
| freemangordon | mripard and that what-was-the-nick chinese lady I guess | 16:52 |
| 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 | 16:52 |
| freemangordon | what os is that? | 16:52 |
| gnarface | all of them | 16:52 |
| freemangordon | 3 days on PP? | 16:52 |
| gnarface | yea | 16:53 |
| gnarface | 3 days STANDBY | 16:53 |
| gnarface | as in, not screen-on time | 16:53 |
| freemangordon | yeah | 16:53 |
| gnarface | turn it on and watch video you still burn through the battery in 1-2 hours at most | 16:53 |
| freemangordon | but, but... it does not support DVFS, no? | 16:53 |
| freemangordon | like, maemo does not susped | 16:53 |
| gnarface | uh... sorry, what's DVFS? | 16:53 |
| freemangordon | *suspend | 16:53 |
| freemangordon | frequency scaling and turning various modules off | 16:54 |
| gnarface | oh, dynamic voltage and frequency scaling... uh, i dunno. i'm no kernel dev | 16:54 |
| gnarface | i do suspect it might be missing support for stuff like this still, yes, but not sure | 16:54 |
| gnarface | or maybe only partial support | 16:55 |
| freemangordon | so, afaik (but don;t quote me on that), you can only suspend and run full-power, more or less | 16:55 |
| freemangordon | so haveing 3 days of standby time is great | 16:55 |
| 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 | 16:55 |
| gnarface | i do think you're right, that just implementing basic suspend on idle was what got us those 3 days | 16:56 |
| freemangordon | modesetting adds to that, by not supporting HW rotation :) | 16:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!