The "4.7 Mcopy" section inside the mtools info manual explains that
mcopy's '-m' argument "Preserve the file modification time.".
So in the commit 9cc02ddde1 ("packages:
roms: Start adding automatic tests."), I vaguely recall having used it
to workaround some reproducibility issues.
Guix 1.4.0 uses mtools 4.0.42. So after retrieving the source with
'guix time-machine --commit=v1.4.0 -- build --system=i686-linux
--source mtools' we have that in the writeit function in mcopy.c (with
arg->preserveTime being set by -m):
/* preserve mod time? */
if (arg->preserveTime)
now = date;
else
getTimeNow(&now);
And date is set by the following in mtools 4.0.42:
if (Source->Class->get_data(Source, &date, &filesize,
&type, 0) < 0 ){
fprintf(stderr, "Can't stat source file\n");
return -1;
}
Since Guix is supposed to make images reproducible somehow, and that
mtools isn't patched by Guix to do that, and that it takes the time
from the source file, I used '-m'.
Since I was confident enough that gnuboot-trisquel-preseed.img was
reproducible, in the commit 9cc02ddde1
("packages: roms: Start adding automatic tests."), I also added the
checksum and checked it at build time to make sure the image is really
reproducible.
But when building this image again few days ago the checksum was
different. So I used the Guix diffoscope package to investigate the
issue.
Note that at the time of writing, you either need to use Guix's
diffoscope or to disable guestfs support in diffoscope for it to work,
otherwise diffoscope 277-1 (the version in the Parabola at the time of
writing) produce a python error probably because the partition table
size is 0, and it contains a FAT12 filesystem according to fdisk, but
then the FAT12 filesystem contained within also contains that
partition table. See the upstream bugreport at
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/390
for more details.
Here the preseed.img.old file corresponds to the checksum in the
commit 9cc02ddde1 ("packages: roms:
Start adding automatic tests."), and preseed.img.new to the one I got
by building again few days ago:
$ sha512sum preseed.img.old preseed.img.new
f12a4a941afc9e24288481ed1b44fbfedf52d706e9e8aa01cfb26bf5ccd54ca52afe9ef5497faf2966ba730c1200d8b8691ebb87e6a75cd8966e0edd49bcb3c0 preseed.img.old
5613d9a5cdd8847d5a688d56c77b8cf8881baa5eef7f373bb05a5ec601e383204e6a57b399d3de913c29386b18e7e3903c9511037922204744e3234cadc8671b preseed.img.new
And by using diffoscope we have:
$ diffoscope preseed.img.old preseed.img.new
--- preseed.img.old
+++ preseed.img.new
│┄ Format-specific differences are supported for ext2/ext3/ext4/btrfs/fat filesystems but no file-specific differences were detected; falling back to a binary diff. file(1) reports: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 2048 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 2, sectors/track 16, serial number 0x1234abcd, label: "MEDIA ", FAT (12 bit)
│┄ Installing the 'guestfs' Python module may produce a better output.
@@ -157,23 +157,23 @@
000009c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000009f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000a00: 4d45 4449 4120 2020 2020 2008 0000 5a4b MEDIA ...ZK
00000a10: 6e46 6e46 0000 5a4b 6e46 0000 0000 0000 nFnF..ZKnF......
00000a20: 5052 4553 4545 4420 4346 4720 1800 0000 PRESEED CFG ....
-00000a30: 21ec 21ec 0000 0000 21ec 0200 f50d 0000 !.!.....!.......
+00000a30: 21ec 2859 0000 0000 21ec 0200 f50d 0000 !.(Y....!.......
00000a40: 4365 0000 00ff ffff ffff ff0f 0000 ffff Ce..............
00000a50: ffff ffff ffff ffff ffff 0000 ffff ffff ................
00000a60: 0272 002d 0062 006f 006f 000f 0000 7400 .r.-.b.o.o....t.
00000a70: 2e00 7300 6500 7200 7600 0000 6900 6300 ..s.e.r.v...i.c.
00000a80: 0173 0068 0075 0074 0064 000f 0000 6f00 .s.h.u.t.d....o.
00000a90: 7700 6e00 2d00 6100 6600 0000 7400 6500 w.n.-.a.f...t.e.
00000aa0: 5348 5554 444f 7e31 5345 5220 0000 0000 SHUTDO~1SER ....
-00000ab0: 21ec 21ec 0000 0000 21ec 0400 3002 0000 !.!.....!...0...
+00000ab0: 21ec 2859 0000 0000 21ec 0400 3002 0000 !.(Y....!...0...
00000ac0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ad0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000ae0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000af0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b00: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b10: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000b20: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Here it really look like a timestamp, and since mdir gave no
difference between the 2 files inside the 2 images, I patched mdir
with the following patch:
@@ -438,6 +438,18 @@ static int list_file(direntry_t *entry, MainParam_t *mp UNUSEDP)
if(*mdir_longname)
printf(" %s", mdir_longname);
printf("\n");
+
+ printf("-> ctime_ms: 0x%hhx\n", entry->dir.ctime_ms);
+ printf("-> ctime[0]: 0x%hhx\n", entry->dir.ctime[0]);
+ printf("-> ctime[1]: 0x%hhx\n", entry->dir.ctime[1]);
+ printf("-> cdate[0]: 0x%hhx\n", entry->dir.cdate[0]);
+ printf("-> cdate[1]: 0x%hhx\n", entry->dir.cdate[1]);
+ printf("-> adate[0]: 0x%hhx\n", entry->dir.adate[0]);
+ printf("-> adate[1]: 0x%hhx\n", entry->dir.adate[1]);
+ printf("-> time[0]: 0x%hhx\n", entry->dir.time[0]);
+ printf("-> time[1]: 0x%hhx\n", entry->dir.time[1]);
+ printf("-> date[0]: 0x%hhx\n", entry->dir.date[0]);
+ printf("-> date[1]: 0x%hhx\n", entry->dir.date[1]);
} else {
char tmp[4*MAX_VNAMELEN+1];
And this then gives the following diff:
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
@@ -20,8 +20,8 @@
-> ctime[1]: 0x0
-> cdate[0]: 0x21
-> cdate[1]: 0xec
--> adate[0]: 0x21
--> adate[1]: 0xec
+-> adate[0]: 0x28
+-> adate[1]: 0x59
-> time[0]: 0x0
-> time[1]: 0x0
-> date[0]: 0x21
This means that the access date difers. This also explains why it was
not spoted during the creation of the commit
9cc02ddde1 ("packages: roms: Start
adding automatic tests.") as tests were done at the same date.
So this time I created a build VM by adding the following service to
my Guix system configuration (I also had to remove hacks I had that
set the kvm group id to the same ID used by Trisquel run 'guix system
reconfigure' and rebooted):
(service virtual-build-machine-service-type
(virtual-build-machine
(cpu "host")
(cpu-count 2)
(auto-start? #f)))
This created a VM whose clock is set to 'a few years ago' according to
the Guix manual[1].
[1]https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#Virtual-Build-Machines
I then ran built the image as usual:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img
--without-tests=gnuboot-trisquel-preseed.img
I then copied the resulting image, started the build VM with 'herd
start build-vm', deleted the old image from the store (with 'guix gc
-D') and then re-built it (it used the VM to offload the build as
shown in the build logs).
And now both resulting files are now the same despite being built on a
different date.
See also the following blog post for more context into use cases for
this build VM[2]:
[2]https://hpc.guix.info/blog/2024/03/adventures-on-the-quest-for-long-term-reproducible-deployment/
Bug: https://savannah.gnu.org/bugs/?66224
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The image resulting from the gnuboot-trisquel-preseed.img package is
checked against checksums inside the 'check function of this package.
If for some reasons we want to update the checksums, an easy way to do
it is to build the package but not run the 'check function and do the
checksum on the resulting file. The Guix 1.4.0 manual explains how to
not run 'check with the "--without-tests=package" option in the
"10.1.2 Package Transformation Options" section.
However if we attempt that with the following command, the
without-tests has no impact at all:
$ guix time-machine --commit=v1.4.0 -- build -L resources/guix/ \
gnuboot-trisquel-preseed.img \
--without-tests=gnuboot-trisquel-preseed.img
This changes makes the above command work as expected.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The test data consists mostly in nonfree boot firmware images. The
images contain nonfree binaries like for instance microcode updates
without complete and corresponding source code.
As more and more boot firmware images are added over time it's a good
idea to just remove everything in that directory to make sure that we
don't ship nonfree software from that directory again, while also
lowering the maintenance costs.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit fixes an error encountered on Trisquel 11 while trying to
build the fam15h coreboot crossgcc 8.3.0:
In file included from /usr/include/signal.h:328,
from /usr/include/x86_64-linux-gnu/sys/param.h:28,
from ../../gcc-8.3.0/gcc/system.h:298,
from ../../gcc-8.3.0/gcc/ada/init.c:65:
../../gcc-8.3.0/gcc/ada/init.c:575:18: error: missing binary operator before token "("
575 | # if 16 * 1024 < MINSIGSTKSZ
| ^~~~~~~~~~~
make[1]: *** [Makefile:1110 : ada/init.o] Erreur 1
The changes of the GLIBC that removed the MINSKTSZ constant was
introduced only for systems using the Linux kernel, and while the
changelog is recommanding using sysconf to get the value of
`_SC_MINSTKSZ`. The problem is that it does not allow to get the value
in the preprocessor context.
This error has been corrected on upstream GCC by Eric Botcazou <ebotcazou@adacore.com>
but this was not applied on upstream coreboot (even 4.11 branch).
It has been accepted by GCC and the bug report has been set as RESOLVED
FIXED, meaning it solved the bug.
The MINSTKSZ patch is needed for all GCC versions from 8 to 9, since this
commit solved the bug for 9, 10 and later versions. It has been adopted
by OpenSUSE for its GCC 8 package:
https://build.opensuse.org/projects/devel:gcc/packages/gcc8/files/gcc8-ada-MINSTKSZ.patch
Here's the corresponding patch header (in debian's format:
https://dep-team.pages.debian.net/deps/dep3/):
Origin: upstream, https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a5a7cdcaa0c29ee547c41d24f495e9694a6fe7f1
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264
Bug-GNU Boot: https://savannah.gnu.org/bugs/?64870
The MINSTKSZ patch added by this commit is unmodified from the
OpenSUSE one mentioned above, and the OpenSUSE patch is probably a
backport of the upstream GCC patch as there is not difference in what
it does.
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
GNUtoo: small formatting of the commit message + last paragraph.
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
We have redundant news systems: GNU Boot is already using GNU and
Savannah's new infrastructure, so we don't need to duplicate that on
the GNU Boot website.
This lowers the maintenance now (as we need to do less work to publish
news).
But it also lowers the amount of work in the future as Untitled (the
static website generator that we use) handles news generation
differently from the rest of the pages, and since we planned to
migrate to Haunt, getting rid of news generation should probably
divide the amount of work needed to do the migration by two.
Thanks a lot to Adrien 'neox' Bourmault for the help with this patch
(neox gave me the links, told me about the capabilities of Savannah,
Planet, etc).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
We have a test for catching a situation where new files are added in
releases without adding them as well in the ${release_files} variable
to test for their existance.
But this test only warn of the issue instead of failing. And since
people might not inspect all the log details in depth, it's better to
fail instead.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Before this commit if some files were in the release directory but
missing from ${release_files}, it would show something like that:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar
The ${release_files} variable is used to test for files missing in the
release directory, and it prints something if a file is missing:
[ !! ] release/roms/gnuboot-0.1-rc3-95-g1783708_d510mo.tar.xz is missing
Since confusion is possible between the two tests (especially if the
people looking at the log don't have all the code and context in mind
when doing that), this commit changes the code to print something like
that instead:
[ !! ] release/i945-thinkpads-install/gnuboot_src.tar missing in ${release_files}
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
This was broken by the commit 7df6d6169b
("Build bucts and patched flashrom for I945 ThinkPads with Guix.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix the build is stuck on the following during days on a
ThinkPad X200 with 8GiB of RAM and an Intel P8600:
building /gnu/store/z7k1rs4j98s5zj0f9xrn1p3k1w1fmgqa-proot-static-5.3.0.drv...
/ 'check' phase
And the Guix manual says the following about -R/-RR:
When this option is passed once, the resulting binaries require
support for “user namespaces” in the kernel Linux; when passed
_twice_(1), relocatable binaries fall to back to other techniques
if user namespaces are unavailable, and essentially work
anywhere—see below for the implications.
So by using -R instead of -RR we don't build proot-static anymore, and
we rely on the fact that most GNU/Linux distribution have namespaces
enabled (else a lot of packages like Guix or container software
would not work on them).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typo in commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
It can be handy to build GNU Boot in a chroot because Guix's
debootstrap can easily debootstrap both PureOS byzantium and Trisquel
10 (nabia), and once done users can simply chroot inside the target
rootfs. In addition chroots also don't have much isolation with the
host, so it is easy to set it up in a way that export /dev/kvm for
faster testing.
The downside is that while some init systems can start daemons while
in chroot, systemd chose not to support that as the separation between
the chroot and the host operating system is not good enough to prevent
accidental modifications of the host system[1].
So practically speaking if we want to start guix-daemon, 'systemctl
start' detects that it's in a chroot and refuses to work.
The concerns of systemd about running some init in chroots[1] is valid
however here we limit the risk by only running the daemon start
commands and not something else that kills host processes.
Also we choose to parse systemd units instead of running the commands
manually as some settings need to be retrieved from the distribution
such as the environment or the build group being used (this varries
accross distributions or installation methods).
[1]https://0pointer.de/blog/projects/changing-roots
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed whitespace issue in code and fixed commit message
Acked-by: Adrien Bourmault <neox@gnu.org>
We need to somehow isolate the git configuration being used to build
GNU Boot from the rest of the system as otherwise things like
automatic gpg signatures can kick in and block the build because it
waits for a pinentry.
In addition:
- It enables us to simplify the build code as the git configuration is
now the same during all the build.
- Contributors don't need to setup git anymore just to build GNU
Boot. This also makes GNU Boot a bit more reproductible.
Replacing git inside the build scripts / Makefiles enable us to still
run them manually (like ./resources/packages/coreboot/download).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
With Trisquel 11 (aramo) and its guix package (guix 1.3.0) using 'guix
time-machine --commit=v1.4.0' fails like that:
$ guix time-machine --commit=v1.4.0 -- describe
guix time-machine: error: Git error: unable to parse OID - contains invalid characters
But if we use the real commit hash instead of the tag name, the same
command works fine:
$ guix time-machine --commit=8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 -- describe
guix 8e2f32c
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The resources/packages/roms/boot script already work with the "help"
argument, however most of the other scripts use --help, so for
consistency we need to add --help as well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
The Intel Flash Descriptor files are supposed to be reproducible
already, so it's a good idea to add a test for that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
Without that fix, with a very basic Trisquel 11 (aramo) installation
and after running resources/dependencies/trisquel-10, the GNU Boot
autogen.sh is broken due to the lack of libtool:
$ ./autogen.sh 2>&1 > temp
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: /usr/bin/autoconf --force
configure.ac:79: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
So we simply make sure that libtool is installed as part of the
dependencies.
For Arch, libtool is already in base-devel (checked with Parabola).
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
In GNU Boot, at the time of writing, we want to advise users to use
the GRUB images as they don't require users to modify their
distribtions.
However before the commit aec2e2f2bcf7693a05e416f9722e15b9d1854516
("Fix bug #65663 (No support for LVM2)."), most computers using LVM2
would not boot with these images.
The bug is now fixed by this commit, however since we ship a custom
grub.cfg and that it is very important to get it right, it's a good
idea to have some sort of automated testing for it.
It uses Trisquel (instead of other FSF certified distributions) for
several reasons:
- Trisquel can be used by less technical users, and so it's important
to make sure it works as less technical users tend to have harder
times finding workaround when things break.
- It's probably the GNU/Linux distribution that most current and
potential GNU Boot users use.
- It is also maintained by a community that welcome contributions, so
if we hit some issues, we can also contribute to get it fixed (we
also verified that multiple times by contributing to it).
Note that we also welcome tests that reuse other distributions as
well.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: fixed typos in the commit message and fixed copyright notice
Acked-by: Adrien Bourmault <neox@gnu.org>
The xz compression operation can be quite long, so it's a good idea to
show its progression.
To do that we need to produce a tarball file first as xz doesn't have
any idea of the progression when just compressing a piped stream of
data.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien Bourmault <neox@gnu.org>
This enables guix commands used in various place to use that variable.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This was there from the start in the introduction of the guix command
detection in the commit 7df6d6169b
("Build bucts and patched flashrom for I945 ThinkPads with Guix.").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix, 'make release' results in the following issue:
resources/scripts/misc/generate-configure-makefiles.sh:
line 46: ./autogen.sh: No such file or directory
make: *** [Makefile:711: release] Error 127
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without that fix we have the following when running 'make release':
make[1]: Leaving directory '/home/gnutoo/work/projects/gnuboot/gnuboot'
cp: cannot stat 'i945-thinkpads-install-utilities/':
No such file or directory
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The creation of what became grub_memdisk.cfg can be tracked back to
the grub.cfg that I published in 2013 in my build-makefiles repository
and that is available in the very first Libreboot release in
build-makefiles/grub/memdisk/boot/grub/grub.cfg.
It was then modified by leah in 2014 who removed most of my work from
it. Details can be seen in the following repository:
[1]https://notabug.org/libreboot/obsolete-repository-preserved-for-historical-purposes
It was then picked up as-is in the osbmk repository and then the lbmk
repository that GNU Boot also has the history of.
Since we now have proper copyright history in all the files in
resources/grub/config we can now safely remove the AUTHORS file.
As for the COPYING file, we already have copyright headers and we
already ship a copy of the GPLv3 in our repository.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without this change, we have no idea if the website we see on
https://gnu.org/software/gnuboot/ is using the latest git commit.
It also allows anyone to spot and report to us that the website has
the wrong revision.
With this change we can also potentially spot issues in the website
generation for instance when the website should have been regenerated
and it wasn't, or from an archive or web page file, get to the git
commit it was generated from.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Since the commit 776073e2f8 ("website:
make the website prefix (software/gnuboot) configurable."), site.cfg
is generated. So we also need to add it to .gitignore as well, else it
shows up in git status.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
All the content on this page has now been reviewed by the GNU Boot
project.
This change is badly needed as the docs link is available in the
header of most pages of the website, and also because the docs page
also links to pages that were reviewed and that are perfectly valid,
so readers might stop there and not look at other pages below.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The information on how to find the GNU Boot version that is running is
outdated (for instance there is no lbversion, it also refers to older
Libreboot revisions). Because of that, we move it in a separate page
for now as this can then enable to remove the unreviewed tag to the
docs index page.
This is urgent and important as the docs link is available in the
header of most pages of the website, and also because the docs page
also links to pages that were reviewed and that are perfectly valid,
so readers might stop there and not look at other pages below.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The entries inside the "Verified copyright headers" section refer to
commit hashes. And since a commit can't refer to itself (unless SHA1
is broken), we split that in two commits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The serve.sh script was added in the commit
58fc2a673d ("Add the ability to test the
website locally") in the website-build repository of the Genuine
Libreboot project. This repository was then merged in GNU Boot.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The entries inside the "Verified copyright headers" section refer to
commit hashes. And since a commit can't refer to itself (unless SHA1
is broken), we split that in two commits.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The Libreboot maintainer (Leah Rowe) included nonfree software in
Libreboot releases. This lead to the creation of Genuine Libreboot
project (https://libreboot.at). Since this project reused the
Libreboot website from before the inclusion of nonfree software, it
also depended on Untitled, a website generator written in shell
script.
Since this website generator is not packaged in most distributions,
and that the Genuine Libreboot project wanted automatic builds of the
website, I wrote a set of scripts and Makefile to automatize the
download of Untitiled and the build of the website in November
2022. This corresponds to the commit
db0fb8a251 ("Initial import").
Then I improved these script(s) and Makefile(s) over time and they
were merged in the GNU Boot project.
While what is now in website/ is the result of merging the site/ and
website-build/ directories. To do that site/ was renamed to website/
just before the merge. Only website-build/ had a .gitignore.
This is because the website was only built with the website-build code
in subdirectories of website-build/ and/or in temporary volatile
directories, and so this would not create any built file in the git
repository outside of website-build.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
Without this commit we have no way of tracking the status of files and
we risk making the same verification too many times.
Ideally we also need procedure and/or tools to make sure omissions
don't get in.
So far the work to update some of the headers on some of the files
required to look at multiple git repositories and even tarball
releases, and in some cases it even required good knowledge of the
provenance of the files to reconstruct the proper history.
In contrast the way we track contributions in git makes it much easier
to fix subsequent omissions of people/dates in the copyright headers.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
I've not found how to fix the example, and we also need to document
how to build an image for a specific computer.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
At the very beginning, we had tarball releases of Libreboot which were
made by Leah Rowe.
The first 3 tarball releases are in 2013 and the fourth is in
2014. The 2013 tarballs didn't have this build script: In 2013, to
build Libreboot, Leah used a combination of commands typed by hand and
scripts I provided her (they are in the build-makefiles directory in
these tarball releases). So she wrote the build script in 2014.
I also looked if I could find traces of my "build-makefiles" scripts
inside Leahs's build script but I didn't find any. This means that she
wrote it from scratch and that the copyright really starts with her in
2014.
Then in 2014, more tarball releases follow and then we finally have
the very first commit of Libreboot: commit
cee90ae0fce6d6aee8d78969b60c952c8890abd6 ("Libreboot release 6 beta
1.").
Since all these tarball releases and the very first commit of
Libreboot were made by Leah Rowe and that all that happened in 2014,
it means that the build script in it was made in 2014 by Leah Rowe.
After that following the history is easier. To do that we need several
repositories:
- First we need to follow it in
obsolete-repository-preserved-for-historical-purposes from the very
first commit until the r20160907 tag.
- Then we follow it in osbmk from the very first commit: commit
df76c3eb63dd8f4979d78ca262218eedb93512ed ("Fork Libreboot 20160907
build system. Large parts have been re-written.") up to the last
commit of the libre branch: commit
a02723897cab744c7ed31d7cca48308528cafe76 ("fix seabios
downloading").
- Then we follow it in GNU Boot directly as we included the history of
lbmk as well, starting from the commit
89517ed6b9 ("libreboot!").
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: minor fix in commit message (typo)
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The resources/packages/src/release content appeared in osbmk in the
2e2fe863172b513c3bdd4d0497657223ff6abdb4 ("Retroboot beta release,
20201228"). This commit is present in both the master branch and the
libre branch of osbmk.
The libre branch was then used as a basis to the (first) commit
89517ed6b9 ("libreboot!").
Then since GNU Boot kept the history of lbmk, we then have the rest of
the history of that file.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The GNU Boot project merged several repositories in its main git
repository, each with their separate histories. So far we have:
- the documentation/website that came from Libreboot
- the documentation/website pictures that also came from Libreboot
- the build system that also came from Libreboot (it's called lbmk there).
- some website autotools build system that was made from scratch by me.
The grub.cfg we use comes from the build system repository (lbmk). I
extracted the copyrights from the git commits of this repository.
However the first commit of lbmk (which we also have in our main GNU
Boot repository) is the following:
commit 89517ed6b9
Author: [Leah Rowe]
Date: [2021]
libreboot!
this is forked from the "libre" branch in osboot, which is itself a libre,
deblobbed fork of osboot, a blobbed up fork of libreboot
libreboot needed to be purged clean. this is the new libreboot development
repository. the old one has been abandoned
So I had to continue and look at the libre branch of osboot and
extract the copyrights from its commits as well.
Then I downloaded osbmk (https://notabug.org/osboot/osbmk) and
continued to look.
And here too we need to go beyond the first commit again, because
osbmk is based on 'Libreboot 20160907':
commit df76c3eb63dd8f4979d78ca262218eedb93512ed
Author: [Leah Rowe]
Date: [2020]
Fork Libreboot 20160907 build system. Large parts have been re-written.
This build system builds ROMs for X230, but they are so far untested.
Use at your own risk!
I still need to write documentation and do testing.
SOON: T60 with ATI GPU
We can find Libreboot 20160907 in
https://notabug.org/libreboot/obsolete-repository-preserved-for-historical-purposes
And then we end up with this commit:
commit cee90ae0fce6d6aee8d78969b60c952c8890abd6
Author: [Leah Rowe]
Date: [2014]
Libreboot release 6 beta 1.
Before that Libreboot only had tarball releases and the very first
tarball release was based on build scripts/Makefiles made by me, and
the git repository having the GRUB configuration can be found in
Libreboot 20131212 in X60/build-makefiles.
commit 80c37b9093be8325bf9ca8271ae4c6dba8fe81d6
Author: [GNUtoo]
Date: [2013]
Initial commit.
For now we only build the grub payload.
Signed-off-by: [GNUtoo]
And the intial grub.cfg was made by hand by me.
While I was at it I also updated the name/email combination in the
copyright header for the ones currently used.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This has several reasons:
- The GNU Boot project didn't review all the hardware made by Pusi.sm,
especially because Puri.sm also sell hardware that is out of scope
for the GNU Boot project like USB tokens or SIM cards.
- Reducing the scope to just x86 computers made by Puri.sm instead
doesn't work either because there is no context to the
recommendation.
In harm reduction[1], the Freedom Ladder campaign by the FSF[2], and
the FSF giving guide[3], context is taken into account so that people
can make informed choices based on their constraints and choices.
In practice these approaches make statement like "this computer
respects more your freedom than this other one", or "this is
dangerous because of that and you can reduce harm this way, even if
it's far from perfect" and give context to statements to enable
people to really understand what it means.
[1]https://en.wikipedia.org/wiki/Harm_reduction
[2]https://www.fsf.org/campaigns/campaigns-summaries#ladder
[3]https://www.fsf.org/givingguide/
At the end of the day it's also less work and maintenance to just
remove that hardware recommendation statement than to review specific
computers that GNU Boot doesn't even support.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
The idea behind this FAQ entry is to be able to point to it when
people ask us to support additional computers.
This makes sure we don't miss important points in our answers and it
also tries to convey the kind of work needed, including for less
common but important cases like when the code for a computer is found
to work on another one (in that case we badly want to know about it,
especially if there is only documentation work to be done for it).
In addition this kind of question is very common in projects that have
limited hardware support, so that also should help us spending less
time answering that question again and again.
The answer also makes it very clear that GNU Boot is just a
distribution and also shows the kind of work various contributors do
to show that some of them are really easy to do, in the hope that it
could bring up more contributors as well.
The way the entry is written (trying to avoid technical words, while
also speaking about very technical topics) is because it is meant for
a very wide audience that go from less technical users that just want
GNU Boot to work on the computer they have but don't know anything
about hardware support, to contributors to projects like Coreboot and
U-Boot that might just want to also add support for computers they
worked on in GNU Boot.
Wording like "the computer will need to be supported well by other
project" is vague to enable people used to contribute to projects like
Coreboot or U-Boot or even experienced distributions contributors will
understand it as having the strict minimum of out of tree patches,
while also enabling less technical users (that don't know what is an
"out of tree patch") to understand more or less what it means.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
neox: minor changes (typo and repetition)
Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
