Package Details: syncthingtray 1.3.1-1

Git Clone URL: (read-only, click to copy)
Package Base: syncthingtray
Description: Tray application for Syncthing
Upstream URL:
Licenses: GPL
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 68
Popularity: 5.36
First Submitted: 2016-09-14 20:13 (UTC)
Last Updated: 2022-12-06 15:56 (UTC)

Pinned Comments

Martchus commented on 2016-10-31 11:39 (UTC) (edited on 2022-09-30 00:15 (UTC) by Martchus)

All my packages are managed at GitHub where you can also contribute directly:
There also exist a binary repository:
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.

Important remarks:

  • Like with any other package a rebuild is required when the soname of a dependency like boost changes (see e.g. The package in my binary repository should be rebuilt in a timely manner. I'm usually also updating pkgrel of the AUR package when a rebuild is required (only in accordance with Arch Linux of course, not in accordance with Manjaro).
  • 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, qtforkawesome and syncthingtray in that order.
  • 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 .. 9 Next › Last »

Martchus commented on 2022-11-03 16:13 (UTC)

A "normal" update from 1.2.4 to 1.3.0 without helpers and only using makepkg --nocheck will fail because of how dependencies are checked.

Not if one uninstalls the old version of syncthingtray before. Having to do that is not a big loss considering it would be broken in the meantime anyways (which is also the reason pacman complains). It is nice that Arch Linux lowers the entrance barrier for building packages by allowing one to invoke makepkg without chroot. When building leaf packages or other packages that do not require rebuilding further packages that is good enough. However, this simple approach has its limitations. That's also why official developers always use makechrootpkg. I cannot solve this limitation (and also not the maintainer of other AUR packages like ffmpeg-libfdk_aac). One can only point out workarounds or to use makechrootpkg. I personally don't use AUR helpers (just my own scripts / build service) but I believe there are AUR helpers out there that can help with using makechrootpkg (to make its use easier).

iyanmv commented on 2022-11-03 15:45 (UTC)

Martchus: Regarding frazar0 comment, I still think that not supporting AUR helpers (which is okay) and only being able to build/install it successfully using makechrootpkg or extra-x86_64-build are different things. A "normal" update from 1.2.4 to 1.3.0 without helpers and only using makepkg --nocheck will fail because of how dependencies are checked.

Martchus commented on 2022-11-03 09:47 (UTC)

Once I've got feedback on I'll add patches to this package. Until then, please use --nocheck or stop anything using port 8384 on your system before attempting the build.

@jackdinn I cannot give you support for AUR helpers. I don't use those myself. Somehow you need to find a way to pass flags to makepkg as mentioned in the pinned comment.

@Sintan I mentioned in my previous comments two other "dirty" ways that are likely even better and one clean way.

@frazar0 Using AUR helpers is definitely not what I'd call "normal". Maybe those helpers cannot handle so-dependencies very well. Note that this way of specifying dependencies is the preferred way now and many official packages use it as well. Those dependencies have the advantage that pacman will refuse breaking your system in case a soname changes. Note that other AUR packages with similar dependencies (like ffmpeg-libfdk_aac) aren't different.

frazar0 commented on 2022-11-03 08:16 (UTC)

I am surprised as to why the "normal" installation fails. I have tried with different AUR helpers, but only achieved failures:

$ yay -S syncthingtray
 -> Could not find all required packages: (Wanted by: syncthingtray) (Wanted by: syncthingtray) (Wanted by: syncthingtray)

$ paru -S syncthingtray
:: Resolving dependencies...
error: could not find all required packages: (wanted by: syncthingtray) (wanted by: syncthingtray) (wanted by: syncthingtray)

I often install AUR packages, and I was wondering: why does only the syncthingtray package present this issue?

Thank you for your work.

Sintan commented on 2022-11-03 04:35 (UTC) (edited on 2022-11-03 04:37 (UTC) by Sintan)

Ran into the same issue. A quick and dirty fix is to edit /var/lib/pacman/local/syncthingtray-1.2.4-1/desc and remove the line with qtforkawesome and then doing the upgrades.

VorpalGun commented on 2022-11-02 21:50 (UTC)

I ran into the same build issue on Arch Linux. I submitted a github bug about this and included the actual failing test output (helps being a software dev so I know what to look for).

jackdinn commented on 2022-11-02 21:47 (UTC)


I am sorry but im just a beginner, i have read the pinned comment. I dont know how to "I recommend building without tests (see pinned comment)"

All i use is yay and/or the GUI pamac.

I have tried ❱yay -S syncthingtray --editmenu and taken a look through the PKGBUILD but i really dont know what im looking for or doing :( sorry.

iyanmv commented on 2022-11-02 21:44 (UTC)

Martchus: I will also consider adding your repo to have smooth updates ;) Thanks for maintaining it by the way.

iyanmv commented on 2022-11-02 21:41 (UTC)

Martchus: Let me know what additional information I can provide that can help you. I will try tomorrow to build with extra-x86_64-build. I do use this to check the packages I maintain, and this is helpful to find issues with the PKGBUILD, missing dependencies, etc. But packages in AUR are also expected to build correctly with makepkg, which is not the case now. Other packages in AUR also require a particular order to be built/install but they work just fine.