Re: upstream python concerns, python3-full package for bullseye

2021-02-12 Thread Simon McVittie
On Fri, 12 Feb 2021 at 10:40:48 +0100, Valentin Vidic wrote: > Perhaps python3-core would be more appropriate, and python3-full can be > left for something even bigger. We have a python3 package already. If I saw a python3 package and a python3-core package, I would expect that either they're the

Re: Should Binaries provided by python-babel have a "python3-" prefix?

2020-11-27 Thread Simon McVittie
On Thu, 26 Nov 2020 at 22:33:19 +0100, Steffen Möller wrote: > On 26.11.20 13:16, Nilesh Patra wrote: > > Currently src:python-babel provides 3 binaries: > > > > * python3-babel > > * python-babel-doc > > * python-babel-localedata > > > > of which python3-babel is the main binary, -babel-doc is

Re: Package naming advice: python3-pyls-jsonrpc or python3-jsonrpc-server?

2020-11-01 Thread Simon McVittie
On Sun, 01 Nov 2020 at 19:36:52 +0200, Otto Kekäläinen wrote: > I am currently reviewing the Debian packaging at > https://salsa.debian.org/python-team/packages/python-jsonrpc-server of > the upstream project https://github.com/palantir/python-jsonrpc-server > > Upstream uses

Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?

2020-06-09 Thread Simon McVittie
On Tue, 09 Jun 2020 at 11:50:02 +0200, Julien Puydt wrote: > (1) during the autopkgtest run, we're not in the package source tree, > are we? So there should be no access do d/changelog? The cwd of each test is guaranteed to be the root of the source package, which will have been unpacked

Re: python 3.7 for Debian 9

2020-05-05 Thread Simon McVittie
On Tue, 05 May 2020 at 07:45:55 +0200, Vimanyu Jain wrote: > I have my python application written in version 3.7 and would like to run the > application on Debian. I would like to know of there is a plan to upgrade > python to version 3.7 from 3.5 in Debian 9.  The version of Python in Debian 9

Re: pkg-config of python3

2020-04-24 Thread Simon McVittie
On Fri, 24 Apr 2020 at 18:32:06 +, PICCA Frederic-Emmanuel wrote: > > If you want to embed python in an application, you need to use > > python3-embed.pc > > Or python3-config --embed > > then it links the program with -lpython3.8 > > so what is the purpose of python3.pc ? You use

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Simon McVittie
On Mon, 30 Mar 2020 at 15:30:01 +0200, Johannes Schauer wrote: > does this mean that build-depending on python3-dev is wrong in general and > should instead be replaced by build-depending on python3-all-dev? It is only wrong for packages that build Python 3 extensions (binary modules) that are

Re: New packages: -doc package with python or python3 prefix?

2020-03-28 Thread Simon McVittie
On Sat, 28 Mar 2020 at 11:44:35 +0100, ghisv...@gmail.com wrote: > Le samedi 28 mars 2020 à 11:22 +0100, Christian Kastner a écrit : > > The Python 2 removal page [1] states that existing python-$foo-doc > > packages should not be renamed to python3-$foo-doc. > > > > But what about new packages?

Re: Python3.8 as default final status

2020-03-27 Thread Simon McVittie
On Fri, 27 Mar 2020 at 11:12:35 -0400, Scott Kitterman wrote: > meson/0.52.1-1: #952610 This is fixed in experimental. The version in experimental is an unrelated new upstream release candidate, but the relevant packaging change seems readily backportable. smcv

Re: Bug#949187: transition: python3.8

2020-02-05 Thread Simon McVittie
On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote: > Thanks, yes, that prevents the install of the "old" > gobject-introspection with the new python3 from experimental. Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That isn't actually what you need if you

Re: Bug#949187: transition: python3.8

2020-02-04 Thread Simon McVittie
On Tue, 04 Feb 2020 at 21:20:07 +0100, Rene Engelhard wrote: > root@frodo:/# g-ir-scanner ... > ModuleNotFoundError: No module named 'giscanner._giscanner' This is fixed in 1.62.0-5 (#950267). Upload was delayed by FOSDEM, needing a glib2.0 upload to be built first (to have the right Breaks for

Re: Bug#949187: transition: python3.8

2020-02-03 Thread Simon McVittie
On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: > I think this is now in shape to be started. Please can this wait until the remaining bits of the libffi7 transition and the restructuring of the libgcc_s packaging have settled down? I'm still trying to sort out the missing Breaks

Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00

2020-01-03 Thread Simon McVittie
Control: severity 942941 normal Control: user debian-python@lists.debian.org Control: usertags 942941 + py2keep On Sun, 22 Dec 2019 at 12:36:38 -0500, Sandro Tosi wrote: > # python-dbus-tests is a module and has 0 external rdeps or not in testing > severity 942941 serious I do not consider this

Re: name change: python-lark-parser -> python-lark

2019-12-30 Thread Simon McVittie
On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote: > https://bugs.debian.org/945823 > > which says: > > "use the name you import in preference to the name from the PKG-INFO". > > That is why I decided to change the name to python-lark. But given the > PyPI name clash this is

Re: Proposal on how to proceed with Python 2 removal from bullseye

2019-12-22 Thread Simon McVittie
On Wed, 18 Dec 2019 at 01:08:11 -0500, Sandro Tosi wrote: > let me know if this makes sense or additional changes are required. #942941 in src:dbus-python was bumped to serious because: > python-dbus-tests is a module and has 0 external rdeps or not in testing Please could you give

Re: Future of Trac in Debian

2019-11-30 Thread Simon McVittie
On Fri, 29 Nov 2019 at 18:13:02 -0500, Nicholas D Steeves wrote: > At that upstream issue gwync writes that he might have to drop Trac in > Fedora if there isn't a py3 test release "before Fedora 32 is GA". I'm > not sure what "GA" means Presumably "general availability", i.e. properly released

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Simon McVittie
On Thu, 28 Nov 2019 at 17:27:53 +, Simon McVittie wrote: > On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: > > if you install `pubsub` as top-level module, your package must be > > named pythonN-pubsub, if not it violates the policy and it's RC buggy. > > That

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Simon McVittie
On Fri, 29 Nov 2019 at 08:30:16 +0800, Yao Wei (魏銘廷) wrote: > The binary package for module foo should preferably be named > python3-foo, if the module name allows > > If the module name has upper case in it, it would actually break Policy §5.6.1 I'd assumed the "foo" here was shorthand

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-28 Thread Simon McVittie
On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: > if you install `pubsub` as top-level module, your package must be > named pythonN-pubsub, if not it violates the policy and it's RC buggy. That's what I had thought, but I've also seen people asserting that the Debian package name ought

Re: Discussing next steps for the Python2 removal

2019-10-28 Thread Simon McVittie
On Fri, 25 Oct 2019 at 12:38:11 +0200, Ondrej Novy wrote: > this is not how autorm works. You can't remove from testing only one of two > binary package from same source package. You are removing  package as a whole. > > But maintainer can anytime fix that bug by removing py2 binary from source >

Re: 2Removal: handling circular dependencies

2019-10-24 Thread Simon McVittie
On Wed, 23 Oct 2019 at 23:05:39 +0100, Rebecca N. Palmer wrote: > - One big tangle (159 packages). This probably needs breaking up: > --- Some of it involves documentation tools (e.g. sphinx). These cycles can > be broken by using the Python 3 version of the tool. You've listed dbus-python as

Re: Help needed for issue in test suite for Python3 (Was: Bug#937698: python-dendropy: Python2 removal in sid/bullseye)

2019-10-08 Thread Simon McVittie
tl;dr: The issue in the test suite is that there is no test suite. On Tue, 08 Oct 2019 at 09:28:45 +0200, Andreas Tille wrote: > File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 229, > in run > self.run_tests() setuptools is trying to find the tests declared in

Bug#935395: RFP: python3-anytree -- Tree data library

2019-08-22 Thread Simon McVittie
Package: wnpp Severity: wishlist * Package name: python3-anytree Version : 2.6.0 Upstream Author : "c0fec0de" * URL : https://github.com/c0fec0de/anytree https://pypi.org/project/anytree/ * License : Apache 2.0 Programming Lang: Python

Re: Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie
On Fri, 14 Dec 2018 at 20:19:00 +0100, Matthias Klose wrote: > On 14.12.18 12:48, Simon McVittie wrote: > > On Fri, 14 Dec 2018 at 11:31:02 +0000, Simon McVittie wrote: > >> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. > > > > This seems to

Re: Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie
Control: forwarded -1 https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42 Control: tags -1 + patch On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote: > tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. This seems to be caused by using socket.send() (and assum

Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie
Package: autopkgtest Version: 5.6 Severity: important File: /usr/bin/autopkgtest-virt-qemu Control: found -1 5.7 Control: user debian-python@lists.debian.org Control: usertags -1 + python3.7 X-Debbugs-Cc: debian-python@lists.debian.org tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. A

Re: Upstreams dropping Python 2 support

2018-09-27 Thread Simon McVittie
On Thu, 27 Sep 2018 at 11:58:28 +0200, Ole Streicher wrote: > Is there a reason why one would use Python2-sphinx instead of the Python > 3 version? src:dbus-python has more Python 2 API than Python 3 API (some objects cease to exist in Python 3 builds). As long as python-dbus.deb exists, it's

Re: Bug#906949: Clarify documentation location in a Python2-less distribution

2018-08-22 Thread Simon McVittie
On Thu, 23 Aug 2018 at 01:20:44 +1000, Stuart Prescott wrote: > d) revert to /usr/share/doc/python-foo-doc: do we ignore policy's > recommendation, overriding (or changing) dh_installdocs? While > /usr/share/doc/main-package is only a recommendation in policy, 700 > python-foo-doc packages

Re: Bug#886291: Debian package transition: Rename package and reuse old name with new content

2018-08-19 Thread Simon McVittie
On Sat, 18 Aug 2018 at 16:31:37 +0200, Alexis Murzeau wrote: > To fix #886291, we should: > - Rename python3-pycryptodome to python3-pycryptodomex > - Reuse python3-pycryptodome package name to package a non compatible > python3 module. > > The rationale of this rename + reuse is that currently,

Re: git-dpm -> gbp conversion (mass-change)

2018-08-09 Thread Simon McVittie
On Thu, 09 Aug 2018 at 10:16:31 +0200, Thomas Goirand wrote: > Now, if all goes well, and if the above cases are fixed, them I'm fine > using "gbp pq", but it's not any better than fixing by hand using quilt. One advantage of both quilt and gbp-pq over git-dpm (and probably git-debrebase) is that

Re: git-dpm -> gbp conversion (mass-change)

2018-08-03 Thread Simon McVittie
On Fri, 03 Aug 2018 at 08:21:28 +0200, W. Martin Borgert wrote: > In fact, I thought that "upstream/master" were DEP-14-ish, but > only "upstream/latest" (for the newest release) is. Yes. The simple case for DEP-14 is that you are only following one upstream branch, which is upstream/latest; the

Re: Python 3.7 in testing/experimental

2018-06-30 Thread Simon McVittie
On Fri, 29 Jun 2018 at 23:29:37 +0200, Vincent Danjean wrote: > Will the python3-numpy pacakge be fixed by an automatic rebuild ? > (ie I just have to wait for a few days) It should be. It's in Needs-Build state at the moment: https://buildd.debian.org/status/package.php?p=python-numpy 378

Re: Questions about salsa and Git

2018-04-10 Thread Simon McVittie
On Tue, 10 Apr 2018 at 10:41:41 +, Scott Kitterman wrote: > On April 10, 2018 7:24:18 AM UTC, "Guðjón Guðjónsson" > wrote: > >Following the advice on > >https://wiki.debian.org/Python/GitPackaging > > Use this instead: >

Re: packages that use dh_python{2,3} but don't depend on dh-python

2018-03-26 Thread Simon McVittie
On Mon, 26 Mar 2018 at 13:32:10 +0200, Piotr Ożarowski wrote: > Here's a list of packages that will FTBFS soon if dh-python will not be > added to Build-Depends (it's time to drop dh-python from python3's > Depends and old version of dh_python2 from python package). Is there a Lintian tag for

Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils

2018-03-23 Thread Simon McVittie
Package: python3-distutils Version: 3.6.5~rc1-2 Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org I'm confused about the current status of distutils, and what should be done by packages that depend on it to be as future-proof as possible. I don't think I'm the only one confused by

Re: RFS: mwic 0.7.4-1

2018-03-20 Thread Simon McVittie
On Tue, 20 Mar 2018 at 12:18:39 +0100, Gregor Riepl wrote: > > In case I've misunderstood you, and you're referring to unit tests > > shipped debian/tests/*, than yes, I agree. :) > > As far as I understand, these tests are executed by the package builder after > the upstream build script has

Re: Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-12 Thread Simon McVittie
On Mon, 12 Mar 2018 at 11:16:16 +0100, W. Martin Borgert wrote: > policy (12.3) says, that putting the contents of package-doc > into /usr/share/doc/package/ (main package) is preferred over > /usr/share/doc/package-doc/. debhelper detects the Python 2 > package as main package. One can override

Re: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

2018-01-25 Thread Simon McVittie
On Thu, 25 Jan 2018 at 17:45:33 +, peter green wrote: > > However, in Debian case, I do not know how this can be handled as > > 2 packages cannot hold the same file (even if __init__ is only an empty > > file), and at least one must be present (if you install only one). The Python jargon is

Re: DPMT and git workflows

2018-01-19 Thread Simon McVittie
On Fri, 19 Jan 2018 at 14:25:57 +0300, Dmitry Shachnev wrote: > I think for new packages it is better to use gbp-pq based workflow: > https://wiki.debian.org/Python/GitPackagingPQ Is there consensus that the gbp-pq workflow is now allowed? I only maintain one package in DPMT (tap.py) and every

Re: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

2018-01-15 Thread Simon McVittie
On Mon, 15 Jan 2018 at 12:59:29 +0100, Andreas Tille wrote: > E File > "/build/python-aws-xray-sdk-0.95/.pybuild/pythonX.Y_2.7/build/tests/test_async_local_storage.py", > line 10 > E async def _test(): > E ^ > E SyntaxError: invalid syntax Looks like it needs python3

Re: python-markdown and mkdocs circular build-dep

2018-01-11 Thread Simon McVittie
On Thu, 11 Jan 2018 at 13:35:13 +0300, Dmitry Shachnev wrote: > The new release of python-markdown has switched docs building from its own > custom build system to mkdocs. However python-mkdocs itself build-depends on > python3-markdown for tests, which results in a circular build-dependency. It

Re: Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package

2017-12-01 Thread Simon McVittie
On Fri, 01 Dec 2017 at 12:13:26 +0100, Ondrej Novy wrote: > 2017-12-01 11:25 GMT+01:00 Simon McVittie <[1]s...@debian.org>: > Within Debian, wouldn't this be better achieved by having Python 2 > packages > that require enum34 depend on python-enum34 directly, as they

Re: doc-central

2017-10-13 Thread Simon McVittie
On Fri, 13 Oct 2017 at 08:13:08 +0800, Paul Wise wrote: > On Fri, Oct 13, 2017 at 3:27 AM, Diane Trout wrote: > > > Being able to find all your documentation in one place would really be > > convenient. > > I don't think doc-base/doc-central will ever be the answer to this as > it is very

Re: pycharm package in debian

2017-10-04 Thread Simon McVittie
On Wed, 04 Oct 2017 at 14:11:02 -0700, Diane Trout wrote: > I do wish that these third party app systems like conda, snappy or > flatpak would include metadata like AppStream or DOAP. Flatpak already does. Flatpak apps nearly always include AppStream metadata, which Flatpak's repository

Re: providing sphinx3-* binaries

2017-09-28 Thread Simon McVittie
On Thu, 28 Sep 2017 at 01:03:27 +0300, Dmitry Shachnev wrote: > On Tue, Sep 26, 2017 at 06:29:05PM -0400, Antoine Beaupré wrote: > > 1. there should be a more easy way to override SPHINXBUILD in > > quickstart-generated Makefiles. IMHO, that means SPHINXBUILD?= > > instead of SPHINXBUILD=

Re: PAPT git migration

2017-06-01 Thread Simon McVittie
On Thu, 01 Jun 2017 at 15:06:07 +1000, Brian May wrote: > So to me it looks like the required changes are: > > * Rename Author field to From. Ensure it is first field. It doesn't *have* to be the first, but if it isn't, gbp pq export will re-order it. > * Add Date field. Set to what? The date

Re: PAPT git migration

2017-05-31 Thread Simon McVittie
On Thu, 01 Jun 2017 at 00:16:45 +0200, Stefano Rivera wrote: > Hi Barry (2017.05.31_23:32:20_+0200) > > $ gbp pq export > > - This doesn't work until you at least do a first pq import, but now I see > > the > > d/p/changlog-docs patch gets changed in ways that lose information: > > Sounds like

Re: python-parse-type

2017-05-17 Thread Simon McVittie
On Wed, 17 May 2017 at 11:03:40 +0200, Thomas Goirand wrote: > On 05/16/2017 02:30 PM, Simon McVittie wrote: > > PyPI packages correspond to Debian source packages, not binary packages. > > I don't think there ever was a source package name policy, neither in > Debian nor in th

Re: python-parse-type

2017-05-16 Thread Simon McVittie
On Tue, 16 May 2017 at 08:00:43 -0400, Barry Warsaw wrote: > On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote: > >packaged as python-enum34 (correct name is python-enum, that's why you > >didn't find it most probably) > > Why is that wrong? Agreed it's perhaps less discoverable in this case,

Re: Salvaging python-cassandra for Stretch

2017-04-06 Thread Simon McVittie
On Thu, 06 Apr 2017 at 17:49:15 +0200, Thomas Goirand wrote: > Attached is the debdiff. As you can see, I'm attempting to use the new > system that creates -dbgsym, and transitioning to it. Sorry, I don't think this is a correct solution. For non-Python packages, foo-dbg traditionally contained

Re: Transition away from git-dpm was: Re: Adopting OpenStack packages

2017-03-08 Thread Simon McVittie
On Wed, 08 Mar 2017 at 17:47:40 +1100, Brian May wrote: > At the moment - since there were no objections yet - I have revised the > wiki documentation (link already provided) to include DEP-14 and > debian/master (as per DEP-14). I think there's value in using debian/master for the focus of

Re: Adopting OpenStack packages

2017-03-06 Thread Simon McVittie
On Mon, 06 Mar 2017 at 10:32:17 -0500, Scott Kitterman wrote: > I think it's reasonable to try this out on a branch Here's a maybe-stupid idea: use http://dep.debian.net/deps/dep14/ branch naming (debian/master, debian/experimental) for that branch, and switch to it as the default branch (edit

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-14 Thread Simon McVittie
On Tue, 14 Feb 2017 at 11:44:33 -0500, Barry Warsaw wrote: > So how do I drop a patch with gbp-pq? rm debian/patches/this-got-fixed-upstream.patch, vi debian/patches/series, commit? :-) Or more generally, to do it the git way, if the rest of the patch series might need non-trivial adjustment:

Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-07 Thread Simon McVittie
On Tue, 07 Feb 2017 at 10:47:00 +, Ghislain Vaillant wrote: > I know the discussion is leaning towards replacing usage of git-dpm > with gbp-pq. I have nothing against it but, since we are talking about > solutions for a git-centric workflow, has anyone considered the dgit- > maint-merge

Re: Best way to package a python module which is "private" with exposed calling script

2017-02-06 Thread Simon McVittie
On Mon, 06 Feb 2017 at 16:43:32 -0500, Thomas Nyberg wrote: > What I would ideally like is for the module > code to be put somewhere off the regular system path and then have the > binary "know" how to find it. If you do this: /usr/ ├── bin/ │ └── script →

Re: [Python-modules-team] Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t

2017-01-30 Thread Simon McVittie
On Mon, 30 Jan 2017 at 20:31:06 +1100, Brian May wrote: > > File "faker/providers/date_time/__init__.py", line 403, in > > date_time_this_century > > return cls.date_time_between_dates(now, next_century_start, tzinfo) > > File "faker/providers/date_time/__init__.py", line 381, in > >

Re: git-dpm breakage src:faker

2017-01-29 Thread Simon McVittie
On Sun, 29 Jan 2017 at 20:50:48 +0100, Raphael Hertzog wrote: > On Sun, 29 Jan 2017, Brian May wrote: > > 3. Update debian/source/options with "unapply-patches" (anything else?). > > You don't need that. dpkg-buildpackage unapplies them automatically after > the build if it has applied them. If

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

2016-08-11 Thread Simon McVittie
On Thu, 11 Aug 2016 at 09:29:13 -0400, Barry Warsaw wrote: > On Aug 11, 2016, at 12:12 AM, Simon McVittie wrote: > >where all Debian-specific pseudo-headers appear at the end of the diff > >(next to the Signed-off-by if any), > > Did you mean to say "end of the diff hea

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

2016-08-10 Thread Simon McVittie
On Wed, 10 Aug 2016 at 16:41:40 -0400, Barry Warsaw wrote: > * With git-dpm we *had* to enforce the tool choice because git-dpm's artifacts > had to be preserved. If we ditch git-dpm, is that still the case? IOW, if > you choose to use gbp-pq, am I forced to do so when I modify the same repo?

Re: Package name for github.com/miguelgrinberg/python-socketio

2016-08-02 Thread Simon McVittie
On Wed, 03 Aug 2016 at 09:12:22 +1000, Ben Finney wrote: > Yes, this is a problem with the current Debian Python policy: it assumes > distribution authors will not collide on package names. > > I don't have an answer, though I will point out that whatever the > solution is, it will be

Re: transition: python3-defaults (python3.5 as default python3) - status update

2016-01-13 Thread Simon McVittie
On 13/01/16 14:02, Scott Kitterman wrote: > On Wednesday, January 06, 2016 03:39:15 PM you wrote: >> b. Remove pygpgme from Testing. It has rdepends so it would kill off a few >> other packages as well: ... >> bmap-tools: bmap-tools It turns out I can drop pygpgme to a Recommends on this one:

Re: Rebuild for packages with entry points?

2015-12-08 Thread Simon McVittie
On 08/12/15 16:50, Nikolaus Rath wrote: > On Dec 07 2015, Simon McVittie <s...@debian.org> wrote: >> This looks like a job for Lintian, assuming setuptools entry points are >> easy to detect with a regex. > > Well, yes, but what's the point? New uploads will not be af

Re: Rebuild for packages with entry points?

2015-12-07 Thread Simon McVittie
On 07/12/15 19:00, Barry Warsaw wrote: > On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote: >> It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/ >> fixed in stretch. > > I'm also not sure how many packages it affects in practice. We could also let > rebuilds be bug-driven.

Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!

2015-08-07 Thread Simon McVittie
On 07/08/15 11:30, Sandro Tosi wrote: On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw ba...@debian.org wrote: But, is that a good thing? quilt itself is a PITA to use IMHO a lot of people seems to appreciate quilt (I know that 3.0 (quilt) doesnt necessarily reflect in using quilt). It's not

Re: Bug #751908, tox, and bin-only Python packages

2015-08-06 Thread Simon McVittie
On 06/08/15 15:50, Barry Warsaw wrote: The example that sparked issue #751908 was tox, which when I initially packaged it, I called the binary package python-tox. I did this because, while the package does not provide any publicly importable modules, I felt it was presumptuous to claim a

Re: pybuild (Re: image-file-in-usr-lib)

2015-05-11 Thread Simon McVittie
On 11/05/15 08:03, Ole Streicher wrote: What is the rationale between having all this in /usr/lib? Conversely, it might be informative to consider the rationale for /usr/lib and /usr/share being separate: This hierarchy is intended to be shareable among all architecture platforms of a given

Re: Keeping upstream commits separate from Debian packaging commits

2014-10-16 Thread Simon McVittie
On 16/10/14 18:01, Tristan Seligmann wrote: The purpose of pristine-tar is the same whether you base it on a revision fetched from upstream, or a revision created by git-import-orig or a similar tool ... or a revision created by git-import-orig --upstream-vcs-tag=v1.2.3, which has the contents

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

2014-09-05 Thread Simon McVittie
On 04/09/14 20:40, Barry Warsaw wrote: The file is patched, but now I have an d/p/0005- file instead of a modified 0003- patch file. Sigh. The systemd maintainers configured git-buildpackage (in their debian/gbp.conf) to not use patch numbers. I'm starting to think that's The Right Thing in

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

2014-09-05 Thread Simon McVittie
On 05/09/14 13:10, Simon McVittie wrote: On 04/09/14 20:40, Barry Warsaw wrote: The file is patched, but now I have an d/p/0005- file instead of a modified 0003- patch file. Sigh. The systemd maintainers [...] It might also be worth noting that the systemd maintainers switched from git-dpm

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

2014-09-05 Thread Simon McVittie
On 05/09/14 15:53, Barry Warsaw wrote: On Sep 05, 2014, at 01:21 PM, Simon McVittie wrote: It might also be worth noting that the systemd maintainers switched from git-dpm to gbp-pq recently (between 204 and 208, I think), so they obviously didn't think git-dpm was the better option

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

2014-09-05 Thread Simon McVittie
On 05/09/14 16:18, Martin Pitt wrote: I don't think anyone in pkg-systemd@ has looked at git-dpm yet. In fact we switched from gitpkg to standard git-buildpackage. Ugh, sorry. So I'm not sure where switched from git-dpm came from? smcv mis-remembering the situation, evidently. S --

Re: multiple deb packages from python program.

2014-08-30 Thread Simon McVittie
On 30/08/14 10:50, Cornelius Kölbel wrote: But now my originial program package is empty and does not contain the python code. It looks like only the .install scripts are run, but obviously python setup.py install is not run anymore - so I guess something does not work right with the simple

Re: How does team maintenace of python module works?

2013-02-20 Thread Simon McVittie
On 20/02/13 14:14, Thomas Goirand wrote: Now, do you know if it is possible to use git-buildpackage without storing the full upstream source in a branch? Yes, most conveniently done via 'overlay = True' in debian/gbp.conf. You have to supply a copy of the upstream tarball as you would for plain

Re: python-xlrd

2013-02-06 Thread Simon McVittie
On 06/02/13 16:12, Thomas Kluyver wrote: Of course, it's good to exercise due diligence, but the flip side is that technical changes which I hope would be uncontroversial have now taken a back seat to bureaucracy, because one man a few years ago declared himself 'the maintainer'. If the

Re: bug in backports that affects wheezy

2013-01-31 Thread Simon McVittie
On 31/01/13 09:00, Javi Merino wrote: Assuming that it does affect wheezy, should I upgrade it to important If you think it has a major effect on the usability of the package, without rendering it completely unusable to everyone[1] then yes. fix it in wheezy and then backport it to

Re: Advise on packaging a new Python module

2012-11-07 Thread Simon McVittie
On 07/11/12 16:06, Tomás Di Domenico wrote: On 07/11/12 16:43, Jakub Wilk wrote: * Tomás Di Domenico td...@tdido.com.ar, 2012-11-07, 12:30: About the different versions in the git repository and the upstream package, that is actually my fault. I checked out the code from the upstream

Re: RFR: python-secretstorage

2012-06-22 Thread Simon McVittie
On 22/06/12 11:27, Thomas Kluyver wrote: I recently did a wrapper for the dbus desktop notifications API 5 # This is needed on buildd so that dbus can use ~/.dbus 6 export HOME = $(CURDIR) FYI this shouldn't be necessary on Linux if you're either under X or running dbus-daemon

Re: how to take a public package private?

2012-04-30 Thread Simon McVittie
On 30/04/12 09:45, Piotr Ożarowski wrote: I will change that to /usr/share/package-name/module and /usr/lib/package-name/module if no one objects (adding /usr/share or /usr/lib to sys.path is not a good idea, we don't do that so policy should be updated) Some PyGTK apps seem to make good

Re: how to take a public package private?

2012-04-30 Thread Simon McVittie
On 30/04/12 10:39, Piotr Ożarowski wrote: [Piotr Ożarowski, 2012-04-30] I will change that to /usr/share/package-name/module and /usr/lib/package-name/module if no one objects (adding /usr/share or /usr/lib to sys.path is not a good idea, we don't do that so policy should be updated) on

Re: how to take a public package private?

2012-04-30 Thread Simon McVittie
On 30/04/12 15:50, Barry Warsaw wrote: On Apr 30, 2012, at 12:08 PM, Simon McVittie wrote: I think it would still be clearer to say /usr/share/package-name/module.py, /usr/lib/package-name/module.so, assuming the library-user code involves import module? Debian package-name or Python

Re: how to take a public package private?

2012-04-30 Thread Simon McVittie
On 30/04/12 17:29, Paul Elliott wrote: I want to move the python package openastromod to a private location. My package, (openastro.org) before modification, when it is still creating a public python package, creates: (from dpkg-query -L openastro.org) /usr/share/pyshared/openastromod

Re: qscintilla2: package Python 3 bindings

2012-03-14 Thread Simon McVittie
On 14/03/12 15:40, Barry Warsaw wrote: It would be nice to build for all supported Python 3 versions. Python 3.3 is currently scheduled for August of this year, but I'm hoping we'll start seeing it show up in Debian around the time of the first beta in June. That's too late for it to be

Re: New python-qt4 upload to experimental

2012-01-29 Thread Simon McVittie
On 29/01/12 05:28, Scott Kitterman wrote: 2. It builds a new python3-pyqt4-dbus (and dbg) package that needs python3- dbus which is only available in experimental at the moment. Thanks, I'd meant to ask if you could get that working but you were obviously way ahead of me :-) Did you

call for testing: dbus-python/experimental

2012-01-29 Thread Simon McVittie
As Scott Kitterman has already noticed, dbus-python in experimental supports Python 3 (kudos to Barry Warsaw for making that happen). This required changes to both C and Python code, and Python 2 uses the same codebase (with some #ifdef stuff), so please test the new version with Python 2 apps

Re: Bug#493022: RFP: python-gnucash -- Python bindings for the GnuCash library

2011-07-15 Thread Simon McVittie
forcemerge 617728 493022 thanks On Wed, 30 Jul 2008 at 20:21:37 +0100, Sam Morris wrote: * Package name: python-gnucash Version : 0.7.55 * URL : http://www.parit.ca/projects/pythongnucash/ This seems to have been merged into Gnucash upstream, so instead of a new

Re: Fw: Python packaging, dependencies, upstream facilities

2010-09-21 Thread Simon McVittie
On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote: I'm not sure we should try to solve this. IMHO we should try to convince upstreams that breaking API/ABI so often is a bad thing instead. ... and that when they do, they need to rename the module with a version number, just like C

Re: Ongoing Python Transition: related FTBFSes

2010-01-28 Thread Simon McVittie
On Thu, 28 Jan 2010 at 12:50:24 +0100, Cyril Brulebois wrote: FWIW, here are some FTBFSes I've reported lately, which look due to this transition: [...] ... and for those who care about FTBFSs, the binNMUs of pygtk are also all failing (either due to #548211 or not waiting for python2.6-gobject

Bug#561479: RM: docutils-writer-manpage -- uninstallable, integrated into new python-docutils

2009-12-17 Thread Simon McVittie
Package: ftp.debian.org Severity: normal Please remove docutils-writer-manpage from unstable (and hence testing). Its functionality has been merged into its dependency python-docutils in version 0.6, so it's now uninstallable in unstable, and the new docutils can't migrate to testing until

Bug#561478: RM: odtwriter -- uninstallable, integrated into new python-docutils

2009-12-17 Thread Simon McVittie
Package: ftp.debian.org Severity: normal Please remove odtwriter from unstable (and hence testing). Its functionality has been merged into its dependency python-docutils in version 0.6, so it's now uninstallable in unstable, and the new docutils can't migrate to testing until odtwriter and

Re: docutils: 0.6, rst2man/rst2odt obsoleted, RFH

2009-12-07 Thread Simon McVittie
enough already), but it might be worth mentioning scripts like rst2html and rst2latex, or some similar wording, in the Description. Simon McVittie s...@debian.org writes: Unrelated to 0.6, I've been thinking about handing over python-docutils to someone else - I hardly use it myself, and I'm

docutils: 0.6, rst2man/rst2odt obsoleted, RFH

2009-12-06 Thread Simon McVittie
I've been updating python-docutils to version 0.6. This version includes the separate man page and ODT writers that were previously packaged by Ben Finney and Michael Schutte, so I've made it conflict/provide/replace them, and put their maintainers in the Uploaders (I hope you don't mind). If

Re: dependency questions

2008-08-27 Thread Simon McVittie
On Wed, 27 Aug 2008 at 13:07:19 +0200, Josselin Mouette wrote: Le lundi 25 août 2008 à 00:03 +0200, Eike Nicklas a écrit : c) Depends: python (=2.4), python-elementtree (does python2.5 provide python-elementtree?) It does not, which is a bug, since this option should be the correct one.

Re: Debian has switched to python2.5

2008-04-14 Thread Simon McVittie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 14 Apr 2008 at 09:39:05 +0200, Ondrej Certik wrote: So currently, some packages needs to be fixed, for example on my system, these packages now want to be removed: gimp-python hpijs hpijs-ppds hplip hplip-gui libapache2-mod-python

RFS: python-docutils 0.4-6

2008-03-20 Thread Simon McVittie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 470697 + patch pending thanks Could someone (madduck?) please upload python-docutils (r4865) from python-modules-team svn? It fixes build failure with the current python-central version. You'll need to change UNRELEASED to unstable in

Re: Packaging software for Cheeseshop and Debian

2007-10-24 Thread Simon McVittie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 Oct 2007 at 10:03:09 +0200, Bernd Zeimetz wrote: I develop and package webcheck [0] (a python application with private modules). I put all stuff in /usr/share/webcheck and use python-support for compiling the stuff there. I ship an

Re: Python independant binary extensions

2006-07-02 Thread Simon McVittie
On Fri, 30 Jun 2006 at 19:00:02 +0200, Mike Hommey wrote: On Fri, Jun 30, 2006 at 06:43:22PM +0200, Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 30 juin 2006 à 17:38 +0200, Mike Hommey a écrit : On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette [EMAIL PROTECTED]

RFS: python-docutils 0.4-2 (policy transition upload)

2006-06-28 Thread Simon McVittie
Martin F. Krafft and I recently adopted python-docutils, and I've updated it to the new policy. I've been waiting for feedback from Martin, but since an upload is needed for the policy transition, perhaps someone else could look at it? There are quite a lot of changes, since I went through some

Request to join python-modules team

2006-06-13 Thread Simon McVittie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to join the python-modules team, in order to co-maintain python-docutils with Martin F. Krafft. My Alioth login is smcv-guest. I'm currently preparing an upload which will fix some of the old bugs and use the new Python policy. Thanks,