cbmk/include/git.sh

143 lines
3.8 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 "" loc url bkup_url subfile mdir subhash subrepo subrepo_bkup \
depend subfile_bkup`
fetch_targets()
{
[ -n "$tree_depend" ] && [ "$tree_depend" != "$tree" ] && \
2024-06-29 22:13:55 +00:00
x_ ./update trees -f "$project" "$tree_depend"
e "src/$project/$tree" d && return 0
2024-06-29 22:13:55 +00:00
printf "Creating %s tree %s\n" "$project" "$tree"
git_prep "$loc" "$loc" "$PWD/$configdir/$tree/patches" \
"${loc%/*}/$tree" u; nuke "$project/$tree" "$project/$tree"
}
fetch_project()
{
eval `setvars "" xtree tree_depend`
eval `setcfg "config/git/$project/pkg.cfg"`
chkvars url
[ -n "$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
[ -d "$x" ] && nuke "${x##*/}" "src/${x##*/}" 2>/dev/null
done; return 0
}
clone_project()
{
loc="src/$project/$project" && singletree "$project" && loc="${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
_seval="if [ -n \"\$sub$xt\" ] || [ -n \"\$sub${xt}_bkup\" ]"
eval "$_seval; then st=\"\$st \$xt\"; fi"
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()
{
for p in "$2/"*; do
[ -L "$p" ] && continue; [ -e "$p" ] || continue
[ -d "$p" ] && git_am_patches "$1" "$p" && continue
[ ! -f "$p" ] || git -C "$1" am "$p" || $err "$1 $2: !am $p"
done; return 0
}
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
}