Installation dump file uploaded.

Denis 'GNUtoo' Carikli wrote on 31 Aug 2023 18:30

Re: [bug #64569] Document how GNU Boot deblobs coreboot

Recipients:(address . 64569@debbugs.gnu.org)(name . Adrien Bourmault)(address . neox@gnu.org)

Message-ID:20230831183016.51542f74@primary_laptop

Hi,

Toggle quote (4 lines)

> It would be good that our documentation explains how GNU Boot deblobs

> coreboot for each board and how users can remove new blobs if they

> found some (it would help people to create patches for us, knowing

> where blobs are identified)

Having blob specific documentation not in the code would probably

increase maintenance cost if we want to keep it in sync with the code.

Another way to do that would be to do like with u-boot-libre which is:

- to document what is being removed directly in the source code

- to have only one source file that generates various released files

- to make it as easy as possible to reuse the source or various

released files like the script that does the deblobing, tarballs, etc.

- If time permits to do releases of that in two different ways:

- One as part of GNU Boot releases: we need to provide the deblobbed

Coreboot source code we use as part of GNU Boot releases.

- One separate that will look more like linux-libre that will not

patch Coreboot at all, but only deblob it and produce releases

matching Coreboot releases.

As for having multiple outputs:

- I've not looked in details but for instance Guix doesn't seem to

use linux-libre tarballs and instead it seems to produce its own

source files by running the deblobing scripts.

- Other distributions use linux-libre tarballs (like Parabola).

So if the goal is to make it easily reusable having multiple outputs

make it way easier.

A way to do it would be to unify the blob list files like that:

$ cat ./resources/coreboot/default/blobs.list \

./resources/coreboot/fam15h_rdimm/blobs.list \

./resources/coreboot/fam15h_udimm/blobs.list | sort -u

And then at least to add support for comments in this file list, and

find where to put that file (which is not as easy as it seems).

The advantage is that it would then be easy to do and easy to maintain.

As for moving the file, you might need commits like this one which is

in GNUtoo/various-fixes branch:

Toggle quote (2 lines)

> d73e45aa build: options: only show executables scripts

I'm not sure if it's sufficient but we can probably hack our way around

somehow by not listing resources/deblob for instance if we move it

there.

Denis.