Package: wnpp
Severity: wishlist
Owner: Julian Gilbey
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-mypy-testing
Version : 0.1.3
Upstream Author : Copyright: David Fritzsche
* URL : https://github.com/davidfritzsche
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-console-scripts
Version : 1.4.1
Upstream Author : Vasily Kuznetsov
* URL : https://github.com/kvas-it/pytest
On Wed, Mar 27, 2024 at 11:36:55AM +0100, Timo Röhling wrote:
> Hi,
>
> Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey :
> >I'm stymied by a pytest-related bug. I thought it was a bug in a
> >particular pytest plugin (pytest-order), but it's now shown up in
> >an
On Wed, Mar 27, 2024 at 11:36:55AM +0100, Timo Röhling wrote:
> Hi,
>
> Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey :
> >I'm stymied by a pytest-related bug. I thought it was a bug in a
> >particular pytest plugin (pytest-order), but it's now shown up in
> >an
Hi,
Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey :
>I'm stymied by a pytest-related bug. I thought it was a bug in a
>particular pytest plugin (pytest-order), but it's now shown up in
>another pytest plugin as well, so I wonder if either there's a bug in
>pytest 8.x or some
I'm stymied by a pytest-related bug. I thought it was a bug in a
particular pytest plugin (pytest-order), but it's now shown up in
another pytest plugin as well, so I wonder if either there's a bug in
pytest 8.x or something subtle has changed that requires a
modification to the plugins. I
Package: wnpp
Severity: wishlist
Owner: Julian Gilbey
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-jupyter
Version : 0.9.1
* URL : https://github.com/jupyter-server/pytest-jupyter
* License : BSD-3-clause
Control: tags -1 pending
Hi,
I've fixed the issue reported in the bug in Git. However, Salsa CI
shows another issue[1]:
if _is_instance_mock(spec):
> raise InvalidSpecError(f'Cannot spec a Mock object.
> [object={spec!r}]')
E mock.mock.InvalidSpecError: Cannot spec
Am Mon, Jan 29, 2024 at 02:29:28PM +0300 schrieb Dmitry Shachnev:
>
> I have seen a similar problem in https://bugs.debian.org/1052802 and solved
> it by disabling dh_auto_clean completely.
I've found another solution by trying hard to keep te .egg-info dirs
(in a tarball inside debian/ dir and
Hi,
On Sun, Jan 28, 2024 at 08:27:12PM -0500, Scott Talbert wrote:
> I suspect the issue is because dh-python is clobbering the *.egg-info
> directories in the tests directory during the 'clean' target.
>
> While this is helpful in a lot of cases, it would be nice if there was a way
> to opt out
On Sun, 28 Jan 2024, Andreas Tille wrote:
Hi,
I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.
I suspect the issue is because dh-python is clobbering the *.egg-info
directories in the tests directory during the 'clean' target.
While this is
Hi,
I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.
Kind regards
Andreas.
--
http://fam-tille.de
On Sat, 27 Jan 2024, Andreas Tille wrote:
Control: tags -1 help
Hi,
I upgraded python-miio in Git. Unfortunately there are some test suite
errors[1]
Any help would be welcome
Andreas.
Fixed.
Control: tags -1 help
Hi,
I upgraded python-miio in Git. Unfortunately there are some test suite
errors[1]
Any help would be welcome
Andreas.
[1] https://salsa.debian.org/python-team/packages/miio/-/jobs/5212674
--
http://fam-tille.de
Hi Timo,
And the transition is now complete :-)
Best wishes,
Julian
On Tue, Jan 09, 2024 at 05:45:04PM +, Julian Gilbey wrote:
> Hi Timo,
>
> Please can we hold back on uploading pytest 8 to unstable until the
> current Python 3.12 transition is complete? It is entir
Hi Stefano,
Am Thu, Jan 11, 2024 at 08:25:46PM + schrieb Stefano Rivera:
>
> The test is expecting the module to be installed in the test
> environment. Either we could try harder to emulate that, or skip the
> tests.
I admit I tried to copy around the module before running the test with
no
Hi Andreas (2024.01.11_17:48:43_+)
> I've fixed the two other bugs in python-pkginfo and upgraded to latest
> upstream. Unfortunately I have no clue about this issue.
The test is expecting the module to be installed in the test
environment. Either we could try harder to emulate that, or skip
Control: tags -1 help
Hi,
I've fixed the two other bugs in python-pkginfo and upgraded to latest
upstream. Unfortunately I have no clue about this issue.
Any idea what might be wrong here?
Kind regards
Andreas.
--
http://fam-tille.de
Control: tags -1 help
Hi,
I tried the suggested patch for the cython3 issue of bug #1056872
in the currently packaged version[1] as well also tried upgrading
to latest upstream and tried building[2] which failed as well.
I admit, I'm running out of ideas what to do next.
Any help is welcome
Hi Julian,
* Julian Gilbey [2024-01-09 17:45]:
Please can we hold back on uploading pytest 8 to unstable until the
current Python 3.12 transition is complete?
Sure! I'll keep it in experimental, and we can check what still
needs fixing after the Python 3.12 dust has settled.
Cheers
Timo
On 2024-01-09 12:45, Julian Gilbey wrote:
Hi Timo,
Please can we hold back on uploading pytest 8 to unstable until the
current Python 3.12 transition is complete? It is entirely possible
that several of the packages that currently break with pytest 8
already have newer upstream versions
Hi Timo,
Please can we hold back on uploading pytest 8 to unstable until the
current Python 3.12 transition is complete? It is entirely possible
that several of the packages that currently break with pytest 8
already have newer upstream versions that address these issues, but
it's probably
Hi,
I recently uploaded the pre-release pytest 8.0.0~rc1 to experimental
as an early warning for the breaking changes which typically happen
on major version bumps.
I've attached a dd-list of packages which exhibit autopkgtest
regressions [1], with the intent of MBF'ing (with separate
Le 04/01/2024 à 11:51, Thomas Goirand a écrit :
On 1/4/24 00:30, Alexandre Detiste wrote:
The better solution is to remove python3-future altogether.
I very much agree with this. Most of the time, it's simply patching out
stuff like:
from __future__ import
Not quite:
- __future__
On 1/4/24 00:30, Alexandre Detiste wrote:
Le lun. 11 déc. 2023 à 16:43, Andreas Tille a écrit :
Control: tags -1 help
[Bug #1056419 in CC since the issue seems to be caused by python-future]
Hi Vincent,
I tried to upgrade python-future to the latest upstream version in the
hope that this
Hi,
Thank you very much for looking into this, it is much appreciated and you can
go ahead with the upload.
Ana
On Thu, Jan 4, 2024, at 12:19 PM, Alexandre Detiste wrote:
> Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit :
>> > @Vincent: this one package "gtextfsm" is yours
>> > do you
ok for me
- Le 4 Jan 24, à 13:19, Alexandre Detiste alexandre.deti...@gmail.com a
écrit :
> Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit :
>> > @Vincent: this one package "gtextfsm" is yours
>> > do you green light an upload ?
>>
>> If you ask me the package is team maintained and a
Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit :
> > @Vincent: this one package "gtextfsm" is yours
> > do you green light an upload ?
>
> If you ask me the package is team maintained and a "Team upload"
> should be fine.
Hi, I just try to follow the rules I agreed on last month.
Hi Alexandre,
Am Thu, Jan 04, 2024 at 12:30:21AM +0100 schrieb Alexandre Detiste:
>
> There might be some nmu needed too if maintainers don't react.
>
> @Vincent: this one package "gtextfsm" is yours
> do you green light an upload ?
If you ask me the package is team maintained and a "Team
On 2024-01-04 00:30, Alexandre Detiste wrote:
@Vincent: this one package "gtextfsm" is yours
do you green light an upload ?
Yes.
Le lun. 11 déc. 2023 à 16:43, Andreas Tille a écrit :
> Control: tags -1 help
>
> [Bug #1056419 in CC since the issue seems to be caused by python-future]
>
> Hi Vincent,
>
> I tried to upgrade python-future to the latest upstream version in the
> hope that this would solve the issue reported in
Hi Alexandre,
Am Mon, Dec 11, 2023 at 09:18:16PM +0100 schrieb Alexandre Detiste:
> > https://github.com/lebigot/uncertainties/releases/tag/3.1.7
>
> +1
OK.
> > Also we should probably get rid of python-future at some point.
>
> I removed it from three games this week-end
> and filled 6 more
Le lun. 11 déc. 2023 à 17:02, Jochen Sprickerhof a écrit :
> I think the right thing here is to package the new uncertainties version
> which drops the past import:
>
> https://github.com/lebigot/uncertainties/releases/tag/3.1.7
+1
> Also we should probably get rid of python-future at some
Hi Andreas,
* Andreas Tille [2023-12-11 16:42]:
Control: tags -1 help
[Bug #1056419 in CC since the issue seems to be caused by python-future]
Hi Vincent,
I tried to upgrade python-future to the latest upstream version in the
hope that this would solve the issue reported in bug #1042244.
Control: tags -1 help
[Bug #1056419 in CC since the issue seems to be caused by python-future]
Hi Vincent,
I tried to upgrade python-future to the latest upstream version in the
hope that this would solve the issue reported in bug #1042244.
Unfortunately this is not the case and now with
Hi Yaroslav,
Am Mon, Apr 17, 2023 at 05:59:23PM -0400 schrieb Yaroslav Halchenko:
> Hi Andreas,
>
> Thank you very much for offering help. I think Tiziano would not mind,
> so please feel very welcome to a) for the sake of b) or any other
> goodness you would like to bring ;)
Am Fri, Jan 20, 2023 at 04:24:07PM -0500 schrieb Éric Araujo:
> Le 20/01/2023 à 16:21, FC Stegerman a écrit :
> > Should that not use "func" instead of "inspect.getframeinfo"?
>
> Yes of course! I tested in a terminal to give valid code and forgot to
> replace my example function with the
Le 20/01/2023 à 16:21, FC Stegerman a écrit :
Should that not use "func" instead of "inspect.getframeinfo"?
Yes of course! I tested in a terminal to give valid code and forgot to
replace my example function with the original variable name. Thanks!
* Éric Araujo [2023-01-20 22:01]:
> tl;dr: replace the body of the try block with this:
>
> argspec = inspect.signature(inspect.getframeinfo)
> argspec = str(argspec).replace('*', '\\*')
> signature = '%s%s' % (func_name, argspec)
Should that not use "func" instead of
Hello,
Le 20/01/2023 à 15:33, Andreas Tille a écrit :
I finally do not have an idea how to replace:
Handler for event
'autodoc-process-docstring' threw an exception (exception: 'FullArgSpec' object has
no attribute 'replace')
which you can find in the latest build log in Salsa CI.
Control: tags -1 help
Hi,
I think I have fixed the numpy 1.24 issues that were causing this build
failure. Unfortunately there are also numpydoc issues and I did not
found documentation about this when doing a web search. I failed
finding something for inspect.formatargspec which I simply
to be consistent with uscan. But I am using the standard tools.
Then for the packaging itself (which is in pretty good shape):
* changelog: please leave the release at UNRELEASED, cf. team policy.
* control:
+ the binary pkg for a pytest plugin is commonly named
python3-pytest-;
+ short
hi Ileana,
I took a look at pytest-fail-slow, up for sponsorship in the Python
team.
Some repo issues:
* It appears tags were not pushed, as there's no tags at all in the
repo - not even for the imported upstream release - although the
typical gbp workflow would handle that.
* The upstream
For the record, I found it..., the upstream modify the HDF5_PLUGIN_PATH when
loading the dxtbx module.
they guess that they are using conda and override the path. All this is useless
on Debian since the plugin are system installed properly.
Cheers
Fred
# Ensures that HDF5 has the conda_base
Hello Neil
> Looks like you need a -v option to see more detail.
thanks for the advices, I found by removing files one by one that the failling
behavious is due to the import of the library itself.
the failing test PASS by himself, but if I add a useless import dxtbx inside,
it failes.
so
_as_flex.py ..F..F..F
>[ 2%]
Looks like you need a -v option to see more detail.
> I put the error message bellow, it is quite long
>
> now If I execute by hand only the failing test like this, it works
>
>
> $ pytest-3 tests/test_dataset_as_flex.py
The 2% indicates that
If I execute by hand only the failing test like this, it works
$ pytest-3 tests/test_dataset_as_flex.py
=
test session starts
A new version of https://tracker.debian.org/pkg/python-model-bakery is
available but it cannot be uploaded as the tests fail with the
pytest-django 3.* series.
https://github.com/model-bakers/model_bakery/issues/311
The new upstream will need pytest-django >= 4.5.2
With pytest itself upda
Le lundi 11 juillet 2022 à 18:37 +0100, Julian Gilbey a écrit :
> [Explanation: britney (?) tries each
> package on its own when testing for migration: pytest can't migrate
> as that would break pygments in testing, and pygments can't migrate
> as it depends on the newer pytest. So
Hi,
On Fri, Jul 08, 2022 at 09:33:10PM +0200, Carsten Schoenert wrote:
> Hi,
>
> Am 16.06.22 um 10:05 schrieb Julian Gilbey:
> ...
> > Great, thanks. Since the pygments in testing fails on pytest 7.2.1,
> > and the version in experimental depends on pytest >
Hi,
Am 16.06.22 um 10:05 schrieb Julian Gilbey:
...
Great, thanks. Since the pygments in testing fails on pytest 7.2.1,
and the version in experimental depends on pytest >= 7.0, we'll need
to do the following when we are ready to upload pytest 7.2.1 to
unstable:
* Mark pytest 7.2.1 as Bre
urned into
> > > .pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
> >
> > I see how pytest does it (but keep reading)
> >
> > > a longer path, and why only this package fails in this way. Perhaps
> > > this is the only package that has
Hi Carles,
It is utterly, utterly bizarre. But I think I've found the problem.
There's a pytest.ini file in the package, but it's not copied into the
test directory. So when pytest is run in the .pybuild directory, it
climbs all the way back up the directory tree to the python-qtpy-2.1.0
until
Hi Julian,
On Jul/04/2022, Julian Gilbey wrote:
> Hi Carles,
>
> Thanks for your thoughts! Yes, indeed that seems to be the issue.
> But what I don't understand is why the import is turned into
> .pybuild.cpython3_3.9_qtpy.build.qtpy.tests and not just qtpy.tests or
I see
n (I might look more
> another time if time permits) but I might have something that might help
> someone who knows the tools better.
>
> I am not familiar with Python Debian packaging details/tools neither
> with pytest :-( so take all of this with a pinch of salt.
>
> If i
packaging details/tools neither
with pytest :-( so take all of this with a pinch of salt.
If it helps the error comes from:
/usr/lib/python3.9/importlib/__init__.py in the functin "import_modules"
it does:
"""
if name.startswith('.'):
if not package:
msg =
Dear all,
I wonder whether you might have any clue about
https://bugs.debian.org/1013700
I have mostly worked out the "cause" of the bug, but I haven't quite
got to the bottom of it.
When running the command
PYTHONPATH=. python3.10 -m pytest qtpy/tests
in the director
On Fri, Jun 24, 2022 at 06:53:04PM -0400, Louis-Philippe Véronneau wrote:
> Thank you for your guidance.
>
> I have filled all of the regressions you reported in the BTS:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pytest7;users=debian-python@lists.debian.org
Thanks Louis-Philippe!
⠈⠳⣄
On 2022-06-15 15 h 32, Lucas Nussbaum wrote:
> Hi,
>
> On 15/06/22 at 15:22 -0400, Louis-Philippe Véronneau wrote:
>> Thanks a lot for this rebuild, very useful.
>>
>> I was told you needed a list of pytest regressions for you to fill bug
>> reports.
>>
On Wed, Jun 15, 2022 at 09:30:56PM +0200, Carsten Schoenert wrote:
> Hi,
> [...]
> >
> > * monitoring-plugins-systemd 2.3.1-2
>
> I've updated sentry-python last week to the current upstream version, so
> this package can be count as fixed.
>
> Current pygm
Hi,
Am 15.06.22 um 21:22 schrieb Louis-Philippe Véronneau:
# Doesn't seem like a pytest regression, but I could be wrong?:
...
* sentry-python 1.4.3-1 (AssertionError: previous item was not torn down
properly)
# Already fixed in the archive:
* monitoring-plugins-systemd 2.3.1-2
I've
Hi,
On 15/06/22 at 15:22 -0400, Louis-Philippe Véronneau wrote:
> Thanks a lot for this rebuild, very useful.
>
> I was told you needed a list of pytest regressions for you to fill bug
> reports.
> It's my first time doing this, so if I missed something you needed, please say
&g
Thanks a lot for this rebuild, very useful.
I was told you needed a list of pytest regressions for you to fill bug reports.
It's my first time doing this, so if I missed something you needed, please say
so.
# Valid pytest regression, deprecated feature:
* asyncpg 0.25.0-1 (deprecated pytest
Hi Sandro,
On 08/06/22 at 21:21 -0400, Sandro Tosi wrote:
> Hello Lucas,
> the Debian Python Team is in the process of updating pytest to a new
> upstream release. Given the substantial number of packages depending
> on it, we'd like to leverage the mass rebuild infrastruct
Hello Lucas,
the Debian Python Team is in the process of updating pytest to a new
upstream release. Given the substantial number of packages depending
on it, we'd like to leverage the mass rebuild infrastructure to build
the reverse dependencies against pytest/7.1.2-1 in experimental.
I've opened
Hi,
On 2022-06-08 14:47, Julian Gilbey wrote:
> 1. finalcif: it seems like an update to python3-gemmi has broken this
> package
Yes, this is indeed the case with finalcif. Will report and investigate
it soon.
Best,
Andrius
On Tue, Jun 07, 2022 at 03:49:37PM -0400, Sandro Tosi wrote:
> > Sandro: you managed the numpy transition, it seems. What is involved
> > in something like this? I would imagine something like:
> >
> > (1) Upload pytest 7.x to experimental
>
> i took care of t
On Tue, Jun 07, 2022 at 03:49:37PM -0400, Sandro Tosi wrote:
> > Sandro: you managed the numpy transition, it seems. What is involved
> > in something like this? I would imagine something like:
> >
> > (1) Upload pytest 7.x to experimental
>
> i took care of t
> Sandro: you managed the numpy transition, it seems. What is involved
> in something like this? I would imagine something like:
>
> (1) Upload pytest 7.x to experimental
i took care of this just now, uploading pytest/7.1.2 to experimental
(and i've messed up the branches on sa
On Tue, Jun 07, 2022 at 08:27:38AM +0100, Julian Gilbey wrote:
> > > Anyone willing to go for it?
> >
> > I thought you were volunteering for it? :) jokes aside, i think
> > preparing the new pytest upstream release for experimental may be the
> > "easi
On 2022-06-07 04:01, Sandro Tosi wrote:
> I would consider pytest a "core" python package, and so a complete
> rdeps rebuild is appropriate
+1. That is what I meant by suggesting ratt-rebuilding all the rdeps.
Best,
Andrius
igrating experimental to unstable.
> >
> > Oh wow, thanks! That's perfect. So we can upload the new pytest to
> > experimental and see what happens...
>
> please be aware that that is a very partial view, in particular only
> showing reverse dependencies with (meaningf
> > I think this page includes debci results for experimental:
> >
> > https://release.debian.org/britney/pseudo-excuses-experimental.html
> >
> > It shows what would happen when migrating experimental to unstable.
>
> Oh wow, thanks! That's perfe
:
>
> https://release.debian.org/britney/pseudo-excuses-experimental.html
>
> It shows what would happen when migrating experimental to unstable.
Oh wow, thanks! That's perfect. So we can upload the new pytest to
experimental and see what happens...
Anyone willing to go for it?
Best wishes,
Julian
On Fri, 2022-06-03 at 19:08 +0100, Julian Gilbey wrote:
> I believe that ci.debian.net checks packages against packages in
> experimental (see
> https://ci.debian.net/packages/s/spyder/unstable/amd64/ for example),
> so it may be that the work is already done for us; what I don't know,
> though,
On Thu, Jun 02, 2022 at 05:28:36PM +0200, julien.pu...@gmail.com wrote:
> Le jeudi 02 juin 2022 à 10:28 -0400, Sandro Tosi a écrit :
> > > I would suggest ratt-rebuilding all reverse dependencies. Could
> > > that be
> > > done?
> >
> > there order of thousands rdeps, i dont think it's fair to
Le jeudi 02 juin 2022 à 10:28 -0400, Sandro Tosi a écrit :
> > I would suggest ratt-rebuilding all reverse dependencies. Could
> > that be
> > done?
>
> there order of thousands rdeps, i dont think it's fair to ask any
> individual contributor the time and resources to check that via ratt.
> I would suggest ratt-rebuilding all reverse dependencies. Could that be
> done?
there order of thousands rdeps, i dont think it's fair to ask any
individual contributor the time and resources to check that via ratt.
Something i've done in the past (f.e. with numpy and matplotlib) is
leveraging
Hi Julian,
On 2022-06-02 11:23, Julian Gilbey wrote:
> When I updated pytest-mock, I noticed that pytest is somewhat out of
> date and it would be good to upgrade it. But it's quite a major
> package, and I don't really want to do it without a go-ahead from
> others.
>
> Perha
Hi all,
When I updated pytest-mock, I noticed that pytest is somewhat out of
date and it would be good to upgrade it. But it's quite a major
package, and I don't really want to do it without a go-ahead from
others.
Perhaps we could upload a newer version to experimental first to see
what breaks
Hi Jonas,
On Fri, May 27, 2022 at 01:11:45AM +0200, Jonas Smedegaard wrote:
> Hi Julian and other Pythonistas,
>
> Quoting Julian Gilbey (2022-05-27 00:44:22)
> > Currently python-pytest-asyncio is maintained just by you. I wonder
> > whether you would be willing to mo
Hi Julian and other Pythonistas,
Quoting Julian Gilbey (2022-05-27 00:44:22)
> Currently python-pytest-asyncio is maintained just by you. I wonder
> whether you would be willing to move this to the Debian Python Team's
> shared repository on salsa and transfer the maintainership to t
Dear Jonas,
I note that there is currently a serious bug against both
python-pytest-asyncio and pytest-mock
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006736), and this
bug is preventing the migration of several major packages to testing.
I also note that the current Debian version
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
* Package name: python3-pytest-fail-slow
Version : 0.1.0
Upstream Author : John Thorvald Wodder II
* URL : https://github.com/jwodder/pytest-fail-slow/
* License : MIT/X
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-relaxed
Version : 1.1.5
Upstream Author : bitprophet
* URL : https://github.com/bitprophet/pytest-relaxed
Hi again,
Am 24.01.22 um 06:35 schrieb Carsten Schoenert:
...
So I think I can answer my original question by myself. These two
packages are not relevant and not needed any more. But thanks for your
feedback!
I moved along and worked further on tuning the packaging for twisted.
I'm able to
Hello Gregor,
Am 23.01.22 um 19:01 schrieb Gregor Riepl:
Ignoring the autopkgtest for now Lintian is complaining about empty
binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
OTOH it's looking not that bad and a lot of the messages should be easy
to fix.
X:
> Ignoring the autopkgtest for now Lintian is complaining about empty
> binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
> OTOH it's looking not that bad and a lot of the messages should be easy
> to fix.
> X: python3-twisted: library-package-name-for-application
Hi,
I've came across through #1001371 which is basically
pytest-twisted: (autopkgtest) needs update for python3.10: E {'warnings': 2} !=
{'warnings': 1}
https://bugs.debian.org/1001371
So far I understand the information from the bug report the real problem
isn't a broken autopkgtest
mpare/master...1.0a3
If I bypass the Sphinx bits, I run into "INTERNALERROR> IndexError:
list index out of range" (and the full backtrace appears to all be in
non-Hy codelike pytest and "pluggy"), which I *think* is related to
funcparserlib needing to be 1.0.0a0+
(https://github
Source: python-pytest-lazy-fixture
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
Hello Team,
New upstream release is need for marshmallow-sqlalchemy new version.
I've just push the new upstream release to salsa, but I left this bugs
open until freeze end and anyone can
ou ellaborate? Maybe we should have a discussion in the Python
>>>> team so that we implement consistent practices. For example, `gunicorn`
>>>> and `pip` now point to their python3 versions, but you are saying that
>>>> pytest will not do that, what maybe creates more con
t; team so that we implement consistent practices. For example, `gunicorn`
> >> and `pip` now point to their python3 versions, but you are saying that
> >> pytest will not do that, what maybe creates more confusion given Debian
> >> bullseye will not support any other
now point to their python3 versions, but you are saying that
>> pytest will not do that, what maybe creates more confusion given Debian
>> bullseye will not support any other Python.
>
> "pytest" in buster now points to python2 version of pytest and
> "pytest-3&quo
ll not do
> that, what maybe creates more confusion given Debianbullseye will not support
> any other Python.
"pytest" in buster now points to python2 version of pytest and "pytest-3" points
to python3 version. To prevent confusion after upgrade I want to keep one stable
Package: wnpp
Severity: wishlist
Owner: Paul Wise
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: pytest-rerunfailures
Version : 9.1
Upstream Author : Leah Klearman and others
* URL : https://github.com/pytest-dev/pytest
Control: retitle -1 ITP: python-pytest-flake8 -- pytest plugin to check FLAKE8
requirements
Control: owner -1 !
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
On Wednesday, April 04 2018, Julien Puydt wrote:
> * Package name: python-pytest-flake8
> V
On 2020-05-18 01:30, Scott Kitterman wrote:
> On Sunday, May 17, 2020 6:26:11 PM EDT Christian Kastner wrote:
>> From the GitHub issue, it seems as if the current practice of testing
>> from within .pybuild is not supported by pytest, but I'm inclined to
>> believe t
In a recent version of src:scikit-learn, a workaround was added to
resolve an ImportMismatchError regarding one of the conftest.py files
used by pytest.
I hit a new instance of this while preparing a new upstream release, so
I inquired [1] with pytest upstream as to why this could be happening
On Tue, 5 May 2020 at 10:55, Tianon Gravi wrote:
> I was definitely over my head with this one, so I reached out to the
> Hy community and was pointed to https://bugs.python.org/issue39562,
> which does seem quite related from my own limited understanding, so
> this might technically be a bug in
1 - 100 of 192 matches
Mail list logo
