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
Is the subject line a leftover, or are you actually proposing to move
0.9.0 from experimental to unstable (which is not generally allowed in
soft freeze)?
The upstream fix for #880245 (the original reason given for wanting the
new version) is supposedly
https://github.com/statsmodels/statsmo
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
On 13/02/2019 09:10, Andreas Tille wrote:
Any volunteer to backport the relevant changes I pushed to Git right now
to 0.8.0?
I intend to try tomorrow, if the uploaders don't say anything first.
I'm actually wondering why the package did not got any removal
from testing warning (or did I misse
Package: lintian
Version: 2.5.94
Severity: minor
Control: tags -1 patch
autopkgtest recently (5.4) added two new Restrictions, flaky and
skippable. Lintian does not know about these and hence reports
unknown-runtime-tests-restriction.
This can probably be fixed by adding them to the list at
I take this discussion to mean the existence of autopkgtests is
considered a good thing even when they can't be run on ci.debian.net
(should we explicitly say that somewhere?). I hence added some to
beignet (an OpenCL driver, so hardware specific).
Simon McVittie wrote:
At some point I might
Package: tracker.debian.org
Severity: minor
Control: tags -1 patch
The 'all' bugs count double-counts 'patch' bugs (but not 'help' or
'newcomer' bugs, which also appear both there and in a severity
category), e.g. https://tracker.debian.org/pkg/debhelper
Can probably be fixed (though I haven'
Package: autopkgtest
Severity: wishlist
Control: block -1 by 901804
(From #901804 discussion, moving to a new bug as requested.)
On 29/07/18 14:58, Paul Gevers wrote:
[...]> On 27-07-18 22:49, Rebecca N. Palmer wrote:
[...]
Simon McVittie wrote:
At some point I might add a way to mark s
Control: tags -1 patch
(in https://salsa.debian.org/ci-team/autopkgtest/merge_requests/24)
On 29/07/18 14:58, Paul Gevers wrote:
I think we should keep
neutral-to-fail a regression.
I agree that neutral (tests all ignored) -> fail should be a regression.
I was referring to the no tests -> fa
On 31/07/18 14:59, Paul Gevers wrote:
Not sure if that would be the same value of trivial.
I agree that "should trivial be a defined Restriction" and "should
autodep8 and similar checks that we can import/link to/etc this (i.e.
checking its top-level module for syntax errors/missing dependenc
Package: autodep8
Severity: wishlist
(Moving to a new bug: note that I have not decided whether I agree with
this proposal.)
On 31/07/18 14:59, Paul Gevers wrote:
Hi Rebecca,
On 30-07-18 08:57, Rebecca N. Palmer wrote:
On 29/07/18 14:58, Paul Gevers wrote:
[...]
A similar idea has come to
On 01/08/18 02:58, Antonio Terceiro wrote:
FWIW, most of the supported package types do already set allow-stderr.
From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append
`2>/dev/null` to the Test-Command.
Those being dkms, go, octave, r (allow-stderr) and ruby (2>&1). I don't
s
Package: python3-pygpu,python3-theano
theano.gpuarray does not work because the currently packaged version of
pygpu is too old for it.
Is there a reason for not packaging 0.7.x or have you just not got
around to it? According to codesearch, theano is the only package using
pygpu, so compati
Source: sphinx
Version: 1.7.5-1
Severity: serious
Control: tags -1 patch
Control: affects -1 src:theano src:python-jira
(These are the ones I've actually checked; I suspect most/all of the
~100 packages that build-depend on *-sphinx-rtd-theme are affected.)
sphinx's included themes have layout.ht
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
This breaks the (6 according to codesearch [0]) links from Developers'
Reference to specific Policy sections.
[0]
https://codesearch.debian.net/search?q=package%3Adevelopers-reference+url-debian-policy%3Bch-
Should this also make explicit which Debian suites have this restriction?
I thought this rule also applied to backports having found [0] in a list
archive search, and hence have been explicitly changing dependencies for
backports [1] instead of using alternatives.
However after finding this p
Laura Arjona Reina wrote:
I didn't add exact rules to match
www.debian.org/doc/debian-policy/footnotes.html#f1 to
www.debian.org/doc/debian-policy/#id1 etc because I'm not sure all the
"old" footnotes and the "new" footnotes match in content
They don't - they're not even unique in the one-page ve
Control: retitle -1 unnecessarily scary warning under Wayland
I also see this warning, but beignet still works after it.
Is this also the case for you (to check, run
/usr/lib/x86_64-linux-gnu/beignet/utest_run from the beignet-dev
package) or is your beignet actually broken?
Package: libqt5wayland5,plasma-workspace-wayland
Version: 5.7.1~20161021-2,4:5.8.6-2.1
Severity: minor
To reproduce (>50% but not 100% reproducible):
- right-click on two areas, opening both their right-click menus (the
example below was two application launchers, but the desktop then an
empty
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 fixed-upstream
Upstream have a different patch for skipping CUDA-only tests on OpenCL
(which I haven't tried myself):
https://github.com/Theano/libgpuarray/commit/f036aef3a425560161de362f390d238f4e7c1721
There are also two real issues in this set of test failures/errors:
- e
Control: tags -1 patch
The only required packaging change to build the new version is to update
the soname (see below). I only tested the Python 3 version on pocl,
which passes (i.e. #870128 is gone as expected).
Other things you might want to look at while you're making an upload:
- libgpua
To identify more precisely what isn't working, please install the
beignet-dev package and run
OCL_IGNORE_SELF_TEST=1 /usr/lib/x86_64-linux-gnu/beignet/utest_run
Is this a new problem (i.e. have you used it without this error before),
and if so, when did it start?
darktable doesn't actually us
The lack of failures is strange - does the original bug still exist?
(beignet hasn't changed, but it might be elsewhere.) Does
/usr/lib/x86_64-linux-gnu/beignet/utest_run without OCL_IGNORE_SELF_TEST
also report "self-test failed"?
On 01/01/18 22:38, Achim Schaefer wrote:
Here I see something different:
displacement_map_element() [SUCCESS]
compiler_mandelbrot()utest_run:
/build/beignet-ydQSQk/beignet-1.3.2/utests/utest_helper.cpp:713: void
cl_write_bmp(const int*, int, int, const char*): Assertion `fp' failed.
Inter
I have now reproduced this bug, but have not yet had time to investigate
further.
On 02/01/18 23:16, Achim Schaefer wrote:
now boinc does not find the GPU anymore.
This was after a restart, I don't know when I started boinc the last time.
This might be the same bug, but I don't know if/where
Control: tags -1 patch
Description: Fix self-test fail in Darktable
Reverts upstream 81755054c4c19d821e58456a1a7d601806e60e92
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/885423
Forwarded: todo
diff --git b/backend/src/backend/gen_insn_selection_optimize.cpp a/backend/src
Package: nm.debian.org
Severity: minor
The page requesting one's signed agreement to the SC/DFSG/DMUP contained
the text below when I used it: 'convenince' is mis-spelled, and
'Policy...them' is grammatically incorrect (it should probably be
'Policies').
The latter would presumably need to b
Package: nm.debian.org
Severity: minor
- The documentation on the wiki (
https://wiki.debian.org/DebianMaintainer#step_1_:_Identification ) says
1 (but that more is recommended).
- The form for registering oneself in the NM database says 2 are needed
(but doesn't enforce this, presumably becau
On 11/03/18 16:06, Mattia Rizzolo wrote:
the DMUP is one policy (you have read it, right??)
It's one document, but its title uses the word 'Policies'.
'Policy..it' would also be grammatically correct.
This is because tornado 5.0 deliberately removed
ioloop.IOLoop.initialized() because "It is no longer possible to provide
this method with reasonable semantics":
https://github.com/tornadoweb/tornado/commit/426b3812b9dd21ae0bac19d4146c6952816c7bfe#diff-1d4144f0ef561b7c18c7fe438816e1f5
This bug
Source: theano
Severity: wishlist
(Posting here rather than on debian-release as the formal transition
process is rarely used, and its tools mostly useless, for non-compiled
cases.)
Theano 1.0 (currently in Salsa) contains some API-breaking changes:
http://www.deeplearning.net/software/theano
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org
python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so if you need it, please build-depend on it. (Or python3-setuptools,
given that this looks like it might prefer that.)
(
o use setuptools instead
of distutils as recommended by the PyPA?
Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer a
écrit :
Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org
python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so i
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
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
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 +=
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
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: tags -1 pending
This is the same underlying problem as #992673, but for this one it
looks like switching to clblast is enough to pass the tests we actually
run. (Which isn't all of them because the GPU part of theano has never
fully worked under OpenCL, but we already warn the user a
Control: retitle -1 libgpuarray: *gemv broken on libclblast
For now I have disabled *gemv when used with libclblast, to make this
bug an explicit error rather than a silently wrong answer.
These functions are still available with clblas, but that has enough
other issues (https://bugs.debian.o
There's also this test failure on arm64 (which is at least a crash not a
wrong answer), again with clblast not clblas. It probably isn't a new
problem either: the tests were previously run with clblas only.
(The "regression" on ppc64el is that the test has never been installable
there and we'
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
On 17/02/2021 10:00, Andreas Beckmann wrote:
Note to self: `reportbug clinfo` should report all installed ICDs
Feel free to borrow beignet-opencl-icd.bug-script
On 22/02/2021 12:44, Drew Parsons wrote:
v1.2.2 is the latest pandas release
Has this error in test_from_coo been fixed in that latest release?
Not obviously, but I haven't tried actually running that.
Is scipy 1.6.1 intended for bullseye?
What, if any, action are you proposing before bullseye? Or is this a
request for an up-to-date pandas in experimental?
That workaround just disables the affected test, i.e. it will probably
fix the FTBFS but do nothing to the underlying problem. As noted in
#983404, a real scipy fix also exi
Fine by me, thanks.
Control: reassign -1 src:statsmodels
Control: tags -1 fixed-upstream
Appears to be these (but not yet tested in Debian):
https://github.com/statsmodels/statsmodels/issues/7371
https://github.com/statsmodels/statsmodels/issues/7453
clblas has been replaced by clblast, so I tried switching to that, but
doing so makes a varying number of cases of test_gemv fail, e.g.
==
FAIL: pygpu.tests.test_blas.test_gemv((128, 50), 'float32', 'c', True,
False, 2, True, F
This _might_ be an API break. The reverse dependencies are snakemake
and congress.
snakemake recently started declaring a <=1.6.8 version restriction:
https://github.com/snakemake/snakemake/commits/a7ac40c96d6e2af47102563d0478a2220e2a2ab7
However, their reason seems to be that pulp 2.x doesn't
Jessica Clarke wrote:
It seems to me like dpkg has done a very dodgy
sequence of events that have resulted in the system being broken for a
short period and, whilst most don't notice, cowdancer does. Why is this
not a dpkg (or apt) bug? It should be possible to do that sequence in a
way that pres
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
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: gobby
Nonsense characters instead of (probably) bullet points in
https://gobby.debian.org/export/debconf19/bof/Python
Control: tags -1 patch
If you'd prefer to just fix this without (for now) the broader rewrite,
https://salsa.debian.org/qa/qa/-/merge_requests/28 claims to do so; I
haven't tried it but it looks plausible.
Weirdly, this bug doesn't seem to affect everything with build profiles:
of my package
This appears to be fixed, probably by
https://salsa.debian.org/qa/qa/-/commit/56fbe1b36e3a8ec9064cb9ce6cbcbfd5448feb61
(Fixed on qa.debian.org/dose/debcheck/...;
qa.debian.org/debcheck.php?... doesn't have a tracker link at all.
Should it?)
Control: retitle -1 debcheck: :$arch and :native always appear broken
Since
https://salsa.debian.org/qa/qa/-/commit/526d2319174cb15111bb2d6c702f8e23ee7bd0d7
, arch-specific Depends don't crash debcheck, but do search for a
package named literally $package:$arch not just $package. As this does
debcheck processes a single release per run, so in its current form
can't check this, or anything that requires comparing multiple releases.
(The oldlibs check looks for explicit Section: oldlibs labels.)
There is a separate tool on jenkins that does check this:
https://salsa.debian.org/qa/jen
Control: retitle -1 UDD/dmd: fails to load when debci data is missing
The problem isn't the number of packages, but some specific packages
that can't be displayed even when they are the only package requested:
https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=node-file-entry-cache&ig
Johannes Schauer wrote:
In particular, in the "CI" column, look for those rows where the first line
shows exactly "✔-" -- those packages have to be excluded. Failures are fine and
even both missing is fine but a checkmark followed by a minus triggers that
bug.
Neutral/missing ("⛔-") is also bad
Control: reassign -1 src:llvm-toolchain-10
Control: reopen -1
Probably still exists, though pocl no longer appears affected:
$ strings /usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1 | grep "/clang/"
/usr/lib/llvm-10/lib/clang/10.0.0/include
$ strings /usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0 | gr
This fix causes Sphinx to fail if documenting an object whose
__getattr__ fails, e.g. flask.request. This causes at least snakemake
to FTBFS.
Details and fix:
https://github.com/sphinx-doc/sphinx/pull/7520
A workaround in failing packages is to add
autodoc_default_options = {'exclude-members'
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: affects -1 snakemake
Upstream snakemake have now moved to pulp 2.x - but went straight from
1.x only to 2.x only, i.e. they need to be upgraded together.
Most of these tests no longer fail in 0.11.1-5 (current Ubuntu) and
0.12.0-2 (current Debian), but 3 still do: two variants of varmax
test_bse_oim, and test_pickle_fit_sarimax.
Control: merge -1 972015
Control: found -1 1.0.5+dfsg-3
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/36296
Control: tags -1 fixed-upstream
pandas 1.1.3 may fix this, but moving to 1.1.x triggers #969648.
There's a 1.1.3 package in Salsa, but it hasn't been tested. (With
python3-all-dev from experimental, it fails because numpy doesn't have a
3.9 build yet.)
Control: block 972033 by 969650
This is now the only bug blocking pandas 1.1. Is there something wrong
with the above fix, or have you just not had time to try it?
Upgrading dask to a newer upstream version is also an option, but I
haven't checked if it would break anything else.
Python 3.
The linked upstream report says this went away in numpy 1.18.4, and the
tests in question now pass on debci.
Control: severity 969648 serious
Control: tags 969650 pending
Control: tags 972033 pending
Python 3.9 related breakage has been declared RC, so if nobody objects,
I intend to upload pandas 1.1 to unstable (possibly tonight, but it
probably won't build before numpy and matplotlib are binNMUd fo
Control: tags -1 - pending
The package currently in Salsa doesn't work. test_statsmodels is
probably a circular dependency that should be ignored for now;
TestHDFStore is under investigation.
=== FAILURES
===
T
The error message has gone for me as well, but I don't have the hardware
to tell whether mesa-opencl-icd actually works. Have you checked this?
I agree that this is probably the same bug as #964973, which is marked
as fixed.
This bug is not specific to DateTimeIndexes, and the immediate cause is
the index being passed to numpy as a
pandas.core.computation.pytables.Constant instead of an int:
$ python3.9
Python 3.9.0+ (default, Oct 16 2020, 17:57:59)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "lice
Control: tags -1 patch
The underlying cause (and reason this is 3.9-specific) appears to be the
mostly-removal of ast.Index and its replacement by a bare value.
This appears to fix it, though I'm not yet sure if it's a good idea:
--- a/pandas/core/computation/pytables.py
+++ b/pandas/core/com
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
Package: python3-dask
Version: 2.11.0+dfsg-1
Some of fsspec's functionality now requires python3-aiohttp, including
parts used in dask autopkgtests:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/7549002/log.gz
Some of these work if I add a test-dependency, but 2 continue to fail
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.
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
I don't think this is a moderation-specific problem, as I've had it on
-backports: see below, "From cmake information".
Forwarded Message
Subject: DMARC fail on non-spam - is this a lists.d.o bug?
Date: Sat, 22 Feb 2020 17:36:58 +0000
From: Rebecca N.
Package: python3-pandas
Version: 0.25.3+dfsg-9
Severity: serious
Tags: fixed-upstream patch
numpy 1.18 includes two behaviour changes that affect pandas, causing a
CI fail / presumed FTBFS.
Both are fixed in pandas 1.0 (in experimental, but moving that to
unstable causes other issues, see #95
Control: tags -1 patch
The failed tests are expecting an 0/0 warning from numpy, which it
produces on amd64 but not armel:
amd64$ python3
Python 3.8.2 (default, Apr 1 2020, 15:52:55)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy a
gregor herrmann wrote:
This link and the whole check would be helpful only for not-migrated
alioth lists which don't work anymore but I guess lintian has no
chance to make this discrimination.
Lintian already has a list of individual known-bad addresses
(data/fields/bounce-addresses, tags *-ca
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
Note that these are distinct:
- conda, the package manager itself; BSD-3 licensed
- Anaconda Individual Edition, a bundle of conda + some commonly-used
packages; non-DFSG-free as it includes intel-mkl and cudnn
(https://docs.anaconda.com/anaconda/eula/)
- Anaconda repository, the server conda us
A potential problem is that upgrading pandas breaks some of its reverse
dependencies: whether this is a blocker for backports is being discussed
at https://lists.debian.org/debian-backports/2020/04/threads.html#00062
Packages thought to break are
cnvkit influxdb-python snakemake statsmodels tqd
Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Some packages' vcswatch pages have the error
fatal: could not read Username for 'https://salsa.debian.org': No such
device or address
(e.g. apertium-bel, python-asteval) or
remote: Retry later fatal: unable to acces
Control: clone -1
Control: reassign -1 qa.debian.org
Control: retitle -2 apertium-bel: stray cgit in Vcs-Git
spyder, python-asteval and beignet don't have a cgit in Vcs-Git. Hence,
while I agree it's a bug that apertium-bel does, this alone doesn't
explain either of the above messages.
The packages below have cgit in Vcs-Git and a vcswatch error.
Maybe Lintian should check for this (vcs-field-bitrotted?). However,
libvmime also has cgit in the address, but its vcswatch reports success.
apertium-bel
arduino-mighty-1284p
astrodendro
casacore-data-igrf
casacore-data-lines
casa
Control: retitle -1 RM: hyantesite -- RoM; behaviour does not match
documentation, upstream/uploader inactive
The patches above and regenerating the test references would probably
fix the FTBFS, but that still leaves the code for amortized_disk and
pareto not matching the documentation. It wou
Package: www.debian.org
On the packages.d.o pages of arch:all packages from sid, bullseye or
experimental, the "list of files" link gives the error message "No such
package in this suite on this architecture."
This does not affect arch:any packages, or packages from stable.
e.g.
fails - http
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.
Package: python3-xlrd
Version: 1.2.0-1
Tags: patch
xlrd 1.2.0 started using defusedxml if available.
As defusedxml.cElementTree does not have a top-level ElementTree
attribute, Element_has_iter gets set to False
(https://sources.debian.org/src/python-xlrd/1.2.0-1/xlrd/xlsx.py/#L59).
However,
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.
Control: severity -1 serious
Control: affects -1 pandas
This breaks the default form of pandas.read_excel().
A workaround for this is to use pandas.read_excel(engine='openpyxl'),
and pandas upstream have made this the default:
https://github.com/pandas-dev/pandas/pull/35029/files
I intend to
501 - 600 of 1024 matches
Mail list logo
