[Dev] libreboot-utils, moving forward.

[Denis 'GNUtoo' Carikli]

On Sun, 18 Dec 2022 13:19:57 +0200
Wael Karram <wael at waelk.tech> wrote:

> On Sun, 2022-12-18 at 01:42 +0100, Denis 'GNUtoo' Carikli wrote:
> >   
> > > Seeing as libreboot isn't strictly FSDG-compliant anymore, and
> > > since we were using it as a deblobbed coreboot downstream to
> > > build the binaries (all of which are still free software) in
> > > libreboot-utils; should we simply do a git checkout of the free
> > > parts on the build (and that way side-step the blobs - as they
> > > are in a separate directory).
> > > 
> > > Does that seem like a reasonable solution?  
> > That is probably not sufficient, if I recall well, some of the files
> > libreboot removes have nonfree software in them. Since that nonfree
> > software will not be removed anymore, we won't be able to use the
> > newer tarballs.  
> Pertaining to the issue of non-free software, it is mainly support
> blobs and microcode - the tools coming from upstream coreboot as
> still the same as before. Hence deblobbing and scrubbing the
> problematic parts isn't hard at all (though it does raise the
> question of just using upstream coreboot instead anyhow).
The advantage of having a project like Libreboot is that any non-Android
distribution can very easily reuse the released tarballs. So if we'd
want to add nvramtool in Guix for instance, the libreboot tarballs
could be reused.

> > I'm already in discussion with other people to continue a libre
> > version of Libreboot. Personally I need that to update the u-boot
> > packages in Parabola, so it's quite urgent for me.  
> As for uboot, I am not quite sure what the solution would be -
> possibly looking at the deblobbing scripts from earlier releases?
I was the de-facto maintainer for the u-boot part in Libreboot. So once
the project is setup, I'd just to continue maintaining that part like I
did before: I'd push the patch that Leah refused because it deblobbed
more u-boot and make a new tarball release.

My patch also had issues with reproducible builds, but that's not ultra
urgent to fix, so I'll try to find the time to fix that later on.

> > Another issue with the tools is that Leah's Libreboot dropped
> > support for some of the boards it supported before like the KGPE
> > D16. And the tools probably work fine with the previous release of
> > Libreboot. So the issue here is that ideally the tools should also
> > be tested against the older release as well because of that.
> > 
> > Parabola has a KGPE-D16 so it might be easy to do some quick tests.
> > 
> > Denis.  
> At least when it comes to the tools strictly on their own; they
> should generally be release-agnostic, as even on boards that were
> dropped they should work still (most of them should really work with
> just about any computer, they're accessing low-level interfaces).
Most of them are indeed. I was more concerned about tools like cbmem or
nvramtool that have to interact with Coreboot somehow. 

As far as I know Coreboot doesn't have guarantee that it won't change
the interfaces, so it's probably best to at least do a quick test on
the Parabola's D16. I have access to it at least (I'm not sure who else
does though). The test can probably even done after the packages have
been released but it's good to do it to avoid bad surprises.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20221220/7c35a382/attachment.sig>