> Control: tags -1 + pending
> Given that both these (bug#868049, bug#868047) are Severity: serious,
> the ‘pelican’ package is scheduled for removal from “testing” very
> I have a Git repository to develop release “3.7.1+dfsg.1-1”
> If there is no substantive objection before my evening today (Tue
> 2017-08-08 UTC+10:00), I will do a Non-Maintainer Upload of the
> release I have prepared, incorporating the patches to fix these bugs
> to allow the package to remain.
NACK from maintainer.
Shipping a broken theme by default would be a disservice to our users
(yes, I consider replacing social media images in the default theme
with nondescript images to be completely broken behaviour for end
users of the package). I'd much rather see the "notmyidea" theme
removed from the package (which is probably what I'll end up doing to
fix #868047), or pelican removed from the archive entirely.
As a side note, I object to #868049 being considered a RC bug. The
specified HTML file in the bug,
pelican/themes/notmyidea/templates/base.html, isn't even a valid HTML
file; it's merely a jinja template that will fail to open in any
browser as-is, so there's no way it can breach the privacy of the user
who installed the package (the user is not even expected to open the
files as-is in a web browser, as opposed to say, documentation
provided by doc packages). Arguing that the referenced HTML file has
the potential to be privacy-breaching (and thus RC-buggy) when used to
generate a blog with pelican is akin to arguing that gcc is RC-buggy
because it can be used to compile non-free, privacy-breaching
software, or apache/nginx is RC-buggy because it can be used to serve
up non-free, privacy-breaching data.