A Call For Volunteers To Maintain 32-bit Support
- Inicie sesión ou rexístrese para enviar comentarios
From today's meeting in #trisquel-dev on IRC it appears that the current plan is to drop 32-bit x86 for Trisquel 10, following what happened with upstream.
There are a number of reasons for this: All of the packages would need to be built from scratch, not just the ones that are modified for Trisquel.
This would not be for just the initial task of setting things up but an ongoing task as security and other updates become available and need packages to be updated. Please don't underestimate the size of that task. Further, upstream doesn't test that anymore, so the 32-bit ones may fail to build and need work to fix, making this an even larger ongoing task.
The current development efforts on Trisquel can't take this additional load.
quidam says he'd be happy to set up access for volunteers to work on building the 32-bit stuff and so: This is a call for volunteers. If you're interested in helping to do the work to compile 32-bit x86 packages for Trisquel 10 please get in touch with quidam on #trisquel-dev on irc.freenode.net.
I've built 32-bit debs, I'll talk to quidam soon.
Devuan is cranking out ISO's for amd64, arm64, armel, armhf, i386 and ppc64el as we speak, and is much simpler to turn libre than Ubuntu. You guys should consider making the switch to a Devuan base.
I'd personally much rather work from a Devuan base than from an Ubuntu base. Much cleaner.
Either Debian or Devuan is okay as the base of future Trisquel. To liberate either distribution, we don't need to do much more than disabling the firmware installation hint.
> Either Debian or Devuan is okay as the base of future Trisquel. To liberate either distribution, we don't need to do much more than disabling the firmware installation hint.
This is simply untrue. I feel like I must have explained a dozen times in this forum the ways in which Debian falls short of meeting the FSDG. The amount of work involved modifying Debian to meet the FSDG is approximately the same as modifying Ubuntu to meet the FSDG. It is just as trivial to exclude Ubuntu's Multiverse and Restricted repos as it is to exclude Debian's contrib and non-free repos, and once you do that the distros are pretty much the same freedom-wise.
I personally do think that Debian would be a better base than Ubuntu, but for reasons that have nothing to do with the FSDG, such as better architecture support (the subject of this thread), security updates for the entire repository, fewer hacky patches to important libs like GTK, and less code with dependencies on snapd (important for Trisquel since we don't package snapd), systemd (not currently important for Trisquel, but would be if we ever wanted to support other init systems), and Ubuntu's hacky patches to GTK.
Hello,
That is a shame, because 11 years through slackware, fedora, puppy, puppy, puppy, mint, bsd(s), devuan, Trisquel is the most pleasing, most successfully functional, least permission restrictive os that I have used. It is also the second most responsive on my older machines' hardware (of the pleasing part).
Thanks.
I am a translator!
When was the last 32 bit computer/laptop released? If I remember correctly some models of T60 and X60 are only 32 bit and those are 14 years old (I'm currently using a T60, thankfully with a 64 bit CPU).
There are still some 32-bit machines running that use libreboot. Given that there's a dearth of fully-free computers available it seems useful to continue to support them even if they are old to avoid cutting off the nose to spite the face.
I am a translator!
Right but Trisquel never prioritized the libre computers when making releases. The Yeelong didn't get a dedicated release (if I remember correctly gNewSense supported it shortly after it was released) and none of the ARM boards (even those that can be used in freedom) have Trisquel ports so it's unclear why special effort should be made to accommodate 14 year old computers. It's probably better to just base the release on a distribution with active 32 bit releases such as Debian stable or the current version of Hyperbola before they switch to a different kernel.
Rebasing on Debian is not an insane idea, though I don't see it happening anytime soon.
Rebasing on Hyperbola is a completely insane idea. Efforts are shifting to HyperbolaBSD, so there will likely never be a 1.0 release of Hyperbola GNU/Linux, so its package versions will remain stuck at their 2017 snapshots, a permanent downgrade from Trisquel 9. Switching from an apt-based upstream to a pacman-based upstream would require virtually all of Trisquel's code to be tossed out and rewritten from scratch, a massive undertaking that would immediately need to be repeated to rebase an another distro that is not abandoned.
HyperbolaBSD is a very cool project, and I fully support Emulatorman shifting his efforts in that direction, but it makes Hyperbola GNU/Linux a total dead end as a potential upstream for other distros.
> its package versions will remain stuck at their 2017 snapshots
Actually, it looks like there is going to be a 0.4 release based on a 2020 snapshot.
=> https://wiki.hyperbola.info/doku.php?id=en:main:releases
But this only delays the issue. Also, Hyperbola 0.4 will have a large problem:
Hyperbola 0.1-0.3 is based on a May 2017 Arch snapshot, and it uses patches from Debian stretch, which entered its soft freeze in January 2017, so Hyperbola 0.1-0.3 is only missing security fixes for vulnerabilities that were introduced during that four-month window, minus any vulnerabilities in packages that Hyperbola has purged from the repo and any vulnerabilities that Hyperbola's small team may have fixed themselves.
However, Hyperbola 0.4 is apparently based on a May 2020 snapshot, with patches from Debian Bullseye, which will enter its soft freeze in February 2021. This means that Hyperbola 0.4 will only have automatic security fixes for vulnerabilities which were introduced prior to May 2020, remained unfixed for at least nine months, and were then fixed after Febrarury 2021. Unless Hyperbola's small team somehow manages to do the work of hundreds of Debian maintainers while also creating HyperbolaBSD, this means that the whole repository is essentially unmaintained.
It's already a problem that we can't rely on Ubuntu for security fixes when it comes to the Universe repository. With Hyperbola 0.4 as an upstream things would be even worse. It would be like if Ubuntu's Main repository (which contains many, though unfortunately not all, of the security-critical packages) did not receive security updates either.
I am a translator!
I was thinking of something simpler - maybe Hyperbola and Trisquel cooperating and making a Hyperbola release for 32 bit computers with a graphical installer (I think arch has that option) and Trisquel's icon theme, splash screen etc would be included (it would essentially be a special Hyperbola release and not Trsiquel though so users would need to install packages via pacman). It would look similar to my Hyperbola desktop which has the trisquel icon theme (see bottom left of the attached image).
The only thing it would have in common with Trisquel is the branding. If Hyperbola ever decides that they want to attract less advanced users, it would be a good idea to create a graphical ISO with a default desktop environment and an installer, but none of Trisquel's code would help them with this because the metapackages for Trisquel's desktop flavors and the script that builds Trisquel's ISOs are both specific to Debian-based distros.
If someone were interested in creating a graphical edition of Hyperbola GNU/Linux, they would probably be better off borrowing code from Parabola, which has a MATE edition if I recall correctly (the Parabola website is down at the moment).
The result would not be useful to Trisquel users though. Trisquel 9 has more packages and newer packages than Hyperbola, so it would be a downgrade. Also, Trisquel is geared toward average users who want something like Ubuntu with the non-FSDG stuff removed. Hyperbola is geared toward a very different set of users who reject not only non-free software, but also a lot of popular free software for various reasons. Each distro should serve the needs and desires of its respective user base. An attempt to Trisquel-ize Hyperbola would please neither group.
I am a translator!
Actually it can have more in common than just branding - the hybrid distro can include the same software that comes with Trisquel by default (or Hyperbola's counterparts), e.g. a video editor (Avidemux or something else), an email client (e.g. Evolution), a browser (probably Iceweasel UXP and Iceape UXP) so that once you install it you get similar software to Trisquel by default and the only main difference is that non-repo packages will be installed from PKGBUILDs or from the AUR instead of from PPAs.
> the hybrid distro can include the same software that comes with Trisquel by default (or Hyperbola's counterparts)
Trisquel's default packages take the form of a metapackage. This approach is specific to Debian-based distros. Hyperbola may be able to take some inspiration from Trisquel's choices of default software, but not much since a lot of Trisquel' default software is incompatible with Hyperbola. Sure, you can replace Abrowser with IceweaselUXP, etc., but having a default browser and mail client is something every normal distro does. It's not at all unique to Trisquel.
Also, not all of Trisquel's software has a Hyperbola equivalent. For example, Hyperbola has banned NetworkManager, which is the only way to connect to certain WiFi hotspots, such as those on many university campuses, without using a terminal or editing a text file, too difficult for Trisuqel's target audience. This is an edge case that would not affect all users, but smoothing out edge cases like these so that a broad range of users have something that works out of the box for them is how Trisquel is designed, and what its users like. Hyperbola is the opposite.
> the only main difference is that non-repo packages will be installed from PKGBUILDs or from the AUR instead of from PPAs
The main difference is that it will not be a distro appropriate for the average user, which is Trisquel's target audience. One reason for this is the difficulty of installing out-of-repo software on Hyperbola*, but it is far from the only reason. You seem to think that Hyperbola just needs some prettying up to meet the needs of the kind of person who uses Trisquel. This would be like putting lipstick on a pig. Trisquel and Hyperbola have incompatible philosophies. Hyperbola should focus on serving its niche, and Trisquel should focus on its own.
*AUR packages are intended for a rolling distro and often require never versions of their dependencies than those in Hyperbola. They are also intended for systemd and so often lack OpenRC scripts or are configured to make use of systemd-specific features. They also assume that /usr/bin is a symlink to /bin. Hyperbola is not compatible with a larger distro like Trisquel is with Ubuntu, so software for Hyperbola needs to be packaged specifically for Hyperbola, and lots of Hyperbola packages have been removed from the repo.
In my experience, attempting to contribute to Trisquel is a futile and frustrating experience, in which it takes weeks to months for even simple changes to be merged, making it nearly impossible to get anything significant done. Unless there has there has been a really massive change in how Trisquel development works, "quidam says he'd be happy to set up access for volunteers" sounds like a nice way of saying "32-bit support is not happening."
I haven't had a look at how development happens on the inside, but I also find it very hard to believe that Trisquel can set up its own build-infrastructure to build all 32-bit applications by itself, given how long it takes for a release to happen in the current state of things.
I know the development of Trisquel has very limited resources, so I don't blame anyone. I just don't think this plan is feasable.
Then a Devuan respin makes a lot more sense. One Devuan respin, Exe GNU/Linux, already claims to be completely libre.[1] I've used it, it was quite enjoyable. It has 32 bit and 64 bit downloads.[2] Could be worth taking a look at, for ideas on how Exe's dev goes about it.
[1] http://exegnulinux.net/
[2] https://sourceforge.net/projects/exegnulinux/files/iso/
At first glance at least, it looks like just a preconfigured Devuan ISO. Unless Exe has independent repositories which exclude certain Devuan packages and replace others with modified versions, zero work has gone toward meeting the requirements of the FSDG.
You may want to check again - There's a new setup going and you specifically are included in the whitelist. So merges from those trusted people such as yourself get their changes built automatically. The results are stored in the development repo. Then, after being approved, they are built again and sent to production repo. 100% automated.
Many hands make light work. Are there any recommended resources for learning to do such a thing? Also, how much volunteer time per week could one expect to devote to this?
Anyway, it seems important to keep support for 32 bit. I hope it works out.
If anyone is interested in volunteering, I am willing to teach them everything they need to know over IRC. I am too busy at the moment to make any large contributions to Trisquel directly, but I can set aside a few hours to teach others. If doing so increases the size of Trisquel's development team, it will be time well spent.
I will follow this closely.
By now I don't have enough skills or time to make significant contributions to 32 bit support in Trisquel, but if there is an IRC channel with such teachings, I can seriously consider getting involved and maintaining some packages that suit beginners (apps that don't connect to the web for instance).
When it comes to 32-bit supprt, I don't expect it to matter much whether an application connects to the web or not. Ubuntu still tests all these packages on other architectures, so the only problems we should run into are those that only affect i386. The most common problem will be a program that fails to build from source on 32-bit. In this case, it shouldn't matter too much what the program actually does. You just need to figure out why it's not compiling, and fix that. The workflow will likely often look like this:
1. Pick a package that is currently failing to build from source on i386
2. Attempt to build it and hit an error
3. Search the web for the name of that package, "i386" or "32-bit", and the error you got
4. Find a thread in which someone else ran into this error, or a bug report in which another distro ran into this error
5. See how they fixed it
6. Use your knowledge of shell scripting, sed, and git (this is the part I would teach you) to apply the fix to Trisquel and submit a merge request
Thanks for being willing to do this, chaosmonk. I'm interested in the IRC session, I'm just not clear on how much time could need to be devoted by each individual contributing to a 32-bit support long-term. That would be good to have some idea of. I already have some basic familiarity with the stuff you listed, so I'm optimistic that I can pick it up quickly and then from there see if I'm able to make a useful contribution. But I have one potentially dumb question: is a 32-bit computer required to build the 32-bit packages?
> I'm just not clear on how much time could need to be devoted by each individual contributing to a 32-bit support long-term.
As a volunteer, you can contribute as much or as little as you choose.
If you are asking how much total work will be required from everyone to make 32-bit support happen, I'm not sure. This Friday I plan to go to the week's meeting and get updated on the situation.
If you mean how much time will it take befor your efforts result in a useful contribution, I'm also not sure yet. Probably a few hours for training, and after that it would depend on how efficient of a workflow for working on the packages we come up with, and how long each package takes. That I don't know yet, I would say that if it takes more than a few hours to fix an average 32-bit package, then unless the number of packages that needs attention is very small then this is probably not a realistic endeavor.
> is a 32-bit computer required to build the 32-bit packages?
Nope. You can be using any Debian-based distro on any architecture. We use sbuild to compile packages in a chroot for the target architecture.
Will be busy till after the 25th, but would like to find a way to contribute back to the community. Building, researching, and problem solving isn't very difficult, however I would need some mentoring on the shell scripting/sed/git side of things.
@jxself
I'll try to stop by Friday and get caught up, but maybe you can tell me whether any discussion has taken place about setting up CI. In the past, the number of packages compiled by Trisquel has been small enough to test manually. If we are going to start compiling thousands of 32-bit packages, we probably want to automate that.
Debian uses autopkgtest to test packages for regressions before migrating them from unstable to testing. Perhaps we could run the same tests for our 32-bit builds to help identify packages that need attention.
=> https://wiki.debian.org/ContinuousIntegration/autopkgtest
That does seem a good idea.
To chaosmonk, what a pleasant news, I wish you success in your PhD.
- Inicie sesión ou rexístrese para enviar comentarios