[buildd-tools-devel] Bug#823788: Bug#823788: sbuild: non-error on stderr: "There are no foreign architectures configured"

[Adam Borowski]

On Mon, May 09, 2016 at 08:37:13AM +0200, Johannes Schauer wrote:
> Quoting Adam Borowski (2016-05-09 04:19:23)
> > I'm afraid that today's update introduced a spurious message, emitted both
> > on package build and on chroot update:
> > "There are no foreign architectures configured".

Correction: turns out this happens with sbuild-update but _not_ sbuild
itself.  I have no idea how I got the impression it's the case, sorry for
wasting your time with this part.

> > Putting aside the question whether this message fits places it's emitted, it
> > definitely shouldn't be written to stderr.  This breaks scripts that assume
> > stderr output means errors.  This includes for example cronjobs to update
> > chroots.
> 
> I want to better understand what scripts using sbuild expect from it.
>
> I don't think it has been the case before that sbuild only writes error
> messages to stderr. I see lots of output done to stderr which is merely status
> display. For example:
> 
>  | Checking available source versions...
> 
> or
> 
>  | Not removing foreign architectures: cloned chroot in use

Nope, nothing of these goes to stderr:

Good package:
[/tmp]$ sbuild tran >/dev/null;echo $?
0

Unknown package:
[/tmp]$ sbuild kjdgndfkjgh >/dev/null;echo $?
E: Failed to fetch source files
3

Invalid version:
[/tmp]$ sbuild tran_2 >/dev/null;echo $?
E: Failed to fetch source files
3

FTBFS ("failed"):
[/tmp]$ sbuild proll >/dev/null;echo $?
E: Package build dependencies not satisfied; skipping
3

FTBFS ("attempted"):
[/tmp]$ sbuild debdry >/dev/null; echo $?
2

In the last case sbuild is even too unchatty.

> As far as I understand the codebase, errors are differentiated by warnings and
> informational messages by their prefix. Errors start with "E: ". So it is true
> that many informational messages (see above) are not prefixed with a "I: " as
> they should.

It'd be nice if you could prefix "There are no foreign architectures configured"
with an "I: ", it currently sounds like a warning of some kind.

> But I do not see that this situation is actually a regression because as I
> showed above, sbuild already outputs lots of information of merely
> informational value on stderr.

Neither sbuild nor sbuild-update put information to stderr, except for this
new message in sbuild-update.

> So I need to understand:
> 
>  - which scripts break?
>  - what to scripts expect?
>  - how was the situation before any different than the one now?

In my case, crontab with:

5 3,15 * * *	sbuild-update -udcar jessie stretch unstable >/dev/null

I'd think a good part of sbuild users run sbuild-update from cron like this,
at least this seems a natural thing to do.
 
> It would also be helpful if you could write me a command for me to try out such
> that I see what exactly what breaks.

sbuild-update -udcar unstable >/dev/null
which should say nothing unless there's an error, but currently emits this
line.


Meow!
-- 
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.