On Thu, 29 Feb 2024 at 10:26, Patrick Huesmann wrote:
> Your suggestion will probably get rid of a lot of complexity in our recipe
> that tried to work around bitbake's limitations. But I'm still not sure how
> to tackle the original problem (AUTOINC from PRSERV for file:// and http://
> resour
Thank you, Alex!
Your suggestion will probably get rid of a lot of complexity in our recipe that
tried to work around bitbake's limitations. But I'm still not sure how to
tackle the original problem (AUTOINC from PRSERV for file:// and http://
resources), even if I have SRCREV as static data be
Oh mercy me. Yocto isn't designed for this; everything is assuming
that SRCREV, SRC_URI and PV are static and set in the recipe.
So I would rather implement the logic to determine what they are in an
external script, and run that prior to bitbake. The script would write
the dynamic values into an
Hi Alex,
We have Yocto running on FPGA boards; the Linux images and package feeds
include bitstream files to download into the FPGA.
These bitstreams cannot be built within the Yocto/BitBake system, because they
require special (closed source) build tools, take ages to build, etc.
So they are b
At this point you need to show the recipe. Because I don't understand
how packages can have dedicated source revision, if source revision is
set by the recipe, and is the same for all packages it makes... where
is the problem here?
Alex
On Wed, 28 Feb 2024 at 16:15, wrote:
>
> As far as I can se
As far as I can see, the SRCPV / AUTOINC logic works on a per recipe basis (not
per package), right?
So when my recipe is divided into subpackages with a dedicated source revision
for each, my only choice is to either split it into multiple recipes or use
SRCREV_FORMAT to build a summarized SR
You can check if existing recipes in oe-core get correct PKGV into
package files, there's plenty of them, e.g. xinput-calibrator, or any
other that adds +git to PV (without zero at the end).
Alex
On Wed, 28 Feb 2024 at 14:17, wrote:
>
> Great! This was exactly the bit of information I was missin
Great! This was exactly the bit of information I was missing.
The recipe in question puts a hardcoded "git0" there; I have to make it
interact with PRSERV somehow.
Thanks,
Patrick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62635): https://lis
Note that the package version has 'git0' in it. That zero is supposed
to be filled in by PR server, and if this doesn't happen, something is
misconfigured, or there's a bug.
You can find the code that does this in
meta/classes-global/package.bbclass, particularly look for PKGV
manipulations in pac
PRserv isn't only for incrementing EXTENDPRAUTO, but it should also
increment the LOCALCOUNT (the "0" in "+git0") whenever git sha is
changed to new value not yet recorded in PRserv db.
If this doesn't work, then something isn't configured correctly or
there is a bug.
Cheers,
On Wed, Feb 28, 202
Hi Alex,
I'm using PRSERV and the PR is also incrementing in the example I've shown;
this doesn't help as the PV of the older version is considered newer due to the
commit hash - in this case the PR is never evaluated.
Patrick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to thi
Welcome to PR service which you need to run and use during yocto builds:
https://wiki.yoctoproject.org/wiki/PR_Service
Alex
On Wed, 28 Feb 2024 at 12:56, wrote:
>
> Hi,
>
> I noticed a strange behavior of dnf not updating a package from the package
> feed, and when I told it to explicitly inst
Hi,
I noticed a strange behavior of dnf not updating a package from the package
feed, and when I told it to explicitly install that newest package version it
went "Downgrading: " as if the newest version were a older one.
The "competing" packages were:
foo-bar-1.0.0+git0+93a939c4-r0.24
foo-
13 matches
Mail list logo
