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

meson: initialize time-epoch to reproducible builds compatible value #15827

Merged
merged 1 commit into from May 18, 2020

Conversation

xnox
Copy link
Member

@xnox xnox commented May 15, 2020

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/

@poettering
Copy link
Member

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()
Copy link
Member

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)

Copy link
Member Author

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/
@floppym
Copy link
Contributor

floppym commented May 16, 2020

Why not just call meson setup -Dtime-epoch=$SOURCE_DATE_EPOCH from the Debian packaging scripts?

@mbiebl
Copy link
Contributor

mbiebl commented May 16, 2020

I was under the impression that more distros besides Debian were interested in reproducible builds.
If indeed Debian is the only distro that cares for this, then we could indeed set this via debian/rules.

@xnox
Copy link
Member Author

xnox commented May 17, 2020

Why not just call meson setup -Dtime-epoch=$SOURCE_DATE_EPOCH from the Debian packaging scripts?

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.

@floppym
Copy link
Contributor

floppym commented May 18, 2020

Perhaps you should convince the meson developers to support this environment variable instead of adding this hacky workaround.

@keszybz
Copy link
Member

keszybz commented May 18, 2020

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. -Dtime-epoch=$SOURCE_DATE_EPOCH is good-enough as a work-around. So let's first figure out what happens in meson.

@keszybz
Copy link
Member

keszybz commented May 18, 2020

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.)

@keszybz keszybz merged commit 6dbf352 into systemd:master May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

5 participants