Note that the text is a collective work by many people and that I only
have written an extremely small part of it.
Signed-off-by: Adrien Bourmault <neox@a-lec.org>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@a-lec.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
For some reasons pandoc on Guix fails at guix commit
5312d798ac36a72d8a977325a7c6ff7647be670a ("gnu:
go-golang-zx2c4-com-wireguard: Update to 0.0.20211016.") and produce
the following error:
build of /gnu/store/<hash>-ghc-basement-0.0.15.drv failed
View build log at '/var/log/guix/drvs/h7/<hash>-ghc-basement-0.0.15.drv.gz'.
Since I use i686 and that we need to publish the website now, we
workaround the build failure by using a known working commit hash.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
As adding organization support to Source Hut is still a
work in progress, we will use this workaround in the
meantime.
Sourceware also uses a similar workaround.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This makes sure that we host all the source code to reproduce that
website and that we build it with that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The token will need to be added in id_oauth2_bearer.
It's not very safe to pass the content to a command as any user on the
system on which it is run will be able to get the token, though I
didn't find a command line argument in curl to pass it a file path
instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Sourcehut has a way to setup a static website by uploading a tarball
of the content[1].
Even if we don't end up using Sourcehut, generating a tarball of the
website enables more easy deployments.
Note that we didn't touch to the website code yet, so it still uses
the old URLs, the old image locations, etc.
After creating a token (documentation[1]), the website can then be
uploaded with the following command:
curl \
--oauth2-bearer "<token>" \
-Fcontent=@website.tar.gz \
https://pages.sr.ht/publish/gnutoo.srht.site
[1]https://srht.site/quickstart
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
this is cherry-picked from osbmk. the cherry-pick was
performed by i, leah rowe. this is adapted from shmalebx's
patch there, in osboot
specifically, these patches from osbmk are being imported:
327a39ef058d5385bf8c1a1b09bac8db6a51b016
5139ad4be4df1835ce154f39161eef4f7c31ee1a
with this change, it's unlikely we'll hit errors again. previously,
some projects used were calling "python" which in context was
python3, but on some setups, the user only has python2 and python3
but no symlink for "python" (which if exists, we assumed linked to
python3)
now it's unambiguous. docs/build/ can probably be updated now, as
a result of this change, to remove the advice about that
I was running into a race condition when rebuilding seabios with a high cpu count,
resulting in failure with this error message:
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
Performing the silentoldconfig step before the full make step seems to resolve the failure.
When running ./download all, we have the following error:
resources/scripts/download/coreboot: Line 52: $1 is not set.
The ./download all command was broken by the following commit:
2bb805e2e0 (download: Add --help in the
individual download scripts).
Reported-by: madbehaviorus[m] on #libreboot on liberachat
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Without that fix we have the following warning during the download:
Cloning into 'u-boot/u-boot'...
warning: redirecting to https://source.denx.de/u-boot/u-boot.git/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
the generated script to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
that blob to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The tar options come from the tutorial to remove archives metadata at
reproducible-builds.org[1].
[1]https://reproducible-builds.org/docs/archives/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This doesn't change the existing usage of the scripts:
- For the Coreboot script, before this change, all arguments that were
passed were considered as board to download the Coreboot source code
for.
Here we added the '--help' and '--list-boards' arguments, so it
should not be an issue as it is extremely unlikely that a board
would be called '--help' or '--list-boards'.
- All the other scripts don't use any arguments so passing --help
should not conflict with the existing usage.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
If the script is named u-boot-stable-src-release and that users see an
u-boot-libre tarball they will not make the link between both unless
we rename the script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Many people using FSDG compliant distributions or wanting to use one
are already familiar with linux-libre. This change renames the
resulting tarball to u-boot-libre to make it easier for people to
understand the goal of this tarball.
In addition we also rename the version from v2021.07 (which is the git
tag corresponding to the release) to 2021.07 as u-boot upstream
tarballs use that.
The revision wasn't bumped as we didn't have any releases of
u-boot-libre yet.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Once the tarball are released, it will enable distributions to use
these tarballs to produce deblobbed u-boot packages.
Note that the produced tarball is not reproducible yet. Because of
that it has to be trusted.
During a release, it's a good idea to sign the uncompressed tarball as
the various compression formats and associated tools make different
tradeoffs.
For instance with xz, xz -9e tends to compress really well with the
the most used xz[1] implementation, and most GNU/Linux users probably
already have it installed, but and the drawbacks is that the format is
very fragile[2].
The lzip format is more suited for long term archiving but its most
packaged implementation[3] is less likely to be already installed by
users than more well known formats like xz, bzip2 or gzip.
Being able to add more compression formats after the release is also
useful, for instance to accommodate different build systems or use
cases (like being able to build u-boot with less dependencies in
distributions like Guix, or building u-boot directly on devices which
don't have enough RAM for xz for instance).
[1]https://tukaani.org/xz/
[2]https://www.nongnu.org/lzip/xz_inadequate.html
[3]https://www.nongnu.org/lzip/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Many people
