cbmk/include/git.sh

177 lines
4.7 KiB
Bash
Raw Normal View History

# SPDX-License-Identifier: GPL-3.0-or-later
# Copyright (c) 2020-2021,2023-2024 Leah Rowe <leah@libreboot.org>
# Copyright (c) 2022 Caleb La Grange <thonkpeasant@protonmail.com>
eval "$(setvars "" _target rev _xm loc url bkup_url depend tree_depend xtree \
git.sh: support downloading *files* as submodules when we download coreboot, we currently don't have a way to download crossgcc tarballs, so we rely on coreboot to do it, which means running the coreboot build system to do it; which means we don't get them in release archives, unless we add very hacky logic (which did exist and was removed). the problem with coreboot's build system is that it does not define backup links for each given tarball, instead relying on gnu.org exclusively, which seems OK at first because the gnu.org links actually return an HTTP 302 response leading to a random mirror, HOWEVER: the gnu.org 302 redirect often fails, and the download fails, causing an error. a mitigation for this has been to patch the coreboot build system to download directly from a single mirror that is reliable (in our case mirrorservice.org). while this mitigation mostly works, it's not redundant; the kent mirror is occasionally down too, and again we still have the problem of not being able to cleanly provide crossgcc tarballs inside release archives. do it in config/submodules, like so: module.list shall say the relative path of a given file, once downloaded, relative to the given source tree. module.cfg shall be re-used, in the same way as for git submodules, but: subfile="url" subfile_bkup="backup url" do this, instead of: subrepo="url" subrepo_bkup="backup url" example entries in module.list: util/crossgcc/tarballs/binutils-2.41.tar.xz util/crossgcc/tarballs/gcc-13.2.0.tar.xz util/crossgcc/tarballs/gmp-6.3.0.tar.xz util/crossgcc/tarballs/mpc-1.3.1.tar.gz util/crossgcc/tarballs/mpfr-4.2.1.tar.xz util/crossgcc/tarballs/nasm-2.16.01.tar.bz2 util/crossgcc/tarballs/R06_28_23.tar.gz the "subrev" variable (in module.cfg) has been renamed to "subhash", so that this makes sense, and that name is common to both subfile/subrepo. the download logic from the vendor scripts has been re-used for this purpose, and it verifies files using sha512sum. therefore: when specifying subrepo(git submodule), subhash will still be a sha1 checksum, but: when specifying subfile(file, e.g. tarball), subhash will be a sha512 checksum the logic for both (subrepo and subfile) is unified, and has this rule: subrepo* and subfile* must never *both* be declared. the actual configuration of coreboot crossgcc tarballs will be done in a follow-up commit. this commit simply modifies the code to accomodate this. over time, this feature could be used for many other files within source trees, and could perhaps be expanded to allow extracting source tarballs in leiu of git repositories, but the latter is not yet required and thus not implemented. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-08 02:01:05 +00:00
mdir subhash subrepo subrepo_bkup subfile subfile_bkup)"
fetch_project_trees()
{
_target="$target"
[ ! -d "src/$project/$project" ] && x_ mkdir -p "src/$project" \
&& fetch_project_repo "$project"
fetch_config
e "src/$project/$tree" d || prepare_new_tree; return 0
}
fetch_config()
{
rm -f "$cfgsdir/"*/seen || $err "fetch_config $cfgsdir: !rm seen"
eval "$(setvars "" xtree tree_depend)"
while true; do
eval "$(setvars "" rev tree)"
_xm="fetch_config $project/$_target"
load_target_config "$_target"
[ "$_target" = "$tree" ] && break
_target="$tree"
done
[ -n "$tree_depend" ] && [ "$tree_depend" != "$tree" ] && \
x_ ./update trees -f "$project" "$tree_depend"; return 0
}
load_target_config()
{
safer, simpler error handling in cbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in cbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. cbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from cbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <info@minifree.org>
2024-03-27 01:19:39 +00:00
[ -f "$cfgsdir/$1/target.cfg" ] || $err "$1: target.cfg missing"
[ -f "$cfgsdir/$1/seen" ] && $err "$_xm cfg: infinite loop in trees"
safer, simpler error handling in cbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in cbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. cbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from cbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <info@minifree.org>
2024-03-27 01:19:39 +00:00
. "$cfgsdir/$1/target.cfg" || $err "load_target_config !$cfgsdir/$1"
touch "$cfgsdir/$1/seen" || $err "load_config $cfgsdir/$1: !mk seen"
}
prepare_new_tree()
{
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
printf "Creating %s tree %s (%s)\n" "$project" "$tree" "$_target"
git_prep "src/$project/$project" "src/$project/$project" \
"$PWD/$cfgsdir/$tree/patches" "src/$project/$tree" "update"
nuke "$project/$tree" "$project/$tree"
}
fetch_project_repo()
{
eval "$(setvars "" xtree tree_depend)"
scan_config "$project" "config/git"
chkvars loc url
[ -n "$xtree" ] && [ ! -d "src/coreboot/$xtree" ] && \
x_ ./update trees -f coreboot "$xtree"
[ -z "$depend" ] || for d in $depend ; do
printf "'%s' needs '%s'; grabbing '%s'\n" "$project" "$d" "$d"
x_ ./update trees -f $d
done
clone_project
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
for x in config/git/*; do
[ -f "$x" ] && nuke "${x##*/}" "src/${x##*/}" 2>/dev/null
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
done
}
clone_project()
{
loc="${loc#src/}"
loc="src/$loc"
printf "Downloading project '%s' to '%s'\n" "$project" "$loc"
e "$loc" d && return 0
remkdir "${tmpgit%/*}"
git_prep "$url" "$bkup_url" "$PWD/config/$project/patches" "$loc"
}
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
git_prep()
{
_patchdir="$3" # $1 and $2 are gitrepo and gitrepo_backup
_loc="$4"
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
chkvars rev
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
tmpclone "$1" "$2" "$tmpgit" "$rev" "$_patchdir"
if singletree "$project" || [ $# -gt 4 ]; then
prep_submodules "$_loc"
fi
[ "$project" = "coreboot" ] && [ -n "$xtree" ] && [ $# -gt 2 ] && \
[ "$xtree" != "$tree" ] && link_crossgcc "$_loc"
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
[ "$xbmk_release" = "y" ] && [ "$_loc" != "src/$project/$project" ] \
&& rmgit "$tmpgit"
move_repo "$_loc"
}
prep_submodules()
{
mdir="$PWD/config/submodule/$project"
[ -n "$tree" ] && mdir="$mdir/$tree"
[ -f "$mdir/module.list" ] && while read -r msrcdir; do
fetch_submodule "$msrcdir"
done < "$mdir/module.list"; return 0
}
fetch_submodule()
{
mcfgdir="$mdir/${1##*/}"
eval $(setvars "" subhash subrepo subrepo_bkup subfile subfile_bkup st)
[ ! -f "$mcfgdir/module.cfg" ] || . "$mcfgdir/module.cfg" || \
$err "! . $mcfgdir/module.cfg"
for xt in repo file; do
eval "[ -n \"\$sub$xt\$sub${xt}_bkup\" ] && st=\"\$st \$xt\""
git.sh: support downloading *files* as submodules when we download coreboot, we currently don't have a way to download crossgcc tarballs, so we rely on coreboot to do it, which means running the coreboot build system to do it; which means we don't get them in release archives, unless we add very hacky logic (which did exist and was removed). the problem with coreboot's build system is that it does not define backup links for each given tarball, instead relying on gnu.org exclusively, which seems OK at first because the gnu.org links actually return an HTTP 302 response leading to a random mirror, HOWEVER: the gnu.org 302 redirect often fails, and the download fails, causing an error. a mitigation for this has been to patch the coreboot build system to download directly from a single mirror that is reliable (in our case mirrorservice.org). while this mitigation mostly works, it's not redundant; the kent mirror is occasionally down too, and again we still have the problem of not being able to cleanly provide crossgcc tarballs inside release archives. do it in config/submodules, like so: module.list shall say the relative path of a given file, once downloaded, relative to the given source tree. module.cfg shall be re-used, in the same way as for git submodules, but: subfile="url" subfile_bkup="backup url" do this, instead of: subrepo="url" subrepo_bkup="backup url" example entries in module.list: util/crossgcc/tarballs/binutils-2.41.tar.xz util/crossgcc/tarballs/gcc-13.2.0.tar.xz util/crossgcc/tarballs/gmp-6.3.0.tar.xz util/crossgcc/tarballs/mpc-1.3.1.tar.gz util/crossgcc/tarballs/mpfr-4.2.1.tar.xz util/crossgcc/tarballs/nasm-2.16.01.tar.bz2 util/crossgcc/tarballs/R06_28_23.tar.gz the "subrev" variable (in module.cfg) has been renamed to "subhash", so that this makes sense, and that name is common to both subfile/subrepo. the download logic from the vendor scripts has been re-used for this purpose, and it verifies files using sha512sum. therefore: when specifying subrepo(git submodule), subhash will still be a sha1 checksum, but: when specifying subfile(file, e.g. tarball), subhash will be a sha512 checksum the logic for both (subrepo and subfile) is unified, and has this rule: subrepo* and subfile* must never *both* be declared. the actual configuration of coreboot crossgcc tarballs will be done in a follow-up commit. this commit simply modifies the code to accomodate this. over time, this feature could be used for many other files within source trees, and could perhaps be expanded to allow extracting source tarballs in leiu of git repositories, but the latter is not yet required and thus not implemented. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-08 02:01:05 +00:00
done
st="${st# }" && [ "$st" = "repo file" ] && $err "$mdir: repo+file"
git.sh: support downloading *files* as submodules when we download coreboot, we currently don't have a way to download crossgcc tarballs, so we rely on coreboot to do it, which means running the coreboot build system to do it; which means we don't get them in release archives, unless we add very hacky logic (which did exist and was removed). the problem with coreboot's build system is that it does not define backup links for each given tarball, instead relying on gnu.org exclusively, which seems OK at first because the gnu.org links actually return an HTTP 302 response leading to a random mirror, HOWEVER: the gnu.org 302 redirect often fails, and the download fails, causing an error. a mitigation for this has been to patch the coreboot build system to download directly from a single mirror that is reliable (in our case mirrorservice.org). while this mitigation mostly works, it's not redundant; the kent mirror is occasionally down too, and again we still have the problem of not being able to cleanly provide crossgcc tarballs inside release archives. do it in config/submodules, like so: module.list shall say the relative path of a given file, once downloaded, relative to the given source tree. module.cfg shall be re-used, in the same way as for git submodules, but: subfile="url" subfile_bkup="backup url" do this, instead of: subrepo="url" subrepo_bkup="backup url" example entries in module.list: util/crossgcc/tarballs/binutils-2.41.tar.xz util/crossgcc/tarballs/gcc-13.2.0.tar.xz util/crossgcc/tarballs/gmp-6.3.0.tar.xz util/crossgcc/tarballs/mpc-1.3.1.tar.gz util/crossgcc/tarballs/mpfr-4.2.1.tar.xz util/crossgcc/tarballs/nasm-2.16.01.tar.bz2 util/crossgcc/tarballs/R06_28_23.tar.gz the "subrev" variable (in module.cfg) has been renamed to "subhash", so that this makes sense, and that name is common to both subfile/subrepo. the download logic from the vendor scripts has been re-used for this purpose, and it verifies files using sha512sum. therefore: when specifying subrepo(git submodule), subhash will still be a sha1 checksum, but: when specifying subfile(file, e.g. tarball), subhash will be a sha512 checksum the logic for both (subrepo and subfile) is unified, and has this rule: subrepo* and subfile* must never *both* be declared. the actual configuration of coreboot crossgcc tarballs will be done in a follow-up commit. this commit simply modifies the code to accomodate this. over time, this feature could be used for many other files within source trees, and could perhaps be expanded to allow extracting source tarballs in leiu of git repositories, but the latter is not yet required and thus not implemented. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-08 02:01:05 +00:00
[ -z "$st" ] && return 0 # subrepo/subfile not defined
chkvars "sub${st}" "sub${st}_bkup" "subhash"
[ "$st" = "file" ] && download "$subfile" "$subfile_bkup" \
"$tmpgit/$1" "$subhash" && return 0
rm -Rf "$tmpgit/$1" || $err "!rm '$mdir' '$1'"
tmpclone "$subrepo" "$subrepo_bkup" "$tmpgit/$1" "$subhash" \
"$mdir/${1##*/}/patches"
}
tmpclone()
{
git clone $1 "$3" || git clone $2 "$3" || $err "!clone $1 $2 $3 $4 $5"
git -C "$3" reset --hard "$4" || $err "!reset $1 $2 $3 $4 $5"
git_am_patches "$3" "$5"
}
git_am_patches()
{
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
for _patch in "$2/"*; do
[ -L "$_patch" ] || [ ! -f "$_patch" ] || git -C "$1" am \
"$_patch" || $err "$1 $2: !git am $_patch"; continue
done
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
for _patches in "$2/"*; do
[ ! -L "$_patches" ] && [ -d "$_patches" ] && \
git_am_patches "$1" "$_patches"; continue
done
}
link_crossgcc()
{
(
x_ cd "$tmpgit/util" && x_ rm -Rf crossgcc
ln -s "../../$xtree/util/crossgcc" crossgcc || $err "$1: !xgcc link"
) || $err "$1: !xgcc link"
}
move_repo()
{
[ "$1" = "${1%/*}" ] || x_ mkdir -p "${1%/*}"
mv "$tmpgit" "$1" || $err "git_prep: !mv $tmpgit $1"
}
# can delete from multi- and single-tree projects.
# called from script/trees when downloading sources.
nuke()
{
e "config/${1%/}/nuke.list" f missing || while read -r nukefile; do
rmf="src/${2%/}/$nukefile" && [ -L "$rmf" ] && continue
e "$rmf" e missing || rm -Rf "$rmf" || $err "!rm $rmf, ${2%/}"
done < "config/${1%/}/nuke.list"; return 0
}