Re: Updating Celery, Kombu, python-amqp
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
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
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
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
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
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
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
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
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
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 De
Re: Updating Celery, Kombu, python-amqp
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
On 2017-03-24 08:33, Christopher Hoskin wrote: > 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. Yuck. I guess the options we have available are (without any evaluation or filtering of bad or stupid options): * Try to get Kombu working with older 2.1.4. * Ignore breakage until after freeze. * Upload python-amqp 2.1.4 to unstable (plus anything that this breaks??). * Upload previous Kombu to unstable, using an epoch for the version (and all subsequent uploads). * Upload previous Kombu to unstable, without adjusting version, and watch for automatic rejection email. Take legal action against DAK for the improper rejection. * Hope aliens invade Earth within the next several days, and they can deal with this, while the human race is subject to become slaves for eternity. Any other options?
Re: Updating Celery, Kombu, python-amqp
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 writes: > Looks like this change has problems, see #858540. Suspect a missing > depends on the vine package. Trying to fix this, I notice it also depends on python{,3}-amqp that only exists in experimental :-( -- Brian May
Re: Updating Celery, Kombu, python-amqp
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
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
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
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
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
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
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
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
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
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
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
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 writes: > Thanks. I'm new to gbp pq, but beginning to get the hang of it. 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 for your help! Thanks for your help! -- Brian May
Re: Updating Celery, Kombu, python-amqp
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
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
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