GNU bug report logs - #64569
Installation dump file uploaded.

Previous Next

To reply to this bug, email your comments to 64569 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: gnu <raulvior.bcn <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: Installation dump file uploaded.
Date: Mon, 10 Jul 2023 21:37:58 +0200

Installation fails at last step due to not enough storage. Uploaded 
file as installer-dump-93af8d14.

Message #8 received at 64569 <at> debbugs.gnu.org (full text, mbox):

From: Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
To: 64569 <at> debbugs.gnu.org
Cc: Adrien Bourmault <neox <at> gnu.org>
Subject: Re: [bug #64569] Document how GNU Boot deblobs coreboot
Date: Thu, 31 Aug 2023 18:30:16 +0200

[Message part 1 (text/plain, inline)]

Hi,

> 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:
> 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.

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.