Without that fix, 'sudo resources/dependencies/pureos-10' results in
the following issue:
Finished [=========================]
Command failed: Expected package name, actually got file.
Try using 'pkcon install-local libtool' instead.
And with this patch the command above works fine:
Finished [=========================]
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 PureOS 10
(byzantium):
Submodule path 'util/nvidia/cbootimage': checked out
'65a6d94dd5f442578551e0a81ecbe5235e673fd4'
Committer identity unknown
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got '[...]')
ERROR: download/coreboot: Unable to apply patch
'../../resources/coreboot/default/patches/0001-apple-macbook21-Set-default-VRAM-to-64MiB-instead-of.patch'
for board 'default' on tree 'default'Committer identity unknown
This is because PureOS 10 (byzantium) has git 2.30.2 and in PureOS,
and since 'man git' doesn't show GIT_CONFIG_GLOBAL nor
GIT_CONFIG_SYSTEM, git 2.30.2 doesn't understand these variables.
Since git already has -c option, we use that instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' fails with the following error:
[...]
ROM image release archives available at release/roms/
set -o pipefail ; ./build release website | tee -a make-1732208182.log
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
[...]
checking for dot... no
configure: error: dot was not found in PATH ([...])
make: *** [Makefile:710: release] Error 1
This happens because during releases we also ship a tarball of the
website, and the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.")
started using dot without also adding the graphviz dependency in the
dependencies for building releases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' fails with the following error:
ROM image release archives available at release/roms/
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for awk... awk
[...]
checking for dot... no
This happens because during releases we also ship a tarball of the
website, and the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.")
started using dot without also adding the graphviz dependency in the
dependencies for building releases.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, Trisquel fails with the following error:
Resolving [=========================]
Package not found: ttf-unifont
Command failed: This tool could not find any available package:
No packages were found
And when installing ttf-uifont with apt, we get this error:
# apt install ttf-unifont
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package ttf-unifont is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
fonts-unifont
E: Package 'ttf-unifont' has no installation candidate
The ttf-unifont dependency was introduced in Libreboot when it didn't
use git yet. It can be found in Libreboot's 5th release, second
revision[1] in libreboot_src/builddeb.
[1]https://rsync.libreboot.org/oldstable/20140622/libreboot_src.tar.gz
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix running the script results in the following error:
# ./resources/dependencies/trisquel
+ ./resources/dependencies/trisquel
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
packagekit-tools is already the newest version (1.2.5-2ubuntu2+11.0trisquel1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
awk: cmd. line:1: {print
awk: cmd. line:1: ^ unexpected newline or end of string
The issue was introduced in the commit
94118b896a ("dependencies: Trisquel 10:
Fix script for non-english locales.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
While the FAM12H SMU firmware is under a free license, as the
F12NbSmuFirmware.h contains the following copyright header:
* Copyright (c) 2011, Advanced Micro Devices, Inc.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of Advanced Micro Devices, Inc. nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
we also lack the corresponding source code.
Since AMD Family 12H was removed upstream, and that GNU Boot doesn't
support any computers with this CPU family, it's easier to remove the
file than to try to fix the issue in some other way.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The file contains the following copyright header:
// This file contains an 'Intel Peripheral Driver' and is
// licensed for Intel CPUs and chipsets under the terms of your
// license agreement with Intel or your vendor. [...]
[...]
// Copyright (c) 2010-2013 Intel Corporation. All rights reserved
// This software and associated documentation (if any) is furnished
// under a license and may only be used or copied in accordance
// with the terms of the license. Except as permitted by such
// license, no part of this software or documentation may be
// reproduced, stored in a retrieval system, or transmitted in any
// form or by any means without the express written consent of
// Intel Corporation.
While there is also many contradicting statements like this one in
src/soc/intel/fsp_baytrail/Kconfig:
## This file is part of the coreboot project.
##
## Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
## Copyright (C) 2013-2014 Sage Electronic Engineering, LLC.
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; version 2 of the License.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
The baytrail FSP was added in Coreboot by the commit
954f3882f1ea8512de9a5a6a38569c36bffae405 ("Add the Bay Trail FSP
include & srx directories") by Martin Roth, proably not on behalf on
Intel.
The commit also contains an email address from Martin Roth with the
se-eng.com domain (from Sage Electronic Engineering) and doesn't
contain any email address related to Intel. This increase the
probability that Intel wasn't involved in adding the Bay Trail FSP to
Coreboot.
Because of the (strong) doubts, the fact that the Bay Trail FSP was
also removed upstream and that GNU Boot doesn't support computers with
Intel Bay Trail, it's easier to just remove the nonfree software.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
This was introduced in ARM trusted firmware in the commit
c76631c52b0b1550ff182c177555485700274314 ("rockchip: include hdcp.bin
and declare hdcp key decryption handler").
The hdcp.bin file contains code as it is included inside one of the
arm-trusted-firmware drivers with the following code:
__asm__(
".pushsection .text.hdcp_handler, \"ax\", %progbits\n"
".global hdcp_handler\n"
".balign 4\n"
"hdcp_handler:\n"
".incbin \"" __XSTRING(HDCPFW) "\"\n"
".type hdcp_handler, %function\n"
".size hdcp_handler, .- hdcp_handler\n"
".popsection\n"
);
The same file that contains the above code has the following copyright header:
* Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
This conflicts with the message of the commit mentioned above:
For some reason, HDCP key decrytion can't open source in ATF, so we
build it as hdcp.bin. Besides declare the handler for decrypting.
and we also have missing corresponding source code.
Because of the lack of source code, and the fact that GNU Boot doesn't
support computers with RK3399 yet, it's easier to remove the hdcp.bin
firmware than to pursue other ways to fix the issue.
Reported-by: Leah Rowe <info@minifree.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed "file file" typo in commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
This was broken by the commit 6b4b553d49
("website-build: targets: rename targets to use build, serve and
publish.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
For some reasons I used MediaWiki syntax for that link instead of the
CommonMark syntax.
The broken link was introduced by the commit
88d3ad4765 ("site: fix the GNU Boot
build instructions.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The commit 768fde6f2d ("website: Remove
news generation.") was supposed to produce a web page at
https://www.gnu.org/software/gnuboot/web/news.html.
This didn't work because due to a combination of the Apache rules
deployed on the web server and the fact that we couldn't delete files.
After discussing with the FSF sysadmins, they now fixed the problem,
so we can now use --delete with rsync and this makes the news page
appear.
It's also possible to get the Apache rules being used under a free
license, so to avoid this kind of situation again, so in the future we
should get these rules and replace the test with lighttpd with a test
that uses Apache and these rules instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The GNU Coding Standards has the following in the chapter "4.8.1
--version"[1]:
The program’s name should be a constant string; don’t compute it
from argv[0]. The idea is to state the standard or canonical name
for the program, not its file name. There are other ways to find
out the precise file name where a command is found in PATH.
[1]https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion
This fixes that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The page name aren't directly meaningful. In contrib.md for instance I
would expect to find how to contribute. In git.md instead I would
expect to find how to download GNU Boot but not how to contribute.
Since the authors page isn't meaningful anymore for GNU Boot as it has
different priorities than Libreboot at the time where it was fully
free, and also because GNU Boot also wants to put forward smaller
contributions, especially contributions that aren't recorded in git.
As the GNU Boot project doesn't have the same community or dynamics
than the Libreboot project had, the gaps it has are different. So we
also try to put forward contributions that fills these gaps.
However since this page is very important historically, so we need to
keep it not to forget about it. So to fix that we added GNU Boot's
point of view and moved it in the history section.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: updated link in pages/template.include
Acked-by: Adrien Bourmault <neox@gnu.org>
As the page is quite similar to the NetBSD and OpenBSD pages,
it should contain similar changes.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
As the page is quite similar to the OpenBSD page, it should contain
similar changes.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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 if mkdir is is present when using guix to build the website.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed the commit message
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.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>
Acked-by: Adrien Bourmault <neox@gnu.org>
My main key fingerprint was used inside .guix-authorizations, but all
my commits are signed with a subkey and 'guix git authenticate' only
works if we put my subkey inside .guix-authorizations.
I also remember that at some point I had verified that 'guix git
authenticate' worked for my key, so I probably lost the changes that
made it work (using my subkey) at some point while moving to another
repository to do tests that don't interfere with my main work on
GNU Boot.
This was broken from the start in the commit
bf2b91df54aa71ecbfab891d32000ad2d6af6093("Add .guix-authorizations
file for "guix git authenticate"").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.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>
