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.

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.

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.

see https://github.com/Martchus/syncthingtray/issues/98

$ syncthingctl status
syncthingctl: error while loading shared libraries: libboost_filesystem.so.1.75.0: cannot open shared object file: No such file or directory

$ pacman -Q boost-libs
boost-libs 1.76.0-1

$ pacman -Q syncthingtray 
syncthingtray 1.1.8-1

I assume you've just ran the local -a command in some shell in some terminal. You could add the command within the PKGBUILD's check() function and also echo the environment variables. This way you would see whether it is setup as expected also in the build environment. (An AUR helper or makepkg might mess-up something here, e.g. makepkg generally sets environment variables from /etc/makepkg.conf.)

at the beginning

I've noticed that setting variables at the beginning of the file might not be reliable, at least that's my experience when using makechrootpkg (see https://github.com/hipersayanX/ArchPackages/commit/1e61856d067b5aeae6828e39e01d617661b1069e). Hence I recommend to set environment variables within the relevant functions.

I'm not sure what's wrong with my locales, it seems alright:

$ locale -a
C
en_GB.utf8
en_US.utf8
POSIX

But adding export LC_ALL=C; unset LANGUAGE at the beginning of the PKGBUILD worked, thanks!

Looks like the locale isn't setup correctly in your build environment. Does it help to put export LC_ALL=C; unset LANGUAGE into the check() function within the PKGBUILD (before the test suite is invoked)? If that's the case than the problem is likely due to an incorrect locale setup.

By the way, this is how one usually sets up the locale: https://wiki.archlinux.org/title/Locale#Generating_locales

Upgrading from 1.1.7-1 to 1.1.8-1 fails because the tests fail.
Full logs: https://0bin.net/paste/W-nQ1Ar0#OaFh1cPlBcy65ZQy7luStEtnNS3jY7EL9zCi+N6h-5A

2: !!!FAILURES!!!
2: Test Results:
2: Run:  1   Failures: 0   Errors: 1
2:
2:
2: 1) test: ApplicationTests::test (E)
2: setUp() failed
2: - uncaught exception of type std::exception (or derived).
2: - locale::facet::_S_create_c_locale name not valid
2:
2:
2: Tests failed
2/2 Test #2: syncthingctl_run_tests ...........***Failed    0.01 sec
0% tests passed, 2 tests failed out of 2
Total Test time (real) =   0.02 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: /tmp/bauh/arch/build_1625912474/syncthingtray/src/syncthingtray-1.1.8/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
FAILED: connector/CMakeFiles/check
cd /tmp/bauh/arch/build_1625912474/syncthingtray/src/syncthingtray-1.1.8 && /usr/bin/ctest -V
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
Aborting...
rm -rf /tmp/bauh/arch/build_1625912474

Package "syncthingtray" upgrade failed

If it helps, I noticed the same error trying to build this package. During the test run is the same error I got when I tried running plasmashell in a console. parsting and something about a - in a date throwing a c++utilities exception.

Thanks for the stack trace, its very useful and I guess I've already found the issue. It is not within c++utilities, though. The problem is that a parsing error isn't handled correctly.

Here's the stacktrace generated by my just-updated version of Arch. Looks like the problem is in C++ utilities:

Application: Plasma (plasmashell), signal: Aborted

[KCrash Handler]

4 0x00007f40a4415ef5 in raise () at /usr/lib/libc.so.6

5 0x00007f40a43ff862 in abort () at /usr/lib/libc.so.6

6 0x00007f40a463c86a in __gnu_cxx::__verbose_terminate_handler() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95

7 0x00007f40a4648d3a in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48

8 0x00007f40a4648da7 in std::terminate() () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58

9 0x00007f40a464904e in __cxxabiv1::__cxa_throw(void, std::type_info, void ()(void)) (obj=<optimized out>, tinfo=0x7f40880d72b8 <typeinfo for CppUtilities::ConversionException>, dest=0x7f40880bf120 <CppUtilities::ConversionException::~ConversionException()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95

10 0x00007f40880ae3f5 in () at /usr/lib/libc++utilities.so.5

11 0x00007f4088101fbc in Data::SyncthingConnection::readStatus() () at /usr/lib/libsyncthingconnector.so.1.1.3

12 0x00007f40a4a71d86 in () at /usr/lib/libQt5Core.so.5

13 0x00007f40a41f5965 in () at /usr/lib/libQt5Network.so.5

14 0x00007f40a4a67532 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5

15 0x00007f40a56d9752 in QApplicationPrivate::notify_helper(QObject, QEvent) () at /usr/lib/libQt5Widgets.so.5

16 0x00007f40a4a3aa2a in QCoreApplication::notifyInternal2(QObject, QEvent) () at /usr/lib/libQt5Core.so.5

17 0x00007f40a4a3d523 in QCoreApplicationPrivate::sendPostedEvents(QObject, int, QThreadData) () at /usr/lib/libQt5Core.so.5

18 0x00007f40a4a94054 in () at /usr/lib/libQt5Core.so.5

19 0x00007f40a2e1af9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0

20 0x00007f40a2e6ea49 in () at /usr/lib/libglib-2.0.so.0

21 0x00007f40a2e186f1 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0

22 0x00007f40a4a93691 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5

23 0x00007f40a4a393ac in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5

24 0x00007f40a4a41844 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5

25 0x000055ab7b60720b in ()

26 0x00007f40a4400b25 in __libc_start_main () at /usr/lib/libc.so.6

27 0x000055ab7b60733e in ()

[Inferior 1 (process 1772) detached]

On my system, I was able to update everything but Syncthingtray itself; that fails to install due to an error with the tests:

2: !!!FAILURES!!! 2: Test Results: 2: Run: 1 Failures: 1 Errors: 0 2: 2: 2: 1) test: ApplicationTests::test (F) line: 130 cli/tests/application.cpp 2: forced failure 2: - app failed with return code 134 2: stdout: 2: stderr: Info: Connecting to http://localhost:59718 ...terminate called after throwing an instance of 'CppUtilities::ConversionException' 2: what(): unexpected "-" after day 2: 2: 2: 2: Tests failed 2/2 Test #2: syncthingctl_run_tests ...........***Failed 2.55 sec

0% tests passed, 2 tests failed out of 2

Total Test time (real) = 5.08 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/sezovr/.cache/yay/syncthingtray/src/syncthingtray-1.1.4/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. FAILED: connector/CMakeFiles/check cd /home/sezovr/.cache/yay/syncthingtray/src/syncthingtray-1.1.4 && /usr/bin/ctest -V ninja: build stopped: subcommand failed. ==> ERROR: A failure occurred in check(). Aborting... error making: syncthingtray

So I assume you're using the Plasmoid and plasmashell crashes. Without logs and stack trace it is hard to tell what's wrong.

That a single Plasmoid can crash the whole shell is likely nothing I can improve because that's a result of how Plasma's architecture is designed.

Note that if you're using Manjaro the package in my binary repository might be to new and hence break with the possibly older version of plasmashell in Manjaro.

About the test suite: https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/121