gnutar: make reproducible by default #107251
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
prusnak
force-pushed
the
gnutar-repro-hook
branch
2 times, most recently
from
8447be5
to
1484f1e
Compare
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Still relevant. |
stale
bot
removed
the
2.status: stale
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
@prusnak you marked this as 'Draft' in december 2020 - why? Is there anything you'd like to do before we start reviewing this? Would you like help? |
stale
bot
removed
the
2.status: stale
prusnak
force-pushed
the
gnutar-repro-hook
branch
from
1484f1e
to
24fdc30
Compare
|
@raboof No. I just wanted to gather more feedback before someone accidentally merges this. Since there was no feedback, I am marking this as ready. |
prusnak
force-pushed
the
gnutar-repro-hook
branch
2 times, most recently
from
b43561d
to
a3ad038
Compare
raboof
approved these changes
May 15, 2022
There was a problem hiding this comment.
Tested with nix-shell -p gnutar that the expected environment variable is set and behaves as expected:
$ tar -c -f foo.tar foo.txt
$ tar -v --list -f ./foo.tar
tar: Option --mtime: Treating date '@315532800' as 1980-01-01 01:00:00
-rw-r--r-- 0/0 0 1980-01-01 01:00 foo.txt
That 01:00 was suspicious to me: 315532800 is 1:00am in my timezone, so this is correct only assuming tar takes into account the current timezone when listing (not creating) the archive. I checked, and this is luckily the case: I switched timezones and the printed timestamp 'changed along' with it. So all good AFAICS 👍
|
I think the issue with this that was mentioned by @FRidh, is that we still do not have |
stale
bot
added
the
2.status: stale
|
@prusnak Any feedback on this? |
$ tar --mtime="1" --owner=0 --group=0 --numeric-owner --sort=name xf
tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
Try 'tar --help' or 'tar --usage' for more information.
$ tar xf --mtime="1" --owner=0 --group=0 --numeric-owner --sort=name
tar: --mtime=1: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
$ tar xf blah --mtime="1" --owner=0 --group=0 --numeric-owner --sort=name
tar: blah: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
$ tar --mtime="1" --owner=0 --group=0 --numeric-owner --sort=name xf blah
tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
Try 'tar --help' or 'tar --usage' for more information.tar seems to be very picky about it's arguments Switched it to use if |
Artturin
force-pushed
the
gnutar-repro-hook
branch
2 times, most recently
from
12ea7ea
to
8f31dc5
Compare
|
err from nix tests adding the reproducible flags and updating the |
|
Tested and confirmed to work if PR in nix is merged, see NixOS/nix#9225 (review) |
|
@GrahamcOfBorg eval |
|
@drupol can I let you adopt this PR? |
No comments, LGTM 👍 |
|
@RaitoBezarius I wish I could help on this, but I really don't know how to fix the remaining issues. |
|
@prusnak could I bother you with a rebase for this PR? I will try to see it to the finish line. |
prusnak
force-pushed
the
gnutar-repro-hook
branch
from
8f31dc5
to
e1edc81
Compare
Done. Rebased on top of current staging. |
drupol
force-pushed
the
gnutar-repro-hook
branch
3 times, most recently
from
95ae68a
to
b4a89d0
Compare
|
I pushed an extra commit to refactor the file and switch to |
prusnak
commented
Jan 12, 2024
drupol
force-pushed
the
gnutar-repro-hook
branch
2 times, most recently
from
08a0de7
to
b5cf705
Compare
prusnak
force-pushed
the
gnutar-repro-hook
branch
from
b5cf705
to
1a574f9
Compare
No, you don't understand. I took your changes and restructured them. Basically I took some of your cosmetic changes you did to my first commit and moved them to your second commit. |
|
Yep, sorry I've been too hasty for replying :) |
|
I'm trying to fix the issue locally. The issue is with When using For some reason, there's an issue with the |
|
I made further investigations. Currently, in this PR, there's an issue when doing the following: When replacing (The decompressing part is done in https://github.com/NixOS/nixpkgs/blame/b5cf705fc77b75f762ce1cb3c5391e5f373e34fa/pkgs/stdenv/generic/setup.sh#L1051) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation for this change
Fixes #106643
tarflags whenGNUTAR_REPRODUCIBLEis set:GNUTAR_REPRODUCIBLE =1ingenericBuild()ofpkgs/stdenv/generic/setup.shThings done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)