Getting the latest version of user-facing apps into Trisquel
- Anmelden oder Registrieren um Kommentare zu schreiben
I often find that the versions of user-facing apps in the Trisquel repos are so old as to render them semi-functional or even non-functional. Some examples are discussed in these threads:
https://trisquel.info/en/forum/syncthing-failing-etiona
https://trisquel.info/en/forum/jami-version-trisquel-8-repos-still-called-ring
This gives users a bad impression of the quality of both the apps and Trisquel itself, especially when the apps are installed by default. Getting the latest versions of theses apps required adding a whole lot of extra repos, which can create other issues. Various new packaging systems have attempting to solve the problem of out-dated users apps; AppImages, Snap, Flatpak etc but all of these seem to have issues of their own. Back-porting newer versions has been suggested as an option but seems to create a lot of volunteer labour, something Trisquel already seems to be short of. How could we solve this problem in a way that provides both the maximum possible software freedom and the best possible user experience?
My experience is just the opposite: The "apps" in Trisquel work just fine and perform their intended functions with their usual efficiency. I, for one, appreciate that the "app" version numbers are generally frozen on release. If that weren't the case and if there were ever-newer versions coming in which may fix existing matters but also introduce new ones at the same time, it becomes more an exercise in finding and fixing never-ending newer issues so it doesn't resolve the problem you're describing. The current method where the "app" version numbers are generally frozen on release doesn't mean there aren't bugs but at least you know you know where they are and how to work around them, and then knowing that the fix you did is the fix that will stay there, knowing that things won't be changing out from under you. This gives me the chance to work on the things that *I* want to work on in my day-to-day rather than spending my time fixing never-ending new & different bugs that come in from ever-newer "app" versions.
It sounds like you might be interested in the "rolling release" model instead? Something like Hyperbola may be more what you're looking for, since it's intended to work that way, rather than the "frozen on release" model.
And yet, probably no one prepares as many bleeding edge, critically important packages which can be easily dropped in place on Trisquel as you. Your repo is an absolute goldmine.
Thank you. Despite my obvious preference for the "frozen on release" model I do understand and agree that in certain situations it can make sense for a person to do what I like to refer to as a "strategic melting of the Trisquel glacier". I see my Linux-libre APT repository playing a role in that for the situations where it makes sense.
> It sounds like you might be interested in the "rolling release" model instead? Something like Hyperbola may be more what you're looking for, since it's intended to work that way, rather than the "frozen on release" model.
Did you actually mean Parabola? Or were you just mocking Hyperbola for its stability-breaking releases of subsequent Milky Way versions?
"Did you actually mean Parabola?"
Yes, sorry.
> user-facing apps
One would have thought all "apps" are "user-facing". Or do you mean all GUI front-ends?
> both the maximum possible software freedom and the best possible user experience?
I guess the answer depends very much on the way you define "best possible user experience", which might greatly vary with users. Trisquel combines maximum possible software freedom and easiest possible user experience. User experience would only get marginal improvement, if any, by playing catch-up with rolling release versions.
To take Jami as an example, we can assume that most Trisquel users simply never use it. So the best choice might be to keep some stable version in the repo, rather than to maintain a bleeding edge version requiring extra volunteer packaging work to very little effect. As you just wrote in another thread: "Jami is not yet ready for production use." [1] Installing by default a partly functional app might arguably be the worst option.
You might want to join the IRC meetings, that's most probably where these things are effectively discussed. It would make sense that people who suggest to manage an app as rolling-release also contribute their time to keep a recent version available. I personally have no suggestion to make, being quite happy with the current status of Trisquel and not currently doing any paid community management work.
[1] https://trisquel.info/en/forum/jami-vs-wire-vs-other-programs#comment-157600
I've packaged back ports for another distro and would be happy to do the same for Trisquel. However, I'm no expert in packaging and do best when I can follow a step-by-step guide. Unfortunately, pretty much none of the distros makes a decent packaging how-to. I'll bet that if Trisquel had a good packaging how-to that other users would be happy to volunteer as well. We all have spare machines lying around that could be put to work compiling; and compiling and packaging is quite fun. As it stands I don't know if Trisquel backport packaging is done with sbuild or pbuilder or some other tool. I don't know how the build tool would need to be setup, or if special patches would be required. I do know that there's tons of Ubuntu source packages that would be super easy to download and get to work on if there were some kind of Trisquel backport packaging how-to.
I do like that abrowser is kept up to date and that jxself makes so many modern linux-libre kernels available. I use abrowser and linux-libre regardless of which distro I'm working on.
So there seems to be an option there, after all.
However, all this backporting activity would also need to be managed: writing that good packaging how-to, deciding what gets backported, how, by whom etc.
The 'what, how, and whom' tends to take care of itself in my experience. Volunteer packagers tend to work on the packages they need first and foremost. And then they usually jump in to help when people in the forums start clamoring for a new package that they want. Then the backorts repo maintainer can decide what gets allowed in and what gets kept out.
The key is the backport packaging how-to. If you build it, they will come.
> "Various new packaging systems have attempting to solve the problem of out-dated users apps; AppImages, Snap, Flatpak etc but all of these seem to have issues of their own.”
You forgot one strypey, guix package manager. It's pretty much the ideal solution - works great on Trusquel, has tons of the latest software, all libre.
> Trusquel
I see you could not help creating yet another respin of a popular distro. What did you put into Trusquel? Some trusted peer authentication tool?
> guix
I agree. Guix probably has 99% of the packages for which most Trisquel users might possibly want a more recent version.
I am a translator!
I installed Guix on Trisquel but realized that actually I don't really need any of what it provides.
What I am worried about now is the upgrade to Trisquel 10, I suspect the best would be to uninstall Guix first but how to do that seems not covered in current documentation of Guix.
I would not worry too much about upgrading to Trisquel 10 when time comes, with or without Guix installed.
If I wanted to remove Guix, then I would try something along the lines of the following steps:
sudo systemctl stop guix-daemon.service
sudo rm -rf /gnu
sudo rm -rf /var/guix
sudo rm -rf ~/.profile/guix
sudo rm -rf /etc/guix
Please note that I would check the actual guix user profile paths first. I currently have no access to the machine on which I tried Trisquel9+Guix.
The solution is not basing Trisquel on an old LTS release of Ubuntu.
Rebasing Trisquel on Debian testing/unstable doesn't solve the freedom issue, but does solve the obsolescence issue.
"Rebasing Trisquel on Debian testing/unstable" doesn't solve anything: it creates problems where there is none.
To quote jxself's post above: "It sounds like you might be interested in the "rolling release" model instead? Something like Hyperbola may be more what you're looking for, since it's intended to work that way, rather than the "frozen on release" model."
You can always apply andyprough's libretizing protocol of Debian/Devuan if you are looking for something more familiar than Hyperbola and closer to FSDG compliance than vanila Debian.
Or install Guix on Trisquel - and feel the heat of the bleeding edge while comfortably sitting on your frozen Trisquel system.
Unfortunately, Hyperbola or Parabola or any other Arch-based distribution is practically unusable in our country. Whenever I perform an update, I could never retrieve public keys for certain packages to verify their signature. Surely said distributions are not to be blamed, but our fascist firewall.
We already purified our Debian installation for several years.
Can you share a respin of your purified Debian?
That would indeed be cool and noble help to us.
Alternatively, you could tell us what the purification process consisted of exactly.
Of course, you could also go as far as sharing the respin and telling us how it was made.
In return for this selfless gesture, we would promise never to use WeChat. Even with our Chinese or China-based friends.
For every Debian testing's weekly build, we perform certain routine modification to its installer (binary installer, not Live media). Basically, there are following major concerns:
1. When Debian installer detects non-free hardware (mostly, wireless NICs other than ath5k/ath9k), the original installer prompts users to insert a USB media containing the non-free firmware
2. If the users insert said USB media containing firmware but choose not to load firmware at this point, corresponding non-free hardware will not function during installation. However, the firmware would still be installed as long as the USB media containing them are connected during installation.
3. If any non-free firmware was installed during the installation process, "non-free" repository (but not "contrib") would be automatically enabled in /etc/apt/sources.list
But as long as the users don't provide such dirty USB media, the resulting operating system installations could be considered 99% free/libre (e.g. Firefox, if you insist that it's non-free).
We obtain Debian Installer weekly builds here:
https://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-dvd/
Thank you for your feedback, we shall keep away from WeChat (if ever we had been tempted).
I guess some people here would take issue with the remaining 1%, which is what you were probably referring to in your earlier post. Also, would your system not allow an unsuspecting user to enable non-free repositories by mistake?
Is there any specific reason why the Trisquel+Guix option would not fit your needs?
Idk what nadebula's reasons are but I can think of some too:
1. Debian stable is still more up-to-date than Trisquel.
2. It is possible to use Devuan instead of Debian and be systemd-free. There is no such alternative for Trisquel.
3. Some users perhaps want to keep some packages that merely "suggest nonfree" and besides that are free by themselves.
4. Debian supports more architectures.
> Idk what nadebula's reasons are
We believe you. Still, thank you for not answering the question.
The general reasons for using Debian are well known here, and generally not accepted as good enough. That might explain why people keep using Trisquel and enjoy it. Trisquel+Guix has the potential to make even more people happier, hence the specific question to a specific Debian user.
> It is possible to use Devuan instead of Debian
This does not sound like a good reason to use Debian.
- Anmelden oder Registrieren um Kommentare zu schreiben