Re: RFS: python-patch 1.16
On Tue, Nov 29, 2016 at 08:20:23AM +0100, Paolo Greppi wrote: > Hi, Hi! FYI, I found your RFS only thanks to the /topic in #debian-python. Unless you're very lucky most RFSes sent to random mailing lists have a tendency to get lost/ignored; that's why I suggest you always file a RFS bug and X-Debbugs-CC the relevant team, unless you know that team is going to react (like pkg-js recently). > I packaged python-patch as per this ITP: > https://bugs.debian.org/845482, this is the repo: > https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git > > Please someone more experienced than me review it and if it's OK sponsor > its upload. I fixed the file name in the pristine-tar branch (otherwise `origtargz` ignored it..). > Please note that since the pypi tarball has no tests, whereas the github > tarball has no setup, I choose the latter and added the setup.py with a > git-dpm/quilt patch. I hope this is correct. Yep, that's fine. Please ask upstream to syncronize both, and have github ship the setup.py, and the tarball the release. more changes I ask you: * d/changelog: + please kill the second changelog line; first uploads should only come with a "first upload" line + finalize it (dch -r) * d/control: + please wrap-and-sort that list of build-deps + why are you commenting out the Testsuite field? + Vcs-* are pointing to a repo that's not DPMT's, that's wrong (furthermore that URL first requires auth, and it gave me a 404, so I think it's a private repo) * d/compat: + please bump to 10 (d/control already have the >= 10, so I guess you just forgot to push this one too) * d/rules: + please repspect DEB_BUILD_OPTIONS=nocheck + please use the method provided by pybuild to properly run the tests against all supported python versions, against what you just "built"; I think that one runs only one python version (2.7) against the original sources. + you're overriding dh_auto_install when you only want to append --install-script to the command invoked. Please use PYBUILD_INSTALL_ARGS=--install-scripts=... instead. * d/copyright: + why are you licensing debian/ under a different license? + personally I find a lot more readable to have all the file paragraph at the top, and all stand alone licenses at the bottom + other/pack.py is under another license * I: python-patch: new-package-should-not-package-python2-module python-patch + right, I was about to forget about this... * I: python-patch source: binary-control-field-duplicates-source field "section" in package python-patch -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]
Le mardi 27 décembre 2016 à 22:11:38+, Sean Whitton a écrit : > Hello Pierre, > > On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote: > > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit : > > > control: tag -1 +moreinfo > > > > > > Dear Pierre, > > > > > > Thank you for your interest in adopting this package. > > > > > > Unfortunately, your work has not been properly integrated with what is > > > already in Debian: > > > > > > - you marked version 0.4.74-4 as released but it was never uploaded > > > > True. Yet, it is in the team repo. > > The changelog tracks the Debian archive. You should merge the existing > 0.4.74-4 changelog entry with your changes. 0.4.74-4 is not in the debian archive, only in the team repo. How should I merge exactly? > > > > Actually, it is included. The commit is just hidden in the history of the > > team git repository for an unknown reason. See commit > > 53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit > > 6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog > > that has been truncated in the merge. > > Sorry, my fault, thanks for fixing up the changelog in your upload. No worries, you're welcome. :) > > > - your work is not pushed to the team git repository > > > > I have no permission to push. > > Have you asked to join the team? I don't feel that I've done enough to get permissions, maybe my interpretation is wrong. -- PEB signature.asc Description: PGP signature
Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]
Hello Pierre, On Thu, Dec 29, 2016 at 09:20:02PM +0100, Pierre-Elliott Bécue wrote: > Le mardi 27 décembre 2016 à 22:11:38+, Sean Whitton a écrit : > > Hello Pierre, > > > > On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote: > > > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit : > > > > control: tag -1 +moreinfo > > > > > > > > Dear Pierre, > > > > > > > > Thank you for your interest in adopting this package. > > > > > > > > Unfortunately, your work has not been properly integrated with what is > > > > already in Debian: > > > > > > > > - you marked version 0.4.74-4 as released but it was never uploaded > > > > > > True. Yet, it is in the team repo. > > > > The changelog tracks the Debian archive. You should merge the existing > > 0.4.74-4 changelog entry with your changes. > > 0.4.74-4 is not in the debian archive, only in the team repo. How should I > merge exactly? This is roughly what I have in mind: pyvtk (0.5.18-1) unstable; urgency=low [ Jakub Wilk ] * Use canonical URIs for Vcs-* fields. * Remove obsolete Conflicts/Replaces with python2.3-pyvtk and python2.4-pyvtk. [ Stefano Rivera ] * Convert inline patch to 3.0 (quilt) to ease git-dpm migration. [ Ondřej Nový ] * Fixed VCS URL (https) [ Pierre-Elliott Bécue ] * New maintainer (Closes: #795017). * New upstream release * Uses pybuild for building the package. * Cleaning debian/* -- Pierre-Elliott Bécue Sat, 17 Dec 2016 00:24:15 +0200 > > > > - your work is not pushed to the team git repository > > > > > > I have no permission to push. > > > > Have you asked to join the team? > > I don't feel that I've done enough to get permissions, maybe my > interpretation is wrong. I see what you mean, and every Debian team is different. However, chances are they would prefer that you join the team and push your git history there, as then other team members can more easily build upon your work. So please submit a request, explaining that you want to work on pyvtk. If they say no, it's not a big deal! -- Sean Whitton signature.asc Description: PGP signature
Python 2 in the default installation -- progress made!
Hi everyone, one of the objectives for stretch was to reduce the number of Python 2 packages that are installed in common scenarios, instead having the Python 3 stack take over. The "standard task" within tasksel is a reasonable place to look.¹ Thanks to the recent work on reportbug and debianbts, this is now largely complete. In a stretch chroot, install the standard task:² # aptitude install ~prequired ~pimportant ~pstandard and the only python packages installed are: # aptitude search ~npython~i i A dh-python i A libpython-stdlib i A libpython2.7 i A libpython2.7-minimal i A libpython2.7-stdlib i A libpython3-stdlib i A libpython3.5-minimal i A libpython3.5-stdlib i python i python-apt i A python-apt-common i python-gpg i python-minimal i python2.7 i A python2.7-minimal i A python3 i A python3-apt i A python3-chardet i A python3-debian i A python3-debianbts i python3-gpg i A python3-httplib2 i A python3-minimal i A python3-pkg-resources i A python3-pycurl i A python3-pysimplesoap i python3-reportbug i A python3-requests i A python3-six i A python3-urllib3 i A python3.5 i A python3.5-minimal where the packages marked "A" (Automatically Installed) are there to satisfy dependencies only. We see that: python python-apt python-gpg python-minimal python2.7 are now only installed because they are marked as Priority: standard. Question for discussion: Is Python 2 a tool that would be expected to be found on any linux machine and so should it be Priority: standard? Is Python 3? Is now the time to ask ftp-masters to change the overrides to move them to Priority: optional? (My personal feeling is that none of the above packages should be Priority: standard, including Python 3) The libpython2.7* packages are present because: i logrotate Recommends mailx i A mailutils Provides mailx i A mailutils Dependslibpython2.7 (>= 2.7) I don't know if mailutils can already use Python 3 instead of Python 2 or how it is actually using Python at all -- the build system will certainly need some work. Perhaps a keen Python 3 porter can investigate that as an opening move for stretch+1 (it's too late for stretch for that transition). cheers Stuart ① The standard task contains packages you'd expect to find on a linux machine such as `less`; yes, it also includes a mail-transport-agent and it probably shouldn't; no, let's not discuss that now. ② Unlike other tasks, the standard task is not defined as a list of packages but as this aptitude search pattern to find all packages that declare Priority: required, important or standard; aptitude will also then install packages of lower priority to satisfy the dependencies. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Python 2 in the default installation -- progress made!
On 30.12.2016 05:41, Stuart Prescott wrote: > > Hi everyone, > > one of the objectives for stretch was to reduce the number of Python 2 > packages that are installed in common scenarios, instead having the Python 3 > stack take over. The "standard task" within tasksel is a reasonable place to > look.¹ > > Thanks to the recent work on reportbug and debianbts, this is now largely > complete. > > In a stretch chroot, install the standard task:² > > # aptitude install ~prequired ~pimportant ~pstandard > > and the only python packages installed are: > > # aptitude search ~npython~i > i A dh-python > i A libpython-stdlib > i A libpython2.7 > i A libpython2.7-minimal > i A libpython2.7-stdlib > i A libpython3-stdlib > i A libpython3.5-minimal > i A libpython3.5-stdlib > i python > i python-apt > i A python-apt-common > i python-gpg > i python-minimal > i python2.7 > i A python2.7-minimal > i A python3 > i A python3-apt > i A python3-chardet > i A python3-debian > i A python3-debianbts > i python3-gpg > i A python3-httplib2 > i A python3-minimal > i A python3-pkg-resources > i A python3-pycurl > i A python3-pysimplesoap > i python3-reportbug > i A python3-requests > i A python3-six > i A python3-urllib3 > i A python3.5 > i A python3.5-minimal > > where the packages marked "A" (Automatically Installed) are there to satisfy > dependencies only. > > We see that: > > python > python-apt > python-gpg > python-minimal > python2.7 > > are now only installed because they are marked as Priority: standard. > > > Question for discussion: Is Python 2 a tool that would be expected to be > found > on any linux machine and so should it be Priority: standard? Is Python 3? Is > now the time to ask ftp-masters to change the overrides to move them to > Priority: optional? I think it's time to move these to optional, and bump the priority of the equivalent python3 packages. Should be done in the packages as well. > (My personal feeling is that none of the above packages should be Priority: > standard, including Python 3) I don't know the rationale for having the apt and gpg bindings as Priority standard, but if these can be made optional, then the depending packages can be made optional as well. > The libpython2.7* packages are present because: > > i logrotate Recommends mailx > i A mailutils Provides mailx > i A mailutils Dependslibpython2.7 (>= 2.7) > > I don't know if mailutils can already use Python 3 instead of Python 2 or how > it is actually using Python at all -- the build system will certainly need > some work. Perhaps a keen Python 3 porter can investigate that as an opening > move for stretch+1 (it's too late for stretch for that transition). while the code has some comments about python 3.0 it fails in the configury and later building the extensions, so apparently it's not used, and not tested with recent python3 versions. I filed #849721 for that. Otoh, logrotate could explicitly recommend bsd-mailx | mailx to avoid that dependency. I would prefer having stretch shipping with only one Python version in the base task. Matthias
