the combination of x_ with the "e" function enables
for much simpler file-check error handling, which is
a unique innovation of lbmk as it pertains to sh.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the cbfs function will call cbfstool, which will perform
the same check, and the same error condition would cause
the same exit behaviour in lbmk. the error message would
also provide output that is just as useful for debugging.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There was no error handling, *at all*, on the actual tar
command, due to the lack of set -o pipefail, which we cannot
rely on in sh.
The x_ wrapper can be used in this case, as a mitigation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it wouldn't exit with error status anyway, since i'm
setting +e here, but if that accidentally changed in
the future, i still wouldn't want this to exit.
the bruteforce me extraction naturally throws a lot of
errors, hence +e, because of how the extraction works,
but the result is checked at the end of the process,
to compensate. hence +e, because otherwise this brute
force extraction would never work.
therefore, this is an extremely theoretical bug fix, the
most quintessential of preemptive bug fixes, to the point
that it is actually rather pedantic.
The ":" in "|| :" will likely *never* be executed, but it
handles the theoretical case where the subshell exits with
non-zero status and +e is set; subshells aren't meant to
behave this way anyway, but who knows what cursed sh
implementation the user is on?
Signed-off-by: Leah Rowe <leah@libreboot.org>
in these if clauses, what follows afterward is exactly
the same: set xchanged and return.
Therefore, these lines are redundant and they can be
removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This change finally ensures that no insertions will be
attempted, on the basis that readkconfig failed; this
covers the instance whereby vcfg was set, but no scanned
items were indicated e.g. Intel ME files not specified.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This should speed up automated tests. Otherwise, it goes
through all the extra checks that aren't needed, for each
individual type of vendor file, and also errors out when
handling pico serprog images; during automated testing,
on the bin directory, you might try on every tarball, one
of which is the pico tarball and this patch makes lbmk skip
that one too.
In general, we must not perform unnecessary tasks. Doing so
may even cause other bugs that we couldn't easily detect.
Signed-off-by: Leah Rowe <leah@libreboot.org>
x_ cannot be used, where output is redirectod to a file;
only the conventional piping can be used.
same as the last change. this and the other fix were caught
during testing.
Signed-off-by: Leah Rowe <leah@libreboot.org>
x_ cannot be used, where output is redirected to a file;
only the convention piping can be used, for errors.
relying on x_ in these cases will cause unpredictable bugs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i can't call $err (variable), because it's set
to fail_inject. fix this infinite loop, which
was an oversight in the previous commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I was using a complicated method of knowing whether
the current instance was parent or a child, to know
whether the lock file and TMPDIR needed to be purged.
It was quite error-prone too. Instead, I'm now handling
it directly from within the if statement that previously
initialised xbmk_parent=y, forking ./mk from there.
The forked instance would not trigger that if clause
again, since then TMPDIR is created, thus avoiding
recursion.
This is an improvement because it doesn't rely on how
the parent handles exit statuses, and it ensures that
the lock/tmp files are never accidentally deleted.
Even if a given program/script that lbmk runs would
export TMPDIR, it doesn't matter because lbmk doesn't,
so it would be unaffected.
Signed-off-by: Leah Rowe <leah@libreboot.org>
because the top-down function order isn't as reliable
in lib.sh, since this is what first runs, included
in every other script
Signed-off-by: Leah Rowe <leah@libreboot.org>
write to .version and .versiondate, instead
of version and versiondate.
this will hide them to avoid visual clutter while
analysing files within lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of running pwd all the time, run it once in lib.sh,
and export PWD.
for lbmk-specific use of PWD, use xbmkpwd, which contains
the value of PWD as was set by the pwd utility in lib.sh.
many parts of lbmk rely on pwd, and it *must* be correct.
this change adds basic error handling, since pwd can in
fact return errors in some cases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's incorrect for PATH not to be set, but some users
may foolishly blank it out before running lbmk.
prevent such issues, by initialising it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
PWD could be anything, if the user manually exported
it before running lbmk.
always run pwd instead, to get the real string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
several code lines were condensed together, which
make them less readable. make the code more readable
by having separate commands on separate lines.
i previously did this during my manic build system
audits of 2023 and 2024; condensing lines like this
is overly pedantic and serves no real purpose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We were previously not handling picotool at all, and
pico-sdk would download picotool itself, at build time.
This means that the source archive, if created, would
not contain picotool. While not strictly required, for
complete corresponding source, since it's a toolchain
and not the actual pico-serprog firmware, it is my policy
that releases must include full corresponding source code,
when it is feasible to do so.
I must say, I intensely dislike cmake, with such burning
passion; I am thoroughly displeased by how hacky this is,
but it works and now nothing is in my way for a Libreboot
20241206 rev8 release!
Signed-off-by: Leah Rowe <leah@libreboot.org>
See:
https://docs.python.org/3/library/sys.html#sys.version_info
The sys.version_info tuple is a more reliable way to
get the version. Our previous logic assumed that Python
would always output "Python versionnumber", but this may
not always be how it works. We've seen this for example
where Debian modifies some GNU toolchains to include Debian
something in the output.
Python has a standard method built in for outputting exact
the information we need. In my system, what I got was this:
(3, 11, 2, 'final', 0)
That output was from running this command:
python -c 'import sys; print(sys.version_info[:])'
This is much more robust, so use this instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we already check the python version, and set a variable
for it, so that we can reliably use python3, even if
python in PATH doesn't correspond to python3. for
example if a system has python as python2 and python3
as python3
well, we use that when running deguard for example, but
various upstream projects that we use may need python,
and all of them use python3, not 2
so, re-use the python variable set up by lbmk, and
set it up in PATH accordingly. this now makes the note
about python3 obsolete, on docs/build.md in lbwww.git
Signed-off-by: Leah Rowe <leah@libreboot.org>
They may not actually always be binary blobs, at least not
software. I started referring to these as "vendor files" some
time ago, for this reason.
With this terminology, it applies properly to any sort of file
from the vendor. For example, it may be that in the future, we
start inserting the MFS section of an an Intel ME image, into
the Intel ME.
We already do that with deguard for example (set MFS config),
on MEv11 based setup. That is a vendor *file*, and though it
may still actually be a binary blob, it's not software, but
configuration.
The term "blob" normally means compiled software, in most people's
minds, but the term blob is technically accurate for any blob,
not just software; however, we have to keep people's perception
in mind.
Whereas, "vendor file" is also understood by most people to
include code supplied by the vendor.
We haven't done any releases yet with this ROM image file name
prefix, so it's perfectly OK to handle it now, without handling
the old one for backwards compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Users running setmac on an X200 tarball for example, will
now see it being modified, if they didn't specify
setmac keep, so they might think vendor files are being
inserted, which they are not.
Therefore, a confirmation is provided at the end of the output.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./mk inject libreboot-YYYYMMDD_board.tar.xz setmac restore
This does the same thing as a normal setmac command, except
that it does not alter the MAC address; it is also not the
same as "keep", which skips *writing* the GbE region in-ROM.
The *restore* argument writes the default, unmodified GbE file
kept by lbmk, unmodified because nvmutil is skipped when the
user specifies this argument.
This option is useful for debugging purposes, because it can
be used to verify whether anything else is being wrongly
modified by the script; the "nuke" command can be executed
afterward, and the hash file inspected versus release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
