Bug#562904: adonthell ftbfs on armel

[peter green]

package: adonthell
version: 0.3.5-4
severity: serious
x-debbugs-cc: debian-python@lists.debian.org

During the run up to the lenny release python 2.5 was made the default 
and this made adonthell FTBFS on arm(el) with "Fatal Python error: 
exceptions bootstrapping error." 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486654 ). While doing 
flyby bugsquashing I took a look at this bug but failed to make any 
headway. I asked on debian-python but the only response I received was a 
suggestion to ask upstream. Since I was just doing flyby bugsquashing, 
had failed to produce a reduced testcase (since I really had no idea 
what was triggering the bug) and I don't know python I didn't make any 
contact with upstream (for either python or adonthell).


Since a release was looming and noone had made no progress on finding a 
root cause (afaict none of the maintainers even responsed to the 
bugreport) I proposed a patch that special cased arm(el) and explicityly 
chose python2.4 on theese architectures. after some minor revisions this 
patch was uploaded by Philipp Kern as a NMU.


Due to the planned removal of python2.4 Moritz Muehlenhoff reverted this 
special casing recently and the package now FTBFS again on armel but the 
soloution used last time is no longer possible. So as Moritz indicated 
in his changelog entry either the issue with newer python versions needs 
to be found and fixed (something I'm not capable of doing) or the armel 
adonthell package needs to be dropped.




--
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 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-
>>
>>
>

Re: Trac wrong plugin names.

[Christoph Egger]

On Mon, Dec 28, 2009 at 09:38:26AM +0200, anatoly techtonik wrote:
> On Mon, Dec 28, 2009 at 3:34 AM, W. Martin Borgert  wrote:
> >
> >> Now I still have
> >> AccountManager named "urwid" in Trac Admin panel, but I do not even
> >> want to repeat this awful SSH experience.
> >
> > I have the same problem (wrong Python package names as names of
> > Trac plugins in the admin panel) sometimes, but I don't know what
> > the cause is. Any idea? (But I don't think, it's in any way
> > related to JavaScript nor jQuery...)
> 
> Finally decided to change topic as this time it has nothing to do with jQuery.
> It's probably a conflict between setuptools and Debian packaging (i.e.
> setuptools vs python-central), because manually installed plugins from
> my environment are ok.
> 
> What about switching to python-support and see if it solves the problem?
> 
> -- 
> anatoly t.

I'm seeing it with trac-graphviz, which is python-support as well.

Regards

Christoph

-- 
/"\  ASCII Ribbon : GPG-Key ID: 0xD49AE731
\ /Campaign   : CaCert Assurer
 X   against HTML : Debian Maintainer
/ \   in eMails   : http://www.debian.org/

http://www.christoph-egger.org/


signature.asc
Description: Digital signature

Re: Python Bindings for MLT

[Jonathan Thomas]

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-
>
>

Re: jQuery dependency for Trac 0.11 should be < 1.3

[W. Martin Borgert]

Quoting "anatoly techtonik" :

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?

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/


So, if a package is listed in "Recommends:" section it is installed
automatically by command line "aptitude install trac"? Didn't know
that.


Both aptitude and apt-get install "Recommends" by default. This can
be switched off, but most users don't know that, fortunately :~)


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

Re: Unit tests

[Sandro Tosi]

On Sat, Dec 26, 2009 at 19:11, Guy Hulbert  wrote:
> On Sat, 2009-26-12 at 17:13 +0100, W. Martin Borgert wrote:
>> Quoting "anatoly techtonik" :
>> If unit tests were in the package, reportbug could automatically
>> run them on a bug report. Does someone do this already, maybe?
>
> Can reportbug be modified to download a source package and run tests ?

Short answer: no.

Detailed answer: no, because:

- it bloats reportbug to do something that's not meant to (it _reports bugs_)
- how to recognize packages that have unit tests and those that haven't?
- where are those unit tests and how to execute them? more generally:
there is no standard way to run unit tests.
- what if unit tests need additional dependencies (not present on the
user system) to be executed?

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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