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

src: Sort files in built beipack #20939

Closed

Conversation

martinpitt
Copy link
Member

cockpit-bridge.beipack.xz is currently not reproducible [1] as the order of files in it differs. Dictionaries are
insertion-stable/reproducible since Python 3.7, so apparently the order of files in (cockpit-0-py3-none-any.whl) depends on the environment (we don't ship that wheel itself in distro packages).

Sort the file names to make the content reproducible.

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cockpit.html


It's not obvious to me how to reproduce the different file layout -- I tried different build paths and different LANG/LC_ALL/LANGUAGE values, which are the most obvious candidates from the build environment diff. In all cases I got the same beipack. However, the order (of course) does change with this sorted() patch.

`cockpit-bridge.beipack.xz` is currently not reproducible [1] as the
order of files in it differs. Dictionaries are
insertion-stable/reproducible since Python 3.7, so apparently the order
of files in (`cockpit-0-py3-none-any.whl`) depends on the environment
(we don't ship that wheel itself in distro packages).

Sort the file names to make the content reproducible.

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cockpit.html
@martinpitt
Copy link
Member Author

The F41/C10 regressions are unrelated and in the distros. Seen in fedora-selinux/selinux-policy#2318 or cockpit-project/bots#6775 .

@@ -86,7 +86,7 @@ def write(filename: str, data: AnyStr) -> None:

def beipack_self(main: str, args: str = '') -> bytes:
from cockpit._vendor.bei import beipack
contents = {name: wheel.read(name) for name in wheel.namelist()}
contents = {name: wheel.read(name) for name in sorted(wheel.namelist())}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the wrong spot. I imagine the non-deterministic ordering comes from the os.walk() call in find_sources(). Then the files get added to the wheel in a non-deterministic order, and we iterate the wheel (getting the same order, I'd assume).

Two possible ideas for a fix:

  • change find_sources() to no longer be a generator but to build a list internally, calling .sort() on it before returning it; or
  • (and this is the better one, I think): add sorted() around the two invocation sites of find_sources() where it matters: in build_wheel() and build_sdist(). For find_copy() it's irrelevant.

Copy link
Member

@allisonkarlitskaya allisonkarlitskaya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we don't install them directly, let's also try to make the sdist and wheel deterministic (since that's the cause of the issue)

@jelly
Copy link
Member

jelly commented Aug 26, 2024

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cockpit.html

It's not obvious to me how to reproduce the different file layout -- I tried different build paths and different LANG/LC_ALL/LANGUAGE values, which are the most obvious candidates from the build environment diff. In all cases I got the same beipack. However, the order (of course) does change with this sorted() patch.

If you want to vary reading dirs you can toy around with disorderfs https://salsa.debian.org/reproducible-builds/disorderfs

@martinpitt
Copy link
Member Author

Closing in favor of #20943, thanks @allisonkarlitskaya !

@martinpitt martinpitt closed this Aug 26, 2024
@martinpitt martinpitt deleted the reproducible-beipack branch August 26, 2024 11:12
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 this pull request may close these issues.

3 participants