On 02.02.23 15:27, Greg KH wrote: > On Thu, Feb 02, 2023 at 12:15:36PM +0100, Linux kernel regression tracking (Thorsten Leemhuis) wrote: >> [adding Konstantin and Greg to the list of recipients] >> >> On 01.02.23 12:52, Thorsten Leemhuis wrote: >>> Add a text explaining how to quickly build a kernel, as that's something >>> users will often have to do when they want to report an issue or test >>> proposed fixes. This is a huge and frightening task for quite a few >>> users these days, as many rely on pre-compiled kernels and have never >>> built their own. They find help on quite a few websites explaining the >>> process in various ways, but those howtos often omit important details >>> or make things too hard for the 'quickly build just for testing' case >>> that 'localmodconfig' is really useful for. Hence give users something >>> at hand to guide them, as that makes it easier for them to help with >>> testing, debugging, and fixing the kernel. >> >> Side note: after feedback on social media I'll likely switch to a title >> like "how to quickly configure & build a trimmed-down Linux kernel", as >> some people from the current title assumed this would be about things >> like ccache. I'll also likely will switch to using a localversion file >> in the buildroot instead of modifying the EXTRAVERSION in the top-level >> makefile (but I haven't actually tried it yet). >> >>> [...] >>> >>> The text currently describes two approaches to retrieve Linux' sources >>> using git: the regular clone with linux-stable as a remote and a shallow >>> clone with just one branch from linux-stable. The shallow clone approach >>> is a little bit more tricky to describe and handle, but downloads way >>> less data – and thus is a lot quicker, unless you have a really really >>> quick link to the internet (which in some parts of the world is hard to >>> come by). That's why I wonder if the text should switch to making the >>> shallow clone with selected stable branches the default. What do you >>> think, dear reader? >> >> So, I looked into what Greg suggested (e.g. >> https://kernel.org/best-way-to-do-linux-clones-for-your-ci.html and >> https://www.kernel.org/cloning-linux-from-a-bundle.html >> ). Assuming users have a up2date git (afaics 2.38+) I could use commands >> like this in my text: >> >> curl -L >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle >> -o ~/linux/linux-stable.git.bundle >> git clone --bundle-uri=linux-stable.git.bundle >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git >> ~/linux/sources >> rm ~/linux/linix-stable.git.bundle >> >> This took roundabout 16 minutes with my 100 Mbit cable internet >> connection (~9 min for the download, 7 for the clone [the machine used >> is somewhat old]) and downloads & stores ~4,5 GByte data (without checkout). >> >> [side note: using >> "--bundle-uri=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle"; >> does not work (due to the redirect? whatever) -- but that might be >> unwise anyway in case the download is interrupted] >> >> >> Then I tried creating a shallow clone like this: >> >> git clone >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> --depth 1 -b v6.1 >> git remote set-branches --add origin master >> git fetch --all --shallow-exclude=v6.1 >> git remote add -t linux-6.1.y linux-stable >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git >> git fetch --all --shallow-exclude=v6.1 >> >> This took only roundabout 2 minutes and downloads & stores ~512 MByte >> data (without checkout). >> >> >> Not totally sure, but the shallow clone somehow feels more appropriate >> for the use case (reminder, there is a "quickly" in the document title), >> even if such a clone is less flexible (e.g. users have to manually add >> stable branches they are interested it; and they need to be careful when >> using git fetch). >> >> That's why I now strongly consider using the shallow clone method by >> default in v2 of this text. Or does that also create a lot of load on >> the servers? Or are there other strong reason why using a shallow clone >> might be a bad idea for this use case? > > I think Konstantin answered your question already on a social network > based on the server load question. Yup, he did. For the record, this is what he wrote: ``` it [a shallow clone] is pretty expensive on the server side, but it is only really a problem when a bunch of shallow clones are performed at once (e.g. when a CI farm does it across 50 nodes or something). When that happens, it overwhelms the server. If an actual human being does a single shallow clone it's not a big deal. ``` > For the "will this work for testing", sure, a shallow clone should work > just fine, if no one has to use 'git bisect' to go back further than the > version you originally clone. Hopefully that's not a normal thing. Yeah, that's something I have in mind already. But seems it's not much of a problem, as one apparently can access older versions (including tags) by deepening a shallow clone with a command like "git fetch origin --shallow-exclude=v5.19" these days. Ciao, Thorsten
