> 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" bra
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 +
> > >
> > 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 unusab
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 ther
> 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 file
> > 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 c
> 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:
> >
> > * R
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
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 directories
> 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
> ha
> 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 i
> > 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 t
> 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 firs
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.
>
> > 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 n
> > 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
> > 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:
> http://lists.openembedded.org/pipermail/openembedde
> > 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
> determi
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 ru
> 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 y
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
> > 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 ca
> 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 o
> > 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 m
> 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
> > 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 main
> 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
reject any problems with the build at that point, so you always have a
nightly that works.
AUTOREV was never meant for the project level, it is a facility strictly for
local development.
Alex
On Thu, 1 Aug 2019 at 18:51, chris.laplante--- via bitbake-devel
mailto:bitbake-de
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 buil
> 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-
> stagi
Hello all,
I have noticed that the "get_recipe_local_files" function of
meta/lib/oe/recipeutils.py doesn't have any kind of logic to handle .scc files.
This means when you try to 'devtool modify' a kernel recipe that uses them,
compilation can fail, for instance if the .scc file includes some c
31 matches
Mail list logo
