Making the springlobby build reproducible

[apoleon]

Hi,

to further improve the quality of the Debian distribution we aim to provide byte for byte reproducible builds.

https://wiki.debian.org/ReproducibleBuilds

At the moment springlobby cannot be reproducibly built because DATE and TIME macros are used which make it impossible to reach this goal. One way to solve this bug would be to remove all occurences of these macros within the source code. A patch is attached which achieves that.

A more fine grained approach would be to support builds with timestamps and without them. Although I think nobody really cares when a certain version was exactly built. It would be great if those DATE and TIME macros could be removed.

https://gist.github.com/014ada7ec1f2f837a2dd

[abma]

wouldn't it be more productive to change gcc so it sets DATE & TIME macro to a specific / defined value?

as you maybe can see in code, it is wanted, that the current time and date is stored in the build.

how do other projects solve this? is date/time defined by the buildsystem (=cmake)?

[apoleon]

On 04.05.2015 22:59, abma wrote:

wouldn't it be more productive to change gcc so it sets DATE & TIME
macro to a specific / defined value?

That sounds like a reasonable solution but I presume nobody wants to
disable the DATE and TIME macros completely.

as you maybe can see in code, it is wanted, that the current time and
date is stored in the build.

Yes, of course I saw that and I fully understand why you use these macros.

how do other projects solve this? is date/time defined by the
buildsystem (=cmake)?

Until now other maintainers either removed those macros completely or
they replaced them with another fixed value.

The best solution would be to make timestamps customizable. As far as
end users are concerned, they are usually not interested when a certain
version of springlobby was built. They only care for the version itself
but not the build time. If this issue is solvable with some kind of
cmake option, great. Of course a switch would be nice but everything
else would be fine too.

http://en.cppreference.com/w/cpp/preprocessor/replace

I have read on this site that redefining or undefining those macros
might result in undefined behavior. Otherwise I could live with a Debian
specific patch too, that simply changes the value of those macros to a
fixed value. Of course a permanent upstream solution would be preferable.

[abma]

That sounds like a reasonable solution but I presume nobody wants to
disable the DATE and TIME macros completely.

its just to get "reproducible builds"... i don't see a real difference to the removal of the macros in the source code.

The best solution would be to make timestamps customizable.

thats exactly what i mean. change gcc so it allows to make these timestamps customizeable.

[abma]

in other words: i see this as a bug / missing feature of gcc, thats no bug/problem in springlobby.

[apoleon]

On Mon, 04. May 15:14 abma notifications@github.com wrote:

in other words: i see this as a bug / missing feature of gcc, thats no
bug/problem in springlobby.

No, I think you misunderstood my bug report. Of course you can always
patch the compiler to achieve a certain result but that doesn't change
the fact that this a feature request / bug in springlobby. Nobody wants
to get rid of those macros completely but they prevent that
springlobby can be built reproducibly. 80% of all source packages
in Debian are already reproducible builds because they don't use
timestamps. The benefits are described on the page I linked to in my
initial post.

[baracoder]

maybe use git describe --tags --dirty from cmake?

[abma]

i guess using something like add_definitions(-DBUILD_TIME="some date" ...) will do the trick...

http://stackoverflow.com/questions/24292898/compile-date-and-time-using-cmake

[abma]

partly done:
spring/pr-downloader@bdfb029

[abma]

i hopefully missed none...