Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, On Wed, Dec 21, 2016 at 10:52:54AM +0100, Johannes Schauer wrote: > because somebody who *does* care about this and uses their own local mirror > will have their setup subverted by this feature without any warning. well, I (the user) feed it with a .buildinfo files, which needs old versions.

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Holger Levsen (2016-12-21 10:32:07) > On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote: > > > (though I'm not sure I fully understand why not assume -rb if > > > foo.buildinfo is given - I do understand for foo.changes…) > > > > - Because I'm not so sure that the

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote: > > as long as there's a short version of --rebuild-and-verify=foo.buildinfo > > such as (for example) -rb=foo.buildinfo fine with me… :) > the -r short option is still free. sounds good. > > (though I'm not sure I fully

Bug#774415: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Quoting Holger Levsen (2016-12-21 02:08:57) > On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote: > > Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo > > option > > to sbuild sounds like the most sane thing to do. It would even not require > > the > >

Bug#774415: From srebuild sbuild-wrapper to debrebuild

On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote: > Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option > to sbuild sounds like the most sane thing to do. It would even not require the > existing interface to change (the positional argument is a single

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Holger Levsen (2016-12-19 10:35:53) > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote: > > Other ways to solve this problem include: > > - only accept .buildinfo files that include the .dsc filename and checksum > > - accept .changes files that reference both the

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Johannes Schauer (2016-12-20 13:49:27) > Currently, a buildinfo file does not specify which artifacts were supposed to > be built (source,any,all). as guillem points out to me on #debian-dpkg, the Architecture field lists exactly that. It will contain "source" if the source package

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Johannes Schauer (2016-12-19 10:02:58) > I also came up with another question: and as I'm implementing this, here yet another: Currently, a buildinfo file does not specify which artifacts were supposed to be built (source,any,all). What should happen if the buildinfo file was for an

Bug#774415: From srebuild sbuild-wrapper to debrebuild

On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote: > Other ways to solve this problem include: > - only accept .buildinfo files that include the .dsc filename and checksum > - accept .changes files that reference both the .buildinfo and the .dsc those two seem sensible to me.

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting HW42 (2016-12-19 07:37:00) > So you (at least josch and ntyi) seem to prefer to have the user facing part > in sbuild/pbuilder and the common functionality in some kind of library. How > should the "library" interface look like for sbuild? pbuilder is written in bash, so a plain-text

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi, > > Quoting Niko Tyni (2016-12-17 13:40:32) >> On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote: >>> Quoting Niko Tyni (2016-12-15 14:04:19) In general, I like the concept of sbuild/pbuilder accepting .buildinfo files as input. This makes

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Niko Tyni (2016-12-17 13:40:32) > On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote: > > Quoting Niko Tyni (2016-12-15 14:04:19) > > > In general, I like the concept of sbuild/pbuilder accepting .buildinfo > > > files > > > as input. This makes the user interface

Bug#774415: From srebuild sbuild-wrapper to debrebuild

On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote: > Quoting Niko Tyni (2016-12-15 14:04:19) > > In general, I like the concept of sbuild/pbuilder accepting .buildinfo files > > as input. This makes the user interface simple. My expectation for this mode > > of operation would be

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting Niko Tyni (2016-12-15 14:04:19) > > But then on IRC, HW42 suggested to approach this problem differently. > > Instead of integrating the functionality of figuring out the right > > repositories to reproduce the contents of a buildinfo file into sbuild, > > write a tool that can drive

Bug#774415: From srebuild sbuild-wrapper to debrebuild

On Tue, Aug 02, 2016 at 10:49:00PM +0200, Johannes Schauer wrote: > But then on IRC, HW42 suggested to approach this problem differently. Instead > of integrating the functionality of figuring out the right repositories to > reproduce the contents of a buildinfo file into sbuild, write a tool

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting HW42 (2016-11-17 05:10:00) > After discussing this in the irc meeting yesterday I propose that: > > - we keep it as a separate tool. > - put it in a git repo under >https://anonscm.debian.org/git/reproducible/ > - We have more than enough DDs who are willing to sponsor

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi, > > On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer wrote: >> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer wrote: >>> But then on IRC, HW42 suggested to approach this problem differently. >>> Instead of integrating the

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi all, > > On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer wrote: >> I was thinking about this issue again and thought that instead of creating a >> wrapper for sbuild which then uses a chroot-setup hook to install the >> dependencies, what I should

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi, > > On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer wrote: >> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer wrote: >>> But then on IRC, HW42 suggested to approach this problem differently. >>> Instead of integrating the

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer wrote: > On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer wrote: > > But then on IRC, HW42 suggested to approach this problem differently. > > Instead of integrating the functionality of figuring out

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi all, On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer wrote: > I was thinking about this issue again and thought that instead of creating a > wrapper for sbuild which then uses a chroot-setup hook to install the > dependencies, what I should instead do is to let sbuild

Bug#774415: From srebuild sbuild-wrapper to debrebuild

Hi, On Mon, 09 May 2016 21:07:40 +0200 Johannes Schauer wrote: > The main disadvantage of the current srebuild implementation is, that it will > only make use of a single snapshot.d.o timestamp. This makes it impossible to > reproduce situations where packages are not built in