Re: "debian/main" support or ticket open?

On Mon, 18 Mar 2024 at 10:23:23 +0100, Agathe Porte wrote: > 2024-03-15 10:16 CET, Simon McVittie: > > When the GNOME team switched from debian/master to debian/latest, it > > was a coordinated change applied to every package maintained by the team. > > Do we know if this wa

Re: "debian/main" support or ticket open?

On Fri, 15 Mar 2024 at 08:10:55 +, c.bu...@posteo.jp wrote: > To my knowledge in context of DPT and Salsa the branch name "debian/master" > is used. When creating a new package are there any technical reasons not > renaming that to "debian/main"? Naming is a social thing, not a technical

Re: Did Python 3.12 developers honestly broke special regexp sequences? (Was: hatop fails its autopkg tests with Python 3.12)

On Tue, 13 Feb 2024 at 18:21:17 +0100, Andreas Tille wrote: > SyntaxWarning: invalid escape sequence '\.' > 573s CLI_INPUT_RE = re.compile('[a-zA-Z0-9_:\.\-\+; /#%]') This should be: re.compile(r'[a-zA-Z0-9_:\.\-\+; /#%]') ^ a raw string, where the backslashes are not

Re: Naming of python binary packages

On Fri, 11 Aug 2023 at 14:49:00 +, Stefano Rivera wrote: > > > According to the Debian Python Policy Section 4.3, binary package > > > names should be named after the *import* name of the module, not the > > > PyPI distribution name. > > > Unfortunately, I do not agree at all with this

Re: pybuild now supports meson

On Wed, 02 Aug 2023 at 17:44:24 +, Stefano Rivera wrote: > The latest upload of dh-python to unstable (6.20230802) includes a > meson plugin, so pybuild can easily build a package multiple times for > all supported Python modules. I don't think this is necessarily appropriate for a lot of the

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote: > To quote from the BTS: > ---%<--- > > In 1.2 upstream added a test suite. We should run it during build > > (cd common && $(MAKE) test) but it needs to be able to write to the home > > directory, which is disabled on Debian

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

On Fri, 28 Jul 2023 at 11:08:38 +, c.bu...@posteo.jp wrote: > Am 28.07.2023 11:53 schrieb Carsten Schoenert: > > I don't see any workaround and there is non needed. The bug issue is > > about the not usable upstream test suite that would need to be called > > through d/rules. > > Maybe this

Re: how to properly split up into python3-foo and foo-util package?

On Mon, 17 Jul 2023 at 23:16:03 +0200, Christoph Anton Mitterer wrote: > How does one know (I guess it must be written somewhere and I just > missed it - or was to lazy to read the relevant section O:-) ) which > one the "current directory" is in which stage of the build? > Or is it simply always

Re: how to properly split up into python3-foo and foo-util package?

On Wed, 12 Jul 2023 at 11:19:07 +0200, Andrey Rakhmatullin wrote: > I don't think "usr/bin stuff should likely go > in the other". Many Python module packages ship executables, especially > now that you no longer have Python 2 subpackages. I would personally say that if the executables are

Re: how to properly split up into python3-foo and foo-util package?

On Wed, 12 Jul 2023 at 02:21:48 +0200, Christoph Anton Mitterer wrote: > 2) I then tried with such package.install files like those: >foo-util.install: > usr/bin > >python3-foo.install: > usr/lib > >a) Why does it work to use just usr/... and not debian/tmp/usr/... ? >

Re: Unittests writing to HOME (backintime)

On Wed, 29 Mar 2023 at 07:52:35 +, c.bu...@posteo.jp wrote: > My question now is why newer version of this package are uploaded then? I > couldn't find that the tests where deactivated. Maybe this "disabled on > Debian auto-builders" is outdated and today it is possible to write to HOME >

Re: What is this about the metainfo-file?

This is really a question about packaging applications, not a question about packaging Python. On Fri, 20 Jan 2023 at 09:48:17 +, c.bu...@posteo.jp wrote: > What is the advantage for Debian users of such a file? Debian doesn't offer > a "software center". Yes it does. GNOME Software and KDE

Re: Python 3.11 for bookworm?

On Sat, 07 Jan 2023 at 10:23:19 +0200, Andrius Merkys wrote: > If I may, I would as well be grateful if someone could give a look at: > > #1023972 [src:python-ase] FTBFS with Python 3.11 due to > pathlib.Path.__enter__() deprecation > > I have no idea how to fix this and the upstream is silent.

Re: Bug#1026312: Setuptools 65.5.0-1.1 breaks installing Python modules/extensions via meson

Control: severity -1 serious Control: block 1026526 by -1 Control: block 1026751 by -1 Control: block 1026732 by -1 Control: affects -1 + meson python3-distutils src:dbus-python src:libgit2-glib src:gi-docgen On Sun, 18 Dec 2022 at 11:11:46 +0100, Enrico Zini wrote: > After the 65.5.0-1.1

Re: Bug#1018689: override: python3:python/standard

On Sat, 03 Sep 2022 at 22:41:36 -0700, Sean Whitton wrote: > On Sun 28 Aug 2022 at 10:33PM -05, Daniel Lewart wrote: > > Currently, python3 is Priority: optional. > > > > The following Buster packages have Priority: standard: > > * python > > * python-minimal > > * python2.7 > > *

Re: Bug#1017959: RFP: meson-python -- Meson PEP 517 Python build backend

Control: retitle -1 ITP: meson-python -- Meson PEP 517 Python build backend Control: owner -1 ! On Tue, 23 Aug 2022 at 01:25:49 +0200, Drew Parsons wrote: > * Package name: meson-python > Description : Meson PEP 517 Python build backend I started looking at this because I've wondered

Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)

On Wed, 27 Jul 2022 at 09:18:42 +0100, Julian Gilbey wrote: > There seems to be little point running both pybuild-autopkgtest and a > manually written debian/tests/* test suite. I think it can make sense to have both. d/tests is the right place for an integration test that checks things like "any

Re: Build and run-time triplets

On Thu, 09 Jun 2022 at 09:56:42 +0100, Julian Gilbey wrote: > OK (and yes, it does require the full path at runtime). What triplet > do I use in d/rules? dpkg-architecture offers 6 different ones: > DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}? I'm guessing > DEB_TARGET_MULTIARCH, but I'm

Re: Build and run-time triplets

On Thu, 09 Jun 2022 at 13:03:25 +0500, Andrey Rahmatullin wrote: > The normal way for this is putting it into > /usr/lib//pkgname/foo.so, and according to the code below you'll > need the full path at the run time so you indeed need the triplet at both > build and run time. You can do something

Re: Python C-library import paths

On Sat, 02 Apr 2022 at 12:55:37 +0100, Wookey wrote: > On 2022-04-01 00:30 -0400, M. Zhou wrote: > > They have written > > their own ffi loader, so I think it is an upstream bug. The upstream > > should detect and add multiarch directory to the paths. > > A correct implemntation really should use

Re: sysconfig default scheme change in Python 3.10

On Mon, 28 Mar 2022 at 21:17:40 +, Stefano Rivera wrote: > We've fixed this issue in pybind11 and automake-1.16, so far. Does this mean that packages that build using Automake, but use the pregenerated configure/Makefile.in provided by the upstream maintainer (often on an older or non-Debian

Re: DPT repositories checks/"violations" report

On Sat, 27 Nov 2021 at 09:38:41 +, Scott Kitterman wrote: > I don't think the pypi tarball "issue" should be presumed to be a > problem at all. I wasn't paying attention to Debian when that discussion > happened, but in my experience there was a lot wrong with the idea. > A properly

Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

On Fri, 25 Jun 2021 at 18:29:19 -0400, Nicholas D Steeves wrote: > Take for example the > case where upstream exclusively supports a Flatpak and/or Snap > package... Flatpak and Snap aren't source package formats (like Autotools "make dist" or Meson "meson dist" or Python sdist), they're binary

Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

On Fri, 25 Jun 2021 at 16:42:42 -0400, Nicholas D Steeves wrote: > I feel like there is probably consensus against the use of PyPi-provided > upstream source tarballs in preference for what will usually be a GitHub > release tarball This is not really consistent with what devref says: The

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

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?

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?

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?

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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#886291: Debian package transition: Rename package and reuse old name with new content

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)

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)

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

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

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

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

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

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?

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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

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

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?

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?

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!

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

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)

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

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)

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)

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)

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)

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.

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?

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

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

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

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

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

  1   2   >