X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++---========
ii bzrtools 0.9.0-1 Collection of
tools for bzr
--
Br
y 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]
yet anyway).
Thanks.
--
Brian May
--
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
ch 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
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
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
--
To UNSUBSCRIBE, email to debian-p
ectly.
Please CC responses to me.
Thanks
--
Brian May
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
same directory as the python code).
--
Brian May
On 9 June 2013 08:56, Jakub Wilk 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
://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
On 19 June 2013 14:33, Scott Kitterman 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
On 25 July 2013 07:52, Piotr Ożarowski 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
archive.
Thanks
--
Brian May
python-django-ajax-selects: incorrect-package-name python-ajax-select
What is the problem here?
--
Brian May
>
> 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
ploaded the binary packages themselves anywhere yet. The old
packages (including current orig.tar.gz) are still in Debian/unstable.
--
Brian May
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
tory
usr/share/pyshared/ajax_select/templates/
Can anyone see what I am doing wrong?
Thanks
--
Brian May
On 1 August 2013 22:25, Jakub Wilk 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
On 1 August 2013 15:09, Brian May 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.tx
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
On 24 September 2013 13:16, Chow Loong Jin wrote:
> Why don't you catch the AssertionError at this point and check what the
> extra
> User object is?
>
[, , ]
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
.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
On 25 September 2013 15:14, Brian May wrote:
> Guess I should file a bug report against python-django then...
>
Submitted as #724637
--
Brian May
h://
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
ere to see if there is any interest.
Thanks
--
Brian May
res 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
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
hon-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
ng is that
python packages are suppose to be distributed with a setup.py, not a
setup.py.in.
--
Brian May
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
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
't mentioned in the dh_auto_install man page, and I wasn't sure what
value to use.
--
Brian May
k to
resolve release critical bugs like this.
Alternatively, django-pipeline could be modified to conflict with
python-pipeline. This would allow closing the grave bug report, but seems
wrong.
Notes:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620067
--
Brian May
n? 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
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
hat 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
hat the best naming scheme is.
>
This package supports Python 3. What should I call the python3 package?
--
Brian May
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 wrote:
> Hello,
>
> Debia
ince
> 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
ry some more tomorrow, if I get time.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736878
--
Brian May
On 28 June 2014 17:35, Thomas Goirand 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 everythi
en this package gets in. Have had similar
concerns myself.
--
Brian May
On 28 June 2014 20:43, Brian May 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&q
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
diff -ruN dh-python-1.20140511.old/debian/changelog dh-python-1.20140511/debian/changelog
--- dh-python-1.20140511.old/d
Hello,
Just wondered if anybody has compiled the pillow package on wheezy?
It would save me from reinventing the wheel :-)
Thanks
--
Brian May
d.
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
On 2 July 2014 12:21, Brian May 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.
* Re
PI
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
file is documented. Would have thought
maybe the dh_python2 man page, it isn't there.
--
Brian May
ding 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
On 4 July 2014 12:13, Brian May 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
>
On 28 June 2014 20:43, Brian May wrote:
> I personally will need python3-mysqldb, python3-psycopg, and python3-flup
> (or equivalent).
>
python3-psycopg: was replaced with python3-psycopg2, packages are
available in wheezy and sid already. Have updated svn not to refer to the
psycopg
On 5 July 2014 11:28, Brian May wrote:
> 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
nf.settings --noinput
Can change it for new packages, not for old packages though. I don't see
any good solution for this though.
Hopefully nobody else does this :-)
--
Brian May
headers to suggest these
instead of mysqldb, as mysqldb development appears to be dead.
As far as I can tell this should be supported in Django 1.6 (assuming I am
reading a particular line in the documentation correctly).
--
Brian May
On 7 Jul 2014 13:42, "Brian May" wrote:
> Which is already in unstable:
>
> python-mysql.connector
> python3-mysql.connector
Might have to try and get these updated in Debian.
http://bugs.mysql.com/bug.php?id=71806
Means Django depreciated warnings become fatal err
On 7 Jul 2014 13:42, "Brian May" wrote:
> Which is already in unstable:
>
> python-mysql.connector
> python3-mysql.connector
Also see https://groups.google.com/forum/m/#!topic/south-users/hrxwgimaYy8
By default south doesn't work with mysql connector.
Fortunately
hon3-pika but it is not
installable
etc.
(python3-botocore exists - can this be used instead of python3-boto?)
It would be good if we could get this done by the next freeze, however,
looks like a lot of packages, and I am not familiar with any of them.
Thanks
--
Brian May
See attached patch file.
--
Brian May
Index: debian/control
===
--- debian/control (revision 29742)
+++ debian/control (working copy)
@@ -2,30 +2,24 @@
Section: python
Priority: optional
Maintainer: Debian Python Modules
uld be only a matter of time before
I get totally confused and edit the wrong one)
Anyone got any better ideas?
Thanks
--
Brian May
lution so far.
If the user upgrades to Apache2.4, they will have to manually fix up the
configuration. Which may be as simple as "a2enconf someconf-2.4" (assuming
the new Apache config installs without conflicts). Plus, optionally, delete
the /etc/apache2/conf.d
--
Brian May
On 7 July 2014 11:55, Brian May wrote:
> The problem is that the django-admin wrapper chose the python3 version,
> but karaage.tests.settings is only available in Python2, even though I have
> python3-django installed.
>
See bugs #755341 and #755321.
Looks like code is trying t
On 20 July 2014 11:12, Brian May wrote:
> See bugs #755341 and #755321.
>
> Looks like code is trying to run django-admin as a python script, allows
> it to specify which version of python to use.
>
> Only thing is, it isn't Python. It is now shell. This allows automa
depends on the Django app installed. As well as
maintain compatibility with existing packages.
So the first approach seems to appropriate one here.
--
Brian May
release critical.
"grave:
makes the package in question unusable or mostly so, or causes data loss,
or introduces a security hole allowing access to the accounts of users who
use the package"
--
Brian May
As far as I can tell, all of these "marked for autoremovals" occured
because kombu had a build dependancy on python-librabbitmq, which I have
changed to python-amqp, and uploaded to Debian.
--
Brian May
--- Begin Message ---
kombu 3.0.19-1 is marked for autoremoval from testing on 2014
Hello,
Thanks for you work. I very much agree, would really like to see Django 1.7
in Jessie, even if it does break some things along the way.
Something seems to have gone wrong with your package.
Both python-django and python3-django include
/usr/bin/django-admin
...and as a result conflict.
On 23 July 2014 10:27, Brian May wrote:
> Something seems to have gone wrong with your package.
>
Looks like you already fixed it in -2.
I have back ported this to wheezy.
In case anybody wants to use it, and actually trusts me (why would anybody
trust me?), you can use at by addi
isting migrations directory to south_migrations,
and setting SOUTH_MIGRATION_MODULES.
Which is unfortunate, it means the decision has to be made in the library,
but the SOUTH_MIGRATION_MODULES has to be set in the application.
--
Brian May
On 23 July 2014 12:54, Brian May wrote:
> I think django-south still works with Django 1.7 (), but is considered
> depreciated compared with the Django 1.7 built in migrations.
>
I was wrong. django-south will not work with 1.7, and quite possibly never
will work with Django 1.7 -
On 23 Jul 2014 16:46, "Raphael Hertzog" wrote:
> - we should package South 1.0, it uses "south_migrations" instead of
> "migrations" if it exists, that way applications can provide migrations
> for South and for Django 1.7
Already done. Uploaded and installed in Debian unstable today.
Was st
think the most likely problem
will be locally installed Django apps that are not part of Debian [need
some sort of evidence to back up this claim].
(as an aside, I have users of my Django app who are still running a really
old version on Debian squeeze :-( ).
--
Brian May
rk, I don't think I would trust it.
--
Brian May
this right):
=== cut ===
import sys
import django
if sys.version_info < (3, 0) and django.VERSION < (1, 7):
INSTALLED_APPS += ('south',)
=== cut ===
As south is not available for Python 3.
--
Brian May
uot; directory - it appears to be Django 1.7 compliant
already; it wasn't in wheezy.
--
Brian May
On 14 Jul 2014 22:21, "Matthias Klose" wrote:
> Twisted has some support for Python3, see twisted/python/dist3.py in the
> twisted 14.0 sources. I packaged a twisted-py3 building a
> python3-twisted-experimental, which I didn't yet upload to Debian. For
now you
> can get it from https://launchpad
Raphael said he is not subscribed, so I have sent this to him.
On 3 Aug 2014 14:13, "Thomas Goirand" wrote:
> On 07/23/2014 08:27 AM, Brian May wrote:
> > Hello,
> >
> > Thanks for you work. I very much agree, would really like to see Django
> > 1.7 in Jess
On 3 Aug 2014 14:53, "Brian May" wrote:
>> Django 1.7 final isn't even released upstream, and therefore, downstream
>> projects didn't even try to run against it. There *will* be issues we
>> will have to deal with. 85 packages is quite something. I'm
On 3 August 2014 15:07, Brian May wrote:
> It will be released very soon now. They have released RC2, and I heard, as
> of yesterday, there was only one blocking bug (I am at PyConAu).
>
It sounds like there might be be some effort to make Django 1.7 releasable
at the post-conferenc
go 1.7 in experimental...
--
Brian May
On 23 July 2014 15:58, Brian May wrote:
> You are expected to do all database migrations with Django 1.6, then
> upgrade to Django 1.7
>
Some more thoughts.
Are there any packages in Debian that attempt to automatically do database
migrations on upgrade?
If, not, that is good. Will
jango-filter/issues/157.
Hope I haven't missed other bugs :-).
--
Brian May
the moment, in subversion, we only store the debian/* directory. Is
there any requirement/benefit in putting the full upstream source in git
too?
--
Brian May
o 1.7 can
ignore these successfully.
Thanks
--
Brian May
on versions.
It is possible that there might be python3 packages depending on python-
packages simply because the required Python3 packages haven't been built
yet (or upstream doesn't support Python3 yet). Can't think of a good
example though. In most cases a python-* dependency will
ittle bit yucky though.
If I remove one of the duplicate calls, I get the broken behaviour again.
Thanks
--
Brian May
On 11 August 2014 20:59, Michael Fladischer wrote:
> On 2014-08-11 07:16, Brian May wrote:
> > I have updated kombu in subversion to provide Python 3 packages.
>
> There is already a python3 branch in svn ... waiting for the python-nose
> test failure to be fixed.
&g
If so, sounds like a good plan.
Would be interested to know what is doing on with dh_python3 though... Even
if the workaround is simple.
--
Brian May
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757751
I am kind of stuck what to do here. I reported it upstream, but half expect
them to respond (if they do actually respond) with "that is why we supply
our own copy of librabbitmq-c". Which obviously isn't really a good
solution
On 11 August 2014 21:25, Piotr Ożarowski wrote:
> [Brian May, 2014-08-11]
> > Only the install phase is leaving behind empty directories under
> > debian/python3-kombu/usr/lib/python3.4/dist-packages/kombu/
>
> which version of dh_python3 did you use? Can you paste -v/--verb
On 11 August 2014 21:33, Brian May wrote:
> which version of dh_python3 did you use? Can you paste -v/--verbose's
>> output?
>>
>
This is an up-to-date sid schroot (at least it was up-to-date yesterday).
Not sure if this output helps, except for it saying "moving fil
(changed the subject)
On 11 August 2014 21:56, Michael Fladischer wrote:
> On 2014-08-11 13:32, Brian May wrote:
> > I am kind of stuck what to do here. I reported it upstream, but half
> > expect them to respond (if they do actually respond) with "that is why
> >
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
le "OpenSSL/test/test_rand.py", line 13, in
from OpenSSL.test.util import TestCase, b
ImportError: No module named 'OpenSSL'
running OpenSSL/test/test_ssl.py for python3.4 ...
Traceback (most recent call last):
File "OpenSSL/test/test_ssl.py", line 19, in
from OpenSSL.crypto import TYPE_RSA, FILETYPE_PEM
ImportError: No module named 'OpenSSL'
ls: cannot access build/lib_d.*-3.4: No such file or directory
ls: cannot access build/lib.*-3.4-pydebug: No such file or directory
Traceback (most recent call last):
File "OpenSSL/test/test_ssl.py", line 19, in
from OpenSSL.crypto import TYPE_RSA, FILETYPE_PEM
ImportError: No module named 'OpenSSL'
make[1]: *** [override_dh_auto_test] Error 1
debian/rules:25: recipe for target 'override_dh_auto_test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [build] Error 2
debian/rules:11: recipe for target 'build' failed
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Thanks
--
Brian May
e django-oauth-plus is not in testing. This might be because of RC
bugs in python-oauth2. #722656, #722657.
Is anyone trying to fix python-oauth2 It looks like it has security
issues that have not been touched in almost a year now.
--
Brian May
On 17 August 2014 12:15, Brian May wrote:
> Oddly enough python-djangorestframework is broken in testing already
> because django-oauth-plus is not in testing. This might be because of RC
> bugs in python-oauth2. #722656, #722657.
>
> Is anyone trying to fix python-oauth2 I
On 17 August 2014 12:26, Brian May wrote:
> On second thoughts, after reading past emails on python-oauth2 in this
> group, it sounds like django-oauth-plus needs a RC bug to use
> python-oauthlib instead of python-oauth2. Will open such a bug now.
>
Just opened the following list o
= lambda: _importer(target)
File "/usr/lib/python3/dist-packages/mock.py", line , in _importer
thing = _dot_lookup(thing, comp, import_path)
File "/usr/lib/python3/dist-packages/mock.py", line 1101, in _dot_lookup
return getattr(thing, comp)
AttributeError: 'module' object has no attribute 'sets'
--
--
Brian May
ream? Should I do the same thing for 0.5.1?
Thanks
--
Brian May
1 - 100 of 400 matches
Mail list logo
