On Tue, 06 Aug 2024 at 21:11:53 +0700, Dima Kogan wrote:
> Thanks for the detailed reply. The current expansion
>
> Depends: python3 (<< 3.13), python3 (>= 3.12~), python3:any
>
> has dependencies both with and without :any. Is THAT right?
Sort of. Let me put it this way: I don't think it's wr
On Tue, 06 Aug 2024 at 10:32:49 +0700, Dima Kogan wrote:
> As with most packages, python3-numpy has
>
> Depends: ${python3:Depends}
>
> which today expands to
>
> Depends: python3 (<< 3.13), python3 (>= 3.12~), python3:any
>
> Can somebody comment about why the :any is on the un-versioned
>
On Fri, 02 Aug 2024 at 19:40:59 +0800, Blair Noctis wrote:
> Even today, 2 Aug 2024, is 2 months from the effective date. Please
> file bugreports/issues to ask the packages you care about to migrate.
I agree with this part of what you said.
But, not this part:
> Also, even python3.11 is still t
On Wed, 31 Jul 2024 at 19:01:05 +0500, Andrey Rakhmatullin wrote:
> On Wed, Jul 31, 2024 at 09:46:27AM +0100, Simon McVittie wrote:
> > If we want to run upstream test-suites as autopkgtests, then I think
> > ideally we want the same test coverage as autopkgtest-pkg-python,
> >
On Wed, 31 Jul 2024 at 10:00:34 +0100, Simon McVittie wrote:
> Ideally we would have a way to do (1.) *and* (2.).
It looks as though
"Testsuite: autopkgtest-pkg-python, autopkgtest-pkg-pybuild"
is meant to do that, but doesn't currently work (#1042717 and/or #1061620).
smcv
Package: autodep8
Version: 0.28+nmu1
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
Affects: pybuild-plugin-autopkgtest
autodep8 has two modes for testing Python modules:
1. "Testsuite: autopkgtest-pkg-python" generates a simple smoke-test:
install python3-foo and its mandator
On Mon, 29 Jul 2024 at 18:55:26 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jul 29, 2024 at 03:30:39PM +0200, PICCA Frederic-Emmanuel wrote:
> > My use case, is to check that all the Dependencies computer by dh_python3
> > from the build tools are indeed listed in the Depends of the binary package
On Mon, 29 Jul 2024 at 12:07:27 +, Scott Kitterman wrote:
> While I agree that running tests is good, it's not a universally
> reasonable requirement.
I agree. In a project as large as Debian, most requirements similar to
this one at least need the qualifier "... unless there is a reason why
w
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
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 thing
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 interp
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 policy.
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
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 auto-buil
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 is
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 .
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 signifi
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/... ?
>
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
> durin
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 D
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.
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 update,
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
> > * python3-r
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 wh
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
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 really
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 li
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 t
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 d
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 constructe
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 pa
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 def
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
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 for
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 'python-jsonrpc-serve
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 b
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 wi
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 python3.p
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 int
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? I
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
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 w
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 t
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 aro
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 t
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 certainly
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 python-dbus-te
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 (
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.
>
>
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 f
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 t
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
>
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 be
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 setup.
On Sun, 15 Sep 2019 at 23:39:46 +0200, Thomas Goirand wrote:
> reverse-depends takes sometimes forever in Sid for a reason I
> can't figure out. And if I'm not mistaking, that's the only tool we have
> that can check reverse dependencies in a meaningful way. Or is there a
> better way? I've read ot
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
De
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 be
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 assu
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 sh
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 some
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 delib
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,
>
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
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 m
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 packag
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:
> https://wiki.debian.org/Python/GitPackagingPQ
Is this now official pol
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 this
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 th
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 fini
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 th
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 th
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 tim
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 >=
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 w
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
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 specifi
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 maintenan
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=
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
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
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
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, b
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 d
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 develo
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 foo
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:
gi
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 workfl
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 → ../share/mypackage/scri
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
> > date
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
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
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?
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 incompatible
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: it
On 08/12/15 16:50, Nikolaus Rath wrote:
> On Dec 07 2015, Simon McVittie 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 affected by
> thi
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.
T
On 07/08/15 11:30, Sandro Tosi wrote:
> On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw 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 perfect but
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 r
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
On 05/02/15 05:36, Brian May wrote:
> To try and be flexible, lets say I split up some parts of Karaage into
> plugins[2]; I split them up into separate git source, hence separate
> distributable and packages. This is because some plugins are not needed
> by some installations, and require large de
1 - 100 of 136 matches
Mail list logo
