Skip to content
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

Do not include date in binaries #6581

Merged
merged 1 commit into from Nov 18, 2017
Merged

Do not include date in binaries #6581

merged 1 commit into from Nov 18, 2017

Conversation

bmwiedemann
Copy link
Contributor

and do not claim copyright for 2018
in order to make nim package builds reproducible.

See https://reproducible-builds.org/ for why this is good.

An alternative approach would be to implement using
SOURCE_DATE_EPOCH
for CompileDate and CompileTime

and do not claim copyright for 2018
in order to make nim package builds reproducible.

See https://reproducible-builds.org/ for why this is good.
@Araq
Copy link
Member

Araq commented Oct 24, 2017

Having to update the year every year manually is worse than the current solution.

@bmwiedemann
Copy link
Contributor Author

Is there a way to have the const copyrightYear = "2017" in one place and change all users to use it from there?
Then the script that builds a release tarball could also update that file.

@Araq
Copy link
Member

Araq commented Oct 24, 2017

What's the point anyway, diff the binary files with a tool slightly smarter than memcmp.

@bmwiedemann
Copy link
Contributor Author

bmwiedemann commented Oct 25, 2017

In openSUSE we already have a smart tool called build-compare that comes with a dozen filters for various formats but detecting date/time strings in the middle of binaries is not that trivial... and then you can never be sure that you dont ignore important changes by mistake.
That is why the goal of the reproducible-builds project is to be able to build bit-identical binary packages (and ISO images) where you can publish one sha256sum and other people build the package/ISO from sources and get the same sha256sum.
Maybe nim could do similar to gcc that accepted a patch to use $SOURCE_DATE_EPOCH for its __DATE__ and __TIME__ macros... it is just that I'm not that good at this language (yet) or I would have written it myself.

However, claiming copyright for future years is something I find questionable independent of that.

@Araq
Copy link
Member

Araq commented Oct 25, 2017

An alternative approach would be to implement using SOURCE_DATE_EPOCH for CompileDate and CompileTime

Ok, that is beginning to sound good. But if that env var is not set, it should continue to use the current time.

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

@bmwiedemann
Copy link
Contributor Author

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

@bmwiedemann
Copy link
Contributor Author

See also http://rb.zq1.de/compare.factory-20170807/nim-compare.out for how package diff looks.

@Araq
Copy link
Member

Araq commented Oct 26, 2017

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

Since I work every day on Nim, this is a theoretical issue. Once development slows down I can reconsider this.

@bmwiedemann
Copy link
Contributor Author

No, you are working every day on the master version, but when I talk about today's version, I mean
https://github.com/nim-lang/Nim/tree/b2a2522d2dcef2f85b7e1615fc0720d3475427de (or any release tarball) - things that do not change anymore - and they will still get a Copyright 2018 when built in 10 weeks.

@Calinou
Copy link
Member

Calinou commented Oct 26, 2017

Is dating copyrights even useful today? Version information (version number or Git hash) can easily be looked up online, after all.

@dom96
Copy link
Contributor

dom96 commented Oct 26, 2017

In fact, the date shouldn't be updated according to this: https://stackoverflow.com/a/2391555/492186.

We should be using "Copyright 2004" everywhere!

@FedericoCeratto
Copy link
Member

It is not beneficial to move the year forward if only one date is present. The initial date should stay the same and ideally match the true year of authorship. It's possible to use a range e.g. "2004 - 2017", although it is not a requirement.

@Araq Araq merged commit 49320ad into nim-lang:devel Nov 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants