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 ->
https://lists.freedesktop.org/archives/beignet/2020-January/009251.html
With that partial patch, the errors are
LLVM 10:
builtin_acos_float()clang (LLVM option parsing): for the
--pgo-warn-misexpect option: may only occur zero or one times!
LLVM 11:
In file included from
/build/beignet-1.3.2
(libgpuarray maintainer)
This isn't testable in a qemu-armhf chroot, as pocl doesn't work there.
Do all the non-clblas tests pass? (This can be checked by uninstalling
libclblas-dev then running the tests - this will "error" the clblas
tests but should at least not crash them.)
On 19/11/202
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.
Control: severity -1 minor
Control: retitle -1 imperfect/non-upstreamable architecture detection
The sys.maxsize check should catch amd64 vs i386; the directory check is
mostly to catch other-32-bit vs i386. All this patch does is allow more
rounding error in some tests (because i386 registers
/dar_par.dcf): No such file or directory
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/
Forwarded: not-needed
--- a/doc/samples/Makefile.in
+++ b/doc/samples/Makefile.in
@@ -465,7 +465,7 @@ install-data-hook:
$(INSTALL) -m 0644 $(NO_EXE_SAMPLES) $(DESTDIR)$(pkgdatadir)/samples
Control: tags -1 patch
Looks like the problem is the "-i pythonX.Y" at
https://sources.debian.org/src/pyopencl/2018.1.1-1/debian/rules/#L38 :
that's not valid input to pybuild, and (probably since pybuild commit
https://anonscm.debian.org/cgit/dh-python/dh-python.git/commit/?id=fa7caff4ee25228
lasagne - 3 test failures; fixed upstream by
https://github.com/Lasagne/Lasagne/pull/836
Latest upstream (37ca134; only packaging change was to drop
remove-deprecated.patch) doesn't have these failures. There is a
warning that cuda_convnet is no longer available with Theano 1.0, but
that has
Control: tags -1 patch
The failing tests also happen with the current version installed, so are
probably nothing to do with this fix.
9 tests fail or crash for me, of which 5 are things my hardware isn't
expected to be able to do:
test_coarse_grain_svm - needs OpenCL 2.0
test_scan InclusiveS
Package: python-theano
Version: 0.9.0+dfsg-1
Severity: serious
Suspect the problem is theano/theano/tensor/signal/pool.py:650, which
effectively does int32 = *(int64 *)(pointer_to_some_int_type) - if
some_int_type is int32, that works on little-endian but not big-endian.
Control: tags -1 patch fixed-upstream pending
Ready for upload (the GPU tests again haven't been run, but this
shouldn't touch those parts).
Control: tags -1 fixed-upstream patch
Upstream agree that this is expected under Wayland. The warning can be
disabled with
https://cgit.freedesktop.org/beignet/commit/?id=d1b99a1da56757971753288986419f1b8b9d55f4
This has previously come up in another large game [0], and it was there
noted that while Debian Policy discourages absolute links within a
top-level directory [1], it does not forbid them.
That discussion led to the -X option of dh_link, but note that this only
disables relative/absolute conve
This looks like a GL vs GLES incompatibility: libqt5opengl uses OpenGL
ES on armel+armhf, simgear/flightgear use full OpenGL on all
architectures, and the two can't be mixed.
simgear+flightgear probably can't switch to OpenGL ES because they use
legacy OpenGL functions that aren't in ES. (The
This is known upstream:
https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/96b69154-ebd9-166f-9be5-d4971ee4ab05%40numericable.com/#msg36224500
Upstream keep a dependency list in
https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh
(lines ~330), but i
Package: python-theano
Version: 1.0.1+dfsg-2
Severity: serious
(Filing this as RC to give myself time to investigate: I may downgrade
it later.)
Memory usage increases over theano's tests, to ~6GB by the end of the
python2 set (6981 tests) in Debian sid amd64, and enough to fail the
Ubuntu a
Control: severity -1 normal
This is not a new problem (I'm not sure if it's got worse per test, or
just got noticed because the test suite got longer), so removing the
migration block.
The largest (but not only) leaks are
test_pickle_big_fusion (theano.tensor.tests.test_opt.test_fusion)
test_
Control: severity -1 minor
Control: affects -1 src:theano
Control: retitle -1 libjs-d3: SyntaxError - non-ASCII variable names
This actually does have practical consequences: because d3's source
contains Greek-alphabet variable names (e.g. in
http://sources.debian.net/src/d3/3.5.17-2/src/math/t
Package: libclblas2
Version: 2.12-1
Control: tags -1 upstream
Control: affects -1 beignet-opencl-icd
Some clblas operations use '0.0' (a double-precision literal) not '0.0f'
(a single-precision literal) even when processing single-precision arrays.
This causes it to crash on GPUs that don't su
Package: clang-4.0
Version: 1:4.0.1-5
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
Control: affects -1 beignet-opencl-icd liboclgrind-16.10
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Generating a .pch precompiled header with clan
On 01/10/17 08:38, Ghislain Vaillant wrote:
I thought Theano v0.9.x would require libgpuarray 0.7.x? Or is that for
the future (and probably last) 1.0 version?
The documentation for theano stable (0.9.0, this package) says 0.6.2:
http://www.deeplearning.net/software/theano/install_ubuntu.html#
They have now said libgpuarray 0.6 for Theano 0.9 (i.e. what we
currently have is fine) and libgpuarray 0.7 for Theano 0.10.
https://github.com/Theano/Theano/issues/6454
(#877316 is a separate problem.)
This is actually at least three problems:
- (arm*, mips*el) datetime issues, at least mostly inconsistency in
whether casting NaN to datetime gives NaT.
- (armel, armhf) SystemError in JSON processing. Known upstream as
https://github.com/pandas-dev/pandas/issues/14852 , but they don't have
I intend to file this upstream after investigating further (with a patch
if I can); the main purpose of this Debian bug is to explain why I can't
fully test the theano package I recently pushed.
Possible workarounds for beignet:
- Remove the .pch files entirely. This slows down compiling (which is a
run-time operation in OpenCL): 263sec instead of 90sec for the
540-kernel test suite = ~0.3sec extra per kernel compile. At a guess,
that's unlikely but not impossible to matter in pract
SION_TYPES reproducible
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/877359
Forwarded: no
--- llvm-toolchain-5.0-5.0.orig/clang/lib/Serialization/ASTWriter.cpp
+++ llvm-toolchain-5.0-5.0/clang/lib/Serialization/ASTWriter.cpp
@@ -4153,9 +4153,13 @@ void ASTWriter::WriteOpenCLExtensionType
The problems with current beignet look to be:
- file timestamps in INPUT_FILES_BLOCK (some of beignet's .h files are
script-generated). This part can be fixed in beignet.
- build path captured in ORIGINAL_PCH_DIR. _Might_ be fixable in
beignet by using clang (...) > /path/to/beignet.pch ins
On 07/10/17 14:09, Rebecca N. Palmer wrote:
The problems with current beignet look to be:
- file timestamps in INPUT_FILES_BLOCK (some of beignet's .h files are
script-generated). This part can be fixed in beignet.
That works (COMMAND touch -d '@$ENV{SOURCE_DATE_EPOCH}'
$
It's trying to create a cache directory. You can tell it to do this
somewhere else with the THEANO_FLAGS variable (as we do for the test
suite -
https://sources.debian.org/src/theano/0.9.0+dfsg-2/debian/rules/#L34 ).
What should be done with modules where Python 3.8 compatibility requires
moving to a new upstream release that doesn't support Python 2, but the
Python 2 package still has dependencies (so can't be removed yet under
existing rules)?
- Split them into two source packages with different upstream
On 26/10/2019 22:50, Matthias Klose wrote:
Ubuntu already dropped python-pandas, I wasn't involved with that.
This seems to have been done by the "let things break" approach that
isn't allowed in Debian, e.g. they can no longer build python-matplotlib:
https://bugs.debian.org/cgi-bin/bugreport.
Detailed discussion of pandas has moved to #931557 / debian-science.
Summary:
- python-pandas removal looks feasible, but there is one item that needs
ftpmaster or release team authorization: either let pypubsub out of NEW
(preferred), or give us permission to break tnseq-transit.
- 0.23 -> 0
Python 3.8 is being added (#942106). pandas <0.25 does not support
Python 3.8[0] (when Ubuntu tried they got 268 test failures [1]), while
pandas>=0.25 does not support Python 2.
Hence, our options are:
(a) Remove python-pandas and upgrade pandas to 0.25
(b) Split pandas into two source package
On 28/10/2019 06:30, Mo Zhou wrote:
Hi Rebecca,
Theano is a leaf package
No it isn't: deepnano Depends on it.
(If you used my checker - not finding this is bug
https://lists.debian.org/debian-python/2019/10/msg00106.html )
blocking python2 removal.
What's the blocker for the pending comm
Assuming we're talking about
https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch
I think the actual problem is on the numpy line: it adds the local
inventory but doesn't remove the online one, so the tuple is too long.
(I haven't actua
Package: python3-pandas
Version: 0.25.2+dfsg-1
Severity: serious
Control: notfound -1 0.23.3+dfsg-8
(Filed as RC to make sure I don't forget about these: actual severity to
be decided.)
- Several datetime-related failures on arm* and mips64el.
- Several convert-to-records failures on s390x an
Control: retitle -1 transition: pandas 0.23 -> 0.25
I now have pandas 0.25.2 in experimental, with these autopkgtest failures:
pandas itself: probably I forgot to add a dependency (it passed locally,
but in the same chroot as the build)
statsmodels: looks like a reappearance of #923707 and some
and 14 on riscv64, not investigated yet.
Control: block -1 by 937236
(0.25 is Python 3 only)
I have now done a build test with the new python3-pandas installed:
Success:
bcbio caffe cnvkit dask dask.distributed drms igdiscover lmfit-py
matplotlib mirtop nbsphinx partd patsy poliastro pynwb python-airr
python-apptools python-biom-form
+
+ * Stop build-depending on python-pandas,
+and fix resulting test issues.
+
+ -- Rebecca N. Palmer Thu, 31 Oct 2019 21:42:13
+
+
python-apptools (4.4.0-3) unstable; urgency=medium
* Fixing broken links in python-apptools-doc
diff -Nru python-apptools-4.4.0/debian/control
python-apptools
Package: python-matplotlib
Version: 2.2.4-2
Control: block 937296 by -1
Control: tags -1 patch
pandas upstream dropped Python 2 support in 0.25 (before adding Python
3.8 support). As further discussed in #937296, the Debian package
python-pandas is currently part of a big tangle of circular
(
Package: python3-feather-format
Version: 0.3.1+dfsg1-2
Control: block 931557 by -1
With python3-pandas 0.25, the build fails with these test failures:
==
ERROR: test_boolean_object_nulls
(feather.tests.test_reader.TestFeatherR
Control: retitle -1 NaN -> datetime = 0 (not NaT) on arm*
Control: tag -1 - fixed-upstream
Control: reassign -1 python3-numpy
Control: affects -1 python3-pandas
Control: forwarded -1 https://github.com/numpy/numpy/issues/8325
The underlying issue is that datetime/timedelta are internally ints, an
Control: retitle -1 pandas: test fails/crashes on mipsel
arm* = new tests hitting the already-known issue #877754
(which I don't like having open with no user-level warning, but blocking
the transition over it doesn't actually help)
s390x/ppc64 = bug in the tests, not the library
riscv64 = look
Source: cnvkit
Version: 0.9.6-1
Control: block 931557 by -1
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cnvkit/3322951/log.gz
Package: python3-skbio
Version: 0.5.5-2
Control: block 931557 by -1
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-skbio/3322971/log.gz
Also fails to build; I suspect (but haven't checked) that these are the
same problem.
Source: q2-types
Version: 2019.7.0-1
Control: block 931557 by -1
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-types/3322976/log.gz
Package: python3-statsmodels
Version: 0.10.1-1
Control: fixed -1 0.9.0-6
Severity: serious
While making statsmodels clean up after its tests, I accidentally also
made it ignore failed tests.
Some tests did fail on at least ppc64el and s390x; I don't yet know if
these are actually a serious pr
The test failures are:
armhf: 86, probably all #924036
i386: 1, TestDFM_Approx.test_smoothed_measurement_disturbance out of
tolerance: suspect rounding error (x87 extra precision).
arm64, ppc64el, s390x: the same 3,
base.tests.test_penalized.TestPenalizedPoissonOraclePenalized2*: looks
like
Control: retitle -1 pandas: high RAM usage in test suite
Control: severity -1 normal
The ones I've tried (~half the affected ones) pass on qemu-mipsel when
run in smaller batches.
Memory usage for the whole test suite (on amd64) starts at nearly 1GB
just for *collecting* the tests and continu
Control: severity -1 important
(mostly for ignoring failures, not the actual ones that happened)
After further testing, it looks like
base.tests.test_penalized.TestPenalizedPoissonOraclePenalized2* is on a
convergence edge: if the random seed isn't fixed, it sometimes finds all
4 and sometimes
The Python 2 removal checklist currently says that on uploading a
package as Python 3 only, one should reassign the removal bug to
ftp.debian.org for removal of the old binary, not close it:
https://wiki.debian.org/Python/2Removal
Scott Kitterman wrote (in #938661):
The python-theano binary wa
Control: severity -1 important
Python 3.8 is being added to unstable's supported versions (#942106).
As discussed in #931557, pandas in sid (0.23) doesn't support Python
3.8. pandas in experimental (0.25) does, but contains some API breaks
and doesn't support Python 2, triggering these bugs.
Control: severity -1 important
(blocks pandas 0.23 -> 0.25 transition, and hence python3.8 support)
patsy, pandas and statsmodels form a circular dependency, so they will
all need to drop python2 support at once.
As discussed in #942106 and #931557, this can't happen right now but may
be happ
Control: severity -1 important
Python 3.8 is being added to unstable's supported versions (#942106).
As discussed in #931557, pandas in sid (0.23) doesn't support Python
3.8. pandas in experimental (0.25) does, but contains some API breaks
and doesn't support Python 2, triggering these bugs.
Matthias Klose wrote:
yes, please do [raise pandas 0.25 blocking bugs to "important"]
Done, but only 2 of them have been fixed since.
This leaves 13:
has patch or Ubuntu fix: matplotlib2 patsy python-apptools scikit-learn
may need more extensive work: cnvkit python-feather-format python-skbio
mdp isn't in testing either, but if you're using a policy of "no
py2removals that break packages in testing", tnseq-transit (Depends:
statsmodels) and possibly stimfit (Recommends: pandas) need to be done
as well. Those are both thought to need new upstream versions.
(patsy isn't a leaf packa
On 10/11/2019 13:45, Matthias Klose wrote:
I'm preparing a NMU for scikit-learn, based on the new subminor upstream
release 0.20.3
I don't know why Ubuntu has 0.20.3 and Debian only .2, but it doesn't
look related to either python3.8 or py2removal:
https://scikit-learn.org/0.20/whats_new.html
I have uploaded pandas and statsmodels.
On 10/11/2019 14:18, Matthias Klose wrote:
https://people.debian.org/~doko/tmp/
The patsy one has a bug: as debian/tests/nosetests3 was a symlink to
nosetests2, it should have deleted this link and renamed nosetests2 to
nosetests3, not deleted nosetest
Control: severity -1 serious
python-pandas has now been removed, so these packages are now
BD-Uninstallable.
Matthias disagrees:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942106#73
It should be technically straightforward to make a pandas2 package
(start from the debian-v023 branch and drop the python2 part), but you'd
have to upload it because DMs can't upload NEW packages.
(Only pandas wou
0.25
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/943925
Forwarded: not-needed (upstream have switched to pyarrow)
--- python-feather-format-0.3.1+dfsg1.orig/feather/api.py
+++ python-feather-format-0.3.1+dfsg1/feather/api.py
@@ -15,6 +15,7 @@
import six
from distutils.version
By itself, removing those dependencies reduces the big tangle [0] from
148 packages to 141, the freed ones being: ipywidgets pyqt5 pep8
autopep8 xcffib xlwt cairocffi. (Note that "not in a tangle" means "no
*circular* dependencies", *not* "leaf / can be removed immediately".)
There may also b
psychopy isn't blocking pandas' testing migration because psychopy
already isn't in testing (for reasons unrelated to py2removal).
Upstream say it's now Python 3 compatible [0], but I haven't tried to
fix its other problems.
The ones that are blocking pandas [1] are python-skbio,
python-feath
Control: severity -1 serious
pandas 0.25 is now in unstable.
The explicit Breaks: (causing the current "badpkg" status) end on the
next upload of these packages, but the underlying issues (see above log)
also need to be dealt with.
Ubuntu have dask 2.6.0 and fsspec, but still have a few autopkgtest
failures:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
dask itself - looks like trying to use a nonexistent temporary directory
pyfftw - looks like a test treating a new (unexpected) warni
Control: tags -1 moreinfo
It works for me, in both sid and buster cowbuilder chroots. Has it been
fixed (the version of dune-pdelab hasn't changed, but the bug may have
been elsewhere), or is it hardware/setup dependent?
Control: found -1 1.3.0-1.1
Control: retitle -1 hyantesite: test failures on most architectures
At least on i386, this *isn't* just -0 vs +0 and last-digit rounding
errors: in test 'family' (which applies a cone smoother to a regularly
spaced set of spikes), centre points drop from highest to 0
Control: tags -1 moreinfo
I don't see this in a DIST=sid cowbuilder --build scilab_6.0.1-9.dsc
--binary-indep build: has it been fixed (the -8 to -9 changelog suggests
not), or does my setup allow enough graphics access to not have it?
If the bug does still exist, can someone affected try add
I agree that this is probably fixed in unstable, but as we're in freeze
and unstable has a new upstream version, that won't fix it in buster.
The fix was probably removing the line
-DOCC_INC:STRING="/usr/include/occt" \
from debian/rules (commit 3556b0a, but please don't include the
reformattin
As a fixed version is now in unstable and testing, I suggest closing
this bug.
Control: found -1 4.4.1-5
The /etc/fonts/* issue (but not the out-of-date year) also applies to
testing/unstable.
As they appear to be an already-unused embedded copy from fonts-freefont
(GPL-3 + font exception), and are the .otf not the preferred source
.sfd, it may be best to repack the so
Control: tags -1 upstream
(probably - I haven't actually tried)
The missing centre points (0 instead of max at distance=0) are probably
due to rounding error in the great circle distance
(src/hyantes_run.c:80): equal coordinates should give tmp=acos(1)=0, but
rounding error might make it acos(
However, the "obvious" fix
seems to break ra_pareto, for unknown reasons.
It's not this change that breaks ra_pareto: it was _already_ totally
broken on i386 (all-0s output).
Not using the name 'tmp' for two different variables gives some nonzero
output:
--- a/src/hyantes.c
+++ b/src/hyant
It looks like ra_pareto was also broken on amd64 (probably for the same
"two variables with the same name" reason, though I haven't tested
this), giving a constant output within its range circle, and the
ra_pareto.out reference used that broken version (it's identical to
ra_disk.out).
Hence,
Control: forcemerge -1 926193
Control: tags -1 upstream patch
Control: retitle -1 linux-image-4.19.0-4-amd64: [regression] No graphics on
some IvyBridge / Haswell systems
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=109806
(Summary of the merged bugs - I haven't tried any of
Given that the error is "Illegal instruction", and reproducibly happens
on x86-bm-01 and not the other machines we've tried, could it be
something assuming CPU features more recent than the amd64 baseline?
If so, it's not obvious where: scilab does contain some C/C++ code (as
well as Java), bu
I think this should be a t-p-u upload not a +really, but I'd wait for
release team to decide (see #929108).
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u
On 19/05/2019 18:15, Andreas Tille wrote:
So what is the plan to fix this bug? Create new references to craft
a valid test or ignore these tests?
...or decide that something that's abandoned and doesn't follow its
documentation (even after the above fixes) doesn't belong in Debian
stable and
Control: found -1 6.0.1-10
(I suggest opening a new bug for the 6.0.2 issues: as noted above, that
probably won't be accepted for buster even if we do get it to build.)
Running what I think is the relevant step in a debugger:
* Go to the top level directory of a _built_ source tree (i.e. one t
* valgrind: reports a _lot_ of invalid memory accesses,
It now looks like these are actually "valgrind doesn't understand Java
memory allocation" - 'valgrind jdb' and 'valgrind jar' also report large
numbers of "invalid" accesses.
However, the segfaults are still evidence that this is memory
On 23/05/2019 22:35, Rebecca N. Palmer wrote:
It now looks like these are actually "valgrind doesn't understand Java
memory allocation"
The Valgrind documentation says --smc-check=all should fix this, but it
doesn't.
Ubuntu has a 6.0.2 package that builds in Debian, b
Package: beignet-opencl-icd
Version: 1.3.2-7
Severity: important
Control: block 947435 by -1
(The above version only exists in Salsa; earlier versions won't build at
all with LLVM 8+.)
When beignet is built with LLVM 8+, some operations assert-fail:
compiler_rotate()ASSERTION FAILED: Unsuppor
Progress so far:
compiler_rotate()ASSERTION FAILED: Unsupported intrinsics
The intrinsic in question is an fshl (funnel shift left). I suspect
this issue appeared because LLVM started optimizing rotates to this
intrinsic:
https://github.com/llvm/llvm-project/commit/654e6aabb9f25d0d0fbad19
Block rotate to fshl optimization, as we don't implement fshl.
Set reg for physical registers to avoid out-of-range index crash.
Signed-off-by: Rebecca N. Palmer
---
(where patches 1 and 2 are the LLVM 8/9 ones from
https://svnweb.freebsd.org/ports/head/lang/beignet/files/ ;
see also
Control: reopen -1
Control: found -1 0.25.3+dfsg-6
Control: retitle -1 pandas: HDF I/O crashes on armhf - bus error
test_append_frame_column_oriented does still exist - it was being
silently skipped by -m "not single". Having removed that, it again
crashes on armhf, as do TestHDFStore.test_enc
Re-enabling these tests found that this bug (which is probably actually
multiple bugs) _does_ still exist, on big-endian systems and _possibly_
others.
pandas now (0.25.3+dfsg-7) warns the user when these are used on any
non-x86 system.
** Stata format
- All big-endian (s390x, hppa, ppc64):
Package: dctrl-tools
Version: 2.24-3
Control: tags -1 patch
Example:
grep-dctrl -w -s Package "python3-pandas"
/var/lib/apt/lists/*_debian_dists_sid_main_source_Sources
doesn't find influxdb-python, jsonpickle, poretools and tqdm, while the
same without the -w does. (This caused me to be unawa
These packages were missing from my old packages-to-test list due to
#953014:
influxdb-python jsonpickle psychopy tqdm
They have now been tested:
jsonpickle - OK
influxdb-python (#950063), tqdm - already broken (probably by the 0.23
-> 0.25 transition, where the same bug left them off the to-te
Probably because the arch:all build doesn't build python3-numpy (only
python-numpy-doc), and hence the ls [0] providing the filename for that
>> evaluates to empty.
The obvious fix (though I haven't tested it) is to wrap this in an "only
if building arch:any / python3-numpy" conditional.
[0]
Package: intel-opencl-icd
Version: 19.29.13530-1
Severity: serious
Justification: makes package uninstallable
This package's debian/control hardcodes a dependency on libigdgmm5. As
this library has changed soname to libigdgmm11, this makes it uninstallable.
Changing the dependency may well wo
Package: llvm-9-dev
Version: 1:9.0.0-4
Control: tags -1 patch
llvm-9-dev provides symlinks for both libclang-cpp.so (libclang-cpp9)
and libclang.so (libclang1-9), but depends on libclang1-9 and not
libclang-cpp9.
Control: retitle -1 clblas: *gemm wrong answers in out-of-order queues
Control: reassign -1 src:clblas
Control: found -1 2.12-1
I think I've found the actual bug, in clblas src/library/blas/xgemm.cc:
clblasGemm (with a single command queue) enqueues up to 4 kernels and
returns an event that dep
Package: python-statsmodels-doc
Severity: serious
Control: tags -1 patch
(only tested in 0.11, but believed to exist earlier)
Some documentation examples (e.g. contrasts.rst) fail in a Debian build
because they need to download data.
This has been the case for some time, but only became an FTB
ax in example
+
+Author: Rebecca N. Palmer
+Bug-Debian: https://bugs.debian.org/
+Forwarded: no
+
+--- patsy-0.5.1.orig/doc/spline-regression.rst
patsy-0.5.1/doc/spline-regression.rst
+@@ -179,7 +179,7 @@ marginal spline bases patterns can be ob
+ :{"x1": x1.ravel(),
Package: python-xarray-doc
Version: 0.14.1-2
Severity: serious
Control: tags -1 patch
ipython_directive examples are executed at build time. xarray has some
examples that fail without optional dependencies Debian doesn't have
(e.g. h5netcdf) and/or downloaded data. This used to put the error
Control: reassign -1 python3-sphinx-astropy
Control: tags -1 patch
(untested)
(If reading this in the bug, see
https://lists.debian.org/debian-mentors/2020/01/msg00295.html.)
An intersphinx_mapping can specify multiple alternatives for where to
find the inventory referred to, and these can be
Package: python3-statsmodels
Version: 0.10.2-1
Severity: wishlist
The upstream release notes
https://www.statsmodels.org/stable/release/version0.11.html
don't specifically list API breaks. The one item that is _obviously_ an
API break (removal of DynamicVAR) is something codesearch says we don'
601 - 700 of 1024 matches
Mail list logo
