Daniel Leidert wrote:
If I understand this case correctly then the problem is quite likely that
this message

>> Unknown media type in type '...'

is output to stdout instead of stderr.

Programs/scripts that have to be able to run under debconf are not allowed
to output to or read input from stdout/stdin.

If this is what's going on it's an RC bug in the relevant package.
Possibly it can be worked around by redirecting its output at the call
sites.

But then again, I may have misunderstood this completely...

Cheers,
FJP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkkIueIACgkQgm/Kwh6ICoSatQCgzavIIetTFNu3NI3BuiKsIEGB
kNIAn1xmFcTeuoSSeHIY4MIVBmT7vVaC
=L8gR
-----END PGP SIGNATURE-----

Frans Pop wrote:
> Daniel Leidert wrote:
> If I understand this case correctly then the problem is quite likely that
> this message

>>> Unknown media type in type '...'

> is output to stdout instead of stderr.

> Programs/scripts that have to be able to run under debconf are not allowed
> to output to or read input from stdout/stdin.
[...]

Afaiui the program is not running /under/ debconf, it is started (and
supposed to be stopped) before debconf is initialized.
cu andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Mittwoch, den 29.10.2008, 20:30 +0100 schrieb Frans Pop:
> Daniel Leidert wrote:
> If I understand this case correctly then the problem is quite likely that
> this message
>
> >> Unknown media type in type '...'
>
> is output to stdout instead of stderr.
>
> Programs/scripts that have to be able to run under debconf are not allowed
> to output to or read input from stdout/stdin.

update-mime-database is called inside the postrm (I posted the postrm in
my mail) and issues some warnings. You can simply reproduce the issue by
taking any package using debconf and adding an echo command to the
postrm script:

echo "Make me fail."

And you should be able to reproduce the problem. E.g. use this postrm to
reproduce:

> #!/bin/sh
> set -ex
> echo "Make me fail."
> # Automatically added by dh_installdebconf
> if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
> . /usr/share/debconf/confmodule
> db_purge
> fi
> # End automatically added section

You don't need more. For some reason "Make me fail." is given as
argument to the debconf confmodule:

[..]
> + db_purge
> + _db_cmd PURGE
> + IFS= printf %s\n PURGE
> + IFS=
> read -r _db_internal_line
> + RET=20 Unsupported command "make" (full line was "Make me fail.") received from confmodule.
> + return 20

Regards, Daniel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Right. This is getting somewhat beyond my knowledge of debconf internals,
but here is what happens.

Daniel Leidert wrote:
> You don't need more. For some reason "Make me fail." is given as
> argument to the debconf confmodule:

The full debug log and the sourced confmodule file fairly clearly show
what happens.

This is where the execution of the script starts:

+ echo 'Make me fail.'
Make me fail.
+ '[' purge = purge ']'
+ '[' -e /usr/share/debconf/confmodule ']'
+ . /usr/share/debconf/confmodule

Here confmodule is sourced. If you look at what it does when there is
no frontend running yet, the behavior becomes clear:


if [ ! "$DEBIAN_HAS_FRONTEND" ]; then
PERL_DL_NONLAZY=1
export PERL_DL_NONLAZY
# Since there is no FrontEnd, this program execs a FrontEnd.
# It will then run a new copy of $0 that can talk to it.
if [ "$DEBCONF_USE_CDEBCONF" ]; then
exec /usr/lib/cdebconf/debconf $0 "$@"
else
exec /usr/share/debconf/frontend $0 "$@"
fi
fi


No frontend is yet running, so one is started and the script gets
re-executed *under debconf*!

++ '[' '!' '' ']'
++ PERL_DL_NONLAZY=1
++ export PERL_DL_NONLAZY
++ '[' '' ']'
++ exec /usr/share/debconf/frontend ./test purge

Which is exactly what happens here:

+ echo 'Make me fail.'

So, we get another echo to stdout and _that_ is the one that causes
the eventual error.

+ '[' purge = purge ']'
+ '[' -e /usr/share/debconf/confmodule ']'

The next line is now basically a no-op as it has already been sourced:

+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ '[' '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
+ db_capb
+ _db_cmd 'CAPB '
+ IFS=' '
+ printf '%s\n' 'CAPB '
+ IFS='
'
+ read -r _db_internal_line
+ RET='20 Unsupported command "make" (full line was "Make me fail.")
received from confmodule.'
+ case ${_db_internal_line%%[ ]*} in
+ return 20

Don't ask me why this is done the way this is done, but AFAIK debconf has
always worked this way. The correct version of your test script would be:


#!/bin/sh
set -ex

. /usr/share/debconf/confmodule

echo "Make me fail." >&2

# Automatically added by dh_installdebconf
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
db_capb
fi
# End automatically added section


So, the automatic snippets work fine as long as they are the sole content
of a maintainer script, but if not they need to be properly wrapped. And
use of stdin/stdout is not allowed _anywhere_ in the script, even if it
happens before debconf gets sourced (which is why for D-I we always
source confmodule at the top of scripts).

Maybe not intuitive, but that's life. And again, don't ask me why.

/me suspects this may be cause for some nice mass-filing of RC bugs :-(

Cheers,
FJP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkkI4fsACgkQgm/Kwh6ICoTCkACg1fOIYJiFcbsN097CsNSXNIAZ
Uy4AoKNIZVwYPBdywNvq1ENqa+kzpX2D
=QMUq
-----END PGP SIGNATURE-----

Am Mittwoch, den 29.10.2008, 23:21 +0100 schrieb Frans Pop:
> Right. This is getting somewhat beyond my knowledge of debconf internals,
> but here is what happens.
>
> Daniel Leidert wrote:
[..]
> The full debug log and the sourced confmodule file fairly clearly show
> what happens.

First thanks for your explanation. I will read it carefully. Just let me
ask something about this statement:

[..]
> So, the automatic snippets work fine as long as they are the sole content
> of a maintainer script, but if not they need to be properly wrapped. And
> use of stdin/stdout is not allowed _anywhere_ in the script, even if it
> happens before debconf gets sourced (which is why for D-I we always
> source confmodule at the top of scripts).

The policy states, that output by maintainer scripts and programs called
in maintainer scripts "should" be avoided (3.9). There is no "must".
Maybe you refer to prompting (3.9.1)? IMHO there can be many reasons,
why a program may issue a note or a warning to STDOUT and except
redirecting everything to /dev/null or STDERR we cannot make sure, that
there is no output. So I think, that debconf needs a fix here.

> Maybe not intuitive, but that's life. And again, don't ask me why.

I agree, that this is not intuitive.

> /me suspects this may be cause for some nice mass-filing of RC bugs :-(

@debconf devs: A chance to fix this in debconf?

Regards, Daniel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org