Gajim - 2023-11-09

So I assume you can't turn this nag box off

The source ia out there. Remove the box from the source and compile it.

Possible to check for all logged in devices/ressources?

On my restored machin. gajim fails: https:llpaste.debian.net/hidden/0aea0ad6 - what am I missing?

Almost

https://paste.debian.net/hidden/0aea0ad6/

EmleyMoor: you probably need to reinstall gajim

I have!

(first thing I tried)

... so, what should be the next?

EmleyMoor: check ~/.local/lib/python* for an incomplete/broken gajim module

No ~/.local/lib at all

~/.local/share/gajim has stuff

Moved aside, still same problem

Does /usr/lib/python<version>/{dist,site}-packages/gajim exist?

Are issue reports useful if I cannot reproduce them? I had a crash related to the xml console (I think) that apport caught, but I closed it since I cannot reproduce it yet and I couldn't copy the text from the apport window.

what would the content be of that issue?

I had a crash but i cannot provide any data on it?

As I said, apport caught it and provided specific information

for that case, anyway

it's hard for me to say what all possible cases might be. Let's assume both extremes: sometimes I might know only what I was doing before the crash, other times apport gives details.

fjklp: either exact reproduction steps or a traceback (best both)

no clue what apport is

apport is ubuntu's crash reporting tool

I have no idea how it or similar tools know about crashes

I remember it said something exited with status 5

mentioned 2 files related to gtk code I think

I guess I'll enable text output and mention it here next time

I found the relevant log lines related to said crash

Nov 03 03:15:14 hostname gajim[101067]: ../../../gtk/gtktextbtree.c:4048: byte index off the end of the line Nov 03 03:15:14 hostname gajim[101067]: Byte index 1167 is off the end of the line Nov 03 03:15:14 hostname kernel: traps: gajim[101067] trap int3 ip:7f9e7a4d997a sp:7fff43ed1de0 error:0 in libglib-2.0.so.0.7800.0[7f9e7a490000+9a000] Nov 03 03:15:15 hostname systemd[1]: Started whoopsie.service - crash report submission. Nov 03 03:15:15 hostname update-notifier-crash[148874]: /usr/bin/whoopsie Nov 03 03:15:15 hostname systemd[3082]: Starting update-notifier-crash.service - Notification regarding a crash report... Nov 03 03:15:15 hostname whoopsie[148873]: [22:15:15] Using lock path: /var/lock/whoopsie/lock Nov 03 03:15:15 hostname systemd[1]: whoopsie.service: Deactivated successfully. Nov 03 03:15:16 hostname systemd[3082]: Finished update-notifier-crash.service - Notification regarding a crash report.

no that does not help us

either python traceback, or you can reproduce it, if you can reproduce it run it in gdb to get a real stacktrace

alright

heh, I was waiting for a low priority label to exist on the tracker. I'm surprised to see ~priority: high isn't used ✏

what would you prioritize as "high"?

I'm not sure since I know that's ultimately up to you guys and probably better handled by the people seeing the bigger picture

maybe something that is depended upon by multiple things, such as database upgrades

adding a priority makes only sense if someone needs to know the priority of things

yeah, you are right