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
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. https://github.com/Martchus/syncthingtray/issues/98). 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).
  • The "dirty" way is forcing the installation/update (leaving syncthingtray broken until it has been rebuilt) or to uninstall syncthingtray temporarily before the update. After the update syncthingtray 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, qtforkawesome and syncthingtray in that order.
• The KDE integrations have been ported to KDE 6 but building them for KDE 5 should still work. This package does not build any KDE integrations by default because KDE 6 is now in the main repositories. To build KDE integrations for KDE 6 you need to install syncthingtray-qt6 instead of this package.
• 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.

Thank you for the hint rebuilding syncthingtray...

Sorry for flagging out of date and not reading the comments. I now also installed rebuild-detector from the arch repo and enabled its hook so that is hopefully never happens to me again.

Steps to fix this:

sudo pacman -Syud

paru/yay -S syncthingtray --rebuild

This will force a pacman update without checking for dependency breaks. Then yay/paru will rebuild the package with new dependency.

@Martchus I just wanted to say thank you for your work in maintaining this package. Your directions to do a rebuild worked perfectly for me. Sorry that some people are not reading your directions and causing you headaches. Again, thank you for your efforts!

Note that I do not need this package myself as I develop on https://github.com/Martchus/PKGBUILDs anyways. I just upload this PKGBUILD for your convenience. So have the decency of RTFM (or at least recent comments) and not ask the same questions again and again on every boost update.

Whoever flagged this package AGAIN: Please read the comments before blindly flagging packages!

If this recurring spam on every boost update continues I'm forced to disabled notifications for this package I maintain and will thus no longer be able to take care about any kind of questions.

Whoever flagged this package: Just rebuilt it against the new boost version. There's no modification to the PKGBUILD required.

Just rebuild this package against the new boost package. I'll rebuild the packages in my binary repository as well.

Just a heads up, seems like boost-libs got updated earlier today, so it cannot be upgraded while having this package installed as of now.

Your test failure might be fixed by https://github.com/Martchus/syncthingtray/commit/66a8dda244152a6aef48461f83481faf87167210 which will be part of the next release. I tested it by setting TEMP to a different value and it worked in my environment. In the meantime you can workaround it by ensuring TEMP and similar variables are cleared in your environment.

It fails in CPPUNIT_ASSERT(std::ofstream(m_tempPath / "some/path/1/new-file.txt") << "foo");. I haven't seen that before and find it rather strange. The variable m_tempPath is initialized via std::filesystem::temp_directory_path() and therefore supposed to point to a writeable location. It looks like the sub-path some/path/1 is supposed to be created via Syncthing, though. The only potential problem I see is that Syncthing will always create it under /tmp/some/path/1 whereas std::filesystem::temp_directory_path() might return something different than /tmp. Could it be that you have set an environment variable in your build environment that changes the behaviour of std::filesystem::temp_directory_path()? Regardless of whether that's the concrete problem here, I suppose I will ensure that Syncthing and the test code use always the same path (in the next release).