i was checking whether it's a directory, whereas i should
have been checking whether it's a file. this is a workaround
put in place in case someone downloaded a tarball from codeberg
which is pre-generated per commit. in this situation, the
version and versiondate files do not exist, but the design
of the build system requires that they do exist.
the existing check is correct except for this bug, so fix
the bug. check that they are files, not directories
Signed-off-by: Leah Rowe <leah@libreboot.org>
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a user was getting error "version unset" when using the
tarball generated from codeberg. it's recommended to use
the git repository properly, or a release archive.
mitigate this so that the build succeeds anyway.
Signed-off-by: Leah Rowe <leah@libreboot.org>
again, the directory in question is simply used
in a for loop using asterisk (git_am_patches) and
the for loop simply won't iterate if either the
directory doesn't exist or it contains no items.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in the function that immediately follows, it
starts two for loops that check every item in
that directory, using the asterisk wildcard.
if the directory does not exist, then the for
loop will simply break on first pass.
Signed-off-by: Leah Rowe <leah@libreboot.org>
"./update project trees" is a leftover from the
old build system design, prior to audits.
this particular call is for when xtree is defined,
which means that a given tree must rely on the given
coreboot tree defined by xtree. the "xtree" tree is
downloaded, so that its crossgcc builds can be re-used
to save time when building targets across many trees.
this is because trees often use identical crossgcc builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
for single-tree project (e.g. flashprog):
config/submodule/PROJECT/MODNAME/patches
for multi-tree project (e.g. coreboot):
config/submodule/PROJECT/TREE/MODNAME/patches
MODNAME is e.g.:
3rdparty/vboot directory in coreboot: would become vboot
(the submodule codepath is filtered to up to the final slash)
another example:
submodire src dir 3rdparty/foo/bar
MODNAME would be "bar"
Add whatever patches you like to a given submodule.
An example patch is included in this commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the function is very small and only called once,
from fetch_project_trees()
merge it into fetch_project_trees()
Signed-off-by: Leah Rowe <leah@libreboot.org>
one of the calling functions relies on the return value
to be always 0, so these error conditions in mkrom_tarball
have been altered to cause an *exit* (non-zero) instead.
in practise, the commands in question were printf commands
run after tho directory they output to had been created,
so write access would probably not be an issue.
nonetheless, technically correct is the best kind of correct.
Signed-off-by: Leah Rowe <leah@libreboot.org>
previously, it was attempting to load the configs and silently
failing. we must provide feedback to the user.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The build system already deletes .git in all source
directories for each given release, but does so at
the very end; it still does, but now it is deleted
one by one per project, to save space during very
large builds (release sizes vary wildly, depending
on how many trees exist for coreboot basically).
If you're building entirely in tmpfs (as I do), this
could be a problem if you have lots of .git/ directories.
This change reduces disk usage, or in the above example,
memory usage when running the build system from tmpfs.
This complements another recent change, where ROM images
are compressed per target during release builds, rather
than all at the very end of the process. It is part of a
series of optimisations, to reduce the memory and disk
usage of the build system, and to reduce I/O wastage
in general.
This change will not be the last of such changes!
Signed-off-by: Leah Rowe <leah@libreboot.org>
an equivalent change has been made in cbmk.
certain lbmk-specific variable names have been made
generic, with certain functions and other variables
moved around.
i maintain sync between libreboot and canoeboot, where
both projects can have the same behaviours, and most of
the merge conflicts have to do with variable names
containing "LBMK", "lbmk", "cbmk" or "CBMK", or
indeed "canoeboot" and "libreboot"
LBMK/lbmk/CBMK/cbmk variables between canoeboot and
libreboot now contain the string XBMK/xbmk
it should now be *much* easier to merge build system
changes between lbmk and cbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's only used from main() in the main build script,
and it's very small, as is main()
therefore, move the logic into main()
Signed-off-by: Leah Rowe <leah@libreboot.org>
in lbmk, we call check_project() to set variables
such as projectname, version, version date
this is unnecessary, because all main scripts use
this functionality anyway
do it by default
Signed-off-by: Leah Rowe <leah@libreboot.org>
releases aren't reproducible anyway. we were
using options available in gnu tar for this.
it will be revisited at a later date. however, the next
time this is done, we will use another method because
there are in fact portable ways to create tarballs
reproducibly, documented on reproducible-builds.org
to be revisited, at a later date. for now, remove bloat.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's only called once, from this file, within a small
function, and the function itself is very small.
remove, and put the contents of the function in the
calling function.
Signed-off-by: Leah Rowe <leah@libreboot.org>
export LBMK_RELEASE="y"
if this is done, the tarball is created instead
of a directory, and the rom images are nuked using
./vendor inject with the nuke option, inserting the
correct version files; the rom directory is deleted
now the release script logic simple renames existing
tarballs. the benefit of this change is fewer lines of
code, and now lbmk doesn't use an insane amount of disk
space when building a *lot* of release images (the
uncompressed directories are deleted after each build)
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc is retained, because it's needed on 820 g2
it's no longer needed on haswell, because nri is stable. nri
is short for "native ram initialisation", and libreboot provides
this for: thinkpad t440p, thinkpad w541, dell optiplex 9020 mt,
and dell optiplex 9020 sff
remove, in line with libreboot's binary blob reduction policy
previous revisions, prior to the recent release, stated that
it would be retained for compatibility, but it's really not
right to retain it, because doing so violates libreboot's policy
the recent release excluded mrc-based rom images for haswell
machines, providing only those rom images that use the libre
raminit, while retaining support for mrc in the build system, so
that users could still run the lbmk inject script on older release
roms that use mrc
again: libreboot's binary blob reduction policy is very clear:
https://libreboot.org/news/policy.html
it is a policy that can be summarised, thus:
if a blob can be avoided, it must be avoided.
therefore, we will avoid the Haswell MRC raminit blob
Signed-off-by: Leah Rowe <leah@libreboot.org>
the release variable is all we need, turning a target on
or off for a given release.
the status checks were prone to bugs, and unnecessary; it
also broke certain benchmark scripts.
it's better to keep the lbmk logic simpler. board status
will be moved to the documentation instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
stub it from the main build script
the commands remain identical:
./vendor download arguments_here
./vendor inject arguments_here
Signed-off-by: Leah Rowe <leah@libreboot.org>
i replaced 2022, 2023 with 2022, 2024 when updating
the years, as per modifications, but the 2023 copyright
doesn't become invalidated
change it to 2022-2024 instead, which is correct
Signed-off-by: Leah Rowe <leah@libreboot.org>
export LBMK_THREADS=x
where x is an integer. this is already supported for
setting the number of build threads, but if not set
it uses nproc.
openbsd doesn't have nproc. default to 1 thread.
now you MUST set threads. e.g. in linux do:
export LBMK_THREADS=$(nproc)
preliminary work is being done to make lbmk run
on openbsd!
Signed-off-by: Leah Rowe <leah@libreboot.org>
export LBMK_STATUS=n
if not set, the status checks and confirmation dialogs
persist. if set to y they persist.
if you set it to n, all checks are disabled, so e.g.:
./build roms all
this would once again build all targets, regardless
of status. this is if you want the old behaviour.
Signed-off-by: Leah Rowe <leah@libreboot.org>
export LBMK_VERSION_TYPE=x
x can be: stable, unstable
in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, lbmk defaults to "unknown"
if LBMK_VERSION_TYPE is set, no confirmation is asked
if the given target matches what's set (but what's set
in that environmental variable can only be stable or
unstable)
if LBMK_RELEASE="y", no confirmation is asked, unless
the target is something other than stable/unstable
"unstable" means it works, but has a few non-breaking
bugs, e.g. broken s3 on dell e6400
whereas, if raminit regularly fails or it is so absolutely
unreliable as to be unusable, then the board should be
declared "broken"
untested means: it has not been tested
With this change, it should now be easier to track whether
a given board is tested, in preparation for releases. When
working on trees/boards, status can be set for targets.
Also: in the board directory, you can add a "warn.txt" file
which will display a message. For example, if a board has a
particular quirk to watch out for, write that there. The message
will be printed during the build process, to stdout.
If status is anything *other* than stable, or it is unstable
but LBMK_VERSION_TYPE is not set to "unstable", and not building
a release, a confirmation is passed.
If the board is not specified as stable or unstable, during
a release build, the build is skipped and the ROM is not
provided in that release; this is in *addition* to
release="n" or release="y" that can be set in target.cfg,
which will skip the release build for that target if "n"
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe