Re: Bug#937177: obitools: Python2 removal in sid/bullseye

[olivier sallou]

Le sam. 7 mars 2020 à 06:12, Sergio Durigan Junior  a
écrit :

> On Sunday, January 12 2020, Andreas Tille wrote:
>
> > On Sun, Jan 12, 2020 at 07:27:59AM -0500, Scott Kitterman wrote:
> >> On Fri, 30 Aug 2019 07:28:59 + Matthias Klose 
> wrote:
> >> This
> >> package is blocking several others.  Would it be best to remove it?  It
> can
> >> always be re-introduced if a python3 port appears.
> >
> > Since some time I've pushed a 2to3 based port to Git.  I've now fixed
> > some issues of this and I wonder whether we might give it a try to do
> > the port inside Debian.  For the moment I'm running into the following
> > issue:
> >
> >dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:217: cd
> /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7
> -m unittest discover -v
> > obitools (unittest.loader._FailedTest) ... ERROR
> >
> > ==
> > ERROR: obitools (unittest.loader._FailedTest)
> > --
> > ImportError: Failed to import test module: obitools
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.7/unittest/loader.py", line 470, in
> _find_test_path
> > package = self._get_module_from_name(name)
> >   File "/usr/lib/python3.7/unittest/loader.py", line 377, in
> _get_module_from_name
> > __import__(name)
> >   File
> "/build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build/obitools/__init__.py",
> line 23, in 
> > from _obitools import BioSequence,NucSequence,AASequence, \
> > ModuleNotFoundError: No module named '_obitools'
> >
> >
> > --
> > Ran 1 test in 0.000s
>
> Hey Andreas,
>
> I cannot reproduce this bug when building inside a clean schroot
> (unstable).  I don't know if the reason is because I don't have
> python3.7 installed in the schroot anymore (it was removed recently, and
> python3.8 is the default), or because there's something else different.
>

I pushed in february during our sprint some updates in git fixing the
issue. However it implied lots of modification that may impact software as
it implied to do some choices on types (bytes vs str for example with c
binding), without really knowing the impact

We may push the package but other packages using might be broken
On other side, package will be removed.

So either we push an update, knowing that it may not be fully fonctional,
or let it go.

Olivier






> > FAILED (errors=1)
> > E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1:
> cd /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build;
> python3.7 -m unittest discover -v
> > dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit
> code 13
> > make: *** [debian/rules:15: build] Error 255
> > dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> > I: copying local configuration
> > E: Failed autobuilding of package
> > I: user script
> /var/cache/pbuilder/build/cow.1543005/tmp/hooks/C99_failed_build starting
> > Installing convenience apps: mc less bash-completion
> > root@energija:/# cd build/obitools-1.2.13+dfsg/
> > root@energija:/build/obitools-1.2.13+dfsg# find . -name "*.so"
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_
> options.cpython-37m-x86_64-linux-gnu.so
>=
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_
> bioseqfilter.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/profile/_
> profile.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/utils/_
> utils.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/_
> obitools.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/tools/_
> solexapairend.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/fasta/_
> fasta.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> upperbond.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> rassemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> freeendgapfm.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> nwsdnabyprot.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> assemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> freeendgap.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> qsrassemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> gprofilenws.cpython-37m-x86_64-linux-gnu.so
> > 

Re: influxdb-python FTBFS with pandas 0.25.3

[Olivier Sallou]

- Mail original -
> De: "andreas" 
> À: 950...@bugs.debian.org, "debian-python" , 
> "Alexandre Viau" 
> Envoyé: Mercredi 5 Février 2020 09:36:27
> Objet: Re: influxdb-python FTBFS with pandas 0.25.3

> Hi Alexandre,
> 
> since a Debian Med package is affected as reverse-depends of
> influxdb-python I had a look.  Unfortunately this Python package
> is not maintained by the Python modules team.  I would consider
> it a good idea to move this package into team maintenance.  I'd
> volunteer to do that move but wanted to ask for permission first.
> 

problem is pandas seems to have broken things with last/recent update. influx 
does not seem to have fixed panda issues for now and sticks to older panda 
version requirement, which is fine from python point of view (getting the 
expected version), but being an issue for Debian taking only last one.

+1 for moving it to python if they do agree...

regarding biomaj which depends on influxdb, I think I will workaround issue 
during our sprint and patch program to remove temporarily 
 the requirement (not closing bug but lowering severity, thiswas already done 
in the past before influx package was available).

Olivier


> If you argee I would upgrade the package to 5.2.3 despite I
> realised that there are open issues
> 
>https://github.com/influxdata/influxdb-python/issues/738
> and
>https://github.com/influxdata/influxdb-python/issues/696
> 
> Could you please comment on these?
> 
> Kind regards
> 
>  Andreas.
> 
> --
> http://fam-tille.de

Re: Bug 903801: Python pika rc bug, expected close?

[Olivier Sallou]

On 08/13/2018 09:15 AM, Thomas Goirand wrote:
> On 08/13/2018 08:33 AM, Olivier Sallou wrote:
>> Hi,
>>
>> Any chance to close this bug before removal? I have some packages
>> depending on it.
>> If you don't have time to fix it, I can have a look and upload a fixed
>> package, should not be too difficult to fix.
>> Thanks
>>
>> Olivier
> Well, the upload of yesterday from Jan Dittberner fixed it. Just wait it
> migrates to testing.
Cool,

thanks
>
> Cheers,
>
> Thomas Goirand (zigo)
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

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

Bug 903801: Python pika rc bug, expected close?

[Olivier Sallou]

Hi,

Any chance to close this bug before removal? I have some packages
depending on it.
If you don't have time to fix it, I can have a look and upload a fixed
package, should not be too difficult to fix.
Thanks

Olivier

-- 

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

Re: Preconditions for python-moto finished - help needed to build package itself

[Olivier Sallou]

- Mail original -
> De: "Andreas Tille" 
> À: 777...@bugs.debian.org
> Cc: debian-python@lists.debian.org, "Debian Science List" 
> 
> Envoyé: Vendredi 2 Février 2018 09:16:55
> Objet: Preconditions for python-moto finished - help needed to build package 
> itself
> 
> Hi,
> 
> as you might have noticed I finalised the preconditions to build
> python-moto which is in salsa.d.o[1].  When trying to build I get:
> 
> 
> 
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py test
> running test
> running egg_info
> writing requirements to moto.egg-info/requires.txt
> writing moto.egg-info/PKG-INFO
> writing top-level names to moto.egg-info/top_level.txt
> writing dependency_links to moto.egg-info/dependency_links.txt
> writing entry points to moto.egg-info/entry_points.txt
> reading manifest file 'moto.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'moto.egg-info/SOURCES.txt'
> running build_ext
> Traceback (most recent call last):
>   File "setup.py", line 68, in 
> "Topic :: Software Development :: Testing",
>   File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line 129,
>   in setup
> return distutils.core.setup(**attrs)
>   File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
> dist.run_commands()
>   File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
> self.run_command(cmd)
>   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line
>   226, in run
> self.run_tests()
>   File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line
>   248, in run_tests
> exit=False,
>   File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
> self.parseArgs(argv)
>   File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
> self.createTests()
>   File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
> self.module)
>   File "/usr/lib/python2.7/unittest/loader.py", line 130, in
>   loadTestsFromNames
> suites = [self.loadTestsFromName(name, module) for name in names]
>   File "/usr/lib/python2.7/unittest/loader.py", line 103, in
>   loadTestsFromName
> return self.loadTestsFromModule(obj)
>   File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line
>   52, in loadTestsFromModule
> tests.append(self.loadTestsFromName(submodule))
>   File "/usr/lib/python2.7/unittest/loader.py", line 100, in
>   loadTestsFromName
> parent, obj = obj, getattr(obj, part)
> AttributeError: 'module' object has no attribute 'backport_assert_raises'

backport_assert_raises is a python file in tests directory of moto, maybe it is 
missing in your install?

> E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1:
> python2.7 setup.py test
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:6: recipe for target 'build' failed
> make: *** [build] Error 25
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> 
> 
> I was seeking for some missing backport module but I have no real clue
> what might be missing.  Any help would be welcome.
> 
> Kind regards
> 
>  Andreas.
> 
> 
> 
> [1]
> 
> --
> http://fam-tille.de
> 
> 

Re: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Olivier Sallou]

- Mail original -
> De: "Olivier Sallou" <olivier.sal...@irisa.fr>
> À: "Andreas Tille" <andr...@an3as.eu>
> Cc: debian-python@lists.debian.org, "Debian Science List" 
> <debian-scie...@lists.debian.org>, 777...@bugs.debian.org
> Envoyé: Mardi 23 Janvier 2018 17:11:05
> Objet: Re: Next python-mote pre-condition - issue with pybuild: 
> python-backports.tempfile conflicting
> python-backports.weakref
> 
> 
> 
> - Mail original -
> > De: "Andreas Tille" <andr...@an3as.eu>
> > À: debian-python@lists.debian.org, "Debian Science List"
> > <debian-scie...@lists.debian.org>, 777...@bugs.debian.org
> > Envoyé: Lundi 22 Janvier 2018 15:04:10
> > Objet: Re: Next python-mote pre-condition - issue with pybuild:
> > python-backports.tempfile conflicting
> > python-backports.weakref
> > 
> > Hi,
> > 
> > I kept on working packaging python-moto predependencies.  I'm now
> > stumbling upon python-backports.tempfile[1] and
> > python-backports.weakref[2].  My naive packaging attempt puts
> > the modules into
> 
> well, package name should not really use dots in name, I suppose that's what
> leads to error. But don't know how to fix that with python helper... :-(
> 
> both modules use the same "base module", ie *backports* so final dest is
> correct. From a pure python point of view, you can "merge" multiple sub
> modules in the same mail module, python will manage the duplication of
> __init__.py
> 
> However, in Debian case, I do not know how this can be handled as 2 packages
> cannot hold the same file (even if __init__ is only an empty file), and at
> least one must be present (if you install only one).
> 
> Olivier
> 
> > 
> >/usr/lib/python*/dist-packages/backports
> > 
> > leaving the same package
> > 
> >/usr/lib/python3/dist-packages/backports/__init__.py

after thinking about this, I think the "easy" solution would be to:

 * create a *backports* package, that simply embeds a backports/__init__.py

 * depends on this backports package itself and simply remove 
backports/__init__.py from backports.XXX packages.

If they depend on backports, this file will will always be present, and will be 
of for backports.xx modules.

You would only need to remove the file from installed files in packages.

I see though that you have already uploaded package, how did you handle the 
issue?

Olivier

> > 
> > for both packages and thus the packages are conflicting.  I have no idea
> > why pybuild simply uses the dir backports instead of the full module
> > name nor do I have any idea how to fix this.  I tried to hack around in
> > the backports.weakref package using
> > 
> > 
> > override_dh_auto_install:
> > for dir in `find .pybuild -type d -name backports | sort | uniq` ;
> > do
> > \
> > mv $${dir} $${dir}.weakref ; \
> > done
> > dh_auto_install
> > 
> > but this rather has led to an empty package.
> > 
> > Any help is welcome
> > 
> > Andreas.
> > 
> > 
> > [1] https://salsa.debian.org/science-team/python-backports.tempfile.git
> > [2] https://salsa.debian.org/science-team/python-backports.weakref.git
> > 
> > --
> > http://fam-tille.de
> > 
> > 
> 
> 

Re: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Olivier Sallou]

- Mail original -
> De: "Andreas Tille" 
> À: debian-python@lists.debian.org, "Debian Science List" 
> , 777...@bugs.debian.org
> Envoyé: Lundi 22 Janvier 2018 15:04:10
> Objet: Re: Next python-mote pre-condition - issue with pybuild: 
> python-backports.tempfile conflicting
> python-backports.weakref
> 
> Hi,
> 
> I kept on working packaging python-moto predependencies.  I'm now
> stumbling upon python-backports.tempfile[1] and
> python-backports.weakref[2].  My naive packaging attempt puts
> the modules into

well, package name should not really use dots in name, I suppose that's what 
leads to error. But don't know how to fix that with python helper... :-(

both modules use the same "base module", ie *backports* so final dest is 
correct. From a pure python point of view, you can "merge" multiple sub modules 
in the same mail module, python will manage the duplication of __init__.py

However, in Debian case, I do not know how this can be handled as 2 packages 
cannot hold the same file (even if __init__ is only an empty file), and at 
least one must be present (if you install only one).

Olivier

> 
>/usr/lib/python*/dist-packages/backports
> 
> leaving the same package
> 
>/usr/lib/python3/dist-packages/backports/__init__.py
> 
> for both packages and thus the packages are conflicting.  I have no idea
> why pybuild simply uses the dir backports instead of the full module
> name nor do I have any idea how to fix this.  I tried to hack around in
> the backports.weakref package using
> 
> 
> override_dh_auto_install:
> for dir in `find .pybuild -type d -name backports | sort | uniq` ; do
> \
> mv $${dir} $${dir}.weakref ; \
> done
> dh_auto_install
> 
> but this rather has led to an empty package.
> 
> Any help is welcome
> 
> Andreas.
> 
> 
> [1] https://salsa.debian.org/science-team/python-backports.tempfile.git
> [2] https://salsa.debian.org/science-team/python-backports.weakref.git
> 
> --
> http://fam-tille.de
> 
> 

Python module packaging

[olivier sallou]

Hi,
I'd like to simple package python-eta module[0].
Having a look at policy, I only see SVN repo [1]. Can't we package module
using a git repo ?

Thanks

Olivier

[0] https://github.com/mbreese/eta/
[1] https://wiki.debian.org/Teams/PythonModulesTeam

package for python 2/3 issues

[olivier sallou]

Hi,
I try to package a software that supports both python 2 and 3 with future.
future is not yet available in Debian (I've seen an ITP about it), but I'd
like to start the package on my side.

I have an error when using pybuild, it does not find find_packages (from
setuptools). I wonder what is wrong here (without pybuild it is fine for a
python2 build).

dh clean --with python2,python3  --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py clean
Traceback (most recent call last):
  File setup.py, line 44, in module
'packages': find_packages(),
NameError: name 'find_packages' is not defined
E: pybuild pybuild:256: clean: plugin distutils failed with: exit code=1:
python3.4 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.4 --dir . returned
exit code 13
make: *** [clean] Error 13

I tried to follow https://wiki.debian.org/Python/LibraryStyleGuide but I
certainly missed something.


It is a basic python package with setup.py.

Thanks

Olivier

Re: package for python 2/3 issues

[olivier sallou]

ok, my fault, a package was not installed sorry for noise.

Le ven. 22 mai 2015 à 14:15, olivier sallou olivier.sal...@gmail.com a
écrit :

 Hi,
 I try to package a software that supports both python 2 and 3 with future.
 future is not yet available in Debian (I've seen an ITP about it), but I'd
 like to start the package on my side.

 I have an error when using pybuild, it does not find find_packages (from
 setuptools). I wonder what is wrong here (without pybuild it is fine for a
 python2 build).

 dh clean --with python2,python3  --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
 I: pybuild base:170: python3.4 setup.py clean
 Traceback (most recent call last):
   File setup.py, line 44, in module
 'packages': find_packages(),
 NameError: name 'find_packages' is not defined
 E: pybuild pybuild:256: clean: plugin distutils failed with: exit code=1:
 python3.4 setup.py clean
 dh_auto_clean: pybuild --clean -i python{version} -p 3.4 --dir . returned
 exit code 13
 make: *** [clean] Error 13

 I tried to follow https://wiki.debian.org/Python/LibraryStyleGuide but I
 certainly missed something.


 It is a basic python package with setup.py.

 Thanks

 Olivier

Re: conflict python-captcha vs django-captcha

[olivier sallou]

Le 20 juin 2014 01:23, Brian May br...@microcomaustralia.com.au a écrit
:

 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.
Hi
Python-captcha is a dependency of an other tool i manage (mobyle) and
recently upload a new release due to an other user request.

Olivier

 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: Help with packaging of python executable and its modules

[Olivier Sallou]

I have uploaded a patch and an update to rules and control.

Seems to work now.

Olivier

On 02/07/2014 02:20 PM, Andreas Tille wrote:
 Hi folks,

 I have commited some packaging for a bioinformatics package arden to

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

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

/usr/share/pyshared/arden/core

 and tried to patch the executable scripts to say something like

 from arden.core import  AnalyseMapping as AM

 instead of

 from core import  AnalyseMapping as AM


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

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

 does not work.

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

 Kind regards

Andreas.


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

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


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

Re: Help with packaging of python executable and its modules

[Olivier Sallou]

On 02/07/2014 02:41 PM, Julian Taylor wrote:


 On Fri, Feb 7, 2014 at 2:20 PM, Andreas Tille andr...@an3as.eu
 mailto:andr...@an3as.eu wrote:

 Hi folks,

 I have commited some packaging for a bioinformatics package arden to

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

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

/usr/share/pyshared/arden/core

 and tried to patch the executable scripts to say something like


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

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

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

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


 just for completeness, your approach does not work as you are missing
 a __init__.py in the folder
Part of my patch  ;-)

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

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

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

[Olivier Sallou]

On 02/07/2014 05:12 PM, Andreas Tille wrote:
 Hi folks,

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

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

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


dh_auto_clean
 Downloading 
 http://pypi.python.org/packages/source/d/distribute/distribute-0.6.34.tar.gz
Problem comes from distribute_setup.py which makes some downloads.
It is used in setup.py:

from distribute_setup import use_setuptools
use_setuptools()

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

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

You could first try deleting:

 130 from distribute_setup import use_setuptools
 131 use_setuptools()

if setuptools is already installed.

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


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

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

 Kind regards

Andreas.


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

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

Request for pyramid application packaging recommendations

[Olivier Sallou]

Hi,
I plan to create an application using pyramid application server.

Is there any constraint/recommandation to package my application after
that as a Debian package?

My concern is, after a very quick test with Pyramid, that Pyramid adds
some eggs etc... in my application directory (such as
zope.sqlalchemy-0.6.1-py2.7.egg, ...).  I think I could remove those
files in source package and add symlinks to Debian packaged files, but
I'd like to know if other caveats may occur.

I am not a pyramid expert, and if pyramid is an issue to package my web
application in Debian, I may switch to something else...

Thanks

Olivier

-- 


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



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

Re: need DD for package upload

[Olivier Sallou]

- Mail original -
 De: Sandro Tosi mo...@debian.org
 À: Olivier Sallou olivier.sal...@irisa.fr
 Cc: debian-python@lists.debian.org
 Envoyé: Samedi 20 Août 2011 13:13:24
 Objet: Re: need DD for package upload
 On Sat, Aug 20, 2011 at 13:10, Olivier Sallou
 olivier.sal...@irisa.fr wrote:
  I am a DM, so I will maintain the package (DM-Upload set), but I
  need
  someone for the first upload.
 
 That's not exactly how it works: it's the *sponsor* that decides if
 you are able to maintain the package without supervision, and so
 decides to set the DM-allow flag.
 

That's fine for me, I just wanna point that I am in DM ring, so I can maintain 
package afterwards.
I maintain packages in DebianMed (mainly), and I am now used to put the 
DM-Upload tag there.
More a kind of habit :-)

It's true that Upload mechanism is quite different between debian teams. In 
perl team, there is no dm-upload at all...

Regards

Olivier


 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
Archive: 
http://lists.debian.org/20463308.3211076.1313915310662.javamail.r...@zmbs1.inria.fr

can someone upload package python-captcha ?

[Olivier Sallou]

Hi,
package python-captcha (named python-pycaptcha on svn) needs to be uploaded.
I have fixed most lintian warnings and tested the package.

Can a DD take it in its TODO list?


Thanks

Olivier

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



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

need someone to review and upload my package python-pycaptcha

[Olivier Sallou]

Hi,
this is a new try on the list

I need a DD to upload (and review) my package python-pycaptcha.
Everything is available on alioth, and I tested with lintian and pbuilder.

If someone takes the tasks, please tell me.

Thanks

Olivier

-- 

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



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

Re: need someone to review and upload my package python-pycaptcha

[Olivier Sallou]

HI,
thanks for comments I will have a look.
regarding lintian, which command did you run?

I only have:
debiansid:~/DEBIAN-PYTHON/pycaptcha$ lintian python-pycaptcha_0.4-1_all.deb
W: python-pycaptcha: extra-license-file
usr/share/doc/python-pycaptcha/COPYING



Thanks

Olivier

Le 8/10/11 12:33 PM, Jakub Wilk a écrit :
 * Olivier Sallou olivier.sal...@irisa.fr, 2011-08-10, 08:39:
 I need a DD to upload (and review)

 (Hopefully in the reverse order! :P)

 I'm not interested in uploading it, but here's my (cursory) review:

 - Binary package name is wrong; see Python Policy 2.2. Also, I'd use
 the name upstream uses (pycaptcha) for source package name.
 - python-all is needed in the clean target, so in must be in
 Build-Depends, not
 Build-Depends-Indep.[0]
 - Did you intend to use dh_python2? (You currently use python-support
 without build depending on it...)
 - You don't need get-orig-source target if only calls uscan.
 - Use debhelper (= 8) rather than debhelper (= 8.0.0) to ease
 backporting.
 - Remove DEB_PYTHON_INSTALL_ARGS_ALL += ... from your debian/rules,
 it does
 nothing.

 I tested with lintian and pbuilder.

 Oh, did you? :) My lintian complains heavily:

 P: python-pycaptcha: no-upstream-changelog
 I: python-pycaptcha: extended-description-is-probably-too-short
 I: python-pycaptcha: capitalization-error-in-description python Python
 W: python-pycaptcha: image-file-in-usr-lib
 usr/lib/python2.6/dist-packages/Captcha/data/pictures/abstract/1.jpeg
 W: python-pycaptcha: image-file-in-usr-lib
 usr/lib/python2.6/dist-packages/Captcha/data/pictures/abstract/10.jpeg
 W: python-pycaptcha: image-file-in-usr-lib
 usr/lib/python2.6/dist-packages/Captcha/data/pictures/abstract/11.jpeg
 [snip - 27 more image-file-in-usr-lib...]
 W: python-pycaptcha: extra-license-file
 usr/share/doc/python-pycaptcha/COPYING


 [0] Separating B-D and B-D-I is often tricky, and if a package builds
 only arch:all binaries there's only very little benefit from the
 separation. So my general advice is: use only B-D (unless you know
 what you are doing).


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

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



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

Re: need someone to review and upload my package python-pycaptcha

[Olivier Sallou]

Hi,
I have fixed several things on package:

- Now source package is pycaptcha as upstream (though in svn still named
python-pycaptcha, could rename it in svn later on)

- binary is renamed  python-captcha as per module name

 -I use python2 instead of python-support.

Applied other comments.

Only remaining lintian warn is:
W: python-captcha: old-versioned-python-dependency depends: python ( 2.8)

though i use python-all so maybe it is related

Thanks

Olivier

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

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



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

Re: need someone to review and upload my package python-pycaptcha

[Olivier Sallou]

I am on sid and changes file specify unstable distrib

Whatever, package should be ok now (at least from lintian point of view).
If you have other comments, please let me know

Thanks

Olivier

Le 8/10/11 1:21 PM, Piotr Ożarowski a écrit :
 [Olivier Sallou, 2011-08-10]
 Only remaining lintian warn is:
 W: python-captcha: old-versioned-python-dependency depends: python ( 2.8)

 though i use python-all so maybe it is related
 you should develop on Sid

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

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



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

request review and upload for package python-pycatcha

[Olivier Sallou]

Hi,
can someone review and upload the package python-pycatcha? It is in svn.

I ran lintian and pbuilder and everything is ok.

I tried to follow python packaging rules, but I may have forgot
something as I am not a python expert.

Thanks

Olivier

-- 

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



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