`sudo apt install syncthingtray-kde-plasma` unavailable

[metal450]

I noticed that the "Packages and Binaries" section of the readme now lists the ability to install via sudo apt install syncthingtray-kde-plasma / sudo apt install syncthingtray. However, I'm not seeing the package as available in the default 22.04 repo (I'm specifically using KDE Neon 6). Is there perhaps a ppa or something that needs to be added to get the install to work...?

[Martchus]

You need to ask the maintainer of your distribution. However, I guess the README section about the Debian package simply does not apply to the specific distribution you are using.

The maintainer of the Debian package is @sten0. He put the note in the README and probably knows more about it then me. I can only remark that KDE Neon 6 is a different distribution than Debian despite being based on Debian. It is probably way ahead of Debian when it comes to KDE and Qt packaging so Debian's KDE/Qt related packages such as syncthingtray-kde-plasma are probably not inherited. The syncthingtray-kde-plasma package in Debian is probably even still using Qt 5 targeting KDE 5 while KDE Neon 6 is already at Qt 6 and KDE 6.

[metal450]

Gotcha, thanks for the quick reply. Will wait for @sten0 to chime in, but your guess sounds likely/reasonable.

[Martchus]

In case you want this packaged for KDE Neaon 6 it would probably make most sense to ask the developers of this distribution. While @sten0 might have more insights about this topic in general I would not expect him to move anything forward for KDE Neon 6. (When I remember correctly from another conversation on GitHub he's not even using KDE.)

[metal450]

Luckily in this case it worked fine just copying over my same /opt/syncthingtray folder from the previous Neon installation - so managed to avoid having to go through the whole build process for now. Tho yeah, would be awesome to be able to just install directly someday

[sten0]

Martchus @.***> writes:

The syncthingtray-kde-plasma package in Debian is probably even still using Qt 5 targeting KDE 5 while KDE Neon 6 is already at Qt 6 and KDE 6.

Yup, that's an accurate assessment. We've also had Qt6 since 2022 though--and it was a tonne of work!

In case you want this packaged for KDE Neaon 6 it would probably make most sense to ask the developers of this distribution.

+1, and good luck.

While @sten0 might have more insights about this topic in general I would not expect him to move anything forward for KDE Neon 6.

Yup, I'm a Debian Developer. The flow of packages is this: Debian unstable -> Ubuntu -> Neon <- upstream KDE Frameworks and Plasma desktop.

In Debian, here's currently what's in progress:

https://wiki.debian.org/ReleaseGoals/64bit-time https://www.phoronix.com/news/Debian-Experimental-64bit-Time

This is a blocker to making progress on syncthingtray, but after it's resolved I'll updated and up-to-date martchus-deps and syncthingtray to unstable/sid. When the experimental suite has KF6 and Plasma6 I'll enable it in a syncthingtray experimental branch and upload to this suite. So it's on the way!

In the meantime you're of course welcome to rebuild the Debian/Ubuntu/Neon package for Qt6/KF6/Plasma6 any use. Add deb-src lines to your sources.list, apt get update, apt source foo where foo is each of the martchus-deps & also get syncthingtray, then something like:

cd foo
sudo apt build-dep .
dch "Enable Qt6/KF6/Plasma6"
dpkg-buildpackage -us -uc && cd ../

Install all the new deps, and move on to the next step in the dependency chain. There are lots of HOWTOs and people who would love to help you take the next step in problem solving, self-sufficiency, and hopefully contributing ;)

(When I remember correctly from another conversation on GitHub he's not even using KDE.)

That must be someone else, because I have exclusively used KDE on Debian for a decade and a half.

[sten0]

Nicholas D Steeves @.***> writes:

cd foo
sudo apt build-dep .
dch "Enable Qt6/KF6/Plasma6"

Sorry, I forgot to mention that this point is where you actually need to change the dependencies in debian/control to the Qt6 variants. An additional edit might also be required to debian/rules if Qt6 isn't autodetected and preferred or if we're currently hard-coding Qt5 in debian/rules.

dpkg-buildpackage -us -uc && cd ../

[Martchus]

Thanks for the insightful response.

Note that Syncing Tray's build script currently always defaults to Qt/KF 5 for the sake of compatibility (as I don't want to break existing build scripts/packaging). So you will have to set both variables as shown in the Arch PKGBUILDs to do the switch to version 6 explicitly.

[sten0]

Martchus @.***> writes:

Thanks for the insightful response.

You're welcome.

Note that Syncing Tray's build script currently always defaults to Qt/KF 5 for the sake of compatibility (as I don't want to break existing build scripts/packaging). So you will have to set both variables as shown in the Arch PKGBUILDs to do the switch to version 6 explicitly.

That makes sense to support typical end-user unclean builds, where both Qt variants will usually be installed at the same time (vs builds in a clean environment where the pkg maintainer will choose whether Qt/KF 5 or 6 is the supported version).

Thanks for the tip! Do qtutilities and qtforkawesome also already test for this variable and built against Qt6 when requested?

To anyone reading this: Syncthingtray and its deps have now been updated to their latest versions in Debian unstable/sid, and I've noticed work on KDE Frameworks 6 being uploaded to experimental.

[Martchus]

Thanks for the tip! Do qtutilities and qtforkawesome also already test for this variable and built against Qt6 when requested?

Yes, they do. The handling of those variables is actually defined in qtutilities and present there for ages.

[Martchus]

I would also recommend to set the suffix of libraries in accordance to how I do it for the Arch PKGBUILDs. So Qt 6 based libraries have a -qt6 suffix. This implements not only an easier distinction and co-installability but also an soname change for these binary-incompatible versions of the libraries. (Building against a different major version of Qt breaks bc and the soname wouldn't change otherwise yet. That is really the reason I wait with changing the default Qt version until I bump the major version of qtutilities.)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Martchus]

I guess I can actually close this issue. We clarified that this is something to be done by the Debian maintainer and not an upstream issue. I also answered the questions by the maintainer.

(When updating packages, please configure them to add the -qt6 library suffix as mentioned in https://github.com/Martchus/syncthingtray/issues/254#issuecomment-2097661648 to be consistent with my Arch Linux packaging, e.g. https://github.com/Martchus/PKGBUILDs/blob/master/qtutilities/qt6/PKGBUILD.)

[metal450]

Sure, sounds good - will close :)

[ethanc8]

Has anyone built any packages for KDE Neon yet? Otherwise, I might try to set up a GitHub Action that can build the packages.

[Martchus]

I'm not aware anyone has built any packages yet.

A GitHub action would make sense but preferably on a separate repository (like the Flatpak builds) as I try to separate upstream development from packaging. (The packages I maintain myself also live in separate repos or on OBS.)

[sten0]

The problem is here is that Neon updated KDE Frameworks and Plasma but then didn't rebuild the applications from what Ubuntu calls "universe" (ie: the vast majority of Debian packages). Last I looked into it, Neon is a specialist distribution that doesn't have the resources to support everything. That said, please file a bug with them, because if no one asks them to put Syncthing Tray on their "packages of interest to Plasma users" list then this sort of thing will undoubtedly happen again.

KF6 and Plasma 6 are now in Debian experimental, so please ping me in two weeks about updating Syncthing Tray (and dependencies) to use Qt6 and KF6. Neon users will be able to easily rebuild these source packages for whatever version of Neon they use, so long as it uses KF6.

[sten0]

P.S. When filing that bug, please remind the Neon devs to forward their patch[es] upstream to Debian :) I'd be happy to review and merge their work.

[ethanc8]

Should I file on discuss.kde.org or bugs.kde.org? I'm not sure if this is actually a bug, especially since the package was added to the Debian and Ubuntu repos after the Ubuntu 22.04 release.

[Martchus]

This is not a bug because this was never implemented in the first place. (If Syncthing Tray and in particular the Plasmoid worked before on Neon this was just by accident.)

I think you can file feature requests on https://bugs.kde.org/enter_bug.cgi?classification=KDE%20Neon by selecting severity "whishlist". Note that I am not a KDE developer so this information might be wrong (I'd still give it a try).

If you file a feature request or start a discussion somewhere, please drop a link here so people who are interested and land here can follow.

[sten0]

@ethanc8 Maybe? Is that the usual place to report Neon bugs? The bug @metal450 reported is technically a request for a backport of SyncthingTray from Neon 24.04 to Neon 22.04, but Neon 22.04 now appears to be EOL.

https://neon.kde.org/faq#non-lts-releases

Will there be a version using non LTS Ubuntu releases? No, we plan only to base on the latest LTS version of Ubuntu, this comes with Linux and graphics stack updates to keep drivers relevant. We will backport other software as needed.

So it looks like @metal450 needs to upgrade to 24.04. Then this becomes an actionable bug (for Neon).

This isn't a @Martchus problem, nor a Debian, nor an Ubuntu/Kubuntu problem. Neon broke it, and Neon should either fix this (and forward the patch upstream to Debian), or backport the Plasma6-enabled package from Debian experimental to Neon 24.04 (the prerequisites are finally in place!), or wait for future uploads to unstable/sid if there isn't an urgent need at this time.

@Martchus, as I've explained before, yes, "it was implemented", and I know this because I made the package. Ubuntu is a fork of Debian and inherits its packages; Neon is a fork of Ubuntu and inherits its packages; Thus, Neon is a transient for on Debian an inherits its packages.

[ethanc8]

Neon 24.04 has not been released yet.

[sten0]

Neon 24.04 has not been released yet.

@ethanc8 that's great news! :) Yes, please file a bug asap, then they can fix this for release

[ethanc8]

https://bugs.kde.org/show_bug.cgi?id=491044

[ethanc8]

The Neon developers are not interested in packaging non-KDE software. I will try backporting from Sid myself.

[Martchus]

I guess that's generally the limitation of distributions that are very focused like Neon - one's feature request can be very quickly out of scope.

[sten0]

I guess that's generally the limitation of distributions that are very focused like Neon - one's feature request can be very quickly out of scope.

Agreed; It's now official (Jonathan Riddel is the project lead): Neon isn't designed to be a general-purpose operating system.

@ethanc8

The Neon developers are not interested in packaging non-KDE software. I will try backporting from Sid myself.

I addition to what I wrote previously in this thread, you'll need to modify d/control to change to Qt6, KF6, and Plasma6 deps, and you'll additionally need to modify d/rules to activate the logic to link with them rather than the 5 variants. Also do this everywhere it's relevant in all martchus- deps. There's no stable ABI, so no ABI-tracking, so you don't need to worry about updating that. Oh... I forgot about the t64 transition... Neon probably doesn't have the infrastructure to support that yet, so you'll need to revert it. I forget if I activated move-to-/usr (for system units) yet, but I always use the method that allows backporting (with a backported debhelper that disables move-to-/usr automatically). Alternatively, look for any new systemd-related build-deps and consider just deleting them. Other than reverting the t64 transition, you don't need to rename any binary packages, nor muck with suffixes.

[ethanc8]

It sounds like t64 was applied to Ubuntu Noble too, and KDE Neon is trying to apply t64 to their 24.04 release: https://blog.neon.kde.org/2024/05/09/kde-neon-rebasing-on-ubuntu-noble/

But I'm on 22.04, so I will probably need to revert the t64 transition.

you'll need to modify d/control to change to Qt6, KF6, and Plasma6 deps

So the Qt6/Plasma6 transition is still in progress in Debian, and this package hasn't been affected by the transition yet?

[ethanc8]

Yeah, I've had to backport lots of Debian packages to 18.04 in the past: https://github.com/ethanc8/titanian-repo

This is because Nvidia refuses to support their Jetson Nanos, whose latest model was released in 2019. They have a terribly old kernel and an extremely heavily customized 18.04 distribution, without which you can't effectively use the GPU.

[sten0]

ethanc8 @.***> writes:

It sounds like t64 was applied to Ubuntu Noble too, and KDE Neon is trying to apply t64 to their 24.04 release: https://blog.neon.kde.org/2024/05/09/kde-neon-rebasing-on-ubuntu-noble/

But I'm on 22.04, so I will probably need to revert the t64 transition.

Yes, you definitely will need to. Didn't I mention the necessity to revert this, as well as backporting debhelper? (I can't remember) Take debhelper from bookworm-backports, because it will disable some usrmerge stuff that will make your life difficult and/or break you system.

you'll need to modify d/control to change to Qt6, KF6, and Plasma6 deps

So the Qt6/Plasma6 transition is still in progress in Debian, and this package hasn't been affected by the transition yet?

0. Qt6 has been in stable for ages.
1. KF6 and Plasma6 have been staged in experimental.
2. Team-maintained and high priority packages that are now broken when the CI mixes in experimental will now be fixed.
3. Then KF6 and Plasma6 are uploaded to unstable.
4. Packages break, and when they're fixed, everything migrates to testing.
5. The transition is now complete.

So yeah, the transition will be in progress for a while yet. Depending on when I find the free time to catch up on my work, I'll upload Syncthingtray (and deps) to experimental (for stage 2), or to unstable later (for stage 4), or else someone will probably fix the package for me at that time--I doubt that it will come to that though!

[sten0]

ethanc8 @.***> writes:

Yeah, I've had to backport lots of Debian packages to 18.04 in the past: https://github.com/ethanc8/titanian-repo

Thank you for sharing your work :)

This is because Nvidia refuses to support their Jetson Nanos, whose latest model was released in 2019. They have a terribly old kernel and an extremely heavily customized 18.04 distribution, without which you can't effectively use the GPU.

Booo. Also, isn't this the period in time where Linus Torvalds spoke some choice words at nVidia, with famous gestures ;) Cool boards though! I remember really wanting to develop for them.

Have any of the Rockchip-based NanoPi or NanoPCs overtaken the Jetson Nano's GPU? Given the monetary value of a couple hours of work, it might be cheaper to switch to one of them. 'hope your Jetson Nanos aren't connected to the internet btw.

[ethanc8]

Have any of the Rockchip-based NanoPi or NanoPCs overtaken the Jetson Nano's GPU?

I'm not sure. I am starting to switch to Rockchip boards, but the software support is very bad. Third-parties provide significantly better support than board manufacturers. Fortunately new drivers are currently being mainlined.