Without that fix we have the following issue when building a release:
makeinfo \
--pdf \
--no-split \
-o pages/manual/gnuboot.pdf \
../manual/gnuboot.texi
This is pdfTeX, Version 3.141592653-2.6-1.40.22 [...]
[...]
Writing index file gnuboot.cp
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
./../manual/gnuboot.texi:122: epsf.tex not found, images will be ignored.
@image ...f.tex not found, images will be ignored}
[...]
./../manual/gnuboot.texi:122: Emergency stop.
@image ...f.tex not found, images will be ignored}
@global @warnednoepsftrue ...
l.122 mainboard.}
./../manual/gnuboot.texi:122: ==> Fatal error occurred, no output PDF file pro
duced!
[...]
./../manual/gnuboot.texi:122: ==> Fatal error occurred, no output PDF file pro
duced!
Transcript written on gnuboot.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [Makefile:767: pages/manual/gnuboot.pdf] Error 1
The epsf.tex can be found in the texlive-plain-generic package in
/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex.
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue when building a release:
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 tex... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue when building a release:
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 makeinfo... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following issue when building a release:
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 gm... no
This issue was introduced by the commit
08b9e449e9 ("Add a minimal GNU Boot
manual.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The goal is to minimize the difference with the
resources/dependencies/trisquel script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This makes sure that there is only one apt command that is called.
Since this change results in the some package names (like 'git') being
passed twice to apt install, this situation was tested with 'apt
install sl sl' on Trisquel 10 (nabia), Trisquel 11 (aramo) and also
PureOS 10 (byzantium) in case the trisquel and pureos dependencies are
merged later on, and it worked fine.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This package is unused since the commit
e50f311c45 ("dependencies: pureos: go
back to apt (instead of packagekit).").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This package is unused since the commit
3f85c3ff22 ("dependencies: trisquel: go
back to apt (instead of packagekit).").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The history if the pureos-10 file is shared with the one of the
trisquel-10 file until the ubuntu2004 file was forked into the debian
file in the commit 8a79f7b163 ("Fix
https://notabug.org/libreboot/lbmk/issues/59").
Because of that, like the trisquel file, the pureos-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>
neox: fixed own email address
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
A bug has been introduced in
a202dce646
("images: remove 'libgfxinit' from the image names.")
where we simplified images names without taking care of renaming the filename
used as the SeaBIOS build target.
This error was visible during the generation of the images:
Creating new ROM image: bin/[...]/seabios_kgpe-d16-[...].rom
payload/seabios/seabios.elf: No such file or directory
E: Could not load file 'payload/seabios/seabios.elf'.
E: Failed while operating on 'COREBOOT' region!
E: The image will be left unmodified.
The resulting image was then missing a payload entry and was then
non-functional (people would then just get a black screen without any OS loaded
from the disk).
GNUtoo confirmed by bisecting that the commit cited above was indeed responsible
of the bug and also that the error message above was specific to this issue.
This commit fixes this bug by setting variables to hold the actual payload
location (making future changes easier), in the relevant files.
Tested-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: Added "Created new ROM image" log, made it fit,
improved source code comment.
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit removes the generation of the unused seabios_vgarom.elf image.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: Removed speculations from the commit message
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The goal of this script is similar to Linux's checkpatch.pl: it is
meant to check patch before sending them.
Right now it only tests if a signed-off-by is missing, and if the
commit information (commit message, author, date, etc but not the
diff) is too big as a workaround to the bug #66268[1], but over time
more checks can be added.
The report of the bug #66268[1] mention that what tend to trigger the
issue is commits "with a large (4kB) commit message".
[1]https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66268
So we want to avoid such commits to avoid breaking "guix git
authenticate" in the future.
To do that, checkpatch.scm reports an error if the size of the patch
from the beginning of the patch file until the point where the diff
starts is less than 2500 Bytes.
A lower threshold has been chosen as the commit object size can be
bigger than the patch file without the diff, as there are at least
signatures inside the commit objects.
The last commit GNUtoo signed at the time of writing is the commit
83f955870a ("website/docs/build: mark
the Trisquel bug as solved and clarify the Guix one") and this is done
with an RSA GPG key of 4096 bits and in this case the signature is
about 855 bytes. This was calculated with 'git cat-file -p 83f95587'.
As GNU Boot is looking for contributions, including contributions by
less technical users, we do not require its use by people sending
patches, however it is still a good idea to require its use by the GNU
Boot maintainers as we want to spot the most important issues that
cannot be fixed later on.
Thanks to neox for the research and the calculation on the git commit
signature size.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
If we run the following commands:
$ git clone https://git.savannah.gnu.org/git/gnuboot.git
$ cd gnuboot
$ git authenticate bf2b91df54 \
"E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
-k origin/keyring
We then end with the following issue:
Authenticating commits bf2b91d to c85fbae (47 new commits)...
guix git: error: commit c85fbae78f
is not a descendant of introductory commit
bf2b91df54
But first the bf2b91df54 commit ("Add
.guix-authorizations file for "guix git authenticate".") is the proper
introductory commit and everything else is fine too (it is signed by
the right key, the signature matches, all the history between bf2b91d
and c85fbae is linear and all the signatures also match fine.
The issue is that the introductory commit size is > 4KB and so this
trigger a bug in Guix and/or guile-git[1] where guix uses eq? to
compare commits and two commits are not equals with eq? if their hash
is the same but that they are > 4KB.
[1]https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66268
The workaround is then to substitute the introductory commit with the
one right after it and also to make sure that any commit in between
that introductory commit substitute and HEAD have a commit message and
or commit data and/or patch that is less than 4KB.
This issue also needs to be fixed upstream in Guix and/or guile-git
but we also need to workaround now as the fix could take time to reach
users as first the problem is not trivial to fix and even once fixed
in Guix, it would be best not to require to have to run git pull
(which can take a huge amount of time, probably hours) just to
authenticate the GNU Boot git repository.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The first version of the 3f9b38739f
patch ("manual: Add section about building GNU Boot.)" and the GNU
Boot 0.1 RC4 announce have the following guix git authenticate
command:
$ guix git authenticate $(git rev-parse HEAD) \
"E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
-k origin/keyring
This is wrong as HEAD is not an introductory commit and it can only
work if it is signed by the "E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3
6871 16F6" key which defeats many of the important features of guix
git authenticate like the ability to delegate trust to multiple
people.
This command was probably used by me during early tests as I didn't
have neox's key to sign commit and that my key was invalid (see the
commit dde4223088 "Fix
.guix-authorizations for Denis 'GNUtoo' Carikli." for more details)
and it was probably kept as it appeared to work.
Since the expected way to use guix git authenticate is with an
introductory commit, the output of the command is then predictable and
it should be exactly the same than the one described in the GNU Boot
manual.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: - fixed a typo
- found duplicated see in "(see the @pxref{,,,guix,GNU Guix
reference manual} for more details).", "See the
@pxref{Security features}"
- fixed duplicated see in "they are also documented in the
@pxref{,,,grub,GNU GRUB manual} as well", "and @pxref{Building
GNU Boot from [...]}"
Acked-by: Adrien Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: found/fixed many duplicate see as pxref adds a "see [...]":
- fixed "or the @pxref{Installation,,,guix,GNU Guix[...]}"
- found "See @pxref{Invoking guix git authenticate,[...]}",
"-See also @pxref{Authenticating [...]}", "See the
@pxref{Supported", "See the @pxref{Installing or [...]}
to understand".
Acked-by: Adrien Bourmault <neox@gnu.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: - fixed duplicate see with @pxref in "(@ref{GNU Boot images} for
more details)" and "the @pxref{GNU Boot images types} subsection.",
"will be documented in the @ref{GNU Boot images} section below"
- found "See the @pxref{boot software} section to understand",
"described in the previous subsection (@pxref{GNU resolution graphics",
"described in the previous subsection (@pxref{GNU Boot images types}).",
"(see @pxref{boot software} for more details)."
Acked-by: Adrien Bourmault <neox@gnu.org>
This section explains what hardware components are compatible with GNU
Boot or not.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: found "See @pxref{Supported computer parts and peripherals} for
more details".
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In the GNU Boot 0.1 RC3 release, we already have images for various
computers, so we use that as a base for the list of compatible
computers.
For computers supported by the same images like the ThinkPad X200,
X200s and X200 Tablet, they have different markings on the computer so
it's a good idea to treat them as separate computer models.
Some users might also be used to projects (like Replicant) requiring
very specific computer models, so following the trend probably helps
users avoiding hardware not compatible with distributions they want to
use.
In addition, the installation instructions will also differ a lot
between a ThinkPad X200 whose flash chip is easily accessible and the
ThinkPad X200S which has a WSON-8 flash chip that doesn't have any
clip available for it.
We also list computers that have the RYF certification as separate
computers as it will simplify things later on: so far we're aware that
Minifree Ltd changed the flash chip size on many of the computers they
sold and that that Technoetical provided modified GNU Boot images with
the same MAC Address that is written down on some stickers on the
bottom of the computer.
Because of that installation instructions might differ between a
ThinkPad X200 and a Technoetical X200.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
So far the manual only tell that GNU Boot is a boot software
distribution and it explains what it means.
It didn't tell what it means for GNU Boot to be fully free.
In addition, other 100% free software boot distributions also exists,
so we also need to explain why we need GNU Boot to exist.
More details about the GPU issue will be added later on.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Currently GNU Boot has no manual, and it needs one to organize better
the information it provides to users and/or contributors.
Since we need to start somewhere, beside adding the manual license, we
describe a bit what the GNU Boot project is, and also ask for help for
completing the manual.
The GFDL 1.3 comes from the gnulib source code at the commit
d64d66cc4897d605f543257dcd038524a0a55215 ("autoupdate").
The beginning and the end of the document are also very similar to the
GNU Hello manual from the commit
24225d705684322f482135e8a2d679485fce0811 ("maint: remove the obsolete
gettext module") as they were copied and modified from that.
The 'dircategory Kernel' was chosen to be the same than GRUB, so they
both appear in the same group in the Emacs info reader ('info'
command in Emacs).
As for the "Overview" of GNU Boot it also contains background
information that will be needed later on and that needs to be
introduced right from the start:
- If people reading the manual do not understand what a boot software
is, all the rest will be too complicated to explain.
- We also need to explain where GNU Boot is physically located on the
computer from the start as we plan not to use the 'ROM' terminology
as it's confusing: ROM means read-only-memory, and so there is no
point of providing GNU Boot ROM images if the nonfree boot software
can't be replaced.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
While the website code is separate from the rest, the same rationale
than in the commit ada459875c ("Use a
released guix revision globally.") applies for using Guix 1.4.0
(having access to the Guix manual for the right Guix version, not
needing to run guix pull in some cases).
However if we do that we run into an issue where guix fails to find a
substitute for pandoc for Guix 1.4.0 for i686-linux. This results in
Guix bootstraping ghc and then building pandoc and its dependencies.
The ghc bootstrap is extremely long (many hours / few days on a
ThinkPad X200, and it takes more than one night inside a VM with 8
cores and 16 GiB of RAM that runs on a KGPE-D16). Not running the ghc
tests also doesn't speed up the build enough to be practical.
However while the pandoc substitutes are not available on
ci.guix.gnu.org, they are available on bordeaux.guix.gnu.org which is
also in the default substitute servers.
So the workaround is to tell users to make sure to authorize
bordeaux.guix.gnu.org and then to force its use if it is authorized.
This still enable users to not use substitute (for security reasons)
if they want to.
To do the detection we use guix repl as the guix command is supposed
to be available and it also has access to Guix's guile modules.
In addition, running ./autogen.sh && ./configure && make check results
in the following error without this commit:
guix time-machine --commit= -- shell --system=i686-linux --container
--network --emulate-fhs --share=`realpath ../` bash coreutils
findutils git grep nss-certs pandoc sed -- ./build.sh
guix time-machine: error: Git error: unable to parse OID - too short
make: *** [Makefile:696: build] Error 1
This was broken by the commit 07e9cbd12c99e39d0bc0b8449423bd914bb92b10
("website: properly handle the dot dependency.").
However if we bisect it, we instead find that the commit
f8874d77803426cc01305e7f895284dbe7caae00 ("website: remove
history/git-history.jpg") broke 'make check'.
This is because history/git-history.jpg is supposed to be generated
but it was included in git in the commit
388c0ef3d0 ("website: add history page
of the GNU Boot git repositories.") and so once we starts generating
the file again, 'make check' breaks.
So we modified the commit 388c0ef3d0
("website: add history page of the GNU Boot git repositories.") to not
add history/git-history.jpg to properly bisect it.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in message and diff
Acked-by: Adrien Bourmault <neox@gnu.org>
This change has several goals:
- It reduces code duplication. This also makes it easier to check that
all the commands using Guix use the same revision and system, which
are supposed to be common to the use of Guix. Unifying the Guix
revision between the website and the rest of GNU Boot will be done
later on.
- It reduce the size of the commands, which also help reduces the
indentation and/or increase readability.
Guix users typically run "guix shell [arguments] -- [command]", and
here we abstract away some GNU Boot specific parts like using Guix
1.4.0 and i686-linux, so it makes sense to abstract them.
The --container argument is also specific to GNU Boot as it avoids
potentially leaks between the host and the container (which we want to
avoid for increased reproducibility across different host
distributions), however people used to guix shell will typically
expect to select between --container or not.
In order to more easily enforce --container and make it clear that we
use it, we named the variable GUIX_SHELL_CONTAINER.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
In the commit 0f74569af0 ("dependencies:
switch arch, debian, fedora35, ubuntu2004 to packagekit"), the
Trisquel script was converted to use packagekit to then be able to
unify the dependency management between several distributions.
However GNU Boot doesn't build directly on Parabola, and the build is
completely untested on Fedora and Void, so the other scripts are less
important. In contrast building GNU Boot is regularely tested on
PureOS 10 (byzantium) and Trisquel 11 (aramo).
Since the Guix debootstrap package can be used to safely create
chroots of PureOS and Trisquel, it may be possible to use that to
build GNU Boot on any distributions.
However packagekit requires a daemon to work:
# pkcon install guix
Failed to contact PackageKit: Could not connect:
No such file or directory
And in turn the /usr/libexec/packagekitd daemon requires dbus as shown
by the /lib/systemd/system/packagekit.service file:
[Unit]
Description=PackageKit Daemon
# PK doesn't know how to do anything on ostree-managed systems;
# currently the design is to have dedicated daemons like
# eos-updater and rpm-ostree, and gnome-software talks to those.
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target
[Service]
Type=dbus
BusName=org.freedesktop.PackageKit
User=root
ExecStart=/usr/libexec/packagekitd
So reverting back to apt seems a safe choice for now.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
In the commit 0f74569af0 ("dependencies:
switch arch, debian, fedora35, ubuntu2004 to packagekit"), the
Trisquel script was converted to use packagekit to then be able to
unify the dependency management between several distributions.
However GNU Boot doesn't build directly on Parabola, and the build is
completely untested on Fedora and Void, so the other scripts are less
important. In contrast building GNU Boot is regularely tested on
PureOS 10 (byzantium) and Trisquel 11 (aramo).
Since the Guix debootstrap package can be used to safely create
chroots of PureOS and Trisquel, it may be possible to use that to
build GNU Boot on any distributions.
However packagekit requires a daemon to work:
# pkcon install guix
Failed to contact PackageKit: Could not connect:
No such file or directory
And in turn the /usr/libexec/packagekitd daemon requires dbus as shown
by the /lib/systemd/system/packagekit.service file:
[Unit]
Description=PackageKit Daemon
# PK doesn't know how to do anything on ostree-managed systems;
# currently the design is to have dedicated daemons like
# eos-updater and rpm-ostree, and gnome-software talks to those.
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target
[Service]
Type=dbus
BusName=org.freedesktop.PackageKit
User=root
ExecStart=/usr/libexec/packagekitd
So reverting back to apt seems a safe choice for now.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
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>
