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

Sun Sep 13 12:35:40 UTC 2015

Hi,

On 2015-09-13 12:55, Johannes Schauer wrote:
> 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?

I have to say I don't really know about that. Looking at the changelog,
the package was a native package up to version 0.56, then the following
version is the 0.57.0-1, with this entry in the changelog:

  * Note: All upstream changes are now in an upstream ChangeLog.

Then except for non-maintainer uploads it seems all uploads to debian
have been done with a -1 revision, so it means that the "new upstreams"
and Debian uploads are synchronized.

So it looks like it has been done so that sbuild can be used outside of
Debian, but I don't know if it has been the case in practice.

> > > 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?

I don't know if it is still useful, but it is still how it is advertised
to do in the schroot package.

> 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?

I think the point of having a separate build partition is not a question
of disk space, but that you can examine the build tree when not purging
it after a failing build (--purge-build option). Not using a separate
/build partition means everything would be deleted once the build is
finished (failed or successful).

Besides that it should work fine, as on the Debian build daemons we use
a big (50G or more) tmpfs partition for the unpack directory and no
specific build directory.

> 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.

Yes, it's a point we raised during the reproducible builds BoF. So it
looks like a /build directory and using a reproducible build path is not
something achievable. We probably don't want to support both at the same
time, but we should probably warn users who try to use both at the same
time.

> > - 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.

Great, thanks for the test.

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

Thanks for pointing that, I have just done it.

> > 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?

Indeed it would be nice if we can have some feedback, either from Luca
or from users once it is uploaded to unstable. Anyway from the buildd
point of view, cross-build support is blocked from the wanna-build side.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                 http://www.aurel32.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150913/a0b6fe07/attachment.sig>