Re: Accepted minidjvu 0.8.svn.2010.05.06+dfsg-1 (source amd64)
Adam, I do not see any reason to unblock the freeze on minidjvu for
this issue.
But if you want to, and don't want the revamped autotools stuff, feel
free to just take 0.8.svn.2010.05.06+dfsg-0.1 and push it to
proposed-updates or whatever the procedure is.
Justification for the above
As discussed earlier, despite the overheated rhetoric and +dfsg NMU
version, this is *not* actually a DFSG issue.
There is a file in the upstream source tarball which is in an
unpleasant format (waf). That file is however (a) easily converted to
a nicer format, and (b) completely unused in the build process. We
have a policy of not wanting source files in such unpleasant formats
for a reason. The reason is *not* that they violate the DFSG per-se,
but rather that they're a pain in the ass: we want sources to be easy
to examine and audit both manually and automatically, and files in
weird formats complicate this. But those are not issues *in this
particular case* because the waf file in question is not used during
the build at all. The build uses autoconf instead.
Justification of updated autotools files
The old autotools files were stepping on user variables in a way that
interacted poorly with fortified compilation. The only substantive
difference in version 0.8.svn.2010.05.06+dfsg-2 is that warning and
strictness flags are not accidentally turned off when doing a
fortified (or optimized for that matter) build. This potentially
slightly improves security, and certainly makes the package more
auditable. But, they do not really change the generated binaries
(except for moving library files to multiarch dirs.)
--Barak.
--
Barak A. Pearlmutter
http://www.bcl.hamilton.ie/~barak/
Reply to: