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

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

[Paul Knopf]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

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?

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?

[-- Attachment #2: Type: text/html, Size: 666 bytes --]

Re: Detecting all AUTOREV usages in a build, for reproducible stable production builds.

[Leonardo Sandoval]

On Thu, 16 Nov 2017 05:06:30 -0500
Paul Knopf <pauldotknopf@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?

Re: Detecting all AUTOREV usages in a build, for reproducible stable production builds.

[Paul Knopf]

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

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@linux.intel.com> wrote:

> On Thu, 16 Nov 2017 05:06:30 -0500
> Paul Knopf <pauldotknopf@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?
>

[-- Attachment #2: Type: text/html, Size: 3682 bytes --]