summaryrefslogtreecommitdiff
path: root/config/submodule/grub/nvme
AgeCommit message (Collapse)Author
2026-02-01GRUB: don't download po files in bootstrapLeah Rowe
The files it downloads are not versioned, and they could change any time. GRUB has no way to deterministically grab these. I've removed GRUB's local for grabbing these, instead mirroring them myself and checking hashes; no hashes seem to have been provided by the upstream at Translation Project, so I just used the hashes I had on the files it had, when I downloaded them. From now on, I can just re-download these and re-calculate the hashes as desired, over time, when updating GRUB revisions. Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-09-07Revert "change grub git again"Leah Rowe
This reverts commit 1e07c4eb02da5c51d5278583b2a3e2de551f2a62.
2025-09-07change grub git againLeah Rowe
this time to source hut. for some reason, *grub* is slow no matter what repo provider i host it on?? i tested srht just now, and it seems ok. let's use that. i'm *paying* for this sourcehut account, so it better be good! Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-05-14get.sh: simplify fetch_submodules()Leah Rowe
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>
2025-01-03submodule/grub: use codeberg for 1st gnulib mirrorLeah Rowe
the gnu.org mirror is always slow for some reason, but only for gnulib. it may only be for me, because routing in other countries/networks may differ. when i'm freshly cloning lbmk modules, gnulib is always really slow, like 300KB/s (bytes, not bits) i have 1gbps internet and wish to not have 2005-era speeds, thank you kindly! Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-27add spdx headers to various config filesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12grub: only enable nvme if needed on a boardLeah Rowe
remove nvme support from the "default" grub tree now there are three trees: * default: no xhci or nvme patches * nvme: contains nvme support * xhci: contains xhci and nvme support this is in case a bug like lbmk issue #216 ever occurs again, as referenced before during lbmk audit 5 there is no indication that the nvme patch causes any issues, but after previous experience i want to be sure Signed-off-by: Leah Rowe <leah@libreboot.org>