FreeBSD 14.1-BETA2 Now Available
https://lists.freebsd.org/archives/freebsd-stable/2024-May/002133.html
"A summary of changes since BETA1 includes: ...
Kernels are now built reproducibly."
Yay!
John
James Addison wrote that local storage can contain errors. I agree.
> My guess is that we could get into near-unsolvable philosophical territory
> along this path, but I think it's worth being skeptical of the notions that
> local-storage is always trustworthy and that the network should always
kpcyrd wrote:
> 1) There's currently no way to tell if a package can be built offline
> (without trying yourself).
Packages that can't be built offline are not reproducible, by
definition. They depend on outside events and circumstances
in order for a third party to reproduce them
John Gilmore wrote:
> It seems to me that the next step in making the Arch release ISOs
> reproducible is to have the Arch release engineering team create a
> source-code release ISO that matches each binary release ISO. Then you
> (or anyone) could test the reproducibility of
Congratulations on closing in toward Arch Linux reproducibility!!!
kpcyrd wrote:
> Specifically what I mean - given a line like this:
>
> FROM
> archlinux@sha256:2dbd72d1e5510e047db7f441bf9069e9c53391b87e04e5bee3f379cd03cec060
>
> I want to reproduce the artifact(s) that are pulled in by this,
Thanks, everyone, for your contributions to this discussion.
A quick note:
Vagrant Cascadian wrote:
> It would be pretty impractical, at least for Debian tests, to test
> without SOURC_DATE_EPOCH, as dpkg will set SOURCE_DATE_EPOCH from
> debian/changelog for quite a few years now.
Making a
>> But today, if you're building an executable for others, it's common to build
>> using a
>> container/chroot or similar that makes it easy to implement "must compile
>> with these paths",
>> while *fixing* this is often a lot of work.
I know that my opinion is not popular, but let me try
Vagrant Cascadian wrote:
> > > to make it easier to debug other issues, although deprioritizing them
> > > makes sense, given buildd.debian.org now normalizes them.
James Addison via rb-general wrote:
> Ok, thank you both. A number of these bugs are currently recorded at severity
> level
Roland, thank you for your ongoing work and reporting to make Debian
reproducible!
One question:
> * Last month a question was raised, whether the distributed sources
> are sufficient to rebuild the images. The answer is: probably yes, but
> I haven't tried.
> The chain is: source code
https://reproducible-builds.org/reports/2023-12/
"Reproducible Builds in December 2023
Welcome to the November 2023 report..."
It seems better to NOT reproduce the previous month's header quite so
accurately. ;-/
John
t. Inflating the emotional tone of the discussion is not
constructive toward the community discovering whatever contemporaneous
truths may be findable behind the various claims.
Thank you for listening.
John Gilmore
1.0
Date: Mon, 28 Jan 2019 23:18:43 -0800
Message-ID: <15495.1548746...@hop.toad.com>
From: John Gilmore
Subject: Re: [rb-general] Definition of "reproducible build"
Content-Type: multipart/mixed; boundary="===0660915116=="
Errors-To: rb-general-bounces+gnu=toad@li
David A. Wheeler wrote:
> Please don't view the text above as opposing reproducible builds.
> I think reproducible builds are the gold standard for countering subverted
> builds, and I will continue to encourage them.
> But when you can't get them (e.g., because you don't have time to patch
James Addison wrote:
> When the goal is to build the software as it was available to the
> author at the time of code commit/check-in - and I think that that is
> a valid use case - then that makes sense.
I think of the goal as being less related to the author, and more
related to the creator of
James Addison via rb-general wrote:
> In general, we should be able to
> pick two times, "s" and "t", s <= t, where "s" is the
> source-package-retrieval time, and "t" is the build-time, and using
> those, any two people should be able to create exactly the same
>
Larry Doolittle wrote:
> $ diff <(ls --full-time -u fab-ea2bb52c-ld) <(ls --full-time -u
> fab-ea2bb52c-mb)
> 22c22
> < -rw-r--r-- 1 redacted redacted 644661 2023-04-04 18:10:00.0 -0700
> marble-ipc-d-356.txt
> ---
> > -rw-r--r-- 1 redacted redacted 644661 2023-04-06
>> So, overall, I actually don't think that diffoscope has the requested
>> support, and it's not "just" a bug of failed identification.
I have been surprised at how much effort has gone into "diffoscope" as a
total fraction of the Reproducible Builds effort. Perhaps it is a case
akin to the
On 22/03/2022 13.46, Chris Lamb wrote:
> Just wondering if anyone on this list is aware of any real-world
> instances where RB practices have made a difference and flagged
> something legitimately "bad"?
The GNU compilers are already tested for complete reproducibility. We
at Cygnus Support
> Though without solving #894441 we cannot reach much higher than 80%=20
> (because 93% is the current theoretic maximum, of which we need to=20
> distract 12% binNMUs...)
Even without solving the general binNMU problem, can't you make more
packages reproducible by eliminating those packages'
> I like the idea, however what you are proposing is basically a new
> distro/fork, where you would remove all unreproducible packages, as
> every distro still has some unreproducible bits.
I suggest going the other way -- produce a distro that is "80%
reproducible" from its source code USB stick
=?utf-8?Q?Ludovic_Court=C3=A8s?= wrote:
> I agree that insisting on provenance is crucial. Dockerfiles (andsimilar)
> are often viewed as âsourceâ, but they really arenât source:the actual
> source would come with the distros they refer to (Debian,pip, etc.)
> Those distros might in turn
> We tend to write Markdown, not HTML, after all so having copy-pastable
> snippets is less compelling to me, priority-wise. This also goes for
> the non-Javascript "story" but this is less interesting as the
> situation is somewhat-satisfactory right now.
Here's a vote for making the
22 matches
Mail list logo
