Source: slepc
Followup-For: Bug #1070894
Control: tags -1 ftbfs fixed-upstream
Control: forwarded -1 https://gitlab.com/slepc/slepc/-/issues/83
Fixed upstream in 3.20.2,
https://gitlab.com/slepc/slepc/-/merge_requests/639
Source: hypre
Followup-For: Bug #1069321
It's passing in reproducibility rebuilds.
Perhaps it was a transitory glitch.
Source: hypre
Followup-For: Bug #1069321
Control: tags -1 ftbfs
hypre is passing debci and reproducibility tests on armhf.
Looks like the error reported here was a transitory issue,
possibly related to openmpi upgrades.
Control: tag -1 pending
Hello,
Bug #1063409 in mpi4py reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1066837 in mpi4py reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: mpi4py
Followup-For: Bug #1066449
Control: tags -1 ftbfs
The bug report stopped scanning at the first "error", which is not an
error (it's a check). The last error is the relevant one
testIReadIWrite (test_io.TestIOSelf.testIReadIWrite) ... ok
testIReadIWriteAll
Source: mpi4py
Followup-For: Bug #1069432
There have been ongoing issues with OpenMPI on 32-bit architectures,
partly related to drop of 32-bit support by pmix.
This bug is likely related to that i.e. not a bug in mpi4py itself.
Source: scipy
Followup-For: Bug #1069377
Control: tags -1 ftbfs
This is an odd error. Looks as if the behaviour changed in respect to
which exception gets emitted.
There's a new release needing to get packaged. Likely it resolves the
issue.
Source: openmpi
Version: 4.1.6-12
Followup-For: Bug #1069106
Control: reopen 1069106
4.1.6-12 was intended to fix this bug, but it's still occuring
e.g.
https://ci.debian.net/packages/o/openmpi/unstable/i386/45630865/
https://ci.debian.net/packages/o/openmpi/unstable/armhf/45630866/
Source: dolfin
Followup-For: Bug #1062405
Control: severity 1062405 testing
Control: tags 1062405 moreinfo
This time_t patch was never applied. Is it not needed after all?
Can we close this bug now?
Source: openmpi
Version: 4.1.6-9
Severity: serious
Justification: ftbfs
Control: affects -1 src:fenics-dolfinx src:petsc
openmpi 4.1.6-9 is failing its own tests on 32-bit systems,
presumeably after they were configuring to use a local copy of pmix
instead of libpmix-dev.
For instance on i386
Source: dolfinx-mpc
Followup-For: Bug #1062383
Control: severity 1062383 important
Control: tags 1062383 moreinfo
This patch was never applied. Do we not need it after all? Can we
close this bug now?
Source: fenics-dolfinx
Followup-For: Bug #1062587
Control: severity 1062587 important
Control: tags 1062587 moreinfo
This time_t patch was never applied. I presume it's not needed after
all and we can close this bug now?
Package: libpmix2t64
Version: 5.0.2-2
Followup-For: Bug #1067784
Control: affects 1067784 nwchem nwchem-openmpi
Control: reopen 1067784
Looks like 5.0.2-2 annihilated the symlink fix made in 5.0.2-1.1
See nwchem tests,
https://ci.debian.net/packages/n/nwchem/unstable/amd64/44696719/
90s
Source: python-meshplex
Followup-For: Bug #1067308
Control: tags -1 ftbfs
I can't reproduce this error now. It must have been resolved by a
separate library transition, or possibly a numpy update.
If 0.17.1-3 passes tests successfully then we can close this bug.
Source: pymatgen
Followup-For: Bug #1064749
Control: tags -1 ftbfs
I can't reproduce this error.
See also
https://buildd.debian.org/status/fetch.php?pkg=pymatgen=amd64=2024.1.27%2Bdfsg1-7=1708967242=0
Source: rust-python-pkginfo
Version: 0.5.5-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
rust-python-pkginfo is failing to build on mips64el due to a missing
librust-rfc2047-decoder-0.2+default-dev
Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package.
Should the Build
Source: petsc
Followup-For: Bug #1065323
petsc has a complex set of symlink farms since it needs to enable
multiple alternative build profiles.
I'll implement the patch in a way that doesn't let t64 get in the way
of updating subsequently (to 3.20 in the near future).
Drew
Source: python-hmmlearn
Version: 0.3.0-3
Severity: serious
Justification: debci
python-hmmlearn is failing variational_gaussian tests
(test_fit_mcgrory_titterington1d) with sklearn 1.4.
This comment upstream is relevant:
https://github.com/hmmlearn/hmmlearn/issues/539#issuecomment-1871436258
Source: imbalanced-learn
Version: 0.10.0-2
Severity: serious
Justification: debci
imbalanced-learn 0.10 fails tests with sklearn 1.4.
The problem is fixed upstrema with v0.12.
Source: masakari
Version: 16.0.0-2
Severity: serious
Justification: debci
Control: affects -1 src:sphinx src:python-skbio src:scipy
masakari has started failing tests:
229s FAIL:
masakari.tests.unit.objects.test_objects.TestObjectVersions.test_versions
229s
Source: custodian
Followup-For: Bug #1063752
X-Debbugs-Cc: Debichem Team
Control: reassign 1063752 lists.debian.org
Control: affects 1063752 src:custodian
Scott Kitterman reported that lists.alioth.debian.org is bouncing
emails from debian official addresses (ftpmas...@ftp-master.debian.org
in
Source: custodian
Followup-For: Bug #1063752
I am confused by this bug report.
The debichem Maintainer address used for custodian is the same as that
used for any other debichem package. No problems were reported for
the other packages.
Source: mdtraj
Followup-For: Bug #1060971
X-Debbugs-Cc: 1060971-d...@bugs.debian.org
Control: fixed 1060971 1.9.9-1
Fixed with cython3-legacy at the same time the bug was filed.
Hi Maytham, golang-github-googleapis-enterprise-certificate-proxy is
now built on the main architectures.
https://buildd.debian.org/status/package.php?p=golang-github-googleapis-enterprise-certificate-proxy
It's still not building on the auxiliary architectures.
Can you see a way of extending
Source: adios2
Followup-For: Bug #1062356
The flakey test is adios2-mpi-examples. debian/tests is building and
running them manually, and running on only 3 processors (mpirun -n 3)
So the problem can't be overload of the machine.
I'll just skip insituGlobalArraysReaderNxN_mpi.
For reference,
Source: adios2
Followup-For: Bug #1062356
Can't be quite as simple as just the host machine.
https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41403641/log.gz
completed in 9 minutes,
while
https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41496866/log.gz
failed with
Source: scipy
Followup-For: Bug #1061605
Note that debci tests are passing on all arches (where built) for
scipy 11.
I'm inclined to accept this as a solution.
i.e. update the list of builds tests to skip for scipy 11
rather than reorganise debian/tests skips for scipy 10.
Source: pymatgen
Followup-For: Bug #1053939
[apologies for the spam. testing mail server configuration now]
Source: pymatgen
Followup-For: Bug #1053939
Looks like the latest release should be fine with pandas 2.
Currently building in experimental.
Source: scipy
Followup-For: Bug #1061605
Easy enough to relax tolerances or skip tests if we needed to.
test_maxiter_worsening was giving problems on other arches.
But strange the test only started failing when pythran was deactivated.
I've reactivated it in 1.10.1-8, we'll see if it restores
Control: tag -1 pending
Hello,
Bug #1061385 in golang-github-google-go-pkcs11 reported by you has been fixed
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
On 2024-01-23 14:39, Maytham Alsudany wrote:
Hi Drew,
On Tue, 2024-01-23 at 11:24 +0100, Drew Parsons wrote:
> > Hi Maytham, I can upload it. But note how pkcs11 is failing on 32 bit
> > arches. That needs to be sorted out. I had been waiting for that
> > before up
Source: golang-github-google-go-pkcs11
Version: 0.3.0+dfsg-1
Severity: serious
Justification: debci
Control: block 1024276 by -1
go-pkcs11 tests are failing on 32-bit architectures (armel, armhf, i386),
see https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/
This is preventing
On 2024-01-19 18:52, Drew Parsons wrote:
Hi Andreas, could you push your upstream and pristine-tar branches?
Otherwise we can't use your 2023.12.18 branch.
I see what you mean. The tag is there, the orig tarball can be
regenerated with
gbp export-orig.
Source: pymatgen
Followup-For: Bug #1058040
No, other way around. The new monty is causing the problem.
Will need to patch or upgrade pymatgen.
Source: pymatgen
Followup-For: Bug #1058040
Sounds like it will need the new version of monty
On 2024-01-16 17:55, Andreas Tille wrote:
Control: tags -1 pending
Hi,
I've applied the patch in Git and also tried to upgrade to latest
upstream since there is a chance that other Python3.12 issues might be
fixed. Unfortunately the upgrade is all but straightforward and
I gave up finally
Source: h5py
Followup-For: Bug #1061063
Control: forwarded 1061063 https://github.com/h5py/h5py/issues/1927
The problem was raised upstream at
https://github.com/h5py/h5py/issues/1927
Makes it difficult to test if we can't reproduce it on all armhf
environments.
A patch was suggested for the
Source: python-griddataformats
Followup-For: Bug #1058122
THanks for the patch, Yogeswaran.
Upstream has fixed it in their latest release however.
Control: tag -1 pending
Hello,
Bug #1058122 in python-griddataformats reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
On 2024-01-16 17:55, Andreas Tille wrote:
Control: tags -1 pending
Hi,
I've applied the patch in Git and also tried to upgrade to latest
upstream since there is a chance that other Python3.12 issues might be
fixed. Unfortunately the upgrade is all but straightforward and
I gave up finally
Source: nbconvert
Version: 6.5.3-4
Followup-For: Bug #1057949
An nbconvert update (>= 7.6) is also needed to support the latest
version of pandoc 3.1.3. That is, to avoid the warning that pandoc
3.1.3 is "unsupported".
cf.
Source: hickle
Version: 5.0.2-7
Severity: serious
Justification: debci
h5py 3.10 is triggering test failure in hickle
54s test_H5NodeFilterProxy
54s
54s h5_data =
54s
54s def test_H5NodeFilterProxy(h5_data):
54s """
Control: tag -1 pending
Hello,
Bug #1059634 in pythran reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Package: python3-hdf5plugin
Version: 4.0.1-3
Severity: serious
Justification: FTBFS
python3-hdf5plugin has started failing testZfp,
causing both FTBFS and debci failure.
The error message from debci is
56s ERROR: testZfp (__main__.TestHDF5PluginRW.testZfp) (options={'lossless':
False},
Hi Alistair, given the complexity around hacking openmpi to accommodate
placing the mod files under /usr/include, I'm starting to wonder whether
it's the best way of resolving Bug#1058526 in the first place.
I did it bit of background reading on the fortran mod files. There's a
fair bit of
On 2023-12-27 09:51, Alastair McKinstry wrote:
On 27/12/2023 08:45, Drew Parsons wrote:
...
I guess the problem must be the common files from openmpi-common in
/usr/share/openmpi/. They're not actually arch-independent. Do
mpif90.openmpi and the other components actively read them at runtime
On 2023-12-26 12:45, Drew Parsons wrote:
I can manually reproduce the error trivially on an arm64 chroot
(amdahl.debian.org). Copying hello.f90 from openmpi's debian/tests
and manually running
mpif90 -o hello hello.f90
reproduces the error reference to the x86_64 include path on the arm64
On 2023-12-26 12:31, Drew Parsons wrote:
...
It's not just adios2 and sundials though. openmpi's own arm64 tests
are failing on debci with a reference to x86_64-linux-gnu
...
openmpi's compile_run_mpif90 test doesn't use pkgconfig anyway. It
builds directly with mpif90. Could the problem
On 2023-12-26 11:00, Alastair McKinstry wrote:
On 24/12/2023 10:50, Drew Parsons wrote:
reopen 1058876
block 1058944 by 1058876
thanks
Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi
fortran modules has hardcoded x86_64-linux-gnu
This is preventing builds and tests
reopen 1058876
block 1058944 by 1058876
thanks
Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi
fortran modules has hardcoded x86_64-linux-gnu
This is preventing builds and tests on other architectures, e.g.
rebuilding sundials for the petsc transition.
I think
Control: tag -1 pending
Hello,
Bug #1055698 in py-ubjson reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: openmpi
Followup-For: Bug #1058876
Control: retitle 1058876 libopenmpi-dev: paths missing /usr/include...(for
fortran mpi.mod)
We can see from debci that openmpi's own tests are affected by the
same underlying problem. That indicates that the configuration for
mpif90.openmpi itself is
Control: tag -1 pending
Hello,
Bug #1056515 in pythran reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: slepc4py
Followup-For: Bug #1057863
Correction: curexc_traceback is not used in slepc4py 3.19.
Maybe it's time to upgrade to PETSc 3.19.
Source: slepc4py
Followup-For: Bug #1057863
slepc4py does not use curexc_traceback.
Perhaps this is a bug in cython?
Package: libopenmpi-dev
Version: 4.1.6-2
Severity: serious
Justification: ftbfs (other)
openmpi 4.1.6-2 moved the fortran mod files from /usr/lib to
/usr/include. This is probably correct, but has some consequences we
need to sort out. Applications using cmake for configuration are still
looking
Source: adios2
Followup-For: Bug #1058353
Damn, something went badly wrong in debian/rules. Sorry about that.
I'll fix it as soon as possible, in the meantime use the version in
testing.
Drew
Source: adios2
Followup-For: Bug #1058018
Control: severity -1 important
Call it teething issues. This is a new package, so I'm trying to avoid
making debian/control more verbose than it needs to be by not crowding
the fields with the strict specifications needed to avoid this error.
Once the
Source: ensmallen
Followup-For: Bug #1054712
Should be noted that the problem is linked to debian patch
0002-use-system-catch.patch, which disables upstream's local copy of
catch in order to use the system catch2 library.
So one workaround could be to disable 0002-use-system-catch.patch.
Source: spdlog
Followup-For: Bug #1053774
Looks like you'll need to grab PR#2827 from upstream
https://github.com/gabime/spdlog/pull/2827
Source: ensmallen
Followup-For: Bug #1054712
Control: forwarded 1054712 https://github.com/mlpack/ensmallen/issues/372
This error occurs because of the upgrade of catch2 from v2 to v3.
Unfortunately ensmallen upstream don't sound very enthusiastic about
dealing with it,
Source: gammapy
Version: 1.1-1
Severity: serious
Justification: debci
scipy 1.10.1-4 is triggering errors in test_ndmap.py
test_binary_dilate and test_binary_dilate_erode_3d
on both i386 and s390x.
The error looks a little like
https://github.com/gammapy/gammapy/issues/3662 which was solved by
Control: tag -1 pending
Hello,
Bug #1053527 in python-scipy reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: xtensor
Version: 0.24.7-4
Followup-For: Bug #1053090
Control: severity 1053090 important
xsimd support is optional for xtensor.
Use of batch is apparently not expected to be routinely used
anyway. See further discussion at
https://github.com/xtensor-stack/xsimd/issues/945
In summary,
Source: tuiwidgets
Version: 0.2-1.1
Severity: serious
Justification: debci
catch2 v3 was recently uploaded and breaks tuiwidgets's tests
The needed patch is likely to be simple, similar to the one prepared
for termpaint
Source: termpaint
Version: 0.3.0-2
Severity: serious
Justification: debci
Control: tags -1 patch
catch2 v3 was recently uploaded, and breaks termpaint's tests
Upstream has made a patch:
https://github.com/termpaint/termpaint/commit/dc293554b745b3f010445e9445e620399f8ee2f7
Source: spdlog
Version: 1:1.10.0+ds-1
Severity: serious
Justification: debci
catch2 v3 was recently uploaded, but breaks spdlog's tests.
spdlog upstream has released v1.12.0 which uses catch2 v3.
Source: posixsignalmanager
Version: 0.3-3
Severity: serious
Justification: debci
Control: forwarded -1 https://github.com/textshell/posixsignalmanager/issues/2
Control: tags -1 patch
catch2 v3 was recently uploaded, and breaks posixsignalmanager's tests
Upstream has prepared a patch,
On 2023-10-10 09:26, Rafael Laboissière wrote:
* Rafael Laboissière [2023-10-09 08:30]:
[…] At least, I hope that version 3.1.0+dfsg2-5 will really fix
Bug#1053314 and the h5py transition will be completed.
Unfortunately, it is still not working:
On 2023-10-09 08:30, Rafael Laboissière wrote:
Thanks for this detailed explanation, Drew. I released version
3.1.0+dfsg2-5 of the xmds2 package before reading it. I added
python3-h5py to Build-Depends and libhdf5-mpi-dev to Depends, as you
suggested (even though there is a typo in the
Nilesh explained most of the situation correctly. I can give some more
background.It made sense (to me) to have h5py built against
hdf5-mpi, since I figured that if you need the complexity of the hdf5
file format then you probably want to use it in an MPI environment.
There was a
Package: libxsimd-dev
Followup-For: Bug #1053090
Control: reassign 1053090 libxtensor-dev
Control: forwarded 1053090 https://github.com/xtensor-stack/xtensor/issues/2733
xsimd upstream https://github.com/xtensor-stack/xsimd/issues/945
identified the problem that neon64 does not support bool.
A
reopen 1053267
thanks
hickle 5.0.2-6 was intended to fix the "No write intent on file" error
in Bug#1053267.
But the error still occurs,
see
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hickle/38426042/log.gz
Note that this time the error occurred with old h5py 3.7.0, so there
forwarded 1053341 https://github.com/h5py/h5py/issues/2315
thanks
I suspect it can be resolved by casting the int returned by addressof to
ctypes.c_int. Waiting to hear what upstream thinks.
Note it's not quite as simple as "32-bit". sparc64 is also affected.
Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci
xmds2 Depends: python3-h5py-mpi without depending on python3-h5py
python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace,
not h5py. Hence tests using h5py without specifying _debian_h5py_mpi
fail. This is
Source: ont-fast5-api
Version: 4.1.1+dfsg-2
Severity: serious
Justification: debci
h5py 3.9.0 is triggering an error ont-fast5-api debci tests,
https://ci.debian.net/data/autopkgtest/testing/amd64/o/ont-fast5-api/38279479/log.gz
33s ERROR: test_001_read_events
Source: hickle
Version: 5.0.2-5
Severity: serious
Justification: debci
h5py 3.9.0 is triggering an error in hickle tests, found by debci,
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hickle/38279474/log.gz
62s test_H5NodeFilterProxy
Package: python3-h5sparse
Version: 0.1.0-6
Severity: serious
Justification: debci
Currently python3-h5sparse Depends: python3-h5py-serial, but h5sparse
tests access h5py, not h5py._debian_h5py_serial.
The python3-h5py-serial package only provides
h5py._debian_h5py_serial. If you need to use the
Source: dipy
Version: 1.7.0-2
Severity: serious
Justification: debci
h5py 3.9.0 is triggering an error in dipy debci tests,
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dipy/38279462/log.gz
However from the error log, it's not clear that the problem is
directly related to h5py. An
Source: petsc
Followup-For: Bug #1049903
Control: severity 1049903 important
Control: tags 1049903 moreinfo
I said previously I'd apply the patch, but I wanted to check the
problem first. No problem is showing at
https://tests.reproducible-builds.org/debian/rb-pkg/petsc.html
even in the
Source: mpi4py
Followup-For: Bug #1052748
Control: severity 1052748 important
Control: tags 1052748 moreinfo
I can't reproduce this error, and debci tests at
https://ci.debian.net/packages/m/mpi4py/ continue to pass
So I'm downgrading severity.
I figure there are two possibilities
- it was a
Source: mpi4py
Followup-For: Bug #1052748
Control: retitle 1052748 mpi4py fails test_dynproc.TestDPM.testJoin:
socket.gaierror: [Errno -2] Name or service not known
The failure was incorrectly identified. The build log says the problem
was in testJoin:
ERROR: testJoin
Source: xtensor
Followup-For: Bug #1052882
Control: fixed 1052882 0.24.7-1
This bug is weird, in the sense that xtensor 0.24.3-2 in testing
failed its test against xsimd 10.0.0-3 from unstable.
So why then did the migration daemon allow xsimd to migrate from
unstable to testing?
Package: libxsimd-dev
Version: 10.0.0-3
Severity: serious
Justification: debci
libxsimd-dev 10 triggers an error in xtensor tests on arm64
xsimd passes its own tests, and xtensor passes on other arches (except
armel which has known issues)
The error output from
Source: xtl
Version: 0.7.5-2
Severity: serious
Justification: debci
There's a problem with the xtk 0.7.5 cmake configuration.
It fails debian/tests (debci) since it can't find doctest:
46s CMake Error at CMakeLists.txt:12 (find_package):
46s By not providing "Finddoctest.cmake" in
Control: tag -1 pending
Hello,
Bug #1042034 in nwchem reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1042034 in nwchem reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Package: nwchem
Version: 7.0.2-4
Followup-For: Bug #1042034
The problem seems to be specific to mpich, which is a bit peculiar.
The openmpi build remains successful.
Source: petsc
Followup-For: Bug #1049903
Thanks for the clarification. I'll apply the patch.
Source: petsc
Followup-For: Bug #1049903
Hi Steve, thanks for the bug report.
With patching, wouldn't it be simpler to just add -lstdc++ to
CXX_LINKER_FLAGS at configuration time (in debian/rules) rather than
hacking the upstream detection code? As you say, hardcoding in the
upstream scripts
Source: superlu
Followup-For: Bug #1043313
Upstream has just released a new version to fix it.
Apparently it introduced other problems however.
Let's see what upstream's response to that is.
forwarded 1041372 https://github.com/xtensor-stack/xtensor/issues/2718
thanks
Evidently triggered by excess precision changes in gcc-13,
see https://gcc.gnu.org/gcc-13/porting_to.html
Source: dolfin
Version: 2019.2.0~legacy20230609.8b85e9d.ar-2
Severity: serious
Justification: Policy 8.6.2
Control: affects -1 python3-mshr
The accumulation of git changes and gcc-13 fixes has apparently
introduced an ABI inconsistency in libdolfin.so, such that mshr can no
longer be imported in
Control: tag -1 pending
Hello,
Bug #1037823 in pythran reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: scipy
Followup-For: Bug #1037854
The errors in the build log refer to pythran, not scipy.
Package: libscotchmetis-dev
Version: 7.0.3-1
Followup-For: Bug #1036576
Awkward. Thanks for catching it.
Package: opendrop
Version: 3.3.1-4
Severity: grave
Tags: patch upstream
Justification: renders package unusable
debian patch sundials_nvector_API6.patch enabled opendrop to build
against sundials 6.
Nevertheless it still fails when attempting to analysis interfacial
tension measurements:
Source: pymatgen
Followup-For: Bug #1031705
Apart from that one case of test_cif.py, every other timeout occurs in
test_babel.py. If it were a 3rd test being held up and resolving too
late for other tests to pass, then the timeout would occur more
randomly.
So looks like the 7th item
1 - 100 of 585 matches
Mail list logo
