[yocto] Detecting all AUTOREV usages in a build, for reproducible stable production builds.

[Paul Knopf]

That is EXACTLY what I am looking for. Thanks!

A "nice to have" would be a check to see if any AUTOREVs has snuck in since
last srcrev.conf generation. I'd like to validate/ensure this with a build
task on the build server.

On Thu, Nov 16, 2017 at 10:18 AM Leonardo Sandoval <
leonardo.sandoval.gonzalez at linux.intel.com> wrote:

> On Thu, 16 Nov 2017 05:06:30 -0500
> Paul Knopf <pauldotknopf at gmail.com> wrote:
>
> > I want to store/fix AUTOREV values for production builds. I saw
> > BB_CACHE_POLICY, but the format (sqllite) isn't something that can be
> > checked in.
> >
> > Let's say I have an image:
> >
> > bitbake my-image
> >
> > How do I detect any dependency that is using AUTOREV?
> >
>
>
> would this tool be useful for your needs? I do not fully grasp what you
> want to do.
>
>
> ----
> You can use the buildhistory-collect-srcrevs command with the -a option to
> collect the stored SRCREV values from build history and report them in a
> format suitable for use in global
> configuration (e.g., local.conf or a distro include file) to override
> floating AUTOREV values to a fixed set of revisions. Here is some example
> output from this command:
>
>
>      $ buildhistory-collect-srcrevs -a
>      # i586-poky-linux
>      SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
>      SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
>      SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
>      SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
>      # x86_64-linux
>      SRCREV_pn-gtk-doc-stub-native =
> "1dea266593edb766d6d898c79451ef193eb17cfa"
>      SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
>      SRCREV_pn-update-rc.d-native =
> "eca680ddf28d024954895f59a241a622dd575c11"
>      SRCREV_glibc_pn-cross-localedef-native =
> "b8079dd0d360648e4e8de48656c5c38972621072"
>      SRCREV_localedef_pn-cross-localedef-native =
> "c833367348d39dad7ba018990bfdaffaec8e9ed3"
>      SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
>      SRCREV_pn-opkg-utils-native =
> "53274f087565fd45d8452c5367997ba6a682a37a"
>      SRCREV_pn-kern-tools-native =
> "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
>      SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
>      # qemux86-poky-linux
>      SRCREV_machine_pn-linux-yocto =
> "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
>      SRCREV_meta_pn-linux-yocto =
> "a227f20eff056e511d504b2e490f3774ab260d6f"
>      # all-poky-linux
>      SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
>
> Note
> -----
>
>
>
>
> > I'd like to generate a dynamic.conf file that fixes the SRCREV values for
> > relevant packages.
> >
> > I guess I could do a normal build, then read the sqllite database, and
> > generate a .conf from it. Does this sound feasible?
> >
> > Any other strategies?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171116/4172e91b/attachment.html>