syncthingtray
syncthingtray copied to clipboard
Martchus
Create and maintain Flatpak and Debian packages
Please create a flatpak and a deb package that are both maintained/supported. Flatpak will make it easy to install, deb packages will make it possible to install on Debian and Ubuntu distros and is small in size compared to flatpak
I've already noticed that there's demand at least for Debian/Ubuntu packages. It seems that there are quite some users using Debian (based) distributions but none of those users were willing to create and share packages for their distribution so far.
I haven't created a ticket yet because I'm not motivated to work on that task myself. However, I'd appreciate if anybody would create and maintain such packages.
If someone was willing to create OBS compatible builds scripts for Debian/Ubuntu packages I'd take the effort of building and updating them within my OBS home project: https://build.opensuse.org/project/show/home:mkittler:debian
There's also effort being taken by @sten0, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884575.
@sten0 If you have already some basics but no time/motivation to work further on them you could share what you already have.
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.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Ouf, I missed this one too.
Martchus @.***> writes:
If someone was willing to create OBS compatible builds scripts for Debian/Ubuntu packages I'd take the effort of building and updating them within my OBS home project: https://build.opensuse.org/project/show/home:mkittler:debian
There's also effort being taken by @sten0, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884575.
@sten0 If you have already some basics but no time/motivation to work further on them you could share what you already have.
The vast majority of the work was/is "how does one adapt this software for a Debian context", eg: strict policies. I choose to work on those problems first, because it feels super demotivating to do a bunch of technical work and then find out that it's blocked until the plan is fundamentally reformulated. Unfortunately that policy-related work doesn't help a potential OBS effort. That said, searching for "martchus" on site:bugs.debian.org should find Hannah's work, and it might be possible to adapt that to an OBS context.
P.S. Is your libsyncthing a git submodule fork of upstream Syncthing libs? I haven't quite been able to puzzle that out. The design I'll need to use is to run syncthing using a --user systemd unit, and if the functionality enabled by that lib is necessary or highly desirable then it will need to be:
- Removed from the Debian copy of the source when importing any version of upstream Syncthing Tray (for various reasons)
- Replaced with the Syncthing libs source (golang-github-syncthing-syncthing-dev and/or golang-github-syncthing-notify-dev packages) when building Syncthing Tray
And I'll probably declare a hard dependency on whatever is the most recent Debian version of Syncthing at the time of packaging, to trigger and error notification when Syncthing Tray requires a rebuild. That rebuild will be necessary whenever golang-github-syncthing-syncthing-dev is updated. Thankfully that's not too frequently!
So there's a plan, and hopefully Syncthing Tray will be ready for Debian this spring. Unfortunately it's too late for the Ubuntu 22.04 LTS window now. On the upside, once it's done it will be easier to maintain than a flatpak, and user satisfaction will be higher. The three or four flatpak-using users I act as tech support for haven't been satisfied with the desktop integration or speed of them. From what I've seen, I'm honestly baffled that Flatpak (and Snap) became more popular than AppImage. At the risk of sounding cynical, maybe the magic phrase is "corporate backing"? ;-)
P.S. Is your libsyncthing a git submodule fork of upstream Syncthing libs? …
Don't build with libsyncting support at all. It is meant to distribute Syncthing as part of Syncthing Tray which doesn't make sense for a Linux package where you can just install Syncthing via the package manager as well. (It is meant for Windows and possibly Android in the future.)
And I'll probably declare a hard dependency on whatever is the most recent Debian version of Syncthing at the time of packaging, to trigger and error notification when Syncthing Tray requires a rebuild. That rebuild will be necessary whenever golang-github-syncthing-syncthing-dev is updated. Thankfully that's not too frequently!
Don't declare a dependency on Syncthing at all. One might use Syncthing Tray to connect to a remote Syncthing instance. Note that when libsyncthing is disabled no Go dependencies are required at all.
Note that libsyncthing is disabled by default (for reasons stated in the previous comment) so you actually don't need to do anything to have it out of your way. You can also ignore the Git submodule completely as the entire content of the libsyncthing directory isn't used (unless you actually enable it by adding -DNO_LIBSYNCTHING=OFF to the CMake arguments).
Fiouf, that's great news :-) I'll still prune the subdir for various reasons. Eg: I don't want to maintain a detailed copyright file for something that won't be used, and all code deduplication, even unused code, makes the security team happy--and my life easier in case of a CVE in Syncthing, less to comb through during the review process, etc.
I uploaded cpp-utilities and qtutilities. The former was accepted in record time, which confirms my belief that painstaking attention to detail (in a Debian context) is rewarded. Less rigorous approaches often result in a long (many months) wait for approval.
Finally, we're on track for a summer 2022 release of Syncthing Tray. Finally. Once again, sorry for the slow pace!
Is there anything left to do? Is there some page (e.g. ticket or PR) to track the progress? My last update was that I should clarify the license and I hope the note in my README files is good enough now.
Hi Martchus!
Martchus @.***> writes:
Is there anything left to do? Is there some page (e.g. ticket or PR) to track the progress? My last update was that I should clarify the license and I hope the note in my README files is good enough now.
Sorry for the delay replying (my schedule has unpredictable bouts of crazy busyness). Yes, documenting license in your README files is sufficient.
As far as I know, this issue Create and maintain Flatpak and Debian packages (#33) is the most central location to track progress.
On the Debian side, I did some work updating Syncthing 1.18.0 to 1.18.6 (team maintained package, and aviau usually handles importation of new upstream versions), and we're in the middle of a transition to Go 1.18, which caused breakage in Syncthing that requires packaging of a compatibility shim. That compat shim package is currently awaiting review in the NEW queue, so progress here on this front is currently blocked (pending approval of golang-github-marten-seemann-qtls-go1-18). If I remember correctly Aviau will probably upgrade the Debian copy of Syncthing to the 1.19.x series at the beginning of summer.
Qtforkawesome packaging is in a WIP state. @hrittich, will you have time to apply what you learned from our previous reviews to this package, or should I go ahead and do it myself when next I have some free time?
After that, I think all that remains is Syncthing Tray itself!
Oh, and yes, getting Syncthing Tray in Debian is my penultimate development priority at this time. Only release critical bugs in my other packages preempt this. Please continue to ping me for progress status updates, I do appreciate them ;-)
Regards, Nicholas
You're welcome! To everyone following this issue, Qt Fork Awesome is now in progress :-)
Qt Fork Awesome is currently blocked by https://bugs.debian.org/998147, but will almost certainly be unblocked 21 April.
Update: Qt Forkawesome was approved unusually quickly thanks to a friendly FTP Master. I'm now in the final phase of copyright review and documentation of copyright holders.
For anyone hoping for an eventual Ubuntu 20.04 (focal) PPA, please note that this will not be possible, because the Qt release in this version (5.12.8) is too old. 21.10 (impish) is the oldest possible version, and of course a PPA for 22.04 will be possible. The maintainer of this PPA should take care to test new versions when importing the .dsc from Debian, because occasionally upstream Plasma changes may necessitate backwards-incompatible changes to the Syncthing Tray plasmoid (#133).
because the Qt release in this version (5.12.8) is too old.
For the desktop-neutral Qt Widgets based version even Qt 5.6.x should be sufficient. This is only about the Plasmoid.
By the way, the Qt Widgets based version is now also available in the download section, e.g. https://github.com/Martchus/syncthingtray/releases/tag/v1.1.19.
I tested it on Ubuntu 18.04 and other older distributions and it worked. In contrast to the previous AppImage download it doesn't come with horribly outdated dependencies and hacks to select the correct version of libstdc++. It is even already using Qt 6.3.0. This should be good enough for distribution neutral binary downloads (which will never be able to cover Plasma and Dolphin integration). So I will not be looking into making a Flatpak and will also discontinue building the AppImage when I can no longer maintain compatibility with Qt 5.6.
I just uploaded v1.1.20 to Debian unstable, and it will shortly appear in the NEW Queue. After that it will be reviewed by the ftpmasters for correctness, potential harmfulness, license compliance, etc. When it is accepted, it will enter unstable/sid. Then I will need to do a source-only upload to enable migration to testing/bookwork (what will become Debian 12), and the package will migrate there 10 days later. If anyone would like to see the application on Debian 11 (bullseye), please write to the backports mailing list at that time https://backports.debian.org/.
Because Ubuntu is a derivative of Debian, Ubuntu will sync the package at some point, and it will appear in the "Universe" repo. The package will also become part of Ubuntu 22.10 (Kinetic Kudu).
Thus Syncthing Tray will soon be solved for all Debian (and Ubuntu) derivatives.
It is possible to speed up this process by five days were I to enable CI for the package. If this is a desired, a hint would be appreciated, since I'm in need of a break ;)
because the Qt release in this version (5.12.8) is too old.
For the desktop-neutral Qt Widgets based version even Qt 5.6.x should be sufficient. This is only about the Plasmoid.
By the way, the Qt Widgets based version is now also available in the download section, e.g. https://github.com/Martchus/syncthingtray/releases/tag/v1.1.19.
I tested it on Ubuntu 18.04 and other older distributions and it worked. In contrast to the previous AppImage download it doesn't come with horribly outdated dependencies and hacks to select the correct version of libstdc++. It is even already using Qt 6.3.0. This should be good enough for distribution neutral binary downloads (which will never be able to cover Plasma and Dolphin integration).
Cool that's great news for users on older releases :) I believe Syncthing Tray is on track to becoming very popular!
So I will not be looking into making a Flatpak and will also discontinue building the AppImage when I can no longer maintain compatibility with Qt 5.6.
Sounds good to me. Prioritisation of time energy is both strategic and necessary for good health ;) Also, I suspect someone from the Flatpak and/or Snap-using community will eventually step up to do this work.
Looks like the package is suck in the new queue and will obviously already be outdated as soon as it is there. Considering it'll likely almost lack behind the current version I'm wondering how useful the package will be.
Martchus @.***> writes:
Looks like the package is suck in the new queue and will obviously already be outdated as soon as it is there. Considering it'll likely almost lack behind the current version I'm wondering how useful the package will be.
Yup, the requirement for human review (via the NEW queue) is for totally new packages as well as new versions of existing packages that break ABI or API. As noted previously, this could potentially become an issue if cpp-utilities and qtutilities see lots of changes without stabilising, because every release will require a trip through NEW, and sometimes this takes months.
Future uploads of syncthingtray itself will not need to pass through NEW. Updating to the latest version, uploading, and propagating the updated package to the mirror network may take as little as a few hours; we could even have same-day releases if the release falls on a day when we both have free time.
Previously you explained to me that using a "outdated" release is a plasmoid compatibility feature that is recommended in cases where one doesn't yet have the KDE Plasma version that the current version of syncthingtray targets ;)
Is it possible to download the deb files manually from somewhere? (I've looked for them in the new queue, but can't seem to download them from there.)
Previously you explained to me that using a "outdated" release is a plasmoid compatibility feature that is recommended in cases where one doesn't yet have the KDE Plasma version that the current version of syncthingtray targets ;)
That's true. Updating nothing might be better than updating parts and ending up with a combination of versions never tested by upstream.
As noted previously, this could potentially become an issue if cpp-utilities and qtutilities see lots of changes without stabilising, because every release will require a trip through NEW, and sometimes this takes months.
I'll bump the soname as needed. Turns out it wasn't needed for over two years. I guess that should be a frequency one can live with. (I personally also like to avoid breaking changes myself.)
Future uploads of syncthingtray itself will not need to pass through NEW.
I suppose that's because the libraries contained by syncthingtray itself are not consumed by any other package. Right?
Is it possible to download the deb files manually from somewhere?
Good question. I couldn't find it anywhere as well.
Marcus @.***> writes:
Is it possible to download the deb files manually from somewhere? (I've looked for them in the new queue, but can't seem to download them from there.)
If I remember my Debian history correctly, this is because that would count as [re]distribution, and one of the things that ftpmasters check for is the legality of [re]distribution. Yeah, it's a bit weird that devs will now push to git (which is publicly accessible) before the software has been rubber-stamped as OK...I agree that's inconsistent. Dev culture is much more relaxed now compared to the '90s-00s when there was still stuff like the American embargo on crypto and tonnes of (then litigated) patent landmines.
If you don't want to build from a Debian source package (either the orig.tar+debian.tar+dsc, or the git repo) I can rebuild binary packages. Would you like them for sid/unstable? This would be for 1.1.20.
Today I started working towards 1.2.0 along with checking to see if some bugs which don't matter for the initial upload of 1.1.20 are still present in 1.2.0. More on this later. I don't expect anyone to complain until the package is accepted into Debian (if no one has complained yet). It's related to systemd unit state querying, btw.
Martchus @.***> writes:
As noted previously, this could potentially become an issue if cpp-utilities and qtutilities see lots of changes without stabilising, because every release will require a trip through NEW, and sometimes this takes months.
I'll bump the soname as needed. Turns out it wasn't needed for over two years. I guess that should be a frequency one can live with. (I personally also like to avoid breaking changes myself.)
Wonderful :) And yes, it won't slow things down much (due to NEW queue) with this rate.
Future uploads of syncthingtray itself will not need to pass through NEW.
I suppose that's because the libraries contained by syncthingtray itself are not consumed by any other package. Right?
Yes, because there is not yet other software that uses these libs, so there would not be much benefit for the increased maintenance burden. I put the syncthingtray libs into the application package, and have also disabled the -dev package for syncthingtray to make this choice internally consistent (and defensive). Someday that decision may need to be revised, but I think that day is at least two years in the future.
Is it possible to download the deb files manually from somewhere?
Good question. I couldn't find it anywhere as well.
Anyone who knows how to build debs from a Debian git repo packaging repo can clone and build at local copy of 1.0.2-1
https://salsa.debian.org/debian/syncthingtray.git
If necessary, please hard reset to 600ffdb7af6a24810d4689f9053df8be7dd06ea9 before building. Sorry there's no release tag yet; tags are published when packages are published.
In other news, work towards 1.2.0-1 began yesterday. It's likely that it will be ready for upload by the time 1.0.2-1 is accepted into the Debian Archive, so long as the new qtforkawesome v0.0.4 isn't a hard requirement. v0.0.4 will unfortunately require its own trip through the NEW queue again.
If anyone wants a super early preview for Debian sid/unstable, here is a link. Note that it comes with zero support. If it doesn't work, sorry, you're on your own. I've also included the source package (orig.tar, debian.tar, dsc file) which most people find easier to build than a package in git. P.S. Everywhere where I wrote "1.0.2" previously, I actually meant "1.1.20". Sorry for the inaccuracy.
https://drive.google.com/drive/folders/1tDs_hXEW8GiDBwBCKhy5FGuDsDWE1Xj5?usp=sharing
I put the syncthingtray libs into the application package, and have also disabled the -dev package for syncthingtray to make this choice internally consistent (and defensive).
Makes sense, also considering https://github.com/Martchus/syncthingtray#using-backend-libraries=.
so long as the new qtforkawesome v0.0.4 isn't a hard requirement
It won't be, it is just fixing a build system issue affecting a use case you don't have.
Hey! I just wanted to say thanks for going throught the process of getting this into Debian. I know that whole process isn't easy.
Thank you for the kind words @eode :) and I'm sorry the early steps of this process took so long.
@Martchus
Makes sense, also considering https://github.com/Martchus/syncthingtray#using-backend-libraries=.
Yes, and definitely for this reason! :) Thanks again for documenting facts like these.
so long as the new qtforkawesome v0.0.4 isn't a hard requirement
It won't be, it is just fixing a build system issue affecting a use case you don't have.
That's great news! In this case cpputils, qtutils, and syncthingtray can be brought up to date in Debian very quickly. Today I also pinged FTP Masters to let them know that users are requesting prerelease debs, so I hope that someone will review the package soon. Ideally all this will occur before Ubuntu 22.10's last sync from Debian so that their release (and its derivatives) can have Syncthing Tray!
The package has finally been reviewed and accepted!
https://tracker.debian.org/pkg/syncthingtray
As a bonus, during one round of review I had the opportunity to update the proposed Syncthing Tray package to 1.2.2, so I updated its deps took the opportunity to do so. Thus, the latest versions are now available in sid/unstable. Also, I think we met the deadline for Ubuntu 22.10's last sync, but I'm not entirely sure.
Users of stable/bullseye/Debian 11 (and derivatives) can receive a backport if someone requests one on the "Debian backports" mailing list. I will be happy to do this work, but have to wait for someone to ask.
Ubuntu 22.04 (and derivatives) users can gain access if someone downloads the Debian source packages, runs the correct "dch" command on them (so that upgrades to future official Ubuntu packages will go smoothly), and then uploads to a PPA.
Very nice.
Btw, I'm aware of the appstream issues mentioned in Debian's tracker but haven't had the time to fix them. Including the release time is especially hard because I needed to include that timestamp before doing the actual release (so it can be part of the release).
About https://qa.debian.org/bls/bytag/W-compiler-flags-hidden.html: You should be able to make the build log verbose like it is possible with any other CMake project.
Not sure about the other linter warnings but they are probably harmless.