Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Scott Kitterman]

On Friday, May 22, 2015 02:17:59 PM Ian Cordasco wrote:
> On Fri, May 22, 2015 at 10:12 AM, Tristan Seligmann
> 
>  wrote:
> > On 22 May 2015 at 16:06, Tristan Seligmann  
wrote:
> >> Or are you saying that the ipaddress backport is not compatible with
> >> python3 stdlib's ipaddress? (This would be a very unfortunate state of
> >> affairs, but impossible to imagine)
> > 
> > This should have been "*not* impossible", of course.
> 
> Based purely on the fact that the current version of ipaddr is
> undocumented, I would strongly be against any patch to packaged
> software that causes a dependency on it for the sole purpose of
> Debian's packaging of that software. You're asking the maintainers of
> those packages to maintain patches for things that are undocumented.
> In my opinion, Scott, if your'e so adamant about not packaging
> ipaddress for Python 2, you should work with ipaddr to fix things so
> maintainers can reliably maintain the software. Until that is fixed, I
> think Tristan's packaging should move forward so Debian doesn't fall
> too far behind pip.

I don't know what happens on pip.  I know if I do:

>>> import ipaddr
>>> help(ipaddr)

The module documentation is all there exactly like it should be.

I should have a patch today.  You'll certainly have a patch from me faster 
than python-ipaddress will get through New.

Scott K


-- 
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/3841486.q05gmfchXz@kitterma-e6430

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Ian Cordasco]

On Fri, May 22, 2015 at 10:12 AM, Tristan Seligmann
 wrote:
> On 22 May 2015 at 16:06, Tristan Seligmann  wrote:
>> Or are you saying that the ipaddress backport is not compatible with
>> python3 stdlib's ipaddress? (This would be a very unfortunate state of
>> affairs, but impossible to imagine)
>
> This should have been "*not* impossible", of course.

Based purely on the fact that the current version of ipaddr is
undocumented, I would strongly be against any patch to packaged
software that causes a dependency on it for the sole purpose of
Debian's packaging of that software. You're asking the maintainers of
those packages to maintain patches for things that are undocumented.
In my opinion, Scott, if your'e so adamant about not packaging
ipaddress for Python 2, you should work with ipaddr to fix things so
maintainers can reliably maintain the software. Until that is fixed, I
think Tristan's packaging should move forward so Debian doesn't fall
too far behind pip.


-- 
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/CAN-Kwu2fGHqo7=+qj4uox2u4h9nfxzolsnwfxgpgvsf60sf...@mail.gmail.com

Re: Rename package? (Re: Request to join DPMT and RFS: python-simpy/3.0.7-1 [ITA])

[Scott Kitterman]

On Friday, May 22, 2015 07:08:31 PM Dmitry Shachnev wrote:
> Hi,
> 
> On Tue, 19 May 2015 16:51:34 +0200, W. Martin Borgert wrote:
> > In some cases (don't ask me which ones) Debian changes package
> > names on fundamental changes, e.g. from "python-simpy" to
> > "python-simpy3". This allows to update simpy without sudden or
> > unexptected breakage of current packages or even locally
> > installed software. There is no "accidental" upgrade path.
> > 
> > OTOH, I'm not sure whether this effort would be justified in
> > this case. Comments?
> 
> I see that upstream changed the name of Python module from Simpy to
> simpy (lowercase). This means it's quite easy to make them
> co-installable (correct me if I am wrong).
> 
> However, apt tells me that there are only two packages depending
> on anything from python-simpy source:
> 
> - science-economics Recommends: python-simpy
> - mgltools-scenario2 Depends: on python-simpy
> 
> I think with such a little number of rdepends it's easier to port
> them than to carry two packages.

mgltools-scenario2 is non-free.  It's not clear to me that the license allows 
us to modify it.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: pexif package

[Dmitry Shachnev]

Hi,

On Tue, 19 May 2015 10:36:13 -0300, Marcelo Jorge Vieira wrote:
> I am packaging pexif because it is a dependency for Thumbor [0]. My
> question is, pexif has some scripts with generic names [1], like
> 'timezone', should I rename it?
>
> [0] https://github.com/thumbor/thumbor
> [1] https://github.com/bennoleslie/pexif/tree/master/scripts

This package definitely should _not_ ship /usr/bin/timezone.

I see these are just example scripts, can you just install them
to something like /usr/share/pyexif/examples/?

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Re: package-installs-python-bytecode

[Dmitry Shachnev]

Hi Mathieu,

On Wed, 20 May 2015 11:57:26 +0200, Mathieu Malaterre wrote:
> [Please CC me]
>
> I am reviewing some python packages. On my jessie machine here is what
> I am seeing:
>
> $ dget -u 
> http://mentors.debian.net/debian/pool/main/p/python-udiskie/python-udiskie_1.1.2-1.dsc
> $ cd python-udiskie*
> $ dpkg-buildpackage -rfakeroot -us -uc
> $ lintian -I ../python-udiskie_1.1.2-1_amd64.changes
> E: python-udiskie: package-installs-python-bytecode
> usr/lib/python2.7/dist-packages/udiskie/__init__.pyc
> E: python-udiskie: package-installs-python-bytecode
> usr/lib/python2.7/dist-packages/udiskie/automount.pyc
> [...]
> $ dpkg -c ../python-udiskie_1.1.2-1_all.deb | grep pyc | wc
> 14  841413
>
> from any other jessie machine I've access to this warning is not
> present. What do I have on my setup which makes dpkg-buildpackage
> generates *.pyc (or not remove them...).

The package looks correct to me, and I cannot reproduce the bug.

I think the build log (especially the dh_python2 output) will be helpful.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Re: Rename package? (Re: Request to join DPMT and RFS: python-simpy/3.0.7-1 [ITA])

[Dmitry Shachnev]

Hi,

On Tue, 19 May 2015 16:51:34 +0200, W. Martin Borgert wrote:
> In some cases (don't ask me which ones) Debian changes package
> names on fundamental changes, e.g. from "python-simpy" to
> "python-simpy3". This allows to update simpy without sudden or
> unexptected breakage of current packages or even locally
> installed software. There is no "accidental" upgrade path.
>
> OTOH, I'm not sure whether this effort would be justified in
> this case. Comments?

I see that upstream changed the name of Python module from Simpy to
simpy (lowercase). This means it's quite easy to make them
co-installable (correct me if I am wrong).

However, apt tells me that there are only two packages depending
on anything from python-simpy source:

- science-economics Recommends: python-simpy
- mgltools-scenario2 Depends: on python-simpy

I think with such a little number of rdepends it's easier to port
them than to carry two packages.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On 22 May 2015 at 16:06, Tristan Seligmann  wrote:
> Or are you saying that the ipaddress backport is not compatible with
> python3 stdlib's ipaddress? (This would be a very unfortunate state of
> affairs, but impossible to imagine)

This should have been "*not* impossible", of course.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMT=dhk-uds2mniuf-ut-cxwlg1+ckih3zyetqdeeic...@mail.gmail.com

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Scott Kitterman]

On May 22, 2015 10:06:34 AM EDT, Tristan Seligmann  
wrote:
>On 22 May 2015 at 15:43, Donald Stufft  wrote:
>> I'm not sure if I was looking at the wrong ipaddr or something but
>the
>> documentation I found was pretty crappy and looking at it I didn't
>see how to
>> actually use ipaddr the same way I was using ipaddress in pip. In
>addition to
>> that, the API doesn't really look the same as the ipaddress to me so
>it's going
>> to require some sort of compatability shim maintained in pip in order
>to be
>> able to run one module on Python 2 and another module on Python 3.
>
>If you're talking about the documentation linked to from PyPI (at
>), the problem is just that the
>documentation is for an ancient version of ipaddr. I was also thrown
>off by this originally, but if you look at an actually-recent version
>of ipaddr, the API seems to be the same (or at least very similar, I
>didn't look into it in detail so there may be differences in
>unicode/bytes handling, although I hope not).
>
>On the other hand, if upstream software is going to use ipaddress, it
>really doesn't seem like Debian's place to patch everything to use
>ipaddr.

There are far more users of ipaddr than ipaddress.  There's exactly two API 
differences.  I'm willing to look at pip and propose a patch to work with 
either. 

>On 22 May 2015 at 03:50, Scott Kitterman  wrote:
>> I'm also concerned that because of type processing differences
>(strings versus
>> bytes and UTF-8 by default versus not) there is potential for subtle
>> incompatibilities in the backported ipaddress.  I had complaints on
>an
>> upstream project that uses ipaddress with python3 when it was
>available
>> failing with ipaddress in python2.
>
>I don't quite follow this. If ipaddr isn't compatible with ipaddress,
>then the claim that you can simply import ipaddr instead of ipaddress
>is obviously not true for software that is currently using ipaddress.
>On the other hand, if they are compatible, then having ipaddress
>installed shouldn't break anything regardless of whether it imports
>ipaddress or ipaddr.
>
>Or are you saying that the ipaddress backport is not compatible with
>python3 stdlib's ipaddress? (This would be a very unfortunate state of
>affairs, but impossible to imagine)

Keep in mind that ipaddr came first and became ipaddress in python3.3.  My 
experience was that for my use case there were problems with the backport that 
don't occur with ipaddr. I don't recall the details as I considered ipaddress 
on python2 an unsupported configuration and didn't investigate in great detail. 

Scott K


-- 
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/8077d3bd-4e1b-4711-9699-f419e3e6a...@kitterman.com

Re: Bug#786238: pycaml: deprecation of python-support

[Stéphane Glondu]

Le 20/05/2015 18:36, dktrkr...@debian.org a écrit :
> your package either build-depends or depends on the python-support
> package, or uses dh_pysupport in debian/rules file.

I have the feeling that that dependency is useless. pycaml doesn't
provide any Python module (it provides an OCaml module that links to
libpython). Therefore, I could just drop the dependency (and not depend
on dh-python). Am I right?

Cheers,

-- 
Stéphane


-- 
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/555f3e48.6000...@debian.org

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Tristan Seligmann]

On 22 May 2015 at 15:43, Donald Stufft  wrote:
> I'm not sure if I was looking at the wrong ipaddr or something but the
> documentation I found was pretty crappy and looking at it I didn't see how to
> actually use ipaddr the same way I was using ipaddress in pip. In addition to
> that, the API doesn't really look the same as the ipaddress to me so it's 
> going
> to require some sort of compatability shim maintained in pip in order to be
> able to run one module on Python 2 and another module on Python 3.

If you're talking about the documentation linked to from PyPI (at
), the problem is just that the
documentation is for an ancient version of ipaddr. I was also thrown
off by this originally, but if you look at an actually-recent version
of ipaddr, the API seems to be the same (or at least very similar, I
didn't look into it in detail so there may be differences in
unicode/bytes handling, although I hope not).

On the other hand, if upstream software is going to use ipaddress, it
really doesn't seem like Debian's place to patch everything to use
ipaddr.

On 22 May 2015 at 03:50, Scott Kitterman  wrote:
> I'm also concerned that because of type processing differences (strings versus
> bytes and UTF-8 by default versus not) there is potential for subtle
> incompatibilities in the backported ipaddress.  I had complaints on an
> upstream project that uses ipaddress with python3 when it was available
> failing with ipaddress in python2.

I don't quite follow this. If ipaddr isn't compatible with ipaddress,
then the claim that you can simply import ipaddr instead of ipaddress
is obviously not true for software that is currently using ipaddress.
On the other hand, if they are compatible, then having ipaddress
installed shouldn't break anything regardless of whether it imports
ipaddress or ipaddr.

Or are you saying that the ipaddress backport is not compatible with
python3 stdlib's ipaddress? (This would be a very unfortunate state of
affairs, but impossible to imagine)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
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/CAMcKhMT5mci=eH==fcUOX8zLfq53REoAJxPdt3V+AeC+7_=t...@mail.gmail.com

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

[Donald Stufft]

> On May 21, 2015, at 9:50 PM, Scott Kitterman  wrote:
> 
> On Friday, May 22, 2015 12:34:02 AM Brian May wrote:
>> On Fri, 22 May 2015 at 07:14 Scott Kitterman  wrote:
>>> I was considering the idea of porting things from ipaddr to ipaddress for
>>> python2, but there's a lot more of that then there is for ipaddress (which
>>> is
>>> up to only two packages we know about).
>> 
>> As it is a goal to have everything Python3 compliant, and as Jessie no
>> longer has python3-ipaddr (it was in wheezy), everything is going to have
>> to support ipaddress for python3 anyway.
>> 
>> I don't see why we don't drop python-ipaddr, and replace it with
>> python-ipaddress.
> 
> I dropped python3-ipaddr once python3.3 was default since it comes with
> ipaddress.  For python3, everthing should use ipaddress.
> 
> At some point it might make sense to switch.  There's about 20 packages in the
> archive that use python-ipaddr versus none with one or two candidates using
> python-ipaddress in python2.  Porting two is easier than porting 20.
> 
> I'm also concerned that because of type processing differences (strings versus
> bytes and UTF-8 by default versus not) there is potential for subtle
> incompatibilities in the backported ipaddress.  I had complaints on an
> upstream project that uses ipaddress with python3 when it was available
> failing with ipaddress in python2.
> 
> Scott K
> 
> 
> --
> 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/2512839.pZrC1BOzKj@kitterma-e6430
> 

I released pip 7 last night, as part of that I looked at switching from
ipaddress to ipaddr as a favor to Barry to try and help him get the new pip
into Debian. I've never used the ipaddr library before so I was flying blind
with it.

I'm not sure if I was looking at the wrong ipaddr or something but the
documentation I found was pretty crappy and looking at it I didn't see how to
actually use ipaddr the same way I was using ipaddress in pip. In addition to
that, the API doesn't really look the same as the ipaddress to me so it's going
to require some sort of compatability shim maintained in pip in order to be
able to run one module on Python 2 and another module on Python 3.

Given all of that and the fact I didn't feel like spending a bunch of time
going down a rathole to switch dependencies when we already had a perfectly
reasonable dependency that handled it I went ahead and just released pip 7 with
the ipaddress dependency still.

I'm not entirely sure why that's an unreasonable dependency here, it has a
different name than ipaddr does, at least in the PyPI modules, so it should be
entirely possible to have them both installed side by side without any
conflicts.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

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