Closed trymeouteh closed 1 year ago
Martchus
commented
5 years ago 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.
Martchus
commented
4 years ago 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.
stale[bot]
commented
2 years ago 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.
sten0
commented
2 years ago 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:
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"? ;-)
Martchus
commented
2 years ago 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.
Martchus
commented
2 years ago 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).
sten0
commented
2 years ago 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!
Martchus
commented
2 years ago 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.
sten0
commented
2 years ago 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
Martchus
commented
2 years ago Thanks for the status update, glad to hear you're still on it.
sten0
commented
2 years ago You're welcome! To everyone following this issue, Qt Fork Awesome is now in progress :-)
sten0
commented
2 years ago Qt Fork Awesome is currently blocked by https://bugs.debian.org/998147, but will almost certainly be unblocked 21 April.
Martchus
commented
2 years ago Thanks for the update.
sten0
commented
2 years ago Now waiting for Qt Fork Awesome to be approved, but here is some good news:
sten0
commented
2 years ago 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).
Martchus
commented
2 years ago 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.
sten0
commented
2 years ago 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 ;)
sten0
commented
2 years ago 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.
Martchus
commented
2 years ago 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.
sten0
commented
2 years ago 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 ;)
m-sundman
commented
2 years ago 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.)
Martchus
commented
2 years ago 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.
sten0
commented
2 years ago 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.
sten0
commented
2 years ago 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.
sten0
commented
2 years ago 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
Martchus
commented
2 years ago 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.
eode
commented
2 years ago 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.
sten0
commented
2 years ago 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!
sten0
commented
2 years ago 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.
Martchus
commented
2 years ago 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.
sten0
commented
2 years ago Very nice.
Thank you! And yes, finally!
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).
Wow, that was fast! You don't need to track those if you don't want to, by the way. Thank you for starting work on the wizard, and I agree that it has higher priority (and greater benefit) than this Appstream stuff.
The "date" property is preferred to the timestamp, so why use timestamp?
How are you currently making releases? date -I is all one needs to get
the date in the correct format. There's also almost certainly a CMake
module that will generate or update this property during the CMake
equivalent of make dist. This one shouldn't be a hard problem, and I'd
like to make it easier.
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.
This is a bug specific to mips64el and arm64 and can be ignored.
Not sure about the other linter warnings but they are probably harmless.
You don't need to worry about this stuff, it's usually Debian specific, and the only time users will see it is if they search for "Developer Information" for a package. The thing that stands out the most to me is "W[arning] dpkg-buildflags-missing CPPFLAGS 7 (of 89) missing (arm64, armhf, i386, mips64el, mipsel)". I'll have to investigate whether that's expected for the current state of the toolchain in sid/unstable, or if I'll need to replace @hrittich's debian/rules methods with something else.
One thing that might interest you is having CI coverage. Salsa uses Gitlab CI, and Debci tests software as-installed (eg: to /usr, /var, /srv, etc). I'd like to wait a few months before pursuing this avenue though, to give the basic reprobuilds CI time to test reproducibility and to check for subtle failures.
sten0
commented
2 years ago Martchus @.***> writes:
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.
Oh yeah! My apologies, you had told me this. Thank you for the correcting the record. I guess I'm cognitively biased towards the KDE Plasma desktop integration case ;)
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).
That's great news :)
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.
Also, +1 for strategic use of time/energy.
sybenx
commented
1 year ago Just discovered syncthingtray. Hoping for a flatpak version primarily for Steam Deck. There is quite a bit of attention on using syncthing for saves on Steam Deck among other things. Syncthingtray seems ideal out of available options. Flatpak is the only persistent application method on Steam Deck afaik.
Martchus
commented
1 year ago About the Steam Deck: I don't own it, I cannot really help with it. However, I can make a few remarks:
--windowed parameter to show Syncthing Tray as normal window.I think once 1. has been clearified one could add information about Steam Deck compatibility to the README file. For building/packaging I'd personally try 2. first and if it doesn't work or turns out to be too complicated resort to 3.
I'm not sure about the usefulnes of Flatpack and won't provide a repository as part of this project. However, anybody is welcome to provide a downstream repository. That's already what's happening for other platforms. You could even make your life very simple and just put the generic GNU/Linux binary from the release section on GitHub into the Flatpack (which then should only need the most minimal Flatpack runtime). I suppose the Chocolatey package maintainer just does the same with the Windows binary.
stale[bot]
commented
1 year ago 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.
HereInPlainSight
commented
6 months ago Howdy. \o
syncthingtray works fine in desktop mode, I haven't bothered worrying about it in Gaming mode. Probably doesn't matter for my use case, but as you suspected, there's no real tray area in that mode./home is the only safe place. And Steam updates the deck, like, a lot.Open Syncthing option, it just uses the local browser instead. I'm not sure if that's what you mean by the 'KDE integration,' I use syncthing / syncthingtray for my use case and... that's basically it.)That said, some additional info on how I've got things running because of how the Steam Deck works. YMMV.
Firstly, when switching from desktop to gaming mode, the system restarts. (Not so from gaming to desktop, but not particularly relevant.) Some things don't come up right in gaming mode (such as barrier), so I had an idea I might want to tackle the problem in two halves, especially since syncthingtray supports it: syncthing separate from the tray.
syncthingtray lives in the steamdeck user's Download folder, as does just regular-old syncthing (binary straight from their download page). First thing's first, I set up a dumb little systemd unit file at /home/deck/.config/systemd/user/syncthing.service for ActualSyncthing (non-tray). After a systemd --user daemon-reload, with a systemctl --user enable syncthing.service, I'm syncing up with the desktop GUI available or not. Maybe this was doable with just syncthingtray's built-in syncthing, but I didn't know how to go about it and it was pretty late when I started setting this up last night. Then I just configured syncthingtray to Start the tray icon when the desktop environment launches and have everything else pointing to the systemd service / syncthing direct download. Even when I'm in gaming mode, I can see that my steam deck's still connected to my other syncthing'd devices. When I switch to desktop mode, syncthingtray pops up a few seconds later showing connected to the syncthing systemd service.
I was angling for something that I figured would work so I could get to sleep.
Today, in answer to your first question, I made a little script to start syncthingtray --windowed (since 'sitting in a random directory' isn't counted as an installable app, apparently) and it does work, though I don't think I'll be using it that way, personally.
If there's anything else you want me to test, I certainly can.
Sorry to resurrect an old thread, but I thought that in an absolute worst case scenario, it gives others something to go off of / food for thought for their own setups.
Martchus
commented
6 months ago Thanks for the feedback, interesting to read.
it just uses the local browser instead. I'm not sure if that's what you mean by the 'KDE integration
No, that's not what I mean with KDE integration. It opens the load browser because my builds on GitHub are not built with the built-in web view because I don't want to ship a whole web browser. Using Chrome/Chromium in app mode should still work if selected in the settings. (The KDE integration is the Plasmoid/Plasma-Applet and the Dolphin integration.)
… with a
systemctl --user enable syncthing.service
That's the best way of starting Syncthing on GNU/Linux in my opinion. I prefer it over the launcher of Syncthing Tray myself on that platform. The systemd integration of Syncthing Tray should be able to cope with Syncthing started that way. (The launcher is of course still useful under non-systemd platforms like Windows.)
Sorry to resurrect an old thread
Totally fine with me :-)
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