> > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are
> > archived in buildhistory. SRC_URI has many uses and changes and
> > patches can be easily identified. Same with LICENSE, any changes
> > trigger a review. CVE_PRODUCT is exported so that we can do QA check
> > to make sure
> I'd be curious to see the patches.
> It's definitely something we could use here; we used to have nightly
> build checking the build using AUTOREV as well.
>
> On Fri, Aug 2, 2019 at 3:43 AM wrote:
> >
> > Hi,
> >
> > On Thu, Aug 01, 2019 at
> > I think this supports my point about being more interested in patches
> > allowing people to extend/customise buildhistory than just adding X.
> >
> > Whilst we want to have good defaults, there are always going to be
> > niche cases for people wanting to extend it...
>
>
> Agreed. Then we
> > Wouldn't it be a bit overkill to add a new class just to handle SRC_URI? I
> > would think it would just be a little extra code inside
> write_latest_srcrev.
>
> Ordinarily I'd say yes. But RP had concerns that these changes add up and
> unless everyone wants them it could prove to be a
> But I would like something smarter, e.g. first trying to check if the SRC_URI
> is available, if not switching on using the prebuilt package if available
> (e.g.
> in a DIR_PREBUILT)...
>
> Before going further is there already an existing solution for that? do you
> have any recommendation
Hello all,
Most of my team's closed source recipes use something like the following:
SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}"
SRCREV = "${AUTOREV}"
BRANCH ??= "master"
(BRANCH is just a convention we use to make the SRC_URI branch easy to
override.)
This makes nightly
We’re well aware of the limitations and possibility of failed builds, as I said
we hardcode revisions using SRCREV overrides when necessary. It’s been working
well for us so far. So, respectfully, I think that’s not relevant to the
discussion.
Chris
From: Alexander Kanavin
Sent: Thursday,
> I've had some thoughts of capturing that same information, as well as
> automatically generating a changelog (from short-commit entries) from the last
> build to the current one use standard git commands... but I've never had time
> to
> implement anything.
>
> When I talked with RP about this
> From: Richard Purdie
> Sent: Thursday, September 26, 2019 4:53 PM
>
> This has bugged me since we first created multiconfig. It was always
> intended we'd have configs you could reference. It turned out to be
> hard to code and we (well, I) decided to "come back to it". That hasn't
> happened
Hello,
Thanks to Richard and others recent hard work, multiconfig is poised to become
much more practical in YP 3.0.
One thing I'm not clear on, however, is how it will work in a team environment.
If I have recipes with multiconfig dependencies, then I must ensure that anyone
else using those
> DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux-
> gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
> returning
> https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-
>
Hello all,
I'm encountering a failure like below when using hashequiv. What is happening
is recipe "A" is installing some files in do_install, and changing the group of
those files. The group is defined by a different recipe ("B"). There is no
dependency between A and B, so when A:do_package
> > A workaround is to add:
> > DEPENDS += "B"
> > to recipe A, so that the group ends up in A's pseudo database. This
> > works, but seems really really hacky, since it's only necessary when
> > hashequiv is active.
>
> I suspect this isn't a hack, but necessary and you're finding a
>
> > So why is the group name used in the hash, as opposed to the GID? (I also
> > have the same question regarding user name vs UID). If
> the GID was used we wouldn't have this issue.
>
> That was done in response to this mailing list thread:
>
> > On the contrary. For almost all practical use cases you care about what
> > user/group owns a file, not what UID/GID they happen to be. E.g., in the
> > recipe (or Makefile or whatever) you typically want to specify that a
> > file shall be owned by user foo, not UID 1234. Then, either you do
> > From a caching point of view, it seems incorrect to care about what the
> > corresponding group name happened to be at the time when the cache was
> > created.
>
> On the contrary. For almost all practical use cases you care about what
> user/group owns a file, not what UID/GID they happen to
Hi Richard,
> > > Anecdotally, we are running Zeus for nightly builds with three
> > > multiconfigs. I cherry-picked your "bitbake: fix2" and "bitbake:
> > > fixup" patches and haven't seen any of the BB_UNIHASH errors since.
> > > Granted it's only been a week. But before that, hash equiv +
> >
> One is occasionally I get a lot of undeterministic metadata errors when
> BB_CACHE_POLICY = "cache", multiconfig, and hash equiv are
> enabled. The errors are all on recipes for which SRCREV = "${AUTOREV}". It
> doesn't always happen. But it did just now when I rebased
> our "zeus-modified"
Hi all,
For about two years now, we have been using Emscripten together with Yocto, via
an emscripten.bbclass that I wrote. In a nutshell, it works by conducting the
actual build in a Docker container, whose image is where Emscripten is actually
installed. I mount all the necessary
Hi Richard,
> On Fri, 2020-02-07 at 08:16 +, Alex Kiernan wrote:
> > Hi
> >
> > We've got a couple of multiconfig builds with different
> > configurations in one bitbake run (whether it needs to be like this a
> > different question - I suspect we had something that worked and
> > stopped
> > Anecdotally, we are running Zeus for nightly builds with three
> > multiconfigs. I cherry-picked your "bitbake: fix2" and "bitbake:
> > fixup" patches and haven't seen any of the BB_UNIHASH errors since.
> > Granted it's only been a week. But before that, hash equiv +
> > multiconfig was
> From: LAPLANTE,CHRIS (Agilent USA)
> Sent: Thursday, January 16, 2020 3:21 PM
> To: Pascal Huerst ; Richard Purdie
> ; openembedded-
> c...@lists.openembedded.org
> Cc: Rich Persaud
> Subject: RE: [OE-core] Looking for a way to build latest tagged releases in
> recipes
>
> > TODO:
> >
> > *
> > To be honest, I'm not completely sure. I based this class off of
> > native.bbclass and nativesdk.bbclass and they both do it. I have
> > little idea what stamp-extra-info actually does.
>
> My suggestion is not to do that. native and to a lesser extent
> nativesdk are "special" in ways your
Hi Richard,
> > I have a few concerns/questions:
> > [a] Is the basic premise of a custom CLASSOVERRIDE supported by
> > Yocto? Our situation seems a bit weird, because our emscripten
> > recipes are still sort of “target” recipes, so I feel a bit funny
> > completely wiping CLASSOVERRIDE.
>
> I
> Hmm, removing the stamp-extra-info lines leaves me with errors like these:
>
> ERROR: mc:mc-name:library-emscripten-1.0+gitAUTOINC+ab6d30c10c-r0
> do_packagedata_setscene: The recipe library-emscripten is
> trying to install files into a shared area when those files already exist.
> Those
> I've gone back and forth and re-implemented the code to do so a half dozen
> times. Chronologically, these are the fundamental
> strategies I've attempted:
>
> 1. Simply in terms of buildhistory-collect-srcrevs.
> Pros: dead simple
> Cons: requires that you actually build stuff
> Cross the first TODO off the list:
> https://gist.github.com/mostthingsweb/39e24b329de70c0212e5bf21a431e143/8d1a5f51b3c0bf260c730ed5716d9807c78335b8
>
> (BTW eventually I will move this to poky-contrib; gist is just more
> convenient for me for the short term. If there's a desire for it to
>
Hi Richard,
> FWIW I do want to see the system used to do things like this. I've kind
> of envisaged you'd do it "up front" though. For example it should be
> trivial for a script to use tinfoil, iterate through and generate an
> include file of the revisions you want, using the fetcher calls.
>
> TODO:
>
> * Right now, the class triggers a base environment change every time, which
> means BitBake always reparses every recipe. I guess this
> is because I'm modifying the datastore when I get bb.event.ConfigParsed and
> bb.event.MultiConfigParsed, in order to ensure
> REVRECORD_DATETIME
> > As mentioned in IRC, as I get deeper into it, I'll be going with approach
> > #3 after all :/. Hope to post a tinfoil script soon.
>
> That would be very much appreciated!
Here's a prototype bbclass:
https://gist.github.com/mostthingsweb/39e24b329de70c0212e5bf21a431e143. Please
give it a
30 matches
Mail list logo
