Closed xeruf closed 1 year ago
What happens if you click on "Show details from setup detection"? Is it always reproducible? Normally it should at least run into a timeout after a few seconds.
I've also fixed a race condition that could trigger a similar problem but it isn't part of the latest release. So you might want to try to out the Git version. (I'm not 100 % sure whether it is related to your issue. I could reproduce this race condition very often on Leap 15.4 but never on Arch Linux or Tumbleweed. It also showed up in test cases causing them to fail.)
Note that going back to re-do the setup detection is currently also broken in the latest release (and only fixed on Git).
What happens if you click on "Show details from setup detection"?
Nothing noteworthy in there.
I will try again in a few days, with the -git version.
Nothing noteworthy in there.
Nevertheless it would make sense to paste what's shown there. Also the absence of information can be a clue. And again, is it always reproducible?
I was not sure whether it is a good idea to post my device ID. Maybe truncate in the dialog by default?
Yes, it is reproducible.
Ok, so it had all the information needed to go on. That reduced already the number of places to look for problems. Good that it is always reproducible. That makes it much easier to verify whether improvements actually helped. I'm nevertheless wondering what the difference of your system is (compared to my systems) that makes it reproducible in the first place.
When building the syncthingtray
package, did you disable tests? If not I assume the tests passed. Since the tests are exercising this exact step as well that would mean the issue is also not reproducible in your build environment (if you haven't disabled tests).
It is persistent, even with the latest -git version :/ Tests seem to run fine.
Good to know. Maybe I can stare a little bit more at the code this evening to find the possible mistake. (If I'd be able to reproduce the problem myself it would be much easier.)
I didn't want to close this. I was just referencing the ticket. Well, you could try my recent changes but I don't think I have found the source of the problem yet. Likely I also won't be able to find it anytime soon. If you care to have this fixed you better start debugging this issue yourself. You're the only one I know that can reproduce the issue.
Martchus, thanks for your selfless contribution to the community!
Well, I had the same issue with a fresh installation of Linux Mint (I subscribed to the topic earlier). It seems this occurs after I installed the official syncthing app. If I install syncthingtray without syncthing app, I was able to go through the wizard.
I don't know what you mean by "installed" the official Syncthing app exactly? Simply that the Syncthing executable is in PATH? That shouldn't cause the problem. I have it in PATH myself and can't reproduce the problem. In fact being able to launch Syncthing from PATH is one of the points of the wizard.
How did you install Syncthing Tray on Mint? To avoid confusing different issue, please be sure your testing against the latest version from Git master.
By the way, which version of Boost are (all of) you using? I've noticed a similar problem myself at some point with a too old version of it on openSUSE Leap.
the latest in the arch repos :) The annoying thing about this is that the wizard pops up at every boot, but gets stuck every time :/
the latest in the arch repos
For the record, that would be 1.81.0. (Since issues may be open for quite a while it makes sense to be explicit about such things.)
that the wizard pops up at every boot
That is another problem of its own actually. The wizard is only supposed to show up on the first startup (like the welcome dialog box it has replaced, unless you use the CLI parameter --show-wizard
or --assume-first-launch
or the env variable SYNCTHINGTRAY_FAKE_FIRST_LAUNCH=1
). Supposedly in your case the launched flag is never (persistently) set. I'll check on that issue but supposedly I'm also not able to reproduce (as I would have noticed it by now for sure).
I can't reproduce the wizard popup showing every time syncthingtray
is launched. If I have at least one connection configured (which you then did manually, right?) the wizard isn't showing up anymore on startup. The connection doesn't even have to be complete/valid.
Does Syncthing Tray also "forget" its other settings? I'm asking because it looks like the whole settings mechanism might not work for you. On Linux the config is normally put under $HOME/.config/syncthingtray.ini
so make sure that's a writable location for the user you start syncthingtray
with. I'm not reading the HOME
variable literally but rely on Qt's abstraction to find the config dir so other variables may be relevant as well (see https://doc.qt.io/qt-6/qsettings.html#locations-where-application-settings-are-stored, the user-specific locations are relevant and I'm using the INI format which is under Linux identical to the native format). The code also checks whether syncthingtray.ini
is in the directory next to the binary and uses that if it exists for being able to create a portable installation.
I improved error handling of the settings handling so errors aren't completely ignored anymore. (You also need to rebuild qtutilities to test this.)
Another user is claming that this issue has been introduced in v1.3.2 (and as such v1.3.1 has been working, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1435799307). I don't find that very likely but cannot check that myself as I cannot reproduce the issue. Do you know since when this issue occurs? It might be useful to bisect this although it may very likely just be there from the beginning (when the wizard was introduced).
Just tested, same issue on 1.3.1
Ok, good to know and thanks for testing. Unfortunately I still have no idea what makes your setup special so you run into this problem.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@sten0 still wants to test this, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1627807580.
Martchus @.***> writes:
@sten0 still wants to test this, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1627807580.
Thank you for reopening! So I've tested a basic 1.3.2 setup on Debian 12 (bookworm, the latest stable LTS release), amd64 arch. After installing the package, logging out, and logging in again, the wizard automatically starts. Clicking through the defaults starts the Syncthing --user service, and the wizard completes.
c++utilities5 5.20.0-1 qtforkawesome1 0.1.0-1 libmartchus-qtutilities6 6.10.0-1 Qt 5.15.8-2 Boost 1.74.0+ds1-21 KDE Plasma 5.27.5
I'm not sure if it's relevant, but this is with Debian-provided Syncthing packages.
It might take a month or more to update all the dependencies, but I'll test the latest version of everything soon to test if this issue exists in a user-facing way on amd64. Then I'll enable CI and see if it still holds up on other archs. 'hopefully everything will be fine! :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Relevant components
syncthingctl
)libsyncthing
)Environment and versions
syncthingtray
,qtutilities
andc++utilities
: Linked against: C++ Utilities: 5.20.0, Qt Utilities: 6.10.0, Connection backend of Syncthing Tray: 1.3.2, Data models of Syncthing Tray: 1.3.2, Widgets of Syncthing Tray: 1.3.2, Qt Network: 5.15.8, Qt Gui: 5.15.8, Qt Widgets: 5.15.8, Qt Core: 5.15.8Bug description I went through the wizard, but now it has been trying for minutes to apply changes without visible progress
Steps to reproduce
syncthingtray
in terminal