Re: dh_python3 inocrrect dependancy
On 5 July 2014 03:01, Thomas Goirand z...@debian.org wrote: IMO, just: echo futures debian/py3dist-overrides will do... :) Really? That simple? :-) I assumed it wasn't valid to have a line with only one value in that file. Then again, not sure where this file is documented. Would have thought maybe the dh_python2 man page, it isn't there. -- Brian May br...@microcomaustralia.com.au
Re: dh-python wheezy backport
On 5 July 2014 02:59, Thomas Goirand z...@debian.org wrote: FYI, backporting python-django to Wheezy is very strait forward. No modification is needed. I did it here: I have found back porting most python packages to Wheezy[1] very easy. About the only real issue I have had is some packages try to build under Python 2.6 and need Python 2.7 minimum, but don't declare it, so these appear to build ok, but come up with warnings when installing/compiling them. Squeeze is another story, its Python is too old for a growing number of packages to be worth the effort. Notes: [1] Excluding pillow as discussed in other thread, and matplotlib which takes hours to build and then dies with out of disk space errors :-(. IIRC celery is the only package I have not succeeded in backporting so far. It also needs python3 packages, this in itself may be non-trivial - too many dependencies. -- Brian May br...@microcomaustralia.com.au
Re: python-django-jsonfield
On 4 July 2014 12:13, Brian May br...@microcomaustralia.com.au wrote: I tried to go back to the correct version, django-jsonfield. It doesn't appear to work properly with Python3, something that I require. It imports six, but this seems to be very much incomplete. The tests fail under Python3. If I apply the following patch, all tests pass under Python2 and Python3 without warnings under wheezy and sid. So I might just apply the patch and upload to Debian. Seems like the safest option. Shame though this won't work out of the box with the version in Pypi. Most of the changes involve tests only, so don't matter, there is one line that is for a non-test file however. -- Brian May br...@microcomaustralia.com.au fix_tests_python3 Description: Binary data
Re: pillow
On 2 July 2014 12:21, Brian May br...@microcomaustralia.com.au wrote:
Just wondered if anybody has compiled the pillow package on wheezy?
I ended up with something that appears to work, although some of the
changes included:
* Removing versions from dependencies on various things are too old in
wheezy.
* Removing _imagingtk_d.so debug library, doesn't seem to get built.
The patch for the pillow is attached.
--
Brian May br...@microcomaustralia.com.au
diff -ruN --exclude '*.bak' a/pillow-2.4.0/debian/control pillow-2.4.0/debian/control
--- a/pillow-2.4.0/debian/control 2014-06-13 21:59:46.0 +1000
+++ pillow-2.4.0/debian/control 2014-07-02 14:12:06.732951191 +1000
@@ -3,10 +3,10 @@
Priority: optional
Maintainer: Matthias Klose d...@debian.org
Build-Depends: debhelper, tk-dev, dpkg-dev (= 1.16.1~),
- python-all-dev (= 2.7.3-11~), python-all-dbg, python-setuptools,
- python3-all-dev (= 3.3.4), python3-all-dbg, python3-setuptools,
- python-tk (= 2.7.7-2), python-tk-dbg,
- python3-tk (= 3.4.1-2), python3-tk-dbg (= 3.3),
+ python-all-dev, python-all-dbg, python-setuptools,
+ python3-all-dev, python3-all-dbg, python3-setuptools,
+ python-tk, python-tk-dbg,
+ python3-tk, python3-tk-dbg,
libsane-dev, libfreetype6-dev, libjpeg8-dev, zlib1g-dev, liblcms2-dev,
libwebp-dev
Standards-Version: 3.9.5
@@ -166,7 +166,7 @@
Package: python3-pil.imagetk
Architecture: any
Depends: python3-pil (= ${binary:Version}),
- python3-tk (= 3.4.1-2),
+ python3-tk,
${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
Suggests: python-pil-doc, python3-pil.imagetk-dbg
Provides: ${python:Provides}
diff -ruN --exclude '*.bak' a/pillow-2.4.0/debian/rules pillow-2.4.0/debian/rules
--- a/pillow-2.4.0/debian/rules 2014-01-03 12:14:02.0 +1100
+++ pillow-2.4.0/debian/rules 2014-07-02 14:05:53.449484760 +1000
@@ -122,9 +122,9 @@
! -type d ! \( -name '*_d.so' -o -name '*.h' \) | xargs rm -f
find debian/python-pil*-dbg -depth -empty -exec rmdir {} \;
- dh_movefiles -ppython-pil.imagetk-dbg \
- --sourcedir=debian/python-pil-dbg \
- usr/lib/python$*/$(call py_sitename_sh, $*)/PIL/_imagingtk_d.so
+# dh_movefiles -ppython-pil.imagetk-dbg \
+# --sourcedir=debian/python-pil-dbg \
+# usr/lib/python$*/$(call py_sitename_sh, $*)/PIL/_imagingtk_d.so
# Install the compatibility modules for python2 only.
cd debian/PILcompat python$* setup.py install \
@@ -146,11 +146,13 @@
libImaging/ImDib.h \
debian/python3-pil/$$incdir
- abitag=.$$(python$* -c import sysconfig; print(sysconfig.get_config_var('SOABI')))-$(DEB_HOST_MULTIARCH); \
- dh_movefiles -ppython3-pil.imagetk \
+ abitag=.$$(python$* -c import sysconfig; print(sysconfig.get_config_var('SOABI')))*; \
+ dh_install -ppython3-pil.imagetk \
--sourcedir=debian/python3-pil \
usr/lib/python3/$(call py_sitename_sh, $*)/PIL/_imagingtk$$abitag.so \
- usr/lib/python3/$(call py_sitename_sh, $*)/PIL/ImageTk.py
+ usr/lib/python3/$(call py_sitename_sh, $*)/PIL/ImageTk.py; \
+ rm debian/python3-pil/usr/lib/python3/$(call py_sitename_sh, $*)/PIL/_imagingtk$$abitag.so; \
+ rm debian/python3-pil/usr/lib/python3/$(call py_sitename_sh, $*)/PIL/ImageTk.py
$(SET_CROSS_ENV) python$*-dbg setup.py install \
--root $(CURDIR)/debian/python3-pil-dbg \
@@ -170,10 +172,11 @@
! -type d ! \( -name '*.so' -o -name '*.h' \) | xargs rm -f
find debian/python3-pil*-dbg -depth -empty -exec rmdir {} \;
- abitag=.$$(python$*-dbg -c import sysconfig; print(sysconfig.get_config_var('SOABI')))-$(DEB_HOST_MULTIARCH); \
- dh_movefiles -ppython3-pil.imagetk-dbg \
+ abitag=.$$(python$*-dbg -c import sysconfig; print(sysconfig.get_config_var('SOABI')))*; \
+ dh_install -ppython3-pil.imagetk-dbg \
--sourcedir=debian/python3-pil-dbg \
- usr/lib/python3/$(call py_sitename_sh, $*)/PIL/_imagingtk$$abitag.so
+ usr/lib/python3/$(call py_sitename_sh, $*)/PIL/_imagingtk$$abitag.so; \
+ rm debian/python3-pil-dbg/usr/lib/python3/$(call py_sitename_sh, $*)/PIL/_imagingtk$$abitag.so
# Build architecture-independent files here.
# Pass -i to all debhelper commands in this target to reduce clutter.
python-django-jsonfield
Hello, I accidentally stuffed up and uploaded the wrong upstream. I have requested my upload be rejected for now. Compare: https://pypi.python.org/pypi/django-jsonfield/0.9.12 https://pypi.python.org/pypi/jsonfield/0.9.20 I tried to go back to the correct version, django-jsonfield. It doesn't appear to work properly with Python3, something that I require. It imports six, but this seems to be very much incomplete. The tests fail under Python3. jsonfield, on the other hand, works with Python3 out of the box. It appears to be very similar, although different feature set. It looks like both are being developed upstream, neither have had a release since last year, and while django-jsonfield now passes all Python3 tests, it still produces a lot of (easy to fix) warnings, which makes me feel that maybe jsonfield is the superior version, as it supports Python3 in PYPI already, and tests run without any problems. Can I switch to jsonfield? Or does the risk of breaking something outweigh the benefits of a Python3 package in Debian? Any other comments? Thanks -- Brian May br...@microcomaustralia.com.au
dh_python3 inocrrect dependancy
When trying to package python3-pipeline (see http://bugs.debian.org/753556), I encountered a problem with the python3 dependencies: dh_python3 -O--buildsystem=pybuild I: dh_python3 pydist:181: Cannot find installed package that provides futures. Using python3-futures as package name. Please add futures correct_package_name line to debian/py3dist-overrides to override it IF this is incorrect. That is incorrect, I think it is looking for python-concurrent.futures, which I believe is now included in Python 3. So ideally, the dependency should be dropped, it isn't needed. What is the correct solution here? Maybe something like: echo futures python3 debian/py3dist-overrides Thought I should check here before going ahead and doing the wrong thing :-) Thanks= -- Brian May br...@microcomaustralia.com.au
dh-python wheezy backport
Hello,
I copied the changes from 1.20131021-1~bpo70+1 and applied them
to 1.20140511-1 and appear to have got a working package.
http://code.vpac.org/debian/pool/main/d/dh-python/
This seems to be required to get a fully functioning backport of
python-django.
Ideally this should be uploaded to backports, however I don't entirely
understand this code, so not absolutely sure I got this correct.
Attached is the patch for version in sid.
Thanks
--
Brian May br...@microcomaustralia.com.au
diff -ruN dh-python-1.20140511.old/debian/changelog dh-python-1.20140511/debian/changelog
--- dh-python-1.20140511.old/debian/changelog 2014-05-12 04:59:48.0 +1000
+++ dh-python-1.20140511/debian/changelog 2014-07-01 10:39:20.831415999 +1000
@@ -1,3 +1,19 @@
+dh-python (1.20140511-1~bpo70+1) wheezy-backports; urgency=low
+
+ * Apply changes from 1.20131021-1~bpo70+1:
+ * Rebuild for wheezy-backports.
+ * Replace libpython3-stdlib build dependency with python3.2
+ * Update default/supported Python versions (in a fallback code,
+if python_defaults missing)
+ * Use dpkg-divert to replace python3's dh_python3 and python's
+dh_python2 and drop Breaks/Replaces
+ * dh_python2: do not rename extension files, Wheezy's python2.7 doesn't
+support multiarch tuples
+ * Disable multiarch dependencies (:any not supported that well in
+Wheezy)
+
+ -- Brian May b...@debian.org Tue, 01 Jul 2014 10:38:48 +1000
+
dh-python (1.20140511-1) unstable; urgency=medium
[ Piotr Ożarowski ]
diff -ruN dh-python-1.20140511.old/debian/control dh-python-1.20140511/debian/control
--- dh-python-1.20140511.old/debian/control 2014-01-29 04:01:31.0 +1100
+++ dh-python-1.20140511/debian/control 2014-07-01 10:37:29.961931088 +1000
@@ -3,7 +3,8 @@
Priority: optional
Maintainer: Piotr Ożarowski pi...@debian.org
Uploaders: Stefano Rivera stefa...@debian.org, Barry Warsaw ba...@debian.org
-Build-Depends: debhelper (= 9), python3-minimal, libpython3-stdlib,
+Build-Depends: debhelper (= 9), python3-minimal,
+ python3.2,
# provides rst2man command (python3-docutils not used to avoid circular deps):
python-docutils
Standards-Version: 3.9.5
@@ -15,10 +16,6 @@
Package: dh-python
Architecture: all
Depends: ${misc:Depends}, ${python3:Depends}
-Breaks:
-# due to /usr/bin/dh_python3 and debhelper files
- python3 ( 3.3.2-4~)
-Replaces: python3 ( 3.3.2-4~)
Description: Debian helper tools for packaging Python libraries and applications
This package contains:
* pybuild - invokes various build systems for requested Python versions in
diff -ruN dh-python-1.20140511.old/debian/control.orig dh-python-1.20140511/debian/control.orig
--- dh-python-1.20140511.old/debian/control.orig 1970-01-01 10:00:00.0 +1000
+++ dh-python-1.20140511/debian/control.orig 2014-01-29 04:01:31.0 +1100
@@ -0,0 +1,31 @@
+Source: dh-python
+Section: python
+Priority: optional
+Maintainer: Piotr Ożarowski pi...@debian.org
+Uploaders: Stefano Rivera stefa...@debian.org, Barry Warsaw ba...@debian.org
+Build-Depends: debhelper (= 9), python3-minimal, libpython3-stdlib,
+# provides rst2man command (python3-docutils not used to avoid circular deps):
+ python-docutils
+Standards-Version: 3.9.5
+Vcs-Git: git://anonscm.debian.org/dh-python/dh-python.git
+Vcs-Browser: http://anonscm.debian.org/gitweb/?p=dh-python/dh-python.git
+X-Python3-Version: = 3.2
+XS-Testsuite: autopkgtest
+
+Package: dh-python
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+Breaks:
+# due to /usr/bin/dh_python3 and debhelper files
+ python3 ( 3.3.2-4~)
+Replaces: python3 ( 3.3.2-4~)
+Description: Debian helper tools for packaging Python libraries and applications
+ This package contains:
+ * pybuild - invokes various build systems for requested Python versions in
+order to build modules and extensions
+ * dh_python2 - calculates Python 2.X dependencies for Debian packages,
+adds maintainer scripts to byte compile files, etc.
+ * dh_python3 - calculates Python 3.X dependencies for Debian packages,
+adds maintainer scripts to byte compile files, etc.
+ * dh_pypy - calculates PyPy dependencies for Debian packages,
+adds maintainer scripts to byte compile files, etc.
diff -ruN dh-python-1.20140511.old/debian/links dh-python-1.20140511/debian/links
--- dh-python-1.20140511.old/debian/links 2013-11-05 09:43:33.0 +1100
+++ dh-python-1.20140511/debian/links 2014-07-01 10:37:29.961931088 +1000
@@ -1,4 +1,4 @@
/usr/share/dh-python/pybuild /usr/bin/pybuild
/usr/share/dh-python/dh_pypy /usr/bin/dh_pypy
-#/usr/share/dh-python/dh_python2 /usr/bin/dh_python2
+/usr/share/dh-python/dh_python2 /usr/bin/dh_python2
/usr/share/dh-python/dh_python3 /usr/bin/dh_python3
diff -ruN dh-python-1.20140511.old/debian/manpages dh-python-1.20140511/debian/manpages
--- dh-python-1.20140511.old/debian/manpages 2013-11-05 09:43:33.0 +1100
+++ dh-python-1.20140511/debian/manpages 2014-07-01 10:37
Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)
On 28 June 2014 17:35, Thomas Goirand z...@debian.org wrote: I just saw that Brian May added some commits in the SVN to add Python3 support to it. :) Brian, what's left to do before the upload? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878 Basically everything is done, except I uploaded to DELAYED/10 - I have been told I have should have made a normal non-delayed upload, it will be delayed in NEW anyway. Not yet had a chance to fix this. If it is possible for somebody else to alter the position first, please do so. BTW, I saw that you've added some Suggests: for packages which do not exist yet in Debian (like python3-mysqldb, python3-psycopg, python3-flup, and probably some more). Should we try to add Python 3 support to these first? Are they Python 3.4 compatible? I basically copied and edited the entries for the Python2 version :-) I personally will need python3-mysqldb, python3-psycopg, and python3-flup (or equivalent). django-south will be included in Django 1.7, and as such will have Python 3 support. They have just released 1.7RC1, so it should be too much longer before 1.7 is released. -- Brian May b...@debian.org
Re: Is python-django still maintained in DPMT svn?
On 28 June 2014 17:23, Thomas Goirand z...@debian.org wrote: Is there any progress in adding Python 3 support in the Django package? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878 Also see other thread on debian-python, I just replied there. In short, yes. It'd be nice to not wait too long, because currently, without it to support Python 3, there's no other way but to add django-* packages without support for Python 3 as well, which is annoying (I'm having the issue currently with python-django-pyscss). Yes, that should be possible when this package gets in. Have had similar concerns myself. -- Brian May br...@microcomaustralia.com.au
Re: python 3 and django (was: Is python-django still maintained in DPMT svn?)
On 28 June 2014 20:43, Brian May b...@debian.org wrote: django-south will be included in Django 1.7, and as such will have Python 3 support. They have just released 1.7RC1, so it should be too much longer before 1.7 is released. Obviously I meant to say should not be too much longer. I was told that django-south should sort of work with Python 3, but probably not much point packaging a python3-django-south. http://south.aeracode.org/ticket/1210 -- Brian May b...@debian.org
Re: conflict python-captcha vs django-captcha
On 20 June 2014 23:03, Barry Warsaw ba...@debian.org wrote: python3-django-captcha +1 can-never-have-enough-python-3-ly y'rs, I woke up and realized that I can't do a python3-django-captcha just yet, without a python3-django package. Have made a start here, may try some more tomorrow, if I get time. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878 -- Brian May br...@microcomaustralia.com.au
Re: conflict python-captcha vs django-captcha
Hello, Just noticed that Olivier Sallou did a new upload of python-captcha recently, so presumably this means there is some interest in keeping python-captcha in Debian. Have CCed him in case he can offer any opinions. Thanks. On 5 May 2014 09:58, Brian May br...@microcomaustralia.com.au wrote: Hello, Debian has the following package: Package: python-captcha Source: pycaptcha Version: 0.4-1 Installed-Size: 788 Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Architecture: all Depends: python2.6 | python2.7, python (= 2.6.6-7~), python ( 2.8), python-imaging (= 1.1.5), ttf-bitstream-vera Description-en: collection of Python modules implementing CAPTCHAs This package contains Python modules to add some captcha in an application to recognize a human versus a robot. The package generates an image based on a dictionary. Homepage: http://pypi.python.org/pypi/PyCAPTCHA/0.4 Description-md5: 2d19869b66fbe12deefdf153202fb4b5 Tag: devel::lang:python, implemented-in::python, role::shared-lib Section: python Priority: optional Filename: pool/main/p/pycaptcha/python-captcha_0.4-1_all.deb Size: 385570 MD5sum: 4b080c1bb24da0ab0dff77fb2158fae0 SHA1: 06eca771b4049072dadd97fbdd6f443b0be6c405 SHA256: b85cb47d172a1070ec24e73b063933e134373c1dfcb6c61fe6f5da4d22cf65cc According to that homepage, the last release was 2006, so it appears to have been abandoned upstream. I can't find documentation for it. It provides the python module name Captcha I have a project that requires django-simple-captcha, from: https://github.com/mbi/django-simple-captcha http://readthedocs.org/docs/django-simple-captcha https://pypi.python.org/pypi/django-simple-captcha/0.4.2 It provides the python module name captcha, comes with documentation, and has recent commits. Technically speaking, the module names don't conflict, this is only because of the case of the first character is different, which IMHO isn't sufficient. Also policy would require me to package django-simple-captcha as python-captcha, which would clash. I filed an ITP for django-simple-captcha before I realized the clash: http://bugs.debian.org/746632 I considered porting my application to use python-captcha, however as that appears to be the inferior library, don't think I want to do that. What is the solution? I can think of: * Get upstream to rename django-simple-captcha. Very hard to justify when development of the conflicting package is dead. * Remove python-captcha from Debian. Nothing appears to depend on it in the Debian archive. Any thoughts? Thanks -- Brian May br...@microcomaustralia.com.au -- Brian May br...@microcomaustralia.com.au
Re: conflict python-captcha vs django-captcha
On 20 June 2014 11:48, Scott Kitterman deb...@kitterman.com wrote: This isn't necessarily fatal. See python-dnspython (provides the dns module) and python-dns (provides the DNS module). Sine python-captcha is already used, I'd recommend picking an alternate name for your package. Since python module names are case sensitive, this thing can happen and we shouldn't preclude the two different modules being in Debian. My latest thought is maybe I should rename to: python-django-captcha and create: python3-django-captcha -- Brian May br...@microcomaustralia.com.au
Re: conflict python-captcha vs django-captcha
On 6 May 2014 03:49, Christophe Siraut d...@tobald.eu.org wrote: In this case we can probably name the source django-simple-captcha even if the policy states it should be python-captcha. Note I have seen django modules were source and package name are the same [1], it is not clear to me what the best naming scheme is. So would it be acceptable to have two packages in Debian: python-captcha provides Captcha module django-simple-captcha provides captcha module Should I go ahead anyway and upload django-simple-captcha to Debian and see if anyone opens a bug report? Thanks -- Brian May br...@microcomaustralia.com.au
Re: conflict python-captcha vs django-captcha
On 6 May 2014 03:49, Christophe Siraut d...@tobald.eu.org wrote: In this case we can probably name the source django-simple-captcha even if the policy states it should be python-captcha. Note I have seen django modules were source and package name are the same [1], it is not clear to me what the best naming scheme is. This package supports Python 3. What should I call the python3 package? -- Brian May br...@microcomaustralia.com.au
Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client
Package: wnpp Severity: wishlist Owner: Brian May b...@debian.org * Package name: python-ldap3 Version : 0.9.3.3 Upstream Author : Giovanni Cannata python3l...@gmail.com * 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-python-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
conflict python-captcha vs django-captcha
Hello, Debian has the following package: Package: python-captcha Source: pycaptcha Version: 0.4-1 Installed-Size: 788 Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Architecture: all Depends: python2.6 | python2.7, python (= 2.6.6-7~), python ( 2.8), python-imaging (= 1.1.5), ttf-bitstream-vera Description-en: collection of Python modules implementing CAPTCHAs This package contains Python modules to add some captcha in an application to recognize a human versus a robot. The package generates an image based on a dictionary. Homepage: http://pypi.python.org/pypi/PyCAPTCHA/0.4 Description-md5: 2d19869b66fbe12deefdf153202fb4b5 Tag: devel::lang:python, implemented-in::python, role::shared-lib Section: python Priority: optional Filename: pool/main/p/pycaptcha/python-captcha_0.4-1_all.deb Size: 385570 MD5sum: 4b080c1bb24da0ab0dff77fb2158fae0 SHA1: 06eca771b4049072dadd97fbdd6f443b0be6c405 SHA256: b85cb47d172a1070ec24e73b063933e134373c1dfcb6c61fe6f5da4d22cf65cc According to that homepage, the last release was 2006, so it appears to have been abandoned upstream. I can't find documentation for it. It provides the python module name Captcha I have a project that requires django-simple-captcha, from: https://github.com/mbi/django-simple-captcha http://readthedocs.org/docs/django-simple-captcha https://pypi.python.org/pypi/django-simple-captcha/0.4.2 It provides the python module name captcha, comes with documentation, and has recent commits. Technically speaking, the module names don't conflict, this is only because of the case of the first character is different, which IMHO isn't sufficient. Also policy would require me to package django-simple-captcha as python-captcha, which would clash. I filed an ITP for django-simple-captcha before I realized the clash: http://bugs.debian.org/746632 I considered porting my application to use python-captcha, however as that appears to be the inferior library, don't think I want to do that. What is the solution? I can think of: * Get upstream to rename django-simple-captcha. Very hard to justify when development of the conflicting package is dead. * Remove python-captcha from Debian. Nothing appears to depend on it in the Debian archive. Any thoughts? Thanks -- Brian May br...@microcomaustralia.com.au
dh_auto_* and Makefile
Hello, In a particular project (django-model-utils 2.0.3 to be precise), if I have a debian/rules file containing: %: dh $@ --with python2 Then dh_auto_* tools determine that the project comes with a Makefile (upstream file), and uses that instead of setup.py How can I force it to use setup.py? I have tried providing override_dh_auto_*, but then I hard coded the python version to use. Or should I create a patch in debian/patches that removes the Makefile? This seems to be the simplest solution, but want to make sure it sounds reasonable. Thanks -- Brian May br...@microcomaustralia.com.au
building python debian packages and virtualenv
Hello, Several times I have made the mistake of building a Debian package while a virtualenv is active. This results in the paths being incorrect in the Debian package. Sometimes the package build will fail as a result, this depends on the package. Fortunately, so far I have always noticed this before uploading the package, however think it is only a matter of time before I stuff up an upload. Just wondering if it would be considered appropriate to have, say, dh_auto_build fail if it is about to call setup.py and it is inside a virtualenv. Just a thought. Thanks. -- Brian May br...@microcomaustralia.com.au
Re: dh_auto_* and Makefile
On 2 May 2014 11:14, Christian Kastner deb...@kvr.at wrote: %: dh $@ --with python2 --buildsystem=python_distutils See also section BUILD SYSTEM OPTIONS of debhelper(7). Just what I wanted. Thanks. I did see this in the debhelper(7) man page, but got confused when it wasn't mentioned in the dh_auto_install man page, and I wasn't sure what value to use. -- Brian May br...@microcomaustralia.com.au
Re: pbs python
On 31 March 2014 20:03, Piotr Ożarowski pi...@debian.org wrote: (I think this might have been renamed recently to python-sh, but can't find the reference right now) Here is the reference: https://pypi.python.org/pypi/pbs/0.110 Maybe we should be removing the existing python-pbs from Debian? It looks like it isn't supported any more... it shouldn't be a problem (pbs != bps) Oops. No wonder I couldn't find the above page :-) -- Brian May br...@microcomaustralia.com.au
Re: pbs python
On 31 March 2014 18:54, Jelmer Vernooij jel...@samba.org wrote: Note that Brian is also a DD and maintainer of various packages. He should be aware of the process. :) http://qa.debian.org/developer.php?login=bam Need to think about it if is worth while for Debian as a whole. I am starting to get an accumulation of Packages that in my private repository, some of these perhaps should get pushed to Debian. http://code.vpac.org/debian/dists/sid/main/binary-amd64/Packages Generally, there are three categories: * Packages that are not in Debian, but I need. * Packages that are too old (and in some cases completely broken) in Debian (e.g. django-celery). * Packages that are buggy in Debian, and are unusable without patching (e.g. django-south). Getting back on track, I have an old version of pbs_python (using the non-debian complaint name used by upstream debian/control file), , however was looking at the latest version. It isn't a high priority. In fact, I am not even sure how to test it. I have inherited django-pbs, which requires it. http://code.vpac.org/debian/pool/main/p/pbs-python/ Unfortunately, pbs_python seems to be rather ... creative ... in its packaging techniques. eg. autoconf builds Makefile and setup.py from Makefile.in and setup.py.in, and the Makefile calls setup.py. My initial attempts at creating a Debian package result in errors from the Makefile (looks like it is trying to install the LICENSE.openpbs file in /). My limited understanding is that python packages are suppose to be distributed with a setup.py, not a setup.py.in. -- Brian May br...@microcomaustralia.com.au
pbs python
Hello, *If* I wanted to get the following package into Debian: https://oss.trac.surfsara.nl/pbs_python What should I do? It seems to clash with a package of the same name (when labelled according to policy anyway) that is very different: https://packages.debian.org/sid/python-pbs (I think this might have been renamed recently to python-sh, but can't find the reference right now) If that is not bad enough, looks like there is another python-bps too: https://gitorious.org/python-blip https://pypi.python.org/pypi/python-bps Thanks -- Brian May br...@microcomaustralia.com.au
Re: python-future: clean single-source support for Python 2/3
On 5 February 2014 19:05, Thomas Goirand z...@debian.org wrote: Just a quick message to say sorry for being the source of this big confusion between future and futures (with s). Not a problem. It is rather confusing situation - having a module renamed from futures to concurrent.futures that contains a Future class, and having another future module that isn't remotely related. At least now we know it is something to watch out for. -- Brian May br...@microcomaustralia.com.au
python-future: clean single-source support for Python 2/3
Hello, Has anybody considered packaging python-future for Debian? No, I am not talking about python-futures, python-concurrency.futures, or anything relating to #736523 (the first message in this bug had rather confused at first). Rather I am talking about: http://python-future.org/ future is the missing compatibility layer between Python 2 and Python 3. It allows you to use a single, clean Python 3.x-compatible codebase to support both Python 2 and Python 3 with minimal overhead. Unfortunately, Google now lists #736523 as the major search result, so I thought I would ask here to see if there is any interest. Thanks -- Brian May br...@microcomaustralia.com.au
svn error
Hello, My svn is rusty, how do I resolve the following error? # svn-buildpackage --svn-tag-only Complete layout information: buildArea=/home/brian/tree/debian/build-area origDir=/home/brian/tree/debian/tarballs trunkDir=/home/brian/tree/debian/django-ajax-selects trunkUrl=svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/trunk Starting ssh connection.. W: tagsUrl not specified anywhere, looking in the local repository... Looking in SVN for: Repository lookup, probing 'svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags' ... Repository lookup, probing 'svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1' ... Tagging django-ajax-selects (1.3.3-1) svn -m [svn-buildpackage] Tagging django-ajax-selects 1.3.3-1 cp . svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1 svn: Commit failed (details follow): svn: '/packages/django-ajax-selects/tags/1.3.3-1/debian/patches/update_urls' is out of date Command ' svn -m [svn-buildpackage] Tagging django-ajax-selects 1.3.3-1 cp . svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1' failed in '/home/brian/tree/debian/django-ajax-selects', how to continue now? [Qri?]: debian/patches/update_urls is a file that was deleted in this version. Also feel free to consider this a request to move to git :-) Thanks -- Brian May br...@microcomaustralia.com.au
Re: python-django build weirdness
On 24 September 2013 15:40, Chow Loong Jin hyper...@debian.org wrote: grepping for johndoe shows one match in tests/regressiontests/utils/simplelazyobject.py, where the test case creates a johndoe user. I suspect the error comes from using unittest.TestCase instead of django.test.TestCase. The latter does some cleanup and reinitialization after each testcase, which is necessary, but isn't happening here. Fixing the import line should do the trick. Guess I should file a bug report against python-django then... -- Brian May br...@microcomaustralia.com.au
python-django build weirdness
Hello, From a wheezy box, I am running the following commands: dget http://ftp.de.debian.org/debian/pool/main/p/python-django/python-django_1.5.4-1.dsc cd python-django-1.5.4 dpkg-buildpackage -rfakeroot -sa 21 | tee $logfile For different values of $logfile. If I run this from my home directory, it works. Every time. If I run this instead from /tmp/brian/tmp.rJDf6JJXaz - it fails. It always fails at exactly the same point. == FAIL: test_instance_is_maintained (django.contrib.formtools.tests.wizard.wizardtests.tests.WizardFormKwargsOverrideTests) -- Traceback (most recent call last): File /tmp/brian/tmp.rJDf6JJXaz/python-django-1.5.4/django/contrib/formtools/tests/wizard/wizardtests/tests.py, line 375, in test_instance_is_maintained self.assertEqual(2, User.objects.count()) AssertionError: 2 != 3 -- Ran 5009 tests in 463.080s FAILED (failures=1, skipped=126, expected failures=5) I get identical results building using a clean, wheezy, schroot. However chose not to use my schroot setup here as it is simpler. Curiously the order of copying/creating files and the tests is different for both cases too (according to diff of the log). If I rerun the test on the same file system, I get identical results. My theory is the different ordering of the tests is causing the failure. So I thought maybe some sort of filesystem specific bug, maybe due to different iteration order of files or something. This doesn't make sense though, as I would expect different results every time. Also both filesystems are ext4, on LVM, using the same LVM VG, from the same source disk. /dev/mapper/aquitard-debian on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) /dev/mapper/aquitard-home on /home type ext4 (rw,relatime,data=ordered) Both filesystems have plenty of space: /dev/mapper/aquitard-debian19G 17G 1.2G 94% / /dev/mapper/aquitard-home 19G 14G 4.1G 77% /home Yes, /tmp is in /, it doesn't have a separate filesystem. I considered the possibility that the build looks for /tmp and does something different (however dodgy that might be), however it looks like /aaa has the same issues as /tmp. Any ideas? Still doing some more tests, however this is just plain weird. Will try rebooting my system in case of some weird kernel issue (currently running 3.10-0.bpo.2-amd64). Also, I didn't have any problems with python-django version 1.5.1-2 -- Brian May br...@microcomaustralia.com.au
Re: python-django build weirdness
On 24 September 2013 13:16, Chow Loong Jin hyper...@debian.org wrote: Why don't you catch the AssertionError at this point and check what the extra User object is? [User: johndoe, User: test1, User: test2] I just tried it on the same path as you used, but it worked for me. My /tmp is on tmpfs though. Not surprised... -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
On 1 August 2013 22:25, Jakub Wilk jw...@debian.org wrote: Really? I thought it was based on the package name. So I guess this means I got my other package, already uploaded to Debian, wrong: python-django-filter instead of python-django-filters :-(. .oO( http://lists.debian.org/**20130608225655.GA5961@jwilk.**nethttp://lists.debian.org/20130608225655.ga5...@jwilk.net) Yes, I responded to that with a question: http://lists.debian.org/debian-python/2013/06/msg00061.html Unfortunately nobody answered.
Re: django-ajax-selects
On 1 August 2013 15:09, Brian May br...@microcomaustralia.com.au wrote: 1. My python-ajax-select contains ./usr/share/pyshared/ajax_select/LICENSE.txt despite my debian/debian/python-ajax-select.pyremove file. W: python-ajax-select: extra-license-file usr/share/pyshared/ajax_select/LICENSE.txt Oh, I see, on wheezy, it looks like debian/$package.pyremove will let me remove: debian/python-ajax-select/usr/lib/python2.6/dist-packages/ajax_select/LICENSE.txt debian/python-ajax-select/usr/lib/python2.7/dist-packages/ajax_select/LICENSE.txt However it won't let me remove the source file: /usr/share/pyshared/ajax_select/LICENSE.txt As controlled in pyremove(), which is in /usr/share/python/debpython/tools.py How do I fix this? I was told on this mailing list that I shouldn't be hard coding /usr/share/pyshared/ in debian/rules. Or should I just ignore the lintian warning for now? 2. My django-ajax-selects somehow gets an empty directory: I: django-ajax-selects: package-contains-empty-directory usr/share/pyshared/ajax_select/templates/ Some how I managed to repeatedly miss the debian/django-ajax-selects.dir that created this directory. Oops. -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
On 30 July 2013 15:52, Scott Kitterman deb...@kitterman.com wrote: The package name is incorrect. Per the python policy, the binary name should be python-ajax-select. That's the module name. Ok, fixed that now. Just got two issues that I can see now: 1. My python-ajax-select contains ./usr/share/pyshared/ajax_select/LICENSE.txt despite my debian/debian/python-ajax-select.pyremove file. W: python-ajax-select: extra-license-file usr/share/pyshared/ajax_select/LICENSE.txt 2. My django-ajax-selects somehow gets an empty directory: I: django-ajax-selects: package-contains-empty-directory usr/share/pyshared/ajax_select/templates/ Can anyone see what I am doing wrong? Thanks -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
On 30 July 2013 15:52, Scott Kitterman deb...@kitterman.com wrote: The package name is incorrect. Per the python policy, the binary name should be python-ajax-select. That's the module name. Really? I thought it was based on the package name. So I guess this means I got my other package, already uploaded to Debian, wrong: python-django-filter instead of python-django-filters :-(. Oh wait, I see it now in the policy. I had to reread it several times. The binary package for module foo should preferably be named python-foo, if the module name allows, but this is not required if the binary package ships multiple modules. In the latter case the maintainer chooses the name of the module which represents the package the most. However the word preferably suggests this is optional. -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
x: python-django-ajax-selects: incorrect-package-name python-ajax-select I don't know where it is getting the python-ajax-select name from. If I don't get any responses here, I will assume my package is fine. -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
On 30 July 2013 11:15, Scott Kitterman deb...@kitterman.com wrote: Where is the package? The source is on subversion: svn+ssh:// svn.debian.org/svn/python-modules/packages/django-ajax-selects/trunk http://anonscm.debian.org/viewvc/python-modules/packages/django-ajax-selects/trunk/ I haven't uploaded the binary packages themselves anywhere yet. The old packages (including current orig.tar.gz) are still in Debian/unstable. -- Brian May br...@microcomaustralia.com.au
django-ajax-selects
Hello, Could I please get somebody to check the new version of my package before I upload to Debian? svn+ssh:// svn.debian.org/svn/python-modules/packages/django-ajax-selects/trunk http://anonscm.debian.org/viewvc/python-modules/packages/django-ajax-selects/trunk/ orig.tar.gz from Debian archive. Thanks -- Brian May br...@microcomaustralia.com.au
Re: django-ajax-selects
On 29 July 2013 03:42, Jakub Wilk jw...@debian.org wrote: The changelog reads: * Replace debian/pycompat with X-Python-Version. This suggest that d/pycompat and XPV that the same (or similar) purpose. But this is not the case. I would rewrite it as: * Drop debian/pycompat. * Add X-Python-Version. lintian4python emits: w: django-ajax-selects source: missing-vcs-field vcs-svn svn:// anonscm.debian.org/**python-modules/packages/**django-ajax-selects/trunk/http://anonscm.debian.org/python-modules/packages/django-ajax-selects/trunk/ w: django-ajax-selects source: missing-vcs-field vcs-browser http://anonscm.debian.org/**viewvc/python-modules/** packages/django-ajax-selects/**trunk/http://anonscm.debian.org/viewvc/python-modules/packages/django-ajax-selects/trunk/ Ok, will fix these issues. Thanks. x: python-django-ajax-selects: incorrect-package-name python-ajax-select What is the problem here? -- Brian May br...@microcomaustralia.com.au
Re: PEP 394 and shebang lines for /usr/bin/python2 scripts
On 25 July 2013 07:52, Piotr Ożarowski pi...@debian.org wrote: When my co-worker (who doesn't use Debian on his desktop/laptop machines) asked me if Debian will change the /usr/bin/python symlink anytime soon and I told him over my (or python2.X's) dead body, he responded with: that's why I use Debian on all my servers - it's STABLE! I don't have to worry about crap like this I would have thought that is exactly the reason why we should start planning this early. Rather then at the last minute. If we plan this early, we don't need to go through and change everything at once, rather we can do it happens to be convenient. We have already done this with shell scripts that have bashisms - we now say that they should have #!/bin/bash, not #!/bin/sh. We did this a long time before we considered officially changing the /bin/sh symlink. I don't see why python should be any different. As for supporting older Debian releases. Fair point. However all you need is to type: ln -s /usr/bin/python /usr/bin/python2 Sometimes I worry that Debian is becoming to conservative.
Re: Joining Python Modules Packaging Team
On 9 June 2013 08:56, Jakub Wilk jw...@debian.org wrote: python-django-tables2 python-django-filters python-ajax-select Out of curiosity, why python-ajax-select and not, python-django-ajax-select? -- Brian May br...@microcomaustralia.com.au
django-tables package
Hello, Can I please get somebody to review my django-tables package before I upload to Debian? I copied the updates from my django-filter package. Code is at http://anonscm.debian.org/viewvc/python-modules/packages/django-tables/trunk/debian/ using: http://ftp.de.debian.org/debian/pool/main/d/django-tables/django-tables_0.13.0.orig.tar.gz As far as I can tell it should be OK to me, although a bit nervous about the following build messages from Sphinx: loading intersphinx inventory from http://docs.python.org/dev/objects.inv... loading intersphinx inventory from http://docs.djangoproject.com/en/dev/_objects/... Seems to suggest that it is getting files from external locations during the build. If this is a problem, how do I fix it? Thanks -- Brian May br...@microcomaustralia.com.au
Re: django-tables package
On 19 June 2013 14:33, Scott Kitterman deb...@kitterman.com wrote: Patch to use the installed copy. I had to do this once before. How do I do this? I don't see any references to objects.inv in the upstream source code for django-filter, and I am not really sure what these files are used for. -- Brian May br...@microcomaustralia.com.au
Re: Joining Python Modules Packaging Team
On 9 June 2013 08:56, Jakub Wilk jw...@debian.org wrote: Speaking of which, django-ajax-selects debian/rules does this: cp -r ajax_select/static debian/django-ajax-selects/** usr/share/pyshared/ajax_select /usr/share/pyshared is an implementation detail of Python helpers; you should not rely on its existence. (In fact, now that we support only one Python version, I hope we get rid of it soon.) Hmm. Looks like I don't need that line any more anyway, these files get appear to be installed automatically, presumably by dh_python2 (as they belong in the same directory as the python code). -- Brian May br...@microcomaustralia.com.au
Joining Python Modules Packaging Team
Hello, It has been suggested that I join the Python Modules Packaging Team. I currently am the maintainer of the following packages: django-tables django-filters django-ajax-selects Plus a number of other packages that are not yet available in Debian. My Alioth login is bam. (Yes, I have been told that those package names should be prefixed with python- to be policy compliant - just one of the things that needs fixing) Thanks -- Brian May br...@microcomaustralia.com.au
Re: karaage
Next question: deployment. Django applications come with a number of options to deploy under a webserver. My preferred in fastcgi, but this obviously isn't going to suit Debian, due to the non-freeness of fastcgi. Should I have this application auto-configure itself to use a webserver? If so what method should I use? Or should I leave that to the sysadmin to configure? Note: I personally consider it a sysadmin task to configure the database used, so it won't work out of the box. Thanks Please CC me, I am not subscribed. -- Brian May br...@microcomaustralia.com.au -- 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/aanlktilreeq0f0tq6nrb81rceju6a33sanbbz39iz...@mail.gmail.com
Re: karaage
On 16 July 2010 17:58, Toni Mueller t...@debian.org wrote: I'd guess that this translates to your Django app in the following way: settings.py becomes eg. execfile(/etc/karaage/settings.py) Thanks! This seems a really good answer. Furthermore, looks like I should be able to do setup default variables first, and have the settings.py inspect/modify these values, e.g.: INSTALLED_APPS = ( ... stuff here ... ) execfile(/etc/karaage/settings.py) ... and in /etc/karaage/settings.py ... INSTALLED_APPS += ( ... local apps required ...) Which is a much better solution for this problem then trying to use import everywhere (as i was). It is the weekend here now, will try it for sure next Monday. -- Brian May br...@microcomaustralia.com.au -- 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/aanlktiljdueh5otqk4v0gliwvwr4q6zovjnipiybl...@mail.gmail.com
karaage
Hello All, As part of my paid Job I am working on Karrage, and open source Django based application application for management of users and resources on shared cluster systems. http://code.vpac.org/trac/karaage As this is an open source GPL program (yes, management have already agreed to this), long term I would like to see this included in Debian. Short term however, there are a number of technical issues that need resolving. For example, dependencies on external libraries that are not yet in Debian. On issue that has been nagging us - what is the best way to handle python based config files? e.g. the settings.py file that is standard for Django applications? At present our (planned but not implemented) approach is to have our python dist-utils script create a directory karaage/conf under the python path, and then karaage can import then using import karaage.conf.settings for example. Use of dist-utils and cdbs makes the debian/rules file very simple. However, from the point of view of the package, it would be better if we could put the config files under /etc/karaage. Just wondering if this situation has been encountered before? If so, would rather use an existing solution rather then invent my own. Ideally any solution should be similar to what you would get by installing directly from source and RPMs too. Also: Is there any Debian specific concerns I should be aware of when packaging Django applications? Please CC me, I am not subscribed (not yet anyway). Thanks. -- Brian May br...@microcomaustralia.com.au -- 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/aanlktinfswwqq0vxpeskclnuitkrfzkuiucp_eeur...@mail.gmail.com
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Adeodato Hm. I'd say that you have .pyc files left in: Adeodato Adeodato /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools Adeodato Can you check, please? Yes, see below. Adeodate Also, do you remember having root Adeodato bzr as root? Huh? Adeodato bzrtools 0.9 does not put files under Adeodato /usr/lib/python2.4, since it uses python-support; and Adeodato its maintainer scripts for 0.9 did not bytecompile the Adeodato modules, so the most plausible explanation for .pyc Adeodato files in /usr/lib/python2.4 is having run bzr 0.8 as Adeodato root. Adeodato To debian-python: this is presumably a bug in bzrtools? [EMAIL PROTECTED]:~$ ls -l /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools total 288 -rw-r--r-- 1 root root 31767 2006-07-16 18:58 baz_import.py.bak -rw-r--r-- 1 root root 29959 2006-08-12 12:08 baz_import.pyc -rw-r--r-- 1 root root 830 2006-08-12 12:08 branches.pyc -rw-r--r-- 1 root root 2198 2006-08-12 12:08 branchhistory.pyc -rw-r--r-- 1 root root 4167 2006-08-12 12:08 branch_mark.pyc -rw-r--r-- 1 root root 13906 2006-08-12 12:08 bzrtools.pyc -rw-r--r-- 1 root root 1232 2006-08-12 12:08 cbranch.pyc -rw-r--r-- 1 root root 4167 2006-08-12 12:08 clean_tree.pyc -rw-r--r-- 1 root root 8687 2006-08-12 12:08 dotgraph.pyc -rw-r--r-- 1 root root 1637 2006-08-12 12:08 errors.pyc -rw-r--r-- 1 root root 4235 2006-08-12 12:08 fai.pyc -rw-r--r-- 1 root root 2275 2006-08-12 12:08 fetch_ghosts.pyc -rw-r--r-- 1 root root 8827 2006-08-12 12:08 graph.pyc -rw-r--r-- 1 root root 5466 2006-08-12 12:08 hunk_selector.pyc -rw-r--r-- 1 root root 16502 2006-07-16 18:52 __init__.py.bak -rw-r--r-- 1 root root 18867 2006-08-12 12:08 __init__.pyc -rw-r--r-- 1 root root 20311 2006-08-12 12:08 patches.pyc -rw-r--r-- 1 root root 7321 2006-08-12 12:08 patch.pyc -rw-r--r-- 1 root root 2573 2006-08-12 12:08 patchsource.pyc -rw-r--r-- 1 root root 1460 2006-08-12 12:08 progress.pyc -rw-r--r-- 1 root root 1545 2006-08-12 12:08 rspush.pyc -rw-r--r-- 1 root root 626 2006-08-12 12:08 setup.pyc -rw-r--r-- 1 root root 9907 2006-08-12 12:08 shelf.pyc -rw-r--r-- 1 root root 10210 2006-08-12 12:08 shell.pyc -rw-r--r-- 1 root root 3846 2006-08-12 12:08 switch.pyc -rw-r--r-- 1 root root 1822 2006-08-12 12:08 terminal.pyc -rw-r--r-- 1 root root 1367 2006-08-12 12:08 test.pyc -rw-r--r-- 1 root root 5083 2006-08-12 12:08 userinteractor.pyc -rw-r--r-- 1 root root 3674 2006-08-12 12:08 zap.pyc [EMAIL PROTECTED]:~$ dpkg -S /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools bzrtools: /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools [EMAIL PROTECTED]:~$ dpkg -L bzrtools /. /usr /usr/lib /usr/lib/python2.4 /usr/lib/python2.4/site-packages /usr/lib/python2.4/site-packages/bzrlib /usr/lib/python2.4/site-packages/bzrlib/plugins /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools /usr/share [...] Not sure what those *.bak files are, but I suspect that was some hackish debugging I did for a previous problem. I would speculate that upgrading the package didn't result in the compiled files being deleted. [EMAIL PROTECTED]:~$ dpkg -l bzrtools Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii bzrtools 0.9.0-1 Collection of tools for bzr -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Adeodato Sorry, that should have read: do you remember having Adeodato *run* bzr as root. It's the most likely cause for Adeodato those .pyc files to be there, since bzrtools did not. No - I don't recall running bzr as root, nor have I had any reason to do so. This doesn't mean I didn't do it accidently, but I don't think so. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
