Without this fix, running shellcheck -x on
resources/packages/release/test shows the following error:
In resources/packages/release/test line 200:
missing_in_release_files=$(expr $missing_in_release_files + 1)
^--^ SC2003 (style): expr is antiquated.
Consider rewriting this using $((..)), ${} or [[ ]].
^-----------------------^ SC2086
(info): Double quote to prevent globbing and word splitting.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Tabs were mixed with spaces. This removes the tabs.
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:
[ !! ] release/roms-dbg/gnuboot-<version>_debug_x200_8mb.tar.xz
missing in ${release_files}
[ !! ] release/roms-dbg/gnuboot-<version>_debug_t400_8mb.tar.xz
missing in ${release_files}
[ !! ] release/roms-dbg/gnuboot-<version>_debug_kgpe-d16-rdimm_2mb.tar.xz
missing in ${release_files}
[ !! ] release/roms-dbg/gnuboot-<version>_debug_qemu-pc_2mb.tar.xz
missing in ${release_files}
with <version> being the GNU Boot version being built.
Also note that this was a known issue when it was introduced in the
commit b4a5a47499 ("packages: roms:
release: include debug images in the release") and I was aware of it
during the review.
The issue was not fixed at the time because we had planned a 100% free
software and/or FSDG install party where we installed GNU Boot.
And for that install party I wanted to make sure people were using a
tagged release that had the commit
860b00bf1e ("ressources/grub, website:
add LVM2 support (fix bug #65663 "No support for LVM2").").
This commit was supposed to support some configurations where there is
no /boot and the rootfs is on some LVM2 partition (but in reality this
commit contained issues and so this got fixed later on).
Since we needed to make a release of GNU Boot just before the install
party and to allow time to test the images as well (especially because
this is done by volunteers), I pushed for cutting every corner
possible to make sure that the images were released in time and to
allow time for testing. And so I argued for not fixing the tests for
the images.
At the end of the day the images were released in time but we had 0
time for doing tests (they were done later on).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was broken from the start in the commit
9cc02ddde1 ("packages: roms: Start
adding automatic tests.").
I vaguely remember having made the original tests with Trisquel 10,
and if we select LVM in Trisquel 10 both in the graphical and
netinstall installers, it ends up creating a BIOS boot partition (code
ef02), an UEFI partition (code ef00) in the case of the graphical
installer, and an LVM physical volume. I then migrated the automatic
test to Trisquel 11 before sending the patch.
But with the commit 9cc02ddde1
("packages: roms: Start adding automatic tests."), we end up with a
rootfs that has a /boot partition, so GRUB will find that and use it
to boot, without testing if GRUB can find the grub.cfg inside the LVM
partition.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was broken from the start in 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>
We already have a 'rootfs.img' argument but it is not documented in
the help.
This was broken from the start in 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>
If we do 'ls' in grub, the LVM volumes looks like that: '(lvm/[...])'
and while in certain conditions, the parenthesis are not necessary, in
the case of the code that does the regexp, it is required.
I vaguely remember having made the original tests with Trisquel 10,
and if we select LVM in Trisquel 10 both in the graphical and
netinstall installers, it ends up creating a BIOS boot partition (code
ef02), an UEFI partition (code ef00) in the case of the graphical
installer, and an LVM physical volume. I then migrated the automatic
test to Trisquel 11 before sending it.
But with the Trisquel 11 automatic test, we end up with a boot
partition, so the test will always succeed regardless of weather or
not GRUB is capable of booting from LVM partitions.
This was also tested on real hardware with Trisquel 10 installed with
the graphical installer.
The most likely explanation is that the GRUB config file being tested
also differed from the one in git, especially because both the
automatic tests and the manual tests were tested with both a
non-working GRUB configuration and a working one.
In addition using the new configuration file on a computer that was
using an old Libreboot version probably from around 2016 was made to
boot again using this new configuration file, and this looks even
more strange.
A possible explanation could be that the GRUB version is different,
though the given computer is not available for further testing, so
it's not possible to confirm that hypothesis.
Reported-by: Adrien Bourmault <neox@gnu.org>
neox: private bug report and the information on how to fix it.
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 was not caught because the dev variable is used earlier and so it
produces no error.
In addition the commit 860b00bf1e
("ressources/grub, website: add LVM2 support (fix bug #65663 "No
support for LVM2").") where this issue was introduced was not tested
with LVM partitions that are encrypted.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
While the grub configuration file format is very different from real
shell scripts, the similarities are enough to make it pass shellcheck
with very few adjustements.
The advantage of using shellcheck here is that we can still detect
some issues such as variables that are referenced but not assigned.
For instance if we add 'echo "$test"' in the beginning of the
configuration file we then have:
In resources/grub/config/grub.cfg line 24:
echo "$test"
^---^ SC2154 (warning): test is referenced but not assigned
(for output from commands, use "$(test ...)" ).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit adds a debugging configuration file for the t400_8mb image,
enabling building debugging images with UART console support and RAM
initialization debugging messages, for both corebootfb and txtmode displays.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit adds a debugging configuration file for the x200_8mb image,
enabling building debugging images with UART console support and RAM
initialization debugging messages, for both corebootfb and txtmode displays.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit adds a debugging configuration file for the D16 RDIMM 16MB image,
enabling building debugging images with UART console support and RAM
initialization debugging messages.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This commit includes debugging images (with UART console) from bin-dbg in the
release, for instance in the roms-dbg directory. Tar files contain the string
"debug" to avoid people installing a debug image by accident, which can be a
problem as it can cause longer boot times. We also include a README explaining
what are the debugging settings.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: created the README
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
When a computer does not boot at all or the result is only a deep black screen,
a very useful option can be to use a serial connector to get UART debug console
and read it, looking for any useful hint. However, enabling UART debug console
with a sufficient level of details slows down the boot process in most cases.
This commit adds the capability to build debug images, using a special
configuration file for coreboot with debug options. This is a simplistic way
that works for now, but should be improved later on.
These debug images will be generated in the bin-dbg/ directory instead
of bin/ where regular images are located.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Denis 'GNUtoo' Carikli substancially modified this file at least with the
commits:
a202dce646 (images: remove 'libgfxinit' from the image names)
80f75a334f (rename seabios_withgrub images to seabios)
6fa9af30ad (Remove images with the seabios_grubfirst main payload)
5b9dd7adba (packages: fix calls to build descriptors)
585f4d359a (coreboot/i945 Thinkpads: replace dd commands with INTEL_ADD_TOP_SWAP_BOOTBLOCK)
This commit thus adds GNUtoo's copyright notice.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Denis 'GNUtoo' Carikli substancially modified this file at least with the
commits:
f0959c9283 (packages: roms, src: release: xz: show progress)
fd9986da0b (Move releases from releases/<git describe> to releases)
This commit thus adds GNUtoo's copyright notice.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Before resources/packages/roms/release contained a mix of spaces and
tabs. This unify to spaces as there are less tabs than spaces.
This should contain no code changes.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This test is an easy way to make sure that at least QEMU's SeaBIOS
images work fine.
When designing the GRUB test my intent was mostly to test the grub.cfg
file and also enable further automatic testing to help catch issues
when improving the GRUB configuration.
However since the build system inherited from Libreboot 20220710 is
extremely fragile, and that GNU Boot also starts having the
infrastructure to build on more and more distributions with different
compiler versions (we now supports 2 Trisquel version and 1 PureOS
version), with setups variations (work is ongoing to add support for
building in chroots), it might be a good thing to check if SeaBIOS
works.
This would also catch bugs like bug #66487 ("RC4: All SeaBIOS images
are broken") [1] where the SeaBIOS payload was missing in all images,
however it would not catch situations where SeaBIOS is present in QEMU
images but missing in other images, so different tests must be done
for that situation. In addition it would be costly just to boot a VM
to check for missing files.
[1] https://savannah.gnu.org/bugs/?66487
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:
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>
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>
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>
