Arch Linux User Repository

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.

@Martchus reboot and cleanup and clean start later and it worked, no idea what that was. Sorry for the noise

Looks like the test instance of Syncthing never reaches an idle state. I can't reproduce this in my build environment. Can you connect with the test instance and check what its state is? For a workaround, check out the pinned comment.

The current version fails to build on my laptop because it hangs during tests:

2: Executing test cases ...
2: .
2:  - Setup configuration for Syncthing tests ...
2:  - Using timeout factor 3
2: 
2:  - Launching Syncthing: syncthing serve --gui-address=http://127.0.0.1:59245 --gui-apikey=syncthingtestinstance --home=/home/norbert/.cache/yay/syncthingtray-qt6/src/syncthingtray-2.1.0/cli/testworkingdir/testconfig --no-browser
2: Info: Launched process, PID: 94931
2: 
2: Waiting till Syncthing GUI becomes available ...
2: 2026-05-14 15:30:00 INF syncthing v2.1.0 "Hafnium Hornet" (go1.26.3-X:nodwarf5 linux-amd64) syncthing@archlinux 2026-05-12 08:02:45 UTC [libsqlite3, noupgrade] (log.pkg=main)
2: 2026-05-14 15:30:00 INF Generating key and certificate (cn=syncthing log.pkg=syncthing)
2: 2026-05-14 15:30:00 INF Archiving a copy of old config file format (path=/home/norbert/.cache/yay/syncthingtray-qt6/src/syncthingtray-2.1.0/cli/testworkingdir/testconfig/config.xml.v28 log.pkg=syncthing)
2: 2026-05-14 15:30:00 INF Calculated our device ID (device=3I4WYAD-UTXTC2V-RXSCVTL-FPZ6QKO-VYTFBKH-C7U35TM-WD6Q5FO-C4L45QT log.pkg=syncthing)
2: 2026-05-14 15:30:00 INF Overall rate limit in use (send="is unlimited" recv="is unlimited" log.pkg=connections)
2: 2026-05-14 15:30:00 INF Using discovery mechanism (identity="global discovery server https://discovery-lookup.syncthing.net/v2/?noannounce" log.pkg=discover)
2: 2026-05-14 15:30:00 INF Using discovery mechanism (identity="global discovery server https://discovery-announce-v4.syncthing.net/v2/?nolookup" log.pkg=discover)
2: 2026-05-14 15:30:00 INF Using discovery mechanism (identity="global discovery server https://discovery-announce-v6.syncthing.net/v2/?nolookup" log.pkg=discover)
2: 2026-05-14 15:30:00 INF Using discovery mechanism (identity="IPv4 local broadcast discovery on port 21027" log.pkg=discover)
2: 2026-05-14 15:30:00 INF TCP listener starting (address=127.0.0.1:32452 log.pkg=connections)
2: 2026-05-14 15:30:00 INF Using discovery mechanism (identity="IPv6 local multicast discovery on address [ff12::8384]:21027" log.pkg=discover)
2: 2026-05-14 15:30:00 INF Ready to synchronize (folder.id=test1 folder.type=sendreceive log.pkg=model)
2: 2026-05-14 15:30:00 INF Creating new HTTPS certificate (log.pkg=api)
2: 2026-05-14 15:30:00 INF GUI and API listening (address=127.0.0.1:59245 log.pkg=api)
2: 2026-05-14 15:30:00 INF Access the GUI via the following URL: http://127.0.0.1:59245/ (log.pkg=api)
2: - /home/norbert/.cache/yay/syncthingtray-qt6/src/syncthingtray-2.1.0/cli/syncthingctl-qt6 wait-for-idle --all-dirs --all-devs --api-key syncthingtestinstance --url http://localhost:59245 --no-color

There it hangs indefinitely.

@acuriouscrow You have probably just run into https://github.com/Martchus/syncthingtray/issues/434. So I suggest you just retry the build.

When I try that workaround, I get fatal error: syncthingconnector/syncthingconnection.h: No such file or directory. Anyone know what package includes this header?

[sunshe35@arcHome ~]$ yay -S syncthingtray-qt6
Sync Explicit (1): syncthingtray-qt6-2.0.10-1
Resolving dependencies...
warning: cannot resolve "libboost_filesystem.so=1.90.0-64", a dependency of "syncthingtray-qt6"
:: The following packages cannot be upgraded due to unsatisfied dependencies:
      syncthingtray-qt6

:: Do you want to skip the above packages for this upgrade? [y/N] y
Looking for package conflicts...
Nothing to do today
error: cannot set install reason for package syncthingtray-qt6 (could not find or read package)
 -> error installing repo packages
[sunshe35@arcHome ~]$

I solve this problem through this way:

sudo pacman -Rdd syncthingtray-qt6
cd /tmp
git clone https://aur.archlinux.org/syncthingtray-qt6.git
cd syncthingtray-qt6
makepkg -si --nocheck --skipchecksums --nodeps

Is there a way to build this without building gcc-snapshot?

Sure, this package does not depend on gcc-snapshot so it won't pull-in this dependency by default. Also none of its dependencies will pull it in. If you used some helper there is probably something wrong with that as you should not have ended up building gcc-snapshot by accident.

I have tried looking around as to what pulls it in as a dependency, but I could not find it in the end, I am not experienced enough.

You couldn't find it because there is nothing to find.

And of course that takes hours on a 13900HX.

Really? That CPU sounds like it is actually quite fast. Maybe you should set MAKEFLAGS so that all of your CPU cores are used. I mean not for gcc-snapshot which you don't need anyway but to build packages faster in general.

I would like to build this instead of using the binary as I tend to keep my install fixed to a certain date in pacman, and update when I have the time for that while still being able to install packages consistently. Using the binary would not be possible that way.

If you are using repos from https://archive.archlinux.org then you indeed cannot install packages from my repo at any time. However, considering you probably just need to install a small set of packages from my repo it is probably not going to be a big deal to do this at the same time when you update everything. You could comment my repo in and out as needed to avoid installing packages from it accidentally.

Is there a way to build this without building gcc-snapshot?

I have tried looking around as to what pulls it in as a dependency, but I could not find it in the end, I am not experienced enough. And of course that takes hours on a 13900HX.

I would like to build this instead of using the binary as I tend to keep my install fixed to a certain date in pacman, and update when I have the time for that while still being able to install packages consistently. Using the binary would not be possible that way.

As stated in the pinned comment, I sometimes update the pkgrel. I do that mainly if a patch or other packaging change is required, though. Otherwise it isn't all that helpful and even causes more annoyances for certain users.

The problem is that users of kde-unstable need to rebuild earlier than users of testing which in turn need to rebuild earlier than users of regular repositories. Users of e.g. Manjaro probably need to rebuild even later. So it makes most sense if users handle rebuilds of AUR packages on their own.

I also want to avoid making things worse for people using these unstable/testing repositories who have already rebuilt sooner because that discourages use of these repositories - but this kind of testing is very important and shouldn't be discouraged.

If it needs a rebuild, could you initiate it by upping the pkgrel?