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
meson: initialize time-epoch to reproducible builds compatible value #15827
Conversation
there's a TODO list item for this in TODO. Please remove it in the same PR |
@@ -669,8 +669,13 @@ conf.set_quoted('DEFAULT_NET_NAMING_SCHEME', default_net_naming_scheme) | |||
|
|||
time_epoch = get_option('time-epoch') | |||
if time_epoch == -1 | |||
NEWS = files('NEWS') | |||
time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int() | |||
source_date_epoch = run_command('sh', ['-c', 'echo "$SOURCE_DATE_EPOCH"']).stdout().strip() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
urks...
hmm, this is a bit ugly... maybe we should turn both into a single heler script in tools/.
I figure @keszybz knows this stuff better than I. What's your take on this?
(Apparently meson doesn't have a getenv call natively)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, meson does not read env by design. I'm not a meson expert, so I don't know if this is "mesonic".
Debian Policy encourages to preserve timestamps whenever possible in the tarballs, thus stable release updates of systemd usually do not bump NEWS file timestamp. And thus time-epoch remains the same for the lifetime of a release. It would be better, if each new stable release rebuild of systemd would bump the time epoch a bit. But at the same time remain reproducible. SOURCE_DATE_EPOCH is an environmnet variable defined for this purpose. Thus if available, prefer that, instead of the NEWS file modification time. For example, on Debian/Ubuntu under the reproducible builds the SOURCE_DATE_EPOCH is set to the timestamp from the packaging metadata, thus it is incremented on every new stable release update, whilst preserving reproducible builds capability. Reference: https://reproducible-builds.org/docs/timestamps/
Why not just call |
I was under the impression that more distros besides Debian were interested in reproducible builds. |
Reproducible builds is universal Linux Foundation effort to allow reproducible building of any software from upstream sources. Meaning it's not even "just a thing distributions do". For example, upstream documentation build tools help2man and sphinx support it. Such that any software that uses those build-tools to build their documentation, are can be built reproducible out of the box. A notable upstream project that releases all sources & binaries that can be rebuild byte-to-byte identical is Tor. Anybody who is trying to build systemd from git should be able to do so in a predictable manner. |
Perhaps you should convince the meson developers to support this environment variable instead of adding this hacky workaround. |
It'd be great to have $SOURCE_DATE_EPOCH supported by systemd. Meson developers are convinced about the idea (mesonbuild/meson#1362), but somebody needs to do the work. I'd prefer to see this done in meson. In particular, with this variable we have the same problem as with CC= and other traditional variables, that when a reconfiguration is triggered, there is no clear answer whether the original environment should be used, the one from the reconfiguration run, or some mix. (The answer tends to be "some mix", and things get messy.) Because of this complexity with caching of the environment, if there's a chance that upstream meson will get support for this in some not-too-distant-future, then I don't think we should add this here. |
Hmm, after looking at this a bit more, I think we should merge this anyway. If meson gets support, it will be for things like timestamps of files. But we use this for internal purposes too, so we will need support independently of meson. (Possibly, meson will allow introspection to see what the source epoch for a build is, in which case we could avoid reading the env var ourselves. But that doesn't change too much.) |
Debian Policy encourages to preserve timestamps whenever possible in the
tarballs, thus stable release updates of systemd usually do not bump NEWS file
timestamp. And thus time-epoch remains the same for the lifetime of a release.
It would be better, if each new stable release rebuild of systemd would bump
the time epoch a bit. But at the same time remain
reproducible. SOURCE_DATE_EPOCH is an environmnet variable defined for this
purpose. Thus if available, prefer that, instead of the NEWS file modification
time.
For example, on Debian/Ubuntu under the reproducible builds the
SOURCE_DATE_EPOCH is set to the timestamp from the packaging metadata, thus it
is incremented on every new stable release update, whilst preserving
reproducible builds capability.
Reference: https://reproducible-builds.org/docs/timestamps/