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>
The list of files retrieved by producing files with 'cbfstool
<path/to/image> print' and greping inside that. The image files for
that were the ones generated by the official build of GNU Boot 0.1
RC4.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.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>
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>
