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

Tests fail with SOURCE_DATE_EPOCH set #2405

Closed
smcv opened this issue Jul 25, 2021 · 3 comments · Fixed by #2407
Closed

Tests fail with SOURCE_DATE_EPOCH set #2405

smcv opened this issue Jul 25, 2021 · 3 comments · Fixed by #2407

Comments

@smcv
Copy link
Contributor

smcv commented Jul 25, 2021

Debian builds official packages with SOURCE_DATE_EPOCH set to the date in the Debian changelog, to get a reproducible result from the same source code.

Unfortunately, since 2021.3 this seems to be making several build-time unit tests fail with this message:

downgraded without --allow-downgrade?

I think this is probably because the tests build more than one ostree commit, expecting the second one to have a strictly higher mtime, but the new SOURCE_DATE_EPOCH support gives them both the same mtime.

At the moment I'm working around this with unset SOURCE_DATE_EPOCH before running the tests in the packaging, but ideally the affected tests would unset this themselves.

@dbnicholson
Copy link
Member

I agree with the workaround. Tests that want to check that behavior can set it explicitly. I think there's only one test that does handle it and it already does manage the variable. @lucab what do you think?

@lucab
Copy link
Member

lucab commented Jul 26, 2021

Yes, I'd agree it would be good to fix the tests upstream (i.e. here).
@smcv do you maybe have the logs from the failing test run somewhere? I couldn't find the 2021.3 packages/runs on debian infra yet. Is the failure showing up through a plain make check, or is it going through some other path?

It would be good to see what is the situation across the whole testsuite. If it is only upgrade with and without override-commit having issues, we can surgically fix the epochs there. If it is more widespread, libtest.sh may carry the tweak. Or perhaps both.

@smcv
Copy link
Contributor Author

smcv commented Jul 26, 2021

do you maybe have the logs from the failing test run somewhere?

From a previous attempt: ostree_2021.3-1_amd64_20210725t181136.build.gz

I couldn't find the 2021.3 packages/runs on debian infra yet

I didn't upload the version that was failing tests, because it was failing tests :-)

The finalized version of 2021.3-1 with the workaround is only in experimental so far, because Debian is in freeze for the Debian 11 release.

Is the failure showing up through a plain make check, or is it going through some other path?

https://salsa.debian.org/debian/ostree/-/blob/debian/experimental/debian/test.sh wraps make check, and currently has the workaround.

If it is more widespread

tests/test-pull-bare.sh, tests/test-pull-bareuser.sh, tests/test-pull-bareuseronly.sh, tests/test-admin-deploy-syslinux.sh, tests/test-admin-deploy-uboot.sh, tests/test-admin-deploy-grub2.sh, tests/test-admin-deploy-none.sh are all failing, so I think I'd be more comfortable with putting this in libtest.sh.

smcv added a commit to smcv/ostree that referenced this issue Jul 26, 2021
Some distributions set this during build in order to have reproducible
builds from the same source code: for example, Debian uses the date
from debian/changelog.

However, some of our tests assume that `ostree commit` will result in
a commit with the current date/time, and SOURCE_DATE_EPOCH breaks that
assumption. Unset it for our build-time tests.

Resolves: ostreedev#2405
Signed-off-by: Simon McVittie <smcv@collabora.com>
raspbian-autopush pushed a commit to raspbian-packages/ostree that referenced this issue Aug 26, 2021
Some distributions set this during build in order to have reproducible
builds from the same source code: for example, Debian uses the date
from debian/changelog.

However, some of our tests assume that `ostree commit` will result in
a commit with the current date/time, and SOURCE_DATE_EPOCH breaks that
assumption. Unset it for our build-time tests.

Bug: ostreedev/ostree#2405
Signed-off-by: Simon McVittie <smcv@collabora.com>
Applied-upstream: 2021.4, commit:2c5fa2cdb6c304394ca629c959ec53d878f3f93a

Gbp-Pq: Name tests-Unset-SOURCE_DATE_EPOCH.patch
raspbian-autopush pushed a commit to raspbian-packages/ostree that referenced this issue Aug 26, 2021
Some distributions set this during build in order to have reproducible
builds from the same source code: for example, Debian uses the date
from debian/changelog.

However, some of our tests assume that `ostree commit` will result in
a commit with the current date/time, and SOURCE_DATE_EPOCH breaks that
assumption. Unset it for our build-time tests.

Bug: ostreedev/ostree#2405
Signed-off-by: Simon McVittie <smcv@collabora.com>
Applied-upstream: 2021.4, commit:2c5fa2cdb6c304394ca629c959ec53d878f3f93a

Gbp-Pq: Name tests-Unset-SOURCE_DATE_EPOCH.patch
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 a pull request may close this issue.

3 participants