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.
