Package Details: syncthingtray-qt6 2.0.4-1

Git Clone URL: https://aur.archlinux.org/syncthingtray-qt6.git (read-only, click to copy)
Package Base: syncthingtray-qt6
Description: Tray application for Syncthing (using Qt 6)
Upstream URL: https://github.com/Martchus/syncthingtray
Licenses: GPL-2.0-or-later
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 43
Popularity: 2.43
First Submitted: 2020-11-07 16:16 (UTC)
Last Updated: 2025-12-02 19:21 (UTC)

Pinned Comments

Martchus commented on 2023-11-21 23:20 (UTC) (edited on 2024-10-21 15:10 (UTC) by Martchus)

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs
There also exist a binary repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff

Important remarks:

  • The packages within the binary repository are built against the latest packages from Arch Linux and hence might not be compatible with Manjaro. This can be the cause when the Plasmoid doesn't work.
  • Like with any other package a rebuild is required when the soname of a dependency like boost changes (see e.g. https://github.com/Martchus/syncthingtray/issues/98). The package in my binary repository should be rebuilt in a timely manner. I'm also sometimes updating pkgrel of the AUR package when a rebuild is required (only in accordance with Arch Linux of course, not in accordance with Manjaro).
    • The "dirty" way is forcing the installation/update (leaving syncthingtray-qt6 broken until it has been rebuilt) or to uninstall syncthingtray-qt6 temporarily before the update. After the update syncthingtray-qt6 can be rebuilt and reinstalled again.
    • The correct solution is to use makechrootpkg which is also how official developers build their packages (and how packages in my binary repository are built).
  • It is required to build dependencies (that are not provided by Arch Linux itself) before building this package. So you need to build c++utilities, qtutilities-qt6, qtforkawesome-qt6 and syncthingtray-qt6 in that order.
  • The KDE integrations have been ported to KDE 6. This package builds KDE integrations for KDE 6 by default as KDE 6 is now in the main repositories.
  • Note that the tests of this package might fail despite there's nothing wrong (e. g. because Syncthing is just too slow and the test runs in a timeout). To ignore those false-positives, build the package with makepkg --nocheck or makechrootpkg -- --nocheck. It makes still sense to report failures. But please include the actual error message and not just the last few lines.

Latest Comments

1 2 3 4 5 6 .. 11 Next › Last »

yaros commented on 2025-10-23 03:02 (UTC)

@saymonz I'm sorry, I totally misunderstood you. I thought you tried to build it yourself without cleaning. I'm happy it's working for everyone now :)

saymonz commented on 2025-10-22 02:24 (UTC)

@yaros yeah it worked for me too, that's why I thanked @flying-sheep, sorry if that was unclear. That was indeed a me issue.

yaros commented on 2025-10-22 02:21 (UTC)

@saymonz I just did it and it worked, just like @flying-sheep but with yay. --rebuild flag is important. If you are using makepkg you need to make sure you set -C flag to do a full clean build.

saymonz commented on 2025-10-21 23:18 (UTC)

@flying-sheep thanks, I already tried uninstalling and reinstalling the package, thinking that would suffice, TIL!

flying-sheep commented on 2025-10-21 15:50 (UTC) (edited on 2025-10-21 15:51 (UTC) by flying-sheep)

@saymonz, you need to rebuild it, then it’ll be built against the newest installed version of libboost_filesystem.so. I did this:

paru -R syncthingtray-qt6
paru -Syu
paru -S --rebuild syncthingtray-qt6`

saymonz commented on 2025-10-21 14:30 (UTC)

Since boost-libs update to 1.89, build fails with error: warning: cannot resolve "libboost_filesystem.so=1.88.0-64", a dependency of "syncthingtray-qt6"

I wanted to try building with latest repo version, but I can't figure out where is the dependency on this specific version, the PKGBUILD only mentions the package without a specific version. Is it a me issue?

nathanielcwm commented on 2025-10-18 04:14 (UTC) (edited on 2025-10-18 04:14 (UTC) by nathanielcwm)

Not sure why but I've been getting this error for a bit when clicking on syncthingtray.

qt.qpa.wayland: Failed to create grabbing popup. Ensure popup QWidgetWindow(0x557f01941520, name="QtGui::TrayMenuWindow") has a transientParent set and that parent window has received input.

I'm on Plasma 6.4.5 with QT 6.10.0 on Wayland. I've rebuilt this package and still have the same issue.

The Plasmoid works fine, right click menu and webview and settings menu work fine, log menu works fine, about menu works fine.

Martchus commented on 2025-08-13 20:31 (UTC)

Strange. I've just built syncthingtray-git fine (with tests as I've just updated them). You could try building the -git version, too - although I'm not aware I had to fix anything even remotely related to the error you're getting.

Caydonin commented on 2025-08-13 20:26 (UTC) (edited on 2025-08-13 20:35 (UTC) by Caydonin)

I just cleared the cache with 'yay -Scc' and tried again. Still the same behavior.

EDIT: Just downloading the package with yay -Sw syncthingtray-qt6 and building manually with makepkg -si --nocheck works perfectly fine. Seems like the failed tests corrupt the cache or something.

Martchus commented on 2025-08-13 20:08 (UTC)

The integration tests with syncthing fail now as Syncthing has been updated to 2.0.0. I'll probably release Syncthing Tray 2.0.0 tomorrow with updated integration tests. Note that Syncthing Tray will nevertheless work with Syncthing 2.0.0 - it is really just the tests that use certain (now unsupported) CLI arguments.

This is probably the most relevant line from your build logs:

/home/caydonin/.cache/yay/syncthingtray-qt6/src/syncthingtray-1.7.10/syncthingconnector/./syncthingnotifier.h:6:10: fatal error: syncthingconnector/syncthingprocess.h: No such file or directory
    6 | #include <syncthingconnector/syncthingprocess.h>

I have no idea why this doesn't work, though. The paths imply that some kind of caching is going on so I recommend you make sure the build actually starts from scratch again.