The mention of LibertyBSD was removed in the OpenBSD page, because
according to the LibertyBSD web page: "LibertyBSD's dormant, and in
archive-mode."[1]. The LibertyBSD project also point to the
HyperbolaBSD project as a future alternative to LibertyBSD ("Support
HyperbolaBSD!"[1].).
[1]https://libertybsd.net/
Given that we still mention that the tutorial was made for LibertyBSD
as well but we point to the BSD index page for the warnings and a way
forward (which is basically HyperbolaBSD) to improve support for BSD
systems in GNU Boot.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Since the GNU Boot project doesn't want to force any of its
contributors to test with nonfree distributions or operating systems,
we can't review the accuracy of the BSD pages, and there are no GNU
Boot users who already use BSD systems that contacted the GNU Boot
project.
So the solution here is instead to document the current project
decisions, to point to freedom reviews of the BSD operating systems by
the GNU project, and to convert the articles to refer to what
Libreboot stated about BSD systems, while taking the point of view of
GNU Boot.
Since Libreboot already very strongly discouraged the use of GRUB to
boot encrypted BSD systems, users using BSD systems probably have
followed this advice or were aware of it, so this enables us to remove
support for BSD encryption inside GRUB without the need to try to
directly contact users.
Still, as I plan to try to do that (to reduce GRUB's size for
computers with 512KiB flash size), it's still a good idea good idea to
document it inside the page as well to explain why, according to GNU
Boot (and not LibreBoot) it is a good idea not to rely on GRUB images
for booting encrypted BSD systems.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The history/git-history.jpg file is supposed to be generated so we
don't want to track it in git.
This was broken by the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This was broken by the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
In the Makefile we have the following:
if WANT_GUIX
check: build website.tar.gz index.html history/git-history.jpg
rm -rf site/
mkdir -p site/$(WEBSITE_PREFIX)
tar xf website.tar.gz -C site/$(WEBSITE_PREFIX)
Here the mkdir is used outside of a guix shell, so we need to also
check option, so we need to also check if mkdir is is present when using
guix to build the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
In the Makefile we have the following:
pages/footer.include: pages/footer.include.tmpl pages/footer-git-commit.include
cat \
[...]
This rule is valid reguardless of the '--without-guix' configure
option, so we need to also check if cat is present when using guix to
build the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
In the Makefile we have the following:
help:
@printf "%s\n\t%s\n\t%s\n\t%s\n\t%s\n\t%s\n\t%s\n" \
[...]
This rule is valid reguardless of the '--without-guix' configure
option, so we need to also check if printf is present when using guix
to build the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
In the Makefile we have the following:
pages/footer-git-commit.include:
rm -f $@
[...]
This rule is valid reguardless of the '--without-guix' configure
option, so we need to also check if rm is present when using guix to
build the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
In the Makefile we have the following:
index.html: index.html.tmpl
sed -e "s#WEBSITE_PREFIX#$(WEBSITE_PREFIX)#g" "$^" > "$@"
so we need to make sure that 'sed' is available.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Since GNU Boot currently lacks reproducible builds, building GNU Boot
from source can be a good idea.
However currently the only supported and documented way of build GNU
Boot requires to download GNU Boot from git (signed tarballs and/or
git bundles are completely untested and not supported yet), and while
the commits are signed with GPG, there is no easy way to check the
integrity and authenticity of the source code.
To do the check a person or a program would need to get the keys of
the two current maintainers and somehow do the check with git
directly.
Using "guix git authenticate" instead enables to do that more easily:
only one command is needed, and the command will more likely keep
working over time than the method mentioned above.
Guix is also improving it over time: for instance it recently added
automatic checks through git hooks (through the guix commit
8d1d98a3aa3448b9d983e4bd64243a938b96e8ab ("git authenticate: Install
pre-push and post-checkout hooks.").
Since:
- the "guix git authenticate" command was introduced in the Guix
commit a98712785e0b042a290420fd74e5a4a5da4fc68f ("Add 'guix git
authenticate'."), between Guix 1.1.0 and Guix 1.2.0
- at the time of writing only the following free distributions have
a guix package: Guix, Parabola, PureOS 10 (byzantium), and that
PureOS 10 has the oldest Guix version (1.2.0)
there is probably no need to update Guix in most cases. This
facilitates checking even more, especially because Guix is already
required to build GNU Boot.
In contrast if we look at an alternative called "in-toto"
(https://in-toto.io/), it's not packaged in Dragora, Guix, and
Hyperbola but it's packaged in Parabola, PureOS (10), Trisquel (10,
11), and in very few nonfree distros
(https://repology.org/project/in-toto/versions).
And even if in-toto was packaged in Guix, it would take way longer to
get it through Guix as it's not in Guix 1.4.0 and we would then need
to download a complete set of dependencies just for in-toto as
backporting it would break the chain of trust.
And in-toto is also meant to authenticate complete "supply-chains" and
so it manages well the distribution of responsibilities in an
organization where the people responsible for building releases and
writing the code are different for instance, and so it can easily
manage the signature and authorization of git tags, but I found no
example for signing each git commit in a given branch (see
https://github.com/in-toto/demo and
https://medium.com/synechron/securing-your-software-supply-chain-with-in-toto-5b90a6423c88
for more details).
And here it would be problematic to only secure tagged commits as it
would in practice prevent users that care about source code integrity
from building commits that are not tagged without reviewing them
manually again and again. And doing work to secure all commits would
probably be time consuming and/or error prone, and in contrast 'guix
git authenticate' is readily available.
In addition, at the time of writing current or potential users and/or
contributors to GNU Boot are probably more familiar with "guix git
authenticate" than "in-toto" because the former is mentioned in the
Guix manual and its use is documented on the Guix blog
(https://guix.gnu.org/en/blog/2024/authenticate-your-git-checkouts/)
and in conferences.
In contrast in-toto is also promoted in conference(s) and it's already
used by projects like GitLab, Jenkins, rebuilderd, etc
(https://github.com/in-toto/friends) but then no GNU projects or FSDG
distributions seem to use in-toto or to promote it, so fewer current
or potential GNU Boot users and/or contributors are aware of it.
This also means that learning to use "guix git authenticate" is more
likely to be useful for GNU Boot users and/or contributors than
learning "in-toto".
To use "guix git authenticate", we need to add a .guix-authorizations
file in the branches we want to be able to authenticate, and we do
that in this commit, but this is not sufficient as we also need to add
the committers keys inside a "keyring" branch in the same repository.
The keyring was already added in the commit
4a82cc82d2 ("Add GNU Boot committer keys
for "guix git authenticate".").
In addition documentation also needs to be written to explain how to
use "guix git authenticate" with GNU Boot, for instance to document
which branches are expected to be authenticated, and the command to
type.
This will however be done later on as this would require the commit ID
of this commit, and it's impossible to forge a commit whose ID is also
in the commit message or changes without breaking the security of git
or without writing complex code that retrieves the commit ID
dynamically.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without this fix we have the following error on Trisquel 11 when
building the GRUB payload:
configure: error: qemu, coreboot and loongson ports need unifont
Trisquel 10 also has an 'unifont' package, and installing it doesn't
break the build of the GRUB payload.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
When pandoc is already installed on Trisquel 10, we have the
following:
# pkcon -y --allow-reinstall install pandoc
Resolving [=========================] Package not found: pandoc
Command failed: This tool could not find any available package: No packages were found
Since install_packages takes care of not trying to reinstall a package
that is already installed, using that instead fixes this issue.
This was broken by the commit 8a181f112f
("dependencies: trisquel: Add pandoc").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In French 'Installed' is 'Installé', and so when French is being used,
the grep that is used to understand if a package is already installed
fails.
This was broken by the commit 5050b5365e
("dependencies: trisquel-10: workaround package not found if already
installed.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The entries inside the "Verified copyright headers" section refer to
commit hashes. And since a commit can't refer to itself (unless SHA1
is broken), we split that in two commits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The trisquel-10 file was first introduced by Leah Rowe in 2014 as it
cannot be found in 2013 Libreboot tarball releases (20131212,
20131213, 20131214) but it is found in 20140711.
We then have the complete history through the
obsolete-repository-preserved-for-historical-purposes, osbmk and GNU
Boot repositories.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The build system was designed to produce images with different GPU
drivers for a single computer and/or to show the image name in the
final image names, to enable users to know which GPU driver was used.
However since all boards have practically speaking the same GPU driver
('libgfxinit') this adds too much complexity for almost no benefits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The seabios_grubfirst images provides the same functionality than the
GRUB images, but instead of having GRUB being loaded directly by
Coreboot, Coreboot loads SeaBIOS which then loads GRUB.
These images probably exist to enable end users to try it to workaround
potential compatibility issues between the OS and GRUB with the GRUB
image as we have a BIOS implementation being loaded.
While this looks useful, it also makes things more complicated:
- It increase the number of images to choose from, and it's
complicated to explain the difference between grub and
seabios_grubfirst to end users.
For instance for the "x200_8mb", users need to choose between 2 GPU
modes (corebootfb, or txtmode) and 12 keyboard layouts. So having to
choose between 2 payloads instead of 3 with one difference that is
hard to understand makes things easier.
- It makes testing more complicated as we have one more payload to
test and we also need to make sure to always differenciate both
images in bug reports, documentation, etc.
And if issues arise from this change in the future, we could work with
upstream to fix them and/or replace the grub images with
'seabios_grubfirst' while keeping the 'grub' name to avoid
complicating things by having two main payloads with identical
features.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in commit message
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The entries inside the "Files with an incomplete copyright header"
section refer to commit hashes. And since a commit can't refer to
itself (unless SHA1 is broken), we split that in two commits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Note that we only have the history of the global.css file since the
commit 501e77d996 ("libreboot site").
Since this "libreboot site" commit is about 38000 lines, and that some
pages contain many translations (site/news/rms.md is translated in 20
languages), it is most likely that it was based on an earlier history
of either the older Libreboot website, or the osboot website if it
existed at the time.
The license however is easier to find as the commit mentioned above
has site/license.md which has the following:
Unless otherwise stated, every page and image (e.g. JPG/PNG files) on
libreboot.org or in the repository that it is built on, is released under the
terms of the GNU Free Documentation License, either version 1.3 or (at your
option) any newer version as published by the [Free Software
Foundation](https://www.fsf.org/), with no Invariant Sections, no Front Cover
Texts and no Back Cover
Texts.
And both the osboot website or the older versions of the Libreboot
website also used the same license (GFDL 1.3+ with no Invariant
Sections, no Front Cover Texts and no Back Cover Texts).
Also while I touched the global.css file I didn't modify its content,
including in the commit 0e3ff8047f
(Announce and release GNU Boot 0.1 RC2 and project status.) where I
extracted global.css from site/template.include. This can easily be
verified with meld. Because of that there I didn't add my copyright in
this file.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following build error on Trisquel when
qemu-utils is not installed:
successfully built /gnu/store/[...]-gnuboot-trisquel-preseed.img-07-2024.drv
resources/packages/roms/download: line 175: qemu-img: command not found
make: *** [Makefile:713: release] Error 127
An option would be to make sure that the host has qemu_img by adding
its corresponding packages in resources/dependencies/ and to check for
it in configure.ac, but since we already build the qemu with Guix,
it's easier to just reuse that, and this also gives us less
maintenance in the long run.
This was broken by the commit 9cc02ddde1
("packages: roms: Start adding automatic tests.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The "4.7 Mcopy" section inside the mtools info manual explains that
mcopy's '-m' argument "Preserve the file modification time.".
So in the commit 9cc02ddde1 ("packages:
roms: Start adding automatic tests."), I vaguely recall having used it
to workaround some reproducibility issues.
Guix 1.4.0 uses mtools 4.0.42. So after retrieving the source with
'guix time-machine --commit=v1.4.0 -- build --system=i686-linux
--source mtools' we have that in the writeit function in mcopy.c (with
arg->preserveTime being set by -m):
/* preserve mod time? */
if (arg->preserveTime)
now = date;
else
getTimeNow(&now);
And date is set by the following in mtools 4.0.42:
if (Source->Class->get_data(Source, &date, &filesize,
&type, 0) < 0 ){
fprintf(stderr, "Can't stat source file\n");
return -1;
}
Since Guix is supposed to make images reproducible somehow, and that
mtools isn't patched by Guix to do that, and that it takes the time
from the source file, I used '-m'.
Since I was confident enough that gnuboot-trisquel-preseed.img was
reproducible, in the commit 9cc02ddde1
("packages: roms: Start adding automatic tests."), I also added the
checksum and checked it at build time to make sure the image is really
reproducible.
But when building this image again few days ago the checksum was
different. So I used the Guix diffoscope package to investigate the
issue.
Note that at the time of writing, you either need to use Guix's
diffoscope or to disable guestfs support in diffoscope for it to work,
otherwise diffoscope 277-1 (the version in the Parabola at the time of
writing) produce a python error probably because the partition table
size is 0, and it contains a FAT12 filesystem according to fdisk, but
then the FAT12 filesystem contained within also contains that
partition table. See the upstream bugreport at
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/390
for more details.
Here the preseed.img.old file corresponds to the checksum in the
commit 9cc02ddde1 ("packages: roms:
Start adding automatic tests."), and preseed.img.new to the one I got
by building again few days ago:
$ sha512sum preseed.img.old preseed.img.new
f12a4a941afc9e24288481ed1b44fbfedf52d706e9e8aa01cfb26bf5ccd54ca52afe9ef5497faf2966ba730c1200d8b8691ebb87e6a75cd8966e0edd49bcb3c0 preseed.img.old
5613d9a5cdd8847d5a688d56c77b8cf8881baa5eef7f373bb05a5ec601e383204e6a57b399d3de913c29386b18e7e3903c9511037922204744e3234cadc8671b preseed.img.new
And by using diffoscope we have:
$ diffoscope preseed.img.old preseed.img.new
--- preseed.img.old
+++ preseed.img.new
│┄ Format-specific differences are supported for ext2/ext3/ext4/btrfs/fat filesystems but no file-specific differences were detected; falling back to a binary diff. file(1) reports: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 2048 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 2, sectors/track 16, serial number 0x1234abcd, label: "MEDIA ", FAT (12 bit)
│┄ Installing the 'guestfs' Python module may produce a better output.
@@ -157,23 +157,23 @@
000009c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000a00: 4d45 4449 4120 2020 2020 2008 0000 5a4b MEDIA ...ZK
00000a10: 6e46 6e46 0000 5a4b 6e46 0000 0000 0000 nFnF..ZKnF......
00000a20: 5052 4553 4545 4420 4346 4720 1800 0000 PRESEED CFG ....
-00000a30: 21ec 21ec 0000 0000 21ec 0200 f50d 0000 !.!.....!.......
+00000a30: 21ec 2859 0000 0000 21ec 0200 f50d 0000 !.(Y....!.......
00000a40: 4365 0000 00ff ffff ffff ff0f 0000 ffff Ce..............
00000a50: ffff ffff ffff ffff ffff 0000 ffff ffff ................
00000a60: 0272 002d 0062 006f 006f 000f 0000 7400 .r.-.b.o.o....t.
00000a70: 2e00 7300 6500 7200 7600 0000 6900 6300 ..s.e.r.v...i.c.
00000a80: 0173 0068 0075 0074 0064 000f 0000 6f00 .s.h.u.t.d....o.
00000a90: 7700 6e00 2d00 6100 6600 0000 7400 6500 w.n.-.a.f...t.e.
00000aa0: 5348 5554 444f 7e31 5345 5220 0000 0000 SHUTDO~1SER ....
-00000ab0: 21ec 21ec 0000 0000 21ec 0400 3002 0000 !.!.....!...0...
+00000ab0: 21ec 2859 0000 0000 21ec 0400 3002 0000 !.(Y....!...0...
00000ac0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ad0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ae0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000af0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b00: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b10: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b20: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Here it really look like a timestamp, and since mdir gave no
difference between the 2 files inside the 2 images, I patched mdir
with the following patch:
@@ -438,6 +438,18 @@ static int list_file(direntry_t *entry, MainParam_t *mp UNUSEDP)
if(*mdir_longname)
printf(" %s", mdir_longname);
printf("\n");
+
+ printf("-> ctime_ms: 0x%hhx\n", entry->dir.ctime_ms);
+ printf("-> ctime[0]: 0x%hhx\n", entry->dir.ctime[0]);
+ printf("-> ctime[1]: 0x%hhx\n", entry->dir.ctime[1]);
+ printf("-> cdate[0]: 0x%hhx\n", entry->dir.cdate[0]);
+ printf("-> cdate[1]: 0x%hhx\n", entry->dir.cdate[1]);
+ printf("-> adate[0]: 0x%hhx\n", entry->dir.adate[0]);
+ printf("-> adate[1]: 0x%hhx\n", entry->dir.adate[1]);
+ printf("-> time[0]: 0x%hhx\n", entry->dir.time[0]);
+ printf("-> time[1]: 0x%hhx\n", entry->dir.time[1]);
+ printf("-> date[0]: 0x%hhx\n", entry->dir.date[0]);
+ printf("-> date[1]: 0x%hhx\n", entry->dir.date[1]);
} else {
char tmp[4*MAX_VNAMELEN+1];
And this then gives the following diff:
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
@@ -20,8 +20,8 @@
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
This means that the access date difers. This also explains why it was
not spoted during the creation of the commit
9cc02ddde1 ("packages: roms: Start
adding automatic tests.") as tests were done at the same date.
So this time I created a build VM by adding the following service to
my Guix system configuration (I also had to remove hacks I had that
set the kvm group id to the same ID used by Trisquel run 'guix system
reconfigure' and rebooted):
(service virtual-build-machine-service-type
(virtual-build-machine
(cpu "host")
(cpu-count 2)
(auto-start? #f)))
This created a VM whose clock is set to 'a few years ago' according to
the Guix manual[1].
[1]https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#Virtual-Build-Machines
I then ran built the image as usual:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img
--without-tests=gnuboot-trisquel-preseed.img
I then copied the resulting image, started the build VM with 'herd
start build-vm', deleted the old image from the store (with 'guix gc
-D') and then re-built it (it used the VM to offload the build as
shown in the build logs).
And now both resulting files are now the same despite being built on a
different date.
See also the following blog post for more context into use cases for
this build VM[2]:
[2]https://hpc.guix.info/blog/2024/03/adventures-on-the-quest-for-long-term-reproducible-deployment/
Bug: https://savannah.gnu.org/bugs/?66224
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The image resulting from the gnuboot-trisquel-preseed.img package is
checked against checksums inside the 'check function of this package.
If for some reasons we want to update the checksums, an easy way to do
it is to build the package but not run the 'check function and do the
checksum on the resulting file. The Guix 1.4.0 manual explains how to
not run 'check with the "--without-tests=package" option in the
"10.1.2 Package Transformation Options" section.
However if we attempt that with the following command, the
without-tests has no impact at all:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img \
--without-tests=gnuboot-trisquel-preseed.img
This changes makes the above command work as expected.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The test data consists mostly in nonfree boot firmware images. The
images contain nonfree binaries like for instance microcode updates
without complete and corresponding source code.
As more and more boot firmware images are added over time it's a good
idea to just remove everything in that directory to make sure that we
don't ship nonfree software from that directory again, while also
lowering the maintenance costs.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit fixes an error encountered on Trisquel 11 while trying to
build the fam15h coreboot crossgcc 8.3.0:
In file included from /usr/include/signal.h:328,
from /usr/include/x86_64-linux-gnu/sys/param.h:28,
from ../../gcc-8.3.0/gcc/system.h:298,
from ../../gcc-8.3.0/gcc/ada/init.c:65:
../../gcc-8.3.0/gcc/ada/init.c:575:18: error: missing binary operator before token "("
575 | # if 16 * 1024 < MINSIGSTKSZ
| ^~~~~~~~~~~
make[1]: *** [Makefile:1110 : ada/init.o] Erreur 1
The changes of the GLIBC that removed the MINSKTSZ constant was
introduced only for systems using the Linux kernel, and while the
changelog is recommanding using sysconf to get the value of
`_SC_MINSTKSZ`. The problem is that it does not allow to get the value
in the preprocessor context.
This error has been corrected on upstream GCC by Eric Botcazou <ebotcazou@adacore.com>
but this was not applied on upstream coreboot (even 4.11 branch).
It has been accepted by GCC and the bug report has been set as RESOLVED
FIXED, meaning it solved the bug.
The MINSTKSZ patch is needed for all GCC versions from 8 to 9, since this
commit solved the bug for 9, 10 and later versions. It has been adopted
by OpenSUSE for its GCC 8 package:
https://build.opensuse.org/projects/devel:gcc/packages/gcc8/files/gcc8-ada-MINSTKSZ.patch
Here's the corresponding patch header (in debian's format:
https://dep-team.pages.debian.net/deps/dep3/):
Origin: upstream, https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a5a7cdcaa0c29ee547c41d24f495e9694a6fe7f1
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264
Bug-GNU Boot: https://savannah.gnu.org/bugs/?64870
The MINSTKSZ patch added by this commit is unmodified from the
OpenSUSE one mentioned above, and the OpenSUSE patch is probably a
backport of the upstream GCC patch as there is not difference in what
it does.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: small formatting of the commit message + last paragraph.
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
We have redundant news systems: GNU Boot is already using GNU and
Savannah's new infrastructure, so we don't need to duplicate that on
the GNU Boot website.
This lowers the maintenance now (as we need to do less work to publish
news).
But it also lowers the amount of work in the future as Untitled (the
static website generator that we use) handles news generation
differently from the rest of the pages, and since we planned to
migrate to Haunt, getting rid of news generation should probably
divide the amount of work needed to do the migration by two.
Thanks a lot to Adrien 'neox' Bourmault for the help with this patch
(neox gave me the links, told me about the capabilities of Savannah,
Planet, etc).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
We have a test for catching a situation where new files are added in
releases without adding them as well in the ${release_files} variable
to test for their existance.
But this test only warn of the issue instead of failing. And since
people might not inspect all the log details in depth, it's better to
fail instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Before this commit if some files were in the release directory but
missing from ${release_files}, it would show something like that:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar
The ${release_files} variable is used to test for files missing in the
release directory, and it prints something if a file is missing:
[ !! ] release/roms/gnuboot-0.1-rc3-95-g1783708_d510mo.tar.xz is missing
Since confusion is possible between the two tests (especially if the
people looking at the log don't have all the code and context in mind
when doing that), this commit changes the code to print something like
that instead:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar missing in ${release_files}
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
This was broken by the commit 7df6d6169b
("Build bucts and patched flashrom for I945 ThinkPads with Guix.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix the build is stuck on the following during days on a
ThinkPad X200 with 8GiB of RAM and an Intel P8600:
building /gnu/store/z7k1rs4j98s5zj0f9xrn1p3k1w1fmgqa-proot-static-5.3.0.drv...
/ 'check' phase
And the Guix manual says the following about -R/-RR:
When this option is passed once, the resulting binaries require
support for “user namespaces” in the kernel Linux; when passed
_twice_(1), relocatable binaries fall to back to other techniques
if user namespaces are unavailable, and essentially work
anywhere—see below for the implications.
So by using -R instead of -RR we don't build proot-static anymore, and
we rely on the fact that most GNU/Linux distribution have namespaces
enabled (else a lot of packages like Guix or container software
would not work on them).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typo in commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
It can be handy to build GNU Boot in a chroot because Guix's
debootstrap can easily debootstrap both PureOS byzantium and Trisquel
10 (nabia), and once done users can simply chroot inside the target
rootfs. In addition chroots also don't have much isolation with the
host, so it is easy to set it up in a way that export /dev/kvm for
faster testing.
The downside is that while some init systems can start daemons while
in chroot, systemd chose not to support that as the separation between
the chroot and the host operating system is not good enough to prevent
accidental modifications of the host system[1].
So practically speaking if we want to start guix-daemon, 'systemctl
start' detects that it's in a chroot and refuses to work.
The concerns of systemd about running some init in chroots[1] is valid
however here we limit the risk by only running the daemon start
commands and not something else that kills host processes.
Also we choose to parse systemd units instead of running the commands
manually as some settings need to be retrieved from the distribution
such as the environment or the build group being used (this varries
accross distributions or installation methods).
[1]https://0pointer.de/blog/projects/changing-roots
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed whitespace issue in code and fixed commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
We need to somehow isolate the git configuration being used to build
GNU Boot from the rest of the system as otherwise things like
automatic gpg signatures can kick in and block the build because it
waits for a pinentry.
In addition:
- It enables us to simplify the build code as the git configuration is
now the same during all the build.
- Contributors don't need to setup git anymore just to build GNU
Boot. This also makes GNU Boot a bit more reproductible.
Replacing git inside the build scripts / Makefiles enable us to still
run them manually (like ./resources/packages/coreboot/download).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
With Trisquel 11 (aramo) and its guix package (guix 1.3.0) using 'guix
time-machine --commit=v1.4.0' fails like that:
$ guix time-machine --commit=v1.4.0 -- describe
guix time-machine: error: Git error: unable to parse OID - contains invalid characters
But if we use the real commit hash instead of the tag name, the same
command works fine:
$ guix time-machine --commit=8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 -- describe
guix 8e2f32c
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The resources/packages/roms/boot script already work with the "help"
argument, however most of the other scripts use --help, so for
consistency we need to add --help as well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The Intel Flash Descriptor files are supposed to be reproducible
already, so it's a good idea to add a test for that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix, with a very basic Trisquel 11 (aramo) installation
and after running resources/dependencies/trisquel-10, the GNU Boot
autogen.sh is broken due to the lack of libtool:
$ ./autogen.sh 2>&1 > temp
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: /usr/bin/autoconf --force
configure.ac:79: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
So we simply make sure that libtool is installed as part of the
dependencies.
For Arch, libtool is already in base-devel (checked with Parabola).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
In GNU Boot, at the time of writing, we want to advise users to use
the GRUB images as they don't require users to modify their
distribtions.
However before the commit aec2e2f2bcf7693a05e416f9722e15b9d1854516
("Fix bug #65663 (No support for LVM2)."), most computers using LVM2
would not boot with these images.
The bug is now fixed by this commit, however since we ship a custom
grub.cfg and that it is very important to get it right, it's a good
idea to have some sort of automated testing for it.
It uses Trisquel (instead of other FSF certified distributions) for
several reasons:
- Trisquel can be used by less technical users, and so it's important
to make sure it works as less technical users tend to have harder
times finding workaround when things break.
- It's probably the GNU/Linux distribution that most current and
potential GNU Boot users use.
- It is also maintained by a community that welcome contributions, so
if we hit some issues, we can also contribute to get it fixed (we
also verified that multiple times by contributing to it).
Note that we also welcome tests that reuse other distributions as
well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in the commit message and fixed copyright notice
Acked-by: Adrien Bourmault <neox@gnu.org>
The xz compression operation can be quite long, so it's a good idea to
show its progression.
To do that we need to produce a tarball file first as xz doesn't have
any idea of the progression when just compressing a piped stream of
data.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
This enables guix commands used in various place to use that variable.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was there from the start in the introduction of the guix command
detection in the commit 7df6d6169b
("Build bucts and patched flashrom for I945 ThinkPads with Guix.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' results in the following issue:
resources/scripts/misc/generate-configure-makefiles.sh:
line 46: ./autogen.sh: No such file or directory
make: *** [Makefile:711: release] Error 127
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following when running 'make release':
make[1]: Leaving directory '/home/gnutoo/work/projects/gnuboot/gnuboot'
cp: cannot stat 'i945-thinkpads-install-utilities/':
No such file or directory
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
