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 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.

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).

A full log would help, sorry!

https://gist.github.com/mxmilkiib/fd70af73a4ca97ca4871ce0895ff1c8a

@milkii The log you shared only shows that this is a test failure. Without the test logs themselves there's nothing I can do to help. Checkout the pinned comment for how to ignore such errors.

I'm getting this atm;

...
6/6 Test #6: syncthingfileitemaction_appstream_validation ...   Passed    0.54 sec

67% tests passed, 2 tests failed out of 6

Total Test time (real) =  12.70 sec

The following tests FAILED:
      1 - syncthingconnector_run_tests (Failed)
      2 - syncthingctl_run_tests (Failed)
Errors while running CTest
Output from these tests are in: /home/milk/.cache/yay/syncthingtray/src/syncthingtray-1.4.3/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
FAILED: syncthingconnector/CMakeFiles/check /home/milk/.cache/yay/syncthingtray/src/syncthingtray-1.4.3/syncthingconnector/CMakeFiles/check 
cd /home/milk/.cache/yay/syncthingtray/src/syncthingtray-1.4.3 && /usr/bin/ctest -V
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting...
 -> error making: syncthingtray-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
syncthingtray - exit status 4

I filed a ticket about it: https://github.com/syncthing/syncthing/issues/8785

That tests are failing when HOME is not defined is simply because Syncthing itself requires that variable to be defined (and otherwise panics). The integration tests are spawning Syncthing with a separate config/home anyways specified via --home (so your normal Syncthing setup is not affected) so I suppose I could just set home to something to avoid Syncthing from panicing.

Maybe Syncthing itself could also handle the situation better. The current behaviour makes it look more like an internal and unexpected error within Syncthing itself (rather than something the user has forgotten to setup):

$ HOME= syncthing --help
$HOME is not defined
panic: Failed to get user home dir

goroutine 1 [running]:
github.com/syncthing/syncthing/lib/locations.userHomeDir()
        github.com/syncthing/syncthing/lib/locations/locations.go:228 +0x7d
github.com/syncthing/syncthing/lib/locations.init.0()
        github.com/syncthing/syncthing/lib/locations/locations.go:56 +0x1d