[buildd-tools-devel] [GIT] sbuild branch master updated. debian/sbuild-0.65.2-1-22-g6d705b3

[Johannes Schauer]

Hi,

Quoting Aurelien Jarno (2015-09-06 19:59:07)
> On 2015-08-31 12:05, Johannes Schauer wrote:
> > I saw that it does not seem to be customary to update debian/changelog
> > along with any commit that warrants mentioning there. To keep track of the
> > bugs that were closed, I mentioned them in my commit messages.
> 
> I don't know if it is a good idea or not. I think it's done to ease
> cherry-picking patches between branches.

yes, that makes sense.

I also wonder about the distinction between the sbuild Debian packaging and the
"upstream" part of it.

Is sbuild intended for Debian only? Then why is it not a native package?

If it is not, then why is the debian directory part of the upstream git (and
not at least in a separate branch)? In that case, a new upstream release would
also just say in d/changelog:

 - new upstream release (Closes: #11111, #22222, #33333, ...)

Instead of mostly being a verbatim copy of the git commit messages between now
and the last release (which is something I'd expect from a native package).

So right now it looks like a weird mixture to me. How is this intended to be
handled?

> > Please comment in the respective bugs if you find my solution to be
> > unsatisfactory (maybe CC me directly just to make sure).
> > 
> > Please reply here for general comments about contributing to sbuild. As this is
> > my first push, I might've made some mistakes.
> 
> I just gave a quick look to all the patches. I haven't looked at them in
> details, but I have rather looked at what they are doing. I think they
> are fine overall, but I have a few comments:
> 
> - d720bb7a: add --build-path option: The default fstab in sbuild and
>   buildd mode, /build is actually from /var/lib/sbuild/build and it is
>   customary to mount a big partition there as build space. I don't know
>   how we should handle that with --build-path, maybe at least emit a
>   warning when this option is used while /build is mounted by the
>   schroot fstab?
>   
>   For the official debian build daemons, we don't use a separate
>   partition (we have a fstab different from the default one) so that
>   should not be a problem.

Is bind-mounting /var/lib/sbuild/build to /build inside the schroot useful for
any purpose these days? If the user wants to use a big extra partition for
scratch space, then would they not mount that partition to
/var/lib/schroot/unpack/ so that the whole chroot sits on that separate drive
or partition?

Would anything break if /var/lib/sbuild/build was not bind mounted to /build
inside the schroot in the default schroot configuration anymore? Users who
really do want sbuild to utilize a separately mounted device should use
/var/lib/schroot/unpack/ anyways in the first place, no?

As I see it, bind mounting all the possible (because of access rights) build
locations like /tmp, /build or /home in the schroot is mutually exclusive with
reproducible build paths. Because then it is not possible to do two builds of
the same source package in parallel because the build paths will be the same.

> - About the various cross-build commits, have you tested the --arch-all-only
> option in the non-cross-build mode? I had difficulties to get it implemented,
> as the various options I tried earlier triggered the cross-build code.

I just successfully natively compiled debhelper with and without
--arch-all-only.

Could you also update the sbuild man page with some documentation for the new
option?

> I think we should backport 7780b28a asap to the buildd-0.65 branch (the one
> we use on the build daemons), but I would prefer to wait for more tests
> before backporting the cross-build commits.

AFAIK Luca Falavigna (CC-ed) is running sbuild from experimental which includes
7780b28a and the cross-build commits. Maybe Luca can comment on the experience
with them?

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150913/bcc6ff0a/attachment.sig>