On Sun, Dec 18, 2022 at 07:18:44PM +, c.bu...@posteo.jp wrote:
> Hello,
> a python application isn't a binary but a script. So to invoke such an
> application there need to be a shell script somewhere in PATH that invoke
> that script via python3 interpreter. Imagine an application with a GUI
On Tue, Aug 30, 2022 at 06:02:01PM +0200, PICCA Frederic-Emmanuel wrote:
> > When trying to run tests you should look how does the upstream intend to
> run them.
>
>
> Yes they are building inplace the module like this
>
> from
On Tue, Aug 30, 2022 at 05:26:01PM +0200, PICCA Frederic-Emmanuel wrote:
> Hello Andrey
>
> > Does the same happen when you run the test in the source tree manually?
>
> I do not know
When trying to run tests you should look how does the upstream intend to
run them.
--
WBR, wRAR
On Tue, Aug 30, 2022 at 03:58:26PM +0200, PICCA Frederic-Emmanuel wrote:
> Hello, I am packaging a python extension which use cmake as build system
>
> here the repo
>
> https://salsa.debian.org/science-team/dxtbx
>
> I try to activate the test but this cause this kind of trouble
>
> During
On Sun, Aug 21, 2022 at 04:04:36PM +0300, Dmitry Shachnev wrote:
> Andrey Rahmatullin
>dateparser (U)
Fixing this now, thanks!
Note that in this case nose usage was removed some time ago but the deps
remained, some other packages may be similarly trivial to fix.
--
WBR
On Sun, Jul 24, 2022 at 08:30:42PM +0100, Julian Gilbey wrote:
> On Sun, Jul 24, 2022 at 11:41:56PM +0500, Andrey Rahmatullin wrote:
> > [...]
> > >
> > > I got all of the triplets working, but was then stymied when I tried
> > > to specify Multi-Arch: same i
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> I got all of the triplets working, but was then stymied when I tried
> to specify Multi-Arch: same in the control file. I got a lintian
> warning: multi-arch-same-package-calls-pycompile
> It seems that since the pybuild system (via
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> > > > > I'd like to ask for some help. I'm working on packaging pydevd, which
> > > > > builds a private .so library. Ordinary extensions built using cython
> > > > > or similar end up being called
On Thu, Jun 09, 2022 at 10:43:01AM +0100, Julian Gilbey 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.
> >
> >
On Thu, Jun 09, 2022 at 09:56:42AM +0100, Julian Gilbey wrote:
> > [...]
> > > Well, the upstream wanted to compile two versions of the library, one
> > > for 64 bit architectures and one for 32 bit architectures. I don't
> > > really want to build two different arch libraries in a single build,
On Thu, Jun 09, 2022 at 08:42:28AM +0100, Julian Gilbey wrote:
> > > I'd like to ask for some help. I'm working on packaging pydevd, which
> > > builds a private .so library. Ordinary extensions built using cython
> > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> > >
On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> I'd like to ask for some help. I'm working on packaging pydevd, which
> builds a private .so library. Ordinary extensions built using cython
> or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> but this
On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
> > Does the package *work* at all in 3.10? We might not want to silence
> > real errors here...
>
> Upstream says 3.4-3.9 is supported, but I don't know if that's because 3.10
> doesn't work or because they haven't bothered to add it.
On Sat, May 28, 2022 at 06:39:56PM +0430, Danial Behzadi wrote:
> Hey folks,
>
> I recently uploaded my python app to deb-expo. As this is my first
> packaging experience in Debian, I would love to get some feedback on my
> packaging to make it better.
>
> Here is my package:
On Mon, May 23, 2022 at 10:02:09AM +0200, Jean Baptiste Favre wrote:
> Hello,
> Looking to help to package Frescobaldi 3.2 release, which includes Python
> 3.10 compatibility fixes, I figured out 3.2 release introduces a new
> dependency against qpageview [1] which is currently not packaged in
On Sat, Apr 30, 2022 at 01:38:02PM +0430, دانیال بهزادی wrote:
> Hey,
>
> I recently sent an [ITP request](1) of [my python package](2) to wnnp and
> they told me to send it here.
>
> I'm not familiar to the workflow here yet. What should I do to include this
> app (and my other packages) in
On Fri, Jan 28, 2022 at 09:48:00PM +0100, Andreas Tille wrote:
> Hi,
>
> I need python-subby as a new dependency for some Debian Med package.
> Unfortunately it does not build easily[1]:
>
>dh_auto_build -O--buildsystem=pybuild
> E: pybuild pybuild:367: build: plugin flit failed with:
On Tue, Dec 14, 2021 at 09:17:31PM +0100, Andreas Tille wrote:
> I think I've fixed the issue[1] and it works nicely at command line.
> Unfortunately
> Salsa-CI[2] shows a new issue
>
>AttributeError: module 'importlib' has no attribute 'util'
You should explicitly import modules that you
On Wed, Dec 01, 2021 at 04:57:44PM +, Julian Gilbey wrote:
> Hello!
>
> pybuild is magic. It knows where the build directory is, despite it
> seemingly calling setup.py with no command line arguments specifying
> it!
>
> But anyway, my actual question is this. How do I ensure that the data
On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
> ERROR: py310: could not install deps [django>=2.2.*, pytest, pytest-cov,
> pytest-django, pytest-xdist]; v =
> InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install
> 'django>=2.2.*' pytest pytest-cov
Package: ftp.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org, rodrilopez@gmail.com
Severity: normal
This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its FTBFS actually suggests it doesn't work with modern
celery, this was fixed upstream
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, david.vi...@gmail.com
This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. The test failures aren't fixed upstream, and
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, va...@debian.org
This package wasn't updated for the Python 3.9 transition. It was removed
from testing even earlier than that, on 2019-10-19. It's not installable
as it requires Python 3.7 or 3.8.
The FTBFS
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, fl...@debian.org
This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-12-11. Its FTBFS actually suggests it doesn't work with modern
celery, the upstream bug is
On Mon, Nov 22, 2021 at 01:27:23PM +0100, Andreas Tille wrote:
> Hi,
>
> I think I've found a patch[1] to solve the original issue which just
> seems to be a floating point precision issue. However, meanwhile there
> is another less simple issue:
>
> ERRORS
On Fri, Nov 19, 2021 at 03:54:48PM +0100, Taihsiang Ho (tai271828) wrote:
> [5] Some of the error messages from latest package source:
>
> short test summary info
>
> FAILED
On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:
> I have a package (pyraf) where I need to switch off some tests for i386
> (but not for other 32-bit platforms). I do this by
>
> import platform
> is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')
Yup, this is
On Mon, Oct 11, 2021 at 12:23:31PM +, c.bu...@posteo.jp wrote:
> I am not sure if I misunderstand something or if the documentation is
> inconsistent.
>
> The PythonPolicy
> https://www.debian.org/doc/packaging-manuals/python-policy/
> tells me that dh_python should be the preferred tool for
On Tue, Sep 28, 2021 at 05:06:01PM +0200, Eberhard Beilharz wrote:
> It (build-)depends on packages with these RC bugs:
> 994354: python-gevent: Removal of the python3-*-dbg packages in sid/bookworm
> https://bugs.debian.org/994354
Please read these lines again.
--
WBR, wRAR
signature.asc
On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> I dont think this is the right approach: the default options to work
> on DPT
On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
>
> thanks for your quick feedback!
>
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
>
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by
On Sat, May 22, 2021 at 10:39:06PM +0200, Fabrice Bauzac-Stehly wrote:
> I have followed the procedure to be able to contribute within the Debian
> Python team some time ago, and I now have permissions related to the
> Debian Python team.
Then you can contribute directly, at least to the packages
On Thu, May 06, 2021 at 01:16:40AM +0530, Utkarsh Gupta wrote:
> Hello,
>
> On Thu, May 6, 2021 at 12:33 AM Sandro Tosi wrote:
> > that's correct, the package still needs to be on PyPI, as that's the
> > place where py2dsp obtains most of the package metadata
>
> Can we change that or have a
On Thu, May 06, 2021 at 12:08:06AM +0530, Utkarsh Gupta wrote:
> However, I am running into an issue (or I guess I am just not doing it
> correctly).
> Whilst trying to package from the g/h source
> (https://github.com/keylime/keylime), it fails like this:
> http://paste.debian.net/1195339/
>
>
On Mon, Apr 19, 2021 at 11:12:01AM +0200, Arturo Borrero Gonzalez wrote:
> There may be 2 other options:
> * I could ask ftp-masters to drop my upload, not sure if that's something
> they can do. [spoiler: on IRC #debian-ftp they pointed me to talk to you]
It's already in sid:
On Fri, Apr 16, 2021 at 03:46:45PM +0200, Lorenz Schori wrote:
> Hi,
>
> I updated proxmoxer to upstream 1.1.1 (latest stable release). I've
> pushed debian/master, upstream and pristine-tar branches now to salsa.
>
> I did a smoke test (debian/rules clean, debian/rules build,
> debian/rules
On Fri, Mar 26, 2021 at 10:01:54AM +, PICCA Frederic-Emmanuel wrote:
> > Hello,
>
> > I’d suggest you build it from source (python.org/ftp... with the needed
> > version) as an additional python version, and then create your venv using
> > the 3.6.
>
> > You can dm me if you might need
On Fri, Mar 26, 2021 at 09:55:03AM +0800, Robbi Nespu wrote:
> Dear Debian Python,
>
> I would like to install older python (version 3.6) on my venv environment
>
> $ inxi -S
> System:Host: debian Kernel: 5.10.0-4-amd64 x86_64 bits: 64 Desktop: KDE
> Plasma 5.20.5
>Distro: Debian
On Wed, Mar 03, 2021 at 05:39:04PM +, Stefano Rivera wrote:
> You need python3.8-venv.
Which doesn't exist, at least in the current repos.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Wed, Mar 03, 2021 at 08:32:01AM -0500, Yaroslav Halchenko wrote:
> > I'm trying to use a (non-Debian) python system built on python 3.8.
> > Debian's
> > default is currently 3.9 so I am advised to use a virtual environment.
> > Being
> > a newbie, I searched around and found a writeup
It looks like the only sane way to use non-default Python versions is to
build them locally using pyenv.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Wed, Feb 17, 2021 at 11:51:52AM +1100, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
>
> e.g.
>
> https://qa.debian.org/developer.php?login=bam%40debian.org=yes
>
> Somebody needs to do the work to
On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote:
> > I *wish* I could
> > just install everything via the Debian Packaging System, but the reality for
> > most relevant Python packages is very different: packages are either
> > outdated or do not exist in Debian
>
> Are you talking about
On Sat, Dec 12, 2020 at 01:56:46PM +0100, Nyírő Balázs wrote:
> Can you help me to give the steps
> that how can a new project be placed in Debian repos?
https://mentors.debian.net/intro-maintainers/ has the outline. But please
note the "Please do not treat Debian as a platform to advertise your
On Tue, Dec 08, 2020 at 09:44:51PM +0100, Andreas Tille wrote:
> > https://github.com/nipy/nipy/issues/461
>
> As far as I can see that's included into 0.4.3~rc1.
If by "it" you mean requiring sympy older than the Debian one then yes.
But the package evidently doesn't enforce this requirement.
On Tue, Dec 08, 2020 at 09:33:03PM +0100, Peter Wienemann wrote:
> Dear Python experts,
>
> in trying to update the python-lark package [0] to the most recent upstream
> version, an interesting issue regarding unit tests showed up [1]. Depending
> on how one runs unit tests they either fail or
On Tue, Dec 08, 2020 at 07:02:22PM +0100, Andreas Tille wrote:
> TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add'
Consider starting to use Google to find at least some info related to
questions you ask.
https://github.com/nipy/nipy/issues/461
--
WBR, wRAR
signature.asc
On Tue, Dec 08, 2020 at 01:27:57PM +0100, Andreas Tille wrote:
> test-data/samples/crawl.py:750: error: "yield from" can't be applied to
> "Condition"
> test-data/samples/crawl.py:772: error: "yield from" can't be applied to
> "Semaphore"
> test-data/samples/crawl.py:778: error: "yield from"
On Sat, Dec 05, 2020 at 06:29:32PM +0100, Martin wrote:
> The fix in wokkel should not lead to a problem after the next upload of
> python3-pycryptodome.
I disagree. Currently wokkel clearly has a problem and it's most lilely a
typo. If python3-pycryptodome will be renamed to python3-cryptodome,
On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote:
> Dears,
>
> I'm a little confused about what the correct name for the
> binary package python3-pycryptodome should or will be.
Depends on the module name it provides.
So python3-cryptodome, it seems.
> Because
On Sat, Oct 31, 2020 at 12:03:50PM +0100, Thomas Goirand wrote:
> Pypi is often thought as a Python module source repository. It is *NOT*.
> It is a repository for binaries to be consumed by pip.
Oooh, that's a very interesting thought I never considered.
--
WBR, wRAR
signature.asc
On Fri, Oct 30, 2020 at 03:18:58PM +0100, Fioddor Superconcentrado wrote:
> As I said I'm very new to this and all (python) packages I'm using lately
> use the usual python tools (pipy, setup.py, etc) and my first approach has
> been to stick as close as possible to the upstream procedures. But I
python/gubbins/common.py::parse_and_run() constructs an absolute path for
the executable and then passes it to pkg_resources.get_distribution(). I
have no idea what does this code want to achieve, as get_distribution()
takes requirement specifications, not file paths.
--
WBR, wRAR
On Mon, Oct 26, 2020 at 08:54:37AM +0100, Stephen Sinclair wrote:
> The recommendations are to change the build-dep on "python-dev" to
> "python-all-dev", and I can confirm that this does allow the package
> to build. (Is this the right thing to do?)
Building a module for all supported Python
On Sun, Oct 04, 2020 at 05:39:16PM +0200, Fioddor Superconcentrado wrote:
> Debian's packaging documentation requires the packages containing python3
> apps to be renamed with a python3 suffix.
*apps* shouldn't have a prefix, only modules should.
> Now I can put that prefix to the source too or
On Sun, Oct 04, 2020 at 05:28:57PM +0200, Fioddor Superconcentrado wrote:
> I've packaged a project provided via https://pipi.org and I wanted to
> create a debian/watch file but pipi.org publishes the tarball behind a
> strange url like
>
>
Can you please also describe the current plans for changing/not changing
the Git paths after the merge?
--
WBR, wRAR
signature.asc
Description: PGP signature
On Wed, Jul 08, 2020 at 03:35:19AM -0300, Pablo Mestre wrote:
> Hi
>
> Im start packaging python-jsonrpc-server[1], but im dealing with an
> lintian warning thats I dont understand
>
> W: python-jsonrpc-server source: mismatched-python-substvar
> python-jsonrpc-server ${python3:Depends}
> N:
>
On Mon, May 18, 2020 at 11:24:23AM +0200, jojo wrote:
> One question: Often I read the workflow is to first create a source
> package and then the binary package from it. Is that true for python
> tools as well?
Yes.
> I mean there is no "source/binary" in this sense.
It doesn't matter whether
On Mon, Apr 27, 2020 at 01:17:50PM +0200, Andreas Tille wrote:
> pkg_resources.DistributionNotFound: The 'sklearn' distribution was not found
> and is required by pauvre
It's actually called scikit-learn, not sklearn, see e.g.
/usr/lib/python3/dist-packages/scikit_learn-0.22.2.post1.egg-info and
On Fri, Apr 17, 2020 at 08:10:34AM +, PICCA Frederic-Emmanuel wrote:
> subsidiary question is it possible to run a command before all the
> dh_auto_xxx without overrideing eveythings ?
See "Injecting commands before or after a step" in dh(1).
--
WBR, wRAR
signature.asc
Description: PGP
On Fri, Apr 17, 2020 at 07:31:55AM +, PICCA Frederic-Emmanuel wrote:
> Hello, I have a packahe where the setup.py is not located at the root of the
> directory.
>
> So I need to do
>
> override_dh_auto_XXX:
> dh_auto_XXX -- -d
>
> Is there a export somthing whcih allows to says where
On Sun, Apr 12, 2020 at 03:18:39PM +0200, picca wrote:
> I thought about adding rpath to these libraries in order to move then
> under a private location /usr/lib/.
This looks like the correct way to solve this.
> The issue is that the current build system do not provide rpath for
> these
On Tue, Apr 07, 2020 at 08:13:02PM +0200, Alex Mestiashvili wrote:
> Hi Debian Python folks,
>
> Is there a good entry point for a newbie who wants to package a python
> module? I am looking for a tool similar to dh-make-perl. In the past
> I've been using stdeb as far as I remember, but it is
On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> >From the logs, in the last message[2] it looks like an import-error for
> '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> provide) package. When I dug into looking at libsbml, I noticed that the
> relevant
On Wed, Mar 25, 2020 at 08:31:10PM +0100, Andreas Tille wrote:
> Hi Python folks,
>
> the Debian Med team intends to package multiqc[1]. When running the build
> time tests I get:
>
>
> ...
>debian/rules override_dh_auto_test
> make[1]: Verzeichnis „/build/multiqc-1.8+dfsg“ wird betreten
>
On Thu, Feb 27, 2020 at 05:02:32PM +0100, Julien Puydt wrote:
> > https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> >
>
> I must be going through a very bad day, but trying to follow
> https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
> the
On Thu, Feb 27, 2020 at 12:57:49PM +0100, Julien Puydt wrote:
> Le jeudi 27 février 2020 à 15:49 +0500, Andrey Rahmatullin a écrit :
> > On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> > > Hi,
> > >
> > > I saw python3-itsdangerous
On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> Hi,
>
> I saw python3-itsdangerous was far behind upstream, and decided to if
> it was easy to update : but it's not on salsa.
>
> Should I import the last known package version (recent upload to remove
> the Python 2 package) to a
On Wed, Feb 26, 2020 at 12:14:08PM +, Ian Jackson wrote:
> I looked again and I was looking at an old version. Sorry for the
> noise. I still think we have problems with these
> 937132 nevow: Python2 removal in sid/bullseye
> 938622 tahoe-lafs: Python2 removal in sid/bullseye
> which I
On Wed, Feb 26, 2020 at 11:28:03AM +, Ian Jackson wrote:
> FYI. The widespread impact of this not so apparent because
> git-buildpackage is typically used ad-hoc by maintainers, rather than
> via (Build)-Depends.
>
> Relevant packages and bugs:
> 943107 git-buildpackage: Python2 removal in
On Mon, Feb 03, 2020 at 02:32:22PM +, PICCA Frederic-Emmanuel wrote:
> Hello,
>
> I am packaging a python application . So I dediced to put the module under
> the private directory
>
> /usr/share/
>
> but this software contain a cython extension.
>
> So at the end I have a lintian Error
On Wed, Jan 22, 2020 at 06:59:18PM +0100, Julien Puydt wrote:
> Le mercredi 22 janvier 2020 à 21:04 +0500, Andrey Rahmatullin a écrit :
> > On Wed, Jan 22, 2020 at 04:53:22PM +0100, Julien Puydt wrote:
> > > Hi,
> > >
> > > I'm trying to solv
On Wed, Jan 22, 2020 at 04:53:22PM +0100, Julien Puydt wrote:
> Hi,
>
> I'm trying to solve this bug on python3-setuptools-scm :
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928156
>
> where the problem is :
> - python3-setuptools-scm depends on python3-distutils
> - python3-distutils
On Mon, Dec 16, 2019 at 11:07:07AM +0100, Andreas Tille wrote:
> I'm afraid 2to3 skipped this very file. I retried manually:
>
> $ 2to3 -w roundTripNCLTest.py
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping
On Mon, Dec 16, 2019 at 09:17:50AM +0100, Andreas Tille wrote:
> inputParentPath = lineIter.next().strip()
> AttributeError: '_io.StringIO' object has no attribute 'next'
This should be changed to next(lineIter).strip(), 2to3 for some reason
missed it.
--
WBR, wRAR
signature.asc
On Fri, Dec 13, 2019 at 10:10:03PM +0100, Andreas Tille wrote:
> i$ pdb2pqr
> Traceback (most recent call last):
> File "/usr/bin/pdb2pqr", line 52, in
> from main import mainCommand
> File "/usr/share/pdb2pqr/main.py", line 77, in
> import extensions
> File
On Fri, Dec 13, 2019 at 03:49:22PM +0100, Andreas Tille wrote:
> > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so
> > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib
> > -lpython3.7m -lpython3.7
> > /usr/bin/ld: cannot find -lpython3.7
> >
On Fri, Dec 13, 2019 at 01:40:34PM +0100, Andreas Tille wrote:
> > > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so
> > > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os
> > > -L/usr/lib -lpython3.7
> > > /usr/bin/ld: cannot find -lpython3.7
> > Actually,
On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so
> -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib
> -lpython3.7
> /usr/bin/ld: cannot find -lpython3.7
Actually, it's a different
On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> So how can I enable proper linking to -lpython3.7 which is obviously not
> in the library search path (but package libpython3.7 is definitely
> installed in the pbuilder chroot).
To link to a library you need to install its -dev
On Sat, Dec 07, 2019 at 09:23:16PM +0100, Andreas Tille wrote:
> I tried to port consensuscore to Python3 in Git[1]. Unfortunately 2to3
> was not completely successfully since I get:
This isn't 2to3's fault.
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3.8
Why are you running tests via PYBUILD_SYSTEM=custom
PYBUILD_TEST_ARGS="{interpreter} setup.py test"? Is the pytest one not
working?
--
WBR, wRAR
signature.asc
Description: PGP signature
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
The only release was in 2005. https://www.python.org/dev/peps/pep-0754/
was abouyt including it into stdlib and it failed.
The only revdep, jack-mixer, was recently removed from the archive.
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Not needed with Py3 and not used by any package in Debian anymore.
Popcon 82.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Sun, Nov 17, 2019 at 04:29:56PM +0100, Andreas Tille wrote:
> > If you look on the numpy tracker page [1], you'll see there is a note:
> >
> > "This package is part of the ongoing testing transition known as
> > python3.8. Please avoid uploads unrelated to this transition, they
> > would
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
https://pypi.org/project/adns-python/ no new releases since 2007.
Popcon 544, because of transmission-remote-cli which was recently removed
from the archive.
Reverse deps checked with dak rm -Rnb
On Thu, Oct 24, 2019 at 08:49:41AM +0100, Simon McVittie wrote:
> in general we
> also consider broken Recommends to be a serious bug if anyone notices
> them (due to Policy §2.2.1 "must not require or recommend a package
> outside of main for compilation or execution").
Note that the release
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
http://www.alittletooquiet.net/software/sclapp/ is dead.
The current upstream code was uploaded to Debian in 2008.
Reverse deps checked with dak rm -Rnb python-sclapp
--
WBR, wRAR
signature.asc
On Mon, Oct 14, 2019 at 09:54:18AM -0400, Sandro Tosi wrote:
> i think it's a bit premature to raise severity to RC (we should also
> check with the release team): these bugs have been opened since just 2
> months and a half, and the development cycle for bullseye started not
> longer before.
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Last release in 2009. http://python-rum.org/wiki/WebFlash is dead.
Reverse deps checked with dak rm -Rn python-webflash
--
WBR, wRAR
signature.asc
Description: PGP signature
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Long dead. "Myghty is a legacy library. New projects should use Mako
templates". Last release in 2010.
Reverse deps checked with dak rm -Rn myghty pylons webhelpers
--
WBR, wRAR
signature.asc
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Part of the Pylons stack. Last release in 2016, but no Python 3 support
anyway. "This software is not actively maintained. Simple bugfixes and
other patches will be accepted, and released."
Reverse
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Pylons is dead and Python2-only. The only revdep is python-webhelpers.
Reverse deps checked with dak rm -Rn pylons webhelpers
--
WBR, wRAR
signature.asc
Description: PGP signature
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
Part of the Pylons stack, last release in 2011.
Reverse deps checked with dak rm -Rn pylons webhelpers
--
WBR, wRAR
signature.asc
Description: PGP signature
On Sat, Sep 21, 2019 at 10:18:16AM +0100, Rebecca N. Palmer wrote:
> Some Python 2 packages have circular (build-)dependencies, making it
> impossible to remove them one at a time without breaking anything.
Unless I'm missing something, this shouldn't be a problem, just go away
and remove them all
Note that dak doesn't check autopkgtest deps. I'm using
grep-dctrl -FTestsuite-triggers $pkg -sPackage
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
for that.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Fri, Sep 13, 2019 at 10:04:12PM +0200, Andreas Tille wrote:
> try:
> ttk
> Tkinter
> except NameError:
> sys.exit("Need the following installed: Tkinter, tkFileDialog, ttk")
>
>
> I have no idea what the call to tkk is supposed to do
Checking that the name exists.
> and why it
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
https://pypi.org/project/EnthoughtBase/ is dead and I cannot find the new
source. The current upstream source was uploaded to Debian in 2011.
Popcon is 203, not sure why. It has only a reverse
On Fri, Sep 13, 2019 at 05:16:30PM +0800, Drew Parsons wrote:
> Python maintainers, remember, check your reverse dependencies before
> dropping your python2 packages.
> Check each of
>
> build-rdeps python-yourmodule
> apt-rdepends -r python-yourmodule
>
> and confirm the package has rdeps=0
1 - 100 of 225 matches
Mail list logo
