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

HW42 hw42 at ipsumj.de
Mon Dec 19 06:37:00 UTC 2016


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 the user interface simple. My expectation for this mode
>>>> of operation would be for the builder to recreate the old build as closely as
>>>> possible.
>>>
>>> I agree but would add that they should also have the ability to tell the user
>>> if the checksums of the re-compiled packages do or do not match the information
>>> in the supplied .buildinfo file.
>>
>> I suppose; please just make sure such a failure is easily distinguishable
>> from a failing build.
> 
> My plan would be to add it as a success/failure line next to the lintian or
> autopkgtest status at the bottom of the build log.
> 
>>> I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
>>> sbuild/pbuilder use a common tool to figure out the right lines for the
>>> sources.list inside the chroot. I just want to have .buildinfo support for
>>> sbuild in Stretch and if either solution is not in unstable soon, then my
>>> plan is to just add .buildinfo support to sbuild myself so that it's still
>>> included in the next Debian stable release.
>>
>> Having this just inside sbuild for stretch and refactoring it out later
>> if necessary works for me, but I'm not sure if HW42 and/or Mattia have
>> thoughts about the pbuilder side?
> 
> Putting them back in CC.
> 
> I am especially waiting for a response from HW42 who volunteered to "keep an
> eye on it" but who didn't come back to my pings on IRC yet.
> 
> HW42: I need to know what your plan is for Stretch so that I can decide what to
> include in the next sbuild release.

Sorry about the late reply.

I didn't had any plans sofar for stretch. Given that a) the .buildinfo
format it self b) the services around .buildinfo c) the interface of
debrebuild (or buildinfo-utils, or whatever) is not really
clear/finished yet I would expect that one need anyway the backports
version. If you think otherwise we can of course push to get the current
version into stretch.

>> I note that we're only getting started on working with .buildinfo files. It
>> seems possible that we encounter enough common tasks that something like a
>> 'buildinfo-utils' package will be warranted, in which case a 'buildinfo
>> find-debs' command would fit in there.
> 
> I'm all in for breaking out common functionality into tools used by multiple
> parties.

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161219/6c21e6d1/attachment.sig>


More information about the Buildd-tools-devel mailing list