[PATCH] autoconf-doc: improve reproducibility

[PATCH] autoconf-doc: improve reproducibility

[Juro Bystricky]

autoconf-doc package contains autoconf.info.
This file contains date when this file was created, i.e:

     "This manual (31 January 2018) .."

Therefore, two builds done on two different days will show different dates for
otherwise identical files, hence breaking reproducibility.
The date is obtained from mtime of "autoconf.texi", unfortunately we patch this
file and change the mtime as a consequence.
The date serves as a document version identifier, so preserving the original mtime of
"autoconf.texi" would be misleading, as we actually did modify the document on purpose.
The fix is to set the mtime of "autoconf.texi" based on SOURCE_DATE_EPOCH.

[YOCTO #12524]

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
 meta/recipes-devtools/autoconf/autoconf.inc | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-devtools/autoconf/autoconf.inc b/meta/recipes-devtools/autoconf/autoconf.inc
index df81bc6..f5156f7 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -48,6 +48,15 @@ do_configure() {
 	oe_runconf
 }
 
+do_compile_prepend_class-target() {
+	# mtime of autoconf.texi will end up as embedded date in autoconf.info.
+	# We patch autoconf.texi, so that modifies mtime each time.
+	# To ensure reproducibility, set the mtime to SOURCE_DATE_EPOCH
+	if [ -n "${SOURCE_DATE_EPOCH}" ]; then
+		touch -d @${SOURCE_DATE_EPOCH} ${S}/doc/autoconf.texi
+	fi
+}
+
 do_install_append() {
     rm -rf ${D}${datadir}/emacs
 }
-- 
2.7.4

Re: [PATCH] autoconf-doc: improve reproducibility

[Burton, Ross]

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

A neater fix might be to drop the documentation change from the patch we're
applying, as it's unlikely that people will be reading the autoconf
documentation.

Ross

On 7 February 2018 at 01:42, Juro Bystricky <juro.bystricky@intel.com>
wrote:

> autoconf-doc package contains autoconf.info.
> This file contains date when this file was created, i.e:
>
>      "This manual (31 January 2018) .."
>
> Therefore, two builds done on two different days will show different dates
> for
> otherwise identical files, hence breaking reproducibility.
> The date is obtained from mtime of "autoconf.texi", unfortunately we patch
> this
> file and change the mtime as a consequence.
> The date serves as a document version identifier, so preserving the
> original mtime of
> "autoconf.texi" would be misleading, as we actually did modify the
> document on purpose.
> The fix is to set the mtime of "autoconf.texi" based on SOURCE_DATE_EPOCH.
>
> [YOCTO #12524]
>
> Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
> ---
>  meta/recipes-devtools/autoconf/autoconf.inc | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/meta/recipes-devtools/autoconf/autoconf.inc
> b/meta/recipes-devtools/autoconf/autoconf.inc
> index df81bc6..f5156f7 100644
> --- a/meta/recipes-devtools/autoconf/autoconf.inc
> +++ b/meta/recipes-devtools/autoconf/autoconf.inc
> @@ -48,6 +48,15 @@ do_configure() {
>         oe_runconf
>  }
>
> +do_compile_prepend_class-target() {
> +       # mtime of autoconf.texi will end up as embedded date in
> autoconf.info.
> +       # We patch autoconf.texi, so that modifies mtime each time.
> +       # To ensure reproducibility, set the mtime to SOURCE_DATE_EPOCH
> +       if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> +               touch -d @${SOURCE_DATE_EPOCH} ${S}/doc/autoconf.texi
> +       fi
> +}
> +
>  do_install_append() {
>      rm -rf ${D}${datadir}/emacs
>  }
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

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

Re: [PATCH] autoconf-doc: improve reproducibility

[Bystricky, Juro]

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



> A neater fix might be to drop the documentation change from the patch we're applying, as it's unlikely that people will be reading the autoconf documentation.

Yes, I agree. That was my first thought, too. The less patches the better.  I'll send a v2 of the patch to the ML and gauge the reaction.

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