I overlooked this in a previous patch. It doesn't really
matter, since we're operating on a file anyway, but it's
not correct.
Files should have rm -f on them, not rm -Rf, for deletion.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We already do what the old code does in setcfg, by
virtue of the fact that the st variable is later
checked, after loading this config conditionally,
where the st variable is otherwise blank.
We can avoid the unnecessary work after loading
the config, by returning if the config is absent.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We are calling xbmkget in the same way, whether it's
a subfile or subrepo.
Rename these variables to subcurl and subgit, so that we
can call xbmkget unconditionally.
Signed-off-by: Leah Rowe <leah@libreboot.org>
they were always re-downloading every time.
i've basically re-written most of xbmkget.
there was some erroneous conditions under which
it wrongly deleted the cached file, resulting in
it being downloaded again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The result of the printf statement is sorted, making
it do binaries first, which results in a lot of junk
files then being present inside the source archive.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it now handles more than just git, and i forsee
it handling even more in the future, e.g. rsync,
ftp, bittorrent.
Signed-off-by: Leah Rowe <leah@libreboot.org>
And this time it works.
I'm now calling xbmkget() which in turn calls tmpclone(),
instead of me calling tmpclone() directly.
The git-pull is done on both remotes, regardless of whether
the first succeeds. This way, if I forgot to update a mirror,
downloads would probably still work.
This also fixes an issue people were having, for example where
the gnulib repository of GRUB was always being downloaded
every time.
I'm using a new directory, XBMK_CACHE/clone, instead
of XBMK_CACHE/repo (which I used before), in case people
still have the old caches from before.
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't move to the real directory until the work
is done.
that way, a re-try can be done, while analysing
the old files. it is created based on the tmpdir,
under XBMK_CACHE/
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't need to call it from git.sh, because it's
only being done when building a release anyway,
and we already run rmgit when doing a release.
The function itself is only two simple fx_ calls,
so we can just do that from build_release().
Signed-off-by: Leah Rowe <leah@libreboot.org>
in cbmk, it's only used from there.
in lbmk, it's also used from vendor.sh.
however, i plan to further expand git.sh at
some point, tidying it up so that git cloning
is also done from xbmkget, with dlop=git and
git.sh would then be renamed to get.sh
Signed-off-by: Leah Rowe <leah@libreboot.org>
group the cbfs command to the extract command, since they
are related. this makes it clearer that the following
command to extract refcode is unrelated.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it was too complicated. most of the logic has been moved
to a new function, try_file()
the for loop is handled by xbmkget(), whereas each try
is now handled in try_file()
Signed-off-by: Leah Rowe <leah@libreboot.org>
split the actual bootstrapping to getvfile()
setvfile only sets the config, but then it will
call getvfile() to act on that config.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i moved out more code to vendor.sh, to reduce the
amount of lbmk-only code on inject.sh
this should reduce the number of merge conflicts
even further, when cherry picking from lbmk to cbmk.
in particular, vendor file insertion is now handled
entirely through the "setvfile" function, instead
of from inject.sh, which seems counterintuitive,
but remember that inject.sh also does MAC addresses.
therefore, the inject.sh script is now primarily for
inserting MAC addresses, and handles vendor downloads
in a slightly more convoluted way, but still easy
enough to understand if you read it a bit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
otherwise, we create empty directories where build.list
doesn't exist, like on coreboot.
we already create a directory when needed, when actually
copying elf files, so let's just leave it at that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
to the extent feasible, keep lbmk-specific parts on
inject.sh to a minimum. this will later be used to
re-sync cbmk's inject.sh with lbmk's, because cbmk's
one doesn't handle vendor files.
the way this is designed now, with this patch, will
make cherry-picking lbmk to cbmk easier in the future,
when keeping this part of cbmk in sync with lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
generally go for a more linear function order, and
split up any functions.
the objective is to have functions only suitable to
libreboot be separate. more splitting will be done,
and eventually the vendor-download functions will be
split into a new file, as will several other functions.
this is being done as part of an effort to bring the
libreboot and canoeboot versions of inject.sh in sync,
so that from now on, cherry picking between the two
projects will produce fewer merge conflicts and require
a lesser amount of post-merge maintenance.
some other minor cleanup has also been done; for example,
the "need_files" variable is redundant and was removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
many places in lbmk used err, because older versions
of x_ did not handle globbing properly.
however, use of x_ is preferable on trivial commands.
the only time err() should be called is what it has
to be, when x_ can't work, or when a more useful error
message is needed, for context.
Signed-off-by: Leah Rowe <leah@libreboot.org>
that way, the Intel GbE device can be enabled there,
and only then would the refcode file be copied.
otherwise, the current behaviour would leave buggy
refcode in place, if the dd command failed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use of the e function would slow down execution,
and it's mostly unnecessary in this case.
the e function is only needed if we want to confirm
via user message that a file exists. that is not
needed here.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current test allows a further extraction after
running mecleaner, even if me.bin was found.
further, any recursive calls that exit non-ze
don't lot the loop acthually stop, unless we
subshell that too, otherwise fx_ is returned to
return 0 when a given command it runs returns 1,
or more specifically: the for loop in x_ breaks.
this is by design, and there's not much that can
be done, but this patch should pseed up extraction
a little bit, when dealing with intel me files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
