Closed PeakKS closed 9 months ago
Oops, I see what happened. :(
I forgot to use the -a, --auto-compress
or -J, --xz
options when creating the toolbox-0.0.99.4-vendored.tar.xz
, because I somehow developed the wrong idea that in recent times the compression algorithm is always determined from the archive's suffix. I now realize that it's only true when extracting from the archive.
Sorry about that. I wish meson dist
had a hook to automate generating an unvendored and a vendored tarball.
Can you work around this downstream until we have a newer release? I don't want to replace the existing release tarball because it will break the hashes.
You can also add the vendoring to the unvendored tarball:
$ tar -xf toolbox-0.0.99.4.tar.xz
$ cd toolbox-0.0.99.4/src/
$ go mod vendor
...
Can you work around this downstream until we have a newer release? I don't want to replace the existing release tarball because it will break the hashes.
You can also add the vendoring to the unvendored tarball:
$ tar -xf toolbox-0.0.99.4.tar.xz $ cd toolbox-0.0.99.4/src/ $ go mod vendor ...
Ah yes should have specified that I already am working around it, just wanted to bring the issue to light.
Ah yes should have specified that I already am working around it, just wanted to bring the issue to light.
Okay! That's fantastic.
I will try to be careful next time. I hope I have learnt my lesson. :)
Describe the bug The "vendored" release tarball is not actually an xz compressed tarball
Steps how to reproduce the behaviour Download the vendored tarball from releases Run the "file" command on it to see what file it is
Expected behaviour The file should report "XZ compressed data, checksum CRC64"
Actual behaviour The file reports "POSIX tar archive (GNU)"
Screenshots![image](https://github.com/containers/toolbox/assets/48360696/b827a042-999c-4704-8e4e-0c4aa4fc59f7)
Additional context This doesn't cause errors when doing a
tar xf
, but it does cause an ebuild to die when trying to unpack the tarball because it isn't what it says it is.