Re: A Round of Removals
Anthony Towns <aj@azure.humbug.org.au> writes:
> > I'll downgrade the bug to important [...] instead of grave [...]
> > It is no security bug and people on platforms without signed char can
> > perfectly use the package ("without rendering it completely unusable
> > to everyone").
>
> Just fix the bug. The usual ways of doing so for bugs like this is to
> make use of gcc's -fsigned-char option, or changing your Architecture:
> line to indicate it only works on whichever architectures it works on.
Oh, Come on, please give me a break. Both of these are _not_ the right
ways to fix it. They are workarounds at best and should be replaced by
a real fix, which is in most cases trivial. Usually it is either
required to explicitly define the variable as signed or unsigned or in
most cases it must be an int anyway, like if you assign the return
value of getopt() or getchar() to it. If people would bother to read
the prototypes of library functions in manpages or such, at least half
of those problems would not exist...
> If you can't work out how to fix bugs like these, ask for help on -qa
> or -devel or IRC, don't make up excuses to put off fixing it even longer.
Here the problem was just to find somebody with PPC to confirm that it
is fixed. I just tested it and can confirm that it indeed is, the
postinst does not do an infinite loop anymore. Fortunately the fix was
a real fix and not a -fsigned-char hack.
Lukas
P.S.: I don't blame you for automatically scheduling this for removal,
but the insistence on this after the real issue was pointed out (there
was an upload which probably fixes this) is annoying. You don't have
to be perfect when assembling such a list, but you should also admit
if things have to be corrected instead of trying to be right.
Reply to: