Leopold, thanks for the report.
Yann,
On 12/11/14 07:32 PM, Yann Dirson wrote:
> OTOH, neither the manpage nor --help explain what this value for
> --fullscreen should be. It rather looks like a bug in recent
> tuxpaint: downgrading to 0.9.21-1.1 (and tuxpaint-config 0.0.12-3
> accordingly) shows that the problem was indeed introduced in 0.9.22.
>
> Bumping as RC since it impacts a 3rd-party package, but not to "grave"
> as gcompris is not rendered unusable.
It's certainly muddled. By trial and error I found --fullscreen=yes and
--fullscreen=no work. I'm going to take this to upstream for further
discussion. See this in src/parse.gperf, from which the command-line
parser is generated:
fullscreen, MULTI(parsertmp_fullscreen_native)
See also, in src/tuxpaint.c:
if(tmpcfg.parsertmp_fullscreen_native)
{
// should conflict with other fullscreen/native_screensize setting?
if (!strcmp(tmpcfg.parsertmp_fullscreen_native, "native"))
native_screensize = 1;
fullscreen = strcmp(tmpcfg.parsertmp_fullscreen_native, "no");
}
So the three values are "native", "no", and "yes" (or indeed anything else).
Is that enough to get gcompris working again? If so, I would be inclined
to drop the severity to normal and after I've received a patch from
upstream for both the help and the man page, upload a new version with
the patch applied. I'm pretty sure it's meant to work this way (i.e.
isn't, in fact, broken, but just poorly documented.)
Ben
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
