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
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]
Stefan van der Walt wrote:
One possibility is that NumPy was compiled with an older version of
Cython:[...]
Do you know how I can check the source files for the NumPy 1.17 build
that is used here?
Source: https://sources.debian.org/src/numpy/1:1.17.4-3/
Build log: https://buildd.debian.org/stat
Control: tags -1 pending
This happened when python-statsmodels was removed in 0.10.1-1, and the
documentation was hence moved from /usr/share/doc/python-statsmodels to
/usr/share/doc/python-statsmodels-doc. 0.10.2-1 (in salsa) includes
your suggested fix.
0.9.0-5 -> 0.10.2-1 works, but 0.9.
On 23/11/2019 20:35, Paul Gevers wrote:
Hi Rebecca,
On 23-11-2019 15:33, Rebecca N. Palmer wrote:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-feather-format/3483361/log.gz
appears to have the opposite problem: it finds the new source (-3), but
as this had not yet been built
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-feather-format/3483361/log.gz
appears to have the opposite problem: it finds the new source (-3), but
as this had not yet been built, it used the old binary (-2).
The testing excuses pages for both pandas and python-feather-format
c
On 22/11/2019 17:06, Graham Inggs wrote:
I scheduled statsmodels there, but it
still fails.
The error message points to joblib, which has just been uploaded
(#942899): try again when the new version is available?
This incompatibility is known upstream as
https://github.com/psychopy/psychopy/issues/2189
but has no activity beyond declaring the version restriction.
https://docs.pytest.org/en/latest/deprecations.html#pytest-namespace
has a suggested replacement.
The binNMUs (to add python3.8 support) of pandas and statsmodels failed.
I think this will make them work (but haven't tried it):
- Apply the (existing) #943418 fix to python-xlrd.
- Build matplotlib, pandas and statsmodels in that order. (ben can't
work this out because the declared dependen
On 18/11/2019 07:07, Matthias Klose wrote:
On 18.11.19 07:52, Alastair McKinstry wrote:
So I've uploaded a python-xarray 0.14.0-2 which passes on python3.7.
Its failing on python 3.8 but apparently due to pandas not ready on 3.8, so it
should be ok to pass as the transition completes.
I think
I think that just means "numpy hasn't yet been rebuilt for Python 3.8".
(In Python modules that include a C extension, the .py files are shared
but the C part is compiled separately for each Python version.)
As there are ~500 modules requiring such a rebuild
(https://release.debian.org/transit
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: 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.
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
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
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
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
Control: severity -1 serious
python-pandas has now been removed, so these packages are now
BD-Uninstallable.
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
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
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
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
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.
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
(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
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
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
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
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
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-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.
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
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
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
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
(
+
+ * 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
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
and 14 on riscv64, not investigated yet.
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
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
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
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
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
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
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.
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
Control: retitle -1 matplotlib: has Python 2 Testsuite-Triggers
A bot wrote:
matplotlib 3.0.2-2 ['Testsuite-Triggers->python-matplotlib',
'Testsuite-Triggers->python-matplotlib-dbg', 'Testsuite-Triggers->python-numpy',
'Testsuite-Triggers->python-numpy-dbg', 'Testsuite-Triggers->python-qt4',
On 20/10/2019 14:25, Drew Parsons wrote:
http://sandrotosi.me/debian/py2removal/index.html, where src:libgpuarray
shows with no dependencies,
The 0 there is in the forward Depends column, not reverse depends (maybe
the column order should be changed, given that the reverse depends
column is
The libgpuarray dependency chain is python-lasagne Depends python-theano
Recommends python-pygpu (src:libgpuarray), and none of those have been
uploaded recently.
Did you mean to post this to a different package, or are you using a
checking tool that assumes binary name = python-sourcename and
Control: forwarded -1 https://github.com/andrewrk/browserify-lite/pull/13
Upstream pointed out that this doesn't escape special characters in file
names; corrected version follows.
Subject: Ease reproducible build
author: Rebecca N. Palmer"
Sort module list and dependency lists in o
test was *not* done, as reprotest/disorderfs
fails on my system (I apparently don't have a fuse group even though the
fuse package is installed; I don't know why).
Description: Ease reproducible build
Sort module list and dependency lists in order to be reproducible
Author: Re
Control: reassign -1 cython3
Control: affects -1 python3-pandas python3-skimage
Control: tags -1 fixed-upstream
Control: retitle -1: cython3: generated code does out of bounds reads in
with-dict (subclass of) cdef class
No, it is a proper Timedelta-sized space (144 bytes, not a _Timedelta's
128)
Control: tags -1 - patch
That's not the problem: cdef classes _can_ have non-cdef class (not
instance) attributes. https://github.com/cython/cython/issues/3154
On further inspection, the actual problem is that we have a Timedelta
(full Python class, has a dict) allocated in a memory space siz
There's also a few more of these:
https://salsa.debian.org/science-team/pandas/commit/c6fc5d5ccbec7ca833ca6d2556ab7013aff4b065
However, the above fix doesn't work: cdef attributes can't have default
values.
Control: tags -1 patch
Running the test suite (of -7) under gdb a few times produced a crash in
pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index4]
(4 not 3).
The trace points to Cython-generated C from _Timedelta._has_ns, which
(among other th
The ppc64 failure was this bug, specifically the
pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index3]
version. It was retried successfully. (The hppa failure is something
else.)
The "Build environment" section of the build log (i.e. the versions
Source: sphinx-gallery
Version: 0.2.0-1
Control: tags -1 patch
Control: block 934852 by -1
seaborn, matplotlib2 and sphinx-gallery form a cycle of Python 2
build-dependencies, which makes it impossible to drop Python 2 packages
one at a time without breaking anything.
(I am about to start a d
Control: reassign -1 wnpp
Control: retitle -1 RFP: pandas-datareader
Control: severity -1 wishlist
Control: affects -1 src:pandas
You are correct; moving this to the standard place for new package requests.
In the meantime, it can be installed from PyPI with:
apt-get install python3-pip
pip3 ins
Control: tags -1 unreproducible
Running just the affected test files (in installed -6) produced no
failures in ~350 attempts. The build of -7 succeeded on amd64; it
failed on ppc64, but as the log isn't available yet, I don't know if
it's this bug.
While both tests involve time-related dtyp
Control: retitle -1 pandas: random test crashes
You're right that there are multiple issues here.
--- Random test crashes (this bug):
tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index3]
on amd64; worked when retried, also works here
tests/reshape/test_t
Source: pandas
Version: 0.23.3+dfsg-6
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=pandas&arch=amd64&ver=0.23.3%2Bdfsg-6&stamp=1568839095&raw=0
Was your local build on a different architecture, or must this be
something random / hardware-or-environment-dependent / a very rec
Upstream say Python 3 is supposed to work but that they don't test this:
https://github.com/PyMVPA/PyMVPA/blob/master/doc/source/installation.rst#must-have
This package has been RC-buggy (for unrelated reasons) for over a year
without response, but is quite popular for a scientific package (popc
Control: tags -1 patch
The dependency chain involved is
matplotlib2 -> python-mpltoolkits.basemap -> python-pyproj, python-pyshp
where all but the first no longer exist as Python 2 packages (and pyproj
has also moved to a Python 3 only new upstream version).
Searching the code suggests that
Package: statsmodels
Version: 0.9.0-3
Severity: serious
Control: notfound -1 0.8.0-9
https://buildd.debian.org/status/package.php?p=statsmodels&suite=experimental
This might actually be more than one bug. Some of the armhf ones look
like #924036, but not all of them.
This may be reduced to n
Package: gobby
Nonsense characters instead of (probably) bullet points in
https://gobby.debian.org/export/debconf19/bof/Python
Package: piuparts.debian.org
Since the buster release, stable2sid seems to be failing everything with
E: Repository 'http://mirror-ubc.debian.org/debian buster InRelease'
changed its 'Suite' value from 'testing' to 'stable'
e.g.
https://piuparts.debian.org/stable2sid/fail/python3-statsmodels
Package: lintian
Version: 2.16.0
Severity: wishlist
Control: tags -1 patch
Based on
https://wiki.debian.org/dedup.debian.net#Tips_for_reducing_duplication_in_packages
How: jdupes is simpler, but rdfind+symlinks is currently more popular (8
vs 42 according to codesearch). This may be because
0.9 in salsa is now buildable (but _not_ ready for upload). With this
version installed:
seaborn, tnseq-transit: build successful
pymvpa2: the same FTBFS as with 0.8 (#931888)
pandas only build-depends on statsmodels for documentation examples (run
during build), and the others import (somewhe
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
Source: pandas
Version: 0.23.3+dfsg-3
Severity: wishlist
(Posting here rather than debian-release as that is generally not used
for interpreted language modules)
Upstream have released 0.24.2. They are likely to release 0.25 soon,
but I do *not* intend to go straight to that as it drops Pyth
Source: statsmodels
Version: 0.8.0-9
Severity: wishlist
(Posting here rather than debian-release as that is generally not used
for interpreted language modules)
Upstream have released statsmodels 0.10.0. I am not yet sure whether to
go straight for that or do 0.9.x first.
The upstream rele
Some more testing:
* When run normally, or in gdb with "handle SIGSEGV nostop pass", 6.0.1
has the IllegalStateExceptions and undocumented macro warnings, 6.0.2
does not; both finish.
* valgrind --smc-check=all crashes at about the same place as this bug
(but with a segmentation fault instea
Some further searching suggests that Java triggers and catches SIGSEGVs
as part of normal operation, and hence is expected to not work under gdb
without "handle SIGSEGV nostop pass". With this, both 6.0.1 and 6.0.2
don't crash in gdb, i.e. the crash in gdb probably isn't this bug.
This sugges
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
* 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
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
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
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
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
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
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,
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
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(
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
As a fixed version is now in unstable and testing, I suggest closing
this bug.
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
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
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
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?
I do see this bug in both sid and mostly-buster (I haven't tried
creating a new buster chroot). If only some people see this bug, but
who sees it is reproducible, that could be a sign of another problem
such as the package doing build-time hardware detection.
(https://sources.debian.org/src/hi
Control: retitle -1 statsmodels: KalmanFilter wrong results on armhf
Control: found -1 0.9.0-2
Control: found -1 0.8.0-7
This is not a regression - it only looks new because the upstream tests
weren't previously run.
Also reported as
https://bugs.launchpad.net/ubuntu/+source/statsmodels/+bug/1
Control: tags -1 - moreinfo
Built on every release architecture, autopkgtest good.
As discussed, please also give back statsmodels, as the new pandas
should allow it to build.
ataFrame. (Closes: #923707)
+ * Revert "Add documentation examples dependencies" to comply with
+freeze policy.
+
+ -- Rebecca N. Palmer Mon, 04 Mar 2019
21:59:43 +
+
pandas (0.23.3+dfsg-2) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
(Not release team)
Iain Lane wrote:
I should have uploaded this with a higher urgency probably
That wouldn't have done anything: urgencies have been ignored since soft
freeze.
some quite nice
fixes
Are any of them Important or higher?
https://release.debian.org/buster/freeze_policy.html
Source: pandas
Version: 0.23.3+dfsg-2
Severity: important
Control: tags -1 fixed-upstream patch
np.array @ Series actually calculates Series @ np.array, which is an
error for nonsquare matrices and a *wrong answer* for square matrices.
Fixed upstream by
https://github.com/pandas-dev/pandas/pu
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 +=
Also changing the ipython dependency to ipython3 fixes this.
The documentation so built does contain some error messages in its
example output (the examples are run during build), including attempts
to download data (not allowed in Debian package builds), and attempts to
use modules we don't b
The build log (
https://launchpadlibrarian.net/412630196/buildlog_ubuntu-disco-amd64.pandas_0.23.3-1fakesync1ubuntu3_BUILDING.txt.gz
) suggests this is due to passing a PYTHONPATH to the just-built
python-pandas, but not -lib or python3-, causing a failed import.
However, the obvious way to fi
401 - 500 of 922 matches
Mail list logo
