Add syncthingctl

[palfrey]

This in theory should fix #841. However, it's a hard one as syncthingctl depends on multiple libraries we don't have available in the base image versions of Debian that are all made by the same author, and AFAIK are only really used by his projects.

This PR so far does the following:

• cpp-utilities - core requirement. Seems to build fine, but I think there's some issues with the cmake packaging given complaints later on
• qtutilities - currently build fails due to paths for cpp-utilities headers that are installed fine, but get the wrong paths. That I've got a mkdir /opt/include hack in it's build so far is also a bad sign.
• qtforkawesome - feels like we shouldn't need this to build the cli, but no, the apps depends on this anyways. Doesn't build yet due to a lack of qtutilities build.
• syncthingtray - probably needs a few libraries adding, haven't gotten far enough with the other dependencies to really check that list.

I don't have enough cmake knowledge to really follow this one up, so pushing to ask a wider audience if they've got any ideas.

[Eeems]

Should syncthingctl have installdepends=(syncthing)?

[palfrey]

Should syncthingctl have installdepends=(syncthing)?

Probably! I'll check that if I can ever get it building...

[palfrey]

I've managed to fix the libcpp-utilities build, but I think I've now hit a hard block. The entware qt packages seem to contain just the .so files, not any of the headers or the cmake files. I'd somewhat worked around this by just installing the Debian qt libraries, which is fine up until you actually try and link with any of them 😆 Given the debian and entware versions are different (and are likely to get more so over time v.s. the single minor version difference right now), mixing those two won't work.

AFAIK, the only way this will ever work is going through entware and making qt dev packages (including a qt gui one, because apparently qtutilities always needs that for some reason). Or theoretically making qt packages here as well, but both of those are a giant pile of work, and I think I'm done on this one.

[Eeems]

Toltec doesn't use the entware qt libraries, as qt is shipped on the device. You'll want to use the qt image and use the system qt libraries instead. These should already have header files. If there is a specific library that is not included in the system qt libraries, that would need to be built and added. You can reference https://github.com/toltec-dev/toolchain/blob/v3.x/qt/Dockerfile for how qt was built for the device, and how it's installed.

[palfrey]

You'll want to use the qt image and use the system qt libraries instead

I had somehow completely forgotten that was a thing! So I've unfudged the qtutilities build, but qtforkawesome is another matter, as despite it's readme claiming it supports 5.6, it actually uses at least one 6.0 function. OTOH, it's a small one, so can probably patch around it...

[Eeems]

The qt:v4.0 image has qt6, as rM has updated to qt6 in later OS versions. This wont be available in toltec until #955 has been merged though. For now (and to keep supporting older OS versions) patching around it does seem like the easiest solution.

[palfrey]

qtforkawesome is fixed with a patch, and I've gotten as far as the actual syncthingctl! Brief moment of panic when it looked like it needed Boost, but turns out you can switch that off. OTOH, it also needs Qt 6. Hopefully again that's a fairly simple patch, but that's one for another day right now.

[Martchus]

If you just need syncthingctl you don't need qtforkawesome. If you nevertheless do then I should also fix that.

[Martchus]

Hopefully again that's a fairly simple patch, but that's one for another day right now.

I pushed that patch for you. Maybe further changes are required, though.

I also pushed a patch that let's you avoid dealing with qtforkawesome altogether if you are only interested in syncthingctl.

[palfrey]

I've tested this locally on my rm1 (started syncthing, went to /opt/etc/syncthing/ and ran syncthingctl -f config.xml --cert https-cert.pem status) and LGTM. All seems to be running fine.

[Eeems]

I'll have to figure out how to test on rM1/2 sometime soon. I have some nits about the packages though that will need to be addressed.

[Eeems]

@palfrey do you have any recommendations for how to test this? I've never used syncthing, and I'm not really planning on becoming a user.

[palfrey]

I don't no. I'm also not a user, it was just on the list of things people wanted and an interesting problem! @mooomooo as you originally asked for this, can you make suggestions?

[Martchus]

If you execute unit/integration tests as part of the package build you should be good. You can additionally invoke syncthingctl --help to see whether all dependencies are present.

[Eeems]

--help does work, but I'm seeing the following warnings we'll need to resolve as part of the packaging:

reMarkable: ~/packages/syncthing/ syncthingctl -s
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QFSFileEngine::open: No file name specified
Error: Unable to locate Syncthing config file and no API key specified
reMarkable: ~/packages/syncthing/ syncthingctl edit
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QFSFileEngine::open: No file name specified
Error: Unable to locate Syncthing config file and no API key specified

Likely we'll just want to create a wrapper script for syncthingctl that sets XDG_RUNTIME_DIR before calling it, similar to how we have /opt/bin/xochitl that handles setting environment variables for xochitl before launching it.

[Eeems]

See above comment

[palfrey]

Likely we'll just want to create a wrapper script for syncthingctl that sets XDG_RUNTIME_DIR before calling it, similar to how we have /opt/bin/xochitl that handles setting environment variables for xochitl before launching it.

Done

[Eeems]

Lets put the real executable in libexec so it's not polluting the PATH.

[Eeems]

@palfrey poke

[palfrey]

Lets put the real executable in libexec so it's not polluting the PATH.

Done