| 03:09.25 | *** join/#bzflag heartnet (~msk@90-104-16-160.host.anywhere.rr.nu) |
| 04:05.12 | *** join/#bzflag Snake12534 (uid87978@gateway/web/irccloud.com/x-cnhnwalyomerxsxc) |
| 04:27.14 | BulletCatcher | On Fedora 23, at least, it appears that the only remaining obstacle to reproducible builds is the date compiled into buildDate.cxx. |
| 04:27.16 | BulletCatcher | If we really want to make the 2.4.6 release have reproducible builds we could hard-code the date instead of using the __DATE__ preprocessor macro for just the tagged Git commit, and then go back to using __DATE__ again afterward. |
| 04:27.43 | BulletCatcher | My preference would be to drop the date entirely for just the release. |
| 04:32.12 | blast007 | if we go with the SOURCE_DATE_EPOCH spec, couldn't we fall back to use __DATE__ if SOURCE_DATE_EPOCH isn't defined? |
| 04:33.57 | DTRemenak | why is perfect reproducibility a goal? |
| 04:34.25 | blast007 | https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples |
| 04:34.50 | blast007 | DTRemenak: because the Linuxes are wanting reproducable builds, mainly |
| 04:35.38 | DTRemenak | reproducible builds for fixed environments can already be generated by running ./configure before the distribution (this is how we used to build SRPMs) |
| 04:36.04 | DTRemenak | and if the environment is not fixed there's not much point, I think (linking to a patched library breaks reproducibility too) |
| 04:36.24 | blast007 | we use __DATE__ in one of our source files |
| 04:36.37 | BulletCatcher | The build date is set when buildDate.cxx is compiled, not when configure is run. |
| 04:36.41 | DTRemenak | ah |
| 04:36.54 | DTRemenak | why'd we do that? |
| 04:37.12 | blast007 | probably so it behaved the same on Windows |
| 04:37.32 | DTRemenak | I thought windows' configure.h could take care of that |
| 04:38.55 | DTRemenak | yeah, it used to be a fixed date by configure |
| 04:38.59 | DTRemenak | https://github.com/BZFlag-Dev/bzflag/commit/32828d79acd5747d29c729c978aaf67c2797e394 |
| 04:39.43 | DTRemenak | note the #ifndef BZ_BUILD_DATE |
| 04:39.54 | DTRemenak | __DATE__ was only used if configure hadn't defined it |
| 04:42.00 | DTRemenak | apparently someone though it was too complicated ;) |
| 04:44.53 | BulletCatcher | I still think an abbreviated Git commit hash would be more useful than a date. |
| 04:44.55 | BulletCatcher | I also think we shouldn't clutter the version string with a hash for releases. |
| 04:45.55 | BulletCatcher | But we developers don't have much of a consensus on exactly what info should be in the version string. |
| 04:46.01 | blast007 | DTRemenak: BZ_BUILD_DATE was being undef'ed since 2005: https://github.com/BZFlag-Dev/bzflag/commit/69a298eae14a395653047b5590ffa8af421df4e5 |
| 04:46.51 | DTRemenak | yeah, saw that shortly after pasting the link. still, not sure why it was turned off, or why nobody has complained about our SRPMs since then (assuming we still supply them) |
| 04:47.24 | blast007 | the project hasn't provided RPMs in years |
| 04:47.40 | blast007 | we only provide source .zip, .tar.gz, and .tar.bz2 |
| 04:47.46 | DTRemenak | I haven't run a system using RPMs in years, so... ;) |
| 04:49.03 | blast007 | looks like 2003 for the last source RPM, and 2005 for the last binary RPM |
| 04:49.16 | DTRemenak | well you can call me out of date |
| 04:49.54 | BulletCatcher | gets off DTRemenak's lawn |
| 04:50.54 | DTRemenak | dates have the convenient property that they always go in one direction, whereas commit ids (especially abbreviated ones) don't |
| 04:51.18 | DTRemenak | it's easy to tell whether my development build is newer or older than someone else's with a date...much harder with a commit hash |
| 04:51.46 | blast007 | in the case of Git, it doesn't matter if they're abbreviated or not - from an order standpoint is pretty random looking ;) |
| 04:51.54 | DTRemenak | fair enough |
| 04:52.32 | blast007 | also, the idea was that the git hash would only be for development (odd) binaries |
| 04:52.37 | DTRemenak | for release builds I don't see it mattering much at all, as long as we stick to the basic convention of "all builds with the same version number should be equivalent) |
| 04:52.43 | blast007 | stable releases would just have the version number |
| 04:58.40 | BulletCatcher | If having a nondecreasing number is more important than identifying the specific commit on which the code is based, then there are at least a couple of ways to get that from Git. |
| 04:59.17 | BulletCatcher | For example, "git rev-list HEAD --count" gives the number of commits on the current branch all the way back to the first. |
| 04:59.34 | BulletCatcher | We're currently at 13197 on the 2.4 branch. |
| 05:00.15 | DTRemenak | how consistent is that between active repositories? |
| 05:00.33 | BulletCatcher | It wouldn't be. |
| 05:01.15 | DTRemenak | in the past we've also ended up building multiple release binaries with the same version in some situations (when a particular platform...looking at you OSX...had problem due to the build system's configuration), and the date helped differentiate them. |
| 05:02.16 | DTRemenak | BulletCatcher: so it doesn't help me compare my version string to another developer's, just like a commit hash doesn't :( |
| 05:02.29 | DTRemenak | BulletCatcher: how about "last commit date"? |
| 05:03.09 | BulletCatcher | "Date of HEAD" would be doable. |
| 05:04.17 | BulletCatcher | ... on unix and probably the Mac, but I don't know how to do anything like that on Windows. |
| 05:04.48 | DTRemenak | (also, you don't necessarily need to take anything I say into consideration, considering the last time I actually committed a change...;et;) ) |
| 05:05.01 | DTRemenak | ...let's just say I used "svn commit" |
| 05:05.30 | BulletCatcher | Your perspective remains valuable. |
| 05:05.49 | DTRemenak | windows has almost always needed special attention for build stuff anyway |
| 05:07.15 | DTRemenak | (notably, even when BZ_BUILD_DATE was set in configure, windows used __DATE__) |
| 05:08.20 | BulletCatcher | "git log --author=dtremenak -n 1" :-) |
| 05:10.04 | BulletCatcher | I think the Windows behavior was part of the motivation for just using __DATE__ on all platforms. |
| 05:12.28 | BulletCatcher | Since the desire for reproducible builds seems to be mostly a unix thing, we could make it a configure option and continue as-is on Windows and the Mac. |
| 05:13.46 | BulletCatcher | Sufficiently motivated Windows and Mac developers would be welcome to provide the same functionality for their platforms. |
| 05:24.12 | BulletCatcher | In semantic versioning, different builds of the same underlying code base are distinguished by an extra dot-number rather than a date string. |
| 05:24.36 | DTRemenak | yeah, and that's almost certainly a better way to go |
| 05:24.59 | DTRemenak | I don't know that we currently have any facility for that though |
| 05:25.17 | BulletCatcher | Nothing automatic. |
| 05:25.22 | the_map | the dot is to the right of the comma |
| 05:25.35 | DTRemenak | ~fishslap the_map |
| 05:25.35 | infobot | ACTION slaps the_map up side the head with a wet fish. |
| 05:35.15 | blast007 | not a configure option, an environment variable: https://reproducible-builds.org/specs/source-date-epoch/ |
| 05:37.08 | DTRemenak | heh. and THAT approach would totally work on windows. |
| 05:37.47 | DTRemenak | <PROTECTED> |
| 05:47.49 | BulletCatcher | A commit identifier and the build date convey different information. |
| 05:47.51 | BulletCatcher | Perhaps we should use both. |
| 06:20.07 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 08:49.40 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 09:42.44 | *** join/#bzflag cods_ (~fred@tuxee.net) |
| 09:53.44 | *** join/#bzflag jcp (uid143528@bzflag/contributor/javawizard2539) |
| 10:30.27 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 10:30.27 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 11:20.50 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 11:37.47 | *** join/#bzflag cods (~fred@tuxee.net) |
| 11:39.10 | *** join/#bzflag FastLizard4|zZzZ (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 11:47.01 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 11:48.45 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 13:38.59 | *** join/#bzflag tw1sted_ (~tw1sted@104.236.87.240) |
| 13:50.30 | *** join/#bzflag kaadmy (uid135503@gateway/web/irccloud.com/x-dkuzhfkxhnftcwzy) |
| 14:09.18 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 14:41.30 | *** join/#bzflag tw1sted (~tw1sted@104.236.87.240) |
| 14:44.50 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 15:36.21 | *** join/#bzflag meeba_ (~lamer@c-73-14-146-7.hsd1.co.comcast.net) |
| 15:39.04 | *** join/#bzflag joevano_ (~joevano@bzflag/developer/JoeVano) |
| 15:39.04 | *** mode/#bzflag [+v joevano_] by ChanServ |
| 15:41.02 | *** join/#bzflag tw1sted (~tw1sted@104.236.87.240) |
| 17:12.08 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 17:12.09 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 18:43.33 | *** join/#bzflag the_map_ (~the_map@unaffiliated/the-map/x-1795707) |
| 18:45.18 | *** join/#bzflag TD-Linux (~Thomas@about/essy/indecisive/TD-Linux) |
| 19:13.59 | *** join/#bzflag kaadmy (uid135503@gateway/web/irccloud.com/x-gmirogvpichqyqhb) |
| 22:59.32 | *** join/#bzflag infobot (ibot@rikers.org) |
| 22:59.32 | *** topic/#bzflag is http://BZFlag.org || http://ohloh.net/p/bzflag || https://wiki.bzflag.org/Getting_Help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.4 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19186 |
| 22:59.32 | *** mode/#bzflag [+v infobot] by ChanServ |
| 23:39.29 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 23:40.18 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |