[Re: [PATCH RFC 00/21] Git repository sharing for kernel (and other) repos] On
02/04/2021 (Fri 23:14) Richard Purdie wrote:
> On Fri, 2021-04-02 at 13:15 -0400, Paul Gortmaker wrote:
> > Next Steps:
> > ---
> > With this being a functional implementation, it seems like a good time to
> >
Hello,
We are pleased to announce the Yocto Project 3.2.3 (gatesgarth-24.0.3) Release
is now available for download.
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2
A
Hello,
We are pleased to announce the Yocto Project 3.2.3 (gatesgarth-24.0.3) Release
is now available for download.
http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.2.3/poky-gatesgarth-24.0.3.tar.bz2
A
On Fri, 2021-04-02 at 13:15 -0400, Paul Gortmaker wrote:
> Next Steps:
> ---
> With this being a functional implementation, it seems like a good time to
> get other people looking at it. Ideally step #1 will be getting general
> agreement that this is something we need, something that is
i just noticed that both of the layers meta-secure-core and
meta-security:
https://github.com/jiazhang0/meta-secure-core
https://git.yoctoproject.org/cgit/cgit.cgi/meta-security
seem to include a good deal of TPM/TPM2 content ... is there a primary
layer for that stuff?
rday
On Fri, Apr 2, 2021 at 1:16 PM Paul Gortmaker
wrote:
>
> As per the comment in the file itself, we have to explicitly disable
> (pre)mirror support for both kernel repositories, or else the fetcher
> will unhelpfully volunteer to wget gigs of what amounts to largely
> useless content that we
On Fri, Apr 2, 2021 at 1:16 PM Paul Gortmaker
wrote:
>
> The idea for this recipe is to have a name "linux-master" that people
> can depend on as a reference for mainline; today and ideally for as long
> as we are maintaining it. While the recipe is there for everybody,
> the obvious user we are
On Fri, Apr 2, 2021 at 1:16 PM Paul Gortmaker
wrote:
>
> With v5.10 being the newest baseline currently in use by linux-yocto and
> with the download size being 1/2 the size of current linux-yocto itself,
> the v5.10 makes a good initial line in the sand for blocking out the
> source in a way to
The idea for this recipe is to have a name "linux-master" that people
can depend on as a reference for mainline; today and ideally for as long
as we are maintaining it. While the recipe is there for everybody,
the obvious user we are creating this for is the linux-yocto-dev repo.
At some point
At the moment, linux-yocto-dev is set up to reference v5.12-rt:
mainline
---> stable-5.12
---> linux-rt-5.12
---> linux-yocto-dev
We'll probably move to v5.13-rcN in late May and at that point we
can point it at referencing mainline directly
With all the heavy lifting done, all that is needed is to select the
right endpoint for our reference, and the right fetch wildcards to
ensure we only get what we need. We've got:
linux-5.10 (superset contining v5.4)
--> stable-5.4
--> linux-5.4-rt
With all the heavy lifting done, all that is needed is to select the
right endpoint for our reference, and the right fetch wildcards to
ensure we only get what we need. We've got:
linux-5.10
--> stable-5.10
--> linux-5.10-rt
--> linux-yocto_5.10
As per the comment in the file itself, we have to explicitly disable
(pre)mirror support for both kernel repositories, or else the fetcher
will unhelpfully volunteer to wget gigs of what amounts to largely
useless content that we don't want.
Signed-off-by: Paul Gortmaker
---
Note that the v5.12 content currently is in the devel repo and will
eventually get moved over to the stable-rt repo. When that move
happens, we'll need to update the SRC_URI accordingly. [The v5.12-rt
content itself will remain fast-forward with respect to that which is
in devel currently.]
With a split in two done, extending to three is fairly trivial. The
only difference is that the introduced "touch down" point of 4.12 has a
fetch depend/ref itself to the other touch down point of 3.8. The parent
repo (v5.10) has no need of knowledge of what happens prior to 4.12.
One might wonder why there isn't just a stable-5.x to encompass all of
these, but by having them separate, we can retire/EOL them individually
without disruption.
Note that references are a "round up" to the nearest kernel recipe
containing the stable baseline - so stable-5.4 references
With support for sharing packs, we can now optionally split the larger
mainline kernel content up to v5.10 (approx 1.5G) into two. This may be
advantageous to people with release media constraints or unreliable
connections.
By setting "INITIAL_KERNEL_SPLIT = 1" in your configuration, you will
Extending from three to four roughly equal chunks introduces three new
split boundaries - 3.3 4.3 and 4.18, but is trivial to hook in.
This gets chunks down to roughly 1/2G and with the resulting loss of
compression efficiency, it doesn't seem to make sense to support
splitting things any
With v5.10 being the newest baseline currently in use by linux-yocto and
with the download size being 1/2 the size of current linux-yocto itself,
the v5.10 makes a good initial line in the sand for blocking out the
source in a way to optimize sharing.
With this commit present, one can test via
With changes to the fetcher, we now have what we need to download
kernel sources in a way that is forward thinking for sharing and
growth and EOL of components. This will be achieved by "fetch-only"
recipes that only exist to populate chunks of this "library" of source.
We may wish to reconsider
If a clone in the download directory is not static, and was created with
single-branch to avoid additonal unwanted content, then the fetcher will
come along and spoil that effort by unconditonally getting refs/* from
the server and downloading everything available at the server.
To that end,
A new repository that is cloned with "--reference" in turn creates an
objects/info/alternates file in the new repo containing the path back to
the reference repo objects. This is normally a "one-and-done" type
operation and the reference never changes.
However we can envision where a package
Borrowing from "git pack-objects" manpage[1] we have:
A packed archive is an efficient way to transfer a set of objects
between two repositories as well as an access efficient archival
format. In a packed archive, an object is either stored as a
compressed whole or as a difference
Single repositories containing multiple independent origin commits are
becoming more common. For example the rt development repo has patches
as "raw" format-patch output in a patch series, and also for ease of
automated testing, them all pre-applied (ff and non-ff) to the original
baseline
The "packref" support uses symlinks to "piggy-back" use of packs into
the pack namespace of the consumer from the originator (reference repo).
We use symlinks, so that mirror tarballs won't duplicate the referenced
data, as hardlinks would do. However, that means we also assume that
the pack
It is no secret that we've needed to formalize some kind of sensible
sharing between git repos with common ancestry. The opportunity for
sharing the mainline kernel base between linux-yocto and linux-yocto-dev
is the main obvious candidate.
Many of us have long been doing local hacks to
If we know a repository content has what we need, we can flag it as
static and then optimize accordingly for the future, by not trying to do
any fetch operations against it. In a way, this can be thought of as
the special case of GITFETCHREFS = None.
There are multiple advantages to having this.
It doesn't seem that long ago (kernel 3.x era) that the kernel repo was
less than 1G in size, and while it wasn't actively shared, it was kind of
one of those "we'll deal with that later" type things.
But today, where more people care about CI/CD - if you make use of both
linux-yocto and
When you clone with "--single-branch --branch foo" one of two things
will happen:
If foo is a branch upstream you will get a local branch foo and HEAD
will contain "ref: refs/heads/foo". Output from "git branch" will be:
* foo
If foo is a tag upstream, you won't get any local branch,
29 matches
Mail list logo
