On Fri, 2024-04-19 at 00:11 +0200, kpcyrd wrote:
> does somebody know what the bootstrapping status of autotools is?
>
> Also, is something considered "bootstrapped from source" if the build
> is making use of a pre-generated `./configure` script that is 25k
> lines long?
>
> In my opinion
On Tue, 2024-04-02 at 10:11 -0700, John Gilmore wrote:
> 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
> >
On Wed, 2024-03-06 at 14:57 +, Holger Levsen wrote:
> On Tue, Mar 05, 2024 at 11:51:16PM +0000, Richard Purdie wrote:
> > FWIW Yocto Project is a strong believer in build reproducibiity
> > independent of build path and we've been quietly chipping away at
>
On Tue, 2024-03-05 at 08:08 -0800, John Gilmore wrote:
> > > 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
On Thu, 2023-11-09 at 22:12 +0100, kpcyrd wrote:
> > - $E$, the set of all possible software environment
>
> I'm not aware of any project having this in scope. It's crucial for
> projects to document their build environment (see buildinfo files) and
> matching it when reproducing the build. If
We recently noticed igt-gpu-tools failed our reproducibility tests with
seemingly no changes made to it.
The change was the string g2b29e8ac becoming g2b29e8ac0:
http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230917-br60if6q/packages/diff-html/
Investigating showed this comes from
On Wed, 2023-06-07 at 15:50 +0200, Martin Monperrus wrote:
> We're researching on build reproducibility.
>
> Are you aware of any project where reproducibility is checked in a
> continuous integration pipeline?
>
> (For instance, by building twice in CI and comparing the output)
>
> If
On Sat, 2023-02-25 at 15:56 +, Anthony Harrison wrote:
> This post follows on a chat with Chris Lamb and he felt it was worthy
> of a wider readership and debate.
> As I am sure everyone is aware, there is a growing interest in
> Software Bills of Materials (SBOMs) as a way of improving
On Sat, 2022-06-11 at 11:39 +0200, Jelle van der Waa wrote:
> Hey,
>
> On 10/06/2022 19:55, Richard Purdie wrote:
> > On Fri, 2022-06-10 at 13:52 -0400, David A. Wheeler wrote:
> > > All, FYI:
> > >
> > > The current LLVM-based Rust compiler
On Fri, 2022-06-10 at 13:52 -0400, David A. Wheeler wrote:
> All, FYI:
>
> The current LLVM-based Rust compiler generates builds that
> aren't (easily) reproducible, at least in part because full paths
> to the source code is in the panic and debug strings recorded in
> the generated executable.
Hi,
On Tue, 2022-03-22 at 12: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"?
>
> Pretty sure that everyone here believes that reproducible builds *can*
On Sat, 2021-10-23 at 21:41 -0400, David A. Wheeler wrote:
>
> > On Oct 23, 2021, at 3:23 PM, Arthur Gautier wrote:
> >
> > I would expect Github to use the tar implementation of git-archive (or
> > libgit2). git-archive is specifically designed to be reproducible.
>
> I don’t know if it does,
On Tue, 2021-04-06 at 10:39 -0400, David A. Wheeler wrote:
> Press releases are not the best way to learn technical details :-).
>
> I suggest adding a link to more details e.g.:
>
> See https://sigstore.dev/what_is_sigstore/“>”What is sigstore"
> for more details.
>
> I think mentioning
On Sat, 2021-01-30 at 12:22 +, Holger Levsen wrote:
> On Fri, Jan 29, 2021 at 05:39:01PM -0500, David A. Wheeler wrote:
> > What would be especially helpful for accelerating deployment of
> > verified reproducible builds in a few key places? E.g., what tools,
> > infrastructure, people paid to
On Mon, 2020-12-21 at 15:57 -0500, David A. Wheeler wrote:
> I think these things need to happen in stages. Broadly:
> 1. Get key applications & libraries reproducible (assuming toolchains
> are okay)
> 2. Establish independent processes that *check* that the binaries are
> what they’re supposed
On Tue, 2020-05-12 at 11:00 -1000, Paul Spooren wrote:
> at the RB Summit 2019 in Marrakesh there were some intense discussions about
> *rebuilders* and a *verification format*. While first discussed only with
> participants of the summit, it should now be shared with a broader audience!
>
> A
On Thu, 2019-10-03 at 11:20 +0100, Chris Lamb wrote:
> Hi all,
>
> Please review the draft for September's Reproducible Builds report:
>
> https://reproducible-builds.org/reports/2019-09/?draft
>
> … or, via the Git respository itself:
>
>
>
On Wed, 2019-06-12 at 14:42 +0200, Sebastian Huber wrote:
> Hello Richard,
>
> On 07/06/2019 14:42, richard.pur...@linuxfoundation.org wrote:
> > > How did you propagate the settings to the newly built cross
> > > compiler
> > > invoked to build the target libraries?
> > We already pass in
On Fri, 2019-06-07 at 13:41 +0200, Sebastian Huber wrote:
> Hello,
>
> has someone tried to do a reproducible build of a GCC cross-compiler?
> I
> am not interested in a native GCC. I guess it needs some tweaks in
> the
> build system of GCC, e.g.
>
> * use of -frandom-seed=???
>
> * export
On Thu, 2019-02-14 at 12:25 -0800, John Gilmore wrote:
> > 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
20 matches
Mail list logo
