> -----Original Message-----
> From: Richard Purdie <[email protected]>
> Sent: den 16 augusti 2023 13:13
> To: Peter Kjellerstedt <[email protected]>;
> openembedded-architecture <[email protected]>
> Subject: Re: [Openembedded-architecture] Workflow improvements - incremental
> source updates?
>
> On Tue, 2023-08-15 at 21:27 +0000, Peter Kjellerstedt wrote:
> >
> > I decided to give the related changes you have in master-next a try. I
> > cherry-picked the following three commits:
> >
> > bitbake: fetch2: Add new srcrev fetcher API
> > recipes/classes/scripts: Drop SRCPV usage in OE-Core
> > base/package: Move source revision information from PV to PKGV
[cut]
> > One thing that I would prefer is if there is a variable, similar to
> > the old SRCPV, that contains "${@bb.fetch.get_pkgv_string(d)}" by
> > default and is used from package_convert_pr_autoinc() instead of
> > calling the method directly. The reason for that is to make it
> > possible to use a different method to determine the value. E.g., in
> > our case we have a variable called MAINTPV, which is similar to
> > SRCPV. The reason for it is that it handles Gerrit references and
> > expands them in a more suitable way than just a SHA-1. Thus I would
> > like to be able to use its underlying function instead of
> > bb.fetch.get_pkgv_string(d) to generate the string for PKGV.
[cut]
> I was thinking more about the "in a variable" request and there is a
> good reason for not doing it.
I think we can live without it. If I am not mistaken we can always
inject our extra information by doing something like
PKGV:append = "${MAINTPV}" in recipes where we need it and then rely on
your code to add the SHA-1 if the output from ${MAINTPV} includes a "+".
> I'm deliberately trying to avoid putting
> the function call into a variable as it then becomes part of the task
> hash computations. This means there are calls into it during parsing
> rather than at runtime. That was part of the pain in the previous
> approach and something I'm keen to avoid this time around to simplify
> things if we can. It does get included in the taskhashes after the
> changes but at points we control (vardepvalue) rather than 'random'
> expansion points of a common variable like PV during parsing.
I am a bit unsure about the trying to avoid calls to the get_pkgv_string()
function during parsing, because it seems to happen with the current
code. When I first added your changes, I got errors for a number of
recipes in meta-oe that failed to set SRCREV_FORMAT (Khem has since
corrected those recipes). E.g., if you add meta-oe to the build and
revert commit 4228656bae, then you will get the following error if
you run `bitbake -p`:
WARNING: .../meta-oe/recipes-extended/sysdig/sysdig_0.28.0.bb: Exception during
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-oe/recipes-extended/sysdig/sysdig_0.28.0.bb: Error during
finalise of
/home/pkj/dists/poky-master/meta-oe/recipes-extended/sysdig/sysig_0.28.0.bb
ERROR: ExpansionError during parsing
.../meta-oe/recipes-extended/sysdig/sysdig_0.28.0.bb
This is causing problems for me in our code base because we have a
number of recipes that fetch from Git repositories with restricted
access that I cannot fetch (we have alternative recipes that install
prebuilt binaries for those of us without access to the source code).
Now all those recipes fail during parsing because bitbake cannot run
`git ls-remote`, even if they will never be built in my builds.
> If we did need control the use of it, we'd have to use some other
> variable to control it rather than the older approach. We then come
> back to my other feeling of wanting to get it right so people don't
> need to change it.
>
> Cheers,
>
> Richard
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1738):
https://lists.openembedded.org/g/openembedded-architecture/message/1738
Mute This Topic: https://lists.openembedded.org/mt/100618420/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
