[buildd-tools-devel] sbuild just hangs

[Roger Leigh]

On 30/07/2015 20:10, Johannes Schauer wrote:
> Hi,
>
> Quoting Roger Leigh (2015-07-30 17:13:23)
>>> That was it! Thanks! In my case the problem was that "unstable" (as I
>>> specified in the changelog) would not work either, because my chroot is
>>> called "sid". So sbuild -d sid worked just fine.
>>
>> Note that you probably want
>>
>>     -d unstable --chroot=sid
>>
>> (IIRC) since the distribution is also used when doing stuff that needs
>> the correct distribution name, e.g. making NMUs which needs a valid
>> changelog entry.  The --chroot option selects a different chroot without
>> altering the distribution in use.
>
> since I've also been bitten by this and related issues myself, I'd like to fix
> this and other issues which I think are in a similar area. But before I can
> cook up the right patch, I'd like to discuss with you what it actually is that
> sbuild is supposed to do or should be expected to do. I think many of the
> problems come from sbuild being used on autobuilders mostly but has only
> "recently" gained support to be run by users on unpacked sources.
>
> Firstly, about bug #790547: currently, sbuilds behaviour when it cannot find
> the distribution given in debian/changelog is undesirable. I wonder how to
> correctly handle this. One way would be to just print an appropriate error
> message and exit. Another way would be to fall back to sid/unstable
> automatically. Which option would you find more appropriate?

Well, I think the hanging must be a newish regression because it used to 
immediately error out if it couldn't find a suitable chroot.  I think if 
the distribution can't be found as a named chroot, or the explicitly 
specified chroot overriding the distribution name can't be found, this 
should abort the build immediately.

> Secondly, whenever I saw somebody use the -d argument, they would just use it
> as a way to select the chroot to build in. But in addition to that it will also
> override the value set in debian/changelog, thus possibly leading to wrong
> uploads as the argument to -d is put in the resulting .changes file. The sbuild
> man page doesn't even mention this effect of the -d option which is probably
> why it's used so much. The help text in the configuration file explains better
> what $distribution does but the sbuild wiki even goes so far to suggest putting
> $distribution='sid' in the configuration file which means that unless the user
> is really aware of the implications of -d, they will always create .changes
> file with sid as the distribution no matter what they put in debian/changelog.
> Is this "feature" of putting a different value in the resulting .changes file
> than the maintainer put in their debian/changelog useful for anything?

Yes.  In the general case for autobuilding, we don't have the 
distribution until after the build starts--it comes from the changelog 
not the dsc, so we don't have the information until after we're already 
running in the chroot.  This could be rearchitected, but it would be 
quite painful and come with a significant cost since you'd need to copy 
the downloaded source into the build chroot; and when all the 
information you have is foo_version you can't even download it without 
the apt package list from inside the chroot, so you have to make an 
up-front decision about the chroot to use before you even get the 
source.  This even applies to local sources--if you build from a .dsc, 
you have to unpack it to get this information, and that could be very 
expensive for large source packages.

> I'd like to put much more warnings about the usage of the -d option up in the
> man page, in the help text in sbuildrc and in the wiki.

That would certainly be very useful and appreciated, I'm sure.

> But if there is no real world use for putting a different distribution value in
> the generated .changes file than in the input debian/changelog, then how about
> deprecating this functionality?

If there's a simple way to do this without any major downsides, I'm sure 
it would be an improvement.  But as I described above, getting the input 
debian/changelog is the difficult part.  I would have implemented this 
as the default years ago if it was a simple change.

> Thirdly, I think that the default sbuild configuration should do the right
> thing when building Debian packages. This means, that even if the target
> release in debian/changelog is UNRELEASED, then sbuild should default to build
> for "sid" (or another default value settable in the sbuildrc). If the
> distribution in debian/changelog is sid, then sbuild should also consider the
> chroot called "unstable" and the other way round.

I once implemented exactly this functionality, and I was castigated for 
it when people uploaded packages unintentionally built against the wrong 
distribution, so it was backed out rather rapidly.  The intention was 
good, and it even warns you about it in colour that there's a mismatch, 
but it's inevitable that people will fail to see it and also fail to 
check the .changes.

I think you could make a case for UNRELEASED defaulting to unstable. 
For everything else it's risky ground.  I don't think using sid is 
generally advised?  Better to use unstable everywhere?

> Fourthly, the -c option choose the chroot to use. But I think one of the
> reasons why people rather use -d to choose the chroot is because it's so much
> shorter to write -d sid compared to writing -c sid-amd64-sbuild. There should
> be an equally short option to select the chroot but *without* overwriting the
> distribution value in the resulting .changes file.

This is down to configuration.  If you've configured schroot with the 
appropriate name(s) and aliases then you never, ever, need to use 
--chroot since the -d name will always map to a valid chroot.  Even for 
cross-building.

>> Note that you can add "aliases=unstable-amd64-sbuild" or equivalent for
>> your distribution/arch to your schroot configuration, which will make it
>> select the appropriate distribution when you use "-d unstable".
>
> Fifthly, I think this should be the default behaviour for the sid/unstable
> pair.  I'm just unsure whether schroot should set this default or whether
> sbuild should translate sid to unstable and the other way round?

It's not the job of schroot to impose any policy here.  It knows nothing 
about sbuild.  On the sbuild side, sbuild-createchroot is the place 
where such mappings could be added as aliases at initial debootstrap of 
the chroot.  But as a general point, I would question the use of "sid" 
in place of "unstable".  Just add the "unstable", "unstable-amd64" or 
"unstable-amd64-sbuild" alias(es) and it will automatically select the 
right chroot.  However, automatically adding the unstable-amd64-sbuild 
alias if you debootstrap a sid chroot is absolutely fine--though it 
might need a check for the name already being in use.


Regards,
Roger