Le vendredi 25 mars 2016 à 13:02:55+0800, Paul Wise a écrit :
> On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote:
> > Packaging dependencies for mailman3-hyperkitty
> Does HyperKitty depend on mailman3 or just enhance it by providing an
> archive web interface? If the latter, I would suggest calling it
> hyperkitty instead of mailman3-hyperkitty.
> > robot-detection suffers the same illness, but it's tiny, it's possible to
> > integrate it in hyperkitty, or make it optionnal.
> Embedded code copies are against Debian policy, please package it
> separately or get upstream to switch to something else.
> https://wiki.debian.org/EmbeddedCodeCopies
> Something like that sounds like it isn't possible to keep usefully
> up-to-date in Debian stable though, since the landscape of robots on
> the web will be changing continually and many will be aiming to
> emulate browsers.
> https://pypi.python.org/pypi/robot-detection
> In addition, it seems to be woefully inadequate for that since the API
> doesn't appear to take into account IP address ranges.
> It also depends on the robotstxt.org database, which would need to be
> packaged separately and is also no longer kept up to date at this
> time:
> http://www.robotstxt.org/db.html
> "This robots database is currently undergoing re-engineering. Due to
> popular demand we have restored the existing data, but
> addition/modification are disabled."
> As the page says, there is a better database of user-agents available
> http://www.botsvsbrowsers.com/
> http://www.botsvsbrowsers.com/category/1/index.html
> Unfortunately this is incompatible with the data format used by
> robotstxt.org/robot-detection:
> http://www.robotstxt.org/db/all.txt
> So you can see from the botsvsbrowsers.com data, the User-Agent field
> is often bogus or contains vulnerability attack patterns and is thus
> mostly not useful at all and should probably just be ignored by all
> web apps at this point.
> So I would suggest convincing upstream to remove whatever use of
> robot-detection is present in mailman3 or hyperkitty.

That's in progress, the only goal of this detection is to deactivate
javascript dynamic load of threads. We're thinking about alternative

> > That leaves me with django-gravatar2, that seems useful, and is still
> > developed. I heard there is some kind of "canonical" way of packaging django
> > apps. As I'm not used to that, I'm here to ask advice.
> I would suggest upstream switch from Gravatar (a centralised
> proprietary service) to Libravatar (a federated Free Software service
> that falls back on Gravatar):
> https://www.libravatar.org/

I understand your point, and I'll think about it, but my goal is to make
upstream remove obsolete dependencies. django-libravatar seems to be the
only project that bundles support for that, and it's not maintained, whereas
django-gravatar2 is still maintained.

So, for now, I think that I'd rather have a first mailman3 suite in debian,
and then, think about how to make things better. :)

> Re canonical django packaging, you may be talking about this:
> https://wiki.debian.org/DjangoPackagingDraft
> There are also lots of python-django-* packages in Debian that you
> could look at.



Reply via email to