Dealing with zope.interface unsatisfiable build-dependency.
zope.interface is currently rc buggy because of an unsatisfiable build-depenency on python-zope.event, the package is also orphaned. The package is a key package, so the issue won't be dealt with by autoremovals, furthermore the python-zope.interface package has quite a stack of reverse dependencies, so dropping it doesn't seem like a good option at this point. Testing reveals that the build-dependency in question is only needed by the test suite, so I believe the least-bad option is to drop the build-dependency and not run the testsuite. It would be preferable to only disable the testsuite for python2, but I have no idea how to do that, so my current debdiff disables the testsuite completely, I also ran into an issue with the package's clean target not cleaning up properly. If anyone can suggest how to modify the package so it runs the testsuite for python3 but not python2 that would be appreciated. I plan to go ahead with an upload next week. diff -Nru zope.interface-4.6.0/debian/changelog zope.interface-4.6.0/debian/changelog --- zope.interface-4.6.0/debian/changelog 2019-09-05 11:09:40.0 + +++ zope.interface-4.6.0/debian/changelog 2019-12-07 07:00:43.0 + @@ -1,3 +1,13 @@ +zope.interface (4.6.0-2) unstable; urgency=medium + + * QA upload. + * Drop build-dependency on nonexistent python-zope.event. Downgrades: #938909. + * Disable testsuite, it needs python-zope.event. + * Fix clean target. + * Add build-depends on moreutils, needed by fixed clean target. + + -- Peter Michael Green Sat, 07 Dec 2019 07:00:43 + + zope.interface (4.6.0-1) unstable; urgency=medium * QA upload. diff -Nru zope.interface-4.6.0/debian/control zope.interface-4.6.0/debian/control --- zope.interface-4.6.0/debian/control 2019-09-05 11:09:40.0 + +++ zope.interface-4.6.0/debian/control 2019-12-07 07:00:43.0 + @@ -12,11 +12,11 @@ python-all-dbg:any, python-all-dev:any, python-setuptools, - python-zope.event, python3-all-dbg:any, python3-all-dev:any, python3-setuptools, - python3-zope.event + python3-zope.event, + moreutils Standards-Version: 4.4.0 Testsuite: autopkgtest Homepage: http://pypi.python.org/pypi/zope.interface diff -Nru zope.interface-4.6.0/debian/rules zope.interface-4.6.0/debian/rules --- zope.interface-4.6.0/debian/rules 2016-07-05 21:43:11.0 + +++ zope.interface-4.6.0/debian/rules 2019-12-07 07:00:43.0 + @@ -97,3 +97,10 @@ override_dh_strip: dh_strip -p$(package) --dbg-package=$(package)-dbg dh_strip -p$(package3) --dbg-package=$(package3)-dbg + +override_dh_auto_test: + echo testsuite disabled + +override_dh_auto_clean: + rm -f .eggs/README.txt + rm -f src/zope.interface.egg-info/requires.txt
Re: Merge Requests
On Fri, 06 Dec 2019, Louis-Philippe Véronneau wrote: > On 19-12-06 04 h 34, Jonathan Carter wrote: > > For other MRs, I noticed that many small changes in the packaging didn't > > have an associated changelog entry with it, so I had to dch to add a > > changelog entry. I think for small changes I'd prefer the person who > > submits the MR to add them. For larger ones it probably makes sense not > > to do that since it might take longer. > > I rarely add a changelog entry when creating MRs, as I feel it often is > a burden for the maintainers if the MR isn't immediately merged and new > releases are made (creates merge conflicts, etc.). And it's also painful when you use "gbp dch", having a commit in the middle introduce a changelog entry means that the next "gbp dch" run might miss some commits that need to be documented. Not everybody is sold to the idea of using "gbp dch" but it's definitely cleaner IMO. Commits that do not modify debian/changelog are also easier to cherry-pick between different branches, etc. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Merge Requests
On 19-12-06 04 h 34, Jonathan Carter wrote: > For other MRs, I noticed that many small changes in the packaging didn't > have an associated changelog entry with it, so I had to dch to add a > changelog entry. I think for small changes I'd prefer the person who > submits the MR to add them. For larger ones it probably makes sense not > to do that since it might take longer. I rarely add a changelog entry when creating MRs, as I feel it often is a burden for the maintainers if the MR isn't immediately merged and new releases are made (creates merge conflicts, etc.). -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Re: Merge Requests
It looks like a lot of this is lintian-brush generated and of questionable value, IMO. As an example, bumping compat to 12 is trivial to do. The hard part is checking if it affects the package content, so the bot has produced a proposed change that will take far longer to verify than it would to produce. If I had time to do the checking, I don't need a merge request for the trivial bit of changing one number. I'd caution against just accepting such changes without careful review. Scott K On December 6, 2019 9:34:59 AM UTC, Jonathan Carter wrote: >Hey debian python team > >We currently have a few merge requests open: > >== tools == > >Count: 6 > >https://salsa.debian.org/groups/python-team/tools/-/merge_requests > >== papt == > >Count: 8 > >https://salsa.debian.org/groups/python-team/applications/-/merge_requests > >== dpmt == > >Count: 31 > >https://salsa.debian.org/groups/python-team/modules/-/merge_requests > > >I merged a bunch of trivial ones yesterday, but even then it seems like >we have some problems which might need some update in our policy in >dealing with merge requests. > >I noticed that one MR fixed some typos but did it in the upstream >source >directly, which isn't all that useful to us. > >For other MRs, I noticed that many small changes in the packaging >didn't >have an associated changelog entry with it, so I had to dch to add a >changelog entry. I think for small changes I'd prefer the person who >submits the MR to add them. For larger ones it probably makes sense not >to do that since it might take longer. > >Any suggestions? How about we draft some MR policy in gobby and get it >added to the PAPT/DPMT policies? > >-Jonathan
Merge Requests
Hey debian python team We currently have a few merge requests open: == tools == Count: 6 https://salsa.debian.org/groups/python-team/tools/-/merge_requests == papt == Count: 8 https://salsa.debian.org/groups/python-team/applications/-/merge_requests == dpmt == Count: 31 https://salsa.debian.org/groups/python-team/modules/-/merge_requests I merged a bunch of trivial ones yesterday, but even then it seems like we have some problems which might need some update in our policy in dealing with merge requests. I noticed that one MR fixed some typos but did it in the upstream source directly, which isn't all that useful to us. For other MRs, I noticed that many small changes in the packaging didn't have an associated changelog entry with it, so I had to dch to add a changelog entry. I think for small changes I'd prefer the person who submits the MR to add them. For larger ones it probably makes sense not to do that since it might take longer. Any suggestions? How about we draft some MR policy in gobby and get it added to the PAPT/DPMT policies? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
