Bug#738156: ITP: python-klein -- Python Twisted Web micro-framework inspired by Flask

2014-02-07 Thread Brian Campbell 
Package: wnpp
Severity: wishlist
Owner: Brian Campbell 

* Package name: python-klein
  Version : 0.2.3
  Upstream Author : David Reid 
* URL : https://github.com/twisted/klein
* License : MIT (Expat)
  Programming Lang: Python
  Description : Python Twisted Web micro-framework inspired by Flask

 Klein is a micro-framework for developing production ready web
 services with python.  It is 'micro' in that it has an incredibly
 small API similar to bottle and flask.  It is not 'micro' in that it
 depends on things outside the standard library.  This is primarily
 because it is built on widely used and well tested components like
 werkzeug and Twisted.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140208073034.29026.4964.reportbug@gherkin.editshare.boston

Re: Next time help needed, now with a real Python library (pysam)

2014-02-07 Thread Andreas Tille 
Hi Olivier,

On Fri, Feb 07, 2014 at 06:08:20PM +0100, Olivier Sallou wrote:
> 
> You could first try deleting:
> 
>  130 from distribute_setup import use_setuptools
>  131 use_setuptools()
> 
> if setuptools is already installed.

Patch commited - thanks for the hint.
 
> > How can I prevent the build process from trying to download something
> > and start straightly using Debian packaged setup tools?
> >
> > Once this probably simple question is solved I'd like to come up with a
> > more tricky one:  The Python modules are using libraries which are
> > just packaged (samtools + tabix).  I wonder how I could tweak the
> > build process to use the Debian packaged versions in favour of the
> > code copies here?

I try for this myself first and might come back with further questions.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207173136.ga15...@an3as.eu

Re: Next time help needed, now with a real Python library (pysam)

2014-02-07 Thread Olivier Sallou 

On 02/07/2014 05:12 PM, Andreas Tille wrote:
> Hi folks,
>
> since it worked out pretty well with my more simple question I'm
> impudent enough to come up with a more tricky question:  I need to
> tackle
>
> git://anonscm.debian.org/debian-med/pysam.git
>
> as a predependency of another package but it seems I need to tweek
> the build process initially says:
>
>
>dh_auto_clean
> Downloading 
> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.34.tar.gz
Problem comes from distribute_setup.py which makes some downloads.
It is used in setup.py:

from distribute_setup import use_setuptools
use_setuptools()

It is looking for a "distribute-%s-py%d.%d.egg" in python modules.

Maybe if the "distribute" module is installed (build dep) , it will not
do any download.

You could first try deleting:

 130 from distribute_setup import use_setuptools
 131 use_setuptools()

if setuptools is already installed.

Olivier
> Traceback (most recent call last):
>   File "setup.py", line 131, in 
> use_setuptools()
>   File 
> "/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
>  line 152, in use_setuptools
> return _do_download(version, download_base, to_dir, download_delay)
>   File 
> "/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
>  line 131, in _do_download
> to_dir, download_delay)
>   File 
> "/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
>  line 201, in download_setuptools
> src = urlopen(url)
>   File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
> return _opener.open(url, data, timeout)
>   File "/usr/lib/python2.7/urllib2.py", line 410, in open
> response = meth(req, response)
>   File "/usr/lib/python2.7/urllib2.py", line 523, in http_response
> 'http', request, response, code, msg, hdrs)
>   File "/usr/lib/python2.7/urllib2.py", line 442, in error
> result = self._call_chain(*args)
>   File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
> result = func(*args)
>   File "/usr/lib/python2.7/urllib2.py", line 629, in http_error_302
> return self.parent.open(new, timeout=req.timeout)
>   File "/usr/lib/python2.7/urllib2.py", line 404, in open
> response = self._open(req, data)
>   File "/usr/lib/python2.7/urllib2.py", line 422, in _open
> '_open', req)
>   File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
> result = func(*args)
>   File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
> return self.do_open(httplib.HTTPSConnection, req)
>   File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
> raise URLError(err)
> urllib2.URLError: 
> dh_auto_clean: python setup.py clean -a returned exit code 1
>
>
> How can I prevent the build process from trying to download something
> and start straightly using Debian packaged setup tools?
>
> Once this probably simple question is solved I'd like to come up with a
> more tricky one:  The Python modules are using libraries which are
> just packaged (samtools + tabix).  I wonder how I could tweak the
> build process to use the Debian packaged versions in favour of the
> code copies here?
>
> Kind regards
>
>Andreas.
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Next time help needed, now with a real Python library (pysam)

2014-02-07 Thread Andreas Tille 
Hi folks,

since it worked out pretty well with my more simple question I'm
impudent enough to come up with a more tricky question:  I need to
tackle

git://anonscm.debian.org/debian-med/pysam.git

as a predependency of another package but it seems I need to tweek
the build process initially says:


   dh_auto_clean
Downloading 
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.34.tar.gz
Traceback (most recent call last):
  File "setup.py", line 131, in 
use_setuptools()
  File 
"/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
 line 152, in use_setuptools
return _do_download(version, download_base, to_dir, download_delay)
  File 
"/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
 line 131, in _do_download
to_dir, download_delay)
  File 
"/home/tillea/debian-maintain/alioth/debian-med_git/build-area/pysam-0.7.5/distribute_setup.py",
 line 201, in download_setuptools
src = urlopen(url)
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 410, in open
response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 523, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 442, in error
result = self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 629, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
'_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
raise URLError(err)
urllib2.URLError: 
dh_auto_clean: python setup.py clean -a returned exit code 1


How can I prevent the build process from trying to download something
and start straightly using Debian packaged setup tools?

Once this probably simple question is solved I'd like to come up with a
more tricky one:  The Python modules are using libraries which are
just packaged (samtools + tabix).  I wonder how I could tweak the
build process to use the Debian packaged versions in favour of the
code copies here?

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207161218.gb10...@an3as.eu

Re: Bug#736721: Incorrect dependencies

2014-02-07 Thread Jonas Borgström 
On 2014-02-07 15:08 , Julien Cristau wrote:
> On Fri, Feb  7, 2014 at 15:04:47 +0100, Jonas Borgström wrote:
> 
>> On 2014-02-07 12:12 , Jakub Wilk wrote:
>>> What attic/crypto.py currently does is:
>>>
>>> libcrypto = cdll.LoadLibrary(find_library('crypto'))
>>>
>>> But there is no guarantee that find_library('crypto') returns a library
>>> that is ABI-compatible with the Python code. For the Debian package, a
>>> quick&dirty fix is to replace the find_library() call with
>>> 'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of
>>> course means that the package would need a sourceful upload by the next
>>> OpenSSL transition.
>>
>> You're right. The "find_library('crypto')" line itself won't guarantee
>> any ABI-compatibility but a "Depends: libssl1.0.0 (>= 1.0.0)" line will.
>>
> No, because it doesn't guarantee that libssl1.1 is not installed, and
> find_library('crypto') may well pick that one instead of the expected
> libcrypto.so.1.0.0.

Ok, I see your point. How about this then:

- Use "libssl1.0.0 >= 1.0.0" as a dependency
- I change the code to only fall back on find_library('crypto') if
libcrypto.so.1.0.0 is not found in the usual place?

That way we're ready when/if libssl 1.1 is released _and_ ships with a
different ABI for the 4 libcrypto function used by Attic.

All of this will hopefully be a non-issue in a not so distant future
since I'm thinking about to replace all python extension and ctypes code
with cffi in order to support PyPy.

/ Jonas




signature.asc
Description: OpenPGP digital signature

Re: Bug#736721: Incorrect dependencies

2014-02-07 Thread Julien Cristau 
On Fri, Feb  7, 2014 at 15:04:47 +0100, Jonas Borgström wrote:

> On 2014-02-07 12:12 , Jakub Wilk wrote:
> > What attic/crypto.py currently does is:
> > 
> > libcrypto = cdll.LoadLibrary(find_library('crypto'))
> > 
> > But there is no guarantee that find_library('crypto') returns a library
> > that is ABI-compatible with the Python code. For the Debian package, a
> > quick&dirty fix is to replace the find_library() call with
> > 'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of
> > course means that the package would need a sourceful upload by the next
> > OpenSSL transition.
> 
> You're right. The "find_library('crypto')" line itself won't guarantee
> any ABI-compatibility but a "Depends: libssl1.0.0 (>= 1.0.0)" line will.
> 
No, because it doesn't guarantee that libssl1.1 is not installed, and
find_library('crypto') may well pick that one instead of the expected
libcrypto.so.1.0.0.

Cheers,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207140855.ga16...@crater1.logilab.fr

Re: Bug#736721: Incorrect dependencies

2014-02-07 Thread Jonas Borgström 
On 2014-02-07 12:12 , Jakub Wilk wrote:
> What attic/crypto.py currently does is:
> 
> libcrypto = cdll.LoadLibrary(find_library('crypto'))
> 
> But there is no guarantee that find_library('crypto') returns a library
> that is ABI-compatible with the Python code. For the Debian package, a
> quick&dirty fix is to replace the find_library() call with
> 'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of
> course means that the package would need a sourceful upload by the next
> OpenSSL transition.

You're right. The "find_library('crypto')" line itself won't guarantee
any ABI-compatibility but a "Depends: libssl1.0.0 (>= 1.0.0)" line will.

This thread started because I noticed that the package unnecessarily
listed python3-openssl as a dependency (and python3-openssl depends on
"libssl1.0.0 (>= 1.0.0)").

So I suggested to drop the middleman and replace the "Depends:
python3-openssl" line with "Depends: libssl1.0.0 (>= 1.0.0)" since the
python3-openssl code itself isn't needed, just the libssl1.0.0 dependency.

So from my point of view this somehow changed from being about a one
line change/improvement in debian/control to a discussion about python
best practices and code rewrite.

That said, Debian packages are important and I'm willing to do whatever
changes it takes to make Attic "debian compatible".

/ Jonas




signature.asc
Description: OpenPGP digital signature

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Piotr Ożarowski 
[Andreas Tille, 2014-02-07]
> On Fri, Feb 07, 2014 at 02:41:10PM +0100, Julian Taylor wrote:
> > I assume this is a python application and not a library?
> 
> It is an application including some private modules which I like to be
> compiled into *.pyc.

please install to /usr/share/package-name/ both the library and the
scripts, then symlink these scripts to /usr/bin - this way you will not
have to patch anything.

(use /usr/lib/package-name/ if it contains arch-dep. files)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207140258.gc32...@p1otr.com

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Andreas Tille 
Hi Julian,

On Fri, Feb 07, 2014 at 02:41:10PM +0100, Julian Taylor wrote:
> 
> I assume this is a python application and not a library?

It is an application including some private modules which I like to be
compiled into *.pyc.
 
> don't install into pyshared, its an implementational detail that might
> eventually go away as its technically not needed anymore since we only have
> one python2 version left.

OK.

> python applications usually get installed into /usr/lib/package-name/ as
> upstream intended
> then you just patch the entry points to add that path to their search path:

You mean something like

$ git diff
diff --git a/debian/install b/debian/install
index 84aa2e1..e6e58ca 100644
--- a/debian/install
+++ b/debian/install
@@ -1,3 +1,3 @@
 arden-*usr/bin
-core   usr/share/pyshared/arden
+core   usr/lib/arden
 doc/*  usr/share/doc/arden/html


> sys.path.insert(0, 'module-path')

Since I'm not sure whether I understand this, could you please an example
patch for one of the three applications?

> just for completeness, your approach does not work as you are missing a
> __init__.py in the folder

Ahh, Olivier has given the same hint and I can confirm that Olivier's
approach worked - but I would like to get it right in terms of Python
policy.  It might be me but I have not found the information you wrote
above in the Wiki or somewhere else.  Any hint what I should read to do
it right next time?

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207135612.gg3...@an3as.eu

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Piotr Ożarowski 
[Andreas Tille, 2014-02-07]
>/usr/share/pyshared/arden/core

/usr/share/pyshared/ (and /usr/lib/pyshared/) is implementation detail
(it will be removed once python-support is no longer used)

> and tried to patch the executable scripts to say something like
> 
> from arden.core import  AnalyseMapping as AM
> 
> instead of
> 
> from core import  AnalyseMapping as AM
> 
> 
> However, it seems I mixed things up a bit since with my approach
> 
> >>> import arden
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named arden
> 
> does not work.
> 
> Any hint what might went wrong?  (Feel free to commit directly to
> the Git repository - it is writable for every DD.)

if dh_python2 detects someone installed files directly to
/usr/share/pyshared it creates symlinks in
/usr/lib/python2.7/dist-packages but only if the later one is empty.
I'd check if your dist-package is empty and if you didn't forget to
create namespace (_init__.py file)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207134845.gb32...@p1otr.com

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Olivier Sallou 

On 02/07/2014 02:41 PM, Julian Taylor wrote:
>
>
> On Fri, Feb 7, 2014 at 2:20 PM, Andreas Tille  > wrote:
>
> Hi folks,
>
> I have commited some packaging for a bioinformatics package arden to
>
>git://anonscm.debian.org/debian-med/arden.git
> 
>
> Since it expects to find its modules under the pretty generic name
> "core" I decided to move the modules under
>
>/usr/share/pyshared/arden/core
>
> and tried to patch the executable scripts to say something like
>
>
> I assume this is a python application and not a library?
>
> don't install into pyshared, its an implementational detail that might
> eventually go away as its technically not needed anymore since we only
> have one python2 version left.
>
> python applications usually get installed into /usr/lib/package-name/
> as upstream intended
> then you just patch the entry points to add that path to their search
> path:
>
> sys.path.insert(0, 'module-path')
>
>
> just for completeness, your approach does not work as you are missing
> a __init__.py in the folder
Part of my patch  ;-)

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Julian Taylor 
On Fri, Feb 7, 2014 at 2:20 PM, Andreas Tille  wrote:

> Hi folks,
>
> I have commited some packaging for a bioinformatics package arden to
>
>git://anonscm.debian.org/debian-med/arden.git
>
> Since it expects to find its modules under the pretty generic name
> "core" I decided to move the modules under
>
>/usr/share/pyshared/arden/core
>
> and tried to patch the executable scripts to say something like
>

I assume this is a python application and not a library?

don't install into pyshared, its an implementational detail that might
eventually go away as its technically not needed anymore since we only have
one python2 version left.

python applications usually get installed into /usr/lib/package-name/ as
upstream intended
then you just patch the entry points to add that path to their search path:

sys.path.insert(0, 'module-path')


just for completeness, your approach does not work as you are missing a
__init__.py in the folder

Re: Help with packaging of python executable and its modules

2014-02-07 Thread Olivier Sallou 
I have uploaded a patch and an update to rules and control.

Seems to work now.

Olivier

On 02/07/2014 02:20 PM, Andreas Tille wrote:
> Hi folks,
>
> I have commited some packaging for a bioinformatics package arden to
>
>git://anonscm.debian.org/debian-med/arden.git
>
> Since it expects to find its modules under the pretty generic name
> "core" I decided to move the modules under
>
>/usr/share/pyshared/arden/core
>
> and tried to patch the executable scripts to say something like
>
> from arden.core import  AnalyseMapping as AM
>
> instead of
>
> from core import  AnalyseMapping as AM
>
>
> However, it seems I mixed things up a bit since with my approach
>
 import arden
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named arden
>
> does not work.
>
> Any hint what might went wrong?  (Feel free to commit directly to
> the Git repository - it is writable for every DD.)
>
> Kind regards
>
>Andreas.
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f4e238@irisa.fr

Help with packaging of python executable and its modules

2014-02-07 Thread Andreas Tille 
Hi folks,

I have commited some packaging for a bioinformatics package arden to

   git://anonscm.debian.org/debian-med/arden.git

Since it expects to find its modules under the pretty generic name
"core" I decided to move the modules under

   /usr/share/pyshared/arden/core

and tried to patch the executable scripts to say something like

from arden.core import  AnalyseMapping as AM

instead of

from core import  AnalyseMapping as AM


However, it seems I mixed things up a bit since with my approach

>>> import arden
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named arden

does not work.

Any hint what might went wrong?  (Feel free to commit directly to
the Git repository - it is writable for every DD.)

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207132037.ge3...@an3as.eu

Re: Bug#736721: Incorrect dependencies

2014-02-07 Thread Jakub Wilk 

What attic/crypto.py currently does is:

libcrypto = cdll.LoadLibrary(find_library('crypto'))

But there is no guarantee that find_library('crypto') returns a library 
that is ABI-compatible with the Python code. For the Debian package, a 
quick&dirty fix is to replace the find_library() call with 
'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of 
course means that the package would need a sourceful upload by the next 
OpenSSL transition.


* Dmitry Shachnev , 2014-02-07, 11:37:
a simplier solution will be to use existing modules like python-xattr 
and python-crypto, or writing a Python extension where you can use C 
code.


Instead of full-blow extension module, you could build a thin C wrapper 
over the interesting libcrypto functions, and then dlopen the wrapper 
instead of the shared library.


But then I notice that attic already contains some extensions modules 
written in Cython, so surely rewritting crypto.py and xattr.py in Cython 
shouldn't be a big deal? :-)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140207111203.ga7...@jwilk.net

Re: Bug#736721: Incorrect dependencies

2014-02-07 Thread Jonas Borgström 
On 2014-02-07 08:37 , Dmitry Shachnev wrote:
> Hi Clint,
> 
> See http://docs.python.org/3/library/ctypes.html for description of
> how ctypes works. As Python programs are interpreted, the only way to
> access external shared libraries from Python code is by dlopen()ing
> them. By looking at attic code, it only accesses libc (in xattr.py)
> and libcrypto (in attic/crypto.py).
> 
> Of course, this is not the best practice, a simplier solution will be
> to use existing modules like python-xattr and python-crypto, or
> writing a Python extension where you can use C code.

The original reasons why Attic doesn't use python-crypto and
python-xattr is that they did not have any working python3 support at
the time.

Attic also uses PBKDF2 to passphrase-protect key files and that
functionality has only recently been added to python-crypto. And even
now it is 11 times slower than the libcrypto version which translates
into Attic having to use 11 times fewer iterations which will make the
passphrase 11 times easier to brute force. So I rather not use
python-crypto until this improves.

python-xattr seems to have improved a lot since I last looked at it so
we might be able to switch to that if their Darwin and FreeBSD support
works as intended.

So if this indeed is a showstopper I'll look into replacing the
ctypes-bits with python extensions or cffi.

/ Jonas




signature.asc
Description: OpenPGP digital signature