Bug#819157: ITP: bitstruct -- Python bit pack/unpack package
Package: wnpp Severity: wishlist Owner: Brian May * Package name: bitstruct Binary packages : python-bitstruct and python3-bitstruct Version : 2.1.3 Upstream Author : Erik Moqvist * URL : https://github.com/eerimoq/bitstruct * License : Expat Programming Lang: Python2 and Python3 Description : Python bit pack/unpack package This module is intended to have a similar interface as the python struct module, but working on bits instead of primitive data types (char, int, ...). This package is required by another package I am interested in that I may or may not package in Debian at a later date (lifx-sdk project on pypi). Anybody interested in lifx-sdk please let me know. I intend to maintain it as part of the the Debian Python Modules Team.
Packaging dependencies for mailman3-hyperkitty
Hey, I'm packaging mailman3 suite, and I'm currently working on HyperKitty (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799287 for the ITP). The issue I met is that some dependencies are not yet packaged in Debian. Here is a list : * robot-detection * django-paintstore * django-gravatar2 * django-browserid The latter relies on Mozilla Persona which is due to shutdown in Nov. 2016, so I'll drop it out and suggest upstream to remove this (small) dependency. django-paintstore is not developped nor supported anymore by upstream, I'll try to look to alternatives and discuss with upstream regarding what to do. robot-detection suffers the same illness, but it's tiny, it's possible to integrate it in hyperkitty, or make it optionnal. 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'll create an ITP, and I'm willing to hear any suggestion you could make. Thanks, and cheers, -- PEB
Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: python-django-gravatar2 Version : 1.4.0 Upstream Author : Tristan Waddington * URL : https://github.com/twaddington/django-gravatar * License : MIT Programming Lang: Python Description : Essential Gravatar support for Django. Features helper methods and templatetags. A lightweight django-gravatar app. Includes helper methods for interacting with gravatars outside of template code. . It features the following: . * Helper methods for constructing a gravatar url and checking an email for an existing gravatar * Templatetags for generating a gravatar url or gravatar tag. This package provides gravatar features that are not yet present in django packages in Debian. It's also a dependency of HyperKitty, that I'm currently packaging. I'd be happy to co maintain it with the DPMT, and I look for a sponsor who knows about django packaging.
Re: Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.
Le jeudi 24 mars 2016 à 12:09:00-0400, Pierre-Elliott Bécue a écrit : > Package: wnpp > Severity: wishlist > Owner: "Pierre-Elliott Bécue" > > * Package name: python-django-gravatar2 > Version : 1.4.0 > Upstream Author : Tristan Waddington > * URL : https://github.com/twaddington/django-gravatar > * License : MIT > Programming Lang: Python > Description : Essential Gravatar support for Django. Features helper > methods and templatetags. > > A lightweight django-gravatar app. Includes helper methods for interacting > with gravatars > outside of template code. > . > It features the following: > . > * Helper methods for constructing a gravatar url and checking an email for > an existing >gravatar > * Templatetags for generating a gravatar url or gravatar tag. > > This package provides gravatar features that are not yet present in django > packages in Debian. It's also a dependency of HyperKitty, that I'm currently > packaging. > > I'd be happy to co maintain it with the DPMT, and I look for a sponsor who > knows about django packaging. Package VCS can be found here: https://gitlab.pimeys.fr/PEB/python-django-gravatar2 Package results can be found there: https://peb.pimeys.fr/packages/python-django-gravatar2/ -- PEB
Re: Packaging pythonpy
Hi, Can someone please help me on this one? I'm pretty close to finish the initial packaging work. After fixing the following issues, it will be a matter of adding a manpage and filling a RFS. * How to fix the "python-script-but-no-python-dep" lintian error? I've tried with and without pybuild and the error still persists. * How to get rid of the ".egg-info/" folder that is being packaged? Looks like "debian/clean" rules aren't working. There's a GitHub repository for the package[1]. I have intention on asking for a repository on collab-maint when the package is ready (I have write permissions to it). Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging dependencies for mailman3-hyperkitty
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 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/ 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. -- bye, pabs https://wiki.debian.org/PaulWise
