Re: Updating Celery, Kombu, python-amqp

[Thomas Goirand]

On 03/24/2017 09:30 AM, Brian May wrote:
> So if we upgrade python-amqp *and* that (worse case) requires
> python-oslo.messaging be upgraded too, that is a lot of packages (listed
> below) that *directly* depend on python-oslo.messaging. Eventually we
> will have to deal with this, maybe during the freeze isn't a good time?
> 
>> 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)
> 
> Alternative: maybe I should go to the other plan of uploading the old
> version of kombu with an increased epoch?

Upgrading all of the above is absolutely not possible. I see that it was
uploaded with 4.0.2+really3.0.35+dfsg-2 which was the correct thing to
do. Thanks!

Cheers,

Thomas Goirand (zigo)

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

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

[Scott Kitterman]

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

[Brian May]

Michael Fladischer  writes:

> This seems to be the best way to deal with this. I don't think that
> python-amqp 2.x should be uploaded to unstable as it would potentially
> break a lot of things in OpenStack.

I will wait a little bit in case there is a response to
https://bugs.debian.org/858586, however I tend to think this might be
the best way forward.
-- 
Brian May 

Re: Updating Celery, Kombu, python-amqp

[Brian May]

Christopher Hoskin  writes:

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

I can't complain. I have also accidentally uploaded to unstable instead
of experimental for the same reason. IIRC I didn't understand how the
sbuild options worked. I have now put a check in my build scripts to
prevent this type of mistake happening.

I strongly recommend to use dput-ng, it will stop this kind of
mistake. I just checked this to make sure:

% dput -s ftp-master python-mkdocs_0.16.1-1_i386.changes
Not uploading for real - dry run
Uploading python-mkdocs using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
Upload is targeting experimental but the changes will hit unstable
Upload is targeting `experimental', but the changes will hit `unstable'.
Looks like you forgot -d experimental when invoking sbuild.

Although I used the -s option (I don't won't to risk making the same
error!), I believe if I didn't, it wouldn't let me upload this package
anyway.
-- 
Brian May 

Re: Updating Celery, Kombu, python-amqp

[Michael Fladischer]

On 2017-03-24 03:55, Brian May wrote:
> * Upload previous Kombu to unstable, using an epoch for the version (and
> all subsequent uploads).

This seems to be the best way to deal with this. I don't think that
python-amqp 2.x should be uploaded to unstable as it would potentially
break a lot of things in OpenStack.

Cheers,
-- 
Michael Fladischer
Fladi.at



signature.asc
Description: OpenPGP digital signature

Re: Updating Celery, Kombu, python-amqp

[Brian May]

Christopher Hoskin  writes:

> What worries me is:
>
> apt-rdepends -r python-amqp

I wasn't aware of this command. Thanks for this.

If I understand this command correctly, it is showing everything that
depends directly and indirectly on python-amqp?

Hmm. Looks like a large number of these are due to
python-oslo.messaging. So can't use the argument that the update to
python-kombu has already broken these.

So if we upgrade python-amqp *and* that (worse case) requires
python-oslo.messaging be upgraded too, that is a lot of packages (listed
below) that *directly* depend on python-oslo.messaging. Eventually we
will have to deal with this, maybe during the freeze isn't a good time?

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

Alternative: maybe I should go to the other plan of uploading the old
version of kombu with an increased epoch?
-- 
Brian May 

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

[Brian May]

Brian May  writes:

> * Upload python-amqp 2.1.4 to unstable (plus anything that this
> breaks??). 

I an inclined to think this might be the best option. There are only two
packages that depend on python-amqp - that I can see anyway, and one of
them is python-kombu.

# apt-cache rdepends python-amqp
python-amqp
Reverse Depends:
  python-oslo.messaging
  python-kombu
  python-kombu
  python-kombu
  python-kombu
  python-oslo.messaging

Any objections to uploading the experimental version of python-amqp into
unstable?
-- 
Brian May 

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  wrote:
> Christopher Hoskin  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 

Re: Updating Celery, Kombu, python-amqp

[Brian May]

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

Re: Updating Celery, Kombu, python-amqp

[Brian May]

Christopher Hoskin  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?

Is this upload likely to break anything in unstable?

If not, I wouldn't worry too much about it. Might make things a little
bit harder in the unlikely case a update is required for testing, but
not impossible.

(am assuming it has already entered the archive, or is going to very
soon)
-- 
Brian May 

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

[Scott Kitterman]

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

[Michael Fladischer]

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



signature.asc
Description: OpenPGP digital signature

Re: Updating Celery, Kombu, python-amqp

[Thomas Goirand]

On 03/15/2017 09:56 PM, Christopher Hoskin wrote:
> 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?

python-amqp is used by python-oslo.messaging, which is one of the key
components of OpenStack. OpenStack eventually will drop Python 2
support, though this may happen over the next 6 to 12 months only.
Mostly everything is ready, though some components are still not fully
Py3 compatible.

So yeah, in this case, it is a little bit too soon to drop Python 2.
Hopefully, we will be able to do that before Buster.

Cheers,

Thomas Goirand (zigo)

Re: Updating Celery, Kombu, python-amqp

[Scott Kitterman]

On Saturday, March 18, 2017 05:58:49 PM Brian May wrote:
> Christopher Hoskin  writes:
> > 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?
> 
> I am hardly any authoritative source for this team, but I don't see any
> problems.
> 
> Just need to be mindful of anything that depends or build depends on the
> python-* on the package you are removing - if you break a large number
> of packages (including cascading breakages), maybe not worth it. Just
> yet anyway.
> 
> Or maybe if one of the packages is a highly popular package, might want
> to exercise a bit more caution. I don't think the packages mentioned so
> far count.

I would be inclined not to drop python2 packages.  While it may be fine for 
what's in the archive, there are huge swaths of project code that have not 
been migrated to python3.  I don't see any rush to remove stuff.

If you need to add a python package to support this, feel free to ping me and 
I'll give it a quick review through New.

Scott K

Re: Updating Celery, Kombu, python-amqp

[Brian May]

Christopher Hoskin  writes:

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

I am hardly any authoritative source for this team, but I don't see any
problems.

Just need to be mindful of anything that depends or build depends on the
python-* on the package you are removing - if you break a large number
of packages (including cascading breakages), maybe not worth it. Just
yet anyway.

Or maybe if one of the packages is a highly popular package, might want
to exercise a bit more caution. I don't think the packages mentioned so
far count.
-- 
Brian May 

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

[Michael Fladischer]

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



signature.asc
Description: OpenPGP digital signature

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

Re: Updating Celery, Kombu, python-amqp

[Brian May]

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.