Re: jQuery dependency for Trac 0.11 should be < 1.3

[anatoly techtonik]

On Mon, Dec 28, 2009 at 4:27 PM, W. Martin Borgert  wrote:
>>
>> Then we should also patch "trac-admin deploy" command so that it
>> create symlinks to static resources instead of copies to update user
>> environments to latest jQuery automaically.
>
> I don't remember, I ever used "trac-admin deploy", and I wonder how
> useful it is. It saves you from creating one symlink and creating
> one WSGI file of typically about ten lines, right?

Not only that - these ten lines are not fixed - it records path to the
correct python interpreter and path to environment. That makes sure
that it will be run with the Python you've run "deploy" with and for
which you've probably installed all your plugins. This also important
in case of virtualenv.

> Maybe it's sufficient to change the documentation of the deploy
> command in README.Debian? Like:
>
> If you prefer copies (which are not updated automatically, even
> in case of security issues), use "trac-admin deploy", if you
> prefer links, use the following commands:
>
> $ cp /usr/share/doc/trac/examples/foo.wsgi /my/trac/env/cgi-bin/
> $ vi /my/trac/env/cgi-bin/foo.wsgi # adjust trac env directory
> $ ln -s /usr/share/pyshared/trac/htdocs /my/trac/env/

That's not sufficient. To update Trac environment you will need to run
"trac-admin upgrade" and optionally "trac-admin wiki upgrade". The
second point is that web-servers (including Apache) treat symlinks
differently and I am unsure how to setup web permissions correctly if
symlinks lead outside of your environment. "deploy" is useful command
- it exports web resources that can be configured to be served
statically, which should greatly reduce server load by avoiding
loading interpreter for serving .png buttons. This is especially true
for CGI.

-- 
anatoly t.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Trac upgrade documentation (was: jQuery dependency for Trac 0.11)

[W. Martin Borgert]

Quoting "anatoly techtonik" :

That's not sufficient. To update Trac environment you will need to run
"trac-admin upgrade" and optionally "trac-admin wiki upgrade". The
second point is that web-servers (including Apache) treat symlinks
differently and I am unsure how to setup web permissions correctly if
symlinks lead outside of your environment.


I really have to check my setup. I'm using Apache (and WSGI).
Probably I allowed Apache explicitly to access certain paths.

Changing the semantics of the "trac-admin deploy" command is
something that I would prefer to be done by upstream. For
Debian it sounds like documenting the issue well, so that
people know, what they have to expect.

There is an open bug report anyway, that suggests and
"trac-admin upgrade" to be done automatically on every
upgrade of Trac. This is technically too difficult to solve,
because one never knows which environments exist (they
might not even be available at package upgrade time). Again,
this is sth. that should be documented clearly.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Python Bindings for MLT

[Jonathan Thomas]

I solved this problem also.  I needed to change my setup.py to include a mlt
folder, not a mlt-python folder.  Also, I modified the __init__.py to
include the following code:
"from mlt import *"

Now when I install the package, python-support puts everything in the
/usr/lib/pymodules/ folder, which is in the python path, and then my "mlt"
folder and the customized __init__.py file work great.

Now I am able to import the mlt library as expected:
>> import mlt

Sorry for so many stupid questions.  I tried to explain my solutions so they
are documented for the next person with my questions. =)

Thanks,
-Jonathan

On Mon, Dec 28, 2009 at 4:24 PM, Jonathan Thomas
wrote:

> I have figured out the answer to my question.  Python-support correctly
> adds my folder and files to the Python path.  This changes the way I need to
> import the python module from
> >> import mlt
> to
> >> import mlt-python.mlt
>
> However, "mlt-python" does not appear to be a valid module name for
> Python.  It does not like the "-" character.  Is there a way to tell
> python-support what the name of the folder should be?  For example,
>
> Instead of this folder:  /usr/lib/pymodules/python2.6/mlt-python/
> Use this folder:  /usr/lib/pymodules/python2.6/mlt/
>
>
> Thanks in advance!
> -Jonathan Thomas
>
>
> On Mon, Dec 28, 2009 at 2:48 PM, Jonathan Thomas  > wrote:
>
>> Jakub,
>> Thanks for the advice.  I have removed the postinst script and the
>> DEB_PYTHON_INSTALL_ARGS_ALL line.  I have also contacted the MLT packagers,
>> but I'm not confident they will include the Python bindings in their
>> packages.
>>
>> Here is a dumb question.  After installing the DEB file, it moves all of
>> the correct files to /usr/lib/pymodules/python2.6/mlt-python.  However, when
>> I fire up python, it is unable to import mlt.
>>
>> For example:
>> >> *import mlt*
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> ImportError: No module named ml
>>
>> If I launch the Python interpreter from
>> /usr/lib/pymodules/python2.6/mlt-python, it works just fine.  It is acting
>> like my public Python module is not in the sys.path.  I assumed because
>> /usr/lib/pymodules/python2.6/ was in the sys.path, that this would work.
>>
>> Am I missing something?
>>
>> Thanks,
>> -Jonathan
>>
>> On Thu, Dec 17, 2009 at 6:38 AM, Jakub Wilk  wrote:
>>
>>> Hello,
>>>
>>> * Jonathan Thomas , 2009-12-15, 13:16:
>>>
 I have done my best to package the MLT Python bindings (which were
 generated
 using Swig), and I have published to my own
 PPA(hosted

 on LaunchPad).  I am fairly certain that my build script needs to be
 improved.  For example, I never could figure out how to copy the MLT
 Python
 bindings to the /site-packages/ folder, so I created a postinst file...
 which can't be the best way.

>>>
>>> Right, that's not event an acceptable way. Those files don't need to be
>>> installed into /site-packages/, python-support should take care to put them
>>> in the right place once you remove maintainer scripts and the
>>> DEB_PYTHON_INSTALL_ARGS_ALL line from debian/rules.
>>>
>>> Anyway, these bindings should not have a separate source package. Just
>>> ask mlt maintainers (preferably via a bug report) to build binary package
>>> with Python bindings out of their source.
>>>
>>> --
>>> Jakub Wilk
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>>
>>> iQIcBAEBCAAGBQJLKiYwAAoJEC1Os6YBVHX1ve4P/3661p1kp2xbF2j/LtQ0oA1o
>>> 4goSpI+rg2Fl+zHi4e4VOexhSXrvw2WaaHEXofzVFvcoC3Osgz/H2iLzm6DkL3PI
>>> 5MrlLcAYU/ZP4ahRA20HHiQhvXcZMWgrN+2uLzu4l8tMAexMtNfQ/xPiceKV3kL9
>>> KDHS3X6Rk7jG6vsnPVI7uGztgjprSr6MG3Ks6NoLICgPCk8SUQ1P+okaP99H/Q0f
>>> 6+pbDYiK5g5/v4dw/iIXIJHMsaawh6F+zphvEg7TMVJuWJ9zGPORmDNMon0z3+h0
>>> Q4xTD2qemnL3ybleKVvcF40p/po4HGk+IYaaqM4HQ0DudH8gSkKoFp0Hzx12ZQ34
>>> XMxHL8dNAnYPqlvubgxjQqctmAVm660dqExKQDjPMQytpjntyVPAKQGJdEOBCPwY
>>> Chj5nn36/dAUH9HTd4f2583nRfcCX5BbPdhFbADPAoen8Fbehl4GBGYSoUsJ7COT
>>> sjvXpRKkMxSUhXGXt6k4Gs63YrQ80rZwJPhYM/vtaKzBeLyq/5Acc7n2Ba8CIU1Y
>>> h42OQgG5bhyAFUGdiomUd1eweSfUZ04FZSXHfaVwqUuWeeOYZacQiUj111ygdMTS
>>> vbZ4EU/MR+xc5p6mJNqyJTBI9TrqV1eHfsgjLXTi9J8e3IFDkEt7Nhdweuoid4Gp
>>> hFNHiCz04pdpj/8HWWrS
>>> =kneW
>>> -END PGP SIGNATURE-
>>>
>>>
>>
>

How do I know if my package is 'arch-all' or 'arch-any'?

[anatoly techtonik]

python-support README [1] contains different instructions for
'arch-all' and 'arch-any' packaged. How do I know which one is mine?

[1] 
http://svn.debian.org/viewsvn/collab-maint/deb-maint/python-support/trunk/README

Thanks.
-- 
anatoly t.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: How do I know if my package is 'arch-all' or 'arch-any'?

[W. Martin Borgert]

Quoting "anatoly techtonik" :

python-support README [1] contains different instructions for
'arch-all' and 'arch-any' packaged. How do I know which one is mine?


all: Package works on all architectures without (re-) compilation,
 e.g. a program written in Python

any: Package needs e.g. compilation, but will work on any
 architecture, e.g. a library for Python, but written in C

HTH!

PS: debian-mentors is probably the best list for questions, that
are not directly related to Python.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: How do I know if my package is 'arch-all' or 'arch-any'?

[anatoly techtonik]

On Tue, Dec 29, 2009 at 11:01 PM, W. Martin Borgert  wrote:
> Quoting "anatoly techtonik" :
>>
>> python-support README [1] contains different instructions for
>> 'arch-all' and 'arch-any' packaged. How do I know which one is mine?
>
> all: Package works on all architectures without (re-) compilation,
>     e.g. a program written in Python
>
> any: Package needs e.g. compilation, but will work on any
>     architecture, e.g. a library for Python, but written in C

Thanks! How about updating python-support README with these comments?
Something makes me think that most Python people who are the primary
readers of this text don't really know what is "arch-all" or
"arch-any".

> HTH!
>
> PS: debian-mentors is probably the best list for questions, that
> are not directly related to Python.

You can't say it is not related to Python! And subscribing to yet
another mailing list is painful unless it is a Google Group.
-- 
anatoly y.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Trac upgrade documentation (was: jQuery dependency for Trac 0.11)

[anatoly techtonik]

On Tue, Dec 29, 2009 at 6:10 PM, W. Martin Borgert  wrote:
>
> There is an open bug report anyway, that suggests and
> "trac-admin upgrade" to be done automatically on every
> upgrade of Trac. This is technically too difficult to solve,
> because one never knows which environments exist (they
> might not even be available at package upgrade time). Again,
> this is sth. that should be documented clearly.

If environments are created with trac-admin init, it is possible to
patch it to record their locations and check if these locations exist
at upgrade time.
-- 
anatoly t.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: How do I know if my package is 'arch-all' or 'arch-any'?

[Iustin Pop]

On Tue, Dec 29, 2009 at 11:38:11PM +0200, anatoly techtonik wrote:
> On Tue, Dec 29, 2009 at 11:01 PM, W. Martin Borgert  
> wrote:
> > Quoting "anatoly techtonik" :
> >>
> >> python-support README [1] contains different instructions for
> >> 'arch-all' and 'arch-any' packaged. How do I know which one is mine?
> >
> > all: Package works on all architectures without (re-) compilation,
> >     e.g. a program written in Python
> >
> > any: Package needs e.g. compilation, but will work on any
> >     architecture, e.g. a library for Python, but written in C
> 
> Thanks! How about updating python-support README with these comments?
> Something makes me think that most Python people who are the primary
> readers of this text don't really know what is "arch-all" or
> "arch-any".

People who are creating/maintaining packages should start by reading the
general packaging documentation, which explains these.

> > HTH!
> >
> > PS: debian-mentors is probably the best list for questions, that
> > are not directly related to Python.
> 
> You can't say it is not related to Python! And subscribing to yet
> another mailing list is painful unless it is a Google Group.

With all due respect, these are basic packaging terms that are not
Python specific at all.

regards,
iustin


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org