-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
-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 debian/cha
-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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 Apr 2008 at 22:04:58 +1000, Ben Finney wrote:
> "Sandro Tosi" <[EMAIL PROTECTED]> writes:
> > the repository it's already on Alioth, and it's called PAPT[1] ;)
>
> Unfortunately (as made clear
> in a conversation earlier this evening), the
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
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 nobo
table of that name (the Packages file is big enough already),
but it might be worth mentioning "scripts like rst2html and rst2latex",
or some similar wording, in the Description.
> Simon McVittie writes:
> > Unrelated to 0.6, I've been thinking about handing over
> >
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 odtwrit
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 docutil
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-gobjec
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 u
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
so
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 build-de
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 and
On 30/01/12 05:57, Scott Kitterman wrote:
> The binary name we ended up with is python3-dbus.mainloop.qt, so the python3-
> dbus recommends will need updating in your next upload
Fixed in git, thanks.
I'll remove the python-dbus -> python-dbus-dev dependency when this
version of python-qt4 reache
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 rel
On 20/03/12 23:16, Fernando Lemos wrote:
> Forks that simply suffix "2" are a really poor idea.
Yes, this.
> * Is the python-mpd upstream unresponsive? It looks like Alexander
> will stop actively maintaining python-mpd soon, but he doesn't support
> the fork for a number of valid reasons that ha
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 e
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 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"
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/openastr
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 manua
On 07/11/12 16:06, Tomás Di Domenico wrote:
> On 07/11/12 16:43, Jakub Wilk wrote:
>> * Tomás Di Domenico , 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 Mercurial repos
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 sque
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
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 plai
On 19/08/14 09:33, Matthias Klose wrote:
[Nikolaus Rath wrote:]
>> That's a bug in the test (race condition) rather than in the program.
>> It's fixed upstream.
>
> [...] If you don't care
> about the autopkg tests, and if you are not ready to fix these but rather wait
> for the fixes from upstrea
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 simp
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 g
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 main
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
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
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 cont
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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, 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 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
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
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
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
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 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
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 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
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 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, 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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
1 - 100 of 147 matches
Mail list logo
