FWIW: for webOS we're using "enhanced submissions" for components we own: https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_enhanced_submissions.bbclass https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_submissions.bbclass
which means that instead PV variables we define WEBOS_VERSION like: WEBOS_VERSION = "3.0.0-3_1b978a6d3989a851561baec3ec60082052029f13" Where "3.0.0-3" is set as always increasing PV (without having to deal with AUTOINC/SRCPV). "1b978a6d3989a851561baec3ec60082052029f13" is set to regular SRCREV "3.0.0" is WEBOS_COMPONENT_VERSION which is in some cases (cmake builds currently) checks that the value matches with the version in CMakeLists.txt (we have https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/cmake-modules-webos/cmake-modules-webos-native.bb with common macros for this) and the "3" is WEBOS_SUBMISSION. The bbclass then validates (as do_unpack[postfuncs]) that there is submissions/${WEBOS_SUBMISSION} tag which is annotated and that the SRCREV points to it. This works nicely, without having to deal with BB_SRCREV_POLICY. On Sun, Feb 16, 2020 at 1:22 PM Peter Kjellerstedt < [email protected]> wrote: > We use tags in SRCREV for our own recipes since we have control over them > and know that the tags won’t move. If one sets BB_SRCREV_POLICY = "cache", > then bitbake will not do `git ls-remote` for the tags more than once. So as > long as you have built once you can then build again without network. > (Setting BB_SRCREV_POLICY = "cache" currently breaks ${AUTOREV}, but I sent > patches for that the other day.) > > > > //Peter > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Martin Jansa > *Sent:* den 15 februari 2020 18:39 > *To:* Rudolf J Streif <[email protected]> > *Cc:* [email protected]; Yocto discussion list <[email protected] > > > *Subject:* Re: [yocto] does git SRC_URI really *require" a SRCREV setting? > > > > Both recipes should be updated to use SRCREV like any other recipe, I'll > send patch for that. > > > > The documentation should also mention that using tag names in SRCREV (or > tag parameter) is not recommended, because tags can be moved and bitbake > will always use "git ls-remote" to map the tag name to actual git sha, > which needs to upstream repo to be available (breaking the builds without > access to the network). > > > > On Sat, Feb 15, 2020 at 6:33 PM Rudolf J Streif <[email protected]> > wrote: > > The wording might need improvement but both of your examples actually do > provide SRC_REV but in the inline form with SRC_URI (rev/tag). > > The documentation should probably say something like SRC_REV needs to be > provided but it can either be done by setting the variable explicitly or by > using the rev/tag option with SRC_URI. > > :rjs > > On 2/14/20 10:35 PM, [email protected] wrote: > > yes, yes, more obsessive-compulsive nitpickery, but YP dev tasks > > manual, section 3.3.5, reads: > > > > "Another way of specifying source is from an SCM. For Git > > repositories, you must specify SRCREV and you should specify PV to > > include the revision with SRCPV." > > > > you *must* specify SRCREV? i don't think that's true -- a couple > > examples from meta-oe ... here's hiredis_0.13.1.bb: > > > > SRC_URI = > "git://github.com/redis/hiredis;protocol=git;rev=f58dd249d6ed47a7e835463c3b04722972281dbb > \ > > > > and here's sshfs-fuse_2.8.bb: > > > > SRC_URI = > "git://github.com/libfuse/sshfs;tag=b2fa7593586b141298e6159f40f521d2b0f4f894 \ > > > > neither of which specify SRCREV (clearly since they don't need to > > given the SRC_URI options in use). > > > > rday > > > > p.s. bitbake's git.py fetcher code makes no mention of the "rev" > > option in its opening docstring. just an observation if anyone wants > > to tweak that. > > > > > > -- > > ----- > > Rudolf J Streif > > CEO/CTO ibeeto > > +1.855.442.3386 x700 > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48440): https://lists.yoctoproject.org/g/yocto/message/48440 Mute This Topic: https://lists.yoctoproject.org/mt/71294406/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
