New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ChangeLog date instead of build date #34

Merged
merged 1 commit into from Jan 8, 2018

Conversation

Projects
None yet
3 participants
@bmwiedemann

bmwiedemann commented Dec 16, 2017

in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good.

This date call works with GNU date and BSD date.

Without this patch, the osdlyrics openSUSE package would differ
for every build

/usr/lib64/osdlyrics/daemon/config.py differs (ASCII text) 
--- old//usr/lib64/osdlyrics/daemon/config.py   2017-11-26 12:00:00.000000000 +0000 
+++ new//usr/lib64/osdlyrics/daemon/config.py   2017-11-26 12:00:00.000000000 +0000
@@ -20,4 +20,4 @@

 PROGRAM_NAME = '@PROGRAM_NAME@'
 PACKAGE_NAME = 'osdlyrics'
-PACKAGE_VERSION = '0.5.0-git20171128'
+PACKAGE_VERSION = '0.5.0-git20190103'

and differ in /usr/bin/osdlyrics accordingly
Use ChangeLog date instead of build date
in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good.

This date call works with GNU date and BSD date.
@Corax26

This comment has been minimized.

Show comment
Hide comment
@Corax26

Corax26 Dec 28, 2017

Interesting, wasn't aware of the reproducible-builds effort, thanks for the pointer. I certainly approve of the idea (using the build date in the package version is clearly not a good thing), however using ChangeLog's modification time makes little sense: the last time it was changed was in 2011, so the modification time will basically be the time when you cloned the repo.

Given that we're using Git, we should use Git's metadata to determine the version. In other words, it should be based on HEAD. We can keep a date and use HEAD's commit date, or we can just use HEAD's SHA1 (FWIW that's how -git packages are versioned on Arch Linux). @lenoch @PedroHLC any thoughts?

Corax26 commented Dec 28, 2017

Interesting, wasn't aware of the reproducible-builds effort, thanks for the pointer. I certainly approve of the idea (using the build date in the package version is clearly not a good thing), however using ChangeLog's modification time makes little sense: the last time it was changed was in 2011, so the modification time will basically be the time when you cloned the repo.

Given that we're using Git, we should use Git's metadata to determine the version. In other words, it should be based on HEAD. We can keep a date and use HEAD's commit date, or we can just use HEAD's SHA1 (FWIW that's how -git packages are versioned on Arch Linux). @lenoch @PedroHLC any thoughts?

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Dec 29, 2017

In openSUSE we usually build from tarballs that usually don't contain the git metadata. But it would be possible to have a step in the tarball generation that adds the git commit hash and date into the tarball so that it can be used here.
This ChangeLog patch was just a lot easier than that to get this discussion started ;-)

Also, if you look at the diff, you will notice that it already takes the git commit date if available and date is just the fallback case there.

bmwiedemann commented Dec 29, 2017

In openSUSE we usually build from tarballs that usually don't contain the git metadata. But it would be possible to have a step in the tarball generation that adds the git commit hash and date into the tarball so that it can be used here.
This ChangeLog patch was just a lot easier than that to get this discussion started ;-)

Also, if you look at the diff, you will notice that it already takes the git commit date if available and date is just the fallback case there.

@PedroHLC

This comment has been minimized.

Show comment
Hide comment
@PedroHLC

PedroHLC Dec 29, 2017

Member

It seems fine using date as only fallback. Do you known any use-case where the ChangeLog option isn't available?

Member

PedroHLC commented Dec 29, 2017

It seems fine using date as only fallback. Do you known any use-case where the ChangeLog option isn't available?

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Dec 31, 2017

The file will always have a date. Though it would be good to make sure that it is updated for each release tarball.

Also, there are some other 'date' variants than GNU and BSD ones - e.g. opensolaris and DOS ones, don't have a -r option, so the command might not work there - will that matter?

bmwiedemann commented Dec 31, 2017

The file will always have a date. Though it would be good to make sure that it is updated for each release tarball.

Also, there are some other 'date' variants than GNU and BSD ones - e.g. opensolaris and DOS ones, don't have a -r option, so the command might not work there - will that matter?

@PedroHLC

This comment has been minimized.

Show comment
Hide comment
@PedroHLC

PedroHLC Dec 31, 2017

Member

Neither solaris nor DOS, will be merged then

Member

PedroHLC commented Dec 31, 2017

Neither solaris nor DOS, will be merged then

@Corax26

This comment has been minimized.

Show comment
Hide comment
@Corax26

Corax26 Jan 1, 2018

Oh of course, this is only the fallback! Didn't even read the line before... In this case I guess using ChangeLog is fine, when/if we have a proper release we'll just need to modify it.

Corax26 commented Jan 1, 2018

Oh of course, this is only the fallback! Didn't even read the line before... In this case I guess using ChangeLog is fine, when/if we have a proper release we'll just need to modify it.

@PedroHLC PedroHLC merged commit 9894cbc into osdlyrics:master Jan 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment