On 2020-05-15, Jason Zions via rb-general wrote:
> kpcyrd:
>> The argument was that a debian/arch rebuilder *always* needs to take
>> the buildinfo file as a rebuild input. That's the reason the buildinfo is
>> shipped inside the arch package, collecting detached buildinfo files is a
>> debian thin
On Wed, May 20, 2020 at 02:17:56PM +, Holger Levsen wrote:
> > The buildinfo is an output of the initial build and becomes an input for
> > the rebuilder, but a rebuilder is always going to use the official
> > buildinfo when verifying the official package. I'm not sure if the
> > buildinfo of
hi,
i'm just replying to two small sub points here, I still need to find
the time for a proper general reply. (Besides: YAY, I'm glad we're
finally having this discussion here and several proposals to discuss!)
On Wed, May 13, 2020 at 08:31:21PM +, kpcyrd wrote:
> The buildinfo is an output o
I'm guessing these would be
the results of multiple rebuilders. These rebuilder each offer a *status* for a
"primary key", which is currently something like "reproducible",
"unreproducible" and a few more[1].
[1]:
https://github.com/aparcar/reproducible-builds
Hi Richard,
On Tue, 2020-05-12 at 22:14 +0100, Richard Purdie wrote:
> I'm not sure how relevant this is but I can mention what the Yocto
> Project is doing. We're not a traditional distro in that we don't ship
> binaries. We do however care a lot about getting consistent results.
> Whilst we don
On Wed, 2020-05-13 at 01:08 +0200, Marek Marczykowski-Górecki wrote:
> I would also like to know how this new format relates to already
> existing and working in-toto approach. Is there some specific deficiency
> in in-toto?
Mosty I wasn't aware of in-toto and at the summit a small group came up w
Hi Santiago,
On Tue, 2020-05-12 at 17:12 -0400, Santiago Torres Arias wrote:
> >
> > To make the results accessible, store-able and create tools around them,
> > they
> > should all follow the same schema, hello *reproducible builds verification
> > format* (rbvf).
> > I'm mainly arguing that if we introduce a new concept/file format (the rbvf
> > proposed above), we should be careful it won't prevent us from doing
> > useful things (like indeed running multiple separate builds of the same
> > package at the same time, or running a 'rebuild' without access to
Le jeudi 14 mai 2020, 14:18:38 CEST Arnout Engelen a écrit :
> On Thu, May 14, 2020 at 1:55 PM Morten Linderud
>
> wrote:
> > On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> > > I don't think the buildinfo of the initial build should be a required
> >
> > input
> >
> > > for a
On Fri, May 15, 2020 at 08:51:50PM +, Jason Zions via rb-general wrote:
> kpcyrd:
> > The argument was that a debian/arch rebuilder *always* needs to take
> > the buildinfo file as a rebuild input. That's the reason the buildinfo is
> > shipped inside the arch package, collecting detached build
The discussion in Marrakesh, and thus the solution we started evolving there,
was broader than just "verification format". Participants had different
interests and goals:
- increasing the size of the rebuilder community
- improving verification
- - simplifying the process
- - decreasing p
On Thu, May 14, 2020 at 02:10:04PM +0200, Marek Marczykowski-Górecki wrote:
> > This is an implementation detail, isn't it? A buildinfo wouldn't be
> > required if
> > you are in an environment where the build environment doesn't change. But in
> > many cases, this isn't the case. Dependencies we
On Thu, May 14, 2020 at 1:55 PM Morten Linderud
wrote:
> On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> > I don't think the buildinfo of the initial build should be a required
> input
> > for a rebuilder.
> >
> > Now of course I know in practice it can be logistically convenien
On Thu, May 14, 2020 at 01:55:40PM +0200, Morten Linderud wrote:
> On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> > On Wed, May 13, 2020 at 10:31 PM kpcyrd wrote:
> > > The buildinfo is an output of the initial build and becomes an input for
> > > the rebuilder, but a rebuilder
On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> On Wed, May 13, 2020 at 10:31 PM kpcyrd wrote:
> > The buildinfo is an output of the initial build and becomes an input for
> > the rebuilder, but a rebuilder is always going to use the official
> > buildinfo when verifying the offi
On Wed, May 13, 2020 at 10:31 PM kpcyrd wrote:
> On Wed, May 13, 2020 at 09:39:40AM +0200, Arnout Engelen wrote:
> > This seems useful, though I think it is helpful to describe the
> > relationship between
> > the 'buildinfo' and such a 'rebuild result'.
> >
> > It is already common practice for
On Wed, May 13, 2020 at 09:39:40AM +0200, Arnout Engelen wrote:
> This seems useful, though I think it is helpful to describe the
> relationship between
> the 'buildinfo' and such a 'rebuild result'.
>
> It is already common practice for a reproducible build to record a
> 'buildinfo' with
> inform
I think it makes sense to clarify who's supposed to consume the output,
almost all of the data in there is only useful for plumbing by r-b and
distro people and I don't think that needs to be signed beyond transport
security.
The target "audience" of a rebuilder are package managers like pacman
an
same schema, hello *reproducible builds verification
> format* (rbvf).
>
> Rebuilders should publish those files publicly and sign them. Tools then
> collect
> those files and process them for users and developers.
>
This seems useful, though I think it is helpful to describe the
> are what they claim. This is where *reproducible builds* and *rebuilders*
> > join
> > the stage. The *rebuilders* try to recreate offered binaries following the
> > upstream build process as close as necessary.
> >
> > To make the results accessible, store-abl
plication. However it raises the questions if distributed packages
are what they claim. This is where *reproducible builds* and *rebuilders* join
the stage. The *rebuilders* try to recreate offered binaries following the
upstream build process as close as necessary.
To make the results accessible, st
ere *reproducible builds* and *rebuilders* join
> the stage. The *rebuilders* try to recreate offered binaries following the
> upstream build process as close as necessary.
>
> To make the results accessible, store-able and create tools around them, they
> should all follow
ild process as close as necessary.
>
> To make the results accessible, store-able and create tools around them, they
> should all follow the same schema, hello *reproducible builds verification
> format* (rbvf).
I'm still unsure why not just adopt the existing in-toto link m
reate offered binaries following the
upstream build process as close as necessary.
To make the results accessible, store-able and create tools around them, they
should all follow the same schema, hello *reproducible builds verification
format* (rbvf). The format tries to be as generic as possible to
24 matches
Mail list logo
