[ptxdist] [PATCH 0/3] Minor build improvements

[ptxdist] [PATCH 0/3] Minor build improvements

[Alexander Dahl]

Hei hei,

small series of three patches. 

1. The patch for the opkg package addresses a thing which annoyed me
   for years when using opkg packages. O:-)

2. The second and third patch replaces the dates put into
   '/etc/os-release' and '/etc/issue' by reproducible ones. I just
   searched for invocations of `date` in make rules and fixed those two.
   There's at least one other related to rauc, which I could not test
   easily, so I skipped that one.

Greets
Alex

Alexander Dahl (3):
  opkg: Regenerate config after input variable changes
  os-release: Make date string reproducible
  rootfs: issue: Make date string reproducible

 rules/opkg.make       | 14 ++++++++++++++
 rules/os-release.make |  2 +-
 rules/rootfs.make     |  2 +-
 3 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 1/3] opkg: Regenerate config after input variable changes

[Alexander Dahl]

Some values in `/etc/opkg/opkg.conf` are replaced by 'install_replace'
in targetinstall stage. Especially PTXCONF_OPKG_OPKG_CONF_URL can
contain other variables which might change frequently when developing.
The default for example contains PTXCONF_PROJECT_VERSION which changes
with every git commit. The place where opkg packages are put to on the
dev host would differ then from the opkg.conf on the target. Trigger a
rebuild of the targetinstall stage keeps that in sync.

Signed-off-by: Alexander Dahl <ada@thorsis.com>
---
 rules/opkg.make | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/rules/opkg.make b/rules/opkg.make
index 23390ce0f..2396853fe 100644
--- a/rules/opkg.make
+++ b/rules/opkg.make
@@ -53,6 +53,17 @@ OPKG_CONF_OPT	:= \
 # Target-Install
 # ----------------------------------------------------------------------------
 
+ifdef PTXCONF_OPKG_OPKG_CONF
+OPKG_STAMP := $(call remove_quotes, \
+	$(PTXCONF_OPKG_OPKG_CONF_URL) \
+	$(PTXDIST_IPKG_ARCH_STRING) \
+	$(PTXCONF_OPKG_OPKG_CONF_CHECKSIG))
+
+ifneq ($(strip $(OPKG_STAMP)),$(strip $(call ptx/force-sh cat $(STATEDIR)/opkg.stamp 2>/dev/null)))
+PHONY += $(STATEDIR)/opkg.targetinstall
+endif
+endif
+
 $(STATEDIR)/opkg.targetinstall:
 	@$(call targetinfo)
 
@@ -104,6 +115,9 @@ endif
 
 	@$(call install_finish, opkg)
 
+ifdef PTXCONF_OPKG_OPKG_CONF
+	@echo "$(OPKG_STAMP)" > $(STATEDIR)/opkg.stamp
+endif
 	@$(call touch)
 
 # vim: syntax=make
-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 1/3] opkg: Regenerate config after input variable changes

[Michael Olbrich]

On Thu, Feb 27, 2020 at 03:44:47PM +0100, Alexander Dahl wrote:
> Some values in `/etc/opkg/opkg.conf` are replaced by 'install_replace'
> in targetinstall stage. Especially PTXCONF_OPKG_OPKG_CONF_URL can
> contain other variables which might change frequently when developing.

Right, this is a problem for other packages as well. The more general fix
ist to hash the evaluated PTXCONF_* variables instead. I've implemented
this here. It should hit master once all my test have passed. But maybe
only for the April release.

Michael

> The default for example contains PTXCONF_PROJECT_VERSION which changes
> with every git commit. The place where opkg packages are put to on the
> dev host would differ then from the opkg.conf on the target. Trigger a
> rebuild of the targetinstall stage keeps that in sync.
> 
> Signed-off-by: Alexander Dahl <ada@thorsis.com>
> ---
>  rules/opkg.make | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/rules/opkg.make b/rules/opkg.make
> index 23390ce0f..2396853fe 100644
> --- a/rules/opkg.make
> +++ b/rules/opkg.make
> @@ -53,6 +53,17 @@ OPKG_CONF_OPT	:= \
>  # Target-Install
>  # ----------------------------------------------------------------------------
>  
> +ifdef PTXCONF_OPKG_OPKG_CONF
> +OPKG_STAMP := $(call remove_quotes, \
> +	$(PTXCONF_OPKG_OPKG_CONF_URL) \
> +	$(PTXDIST_IPKG_ARCH_STRING) \
> +	$(PTXCONF_OPKG_OPKG_CONF_CHECKSIG))
> +
> +ifneq ($(strip $(OPKG_STAMP)),$(strip $(call ptx/force-sh cat $(STATEDIR)/opkg.stamp 2>/dev/null)))
> +PHONY += $(STATEDIR)/opkg.targetinstall
> +endif
> +endif
> +
>  $(STATEDIR)/opkg.targetinstall:
>  	@$(call targetinfo)
>  
> @@ -104,6 +115,9 @@ endif
>  
>  	@$(call install_finish, opkg)
>  
> +ifdef PTXCONF_OPKG_OPKG_CONF
> +	@echo "$(OPKG_STAMP)" > $(STATEDIR)/opkg.stamp
> +endif
>  	@$(call touch)
>  
>  # vim: syntax=make
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 1/3] opkg: Regenerate config after input variable changes

[Michael Olbrich]

On Fri, Mar 20, 2020 at 12:31:05PM +0100, Michael Olbrich wrote:
> On Thu, Feb 27, 2020 at 03:44:47PM +0100, Alexander Dahl wrote:
> > Some values in `/etc/opkg/opkg.conf` are replaced by 'install_replace'
> > in targetinstall stage. Especially PTXCONF_OPKG_OPKG_CONF_URL can
> > contain other variables which might change frequently when developing.
> 
> Right, this is a problem for other packages as well. The more general fix
> ist to hash the evaluated PTXCONF_* variables instead. I've implemented
> this here. It should hit master once all my test have passed. But maybe
> only for the April release.

FYI, master should handle this correctly now.

Michael

> > The default for example contains PTXCONF_PROJECT_VERSION which changes
> > with every git commit. The place where opkg packages are put to on the
> > dev host would differ then from the opkg.conf on the target. Trigger a
> > rebuild of the targetinstall stage keeps that in sync.
> > 
> > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> > ---
> >  rules/opkg.make | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/rules/opkg.make b/rules/opkg.make
> > index 23390ce0f..2396853fe 100644
> > --- a/rules/opkg.make
> > +++ b/rules/opkg.make
> > @@ -53,6 +53,17 @@ OPKG_CONF_OPT	:= \
> >  # Target-Install
> >  # ----------------------------------------------------------------------------
> >  
> > +ifdef PTXCONF_OPKG_OPKG_CONF
> > +OPKG_STAMP := $(call remove_quotes, \
> > +	$(PTXCONF_OPKG_OPKG_CONF_URL) \
> > +	$(PTXDIST_IPKG_ARCH_STRING) \
> > +	$(PTXCONF_OPKG_OPKG_CONF_CHECKSIG))
> > +
> > +ifneq ($(strip $(OPKG_STAMP)),$(strip $(call ptx/force-sh cat $(STATEDIR)/opkg.stamp 2>/dev/null)))
> > +PHONY += $(STATEDIR)/opkg.targetinstall
> > +endif
> > +endif
> > +
> >  $(STATEDIR)/opkg.targetinstall:
> >  	@$(call targetinfo)
> >  
> > @@ -104,6 +115,9 @@ endif
> >  
> >  	@$(call install_finish, opkg)
> >  
> > +ifdef PTXCONF_OPKG_OPKG_CONF
> > +	@echo "$(OPKG_STAMP)" > $(STATEDIR)/opkg.stamp
> > +endif
> >  	@$(call touch)
> >  
> >  # vim: syntax=make
> > -- 
> > 2.20.1
> > 
> > 
> > _______________________________________________
> > ptxdist mailing list
> > ptxdist@pengutronix.de
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Alexander Dahl]

Signed-off-by: Alexander Dahl <ada@thorsis.com>
---
 rules/os-release.make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/os-release.make b/rules/os-release.make
index 5156156a0..ba607aa38 100644
--- a/rules/os-release.make
+++ b/rules/os-release.make
@@ -56,7 +56,7 @@ $(STATEDIR)/os-release.targetinstall: $(PTXDIST_PTXCONFIG) $(PTXDIST_PLATFORMCON
 		@PTXDIST_VERSION@, $(PTXDIST_VERSION_FULL))
 
 	@$(call install_replace, os-release, /usr/lib/os-release, \
-		@DATE@, $(shell date +%FT%T%z))
+		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
 
 	@$(call install_link, os-release, ../usr/lib/os-release, \
 		/etc/os-release)
-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Roland Hieber]

On Thu, Feb 27, 2020 at 03:44:48PM +0100, Alexander Dahl wrote:
> Signed-off-by: Alexander Dahl <ada@thorsis.com>
> ---
>  rules/os-release.make | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rules/os-release.make b/rules/os-release.make
> index 5156156a0..ba607aa38 100644
> --- a/rules/os-release.make
> +++ b/rules/os-release.make
> @@ -56,7 +56,7 @@ $(STATEDIR)/os-release.targetinstall: $(PTXDIST_PTXCONFIG) $(PTXDIST_PLATFORMCON
>  		@PTXDIST_VERSION@, $(PTXDIST_VERSION_FULL))
>  
>  	@$(call install_replace, os-release, /usr/lib/os-release, \
> -		@DATE@, $(shell date +%FT%T%z))
> +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))

This sets PTXDIST_BUILD_DATE. I think SOURCE_DATE_EPOCH was not used
here deliberately, otherwise the date would always be the same, and
what's the use of the variable then?

Which leads to the question: why is there a date at all here, and what
useful additional information does it provide? The only thing I've come
up with so far is that it acts as a monotonically increasing version
number for the image, so you can compare images in terms of recency.
Therefore this date should be as new as possible. On the other hand it
should be also as stable as possible for reproducibility. So I think we
should rather set the build date to the modification time of the newest
source file in the BSP. We could do that by defining a variable in
scripts/lib/ the same manner as PTXDIST_BSP_AUTOVERSION.

Same goes for /etc/issue in your next patch.

 - Roland

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Roland Hieber]

On Fri, Feb 28, 2020 at 11:16:09AM +0100, Roland Hieber wrote:
> On Thu, Feb 27, 2020 at 03:44:48PM +0100, Alexander Dahl wrote:
> > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> > ---
> >  rules/os-release.make | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/rules/os-release.make b/rules/os-release.make
> > index 5156156a0..ba607aa38 100644
> > --- a/rules/os-release.make
> > +++ b/rules/os-release.make
> > @@ -56,7 +56,7 @@ $(STATEDIR)/os-release.targetinstall: $(PTXDIST_PTXCONFIG) $(PTXDIST_PLATFORMCON
> >  		@PTXDIST_VERSION@, $(PTXDIST_VERSION_FULL))
> >  
> >  	@$(call install_replace, os-release, /usr/lib/os-release, \
> > -		@DATE@, $(shell date +%FT%T%z))
> > +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
> 
> So I think we
> should rather set the build date to the modification time of the newest
> source file in the BSP. We could do that by defining a variable in
> scripts/lib/ the same manner as PTXDIST_BSP_AUTOVERSION.

That isn't as easy as I thought, as file mtimes get updated when doing a
VCS checkout. Also we would have to list all files in the BSP (and all
base layers), which could potentially be a very I/O heavy operation, or
need to deal with blacklists or whitelists of folders, but then needed
to make sure nothing in that folders is included in a bash script /
kconfig file / Makefile.

Instead we could use the date of ./tarball-version (like
PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
BSP is not a VCS repo, or if the worktree has local changes, fall back
to searching for the most recent file in the current BSP.

Does this sound reasonable?

 - Roland

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Alexander Dahl]

[-- Attachment #1.1: Type: text/plain, Size: 748 bytes --]

Hello Roland,

On Fri, Feb 28, 2020 at 04:40:10PM +0100, Roland Hieber wrote:
> Instead we could use the date of ./tarball-version (like
> PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
> BSP is not a VCS repo, or if the worktree has local changes, fall back
> to searching for the most recent file in the current BSP.

Or the user could just do anything she wants and feed it into
REPRODUCIBLE_TIMESTAMP_CUSTOM?

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Michael Olbrich]

Hi,

On Fri, Feb 28, 2020 at 05:14:41PM +0100, Alexander Dahl wrote:
> On Fri, Feb 28, 2020 at 04:40:10PM +0100, Roland Hieber wrote:
> > Instead we could use the date of ./tarball-version (like
> > PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
> > BSP is not a VCS repo, or if the worktree has local changes, fall back
> > to searching for the most recent file in the current BSP.
> 
> Or the user could just do anything she wants and feed it into
> REPRODUCIBLE_TIMESTAMP_CUSTOM?

How about
 - 'now' (what we have now)
 - 'last commit' (CommitDate fromt the last commit)
 - 'custom' (from a string)

I'm not sure what you'd want to put in a custom string, but I wouldn't mind
adding it.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Alexander Dahl]

[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]

Hello,

On Sat, Feb 29, 2020 at 09:48:28AM +0100, Michael Olbrich wrote:
> On Fri, Feb 28, 2020 at 05:14:41PM +0100, Alexander Dahl wrote:
> > On Fri, Feb 28, 2020 at 04:40:10PM +0100, Roland Hieber wrote:
> > > Instead we could use the date of ./tarball-version (like
> > > PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
> > > BSP is not a VCS repo, or if the worktree has local changes, fall back
> > > to searching for the most recent file in the current BSP.
> > 
> > Or the user could just do anything she wants and feed it into
> > REPRODUCIBLE_TIMESTAMP_CUSTOM?
> 
> How about
>  - 'now' (what we have now)

Nice for backwards compatibility and to not break expections of users.

>  - 'last commit' (CommitDate fromt the last commit)

Assuming the BSP is in Git, but most users will do that anyway. 

I consider this a good one. You get a comprehensible timestamp related
to the BSP (instead of the ptxdist or toolchain version) while still
getting the same result on multiple builds of the same revision of the
BSP, wouldn't you?

>  - 'custom' (from a string)
> 
> I'm not sure what you'd want to put in a custom string, but I wouldn't mind
> adding it.

+1

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/3] os-release: Make date string reproducible

[Michael Olbrich]

Hi,

On Sat, Feb 29, 2020 at 06:41:27PM +0100, Alexander Dahl wrote:
> On Sat, Feb 29, 2020 at 09:48:28AM +0100, Michael Olbrich wrote:
> > On Fri, Feb 28, 2020 at 05:14:41PM +0100, Alexander Dahl wrote:
> > > On Fri, Feb 28, 2020 at 04:40:10PM +0100, Roland Hieber wrote:
> > > > Instead we could use the date of ./tarball-version (like
> > > > PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
> > > > BSP is not a VCS repo, or if the worktree has local changes, fall back
> > > > to searching for the most recent file in the current BSP.
> > > 
> > > Or the user could just do anything she wants and feed it into
> > > REPRODUCIBLE_TIMESTAMP_CUSTOM?
> > 
> > How about
> >  - 'now' (what we have now)
> 
> Nice for backwards compatibility and to not break expections of users.
> 
> >  - 'last commit' (CommitDate fromt the last commit)
> 
> Assuming the BSP is in Git, but most users will do that anyway. 
> 
> I consider this a good one. You get a comprehensible timestamp related
> to the BSP (instead of the ptxdist or toolchain version) while still
> getting the same result on multiple builds of the same revision of the
> BSP, wouldn't you?

Yes, exactly. And it should be the CommitDate not the AuthorDate.
It will be reproducible but still show when the last changes happened.

> >  - 'custom' (from a string)
> > 
> > I'm not sure what you'd want to put in a custom string, but I wouldn't mind
> > adding it.
> 
> +1

I'm sure someone will find a use-case for this as well...

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 3/3] rootfs: issue: Make date string reproducible

[Alexander Dahl]

Signed-off-by: Alexander Dahl <ada@thorsis.com>
---
 rules/rootfs.make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/rootfs.make b/rules/rootfs.make
index b33805d77..6a89bfcc4 100644
--- a/rules/rootfs.make
+++ b/rules/rootfs.make
@@ -210,7 +210,7 @@ ifdef PTXCONF_ROOTFS_ISSUE
 	@$(call install_replace, rootfs, /etc/issue, \
 		@EXTRAVERSION@, $(PTXDIST_VERSION_SCM))
 	@$(call install_replace, rootfs, /etc/issue, \
-		@DATE@, $(shell date +%FT%T%z))
+		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
 	@$(call install_replace, rootfs, /etc/issue, \
 		@VENDOR@, $(PTXCONF_PROJECT_VENDOR))
 	@$(call install_replace, rootfs, /etc/issue, \
-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 3/3] rootfs: issue: Make date string reproducible

[Michael Olbrich]

On Thu, Feb 27, 2020 at 03:44:49PM +0100, Alexander Dahl wrote:
> Signed-off-by: Alexander Dahl <ada@thorsis.com>

Maybe use the same value as os-release?

Michael

> ---
>  rules/rootfs.make | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rules/rootfs.make b/rules/rootfs.make
> index b33805d77..6a89bfcc4 100644
> --- a/rules/rootfs.make
> +++ b/rules/rootfs.make
> @@ -210,7 +210,7 @@ ifdef PTXCONF_ROOTFS_ISSUE
>  	@$(call install_replace, rootfs, /etc/issue, \
>  		@EXTRAVERSION@, $(PTXDIST_VERSION_SCM))
>  	@$(call install_replace, rootfs, /etc/issue, \
> -		@DATE@, $(shell date +%FT%T%z))
> +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
>  	@$(call install_replace, rootfs, /etc/issue, \
>  		@VENDOR@, $(PTXCONF_PROJECT_VENDOR))
>  	@$(call install_replace, rootfs, /etc/issue, \
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 3/3] rootfs: issue: Make date string reproducible

[Alexander Dahl]

Hello,

Am Freitag, 20. März 2020, 12:39:33 CET schrieb Michael Olbrich:
> On Thu, Feb 27, 2020 at 03:44:49PM +0100, Alexander Dahl wrote:
> > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> 
> Maybe use the same value as os-release?

Would make sense, I thought that's what 

$(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z')

would yield, given SOURCE_DATE_EPOCH is always set? I used that line in both 
patches. 

I'm sorry, I don't understand what you mean here, or what you mean with that 
question above.

Greets
Alex

> > ---
> > 
> >  rules/rootfs.make | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/rules/rootfs.make b/rules/rootfs.make
> > index b33805d77..6a89bfcc4 100644
> > --- a/rules/rootfs.make
> > +++ b/rules/rootfs.make
> > @@ -210,7 +210,7 @@ ifdef PTXCONF_ROOTFS_ISSUE
> > 
> >  	@$(call install_replace, rootfs, /etc/issue, \
> >  	
> >  		@EXTRAVERSION@, $(PTXDIST_VERSION_SCM))
> >  	
> >  	@$(call install_replace, rootfs, /etc/issue, \
> > 
> > -		@DATE@, $(shell date +%FT%T%z))
> > +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
> > 
> >  	@$(call install_replace, rootfs, /etc/issue, \
> >  	
> >  		@VENDOR@, $(PTXCONF_PROJECT_VENDOR))
> >  	
> >  	@$(call install_replace, rootfs, /etc/issue, \



_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 3/3] rootfs: issue: Make date string reproducible

[Michael Olbrich]

On Fri, Mar 20, 2020 at 01:08:41PM +0100, Alexander Dahl wrote:
> Am Freitag, 20. März 2020, 12:39:33 CET schrieb Michael Olbrich:
> > On Thu, Feb 27, 2020 at 03:44:49PM +0100, Alexander Dahl wrote:
> > > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> > 
> > Maybe use the same value as os-release?
> 
> Would make sense, I thought that's what 
> 
> $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z')
> 
> would yield, given SOURCE_DATE_EPOCH is always set? I used that line in both 
> patches. 
> 
> I'm sorry, I don't understand what you mean here, or what you mean with that 
> question above.

I mean that the discussion we had about the timestamp for os-release is
applies to this packages as well and they should probably share the
resulting timestamp. Maybe add the options to rules/project-name.in and use
the resulting value for both packages.

The packages should be rebuilt when this changes, but I'm working on some
infrastructure to simplify this, so don't worry about this, I'll handle it.

Michael

> > > ---
> > > 
> > >  rules/rootfs.make | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/rules/rootfs.make b/rules/rootfs.make
> > > index b33805d77..6a89bfcc4 100644
> > > --- a/rules/rootfs.make
> > > +++ b/rules/rootfs.make
> > > @@ -210,7 +210,7 @@ ifdef PTXCONF_ROOTFS_ISSUE
> > > 
> > >  	@$(call install_replace, rootfs, /etc/issue, \
> > >  	
> > >  		@EXTRAVERSION@, $(PTXDIST_VERSION_SCM))
> > >  	
> > >  	@$(call install_replace, rootfs, /etc/issue, \
> > > 
> > > -		@DATE@, $(shell date +%FT%T%z))
> > > +		@DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) '+%FT%T%z'))
> > > 
> > >  	@$(call install_replace, rootfs, /etc/issue, \
> > >  	
> > >  		@VENDOR@, $(PTXCONF_PROJECT_VENDOR))
> > >  	
> > >  	@$(call install_replace, rootfs, /etc/issue, \
> 
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de