Re: [Python-modules-team] RM of shiboken & pyside ?

2016-07-05 Thread Dmitry Shachnev
Hi Didier and Scott,

On July 6, 2016 7:32:22 AM GMT+03:00, Scott Kitterman  
wrote:
> On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote:
> > Hi there,
> > 
> > Now that we have PyOtherSide in Debian, and that both shiboken and
> > PySide are somewhat broken in sid & stretch; what about just
> removing
> > them from Debian ?
> > 
> > I'm not a PySide user myself, and it's abandonned upstream…
> 
> If it's dead, let's remove it.
> 
> Scott K

It is not dead according to Git activity:

https://code.qt.io/cgit/pyside/shiboken.git/
https://code.qt.io/cgit/pyside/pyside.git/

PyOtherSide is a project with different functionality, so having it is not a 
reason for removing PySide. However we have PyQt5, and that can count as such 
reason.

--
Dmitry Shachnev



Re: [Python-modules-team] RM of shiboken & pyside ?

2016-07-05 Thread Scott Kitterman
On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote:
> Hi there,
> 
> Now that we have PyOtherSide in Debian, and that both shiboken and
> PySide are somewhat broken in sid & stretch; what about just removing
> them from Debian ?
> 
> I'm not a PySide user myself, and it's abandonned upstream…

If it's dead, let's remove it.

Scott K



Re: Python package providing both modules and an app

2016-07-05 Thread Thomas Goirand
On 07/05/2016 04:47 PM, Hugo Lefeuvre wrote:
> Hi Thomas,
> 
>> I did lots of that in OpenStack. You can have a look at one of our tool
>> to handle the dh_auto_install for Python:
>>
>> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install
>>
>> The way to use it in your debian/rules file is to do:
>> pkgos-alternative slugify slugify
>>
>> [ this tool is available at:
>> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/misc/pkgos-alternative-bin
>> ]
>>
>> then simply do:
>>
>> override_dh_auto_install:
>>  pkgos-dh_auto_install
>>
>> and that's it, it will handle the /usr/bin/python{3,}-slugify
>> alternative implementations for you.
> 
> That looks very interesting ! 
> 
> However, I have to say I'm a bit reluctant to make the package depend on a 
> supplementary Build-Dependency only in order to prettify debian/rules.

You don't have to do that. You can open pkgos-dh_auto_install, see what
it does, and pickup ideas there. It's only 10 lines of shell scripts,
and you probably don't even need everything that's inside.

Cheers,

Thomas Goirand (zigo)



Re: Removing me from Uploader field of html5lib

2016-07-05 Thread Barry Warsaw
On Jul 04, 2016, at 04:52 PM, Olivier Berger wrote:

>Unfortunately, I'm no longer able to dedicate time to help maintaining
>the html5lib package.

Thanks so much for your past work on it!

>Thus I'm requesting that anyone uploading the next version as part of
>the team, please remove me from the uploaders field.

Done in vcs.  If it's okay with you, I'll hold off doing a new upload until
there's a new upstream.

>Btw, the docs on the wiki documents how to be added/contribue, but not
>really how to stop ;-)

Despite that, you figured it out. :)

Cheers,
-Barry



Re: Python package providing both modules and an app

2016-07-05 Thread Thomas Goirand
On 06/22/2016 09:51 PM, Hugo Lefeuvre wrote:
> Hi Ben,
> 
>>> The package is originally requested as a Python module[2] and it seems 
>>> clear to me that the whole thing is only useful as a library
>>
>> I don't understand this statement. If it is *only* useful as a library,
>> why install the command-line entry point?
> 
> Indeed, I though about that, but python-slugify has been developed as an 
> application[0] so I think it's rather a bad idea to completely ignore the 
> entry point, even if it's not really useful. I think upstream would disagree, 
> too. In my opinion, better build a third package, even if it won't be used
> a lot.

The 3rd package is mandatory if your package needs to store config files.

Cheers,

Thomas



Re: Python package providing both modules and an app

2016-07-05 Thread Thomas Goirand
On 06/21/2016 11:13 PM, Hugo Lefeuvre wrote:
> Hi all !
> 
> I'm currently packaging python-slugify[0], a Python application for
> slugifying unicode strings. Like here[1] upstream decided to write 
> everything as a python module with an entry script placed in /usr/bin
> that calls main(). So we can consider python-slugify as both an application
> and a library.
> 
> The package is originally requested as a Python module[2] and it seems 
> clear to me that the whole thing is only useful as a library, so I've 
> named the source package 'python-slugify'. It provides following packages: 
>  * 'python-slugify' (Python 2 lib), 
>  * 'python3-slugify' (Python 3 lib),
>  * 'slugify' (ships the entry script[3], depends on python3-slugify). 
> 
> Everything is working well. However, I'm not really satisfied by the way I 
> solved the problem in debian/rules[4]. Does anybody know a better way 
> of doing that ?
> 
> Cheers,
>  Hugo

Hugo,

I did lots of that in OpenStack. You can have a look at one of our tool
to handle the dh_auto_install for Python:

http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install

The way to use it in your debian/rules file is to do:
pkgos-alternative slugify slugify

[ this tool is available at:
http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/misc/pkgos-alternative-bin
]

then simply do:

override_dh_auto_install:
pkgos-dh_auto_install

and that's it, it will handle the /usr/bin/python{3,}-slugify
alternative implementations for you.

I hope that helps,
Cheers,

Thomas Goirand (zigo)