Re: Request to join PAPT

[Christopher Hoskin]

Hello,

Is someone able to make me a member of PAPT on Salsa, please?

Thanks.

Christopher

On Wed, 4 Sep 2019 at 20:51, Christopher Hoskin  wrote:
>
> Hello,
>
> Please could I join PAPT in order to maintain a pympress package [1].
> I am a Debian Developer and already a member of DPMT. I have read and
> agreed to [2].
>
> Thanks,
>
> Christopher
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935151
> [2] 
> https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst

Re: Consistent location for library documentation

[Christopher Hoskin]

Thanks - so the policy is that the preference is that documentation is
installed in /usr/share/doc/, but that
/usr/share/doc/-doc is also allowed. The justification
is that the documentation is easier for users to find this way.

dh_installdocs attempts to compute the name of main package by
chopping the -doc off the end of the doc package name in
compute_doc_main_package [1].

So, my question is, have we as a team decided that:

a) We want to install documentation to /usr/share/doc/
not /usr/share/doc/-doc
b) the Python 2 package is the main package and the Python 3 package is not?

It seems to me that when Python2 is dropped, compute_doc_main_package
will no longer be able to compute the main package (because the
python- packages will no longer exist) and existing
python--doc packages which install to
/usr/share/doc/ will be in breach of the policy.

[1] 
https://salsa.debian.org/debian/debhelper/blob/master/lib/Debian/Debhelper/Dh_Lib.pm

Christopher

On 3 March 2018 at 09:56, Scott Kitterman <deb...@kitterman.com> wrote:
> Look at Debian Policy, section 12.3 Additional Documentation.  The answer is
> there.
>
> Scott K
>
> On Saturday, March 03, 2018 09:25:20 AM Christopher Hoskin wrote:
>> Dear Ben,
>>
>> Did you get an answer to this?
>>
>> I've just noticed a change in behavior of dh_installdocs between
>> debhelper compat 10 and 11. With compat 10, documents listed in
>> debian/python--doc.docs (e.g. build/html) would get installed
>> to /usr/share/doc/python--doc/ but with compat 11, they get
>> installed to /usr/share/doc/python-/.
>>
>> >From the dh_installdocs man page it appears dh_installdocs has some
>>
>> logic to auto-detect the main package, which can be overridden with
>> the --doc-main-package option.
>>
>> I'd like to know if dh_installdocs' default is considered correct, or
>> if I should be overriding it?
>>
>> Thanks.
>>
>> Christopher
>>
>> On 16 July 2017 at 05:54, Ben Finney <bign...@debian.org> wrote:
>> > Howdy all,
>> >
>> > Where is the best location for library documentation of a Debian Python
>> > library package?
>> >
>> > Debian Policy §12.3 says:
>> > […] installing the documentation into the documentation directory of
>> > the main package is preferred since it is independent of the
>> > packaging method and will be easier for users to find.
>> >
>> > This is clear enough where a library package ‘libfoo’ is the main
>> > package. The documentation package ‘libfoo-doc’ can install the
>> > documentation to ‘/usr/share/doc/libfoo/’.
>> >
>> >
>> > With the split in Python runtime systems, though, there is commonly not
>> > a single “main package”. Typically there are two, ‘python3-foo’ and
>> > ‘python-foo’.
>> >
>> > The documentation package ‘python-foo-doc’ then has no one obvious place
>> > to install the documentation:
>> >
>> > * Installing to ‘/usr/share/doc/python-foo-doc/’ is discouraged by the
>> >
>> >   above Policy section. I agree that is not necessarily an obvious place
>> >   for a user to look for ‘python3-foo’ documentation.
>> >
>> > * Installing to ‘/usr/share/doc/python-foo/’ or
>> >
>> >   ‘/usr/share/doc/python3-foo/’ is incorrect if the corresponding
>> >   library package is not installed.
>> >
>> > Compounding this is the fact we are (rightly, IMO) moving toward Python
>> > 3 as the primary runtime, and discouraging new Python 2 packages. Is
>> > ‘python3-foo’ then the “main package” by the Policy statement above?
>> >
>> > A symlink could be used, from ‘/usr/share/doc/libfoo-doc’ to
>> > ‘/usr/share/doc/libfoo’. But that still runs into the problem of *which*
>> > package should be assumed.
>> >
>> > And if the documentation package *only* is installed, where should it
>> > install its documentation and symlinks? How should this be done to allow
>> > the library packages to later be installed without changing the
>> > documentation location?
>> >
>> >
>> > I have looked at various documentation and can't see good guidance for a
>> > “one obvious way” to resolve this.
>> >
>> > There is varying practice among packages, and anyway just because some
>> > package does it a particular way doesn't mean I should copy that without
>> > knowing whether it's a good idea.
>> >
>> > What to do?
>> >
>> > --
>> >
>> >  \ “I put contact lenses in my dog's eyes. They had little |
>> >
>> >   `\   pictures of cats on them. Then I took one out and he ran around |
>> >
>> > _o__)  in circles.” —Steven Wright |
>> > Ben Finney
>

Re: Consistent location for library documentation

[Christopher Hoskin]

Dear Ben,

Did you get an answer to this?

I've just noticed a change in behavior of dh_installdocs between
debhelper compat 10 and 11. With compat 10, documents listed in
debian/python--doc.docs (e.g. build/html) would get installed
to /usr/share/doc/python--doc/ but with compat 11, they get
installed to /usr/share/doc/python-/.

>From the dh_installdocs man page it appears dh_installdocs has some
logic to auto-detect the main package, which can be overridden with
the --doc-main-package option.

I'd like to know if dh_installdocs' default is considered correct, or
if I should be overriding it?

Thanks.

Christopher

On 16 July 2017 at 05:54, Ben Finney  wrote:
> Howdy all,
>
> Where is the best location for library documentation of a Debian Python
> library package?
>
> Debian Policy §12.3 says:
>
> […] installing the documentation into the documentation directory of
> the main package is preferred since it is independent of the
> packaging method and will be easier for users to find.
>
> This is clear enough where a library package ‘libfoo’ is the main
> package. The documentation package ‘libfoo-doc’ can install the
> documentation to ‘/usr/share/doc/libfoo/’.
>
>
> With the split in Python runtime systems, though, there is commonly not
> a single “main package”. Typically there are two, ‘python3-foo’ and
> ‘python-foo’.
>
> The documentation package ‘python-foo-doc’ then has no one obvious place
> to install the documentation:
>
> * Installing to ‘/usr/share/doc/python-foo-doc/’ is discouraged by the
>   above Policy section. I agree that is not necessarily an obvious place
>   for a user to look for ‘python3-foo’ documentation.
>
> * Installing to ‘/usr/share/doc/python-foo/’ or
>   ‘/usr/share/doc/python3-foo/’ is incorrect if the corresponding
>   library package is not installed.
>
> Compounding this is the fact we are (rightly, IMO) moving toward Python
> 3 as the primary runtime, and discouraging new Python 2 packages. Is
> ‘python3-foo’ then the “main package” by the Policy statement above?
>
> A symlink could be used, from ‘/usr/share/doc/libfoo-doc’ to
> ‘/usr/share/doc/libfoo’. But that still runs into the problem of *which*
> package should be assumed.
>
> And if the documentation package *only* is installed, where should it
> install its documentation and symlinks? How should this be done to allow
> the library packages to later be installed without changing the
> documentation location?
>
>
> I have looked at various documentation and can't see good guidance for a
> “one obvious way” to resolve this.
>
> There is varying practice among packages, and anyway just because some
> package does it a particular way doesn't mean I should copy that without
> knowing whether it's a good idea.
>
> What to do?
>
> --
>  \ “I put contact lenses in my dog's eyes. They had little |
>   `\   pictures of cats on them. Then I took one out and he ran around |
> _o__)  in circles.” —Steven Wright |
> Ben Finney
>

Re: updating packages

[Christopher Hoskin]

Great, thanks!

What's the plan for moving them to unstable? Are they still using git
pq rather than git-dpm?

Christopher


On 1 August 2017 at 09:22, Michael Fladischer <mich...@fladi.at> wrote:
> Hi guys,
>
> On 2017-07-29 12:48, Christopher Hoskin wrote:
>> I was going to look at updating vine, kombu and python-ampq this
>> weekend, but the upstream tarballs have been signed by a different key
>> pair than the one advertised at:
>>
>> http://docs.celeryproject.org/en/latest/contributing.html#security
>>
>> which makes me reluctant to proceed until the Celery Project confirms
>> that they're using a different key pair.
>
> I checked with upstream on the new signing key[0] and they confirmed it.
>
> amqp, kombu and celery have been updated and uploaded to experimental.
>
> [0] https://github.com/celery/kombu/issues/773
>
> Cheers,
> --
> Michael Fladischer
> Fladi.at

Re: updating packages

[Christopher Hoskin]

> Only has a Python 3 version. Not sure if this matters.
>

As sphinx is used for documentation, even if you're building a python2
package, you can use the python3 sphinx. Build-depends on
python3-sphinx and Build-Conflicts on python-sphinx.

See e.g.

https://anonscm.debian.org/cgit/python-modules/packages/kombu.git?h=debian%2Fexperimental

I was going to look at updating vine, kombu and python-ampq this
weekend, but the upstream tarballs have been signed by a different key
pair than the one advertised at:

http://docs.celeryproject.org/en/latest/contributing.html#security

which makes me reluctant to proceed until the Celery Project confirms
that they're using a different key pair.

Christopher

Re: updating packages

[Christopher Hoskin]

Dear Brian,

sphinx_celery is already packaged as sphinx-celery:

https://packages.qa.debian.org/s/sphinx-celery.html

Christopher

On 3 July 2017 at 23:23, Brian May  wrote:
> Hello,
>
> I have started updating packages, trying to fix Django 1.11 issues where
> applicable, but seem to be running into road blocks for everything I
> try. Have updated git. Help appreciated:
>
> * django-filter, requires djangorestframework.
> * djangorestframework, tests fail, not yet investigated in detail why.
> * celery: requires cyanide (including docs) and sphinx_celery to be packaged 
> in Debian.
>
> Thanks.
> --
> Brian May 
> https://linuxpenguins.xyz/brian/
>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

4.0.2+really3.0.35+dfsg-2 has been accepted into unstable.

Hopefully that sorts this mess out for now.

Thanks for your patience.

Christopher

On 24 March 2017 at 11:22, Christopher Hoskin
<christopher.hos...@gmail.com> wrote:
> Agreed - I didn't know that was an option before. I'll try it this
> evening, unless someone beats me to it.
>
> Thank you for your help.
>
> Christopher
>
> On 24 March 2017 at 11:18, Scott Kitterman <deb...@kitterman.com> wrote:
>>
>>
>> On March 24, 2017 4:30:12 AM EDT, Brian May <b...@debian.org> wrote:
>> ...
>>>Alternative: maybe I should go to the other plan of uploading the old
>>>version of kombu with an increased epoch?
>>
>> Please use newversion+reallyoldverssion instead of an epoch.  It's generally 
>> better to avoid epochs for temporary issues like this.
>>
>> Scott K
>>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

Agreed - I didn't know that was an option before. I'll try it this
evening, unless someone beats me to it.

Thank you for your help.

Christopher

On 24 March 2017 at 11:18, Scott Kitterman  wrote:
>
>
> On March 24, 2017 4:30:12 AM EDT, Brian May  wrote:
> ...
>>Alternative: maybe I should go to the other plan of uploading the old
>>version of kombu with an increased epoch?
>
> Please use newversion+reallyoldverssion instead of an epoch.  It's generally 
> better to avoid epochs for temporary issues like this.
>
> Scott K
>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

I've filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858586

Very sorry about this mess. This is what comes of trying to do
something complex and precise late at night after a long day's work :(

Christopher

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

What worries me is:

apt-rdepends -r python-amqp
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-amqp
  Reverse Depends: python-kombu (>= 3.0.35-1.1)
  Reverse Depends: python-oslo.messaging (>= 5.10.0-2)
python-kombu
  Reverse Depends: murano-agent (>= 1:3.0.0-1)
  Reverse Depends: python-ceilometer (1:7.0.1-1)
  Reverse Depends: python-celery (>= 3.1.23-5)
  Reverse Depends: python-murano (>= 1:3.0.0-2)
  Reverse Depends: python-oslo.messaging (>= 5.10.0-2)
  Reverse Depends: python-taskflow (>= 2.3.0-2)
murano-agent
python-ceilometer
  Reverse Depends: ceilometer-common (= 1:7.0.1-1)
ceilometer-common
  Reverse Depends: ceilometer-agent-central (= 1:7.0.1-1)
  Reverse Depends: ceilometer-agent-compute (= 1:7.0.1-1)
  Reverse Depends: ceilometer-agent-ipmi (= 1:7.0.1-1)
  Reverse Depends: ceilometer-agent-notification (= 1:7.0.1-1)
  Reverse Depends: ceilometer-api (= 1:7.0.1-1)
  Reverse Depends: ceilometer-collector (= 1:7.0.1-1)
ceilometer-agent-central
  Reverse Depends: openstack-proxy-node (0.15)
openstack-proxy-node
  Reverse PreDepends: openstack-toaster (0.15)
openstack-toaster
ceilometer-agent-compute
  Reverse Depends: openstack-compute-node (0.15)
openstack-compute-node
  Reverse PreDepends: openstack-toaster (0.15)
ceilometer-agent-ipmi
ceilometer-agent-notification
ceilometer-api
  Reverse Depends: openstack-proxy-node (0.15)
ceilometer-collector
  Reverse Depends: openstack-proxy-node (0.15)
python-celery
  Reverse Depends: celeryd (= 3.1.23-5)
  Reverse Depends: python-celery-common (= 3.1.23-5)
  Reverse Depends: python-django-celery (>= 3.1.17-4)
  Reverse Depends: python-django-celery-transactions (0.3.6-2)
  Reverse Depends: python-flower (0.8.3+dfsg-1)
celeryd
python-celery-common
python-django-celery
python-django-celery-transactions
  Reverse Depends: python-django-celery-haystack (0.10-1)
python-django-celery-haystack
python-flower
python-murano
  Reverse Depends: murano-common (= 1:3.0.0-2)
murano-common
  Reverse Depends: murano-api (= 1:3.0.0-2)
  Reverse Depends: murano-cfapi (= 1:3.0.0-2)
  Reverse Depends: murano-engine (= 1:3.0.0-2)
murano-api
murano-cfapi
murano-engine
python-oslo.messaging
  Reverse Depends: oslo-messaging-zmq-receiver (= 5.10.0-2)
  Reverse Depends: python-aodh (>= 3.0.0-2)
  Reverse Depends: python-barbican (>= 1:3.0.0-1)
  Reverse Depends: python-ceilometer (>= 1:7.0.1-1)
  Reverse Depends: python-ceilometermiddleware (>= 0.5.0-3)
  Reverse Depends: python-cinder (>= 2:9.0.0-3)
  Reverse Depends: python-congress (>= 4.0.0+dfsg1-3)
  Reverse Depends: python-designate (>= 1:3.0.0-2)
  Reverse Depends: python-glance (>= 2:13.0.0-2)
  Reverse Depends: python-glare (>= 0.1.0-3)
  Reverse Depends: python-heat (>= 1:7.0.0-3)
  Reverse Depends: python-ironic (>= 1:6.2.0-2)
  Reverse Depends: python-keystone (>= 2:10.0.0-6)
  Reverse Depends: python-magnum (>= 3.1.1-2)
  Reverse Depends: python-manila (>= 1:3.0.0-2)
  Reverse Depends: python-mistral (>= 3.0.0-1)
  Reverse Depends: python-murano (>= 1:3.0.0-2)
  Reverse Depends: python-networking-sfc (>= 2.0.1~git20160926.27f311e-1)
  Reverse Depends: python-neutron (>= 2:9.1.1-1)
  Reverse Depends: python-neutron-dynamic-routing (>= 2:9.0.0-1.2)
  Reverse Depends: python-neutron-fwaas (>= 1:9.0.0-3)
  Reverse Depends: python-neutron-lbaas (>= 1:9.1.0-2)
  Reverse Depends: python-neutron-lib (>= 0.4.0-3)
  Reverse Depends: python-neutron-vpnaas (>= 2:9.0.0-3)
  Reverse Depends: python-nova (>= 2:14.0.0-3)
  Reverse Depends: python-oslo.versionedobjects (>= 1.17.0-2)
  Reverse Depends: python-osprofiler (>= 1.4.0-2)
  Reverse Depends: python-sahara (>= 1:5.0.0-2)
  Reverse Depends: python-senlin (>= 2.0.0-2)
  Reverse Depends: python-trove (>= 1:6.0.0-2)
  Reverse Depends: python-watcher (>= 0.30.0-4)
oslo-messaging-zmq-receiver
python-aodh
  Reverse Depends: aodh-common (= 3.0.0-2)
aodh-common
  Reverse Depends: aodh-api (= 3.0.0-2)
  Reverse Depends: aodh-evaluator (= 3.0.0-2)
  Reverse Depends: aodh-expirer (= 3.0.0-2)
  Reverse Depends: aodh-listener (= 3.0.0-2)
  Reverse Depends: aodh-notifier (= 3.0.0-2)
aodh-api
  Reverse Depends: openstack-proxy-node (0.15)
aodh-evaluator
  Reverse Depends: ceilometer-alarm-evaluator (1:7.0.1-1)
  Reverse Depends: openstack-proxy-node (0.15)
ceilometer-alarm-evaluator
aodh-expirer
aodh-listener
aodh-notifier
  Reverse Depends: ceilometer-alarm-notifier (1:7.0.1-1)
  Reverse Depends: openstack-proxy-node (0.15)
ceilometer-alarm-notifier
python-barbican
  Reverse Depends: barbican-common (= 1:3.0.0-1)
barbican-common
  Reverse Depends: barbican-api (= 1:3.0.0-1)
  Reverse Depends: barbican-keystone-listener (= 1:3.0.0-1)
  Reverse Depends: barbican-worker (= 1:3.0.0-1)
barbican-api
barbican-keystone-listener
barbican-worker
python-ceilometermiddleware
python-cinder
  Reverse Depends: cinder-common (= 2:9.0.0-3)
cinder-common
  Reverse Depends: cinder-api (= 2:9.0.0-3)
  Reverse Depends: cinder-backup (= 2:9.0.0-3)
  Reverse 

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

Presumably it will also run into trouble as python-amqp is at 1.4.9 in
unstable, but 2.1.4 from experimental is required.

Christopher

On 23 March 2017 at 21:19, Brian May <b...@debian.org> wrote:
> Christopher Hoskin <christopher.hos...@gmail.com> writes:
>
>> I've made a mistake, and kombu has got uploaded to unstable instead of
>> experimental. (I had experimental in the changelog, but didn't pass
>> "-d experimental" to sbuild on the final build). I'm very sorry about
>> this. What is the best way to resolve this? Should I file a bug
>> against the ftp.debian.org pseudo-package?
>
> I see your changes in the debian/experimental branch. Wondering if it is
> probably best to include them now in master (or debian/master?),
> considering they are now in debian/unstable.
>
> Looks like this change has problems, see #858540. Suspect a missing
> depends on the vine package.
> --
> Brian May <b...@debian.org>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

I've made a mistake, and kombu has got uploaded to unstable instead of
experimental. (I had experimental in the changelog, but didn't pass
"-d experimental" to sbuild on the final build). I'm very sorry about
this. What is the best way to resolve this? Should I file a bug
against the ftp.debian.org pseudo-package?

Thanks, and sorry again.

Christopher

On 20 March 2017 at 13:37, Scott Kitterman <deb...@kitterman.com> wrote:
> On Monday, March 20, 2017 07:28:47 AM Christopher Hoskin wrote:
> ...
>> A Python 2 package for the vine dependency is currently in the NEW queue.
> ...
>
> It was just accepted.
>
> Scott K
>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

Thanks for the feedback. I've pushed my debian/experimental branch of
python-amqp to Alioth [0] and uploaded it to experimental [1].
Hopefully this is what you had in mind. Please let me know if I've
made any mistakes.

A Python 2 package for the vine dependency is currently in the NEW queue.

I'll move on to Kombu next.

Christopher

[0] 
https://anonscm.debian.org/git/python-modules/packages/python-amqp.git?h=debian%2Fexperimental
[1] https://packages.debian.org/source/experimental/python-amqp


On 20 March 2017 at 06:47, Michael Fladischer <mich...@fladi.at> wrote:
> On 2017-03-17 15:53, Christopher Hoskin wrote:
>> Thanks - are you happy for me to remove the Python 2 package?
>>
>> Otherwise I'll need to add Python 2 packages to some of the new dependencies.
>
> I'd like to keep them. Right now popcon indicates that the majority of
> installations is still using python-celery (167) instead of
> python3-celery (6).
>
> Cheers,
> --
> Michael Fladischer
> Fladi.at
>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

Thanks - are you happy for me to remove the Python 2 package?

Otherwise I'll need to add Python 2 packages to some of the new dependencies.

Christopher

On 17 March 2017 at 10:36, Michael Fladischer <mich...@fladi.at> wrote:
> On 2017-03-14 04:48, Christopher Hoskin wrote:
>> Would people be happy for me to start updating Celery and its dependancies,
>> uploading the results to experimental, or should I keep my work to myself for
>> the time being?
>
> Please go ahead with any upload to experimental. I was planning to
> upgrade the whole celery stack after the freeze anyway.
>
> If you need any help, just let me know.
>
> Cheers,
> --
> Michael Fladischer
> Fladi.at
>

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

On 15 March 2017 at 08:45, Brian May  wrote:

> Your changes looks good to me, I have now made them. FYI, I believe
> anybody can create an account and make changes to the wiki.

Thanks. I have a wiki account, but the last time I updated the
Python/GitPackaging page my edit was reverted almost immediately, so I
thought I better check here first ;)

python-amqp depends on vine, but when I previously packaged vine[0], I
only built the python3 package. Is it too soon to start dropping
python2 packages from uploads intended for Buster?

[0] https://packages.debian.org/source/sid/vine

Christopher

Re: Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

Dear Brian,

Thanks. I'm new to gbp pq, but beginning to get the hang of it.

At the end of 
https://wiki.debian.org/Python/GitPackagingPQ#Converting_git-dpm_to_gbp_pq
I think it would probably be a good idea to add instructions to
refresh the patches (and create the patch-queue). Something like:

gbp pq import
gbp pq export
dch -m "Refresh patches after git-dpm to gbp pq conversion"
git add debian/patches/
git add debian/changelog
debcommit

I found all of the patches were updated with the removal of a From: header.

Also, in https://wiki.debian.org/Python/GitPackagingPQ#New_upstream_release
you probably want to add --pristine-tar to the import-orig command.

Thanks for your help!

Christopher

On 14 March 2017 at 04:40, Brian May <br...@linuxpenguins.xyz> wrote:
> On 2017-03-14 14:48, Christopher Hoskin wrote:
>
> For reasons of my own, I need to create a Celery 4.0.2 Debian package. This
> means also updating the Kombu and AMQP packages. As I'm doing this work
> anyway,
> my preference would be to share it with the World through DPMT.
>
> However, I notice that python-amqp has a lot of other reverse dependancies,
> including OpenStack, and that we're currently in a release freeze. I've also
> seen there's been some discussion about using the DEP14 branch/tag
> convention
> and switching to gbp pq.
>
> Would people be happy for me to start updating Celery and its dependancies,
> uploading the results to experimental, or should I keep my work to myself
> for
> the time being?
>
>
> As an uploader for celery, kombu, and python-amqp, I see no problem myself.
> I can't speak for other packages, and definitely I can't speak for packages
> not under DPMT.
>
> For now, I would suggest creating a debian/experimental branch, switching to
> gbp pq (as using non-standard branch names is easier with gbp pq), and then
> continuing. I have done this already for the python-mkdocs package.
>
> If you need any help, let me know.
>
>
>

Updating Celery, Kombu, python-amqp

[Christopher Hoskin]

For reasons of my own, I need to create a Celery 4.0.2 Debian package. This
means also updating the Kombu and AMQP packages. As I'm doing this work anyway,
my preference would be to share it with the World through DPMT.

However, I notice that python-amqp has a lot of other reverse dependancies,
including OpenStack, and that we're currently in a release freeze. I've also
seen there's been some discussion about using the DEP14 branch/tag convention
and switching to gbp pq.

Would people be happy for me to start updating Celery and its dependancies,
uploading the results to experimental, or should I keep my work to myself for
the time being?

Thanks.

Christopher

Moving a package from collab-maint to python-modules

[Christopher Hoskin]

Hello,

I'd like to package python-jsonpointer for Debian. The filer of the RFP (Bug 
#754296) Pietro Battiston, has created a repository at

https://anonscm.debian.org/cgit/collab-maint/python-jsonpointer.git

but has no intention of becoming the maintainer, and the package has not been 
uploaded. The existing repository does not use git-dpm or pristine-tar.

I'd like to maintain this package within DPMT. Is there a way I can migrate the 
existing repository, or should I just start again?

Thanks.

Christopher Hoskin


signature.asc
Description: PGP signature

Re: Naming convention for -doc package

[Christopher Hoskin]

Currently lintian is applying the
new-package-should-not-package-python2-module tag to documentation packages
as well.

I've filed a bug report with a patch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855243

Christopher Hoskin

On 11 February 2017 at 01:51, Ben Finney <bign...@debian.org> wrote:

> Ghislain Vaillant <ghisv...@gmail.com> writes:
>
> > So given your criteria above, you would choose:
> >
> > - python3-pytestqt
> > - python-pytestqt-doc
> >
> > Am I correct?
>
> That allows a future ‘python4-pytestqt’ to use the same documentation.
>
> So far, the overwhelming pattern is that upstream's documentation does
> not come in separate versions for different Python platforms. It's the
> same Py.test QT documentation, regardless of Python version.
>
> The corresponding Debian packages of documentation should not be named
> by any Python version, either.
>
> > Is everyone happy with that?
>
> I am.
>
> --
>  \ “Smoking cures weight problems. Eventually.” —Steven Wright |
>   `\   |
> _o__)  |
> Ben Finney <bign...@debian.org>
>
>

Bug#832970: RFS: txwinrm/1.1.26-1 [ITP]

[Christopher Hoskin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "txwinrm"

 * Package name: txwinrm
   Version : 1.1.26-1
   Upstream Author : Zenoss, Inc. <dbouchil...@zenoss.com>
 * URL : https://github.com/zenoss/txwinrm
 * License : GPL-2
   Section : python

  It builds those binary packages:

python-txwinrm - asynchronous Python WinRM client libraries
 txwinrm- asynchronous Python WinRM client scripts

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/txwinrm


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/t/txwinrm/txwinrm_1.1.26-1.dsc

  More information about hello can be obtained from 
https://github.com/zenoss/txwinrm.

  The package source is under version control on Alioth:

  https://anonscm.debian.org/cgit/python-modules/packages/txwinrm.git


  Regards,
   Christopher Hoskin

Bug#832472: RFS: django-memoize/2.0.0+dfsg-1 [ITP]

[Christopher Hoskin]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

  I am looking for a sponsor for my package "django-memoize"

 * Package name: django-memoize
   Version : 2.0.0+dfsg-1
   Upstream Author : Thadeus Burgess, Thomas Vavrys <tvav...@sleio.com>
 * URL : https://pythonhosted.org/django-memoize/
 * License : BSD-3-clause
   Section : python

  It builds those binary packages:

 python-django-memoize - implementation of memoization technique for Django 
(Python 2)
 python-django-memoize-doc - implementation of memoization technique for Django 
(common documentation)
 python3-django-memoize - implementation of memoization technique for Django 
(Python 3)

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/django-memoize


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/d/django-memoize/django-memoize_2.0.0+dfsg-1.dsc

  More information about django-memoize can be obtained from 
https://pythonhosted.org/django-memoize/.

  The VCS for the package is:

  https://anonscm.debian.org/cgit/python-modules/packages/django-memoize.git/

  Regards,
   Christopher Hoskin

RFS: django-setuptest/0.2.1-1 [ITP]

[Christopher Hoskin]

I have now checked the package into the python-modules Alioth repository:

https://anonscm.debian.org/cgit/python-modules/packages/django-setuptest.git/

Thank you.

Christopher

Request to join team

[Christopher Hoskin]

Hello,

Please can I request to join the Python Modules Team? My Alioth account is
grinorcole-guest.

I have read and agree to the Python Modules Policy.

To date I have only one Python package which is good enough to submit for
consideration:

https://mentors.debian.net/package/django-setuptest

However, I have some more under preparation (pojson, txwinrm,
django-memoize) which I should like to finish off and submit.

Actually, I think my django-setuptest may deviate from the policy in that
both Python 2 and 3 binaries are built. I did this because Sid contains
both Python 2 and 3 Django packages so I assumed that both should be
supported. But perhaps this is not the case?

Thank.

Christopher Hoskin

Bug#803982: ITP: txwinrm - asynchronous Python WinRM client libraries and utilities

[christopher . hoskin]

Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin <christopher.hos...@gmail.com>
X-Debbugs-CC: debian-de...@lists.debian.org,debian-python@lists.debian.org

* Package name: txwinrm
  Version : 1.1.20
  Upstream Author : Zenoss, Inc.
* URL : https://github.com/zenoss/txwinrm/
* License : GPL-2+
  Programming Lang: Python
  Description : asynchronous Python WinRM client libraries and utilities

 txwinrm is a Python library for asynchronously managing Microsoft Windows 
 systems using the WinRM and WinRS services (Microsoft's implementation of the
 WS-Management SOAP protocol). It is developed by Zenoss, Inc. The source also
 includes command line utilities which will be provided in a separate binary
 package.

Bug#796060: ITP: python-pojson -- converts PO files to JSON

[Christopher Hoskin]

Package: wnpp
Owner: Christopher Hoskin christopher.hos...@gmail.com
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-python@lists.debian.org

* Package name: python-pojson
  Version : 0.6
  Upstream Author : Martijn Faassen faas...@startifact.com
* URL : https://pypi.python.org/pypi/pojson
* License : BSD-3-Clause
  Programming Lang: Python
  Description : converts PO files to JSON

 pojson
 **
 .
 pojson is a tool that allows you to create JSON data files from PO
 files. These files are designed to be used with Obviel_'s `i18n support`_.
 .
 * _Obviel: http://obviel.org/
 .
 * _`i18n support`: http://www.obviel.org/en/latest/i18n.html
 .
 The `Javascript Gettext`_ already provides a Perl-based tool (po2json)
 that is very similar, so this can be seen as a rewrite to Python. One
 difference is that pojson does not output domain information in the
 resulting datastructure - it is one level less deep. The domain
 information must instead be supplied when the file is loaded.
 .
 Basic use to generate a JSON file::
 .
   $ pojson path/to/po
 .