Friends -
On Wed, Apr 03, 2024 at 05:21:40AM +0300, Adrian Bunk wrote:
> It is documented that auto-generated Github tarballs for the same tag
> and with the same commit ID downloaded at different times might have
> different checksums.
I've run into this statement before. It's annoyingly
Chris -
On Wed, Mar 13, 2024 at 01:01:47AM +, Chris Lamb wrote:
> > TZ=UTC zip -X --latest-time "$zipfile" fab/*
> > # Note the -X flag; to be pedantic about timestamps,
> > # that means you should unpack with TZ=UTC unzip "$zipfile". See
> > #
> >
Friends -
On Fri, Mar 08, 2024 at 05:21:43PM +0100, Fay Stegerman wrote:
> * Chris Lamb [2024-03-08 12:16]:
> > Oh this is great work! So, using your tool, did you manage to solve the
> > underlying non-determinism? :)
> The original reproducibility issue this thread started with was traced back
Chris -
On Fri, Mar 08, 2024 at 11:16:06AM +, Chris Lamb wrote:
> Oh this is great work!
As the (year-old) thread originator, I agree! This fills a real gap!
> So, using your tool, did you manage to solve the
> underlying non-determinism? :)
We did figure it out, very tediously, a year
ity [sic]."
Dwight Tovey and I (Larry Doolittle) argue for reproducible builds.
I assert "Any program -- especially a mission-critical program like a
compiler -- that cannot reproduce a result at will is broken." Also
"it's commonplace to take a binary from the net, and
Michael -
On Fri, Apr 07, 2023 at 01:31:24PM +0200, Michael Schierl wrote:
> Larry's script already called touch immediately before zip. But I assume
> the nature of atime can mean that any other process may have "won the
> race" and accessed the file just in between these two lines.
That's my
Michael -
On Thu, Apr 06, 2023 at 12:11:38PM +0200, Michael Schierl wrote:
> Am 06.04.2023 um 10:28 schrieb Larry Doolittle:
> > I'm trying to make a process to generate byte-for-byte reproducible zip
> > files.
> > I got the contents identical, including times
Friends -
I'm trying to make a process to generate byte-for-byte reproducible zip files.
I got the contents identical, including timestamps and permissions.
But three bytes at the 98.08% mark (bytes 5543078 to 5543081,
out of a file size 5651451) differ between my run and a friend's run.
quot;utcfromtimestamp" one, or
> bc6a7787? Happy to try either for you, but would need a pointer
> to where to find bc6a7787. :)
bc6a7787 as found at
https://github.com/verilator/verilator/commit/bc6a7787ed271a8f52ed5b8f8a9e0e8cbba1ab38
also attached.
- Larry
commit bc6a7787ed271a8f52ed5b8f8a9
Chris -
On Mon, Feb 13, 2023 at 11:20:06AM -0800, Chris Lamb wrote:
> Larry Doolittle wrote:
> > It's timezone handling in python3 datetime.
> > doc_now = datetime.fromtimestamp(int(os.environ["SOURCE_DATE_EPOCH"]))
> ^
Vagrant et al. -
On Sat, Feb 11, 2023 at 03:01:57PM -0800, Vagrant Cascadian wrote:
> There are some python examples that might be helpful:
> https://reproducible-builds.org/docs/source-date-epoch/
Indeed, thanks! Switching from python "datetime" to "time"
makes all the difference.
> I would
Friends -
verilator 5.006-2 in Debian is not reproducible
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verilator.html
and I finally figured out why. It's timezone handling in python3 datetime.
$ cat verilator_doc.py
# Distilled from upstream verilator docs/guide/conf.py
Friends -
Probably a lot of you already saw headlines pointing to a 51-page
document released by the Linux Foundation and OpenSSF, titled
The Open Source Software Security Mobilization Plan
Sébastien -
On Sun, May 08, 2022 at 10:55:41PM +0900, Sébastien Lerique wrote:
> In a similar line, Bunnie Huang gave an interesting talk about the
> hardware trust level a few years ago, which led to the Precursor
> project.
Right. We (the world in general, and open-source and security
Ludovic and friends -
On Sun, May 08, 2022 at 12:34:47AM +0200, Ludovic Courtès wrote:
> Jan Nieuwenhuizen skribis:
> > Mes has now been ported to M2-Planet and can be bootstrapped using
> > stage0-posix[0], starting from the 357-byte hex0 binary of the
> > bootstrap-seeds[1], as was promised at
In https://reproducible-builds.org/docs/system-images/ there's a paragraph
about SquashFS metadata & compression. It's superficially OK, but points
to IMHO an obsolete fork of mksquashfs. No offense to lynxis! He did
a good job getting usable tools in our hands early on. But the main
16 matches
Mail list logo