Closed dra27 closed 7 years ago
Strange, the error doesn't happen on macOS, but I can reproduce on linux.
That's disturbing! I'm getting the same error with Cygwin (although the log above was Linux)
Resource forks?
In any case the tarballs should be reproducible and in this case they are not I get an md5 of 626db1f29896221af7ed0b34a04d8c15
on linux and 1700991f570b9aaf49e6aad7d886e154
on macOS.
The tar
archives themselves are however.
And rebzipping them manually yields the same md5 (the linux one). I suspect there may be a bug in bos
on this run form.
Argh. Can't reproduce anymore topkg distrib
in topkg
now gives me the same tbz
on linux and macos.
Ah I think I found the problem if I
echo "hey" >> _build/topkg-0.9.0.tbz
and redo a topkg distrib
the md5
is not the same as if I topkg clean && topkg distrib
. I vaguely remember that during the 0.9.0
publication I redid the tagging + tarball once before it hit the internet which if larger could have lead to this situation.
It seems O_TRUNC
is missing here in bos
if we don't append...
@dra27 Thanks for the report.
Note that while tar -xjf
did not surface the bzip2
error message, a direct usage of unbzip2
did reveal the same error message on macOS.
The commit message of faed66f has the exact scenario where this could happen. I have published bos 1.5.0 which along with these constraints will prevent this from happening.
No problem - sometimes bugs surface in the weirdest circumstances!
The archive appears to be fine, though, having compared it with a git clone.