Bug#862725: ITP: python-parse-type -- Extends the parse module
Currently blocked by https://github.com/jenisys/parse_type/issues/7 -- Brian May
Bug#862725: ITP: python-parse-type -- Extends the parse module
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-parse-type Version : 0.3.4 Upstream Author : Jens Engel * URL : https://github.com/jenisys/parse_type * License : BSD-3-clause Programming Lang: Python Description : Extends the parse module parse_type extends the parse module (opposite of string.format()) with the a number of additional features. This is required for packaging pytest-bdd. See #825071.
Bug#728410: ITP: python-glob2 -- enhanced glob module for Python
control: retitle -1 ITP: python-glob2 -- enhanced glob module for Python control: owner ! I am going to attempt to package this as it is needed for pytest-bdd, which I am also packaging. See #825071. As there have been no updates, assuming I will need to start from scratch. I intend to maintain this under the Debian Python Modules Team umbrella. -- Brian May
Bug#825071: RFP: python-pytest-bdd -- BDD library for the py.test runner
control: retitle -1 ITP: python-pytest-bdd -- BDD library for the py.test runner control: owner -1 ! I intend to package python-pytest-bdd for debian, under the Debian Python Modules Team Umbrella. I need it for some personal Debian packages I am creating. -- Brian May
Bug#859199: ITP: dh-curl-sudo-bash -- debhelper tools for automated non-packaging
Stuart Prescott writes: > The dh-curl-sudo-bash package provides a build-system method for debhelper > that automates the non-packaging of programs for which the preferred form of > distribution is the sequence > > "curl http://example.com/setup.sh | sudo bash -" > > dh-curl-sudo-bash causes debhelper to create a maintainer post-install script > that runs the above command on the target machine when the package is > installed. This has the serious flaw that the upstream URL could change without notice. I think the dh-sudo-bash package should be able to scrape a given wikipedia page to obtain the URL that it should download the bash script from. With a check to ensure it is prefixed with http:// not https://. That way anybody can update the URL as required, not just the Debian developer. Oh, sorry, not April 1st anymore :-( -- Brian May
Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Christian Seiler writes: > Specifically take a look at this message from the author of the original > tool: > https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html > > The fork appears to have happened after that, but wasn't mentioned at > all on the upstream mailing list. "However, the basic ideas seem like good ones, and I'll look into adopting these with a less offensive implementation." Seems like the author liked the concepts behinds the patches, but felt that the patches needed more work. I think I would have started by trying to submit a smaller change (e.g. maybe the first patch in the series). I don't see any response to this email. Doesn't inspire confidence :-( -- Brian May
Bug#814045: ITP: fake-factory -- Faker is a Python library that generates fake data
Christopher Baines writes: > This is a dependency of python-factory-boy, which I intend to work on getting > back in to Debian. I somehow completely missed this when I needed factory-boy urgently last month :-( Thought I should mention however that I have a up-to-date package of factory-boy I needed for private use; you can use it to help with your packaging efforts if you want. https://linuxpenguins.xyz/debian/pool/main/f/factory-boy/ I also did fake-factory, however that is probably not needed anymore: https://linuxpenguins.xyz/debian/pool/main/f/fake-factory/ -- Brian May
Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs
> please don't use python- prefix, use mkdocs-bootswatch. Note that binary > package is "mkdocs" Ok, so I just call both source *and* binary packages mkdocs-bootswatch and mkdocs-bootstrap then? >> I plan to maintain this as part of the DPMT - Debian Python Modules >> Team. > > I think PAPT is more appropriate for mkdocs. I don't think it is also > appropriate for themes, but since mkdocs-bootswatch/mkdocs-bootstrap are > tightly related to another DPMT^W PAPT package, IMHO we can make an > exception in PAPT for them (but I'd prefer to have them outside the > team, TBH - DPMT/PAPT are not collab-maint replacements). mkdocs was required for a DPMT package - django-rest-framework - and this is the only reason I bother to package it. It is already in DPMT. Recent mkdocs has split up, and now requires these packages too. I tried to get access to PAPT (so I could fix another package), however so far haven't got a response. I would sooner maintain them in collab-maint rather then PAPT, because I don't really want to have to convert my git repositories to subversion. I believe subversion is still required by PAPT. -- Brian May
Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs
Would appreciate it if somebody could confirm that the license is BSD and if so what version of the BSD license this is. https://github.com/mkdocs/mkdocs-bootswatch/blob/master/LICENSE setup.py declares the license as BSD, however in my current sleep deprived state it looks different to the BSD licenses that I can see here: https://en.wikipedia.org/wiki/BSD_licenses -- Brian May
Bug#823053: ITP: python-mkdocs-bootstrap -- Bootstrap theme for MkDocs
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs-bootstrap Version : 0.1.1 Upstream Author : Dougal Matthews * URL : https://pypi.python.org/pypi/mkdocs-bootstrap/ * License : BSD Programming Lang: HTML/CSS Description : Bootstrap theme for MkDocs No idea what to put here for long description. This is a requirement for python-mkdocs. Not sure if this prefix of python- is appropriate or not because this package doesn't contain any python, however it is part mkdocs, and the source of mkdocs which has been named python-mkdocs in Debian. I plan to maintain this as part of the DPMT - Debian Python Modules Team. Also see discussion on mailing list: https://lists.debian.org/debian-python/2016/04/msg00042.html
Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs-bootswatch Version : 0.4.0 Upstream Author : Dougal Matthews * URL : https://pypi.python.org/pypi/mkdocs-bootswatch/ * License : BSD Programming Lang: HTML/CSS Description : Bootswatch themes for MkDocs No idea what to put here for long description. This is a requirement for python-mkdocs. Not sure if this prefix of python- is appropriate or not because this package doesn't contain any python, however it is part mkdocs, and the source of mkdocs which has been named python-mkdocs in Debian. I plan to maintain this as part of the DPMT - Debian Python Modules Team. Also see discussion on mailing list: https://lists.debian.org/debian-python/2016/04/msg00042.html
Bug#819853: ITP: pytest-runner -- Invoke py.test as distutils command with dependency resolution.
Brian May writes: > Not sure if this is adequate for Debian or not. If this is sufficient, I > have a working package that I can upload. > > Have filled a bug report: > > https://github.com/pytest-dev/pytest-runner/issues/16 Upstream seems to think this is sufficient, so if it isn't please consider contributing to the above bug report. Otherwise I will assume it is ok and upload to NEW... Thanks. -- Brian May
Bug#819853: ITP: pytest-runner -- Invoke py.test as distutils command with dependency resolution.
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: pytest-runner
* Binary Package name : python{,3}-pytest-runner
Version : 2.7
Upstream Author : Jason R. Coombs
* URL : https://github.com/pytest-dev/pytest-runner
* License : Expat
Programming Lang: Python and Python3
Description : Invoke py.test as distutils command with dependency
resolution.
Setup scripts can use pytest-runner to add setup.py test support for pytest
runner.
Will package this as part of the Debian Python Modules Team. Is required
by Django Guardian.
For some reason thought this was already in Debian, however I can't find
it.
The only indication I can see that this is Expat/MIT licenses is:
https://github.com/pytest-dev/pytest-runner/blob/master/setup.py#L43
Which contains:
"License :: OSI Approved :: MIT License",
Not sure if this is adequate for Debian or not. If this is sufficient, I
have a working package that I can upload.
Have filled a bug report:
https://github.com/pytest-dev/pytest-runner/issues/16
Bug#819157: r/bitstruct/python-bitstruct?
Ghislain Vaillant writes: > May I suggest to rename the source package to python-bitstruct as it > seems to be the (unofficial) convention for Python-only library. Tends to be a bit inconsistant. Looking at Debian Python Modules Team there are a lot of packages that don't do this. > FYI, we already have python-bitarray and python-bitstring available in > the archive. Perhaps, it would be nice to emphasize what makes this > library different for the other two, although I understand that the > motivation behind this packaging effort is to satisfy a Build-Depends. Comparison with python-bitarray is easy - This is a native Python implementation. I suspect the major difference is that they were libraries written by different authors with different aims as to what they wanted to archive. I haven't used any of these libraries, don't think I can really compare them :-( -- Brian May
Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone
Edward Betts writes: > This module is available in the python-tzlocal Debian package. > > https://tracker.debian.org/pkg/python-tzlocal Crap. I did look. No idea why I didn't find it. Thanks for this. -- Brian May
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.
Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone
Brian May writes: > Package: wnpp > Severity: wishlist > Owner: Brian May > > * Package name: tzlocal Meant to clarify. The source package is tzlocal, the binary python-tzlocal and python3-tzlocal. > Version : 2.1 > Upstream Author : Lennart Regebro > * URL : https://github.com/regebro/tzlocal > * License : CC0 > Programming Lang: Python2 and Python3 > Description : tzinfo object for the local timezone > > This module attempts to fix a glaring hole in pytz, that there is no way to > get the local timezone information, unless you know the zoneinfo name, and > under several Linux distros that’s hard or impossible to figure out. > . > With tzlocal you only need to call get_localzone() and you will get a tzinfo > object with the local time zone info. On some Unices you will still not get > to > know what the timezone name is, but you don’t need that when you have the > tzinfo file. However, if the timezone name is readily available it will be > used. > . > This package contains the Python 2 module. > > This is required for the latest version of apscheduler. I plan to > maintain it as part of the Debian Python Modules Team. -- Brian May
Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone
Package: wnpp Severity: wishlist Owner: Brian May * Package name: tzlocal Version : 2.1 Upstream Author : Lennart Regebro * URL : https://github.com/regebro/tzlocal * License : CC0 Programming Lang: Python2 and Python3 Description : tzinfo object for the local timezone This module attempts to fix a glaring hole in pytz, that there is no way to get the local timezone information, unless you know the zoneinfo name, and under several Linux distros that’s hard or impossible to figure out. . With tzlocal you only need to call get_localzone() and you will get a tzinfo object with the local time zone info. On some Unices you will still not get to know what the timezone name is, but you don’t need that when you have the tzinfo file. However, if the timezone name is readily available it will be used. . This package contains the Python 2 module. This is required for the latest version of apscheduler. I plan to maintain it as part of the Debian Python Modules Team.
Bug#817056: ITP: python-typing -- Type Hints for Python
"Michael R. Crusoe" writes: > This is a backport of the standard library typing module to Python > versions older than 3.5. Not sure what the point of this is; doesn't typing hinting require PEP 3107, which isn't in Python 2.x? -- Brian May
Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
Nikolaus Rath writes: > Alright. In your opinion, what should be the standard for getting > something packaged into Debian? Just because something does not get included in Debian, doesn't stop you from packaging it and distributing it outside Debian. In fact, in this case, it has certain advantages. You can release a new version whenever you want. You can require user's to have the latest version to get support. Debian is not stuck trying to support a legacy version in stable until LTS support ends. The security team is not stuck trying to patch security vulnerabilities in an obsolete version that the upstream maintainer lost interest in years ago. etc. I haven't seen the code myself, however one of the comments was: "just having whitespace in the destination directory will lead to a crash, set -e is not used, and errors are redirected to /dev/null" This sounds to me like a recipe for security problems. -- Brian May
Bug#810061: ITP: python-django-environ -- utilize 12factor inspired environment variables for Django
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-environ Version : 0.4 Upstream Author : joke2k * URL : https://github.com/joke2k/django-environ/ * License : MIT Programming Lang: Python2 and Python3 Description : Simplified environment variables for Django Simplifies configuring key aspects of Django Applications through environment variables. I am hopeless with descriptions, any improvements to the above description welcome. This will be maintained as part of DPMT, and will be required for the next release of django-guardian.
Bug#802730: ITP: python-setuptools-scm -- Handles managing your python package versions in scm metadata.
Tristan Seligmann writes: > Already packaged, see #797915. Thanks for this. Looks like I messed up the existing package search. -- Brian May
Bug#802730: ITP: python-setuptools-scm -- Handles managing your python package versions in scm metadata.
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-setuptools-scm Version : 1.8.0 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/pypa/setuptools_scm/ * License : MIT Programming Lang: Python 2 and Python 3 Description : Handles managing your python package versions in scm metadata. Handles managing your Python package versions in scm metadata instead of declaring them as the version argument or in a scm managed file. Required for pytest-django, which is required by djangorestframework. Will be packaged as part of the DPMT (Debian Python Modules Team).
Bug#802727: ITP: pytest-django -- Test Django project/applications with pytest.
Package: wnpp Severity: wishlist Owner: Brian May * Package name: pytest-django Version : 2.9.1 Upstream Author : Andreas Pelme * URL : https://github.com/pytest-dev/pytest-django * License : BSD Programming Lang: Python 2 and Python 3 Description : Test Django project/applications with pytest. Running your test suite with pytest-django allows you to access features of pytest that wouldn't normally be available with the Django’s manage.py test command. This seems to be required to get the djangorestframework tests working properly. I will package this as part of the DPMT (Debian Python Modules Team).
Bug#794829: ITP: python-django-cors-headers -- Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-cors-headers Version : 1.1.0 Upstream Author : Otto Yiu * URL : https://github.com/ottoyiu/django-cors-headers/ * License : MIT Programming Lang: Python2 and Python3 Description : Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS) Pypi link: https://pypi.python.org/pypi/django-cors-headers Will be DPMT maintained. Required for another package I am creating. I think this is likely to be useful for other people besides myself. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807011318.15108.81449.report...@prune.in.vpac.org
Bug#784438: ITP: autosubmit -- Manage weather and climate experiments on supercomputers
On Wed, 6 May 2015 at 21:18 Alastair McKinstry wrote: > * URL : https://autosubmit.ic3.cat > This link appears to be broken, I get a mostly blank HTML page: - -
Bug#780887: ITP: python-hammock -- Rest APIs python client
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-hammock Version : 0.2.4 Upstream Author : Kadir Pekel * URL : https://github.com/kadirpekel/hammock * License : EXPAT Programming Lang: Python Description : Rest APIs python client Hammock is a fun module lets you deal with rest APIs by converting them into dead simple programmatic APIs. It uses popular requests module in backyard to provide full-fledged rest experience. I require it for a package I am developing. I plan to maintain it as part of the Debian python modules team. I believe this is Python 3 compatable, so plan on making Python 2 and Python 3 packages. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150320232335.20975.48852.reportbug@falidae
Bug#779417: ITP: python-pytest-timeout -- pytest plugin to abort hanging tests
On 4 March 2015 at 12:18, Brian May wrote: > On 3 March 2015 at 20:53, gustavo panizzo (gfa) wrote: > >> @Brian, can you sponsor this upload? thanks! >> > > Ok, done. > Just noticed that the build-depends on python-tox is possibly redundant. At least it seems to build fine on wheezy which doesn't have it. -- Brian May
Bug#779417: ITP: python-pytest-timeout -- pytest plugin to abort hanging tests
On 3 March 2015 at 20:53, gustavo panizzo (gfa) wrote: > @Brian, can you sponsor this upload? thanks! > Ok, done. -- Brian May
Bug#778269: packaging for mkdocs -- vcs?
On 21 February 2015 at 07:43, Yaroslav Halchenko wrote: > thanks for working on packaging mkdocs. I wondered if I could fetch > current state of packaging from somewhere (sorry if I have missed it in > the report) -- wanted to give it a try. > Hello, I put the packages online at http://code.vpac.org/mkdocs/ Unfortunately you won't be able to use as is, due to a missing dependency on python3-wheel. (which should have appeared in the depends list but didn't due to not having the build depends satisfied when building the package) Once I get this sorted out, will check for any other errors in the package. Thanks -- Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
On 14 February 2015 at 09:52, Brian May wrote: > What should I call the package? mkdocs? Or python3-mkdocs? > Thinking about this, I will call the source python-mkdocs, but the binary package just mkdocs. As I think the names python-mkdocs and python3-mkdocs imply some sort of public and stable python API. -- Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
On 13 February 2015 at 22:03, Dmitry Shachnev wrote: > Thank you, I also need this package because Python-Markdown is going to > use it for building its docs as well at some point in the future (will > need to think how to avoid the circular dependency though). > Circular build depends, what fun :-) > Looks like upstream really does not provide any stable Python API, > so I think there is no need to build public module packages. > What should I call the package? mkdocs? Or python3-mkdocs? > But you will make me a bit happier if you make the executable use > Python 3. > That will have to wait for a python3-watchdog package. Also an update: at one stage I was concerned that it wouldn't work with python markdown 2.5.1, which is in Debian. This appears to be incorrect - it seems to work fine for me anyway. I get the impression the only reason for depending on markdown < 2.5 is for Python 2.6 support, which we don't care about. -- Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
Yuck.
pkg_resources.VersionConflict: (Markdown 2.5.1
(/usr/lib/python2.7/dist-packages),
Requirement.parse('Markdown>=2.3.1,<2.5'))
It looks like mkdocs doesn't Markdown 2.5.1, which is the version in Debian
:-(
--
Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
On 13 February 2015 at 13:31, Brian May wrote: > What is the cleanest way of resolving these numerous Lintian errors? > Never mind, I have included one copy of the file in debian/missing-sources, and copy it as required in debian/rules. Now down to three lintian warnings: W: python-mkdocs: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mkdocs/themes/mkdocs/img/grid.png W: python-mkdocs: binary-without-manpage usr/bin/mkdocs W: python-mkdocs-doc: extra-license-file usr/share/doc/python-mkdocs-doc/html/license/highlight.js/LICENSE Also worth noting I can't build python3-mkdocs just yet, it depends on python3-watchdog - see #776599 -- Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
-packages/mkdocs/themes/simplex/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/simplex/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/slate/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/slate/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/spacelab/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/spacelab/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/united/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/united/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/yeti/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/yeti/fonts/fontawesome-webfont.ttf also in fonts-font-awesome (Ignore the duplicate-font-file warnings for now, I think I can resolve those.) I could create a patch lots of copies of jquery-1.10.2.min.js for every directory - similar to what is already done for every other *.js file used, however that seems to be not efficient - even if it is the upstream design. ./mkdocs/themes/amelia/js/prettify-1.0.min.js ./mkdocs/themes/amelia/js/base.js ./mkdocs/themes/amelia/js/bootstrap-3.0.3.min.js ./mkdocs/themes/readable/js/prettify-1.0.min.js ./mkdocs/themes/readable/js/base.js ./mkdocs/themes/readable/js/bootstrap-3.0.3.min.js ./mkdocs/themes/cosmo/js/prettify-1.0.min.js ./mkdocs/themes/cosmo/js/base.js ./mkdocs/themes/cosmo/js/bootstrap-3.0.3.min.js ./mkdocs/themes/flatly/js/prettify-1.0.min.js ./mkdocs/themes/flatly/js/base.js ./mkdocs/themes/flatly/js/bootstrap-3.0.3.min.js ./mkdocs/themes/united/js/prettify-1.0.min.js ./mkdocs/themes/united/js/base.js ./mkdocs/themes/united/js/bootstrap-3.0.3.min.js ./mkdocs/themes/mkdocs/js/prettify-1.0.min.js ./mkdocs/themes/mkdocs/js/base.js ./mkdocs/themes/mkdocs/js/highlight.pack.js ./mkdocs/themes/mkdocs/js/bootstrap-3.0.3.min.js ./mkdocs/themes/mkdocs/license/highlight.js ./mkdocs/themes/yeti/js/prettify-1.0.min.js ./mkdocs/themes/yeti/js/base.js ./mkdocs/themes/yeti/js/bootstrap-3.0.3.min.js ./mkdocs/themes/slate/js/prettify-1.0.min.js ./mkdocs/themes/slate/js/base.js ./mkdocs/themes/slate/js/bootstrap-3.0.3.min.js ./mkdocs/themes/cyborg/js/prettify-1.0.min.js ./mkdocs/themes/cyborg/js/base.js ./mkdocs/themes/cyborg/js/bootstrap-3.0.3.min.js ./mkdocs/themes/bootstrap/js/prettify-1.0.min.js ./mkdocs/themes/bootstrap/js/base.js ./mkdocs/themes/bootstrap/js/bootstrap-3.0.3.min.js ./mkdocs/themes/readthedocs/js/theme.js ./mkdocs/themes/readthedocs/js/highlight.pack.js ./mkdocs/themes/readthedocs/license/highlight.js ./mkdocs/themes/journal/js/prettify-1.0.min.js ./mkdocs/themes/journal/js/base.js ./mkdocs/themes/journal/js/bootstrap-3.0.3.min.js ./mkdocs/themes/spacelab/js/prettify-1.0.min.js ./mkdocs/themes/spacelab/js/base.js ./mkdocs/themes/spacelab/js/bootstrap-3.0.3.min.js ./mkdocs/themes/simplex/js/prettify-1.0.min.js ./mkdocs/themes/simplex/js/base.js ./mkdocs/themes/simplex/js/bootstrap-3.0.3.min.js ./mkdocs/themes/cerulean/js/prettify-1.0.min.js ./mkdocs/themes/cerulean/js/base.js ./mkdocs/themes/cerulean/js/bootstrap-3.0.3.min.js Or, I could create links to libjs-jquery* packages, however only is libjs-jquery in Debian old, and I can't guarantee an older version will work. Of course, it looks like I will have to patch every base.html file :-( Ideas? -- Brian May
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs Version : 0.11.1 Upstream Author : Tom Christie * URL : http://www.mkdocs.org/ * License : BSD Programming Lang: Python Description : Static site generator geared towards building project documentation MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. This package is required to build the documentation in the latest upstream version of python-djangorestframework. I plan to maintain this as part of the python modules team. The intention appears to be that mkdocs is used as a standalone application, although it supplies a mkdocs python package which could in theory be called directly. Given the above paragraph, is it still appropriate to build both a python-mkdocs and a python3-mkdocs package? Unless I hear otherwise, this will be my plan. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150212230625.20347.36646.report...@aquitard.in.vpac.org
Bug#776892: ITP: python-django-audit-log -- Django app to track changes to models
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-audit-log Version : 0.7.0 Upstream Author : Vasil Vangelovski * URL : https://pypi.python.org/pypi/django-audit-log/0.7.0 * License : BSD Programming Lang: Python Description : Django app to track changes to models This python package will automatically track and record all changes to a Django model. I am packaging this because an application I use and maintain (not yet in Debian) requires it. I plan on mantaining it as part of the Debian python modules team. I will be building Python2 and Python3 packages. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150202230410.16389.2844.report...@aquitard.in.vpac.org
Bug#770889: ITP: python-pymysql -- Pure-Python MySQL driver
On 25 Nov 2014 09:24, "Thomas Goirand" wrote: > This package contains a pure-Python MySQL client library. The goal of PyMySQL > is to be a drop-in replacement for MySQLdb and work on CPython, PyPy, > IronPython and Jython. > > This is yet another new dependency for OpenStack. Note that this package is > interesting because it has Python 3 support. I assume you know about the alternatives for Python 3 support, but just in case, have a look at: https://packages.debian.org/sid/python3-mysql.connector Bug#768096: ITP: python-mysqlclient -- Python interface to MySQL http://bugs.debian.org/768096 (Currently in new awaiting entry to experimental). Just to confirm: this package doesn't appear to conflict with python-mysqldb, is that correct?
Bug#768096: [Python-modules-team] python mysqldb on python 3
On 18 November 2014 16:31, Scott Kitterman wrote: > That does sound like a friendly fork, so I think taking over the package > name > for Stretch would be appropriate, but in the meantime, it should stay in > experimental in case a bug fix is needed for the current package for > Jessie. > Ok, just committing changes right now: svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/python-mysqldb/branches/experimental I am not sure if the following patches are still required. brian@aquitard:~/tree/debian/mine/python-mysqldb/python-mysqldb$ ls -l debian/patches total 16 -rw--- 1 brian brian 658 Nov 18 14:59 01_converters_boolean.patch -rw--- 1 brian brian 630 Nov 18 14:59 03_converters_set2str.patch -rw--- 1 brian brian 749 Nov 18 14:59 05_ssl.patch I suspect I should remove them actually, and make the code the same as upstream. I suspect these patches are to resolve legacy issues and are no longer applicable. Subversion seems to be very slow at doing the commit, or at least svn.debian.org is, so will try to work this out when it decides to wake up. -- Brian May
Bug#768096: [Python-modules-team] python mysqldb on python 3
On 18 November 2014 15:40, Scott Kitterman wrote: > Is the original development inactive? I think it would be at least > somewhat > anti-social to switch to a non-friendly fork (no idea if that's relevant > here). What are the circumstances around the fork. I think that's at > least > socially significant. > I am no expert here. Looking at source force, the latest stable release of (1.2.3) mysqldb was 2010-06-17 (with the corresponding windows msi being generated 2012-09-05). http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.3/ There has been a beta version since (1.2.4b4), having problems getting a date for it using source forge. Last svn commit appears to have been made 2012-09-24. The big issue mysqlclient solves is Python3 support, although I suspect there are other bugs fixed too. https://pypi.python.org/pypi/mysqlclient/1.3.4 Looking at mysqlclient at https://github.com/PyMySQL/mysqlclient-python, there is the text: "This project adds Python 3 support and bug fixes. I hope this fork is merged back to MySQLdb1 like distribute was merged back to setuptools." A merge back would be good, but unfortunately I am doubtful it is going to happen. -- Brian May
Bug#768096: [Python-modules-team] python mysqldb on python 3
On 18 November 2014 15:05, Scott Kitterman wrote: > > [...] Maintainers can decide which they prefer and [...] On second thoughts, me thinks this may not be as easy as you suggest. :-( i.e. if package XYZ changes to depend on python-mysqlclient, it is going to conflict with every package that depends on python-mysqldb. -- Brian May
Bug#768096: [Python-modules-team] python mysqldb on python 3
On 18 November 2014 15:05, Scott Kitterman wrote: > > I'd suggest not just replacing it. How about call your package python- > mysqlclient (as you had originally intended I believe) and have it conflict > with python-mysqldb (since they both provide the same interface, conflicts > is > appropriate). Maintainers can decide which they prefer and if we get a > strong > consensus for Stretch, then we can remove python-mysqldb and have python- > mysqlclient provide it. > I could do this. However I thought that having two packages that do the exactly the same thing conflict with each other would be frowned upon. (not to mention that the name goes against the policy of calling packages python-modulename). -- Brian May
Bug#768096: [Python-modules-team] python mysqldb on python 3
On 5 November 2014 12:11, Collin Anderson wrote: > > There might be a problem because it looks like it conflicts with > python-mysqldb. > Yes, it's a 100% compatible fork intended to replace python-mysqldb. Same > python package name and everything. We could decide to only include it for > python3, or we could even have this completely replace the original > python-mysqldb on python2. > I don't much like the idea of having different code base for python2 and python3 versions. My current plan (unless anyone objects) is to replace the python-mysqldb package with the mysqlclient package, keeping the existing python-mysqldb (which makes sense as the python module name is unchanged). My initial upload will be to experimental. (as time permits) -- Brian May
Bug#768096: ITP: python-mysqlclient -- Python interface to MySQL
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mysqlclient Version : 1.3.4 Upstream Author : INADA Naoki * URL : https://github.com/PyMySQL/mysqlclient-python * License : GPL Programming Lang: Python Description : Python interface to MySQL To maintained by the Debian Python Modules Team. This mysqlclient library is now the recommended choice for using MySQL with Django. https://docs.djangoproject.com/en/1.7/ref/databases/#mysql-db-api-drivers It is compatible with the current mysqldb package, except the current package does not have python3 support. It might be too late now for Jessie(?), but I think it is worth having in sid, regardless. BUT: At quick glance it looks like this package provides a MySQLdb python module. So, unless I am mistaken, it looks like it would conflict with python-mysqldb. Is this considered acceptable? Or would another solution be better, e.g. update the python-mysqldb package to use this fork? -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104223640.13214.20483.report...@aquitard.in.vpac.org
Bug#757980: ITP: cryptography -- cryptography is a package which provides cryptographic recipes and primitives to Python developers.
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: cryptography
Version : 0.5.3
Upstream Author : Various
* URL : https://cryptography.io/en/latest/
* License : Apache License
Programming Lang: Python
Description : cryptography is a package which provides cryptographic
recipes and primitives to Python developers.
cryptography is a Python library which exposes cryptographic recipes and
primitives. Our goal is for it to be your “cryptographic standard
library”
This appears to be required by the latest pyopenssl
(http://bugs.debian.org/751144).
Will be uploading this as a python-modules-team maintained package.
I imagine the binary package will be called python{,3}-cryptography.
Haven't got to this step yet.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140813000629.32143.64368.report...@aquitard.in.vpac.org
Bug#753482: ITP: django-tldap -- High level python LDAP Library
Package: wnpp Severity: wishlist Owner: Brian May * Package name: django-tldap Version : 0.3.0 Upstream Author : Brian May * URL : https://pypi.python.org/pypi/django-tldap * License : GPL3+ Programming Lang: Python2 and Python3 Description : High level python LDAP Library Provides python-tldap, python3-tldap and python-tldap-doc. TLDAP is a high level LDAP library for Python 3 that users django-db like models to define LDAP schemas that can then be used in an easy way from Python code. It also supports fake LDAP transactions, to try and ensure LDAP database remains in a consistent state, even if there are errors that cause the transaction to fail. This uses the python-ldap3/python3-ldap3 packages that I recently packaged for the low level LDAP connection. At present it requires Django, although I imagine it wouldn't be too hard to remove this dependancy. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140702112136.606.66090.report...@aquitard.in.vpac.org
Bug#753481: ITP: django-xmlrpc -- XMLRPC library for Django
Package: wnpp Severity: wishlist Owner: Brian May * Package name: django-xmlrpc Version : 0.1.5 Upstream Author : Fache Julien * URL : https://pypi.python.org/pypi/django-xmlrpc/ * License : BSD Programming Lang: Python2 and Python3 Description : XMLRPC library for Django Provides python-django-xmlrpc and python3-django-xmlrpc. django_xmlrpc offers a means by which a Django developer can expose their views (or indeed any other function) using XML-RPC. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140702111435.31893.50129.report...@aquitard.in.vpac.org
Bug#752140: ITP: django-simple-captcha -- Django Simple Captcha Django application
On 20 June 2014 12:22, Brian May wrote: > * python3-django-captcha > On second thoughts, that will have to wait for a python3-django package first :-). -- Brian May
Bug#752140: ITP: django-simple-captcha -- Django Simple Captcha Django application
Package: wnpp Severity: wishlist Owner: Brian May * Package name: django-simple-captcha Version : 0.4.2 Upstream Author : Marco Bonetti * URL : https://pypi.python.org/pypi/django-simple-captcha * License : MIT Programming Lang: Python Description : Django Simple Captcha Django application Django Simple Captcha is an extremely simple, yet highly customizable Django application to add captcha images to any Django form. I intend to package the binaries as: * python-django-captcha * python3-django-captcha This is to avoid conflicting with python-captcha which is already in Debian. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140620022244.5429.5638.report...@aquitard.in.vpac.org
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
On 5 June 2014 09:50, Brian May wrote: > Still evaluating if it meets my needs though, maybe I was premature with > the upload to incoming :-) > Upstream seems to be pretty responsive to my emails, created this library to be portable across platforms and python versions, and is keen to improve it where possible. So I do think this is a good thing to have in Debian. -- Brian May
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
On 5 June 2014 09:50, Brian May wrote: > * My current code creates an object, updates an attribute on that object, > reads it back, and gets an empty object with no attributes. Still need to > find out what is going on here. Might be my fault. It does appear my code > is doing the right thing though. > Think that is my fault. IIRC the default in python-ldap is for search to return the default attributes if none are given. The default in python3-ldap is not to return any attributes if none are given. -- Brian May
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
On 5 June 2014 01:02, Julien Cristau wrote:
> > This library has the advantage that it is pure Python code, I believe
> > this means it doesn't require the C ldap library.
> >
> Whether that's an advantage is kind of disputable.
>
True.
The main advantage is that it is python3 compatible.
Still evaluating if it meets my needs though, maybe I was premature with
the upload to incoming :-)
So far, my current progress, I have found (disclaimer: this is still early
days, I might have some of this wrong):
* Connection process is different (I expected that).
* Unlike python-ldap, should support reconnecting automatically if
connection dies. In practise this didn't work so well. I have a upstream
ticket on this, haven't read the response yet.
https://www.assembla.com/spaces/python3-ldap/support/tickets/21
* Search takes parameters in different order. Has a paged_size parameter,
which looks interesting.
* Result returns results as { 'dn': dn, 'attributes': attributes }
dictionary instead of (dn, attributes) tuple.
* Add/modify take a modlist parameter which is a dictionary, not a list.
* Different names, e.g. MODIFY_* instead of MOD_*.
* Documentation is ok, not excellent.
* Doesn't have anything similar to ldap.modlist, ldap.dn or ldap.filter
modules. Which I use extensively. Most of these are in pure python and can
be copied. ldap.dn.str2dn() looks like the exception, if I understand this
correctly, it is native C code. ldap.modlist needs changes, due to
different format required.
* Response to my ticket was rather prompt, however creating a ticket on
www.assembla.com was a bit of a pain (website wanted me to create a 25 day
free of charge project first).
* My current code creates an object, updates an attribute on that object,
reads it back, and gets an empty object with no attributes. Still need to
find out what is going on here. Might be my fault. It does appear my code
is doing the right thing though.
The different modlist is perhaps worth explaining in detail, e.g. for
modify, compare python-ldap syntax:
[(MOD_DELETE, 'sn', None), (MOD_ADD, 'sn', ['hello'])]
with python3-ldap syntax:
{'sn': (MODIFY_REPLACE, ['hello'])}
While it is simpler, it only allows one operation per attribute, so I have
to use REPLACE. Which is probably more efficient anyway. This is perhaps
the biggest change to my code base. In fact, possibly I should be using
MODIFY_REPLACE more often, would mean I don't have to keep track of the
current state of the attribute.
The documentation suggests that each dictionary value is a list of tuples,
that doesn't match the code however.
Some sort of wrapper might be possible, and might actually be the best way
to preserve compatibility between the two libraries. So far trying to avoid
that however.
> > I am considering naming the source python-ldap3, which is different from
> > the upstream name, as it works with both python 2 and python 3, and it
> > supplies the ldap3 module, not the ldap module. So it shouldn't conflict
> > with the existing python-ldap package. If I know what I am doing, it
> > will provide the python-ldap3 and python3-ldap binary packages.
> >
> Shouldn't that be python3-ldap3?
>
Yes, typo. Thanks. I got this right in the package I uploaded to incoming.
--
Brian May
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-ldap3 Version : 0.9.3.3 Upstream Author : Giovanni Cannata * URL : https://pypi.python.org/pypi/python3-ldap * License : GPLv3 Programming Lang: Python Description : A strictly RFC 4511 conforming LDAP V3 pure Python client Please correct me if I got something wrong. I believe that python-ldap, already in Debian does not support python3. I see emails from April 2012 stating people are working on Python 3 support, but nothing since. So I can only assume that this has stalled. http://comments.gmane.org/gmane.comp.python.ldap/1078 This library, known as python3-ldap upstream, provides the ldap3 module. It is claimed it works with Python 2 and Python 3. This library has the advantage that it is pure Python code, I believe this means it doesn't require the C ldap library. I am considering naming the source python-ldap3, which is different from the upstream name, as it works with both python 2 and python 3, and it supplies the ldap3 module, not the ldap module. So it shouldn't conflict with the existing python-ldap package. If I know what I am doing, it will provide the python-ldap3 and python3-ldap binary packages. I haven't yet tried to use python-ldap3, so I assume the claims made upstream are accurate. The API looks somewhat different, although I haven't examined it in detail yet. Unfortunately, don't have a good test for this yet, my application uses the python-ldap API. I guess this will have to be updated too. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603060405.11320.84794.report...@aquitard.in.vpac.org
Bug#746632: ITP: django-simple-captcha -- Django Simple Captcha Django application
Package: wnpp Severity: wishlist Owner: Brian May * Package name: django-simple-captcha Version : 0.4.2 Upstream Author : Marco Bonetti * URL : https://github.com/mbi/django-simple-captcha * License : [1] Programming Lang: Python Description : Django Simple Captcha Django application Django Simple Captcha is an extremely simple, yet highly customizable Django application to add captcha images to any Django form. This is used by a Django application I maintain. The source package is django-simple-captcha, the binary will probably have to be renamed to python-captcha to make it Debian python policy compliant. With this in mind, I have a package available at: https://code.vpac.org/debian/pool/main/d/django-simple-captcha/ Later: Just accidentally noticed that the name (python-captcha) has already been taken in Debian, by a packaging that looks rather different (for Python, not Django), so I may not actually be able to do this. However, already entered most of this report now, so I am going submit it like it or not :-). [1] License: Copyright (c) 2008 - 2014 Marco Bonetti Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502062434.28049.80572.report...@aquitard.in.vpac.org
Bug#714342: ITP: pytz -- World timezone definitions, modern and historical
On 28 June 2013 16:29, Thomas Goirand wrote: > Package: wnpp > Severity: wishlist > Owner: Thomas Goirand > > * Package name: pytz > Version : 2013b > Upstream Author : Stuart Bishop > * URL : https://pypi.python.org/pypi/pytz > * License : Apache-2 > Programming Lang: Python > Description : World timezone definitions, modern and historical > > pytz brings the Olson tz database into Python. This library allows > accurate and cross platform timezone calculations using Python 2.4 > or higher. It also solves the issue of ambiguous times at the end > of daylight savings, which you can read more about in the Python > Library Reference (datetime.tzinfo). > I think it is already in Debian. Package: python-tz Version: 2012c-1 Installed-Size: 221 Maintainer: Debian/Ubuntu Zope Team < pkg-zope-develop...@lists.alioth.debian.org> Architecture: all Depends: tzdata, python2.7 | python2.6, python (>= 2.6.6-7~), python (<< 2.8) Description-en: Python version of the Olson timezone database python-tz brings the Olson tz database into Python. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. It also solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). Homepage: http://pypi.python.org/pypi/pytz/ Description-md5: a494a4b54ac250236f51356b49003c79 Tag: devel::lang:python, devel::library, implemented-in::python, role::devel-lib, use::timekeeping Section: python Priority: optional Filename: pool/main/p/python-tz/python-tz_2012c-1_all.deb Size: 39872 MD5sum: dd00d8e63af7988922df3df5d6440591 SHA1: 95d145e32f85fcbce9fcb2ca394642c615208e81 SHA256: 1d7c2d72c9d603c0b7eebf59ebaf1547a3189d2a71e8dbaaf01d2c3941767995 -- Brian May
Bug#666251: RFA: dar
Package: wnpp Severity: normal Hello, I don't use dar anymore, and as such am finding it hard to maintain and efficiently coordinate efforts with upstream. As such am looking for somebody who can give it the attention it deserves. dar is a replacement for tar, written in C++, that has features designed to make is especially useful for backups. Upstream links: http://dar.linux.free.fr/ http://sourceforge.net/projects/dar/ Pros: * Responsive upstream maintainer. * Simple package. * Few bugs. 4 bugs, 2 marked will not fix. Cons: * sourceforce/CVS. * Most bugs reported to Debian BTS are upstream bugs. * Some bugs can be complicated to to understand. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120330003606.31309.56273.report...@merlock.microcomaustralia.com.au
Bug#642372: RFA: dar
Package: wnpp Severity: normal Hello, Due to changing personal circumstances I have found that I am struggling to give dar the time it deserves. Generally speaking dar doesn't require much time. Last I checked it fails to build from source, due to a bug in another package #632889 and this is blocking a number of other easy to fix bugs, e.g. #637991 #637997 #638017 #639206 #639417. So fixing dar may require a NMU of libgpg-error-dev. Or an executive decision to drop support for dar-static. Upstream is responsive to all feedback. Package: dar Priority: optional Section: utils Installed-Size: 612 Maintainer: Brian May Architecture: amd64 Source: dar (2.3.10-1) Version: 2.3.10-1+b1 Depends: libattr1 (>= 2.4.41-1), libbz2-1.0, libc6 (>= 2.3.3), libdar64-4, libgcc1 (>= 1:4.1.1), libssl0.9.8 (>= 0.9.8m-1), libstdc++6 (>= 4.4.0), zlib1g (>= 1:1.1.4) Suggests: par2, dar-docs Filename: pool/main/d/dar/dar_2.3.10-1+b1_amd64.deb Size: 251162 MD5sum: 2be366be895ecaad25eca1659ea0f5c2 SHA1: 642404909f484ae74e2b0ce8ba5c5fefe4ea403c SHA256: 757360c50529fb7440e5aa308665903d801bd2e3940cb48ea01e0bf2ec6c92d3 Description: Disk ARchive: Backup directory tree and files Full featured archiver with support for differential backups, slices, compression, ATTR/ACL support. DAR also supports Pipes for remote operations, including with ssh. Homepage: http://dar.linux.free.fr/ Tag: admin::backup, interface::commandline, role::program, scope::utility, use::storing, works-with::file Thanks -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110921235118.32667.31013.report...@merlock.microcomaustralia.com.au
Bug#619194: ITP: django-tables -- A Django library for rendering Django QuerySets
Package: wnpp Severity: wishlist * Package name: django-tables Version : 0.2 Upstream Author : Michael Elsdörfer * URL : http://github.com/miracle2k/django-tables * License : BSD Programming Lang: Python Description : A Django library for rendering Django QuerySets This package helps programmers present data while allowing them to apply common tabular transformations on it. I have a working version in my private repository: https://launchpad.net/~brian-microcomaustralia/+archive/django -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikykmBGmo6tpqC-JeDyoXTB7D=s1nht5zwkl...@mail.gmail.com
Bug#619195: ITP: django-filter -- Django library for filtering Django QuerySets based on user selections
Package: wnpp Severity: wishlist * Package name: django-filter Version : 0.5.3 Upstream Author : Alex Gaynor * URL : http://github.com/alex/django-filter * License : BSD Programming Lang: Python Description : Django library for filtering Django QuerySets based on user selections A reusable Django application for allowing programmers to filter queryset dynamically. A working version is available from my private repository: https://launchpad.net/~brian-microcomaustralia/+archive/django -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiktwhcuo1muvnqojtanggepa3p21pd_whj44...@mail.gmail.com
Bug#618935: ITP: keepass2 -- password manager
On 21 March 2011 21:22, Julian Taylor wrote: > Also keepass is very widely used, it is currently top 30 most downloaded of > last month, top 70 all time on sourceforge. Also keepass is in Debian stable, and it looks like it has been for a while. As much as I like the ideas behind cpm, it unfortunately hasn't made it to stable yet, and I am not sure how hard it would be to back port it to stable. So I would agree, keep both for the moment. At least cpm has made testing now, maybe there is hope... Oh, does cpm have a website? I found http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm, but that looks seriously old, e.g. it refers to Sarge and Woody. -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimf6hs4stxbyr8wxjaw2w17+o3mehuz7apvz...@mail.gmail.com
Bug#522854: Frage zu eine DEB Paket
On 9 March 2011 19:06, Adrian von Bidder wrote: > The answer to "why is X not in Debian" for free software packages is mostly: > because nobody has done the work (yet.) The package is already in Ubuntu: http://packages.ubuntu.com/search?keywords=openbve As such I would assume most of the hard work has already been done. > Note that for openbve, a "Request for Package" has already been filed: > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522854> > so at least one other person was interested in getting a package at some > time. CCed that bug report. -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=zhbmg82bislenhdqzxf04wlrwspuunnkpe...@mail.gmail.com
Bug#589722: ITP: django-ajax-selects -- Library for editing fields with autocomplete.
Package: wnpp Severity: wishlist Owner: Brian May * Package name: django-ajax-selects Version : 1.1.4 Upstream Author : Chris Sattinger * URL : http://code.google.com/p/django-ajax-selects/ * License : Dual licensed under the MIT and GPL licenses Programming Lang: Python Description : Django library for editing fields with autocomplete Enables editing of ForeignKey, ManyToMany and simple text fields using the Autocomplete - jQuery plugin. django-ajax-selects will work in any normal form as well as in the admin. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100720113407.3458.39010.report...@andean.pri
Bug#389591: status update
Hello, I would really like to see Freeswitch in Debian. Some suggestions: 1. For an initial version of the package, just create (yes duplicate) private libraries, maybe in /usr/lib/freeswitch - it sounds like doing this correctly will take a lot of time. 2. For a long term solution for 1, where upstream is not interested in merging changes, maybe the Debian maintainers might be more open? 3. For /etc I suggest following the example of shorewall - leave the conf directory empty, and allow the system administrator to copy demo files from /usr/share/doc/freeswitch/examples if desired. I think freeswitch configuration is sufficiently complex enough that we don't really want to try and manage the configuration files automatically. Thanks for your efforts, -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3c5cf5261002211833o7989f00ch33cf14ed0d18a...@mail.gmail.com
Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator
Stefano Zacchiroli wrote: Uh? Can you please explain? Even though I'm not following the upstream evolution I'm a user of the shorewall package, which has IPv6 support even though disabled by default. Why we now need a separate package now? It needs to be a separate package, because that is the way it is distributed upstream. ie. shorewall6, with IPv6 support is very distinct from shorewall, with IPv4 support. For more information see <http://www.shorewall.net/IPv6Support.html>. Disclaimer: I am not involved in packaging this for Debian or upstream - just a user. -- Brian May -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#494705: [Monotone-devel] RFA: monotone-viz - visualize a monotone repository
Shaun Jackman wrote: Due to a change of job, I am not using this tool as regularly as I used to. This package we would be better maintained by someone who does. There is one outstanding release-critical bug. Hello Debian-Release team, monotone-viz is RFA'ed and has a release critical bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494558> I am assuming this is a issue in Lenny because Lenny appears to have the latest version of monotone: <http://packages.debian.org/lenny/monotone> Unfortunately, the solution recommended in the bug report is to update the package to the newest upstream version. It looks like this version uses a different mechanism to access the database, from <http://oandrieu.nerim.net/monotone-viz/> 1.0: do not access the monotone database directly: obtain all necessay information via the |mtn automate| mechanism The other changes appear to be relatively minor (documentation and build issues). If somebody were to package the latest version and put it in unstable, is there any chance of it getting into Lenny? Thanks. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Luk Claes wrote: apt-get install debian-backports-keyring or gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C gpg --export | apt-key add - This involves 3 separate commands, and modifies files under /root/.gnupg/ at the same time. Seems overly complicated, especially for non-technical people. Would it be possible to simplify this? or wget -O - http://backports.org/debian/archive.key | apt-key add - Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Adam Majer wrote: Certainly, the backports.org keyring is useful to some people, *but* it is, 1. not free software Presumably the following packages would never have made it into Debian if a public key didn't comply with the DFSG. debian-archive-keyring - GnuPG archive keys of the Debian archive debian-edu-archive-keyring - GnuPG archive keys of the Debian Edu archive debian-keyring - GnuPG (and obsolete PGP) keys of Debian Developers debian-maintainers - GPG keys of Debian maintainers emdebian-archive-keyring - GnuPG archive keys for the emdebian repository Having said that, having one entire package for one key file seems like overkill to me; is there not any other way of securely distributing the key? Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358486: O: planner -- project management application
Package: wnpp Severity: normal Mikael asked me to orphan this package on his behalf: Mikael> I'm nearly Missing In Action, I don't have any time to Mikael> take care of my debian packages, I have got real a baby to Mikael> take care of instead :-) ... Mikael> Multisync and planner should be orphaned, if you Mikael> got the time, please orphan them for me. The package description is: Planner is a project management application that is developed by Imendio as a free software project licensed under the GPL. . Planner supports Gantt charts, resource allocation and integration with various other GNOME applications via its plug-in architecture. . Homepage: http://planner.imendio.org/ . Planner was formerly known as Mr.Project. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-pegasos Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358485: O: multisync -- A program to synchronize PIM data
Package: wnpp Severity: normal Mikael asked me to orphan this package on his behalf: Mikael> I'm nearly Missing In Action, I don't have any time to Mikael> take care of my debian packages, I have got real a baby to Mikael> take care of instead :-) ... Mikael> Multisync and planner should be orphaned, if you Mikael> got the time, please orphan them for me. The package description is: Synchronize calendars, addressbooks and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. Currently it has client plugins for Ximian Evolution and IrMC mobile clients (cell phones such as SonyEricsson T39/T68 and Siemens S45i) via Bluetooth, IR and cable. To get all plugins install libmultisync-plugin-all. . To get all Homepage http://multisync.sourceforge.net -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-pegasos Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358482: O: arla
Package: wnpp Severity: normal Mikael no longer has time to maintain this package: Mikael> I'm nearly Missing In Action, I don't have any time to Mikael> take care of my debian packages, I have got real a baby to Mikael> take care of instead :-) Arla has a number of release critcal bugs: Mikael> Arla should need a rebuild against your newer heimdal-dev Mikael> package, and when that's done it will probably not depend Mikael> on krb4 anymor Presumably this will fix the majority of the release critical bugs. (I have just filled a bug report against ftp.debian.org asking krb4 to be removed from Debian.) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-pegasos Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#141748: openxpki
Anyone looking at openca should also check out openxpki: http://www.openxpki.org/> - it looks like openxpki may be the new openca. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#141748: acknowledged by developer (WNPP bug closed)
reopen 141748 thanks I still think it would be a great idea to see openca in Debian, despite me not having time anymore. It is the only full featured X509 CA I know of. I reopened this bug report instead of the other bug 157711, because this one appears to have more information concerning attempts to package it. I don't know how two bugs came to be opened on the same package. Then again, both bugs are merged, so I might just end up opening the other again anyway... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285267: RFA: libpam-heimdal
Package: wnpp Severity: normal Hello, I longer use this package, not able to test it, nor am I interested in maintaining it anymore. There is one reported bug (#269457, with patch) and one wishlist item (#234882). It is likely that other bugs exist that haven't been reported. The best solution (as suggested in bug #269457) might be to switch to the FreeBSD source code or some other source code. Once this is done, I expect this package to be a very low maintance package. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#285041: ITP: fprobe-ng -- Export captured traffic to remote NetFlow Collector
>>>>> "Radu" == Radu Spineanu <[EMAIL PROTECTED]> writes: What is the difference between this ITP and that in #272201? -- Brian May <[EMAIL PROTECTED]>
Bug#141748: OpenCA packaging status
>>>>> "Jeremy" == Jeremy T Bouse <[EMAIL PROTECTED]> writes: Jeremy> I was just trying to see where any packaging work was at Jeremy> before I spent too much time working to get 0.9.2-RC5 Jeremy> packaged. I need this to be packaged for work and am able Jeremy> to take care of it if it's not currently being worked Jeremy> on. I've already looked at the binary DEBs created by Jeremy> Alessandro but didn't notice any of the source deb files Jeremy> needed to build them. I'm working on the packaging from Jeremy> scratch at this point but should hopefully have something Jeremy> together shortly as I have it building and it's just a Jeremy> matter of arranging the packaging. Due to time constraints, I am no longer working on OpenCA. I think it would be really good though if we could get it into Debian, even if it is too late (probably) for Sarge. I believe Alessandro has done a lot of work to get it going, hopefully he will respond and indicate the current status. I seem to recall that the Debian directory is in CVS on the upstream's CVS server, I haven't tried to access it. -- Brian May <[EMAIL PROTECTED]>
Bug#141748: Status?
>>>>> "Ferdinand" == Ferdinand O Tempel <[EMAIL PROTECTED]> writes: Ferdinand> Hey, I've recently taken an interrest in this product, Ferdinand> and I was looking to implement it on some debian Ferdinand> systems. To my surprise it's been silent around this Ferdinand> package for almost 2 years. What is the current status Ferdinand> of this package? OpenCA itself is currently somewhere Ferdinand> in its 0.9's, and at least debian unstable now has a Ferdinand> sufficient high version of openssl to be able to use Ferdinand> it, I figure. Ferdinand> If noone else is currently working on this, I could Ferdinand> have a whack at packaging it on my own, but I'd hate to Ferdinand> reinvent the wheel. Alessandro Razeto <[EMAIL PROTECTED]> is currently working on it. Alessadandro, What was the current status? Are there debs available for testing? Thanks. -- Brian May <[EMAIL PROTECTED]>
Bug#211120: ITP: gnat-gdb -- Ada-aware version of GDB
9221: `The Implementation of Standard I/O' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:10159: `The GNAT Library' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11059: `Interfacing to Other Languages' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11206: `Machine Code Insertions' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11345: `GNAT Implementation of Tasking' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11450: `Code generation for array aggregates' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11606: `Specialized Needs Annexes' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11638: `Compatibility Guide' has no Up field (perhaps incorrect sectioning?). ./gfdl.texi:1: `GNU Free Documentation License' has no Up field (perhaps incorrect sectioning?). ./gnat_rm.texi:11943: Prev field of node `Index' not pointed to. ./gfdl.texi:1: This node (GNU Free Documentation License) has the bad Next. ./gnat_rm.texi:11943: Up reference to nonexistent node `Top' (perhaps incorrect sectioning?). ./gnat_rm.texi:11943: warning: unreferenced node `Index'. make: [build-stamp] Error 1 (ignored) cd texi && makeinfo --force --html -o ../html/gnat_ug gnat_ug_unx.texi ./gnat_ug_unx.texi:439: `About This Guide' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:647: `Getting Started with GNAT' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:1094: `The GNAT Compilation Model' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:2473: `Compiling Using gcc' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:4786: `Binding Using gnatbind' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:6606: `Linking Using gnatlink' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:6847: `The GNAT Make Program gnatmake' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:7439: `Renaming Files Using gnatchop' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:7725: `Configuration Pragmas' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:7826: `Handling Arbitrary File Naming Conventions Using gnatname' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:8002: `GNAT Project Manager' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:10717: `Elaboration Order Handling in GNAT' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:12520: `The Cross-Referencing Tools gnatxref and gnatfind' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:13137: `File Name Krunching Using gnatkr' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:13327: `Preprocessing Using gnatprep' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:13571: `The GNAT Library Browser gnatls' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:13809: `GNAT and Libraries' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:14196: `Using the GNU make Utility' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:14482: `Finding Memory Problems with gnatmem' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:14896: `Finding Memory Problems with GNAT Debug Pool' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:15035: `Creating Sample Bodies Using gnatstub' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:15143: `Reducing the Size of Ada Executables with gnatelim' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:15445: `Other Utility Programs' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:15770: `Running and Debugging Ada Programs' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:16825: `Inline Assembler' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:18374: `Performance Considerations' has no Up field (perhaps incorrect sectioning?). ./gfdl.texi:1: `GNU Free Documentation License' has no Up field (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:18699: Prev field of node `Index' not pointed to. ./gfdl.texi:1: This node (GNU Free Documentation License) has the bad Next. ./gnat_ug_unx.texi:18699: Up reference to nonexistent node `Top' (perhaps incorrect sectioning?). ./gnat_ug_unx.texi:18699: warning: unreferenced node `Index'. make: [build-stamp] Error 1 (ignored) cd texi && makeinfo --no-split -o ../info/gnat_rm.info gnat_rm.texi cd texi && makeinfo --no-split -o ../info/gnat_ug.info gnat_ug_unx.texi cd texi && \ makeinfo --no-headers --no-split -o ../txt/gnat_rm.txt gnat_rm.texi cd texi && \ makeinfo --no-headers --no-split -o ../txt/gnat_ug.txt gnat_ug_unx.texi touch build-stamp debian/rules binary dh_testdir dh_testroot dh_clean -k [...] -- Brian May <[EMAIL PROTECTED]>
Bug#212729: ITP: gtkatlantic -- game like monopoly
On Thu, Sep 25, 2003 at 06:07:39PM +0200, Julien Delange wrote: > * Package name: gtkatlantic > Version : 0.2.13 > Upstream Author : Rochet Sylvain <[EMAIL PROTECTED]> > * URL : http://gtkatlantic.sourceforge.net/ > * License : GPL > Description : game like monopoly > > GtkAtlantic is a game, like monopoly. > This is a network client which work with the monopd server > (see http://unixcode.org/monopd/) Is monopd in Debian? If I go to http://gtkatlantic.sourceforge.net/, I see a message that the site may be closed down due to patent issues in Europe. If so, will that effect the ITP? -- Brian May <[EMAIL PROTECTED]>
Bug#207849: O: fpm
On Sun, Sep 28, 2003 at 01:09:17AM +0200, Manuel Estrada Sainz wrote: > I am until next Monday. But after that I'll have more time. > > I'll adopt it as soon as I get it building and fix the most fixable > bugs. Thanks. > I also plan to implement some of the ideas of http://dpasman.sf.net/ > but that will probably take much longer, in the mean time I'll adopt > fpm and try to keep it in shape. Sounds good. Also fpm upstream has now revived (see other BTS reports), and there has now been a new upstream release of fpm. The task of marging the two versions together could be... well... interesting ;-). -- Brian May <[EMAIL PROTECTED]>
Bug#211120: ITP: gnat-gdb -- Ada-aware version of GDB
On Sat, Sep 20, 2003 at 08:27:36AM +0200, Ludovic Brenta wrote: > Brian May <[EMAIL PROTECTED]> writes: > > > Will it work with programs compiled with both gnat and gnat-3.3? > > I just tried it with gnat-3.3. It works. Will you sponsor this > package for me? I just issued an RFS on debian-mentors. Unfortunately I am very short of time... However considering I like Ada so much ;-), and want to see more of it in Debian, if you can't find anybody else to act as a sponsor, I will upload the packages for you. -- Brian May <[EMAIL PROTECTED]>
Bug#211120: ITP: gnat-gdb -- Ada-aware version of GDB
On Tue, Sep 16, 2003 at 03:44:04AM +0200, Ludovic Brenta wrote: > Package: wnpp > Version: unavailable; reported 2003-09-16 > Severity: wishlist > > * Package name: gnat-gdb > Version : 5.3.gnat.0.0.20030225 > Upstream Author : Ada Core Technologies > * URL : http://www.act-europe.org/GDB/ > * License : GPL > Description : Ada-aware version of GDB > > This is a version of GDB 5.3 that allows debugging of progams written in Ada > 95. It consists of GDB 5.3 with patches contributed by Ada Core > Technologies, > the company behind GNAT. Note that ACT considers this version to be beta- > quality. Great! Just what I was looking for... Pity this can't be integrated with the standard GDB, I guess the release quality isn't yet good enough though... I assume this will conflict with the standard gdb? Will it work with programs compiled with both gnat and gnat-3.3? (gnat seems to be old, I heard somewhere that 3.15 is now available, and gnat-3.3 seems to be buggy). -- Brian May <[EMAIL PROTECTED]>
Bug#211121: ITP: gnat-gps -- The GNAT Programming System - advanced IDE for C and Ada
On Tue, Sep 16, 2003 at 03:48:38AM +0200, Ludovic Brenta wrote: > GPS is a complete integrated development environment that gives access > to a wide range of tools and integrates them smoothly. I tried to get GPS working, but both gnat and gnat-3.3 seem to have problems reading the generated project *.gpr file. gnat says for default.gpr 3:3 : "end" expected Eyeballing the file reveals nothing obvious wrong, so I wonder if it is a case of gnat 3.14p-3 (the latest in Debian) being too old? Of couse, it could be because the user (ie. me) did something wrong... -- Brian May <[EMAIL PROTECTED]>
Bug#207849: O: fpm
Package: wnpp Version: unavailable; reported 2003-08-30 Severity: normal Unfortunately I am currently maintaining too many packages to keep track of, and do not have time to tack over the role of being the upstream & Debian maintainer of this package. (upstream is dead). It would appear that the co-maintainer is in a similar position. I would expect that the release critical bugs against fpm would be easy to fix given the time. The idea behind fpm is a pretty good one though, and I don't know of any other alternative to it. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux snoopy 2.4.21 #1 Tue Aug 26 17:39:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=
Bug#194961: ITP: yaz -- A C/C++ toolkit for Z39.50/ISO23950 applications
On Tue, May 27, 2003 at 03:46:56PM -0600, Eric Schwartz wrote: > Package: wnpp > Version: unavailable; reported 2003-05-27 > Severity: wishlist > > * Package name: yaz > Version : 2.0.2 > Upstream Author : IndexData > * URL : http://www.indexdata.dk/yaz/ > * License : BSD-ish: http://www.indexdata.dk/yaz/doc/license.php > Description : A C/C++ toolkit for Z39.50/ISO23950 applications > > YAZ is a C/C++ programmer's toolkit supporting the development of > Z39.50v3/SRW clients and servers. Sample clients and servers are > included with the distribution, as well as documentation. > > I've put prospective packages up at > > http://people.debian.org/~emschwar/yaz.html > > if anybody cares to take a look. The license is basically BSD; it lacks > clause 2 in /usr/share/common-licenses/BSD, and the disclaimer is worded > slightly differently but AFAICT it is functionally identical. Great! After looking at Koha (an open source library catalogue system) http://www.koha.org/>, I was hoping that this would get packaged (Koha requires yaz). (actually I haven't yet been able to get Koha to do anything useful; but lets just ignore irrevelavant details like that :-); I probably should have started with the stable version not the beta verion). -- Brian May <[EMAIL PROTECTED]>
Bug#189659: will adopt dnrd
On Thu, Apr 24, 2003 at 10:30:06PM +1000, Anibal Monsalve Salazar wrote: > SECURITY NOTE: dnrd is susceptible to buffer overflow attacks. > However, by default dnrd changes to the "nobody" user. It also does > a chroot to the /etc/dnrd directory, after checking that /etc/dnrd > exists and contains no subdirectories and no executables and is only > writable by root. Using the nobody as a work around for possible security holes seems a really bad idea. At the very least, please consider using another user ID, as other programs might be using the nobody user. If one program is compromised, the rest will also become compromised if they are sharing the one user. Also, even using a non-root, non-shared user id is not going to prevent an attacker doing damage via a buggy daemon, non-root users can do bad things too. eg. DOS attacks (ulimits should help here), attack computers on private/firewalled networks, etc. -- Brian May <[EMAIL PROTECTED]>
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, Dec 28, 2002 at 01:12:10PM +0100, Russell Coker wrote: > On Sat, 28 Dec 2002 08:28, Brian May wrote: > > - The Author recommends linking with -static, so restoration programs > > will work without extra libraries. I haven't decided if this is a good > > idea or not, if it needs to be applied to all binaries. lintian > > gets upset if my package contains static binaries. > > I suggest having a separate "dar-restore-static" package for that. Should I have the packages conflict, or should I give the binary another name, eg. dar_static? -- Brian May <[EMAIL PROTECTED]>
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, Dec 28, 2002 at 01:12:10PM +0100, Russell Coker wrote: > > - My version is compiled with ATTR (EA) support, however, DAR gets very > > verbose if the filesystem doesn't support ATTRs (IMHO errors of type > > "Operation not supported" need to be ignored). These warnings > > will disappear if the -Uu flags are used (don't archive ATTRs). > > Maybe you could patch it to check for ATTR support on backup at the start of > each file system. If a file system does not support ATTR then display a > single message "File system /var does not support ATTR." and continue on with > no further messages. Of course it's a bit more serious if you do a restore > with ATTR support and the file system doesn't like it... I should restate my initial claim, I was slightly inaccurate. It is not an error to read ATTRs from a filesytem that doesn't have ATTRs, you will simply get nothing returned. It is an error to read ATTRs when running a kernel that doesn't support ATTRs though, the error is ENOSYS. I have constructed a patch, and will send it upstream, that allows ATTRs to be ignored if ENOSYS is set. This comes at the risk though that if the user hasn't realized that the kernel doesn't support ATTRs, they will get siliently ignored. -- Brian May <[EMAIL PROTECTED]>
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, Dec 28, 2002 at 01:12:10PM +0100, Russell Coker wrote: > On Sat, 28 Dec 2002 08:28, Brian May wrote: > > - The Author recommends linking with -static, so restoration programs > > will work without extra libraries. I haven't decided if this is a good > > idea or not, if it needs to be applied to all binaries. lintian > > gets upset if my package contains static binaries. > > I suggest having a separate "dar-restore-static" package for that. Good idea. > > > - My version is compiled with ATTR (EA) support, however, DAR gets very > > verbose if the filesystem doesn't support ATTRs (IMHO errors of type > > "Operation not supported" need to be ignored). These warnings > > will disappear if the -Uu flags are used (don't archive ATTRs). > > Maybe you could patch it to check for ATTR support on backup at the start of > each file system. If a file system does not support ATTR then display a > single message "File system /var does not support ATTR." and continue on with > no further messages. Of course it's a bit more serious if you do a restore > with ATTR support and the file system doesn't like it... The problem with this approach is that it would need to be done on a per file basis rather then per filesystem (eg. consider backing up multiple filesystems). Looking at the code though it should be trivial to check errno==ENOTSUP at the appropriate place, and just return an empty EA list in this case (exactly what would happen with the -Uu flag or if EA support wasn't enabled when compiling). I suspect that the write routine only attempts to write EAs if there are EAs to write, so theoritically it should already be OK. Even if there are EAs to write and you want to extract anyway, it should be possible to use -Uu flag to prevent dar from complaining. > > - ssh can be used for backups (just pipe the data via ssh to the > > destination file), for incremental backups (generate catalog at server > > and send it to client first). However, I am not certain about restores > > (client requires 2 pipes to server, one in each direction; this makes > > me nervous about potential deadlocks). > > Shouldn't be a problem, just do "ssh client restore-comand" and then the > client's stdin and stdout are the two pipes you need. Gotta test it first of > course, but I expect it to work. That only brings STDOUT and STDIN to the local computer. The hard part will be doing: dar ... | ssh client darr_slave | dar ... where both dars represent the one process (so the above command line wont work). In other programs (eg. rsync, scp, cvs) it is more usually done like: dar ... -e ssh client darr_slave dar currently doesn't support this. I have heard that Bi-Directional communications like this is a risky, and buffering issues have caused big problems even for programs like rsync (hopefully resolved now). -- Brian May <[EMAIL PROTECTED]>
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, Dec 28, 2002 at 01:18:03PM +0100, Josselin Mouette wrote: > Maybe you can provide both dynamically linked and statically linked > packages. A .udeb could also be useful, if the software can be used to > install a preconfigured system. A udeb is an interesting idea. However, the binary is rather big (4.5Meg if I read this correctly): -rwxr-xr-x root/root 4496772 2002-12-28 12:10:56 ./usr/bin/dar which is stripped and dynamically linked. Are there any guidelines on how big the contents of a udeb can be before it is considered too big? It might be possible to reduce this size, I don't know. It is C++ code. -- Brian May <[EMAIL PROTECTED]>
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
Package: wnpp Version: N/A; reported 2002-12-28 Severity: wishlist * Package name: dar Version : 1.2.0 Upstream Author : Denis Corbin <[EMAIL PROTECTED]> * URL : http://dar.linux.free.fr/ * License : GPL Description : Disk ARchive: Backup directory tree and files. Full featured archiver with support for differential backups, slices, compression, ATTR/ACL support. DAR also supports Pipes for remote operations, including with ssh. Before I package this for Debian, some issues remain: - The Makefile needs a minor, but manual, modification to compile on alpha. - The Author recommends linking with -static, so restoration programs will work without extra libraries. I haven't decided if this is a good idea or not, if it needs to be applied to all binaries. lintian gets upset if my package contains static binaries. - My version is compiled with ATTR (EA) support, however, DAR gets very verbose if the filesystem doesn't support ATTRs (IMHO errors of type "Operation not supported" need to be ignored). These warnings will disappear if the -Uu flags are used (don't archive ATTRs). - ssh can be used for backups (just pipe the data via ssh to the destination file), for incremental backups (generate catalog at server and send it to client first). However, I am not certain about restores (client requires 2 pipes to server, one in each direction; this makes me nervous about potential deadlocks). In fact, I am not sure how this can be done, dar_slave needs to be run on the server, dar needs to be run on the client. STDOUT from dar needs to go to STDIN on dar_slave and vice versa. Any comments on the above? If anybody is interested, I can place my package online for testing before I upload it to Debian. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux snoopy 2.4.19 #1 Wed Oct 30 11:36:54 EST 2002 i686 Locale: LANG=C, LC_CTYPE=
Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Fri, Nov 22, 2002 at 09:47:48AM -0600, John Goerzen wrote: > On Fri, Nov 22, 2002 at 12:24:34AM -0500, Joey Hess wrote: > > > After verifying the signature on the data, the receiver does some sanity > > > checks. One of the checks is doing an md5sum over the entire file > > > > (remember, this includes both the headers and the payload). If it > > > has seen the same md5sum in the last 60 days, it rejects the request. If > > > the date of the request was more than 30 days ago, it rejects the request. > > > > Hold on, if you're md5summing the headers, what is to stop an attacker > > from modifying the subject, and using an intercepted, gpg-signed body to > > repeat the command? > > It's an md5sum over the entire file. The file includes both the headers and > the body. No, I think the question might be "what if the MD5SUM is different but the GPG signature is the same"? I think it depends on the method used to sign the message, some methods sign the headers, some don't. So if I manually sign a message, and include it in the body of this message, it won't protect the headers in anyway. Somebody could alter the headers, resulting in the md5sum becomming altered, and the message won't be detected as a replay. Also, to prevent another possible (maybe obvious) attack; make sure your clock is set correctly (and not some time in the future) before sending a email... -- Brian May <[EMAIL PROTECTED]>
Bug#170069: ITP: grunt -- Secure remote execution via UUCP or e-mail using GPG
On Thu, Nov 21, 2002 at 04:12:42PM -0600, John Goerzen wrote: > After verifying the signature on the data, the receiver does some sanity > checks. One of the checks is doing an md5sum over the entire file > (remember, this includes both the headers and the payload). If it > has seen the same md5sum in the last 60 days, it rejects the request. If > the date of the request was more than 30 days ago, it rejects the request. 30 days seems like an awfully long time... I would have though rejecting any requests, say an hour old would be better... So, if you did issue an halt command, the worst an attacker could do would be to delay execution by one hour, not 30 days. -- Brian May <[EMAIL PROTECTED]>
Bug#166545: O: scannerdaemon
Package: wnpp Version: N/A; reported 2002-10-27 Severity: normal scannerdaemon no longer works in Debian with the DFSG compliant jikes and kaffe and latest virus signatures downloaded with oav-update. A good alternative exists, clamav, which is written entirely in C++. Hence, I am no longer interested in maintaining this package anymore. This is not however to imply that scannerdaemon is a bad program, it isn't. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux snoopy 2.4.18 #1 Thu Jul 11 16:32:07 EST 2002 i686 Locale: LANG=C, LC_CTYPE=
Bug#160916: RFA: fpm -- Password Manager
retitle 160916 O: fpm -- Password Manager thanks After receiving one more bug report, I have decided to orphan fpm, because: > 1. Can no longer build for unstable. I have tried hacking at > the Makefiles, etc, but it still won't build. Also I get > warnings for issues that I just fixed. eg. for some reason > the intl directory is no longer created. > > 2. Somebody with more understanding of Gnome, Glade, will probably > be able to fix this faster then I can. > > 3. This package is probably better suited to someone who > tracks unstable (as all my computers run stable). It is no longer > possible to have the same version compile on woody and unstable > due to the build-depends change (see below). > > 4. No active upstream maintainer. 5. The code is of bad quality, see bugs #144895 and #161596. -- Brian May <[EMAIL PROTECTED]>
Bug#160916: RFA: fpm -- Password Manager
Package: wnpp Version: N/A; reported 2002-09-15 Severity: normal I request an adopter for the fpm package. The package description is: Figaro's Password Manager is a program that allows you to securely store the passwords you use on the web. My reasons are as follows: 1. Can no longer build for unstable. I have tried hacking at the Makefiles, etc, but it still won't build. Also I get warnings for issues that I just fixed. eg. for some reason the intl directory is no longer created. 2. Somebody with more understanding of Gnome, Glade, will probably be able to fix this faster then I can. 3. This package is probably better suited to someone who tracks unstable (as all my computers run stable). It is no longer possible to have the same version compile on woody and unstable due to the build-depends change (see below). 4. No active upstream maintainer. This package contains 3 bugs, 2 which should be easy to fix, not sure about the other one (which was forwarded upstream to the non-active upstream maintainer.) The version in Debian requires the build depends to be changed from gdk-imlib-dev to gdk-imlib1-dev. I can provide my source with my other changes if requested, but it might be better to use the Debian version as a starting point. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux scrooge 2.4.18 #1 Sun Jul 14 19:42:26 EST 2002 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB
Bug#157975: ITP: unzoo -- zoo archive extractor
On Fri, Aug 23, 2002 at 07:48:32PM +0200, Thomas Schoepf wrote: > * Package name: unzoo > Version : 4.4 > Upstream Author : Martin Schoenert > * URL : > http://archives.math.utk.edu/software/multi-platform/gap/util/ > * License : Public Domain > Description : zoo archive extractor > > A zoo archive is a file that contains several files, called its > members, usually in compressed form to save space. 'unzoo' can list > all or selected members or extract all or selected members, i.e., > uncompress them and write them to files. It cannot add new members or > delete members. For this you need the zoo archiver, called 'zoo'. How compatable is this with zoo? Will amavis be able to use unzoo instead of /usr/bin/zoo, or are there compatability problems (eg. different parameters, different list format, etc) that may somehow need to be addressed? -- Brian May <[EMAIL PROTECTED]>
Bug#157711: RFP: openca -- Full featured opensource X.509 CA
Package: wnpp Version: N/A; reported 2002-08-21 Severity: wishlist * Package name: openca Version : 0.9.x Upstream Author : Tommaso Cucinotta, etc. * URL : http://www.openca.org/openca/ * License : Apache Style License Description : Full featured opensource X.509 CA This is a full featured, web based CA, with support for breaking the task up into multiple modules (so the actual part of the CA for instance can live on a disconnected computer for increased security). It also supports stuff like CRLs for revocation, storing certificates in LDAP, and controlling access to different functions based on the adminstrators authenticated key (if correctly configured using HTTPS). I have preliminary packages online at http://snoopy.apana.org.au/~ftp/debian/pool/openca/> (from CVS), but don't have time to test these or keep them up to date. Also, it is possible that someone else might be able to improve on my hacked configuration scheme (upstream rely on configure to do run time configuration; also some configuration files are altered at run time and should not automatically get replaced, altered, or added when upgrading due to security reasons). It requires the CVS version of openssl. This shouldn't be as difficult as it might appear at first, all that is required is a copy of /usr/bin/openssl (could be renamed to openssl-cvs), and no shared libraries seem to be required. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux snoopy 2.4.18 #1 Thu Jul 11 16:32:07 EST 2002 i686 Locale: LANG=C, LC_CTYPE=
Bug#155626: ITP: exiscan -- An email virus scanner for the exim MTA
On Wed, Aug 07, 2002 at 07:21:39AM +0200, David Schmitt wrote: > Hi Gerfrid, folks! > > On Tue, Aug 06, 2002 at 12:14:28PM +0200, Gerfried Fuchs wrote: > > Though it's GPL it will go into contrib for it needs any virus scanner Strange. Wonder how I missed that... > [EMAIL PROTECTED]:~$ apt-cache show clamav > Package: clamav > [..] > Description: powerful anti-virus scanner for Unix. > A GPL'ed virus scanner featuring: ...add to that: Package: scannerdaemon Priority: optional Section: mail Installed-Size: 119 Maintainer: Brian May <[EMAIL PROTECTED]> Architecture: all Version: 5.1-4 Depends: kaffe, oav-virussignatures Filename: pool/main/s/scannerdaemon/scannerdaemon_5.1-4_all.deb Size: 49024 MD5sum: 882c2c6e4a2b2a350d524738f5cd0ad4 Description: virus scanner written in Java Scannerdaemon is a daemon that accepts incoming requests to scan files for viruses. This is also in main. -- Brian May <[EMAIL PROTECTED]>
Bug#155626: ITP: exiscan -- An email virus scanner for the exim MTA
On Tue, Aug 06, 2002 at 12:14:28PM +0200, Gerfried Fuchs wrote: > I don't know about amavis -- that should be able to do almost the same, > but the exim hooks aren't turned on in that package. It's just a > sugguestion to do this package. amavis-exim? (recommended configuration requires newer version of exim not yet in Debian ;-( ) amavis-ng? (I am not sure if amavis-ng has been uploaded to Debian yet, but there was an ITP). > Thanks for the flames/comments/input. Sounds like a good idea, and might be worth while even if it does compete with amavis. (just look at the number of forks in amavis...) -- Brian May <[EMAIL PROTECTED]>
Bug#150218: ITP: dansguardian -- True web content filtering
On Mon, 2002-06-17 at 14:06, Jonathan Hall wrote: > The content phrase filtering will check for pages that contain profanities > and phrases often associated with pornography and other undesirable content. > The POST filtering allows you to block or limit web upload. The URL and > domain filtering is able to handle huge lists and is significantly faster > than squidGuard. Perhaps a more interesting application on content filtering (at least for me) is virus scanning in files downloaded. Can dansguardian do this? Perhaps when used with a virus scanner, eg clamav or scannerdaemon? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
