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 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, 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 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 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, 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 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 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 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
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 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: 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, 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.
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 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
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, 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 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 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 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 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, 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 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, 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 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 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, 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
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 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
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 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 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 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'd like to join the python-modules team, in order to co-maintain
python-docutils with Martin F. Krafft. My Alioth login is smcv-guest.
I'm currently preparing an upload which will fix some of the old bugs
and use the new Python policy.
Thanks,
Martin F. Krafft and I recently adopted python-docutils, and I've updated
it to the new policy.
I've been waiting for feedback from Martin, but since an upload is needed
for the policy transition, perhaps someone else could look at it? There
are quite a lot of changes, since I went through some ol
On Fri, 30 Jun 2006 at 19:00:02 +0200, Mike Hommey wrote:
> On Fri, Jun 30, 2006 at 06:43:22PM +0200, Josselin Mouette <[EMAIL
> PROTECTED]> wrote:
> > Le vendredi 30 juin 2006 à 17:38 +0200, Mike Hommey a écrit :
> > > On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette <[EMAIL
> > > PROT
Control: tags -1 + upstream moreinfo
Control: forwarded -1
https://github.com/projectmallard/mallard-ducktype/issues/21
On Fri, 04 Oct 2024 at 11:22:32 +0100, Colin Watson wrote:
> While pkg_resources is indeed deprecated upstream, there's nothing that
> we can sensibly do about it at the Debian
On Thu, 03 Oct 2024 at 15:54:16 +, James Addison wrote:
> I'd like to request an upload of the src:meson-python package, in
> particular to close bug #1076806, a reproducibility bug related to
> documentation copyright notices
Done, but I'm curious why making this particular package reproducib
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
> I guess whether "upstream name or python-$modulename" would seem fine,
> depends on what "upstream name" is. I guess if the latter is something
> like "py" or some widely known sub-ecosystem that is
> really very much python-specific, an
On Fri, 04 Oct 2024 at 09:41:45 -0700, Soren Stoutner wrote:
> The bug report doesn’t explain exactly what aspect doesn’t
> comply with the policy, but I assume it comes down to python3-trezor
> installing to the following two directories, which have disparate names:
>
> /usr/lib/python3/dist-pa
On Thu, 05 Dec 2024 at 19:00:50 -0700, Soren Stoutner wrote:
> I am working on PyInstaller, which is mostly written in Python, but compiles
> a
> bootloader written in c. blhc failes because the [logs] do not contain
> verbose
> compile flags.
You'll need to look at the implementation of the
On Fri, 31 Jan 2025 at 18:45:22 +0100, Alexandre Detiste wrote:
> The very existence of "*/debian/tests/control: @builddeps@,"
> may contribute to hiding a lot of undeclared python3-pkg-res-sources
> dependencies,
> because it would be pulled-in anyway by python3-setuptools at autopkgtest
> but not
rhythmdb" fails.
I've reported a separate bug for that.
Thanks,
smcv
>From f69c58eda0492a21cd760249e1fe1eda32aa4685 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Tue, 21 Jan 2025 10:47:19 +
Subject: [PATCH] d/control: Remove transitional dependency on
python3-setuptoo
Package: wnpp
Severity: wishlist
Owner: Simon McVittie
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-tap (binary: python3-pytest-tap)
Version : 3.4
Upstream Contact: Matt Layman
* URL : https://pypi.org/project
On Thu, 27 Feb 2025 at 11:02:46 +, Simon McVittie wrote:
> On Thu, 27 Feb 2025 at 10:49:04 +0100, Andreas Tille wrote:
> > gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not
> > found
>
> Is the new upstream version perhaps n
On Thu, 27 Feb 2025 at 10:49:04 +0100, Andreas Tille wrote:
> autopkgtest [08:21:22]: test autodep8-python3: set -e ; for py in
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with
> $py:" ; $py -c "import gi.overrides.v_sim; print(gi.overrides.v_sim)" ; done
...
>
On Thu, 27 Feb 2025 at 12:38:16 +0100, Alexandre Detiste wrote:
> I ve my own take on this: I would MBF the (expected few) remaining users of
> /usr/share/cdbs/1/class/gnome.mk
> and then get rid of this one cdbs module.
In general I'm in favour of conversion of packages from cdbs to dh, but if
my
Control: retitle -1 python-policy: Suggest conventional namespacing for Python
modules' source packages
Control: forwarded -1
https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/19
Control: tags -1 + patch
On Fri, 18 Oct 2024 at 15:07:35 +0100, Simon McVittie wrote:
O
On Tue, 01 Jul 2025 at 10:42:19 +0200, Carsten Schoenert wrote:
Am 01.07.25 um 09:59 schrieb Aryan Karamtoth:
...
So my question is should I rename the source field to “python3-
packagename” too or will it cause any conflicts?
The source package ("Source:") should not be prefixed with "python3
On Mon, 30 Jun 2025 at 06:09:07 +, Aryan Karamtoth wrote:
I'm working on creating a package for a software that's built for GNOME GTK4 +
Libadwaita using Python. The problem is that the software uses a lot of
dependencies mostly python libraries that aren't on debian but only on pip. I
need t
101 - 150 of 150 matches
Mail list logo
