bill-auger

Not that I can see.

i just do not understand what does this mean to "sign in with a custom status message"?

why did you not simply say: "i signed in" ?

if this status message is a mandatory part of signing in then why was it important to mention it?

I'm still having the problem.

I have tried gajim with several custom status messages.

I can not reproduce.

This suggests to me that the issue is with:
1 - Your setup

- or -

2 - The status message you set

Please provide more info

O.k. Since that status message looks perfectly normal it seems it's option 1 we need to Dx.

First lets rule out a messed up plugin. Please set all plugins inactive via

gajim -> plugins -> uncheck all the boxes

then re-launch gajim and try setting the status.

That still does not work. I get a crash report even if the plugins are disabled.

Ok, then you can turn those back on..

since there is a lot of mention of zeroconf and since I know this aspect hasn't been working like it should since the last upgrade, please try:

gajim -> accounts and disable the "local" account

then try setting the status

That worked! Thanks! :)

so is this bug reproducible? what are the steps to reproduce this bug?

I was unable to reproduce the same crash that the OP was experiencing. even after several attempts.

I noted the references to zeroconf in the debug output and deduced that the problem was most likely with the 'local' (a.k.a. zeroconf) account.
I also suspected this because since gajim moved to V1.x.x the 'local' account on my machines refuses to go "online" (which is a weird nominclature for a serverless account).

Deactivating the account seems to be a good work-around for the issue given that I suspect that very few people use that feature.

I did not check with th OP about his avahi set-up. which might be part of the issue as avahi is an optional depend and thus might not be installed/set-up on the OPs machine

If it feels important to get this sorted I'd suggest re-naming this issue to something like "local account doesn't work properly after upgrade to V1.x.x"
The same issue exists in my wifes Arch machine so it is not a Parabola specific problem. The local account worked fine on my Machine and my wifes before the move to 1.x.x. So it is definitely something that was introduces then.

ok - so becuase this packages comes from arch, the main thing i would be trying to determine is if this bug exists in arch - if you say it does then there is nothing more for us to do other than to forward it to the arch packager and make this issue as "forwarded upstream" until it is fixed

i have never used this program before so my install is fresh from 'gajim-1.0.3-2' - when i try to put the "local" account online it fails and i get a desktop notification:

could not start local service - please check if avahi-deamon is running?

How exactly do I setup avahi?

yes that is the same message that show up om my wifes Arch machine (which has avahi installed and configured)
It worked fin on both Arch and Parabola prior to 1.x.x

freemor -

do you have an account on the arch bug tracker - i looked for similar bugs but there are none - could you report it?

https://bugs.archlinux.org/index.php?string=gajim&project=1&type%5B%5D=&sev%5B%5D=&pri%5B%5D=&due%5B%5D=&reported%5B%5D=&cat%5B%5D=&status%5B%5D=open&percent%5B%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&do=index

Nope. But I suppose I could make one easy enough.
Is the standard protocol to create a similarly named bug and then reference this thread?

i dont know if there is a protocol but thats what i would do

Done. Now exists there as:

https://bugs.archlinux.org/task/59259

I've been following this on the Arch tracker.
After an initial question about the state on Avahi the bug was assinged to: Balló György (City-busz)

The last comment by the assignee was:

Comment by Balló György (City-busz) - Wednesday, 11 July 2018, 16:11 GMT
Please report to upstream:
https://dev.gajim.org/gajim/gajim/issues

The issue was then closed on the Arch tracker reason: Upstream

I've checked on: https://dev.gajim.org/gajim/gajim/issues But see no sign of the bug reported there which leaves me wondering if they (Arch) wanted me to report it upstream.

Out of curiosity and some free time decided to debug this a bit further.. with verbose output on one sees:

2018-07-12 09:02:08 (D) gajim.c.z.zeroconf_avahi To make asynchronous calls, receive signals or export objects, D-Bus connections must be attached to a main loop by passing mainloop=... to the constructor or calling dbus.set_default_main_loop(...)
2018-07-12 09:02:08 (I) gajim.c.z.client_zeroconf Disconnecting ZeroconfListener:

So yep looks like the dbus communications from gajim <-> dbus may be hosed in this version.

I'm going to see if there is a git/devel version to see if the issue has been fixed already before reporint it further upstream.