Re: Canoeboot

[Denis 'GNUtoo' Carikli]

On Thu, 09 Nov 2023 09:26:02 +0200
Wael Karram via GNUBoot <gnuboot@gnu.org> wrote:

> Hello,
Hi,

> After having a discussion with bill-auger in the #parabola channel on
> Libera IRC about how to package coreboot utils for Parabola the issue
> of upstream source came up.
> 
> Currently it seems that Leah Rowe has made a downstream of Libreboot
> that is actually FSDG-compliant and happens to be more up-to-date
> than GNUBoot.
The point of using an upstream like Canoeboot or GNU Boot in Parabola
packages is that it takes care of the deblobbing.

This makes sure that Parabola doesn't redistribute nonfree software in
the source package and avoids all legal unknowns related to that.

Right now Canoeboot has a bug open[1] about an incomplete deblobbing.
Similar files are also present in Guix and there is also a bugreport
there.

But once the bug is fixed, Parabola will most likely face the question
of which upstream to use again.

Note that it's also possible to do the deblobbing yourself in the
package with mksource() but it's not always convenient to do that as it
increases the maintenance costs if the deblobbing procedure changes at
each release and also because mksource() can sometime be complex to use,
but it also gives you more freedom to pick the (Coreboot) upstream
versions you want and you don't need to wait for upstream to deblob the
things you want/need.

One of the goal of GNU Boot is also to make deblobbing easier for
downstream users, so over time we'll likely provide multiple ways for
packagers to reuse our deblobing procedure. I already added something
like that in Libreboot for u-boot some time ago but it was removed at
some point.

Another option could also be to use recent Coreboot and look if there
are still nonfree files in it. In the last Coreboot release the nonfree
microcode files seem to be gone as well the files with missing source
code that are found in Canoeboot or Guix, but I've not looked in
details if there are still problematic files.

Looking for more information on why these problematic files are gone in
Coreboot might also lead to some project statement that could give us
more assurance on if there might be other problematic files we missed
or not in its source code, so it's probably work worth doing.

If you're unsure which upstream to use and/or if you want to have the
ability to easily switch upstream an option could be to generate
package for the individual utilities in the PKGBUILD. It might still
require to take care of replaces= / conflicts= / provides= if you use a
meta-package or a package group that change name.

An option could be to use a generic name not specific to
Coreboot/Libreboot/GNU Boot/Canoeboot. For instance the U-boot package
also has a set of utilities. UEFI also has related utilities, etc.

Maybe some bootloader-utilities group could be an option that gives you
the best flexibility?

> This leaves the question of what is the utility of GNUBoot currently?
Currently there isn't a real release yet of GNU Boot and the website
isn't ready either so it's too early to compare the two projects.

You can see a somewhat similar situation with project changing
infrastructure for various reasons (data loss, forks, infrastructure
compromise, projects moving, etc) where it takes time to setup
everything again.

In our case both Libreboot and GNU infrastructure make different
incompatible assumptions, so we also needed to adjust the code and find
an easier way to deploy websites.

I think that in the long run this should be beneficial as we have
access to a lot more resources with GNU (such as automatic testing,
many tests machines, the ability to easily restore websites in case of
compromises, lot of possible automation, better backups, etc).

Right now the next milestone of the project is to have the website
officially published and to accept patches. This would also increase
the potential for collaboration.

> And could there possibly be a collaboration/merging of efforts with
> Canoeboot instead of the current duplication?
Responding to this question or not responding to it brings up a
complicated dilemma. But the response below alleviates many aspects
of this dilemma.

Since all involved projects are public, if you really need an answer
you can look at them yourself and you might find why responding to this
question is complicated.

Looking at the code bases can show in what areas it is possible or not
to collaborate. So you will see there are still some relatively small
areas of collaboration possible. This is the easy part. This can easily
be discussed publicly if you don't look at the human part of how code
can be or was merged.

But if you see very recent collaboration and look too much into the
details or that you try to find ways of collaborating that can work
between the 3 projects, a trigger warning[2] applies here.

> It is also worth noting that Canoeboot seems to have three more
> boards supported compared to GNUBoot (ASUS Chromebook Flip 101,
> Samsung Chromebook Plus v1, and Dell Latitude E6400).
I didn't find a Canoeboot image for Thinkpad X200, so the set of
supported computers looks different.

Also note that while most of the GNU Boot images have been tested and
are based on an older Libreboot release with minimal changes, we
also don't have an official release yet. For instance we lack
installation instructions.

Also given that we don't accept patches yet, people can't easily help us
fill the gaps between the two projects.

References:
-----------
[1]https://codeberg.org/canoeboot/cbmk/issues/1
[2]https://en.wiktionary.org/wiki/trigger_warning

Denis.

pgp5qkMJ8jqci.pgp
Description: OpenPGP digital signature