Bug#819154: ITP: golang-github-cyberdelia-go-metrics-graphite -- Graphite client for the go-metrics
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: golang-github-cyberdelia-go-metrics-graphite Version: 0.0~git20151204 Upstream Author: Timothée Peignier License: BSD-2-clause URL: https://github.com/cyberdelia/go-metrics-graphite Description: Graphite client for the go-metrics This is a reporter for the go-metrics (https://github.com/rcrowley/go-metrics) library which posts metrics to Graphite. This package is a dependency of "docker-containerd" which is a dependency of docker-1.11. signature.asc Description: This is a digitally signed message part.
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.
MBF: php5 -> php7.0 transition
Hey fellow developers, we (as in pkg-php-* teams) been working on PHP 5.x to PHP 7.0 transition for some while and I think it's time to start a MBF to get this sorted out before the next freeze. There are several main things to be done: 1. You need to change all dependencies from php5- to php- 1a) internal PHP extensions built from src:php7.0 are solved by php- depending on default PHP version 1b) external PHP extensions (from PECL) are named just php- to allow binNMUs when we bump PHP major or minor version NOTE: every extension package list php-, php-, php- in Provides, if you require specific extension, please try to depend on that specific extension. Here I would strongly recommend using pkg-php-tools if you can, as the simple rebuild could fix your package to be compatible with new PHP packaging. 2. You need to check that the PHP code inside your package is compatible with PHP 7.0 - you can do that now in unstable with existing packages - binary packages from src:php5 and src:php7.0 are coinstallable, so you can do `apt-get install php5-fpm php-fpm` and configure your web server correctly to use either PHP 7.0 or PHP 5.6. Everybody depending on PHP is also welcome to join our mailing lists where we discussed the changes that have been done (that is pkg-php-main for interpreter packaging, pkg-php-pecl for PHP extensions and pkg-php-pear for PEAR modules). I am also suggesting that instead of packaging PECL or PEAR stuff on your own, you are welcome to join the packaging teams and help others with packaging and be helped with your packages. Some of the really old and upstream-orphaned code will have to be dropped from Debian. Please take it as a good sign to increase overall quality of PHP codebase in Debian :). And last warning - really don't depend on versioned variants of the PHP packages, that will prevent automatic transitions between PHP major.minor versions. If you really think you need to do so, please come and explain your reasons to our mailing list before you do so. Cheers, Ondrej P.S.: The new packaging structure allows multiple versions of PHP to happily coexist, but this won't be supported from within a stable Debian release, but it allows us (the PHP team can't wait for bikeshed repos) and external package providers to host that externally -> you can find some of the work in https://packages.sury.org/php/ for Debian jessie and ppa:ondrej/php for Ubuntu (trusty and higher). dd-list follows: Alan Boudreault mapserver (U) Alessandro De Zorzi phamm (U) php-fpdf Alex Denvir libexpect-php5 Alexander Wirt icinga-web (U) nagios3 (U) nagvis (U) Anders Waananen nordugrid-arc (U) Andreas Tille gdcm (U) stacks (U) Andrew McMillan awl (U) davical (U) Antoine Beaupré drush Antonio Ospite tweeper Bas Couwenberg geos (U) mapserver (U) Bdale Garbee freedombox-setup (U) Benoit Mortier fusiondirectory (U) php-auth-sasl (U) php-net-ldap2 (U) Bhuvan Krishna php-mf2 Bjoern Boschman phpsysinfo serverstats Cacti Maintainer cacti Cameron Dale libphp-adodb Christian Bayle fusionforge (U) libphp-jpgraph Christoph Berg phppgadmin (U) Christoph Haas zabbix (U) Cleto Martín zeroc-ice (U) Craig Small jffnms wordpress Cyril Bouthors php-redis (U) php-sepa-direct-debit Cyril Bouthors php-sepa-direct-debit (U) Cyril Bouthors php-sepa-direct-debit (U) Dain Nilsson yubikey-ksm (U) yubikey-val (U) Daniel Beyer symfony (U) twig (U) Daniel Kahn Gillmor php-net-publicsuffix Daniel Pocock yubikey-ksm (U) yubikey-val (U) Daniel Pocock ganglia-web (U) loganalyzer (U) simpleid (U) simpleid-ldap (U) Dario Minnucci dotclear php-cache php-net-ftp php-net-imap php-net-ipv6 php-net-url2 php-net-whois php-rrd (U) php-validate php-xml-rpc2 rtgui Dave Beckett redland-bindings Davical Development Team awl davical David Prévot assetic (U) doctrine (U) google-api-php-client (U) google-auth-library-php (U) libjs-jcrop (U) owncloud (U) pear-channels (U) php-apigen (U) php-apigen-theme-bootstrap (U) php-apigen-theme-default (U) php-codesniffer (U) php-crypt-blowfish (U) php-cssmin (U) php-doctrine-common (U) php-doctrine-dbal (U) php-dropbox (U) php-fshl (U) php-guzzle (U) php-irods (U) php-json-patch (U) php-jwt (U) php-kdyby-events (U) php-kit-pathjoin (U) php-league-flysystem (U) php-markdown (U) php-nette (U) php-opencloud (U) php-patchwork-jsqueeze (U) php-pdfparser (U) php-picofeed (U) php-pimple (U) php-psr-cache (U) php-punic (U) php-randomlib (U) php-sabredav (U) php-securitylib (U) php-smb (U) php-streams (U) php-superclosure (U) php-tokenreflection (U) php-zend-search (U) php-zend-xml (U) php-zipstreamer (U) phpbb3 (U) symfony (U) Debian A
Re: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
* Pierre-Elliott Bécue [2016-03-23 22:44:18 +0100]: > Control: owner -1 ! > Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID > Protocol (Mozilla Persona) > > Hey, > > I intend to package. VCS is up, the package builds correctly. > > VCS: https://github.com/P-EB/python-browserid > Build results: https://peb.pimeys.fr/packages/python-browserid/ > > Comments welcome, and if everything seems okay, please, I'd like to request > for sponsorship on this package. Hi Pierre-Elliott, To get more luck, you should really use the proper channels for sponsorship: either the debian-python mailing-list specific to python packages, or the general sponsorship-requests process on the debian-mentors mailing-list (more info is available on http://mentors.debian.net/sponsors). Cheers (and good luck with your packages!), -- Nicolas Dandrimont BOFH excuse #287: Telecommunications is downshifting. signature.asc Description: Digital signature
Re: a poll for Dgit workflows
Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> I cannot comment on other the workflows of specific tools, mostly
> because I have never managed to find one that would solve some problems
> that I have, but my own packages do not require anything like that, not
> even quilt. E.g.:
Thanks for sharing.
But this doesn't really do what I am trying to achieve:
But I think that someone who knows how to use git should be able to
get the source code for a package in Debian, as a git branch, and
modify that source code, and share it, and so on, without needing to
deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.
Implicitly I meant that they also shouldn't need to know who the
maintainer is, or look it up (unless they want to talk to the
maintainer, of course).
I also mean that the user should get the source code for the package
in the archive.
So problems for your example package are:
> git clone git://anonscm.debian.org/users/md/kmod.git
> cd kmod
> # if you do not have the upstream source archive then you can make your own
1. You've missed out this step. (dgit arranges for you to have an
upstream source archive, although this is not needed for
entirely-git-based workflows using dgit-compatible git branches.)
I guess you expect that the user should go to ftp.debian.org and
download some tarball from there ? Which one ?
> git checkout v22
2. How does the user know that this is what they should do ? Where
did this `v22' come from ? (The Vcs-Git field in debian/control gives
the repo location, at least.)
3. After doing this, the source code is not the source code that I am
running, because this provides a patches-unapplied branch.
This means that `git-grep' lies. If the user tries to build the
package, they may end up with a build error, or an unpatched version.
In the best case the build tool they use notices, and applies the
patches - but then the build has made their tree dirty by modifying
the source code, which is not what a git user would expect.
> cd ..
> tar cJf kmod_22.orig.tar.xz kmod
> cd kmod
> git checkout master
4. How is the user supposed to know to do these things ? Maybe there
is a README somewhere with some runes in. But I want the user to Just
Have The Source Code In Git.
> # and now you can start hacking
> echo meh >> TODO
> # if you do not know about this step then dpkg-buildpackage will
> # helpfully tell you about it
> dpkg-source --commit
5. Of course a git user would already have committed their changes.
(Probably, actually, the git user has given up in disgust, because of
the unapplied-patches problem. But let's pretend that this is not so.
Perhaps the package had no patches beforehand.) So now they are asked
to commit them again using a different and far-inferior VCS.
Furthermore this dpkg-source commit makes their git tree dirty.
> There is nothing here but pure git and standard Debian tools.
>
> Also, considering that most Debian packages nowadays use the 3.0 quilt
> format I do not think that asking developers to use quilt is an
> excessive burden.
I disagree. quilt is a very poor VCS.
Ian.
Re: a poll for Dgit workflows
Ian Jackson writes ("Re: a poll for Dgit workflows"):
> Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> > I cannot comment on other the workflows of specific tools, mostly
> > because I have never managed to find one that would solve some problems
> > that I have, but my own packages do not require anything like that, not
> > even quilt. E.g.:
>
> Thanks for sharing.
>
> But this doesn't really do what I am trying to achieve:
>
> But I think that someone who knows how to use git should be able to
> get the source code for a package in Debian, as a git branch, and
> modify that source code, and share it, and so on, without needing to
> deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
> git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.
>
> Implicitly I meant that they also shouldn't need to know who the
> maintainer is, or look it up (unless they want to talk to the
> maintainer, of course).
Stepping back a bit:
The way things are done seems very obvious to the maintainer, and the
maintainer suffers much less from the difficulties. The maintainer
knows where their git repository is and how to work with it. The
maintainer already has copies of the relevant .orig files. The
maintainer is (obviously) familiar with the properties of the source
format they've chosen.
But for a non-maintainer, who picks up some package to double check
something and maybe make a small change, all this is quite painful.
In practice people who need to do that kind of thing don't use git.
They use apt-get source. (Now they can use dgit.)
It's worse if you're a user who isn't very familiar with Debian's
currently-conventional approaches to source code management. To an
outsider those approaches are at best outre' - and of course there are
a gazillion different variations.
What dgit provides right now is a way for anyone to get a git branch
which actually represents the source code which is actually in Debian,
in a format that is directly editable and buildable and which supports
git-native workflows. If the user doesn't want to upload to Debian,
they don't ever need to run dpkg-source; they can ignore quilt (if the
package is in quilt).
dgit also provides a way for any user to do an NMU using a git-based
workflow, without knowing anything about the maintainer's source code
management preferences.
Because few maintainers are using dgit, dgit's users see a synthetic
history. So `git blame' and `git log' are not very useful. This is
the next thing that I need to fix.
What I want to do is get to a point where a maintainer can _keep their
existing workflow_, but _also use dgit to publish their history_.
Ian.
Re: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
Are you sure we need this in the archive? Packaging dead horse doesn't seem like a good idea... Wikipedia says: It was launched in July 2011, but after failing to achieve traction, Mozilla announced in January 2016 plans to decommission the service by the end of the year.[3] O. -- Ondřej Surý On 24 Mar 2016 13:52, at 13:52, Nicolas Dandrimont wrote: >* Pierre-Elliott Bécue [2016-03-23 22:44:18 +0100]: > >> Control: owner -1 ! >> Control: retitle -1 ITP: python-browserid -- Python library for the >BrowserID Protocol (Mozilla Persona) >> >> Hey, >> >> I intend to package. VCS is up, the package builds correctly. >> >> VCS: https://github.com/P-EB/python-browserid >> Build results: https://peb.pimeys.fr/packages/python-browserid/ >> >> Comments welcome, and if everything seems okay, please, I'd like to >request >> for sponsorship on this package. > >Hi Pierre-Elliott, > >To get more luck, you should really use the proper channels for >sponsorship: >either the debian-python mailing-list specific to python packages, or >the >general sponsorship-requests process on the debian-mentors mailing-list >(more >info is available on http://mentors.debian.net/sponsors). > >Cheers (and good luck with your packages!), >-- >Nicolas Dandrimont > >BOFH excuse #287: >Telecommunications is downshifting.
Re: Bug#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
Control: tag -1 wontfix Le jeudi 24 mars 2016 à 15:51:34+0100, Ondřej Surý a écrit : > Are you sure we need this in the archive? Packaging dead horse doesn't seem > like a good idea... > > Wikipedia says: > > It was launched in July 2011, but after failing to achieve traction, Mozilla > announced in January 2016 plans to decommission the service by the end of the > year.[3] Hey, hyperkitty, which is part of mailman3 suite depends on django-browserid which depends on PyBrowserID, so for starts I wanted to package these two. I realized yesterday's evening after submitting my ITP that Persona was about to shutdown (in Nov.). Sadly, this was not clearly mentioned neither on https://login.persona.org/ nor on PyBrowserID Github's page. That pushes me backwards. I'll suggest upstream to drop browserid dependency, as it's quite "easy" to do. I close the bug since it seems not relevant to package this library anymore. Thanks for your email, and sorry for the noise. -- PEB
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#819182: ITP: fitspng -- FITS to PNG image converter
Package: wnpp Owner: Filip Hroch Severity: wishlist X-Debbugs-Cc:debian-devel@lists.debian.org,debian-as...@lists.debian.org * Package name: fitspng Version : 0.3.5 Upstream Author : Filip Hroch * URL : http://integral.physics.muni.cz/fitspng/ * License : GPL-3 Programming Lang: C Description : FITS to PNG image converter Fitspng is an utility intended to convert of the natural high dynamic range of FITS images, directly representing measured data, to the limited numerical range of PNG format widely used in computer graphics. Fitspng implements a global tone mapping technique by a set of tone functions using parameters provided by user or by machine estimate on base of a robust count statistics. Moreover, the conversion keeps an important FITS meta-information as a text part of PNG header. It will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth [1]. Best regards, FH --- [1] https://anonscm.debian.org/cgit/debian-astro/packages/fitspng.git -- F. Hroch e-mail, jabber: hr...@physics.muni.cz, tel.: +420549494470 Dept. of theor. physics and astrophysics, MU Brno, Kotlarska 2,CZ-611 37
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.
Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: arch-detect Upstream Author : me * URL : https://github.com/kilobyte/arch-detect * License : MIT Programming Lang: mostly assembler Description : detect architectures supported by your machine/kernel This package lets you enumerate architectures that your kernel can run. The check is for the ability to run machine code and supporting appropriate syscall ABI -- you may need to install userland libraries in a chroot, container or via multiarch to actually execute non-static binaries of such architectures. . Architectures detected by this version of arch-detect are: * amd64, i386, x32 * mips, mipsel, mips64, mips64el * arm, armel, armhf, arm64 * powerpc, ppc64, ppc64el * m68k * sh4 * s390x * sparc64 * illumos-amd64 * win32, win64 My reason here is that x32 can't be detected other than trying a syscall and seeing if it fails. But then, we don't want a 344 byte package -- so here's one that handles all release archs and most -ports ones. Most of these can be detected by reading /proc and binfmts, but that's neither easy nor reliable -- testing empirically works better. Some quirks: * ppc64el: I check "mtvsrd r0, r0" to fail qemu if it suffers from #813698 * armhf: "dmb" nicely SIGILLs on RPi 1, are there other ARMv7-but-not-armhf in the wild worth checking? * arm: untested (does anyone have that old hardware?) -- fails on all porterboxes but succeeds on both kernel 3.8 on Odroid-U2 and 4.1 on Raspbian RPI 1. Archs that are missing: * kfreebsd-*: no cross binutils in unstable (uses a different format, unlike hurd and Solaris which share it with Linux) * hurd: how do you even do syscalls there?!? Trying to figure it out exhausted my attention span. RTFSing glibc, I see it's something bizarre: _exit() requests some server to terminate the process then goes into an endless loop of dividing 1/0. * alpha: no machine to test it on, I'm reluctant to trust qemu exclusively * hppa: no machine to test, not even supported by qemu * ia64: no cross binutils * sparc: binutils can multilib it, does anyone still want it? * powerpcspe: no machine, debootstrap in qemu fails Naming issues: * illumos-amd64: (Solaris): dpkg's table has different names; I used this one as it's an established unofficial port in a pretty good shape; you may argue a different name though -- like, something that mentions that this syscall ABI works on real Solaris... * win32, win64: should I name them -i386, -amd64? Not sure if detecting them even makes sense -- binfmts exist but you're not going to chroot/ multiarch those...
Work-needing packages report for Mar 25, 2016
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 734 (new: 2) Total number of packages offered up for adoption: 186 (new: 1) Total number of packages requested help for: 44 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: cpu (#818629), orphaned 6 days ago Installations reported by Popcon: 97 openxenmanager (#819195), orphaned today Installations reported by Popcon: 284 732 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: openxenmanager (#819195), offered today Installations reported by Popcon: 284 185 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: athcool (#278442), requested 4167 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 27 awstats (#755797), requested 610 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4175 balsa (#642906), requested 1642 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 714 cardstories (#624100), requested 1795 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 6 cups (#532097), requested 2483 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (66 more omitted) Installations reported by Popcon: 169719 cyrus-sasl2 (#799864), requested 183 days ago Description: authentication abstraction library Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper (125 more omitted) Installations reported by Popcon: 192268 developers-reference (#759995), requested 572 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 19371 devscripts (#800413), requested 177 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (27 more omitted) Installations reported by Popcon: 13132 ejabberd (#767874), requested 507 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-mam-mnesia ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 769 fbcat (#565156), requested 2262 days ago Description: framebuffer grabber Installations reported by Popcon: 206 freeipmi (#628062), requested 1764 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: conman freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted) Installations reported by Popcon: 6439 freerdp (#799759), requested 184 days ago Description: RDP client for Windows Terminal Services (X11 client) Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-dbg libfreerdp-dev (28 more omitted) Installations reported by Popcon: 73147 gnat-gps (#496905), requested 2765 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 533 gnokii (#677750), requested 1377 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1264 gridengine (#703256), requested 1103 days ago Descr
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
Bug#819226: ITP: r-cran-bold -- GNU R interface to Bold Systems for genetic barcode data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-bold Version : 0.3.0 Upstream Author : Scott Chamberlain * URL : https://cran.r-project.org/web/packages/bold/ * License : MIT Programming Lang: GNU R Description : GNU R interface to Bold Systems for genetic barcode data A programmatic interface to the Web Service methods provided by Bold Systems for genetic barcode data. Functions include methods for searching by sequences by taxonomic names, ids, collectors, and institutions; as well as a function for searching for specimens, and downloading trace files. Remark: This package belongs to a pyramid of dependencies needed for r-cran-treescape and will be maintained at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-bold/trunk/
