Control: tags -1 patch
It's failing because the documentation build (arch:all) expects the main
build (arch:any) to have been done first. Fix:
diff -Nru libgpuarray-0.6.9/debian/rules libgpuarray-0.6.9/debian/rules
--- libgpuarray-0.6.9/debian/rules 2017-07-26 21:25:20.0 +0100
+++
Control: tags -1 upstream fixed-upstream
This appears to be 2 separate bugs, both triggered by using pandas 0.20
and fixed upstream.
groupby_bins:
https://github.com/pydata/xarray/issues/1386
https://github.com/pydata/xarray/pull/1390
test_sel: this is really a pandas bug (fixed in 0.21, but
Package: python3-xarray
Version: 0.9.2-1
Severity: serious
Control: tags -1 upstream
Two netcdf tests fail in current sid (see log below).
This is known upstream as https://github.com/pydata/xarray/issues/1721 ,
according to which the actual problem is that scipy has been writing
netcdf files
Given the soft freeze, the new upstream version is probably no longer an
option for buster.
Just setting __array_priority__ fails, but with a message that suggests
also including the test_analytics part of that upstream commit would
work; I haven't yet had time to try this.
left = o
This builds (including build-time tests; haven't tried the autopkgtest).
Description: Fix np.array @ DataFrame matrix multiplication
Author: jbrockmendel
Origin: upstream
https://github.com/pandas-dev/pandas/commit/ad2a14f4bec8a004b2972c12f12ed3e4ce37ff52
Bug-Debian: https://bugs.debian.org/91
Source: pandas
Version: 0.23+dfsg-2
Severity: serious
Control: affects -1 src:statsmodels
Control: tags -1 patch
The fix for #918206 (setting __array_priority__ to make np.array @
DataFrame work) is technically API breaking: in-place operators
arr = np.array(...)
df = pd.DataFrame(...)
arr +=
loses: #857683)
+ * Use versioned symbols (Closes: #848368)
+
+ -- Rebecca N. Palmer Sat, 18 Mar 2017 21:29:25
+
+
llvm-toolchain-3.9 (1:3.9.1-5) unstable; urgency=medium
* Fix the incorrect symlink to scan-build-py (Closes: #856869)
diff -Nru llvm-toolchain-3.9-3.9.1/debian/liblldb-X.Y
:56.0
+
@@ -1,3 +1,11 @@
+llvm-toolchain-3.9 (1:3.9.1-5local2) UNRELEASED; urgency=medium
+
+ * Allow '!pointer' in OpenCL (Closes: #857623)
+ * Add missing liblldb symlink (Closes: #857683)
+ * Use versioned symbols (Closes: #848368)
+
+ -- Rebecca N. Palmer Sat, 18 Ma
What do you mean by "not tested" ? You did built it right?
Not as of that message.
I since tried to build the "version script" option: it failed most of
its tests with
--
Exit Code: 126
Command Output (stderr):
--
E: env var COWDANCER_ILISTFILE not defined
E: cowdancer: Fatal, initialize_func
Looks like this is a known cowdancer issue (#640684 - fixed only for
cowbuilder --build, not --login); continuing with LD_PRELOAD=
debian/rules build, the LLVM tests pass:
Expected Passes: 16742
Expected Failures : 124
Unsupported Tests : 339
Unexpected Passes : 17
Still buildin
12 clang tests "unexpectedly" fail, but they're the same 12 that do so
in the existing package:
Failing Tests (12):
Clang :: CodeGen/linux-arm-atomic.c
Clang :: Driver/arm-cortex-cpus.c
Clang :: Driver/arm-features.c
Clang :: Driver/arm-ias-Wa.s
Clang :: Driver/arm-mfpu.c
On 19/03/17 16:09, Sylvestre Ledru wrote:
Indeed. Are you going to update the symbol file?
I just deleted the symbols file to get the build to finish (which it
did, and objdump -T confirmed that libLLVM and libclang had versioned
symbols), but if you want to keep it, here's the full patch fro
Rebuilding beignet and mesa against this llvm succeeds, and this beignet
works. (beignet is statically linked to LLVM/Clang, so we can't use it
as a test of whether non-rebuilt rdeps work.)
blender+pocl-opencl-icd still crashes, with the bad jump being from 3.8
to a versioned 3.9 symbol, but
Thanks, but I think we missed something: as packages rebuilt against new
(versioned-symbols) LLVM don't work with old LLVM, we need a shlibs bump
to make dependencies reflect that (i.e. require upgrading
libllvm/libclang before their dependencies). I think that's
--- /dev/null
+++ a/debian/li
Source: theano
Version: 1.0.2+dfsg-1
Severity: serious
Control: tags -1 patch
Many Theano operations include C code for speed; the compilation process
uses an undocumented Numpy function to check ABI compatibility.
In Numpy 1.16 (recently added to sid), this function is moved, causing
all com
Control: tags -1 pending
Control: tags 918771 pending
I intend to upload theano (also containing other changes - see Salsa
repo) either tonight or tomorrow night.
...or by calling numpy 1.16 a transition, are you implying you want this
minimal fix and nothing else?
non-instantiable (and hence unusable) as char[4] to char& is an
invalid conversion.
Older GCC didn't check this until it was attempted, which it isn't
(instantiating a class template only instantiates those member
functions that are used), but in GCC 8 its existence is an error.
Aut
template specialization
This is probably unused (the use in FatBoundary is commented out),
which would explain it only being an FTBFS in GCC 8 and not sooner:
https://gcc.gnu.org/gcc-8/porting_to.html#hypothetical-instantiation
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/897752
Control: tags -1 patch
Taking just this part of the upstream patch (the other parts are for
code our version doesn't have), together with the Boost fix (which I
will file a separate bug for), makes it build.
Description: Fix const-related FTBFS with GCC 8
Author: Pradeep "9prady9"
Origin: up
While this doesn't crash on amd64, valgrind does find a double free in
test_index - and a comment in the test says checking that there isn't a
double free is the whole point of that test:
https://sources.debian.org/src/arrayfire/3.3.2+dfsg1-4/test/index.cpp/#L1255
==4773== Invalid free() / del
Control: tags -1 fixed-upstream patch
The test failure is that np.array @ pd.DataFrame (matrix product) tries
to keep both the DataFrame's indices, which fails because the new matrix
is a different shape.
This appears to be fixed in 0.24.1 from PyPI, but as previously noted,
this is a new ma
Package: clsparse
Severity: serious
X-Debbugs-Cc: debian-scie...@lists.debian.org, ghisv...@gmail.com
(plus an identical one for freefem3d)
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to have
Package: freefem3d
Severity: serious
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to have an opinion on this: I am opening
this bug as a "don't waste your time fixing it" notice.
If this re
Control: tags -1 fixed-upstream patch
These look like the upstream fixes, though I haven't actually tried them
yet.
for index:
https://github.com/arrayfire/arrayfire/commit/58ac59497b50257631713e689a6b0ddffb73361a
for assign:
https://github.com/arrayfire/arrayfire/commit/1b18226dfec811e4b7b
On i386 with the above patches (plus the gcc8 build fix from the other
bug), all tests pass in the build but Test_gfor_cpu fails in the
autopkgtest; I don't yet know why.
(I had never heard of this package before your d-d post: I'm looking at
it because of the number of to-be-autoremoved reverse dependencies)
I can't reproduce any of these test failures: dpkg-buildpackage -us -uc
-A in a sid/amd64 cowbuilder --login chroot (build-deps + ccache
eatmydata lintian
Control: tags -1 patch
The failing tests are:
==
FAIL: blockdiag.tests.test_generate_diagram.test_generate(at 0x7f79a5528f28>, 'svg',
'/tmp/buildd/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_3.5/build/src/blockdiag/tests/diagrams/m
This involves a lot more than just sympy: the (build-)dependency chain is
execnet - sometimes FTBFS (3-4x unreproducible test failures, no known
fix; disabling/ignoring the tests in question would probably make it
build, but obviously isn't a real fix)
^
|
pytest-xdist
^
|(apparently only for
missing python{,3}-olefile in Build-Depends.
There is no such package in unstable - was this a typo?
(For me the only failed tests were the two in the bug, and just the
patch was enough to fix that.)
olefile (0.43-1) unstable; urgency=medium
* Initial release (closes: #850404).
-- Matthias Klose Fri, 06 Jan 2017 07:36:25 +0100
Which makes it too new to get into stretch, so we're not allowed to
build-depend on it if we want to stay there.
(https://release.debian.org/stretch/rc_policy
I now also see the no-olefile errors in sid:
(This was with a locally built wand - the in-archive one is currently
uninstallable due to #850815 - and is one of many with similar messages.)
I haven't checked whether it works in stretch (which has an older
version of pillow, with an embedded co
Control: tags -1 patch
One way to reproduce this bug:
# apt-get install pocl-opencl-icd blender
$ gdb blender
open User Preferences -> System
This promptly crashes; beignet-opencl-icd 1.2.1-1 (LLVM 3.8, like pocl)
also triggers it, but beignet-opencl-icd 1.2.1-2 and mesa-opencl-icd
(LLVM 3.9, l
On 22/01/17 21:07, Sylvestre Ledru wrote:
> , you haven't pass the arg to LDFLAGS to make sure that libclang or
> liblldb get it,
> is that on purpose?
My original intent was to avoid passing it to those parts of LLVM that
already use a "version" (actually which-symbols-are-public) script, as
I su
kdiag (1.5.3+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't fail tests on a harmless wand warning. Closes: #848478
+
+ -- Rebecca N. Palmer Sun, 22 Jan 2017 22:13:59
+
+
blockdiag (1.5.3+dfsg-1) unstable; urgency=medium
* New upstream release. Close
beignet FTBFS with LLVM > 9 (#974792). beignet uses libllvm/libclang
heavily enough that it usually has this kind of bug on a new LLVM
release, but this time my attempts to fix it failed (see the Salsa CI logs).
It is abandoned upstream and mostly replaced by intel-opencl-icd. (This
is not a
Additional information:
As a rough estimate of how much speed this would cost on older hardware,
I previously measured beignet as 8-16x faster than pocl (but this will
obviously depend on hardware and application). However, beignet (on
hardware that can't use intel-opencl-icd) is limited to s
I have an attempt to fix this in Salsa now (in my fork), but it hasn't
had time to run the tests yet, so I don't know whether it works.
Note the above mention that if we lose dask.distributed then we lose
Spyder, which makes this a bigger issue than I initially thought.
That removed most of the test failures, but there seem to be a few
apparently random ones left (2 runs both failed, but with different errors).
On 04/02/2023 21:35, Andreas Tille wrote:
Any reason to not push to master directly?
I don't do that with packages that aren't mine. Also see above.
I currently have this in a state where it sometimes succeeds and
sometimes doesn't:
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096
Tests I've seen to fail multiple times (and don't have a fix for):
test_balance_expensive_tasks[enough work to steal]
https://salsa.debia
(Background: the pandas + dask transition broke dask.distributed and it
was hence removed from testing; I didn't notice at the time that if we
don't get it back in we lose Spyder.)
On 05/02/2023 21:44, Rebecca N. Palmer wrote:
I currently have this in a state where it sometimes su
I agree that xfailing the tests *may* be a reasonable solution. I'm
only saying that it should be done by someone with more idea than me of
whether these particular tests are important, because blindly xfailing
everything that fails is effectively not having tests.
If we do choose that approa
On 07/02/2023 03:20, Diane Trout wrote:
What's your test environment like?
Salsa CI.
I don't think head is hugely different from what was released in -1.
The diff looks like Andreas adjusted the dask dependency version,
configured a salsa CI run, and added some upstream metadata files
That
I think I got the code to detect if IPv6 is available to work correctly
so I could set the DISABLE_IPV6 environment variable that
dask.distrubted supports.
This probably refers to
https://salsa.debian.org/python-team/packages/dask.distributed/-/blob/debian/master/debian/tests/run-tests#L11
T
On 08/02/2023 22:09, Diane Trout wrote:
I just got back a passed from salsa. So does anyone want to make any
more changes? Or should we release this version?
The *maybe* remaining issue is that test_balance_expensive_tasks[enough
work to steal] seems to fail repeatedly when it fails, so if we wa
On 09/02/2023 06:36, Diane Trout wrote:
Also there's still some flaky tests as the rebuild triggered by my just
committing the changelog release had a failure in "test_release_retry"
I don't think I've seen that particular one before, though like several
others it's a warning being treated as
On 09/02/2023 17:07, Diane Trout wrote:
Would it make sense to drop those errors back to warnings, and do you
know enough about the setup.cfg language to do it quickly?
Plausibly yes but I don't actually know, and remove the 'error' line at
setup.cfg:60.
I went ahead and requested anoth
On 09/02/2023 21:33, Diane Trout wrote:
The place to ask is debian-release; no comment on the likely result.
I'll try to ask.
Looking at the old logs, I think the old "passing" test *didn't actually
run* the tests (just collected them, which was enough to fail on a
dask/dask.distributed mi
Upstream's reason for treating warnings as errors is just generic 'find
potential problems' (https://github.com/dask/distributed/issues/6048).
On 09/02/2023 21:33, Diane Trout wrote:
That worked, but armel (test_steal_twice), armhf (something outright
crashing) and s390x (lots) all failed.
Ar
On 10/02/2023 06:41, Andreas Tille wrote:
Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask release team.
As far as I observed the migration time is now 5 days (no matter wheth
Control: reassign -1 src:pocl,src:libgpuarray
Control: found -1 pocl/3.1-3
Control: found -1 libgpuarray/0.7.6-13
Control: retitle -1 libgpuarray: i386 test fail with new pocl
The trigger is probably pocl, not clinfo. I don't yet know whether the
bug is in pocl or libgpuarray.
Possibly useful here: gdb disassemble works inside pocl kernels, see
#920497 for an example.
Package: python3-pymatgen
Severity: serious
Control: affects -1 python3-pandas
The autopkgtest sometimes times out, and when it does, the last line is
io/tests/test_babel.py and 6 'pass' dots, implying that the 7th item hung.
All known instances are on amd64.
Package: python3-optuna
Severity: serious
Control: affects -1 python3-pandas
test_create_new_trial (both parts) sometimes fails on s390x, failing the
autopkgtest.
It might make sense to remove this package on s390x, if it isn't
reasonable to actually fix this.
I agree that switching to Aesara is probably the only reasonable option
other than removal. (I'd given up on trying to fix 1.0, and was
intending to let removal happen.)
However, it's a much bigger change than is normally allowed in bookworm
at this point. (1.1 includes multiple breaking cha
On 02/03/2023 10:38, Andreas Tille wrote:
I admit I do not see any good reason to stick to the old version if we
decided before that keras/deepnano are no real blockers to even drop
theano. Thus I was considering it more promising to spent my time on
the latest version.
1.1.2 isn't the latest
On 03/03/2023 06:00, Andreas Tille wrote:
Ahh, so aesara is not really a "fork" but a "rename"?
The original is abandoned (no new development since 2017, and now mostly
unmaintained, which is probably why it has this kind of bug). Aesara is
a continuation by a new upstream (possibly one that
While that particular problem is easy to fix, there are other
incompatibilities that aren't (see #1026539, #1027215) and I intend to
let autoremoval happen.
Package: python3-distributed
Version: 2022.02.0+ds1-3
Severity: serious
dask.distributed has been failing its autopkgtests since dask was
upgraded to 2022.12.1.
This is the expected result of upgrading one but not the other: I'd seen
the same in my test PPA, and the upstream setup.py/requirem
Would you like some help? If so, please push what you currently have to
Salsa so we can see it.
(No promises - #1029251 doesn't look like a big job but I might be wrong
about that.)
Control: tags -1 pending
Looks like rounding error in a test; ignored in Salsa.
Control: reopen -1
Control: found -1 2023.01.0-1
This patch was dropped in the next upload (probably by accident), and
hence this bug has reappeared.
It is currently listed as blocking pandas from testing, though I'm not
sure why (it isn't obvious why pandas and xarray would have to go togeth
Control: tags -1 patch
Control: unblock -1 by 1011225
(Block possibly added by mistake - these don't look related.)
This patch is now available as a Salsa merge request, and passed
build+autopkgtest there.
Package: python3-statsmodels
Version: 0.13.5+dfsg-4
Severity: serious
Since scipy 1.10, some statsmodels tests fail on 32-bit with a message
that int64 -> int32 casting is unsafe. I haven't yet had time to
investigate further.
Control: merge -1 1030210 1030221
Not obviously known upstream.
It's due to the test passing an int64 array to np.bincount (which casts
to native-size int). Hence, we can probably get it to pass by
explicitly casting to int32 in the test code, but I haven't tried that yet.
I don't know exac
Control: reopen -1 1026539
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
It is currently broken (FTBFS due to multiple te
Package: hyperspy
Version: 1.7.3-1
Severity: serious
hyperspy currently FTBFS with several failing tests:
https://launchpadlibrarian.net/678551154/buildlog_ubuntu-mantic-amd64.hyperspy_1.7.3-1_BUILDING.txt.gz
Please do *not* upload theano 1.12 to unstable - it's the Aesara
version, which may seriously break backward compatibility.
I haven't had time to properly look at this bug yet.
To get the new upstream version to work, dask_sphinx-theme, dask and
dask.distributed all need to be updated, in that order. Tests here:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/dask2022p12v2/+packages
dask didn't run its tests (PPAs only build, not autopkgtest), and
dask.distribu
(I meant to send that to the dask/pandas bug, which is #1025393, but
both of them are potential reasons to update dask.)
The intake issue is now https://github.com/dask/dask/issues/9813
(They're planning to fix it in intake rather than dask, but we might not
be allowed to do that after the 12th
Package: python3-pygpu
Version: 0.7.6-12
Severity: grave
numpy 1.24 no longer has np.bool, which makes pygpu fail to import:
pygpu/dtypes.py:74: in _fill_dtype_registry
register_dtype(np.bool, ["ga_bool", "bool"])
numpy/__init__.py:284: in __getattr__
raise AttributeError("module {!r} ha
Package: python3-pandas
Version: 1.5.2+dfsg-4
Severity: serious
Looks like the numpy 1.24 issues I knew about weren't the only ones.
Fix in progress in Salsa.
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
Its reverse dependencies are keras, deepnano and invesalius.
It is currently
Control: retitle -1 dask: B-D on python-numpy-doc which no longer exists
Control: tags -1 pending
The python-numpy-doc error is because that package no longer exists.
This build-dependency has already been removed in Salsa.
However, that version doesn't build the dask documentation due to othe
Probably fixed - see my merge request on Salsa.
On 16/01/2023 07:22, Diane Trout wrote:
On Sun, 2023-01-15 at 14:42 -0800, Diane Trout wrote:
On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote:
Probably fixed - see my merge request on Salsa.
I'd tried to build versions of dask from 2022.03 - 2022.06 and they
all
failed
Source: pymvpa2
Version: 2.6.5-1
Severity: serious
This package FTBFS in sid (plain dpkg-buildpackage) with these test
failures (which are different from the ones in #906399, but the same as
the ones in reproducible-builds).
This bug was found during statsmodels 0.9 transition testing, but al
This is _probably_ the same issue that 0.23.3+dfsg-3 has had since it
was new: some tests run in all installed locales, and on
reproducible-builds (but not buildds without a locales-all dependency)
this includes a few with no text encoding.
The underlying issue is in Python stdlib, and is an e
Control: retitle -1 pocl: nested(?) dlopen fails
Control: reassign -1 libpocl2 1.5-2
Control: affects -1 src:libgpuarray python3-pyopencl
ocl-icd-libopencl1 dlopen()s ICDs (at
https://sources.debian.org/src/ocl-icd/2.2.12-4/ocl_icd_loader.c/#L184).
With pocl 1.5, this dlopen() fails in some co
This is because /usr/bin/pegjs exists in node-pegjs 0.7 but not 0.10.
(/usr/share/nodejs/bin/pegjs exists instead; I have not yet checked
whether it works.)
pegjs maintainer: is this an intentional change or a mistake? The
upstream documentation still mentions the command:
https://sources.de
Package: python3-theano
Version: 1.0.4+dfsg-2
Severity: serious
#graphlib-dot.js
make -C debian/missing-source/graphlib-dot --always-make dist
make[2]: Entering directory
'/build/theano-1.0.4+dfsg/debian/missing-source/graphlib-dot'
pegjs -e 'module.exports' src/dot-grammar.pegjs lib/dot-gramma
Control: retitle -1 schema-salad FTBFS: python-rdflib-jsonld too new
Control: tags -1 fixed-upstream patch
This explicit version check was relaxed (without other changes) in the
next upstream commit, though I haven't tested this change:
https://github.com/common-workflow-language/schema_salad/
Control: tags -1 fixed-upstream pending
The trigger was a change in the outside world, not Debian testing: the
tests (of HTML table parsing) were trying to access a web page that no
longer exists. Fixed in Salsa.
Control: tags -1 pending
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/37217
This appears to fix it, though I'm not yet sure if it's a good idea
I was trying to find upstream's fix and use that instead, but it now
looks like they don't have one, and probably didn't know th
Package: python3-joblib
Tags: fixed-upstream
Control: affects -1 scikit-learn statsmodels
Control: block 966426 by -1
Severity: serious
Justification: causes other packages to FTBFS
Our current version of joblib is incompatible with Python 3.9, which was
recently added to the supported versions
The upstream patch doesn't even apply as-is; this version does, but I
don't have time right now to actually test it.
There's also a circular dependency problem, as dask indirectly
build-depends on itself and my new pandas makes it uninstallable.
Description: pandas 1.1 compatibility
Origin:
ertionError
diff -Nru dask-2.11.0+dfsg/debian/changelog dask-2.11.0+dfsg/debian/changelog
--- dask-2.11.0+dfsg/debian/changelog 2020-02-26 21:01:52.0 +
+++ dask-2.11.0+dfsg/debian/changelog 2020-10-19 08:38:20.0 +0100
@@ -1,3 +1,10 @@
+dask (2.11.0+dfsg-1.1) UNRELEASED; urgency=me
Or maybe not an actual regression...it's a ~5e-7 difference and one of
the things the patch does (at around
dask/dataframe/tests/test_rolling.py:270) is _tighten_ the tolerance on
that test.
I have filed a separate bug (#972516) for the fsspec issues.
That looks like my earlier version, which fails with NameError.
sorry, not any more.
On 19/10/2020 19:57, Rebecca N. Palmer wrote:
That looks like my earlier version, which fails with NameError.
On 19/10/2020 20:07, Stefano Rivera wrote:
Hi Rebecca (2020.10.19_11:51:33_-0700)
Or maybe not an actual regression...it's a ~5e-7 difference and one of the
things the patch does (at around dask/dataframe/tests/test_rolling.py:270)
is _tighten_ the tolerance on that test.
Hrm, I didn't see th
A bot wrote:
Dependency installability problem for dask on all:
dask build-depends on:
- python3-pandas:amd64 (>= 0.19.0)
dask build-depends on:
- python3-distributed:amd64
python3-distributed depends on:
- python3-dask:amd64 (>= 2.9.0)
python3-pandas conflicts with:
- python3-dask:amd64 (< 2.11
Control: affects -1 + pynpoint python-loompy umap-learn
Control: affects -1 + dolfinx python-numpy-groupies
As this bug cannot immediately be fixed, numba may be removed from
testing to unblock the python3.9 transition (#966426).
(If any of the failed tests are silently wrong answers, please d
Confirmed, still exists in pandas 1.1.4, not obviously known upstream.
#969648 was also a datetime issue that appeared during the pandas 1.0 ->
1.1 transition, but I don't know if they're related. (cfgrib wasn't
tested as part of that transition because it doesn't directly depend on
pandas.)
Control: tags -1 upstream
cfgrib's upstream CI is failing, and started failing when it started
using pandas 1.1.x.
Existing discussion (in what was originally a different bug):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974797#28
This bug might also be in llvm or clblas.
On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote:
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201205 ftbfs-bullseye
Does this imply that it was also tested and failed in bullseye? The log
is marked unstable, and the test failures in it are #976620, which is
probably unstable-only.
I have applied this workaround to pandas. However, this only makes
pandas use xlrd less; this bug still exists in other users of xlrd when
defusedxml is installed. By default this includes python3-glue (the
original reason for upgrading xlrd), via the Recommends/Depends chain
python3-glue ->
The above patch is now in Alioth, but please do *not* upload it yet.
$ grep '^model name' /proc/cpuinfo | head -n1
model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
... 4200U is [Haswell] so I guess I can do the testing, right?
If your integrated GPU is enabled (it might not be if y
Has anyone tried the clFFT test I requested above?
Nothing further from upstream.
On 02/05/17 07:57, Andreas Tille wrote:
I can confirm that beignet-dev_1.3.0-2 produces a lot of errors which
vanished when using said status from Git.
Good so far.
- the clFFT test from https://bugs.freedesktop.org/show_bug.cgi?id=100639
This needs a small change to work in sid (its reporter
1 - 100 of 402 matches
Mail list logo
