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
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:
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.
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
and 14 on riscv64, not investigated yet.
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
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
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
Control: reassign -1 src:libgpuarray,src:pocl
Control: retitle -1 wrong results in gemm(batch) in out-of-order queues
libgpuarray checks whether the device supports out-of-order queues, and
requests one if it does (src/gpuarray_buffer_opencl.c:155,185).
pocl 1.3 says it doesn't support
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
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(), &quo
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
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
Package: python3-seaborn
Version: 0.9.0-2
Severity: serious
Found during statsmodels transition testing, but also occurs without
statsmodels. I have not investigated further.
__ TestFacetGrid.test_set_ticklabels
___
self =
def
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
Source: libffi
Version: 3.3-3
Severity: serious
(This is a "block migration while I investigate" bug:
it may well be downgraded or reassigned when I know more.)
https://ci.debian.net/packages/libg/libgpuarray/unstable/amd64/
libffi is one of the few that changed:
(The above debci log is misleading due to #764081; pocl also changed,
and the failure goes away on using the old pocl.)
It looks like this fails because it is reading the result before the
computation has finished:
- On a failure, the np.asarray(gr) passed to assert_allclose doesn't
match cr
This might fix the remaining errors (but has not been tested):
https://docs.python.org/3/library/hmac.html#hmac.new
--- tests/unit/utils/test_utils.py~ 2020-04-09 11:02:26.967201681 +0100
+++ tests/unit/utils/test_utils.py 2020-04-09 11:02:26.991202140 +0100
@@ -85,7 +85,7 @@ class
Package: node-unicode-13.0.0
Version: 0~20200315+gitfc57d75a-2
Severity: serious
Tags: patch
The autopkgtest includes the versioned package name (in both
debian/tests/control and debian/tests/require). As these were not
updated when this changed from 12 to 13, the autopkgtest fails as
Package: node-lodash-reevaluate
Version: 3.0.0-1
Severity: serious
Tags: patch
debian/tests/control has a stray . in the package name. As there is no
package with this name, this causes the test to fail as uninstallable.
Package: pegjs
Version: 0.10.0-1
Tags: patch
Severity: serious
debian/control lists a Provides: nodejs.
This is obviously wrong, and also causes the autopkgtest to fail by not
installing the real nodejs.
Package: node-rw
Version: 1.3.3-1
Severity: serious
Tags: patch
One of this package's upstream tests (encoding-async) requires
(node-)d3-queue. It build-depends on this, but does not test-depend on
it (debian/tests/control last test), so the autopkgtest fails.
Control: tags -1 pending
Control: block -1 by 955399
I just pushed what I think is a fix to salsa, but pandas is currently
BD-Uninstallable due to xvfb (#955399), so it has not been tested.
Package: python3-theano
Version: 1.0.4-1
Severity: serious
Justification: at least one looks like a silently wrong answer
The tests passed (at least on amd64) when 1.0.4-1 was first uploaded,
but 9 tests failed when it was rebuilt as 1.0.4-1+b1 (for Python 3.8,
but I suspect the actual cause
Control: severity -1 normal
Control: tags -1 upstream patch pending
Control: forwarded -1 https://github.com/Theano/theano/pull/6749
On closer inspection, this isn't a "silently wrong answer" bug after
all, so lowering the severity. Some parts of it appear to be caused by
numpy 1.17 and some
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
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
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
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:
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
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:
Control: retitle -1 pandas FTBFS: deprecations/improvements fail tests
The message on the old title is just a warning, but there are 6 other
tests that fail.
I think these are all bugs in the tests not the actual package, i.e.
using our current pandas is fine.
Deprecation warnings in
Control: severity -1 important
Control: retitle -1 statsmodels: on armel may give wrong answer or crash
This bug is no longer an FTBFS as the tests are now ignored on armel,
but still exists. (At least as a crash; we stopped using --forked, so
don't know if there are still also wrong
The linked upstream report says this went away in numpy 1.18.4, and the
tests in question now pass on debci.
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
===
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
+++
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
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:
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
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
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
2020-02-26 21:01:52.000000000 +0000
+++ 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=medium
+
+ * Non-maintainer upload.
+ * Fix test failures with pandas 1.1 (Closes: #969648)
+
+ -- Rebecca N. Palmer M
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
sorry, not any more.
On 19/10/2020 19:57, Rebecca N. Palmer wrote:
That looks like my earlier version, which fails with NameError.
That looks like my earlier version, which fails with NameError.
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 (<
Using --forked revealed that the above is one of 21 test crashes on
armel, and that there are also 2 wrong answers.
The ones I have tried (the wrong answers and most of the crashes) are
not reproducible on qemu-armel.
Package: python3-pytest-asyncio
Version: 0.14.0-1
Severity: serious
Control: affects -1 src:pandas
pytest-asyncio 0.14 tries to use pytest Function.from_parent (e.g. at
pytest_asyncio/plugin.py:39), which does not exist in the archive's
current version of pytest (4.6). This causes at least
This bug can happen even if the tests being run don't actually use
pytest_asyncio (e.g. see pandas 1.0.5+dfsg-2); to avoid it one needs to
not have it installed, i.e. remove the build/test-dependency.
This suggests that the current pytest-asyncio package is totally
unusable without a more
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 =
Control: found -1 0.25.3+dfsg2-3
Control: tags -1 fixed-upstream patch
(untested)
Probably matplotlib 3.3:
https://github.com/pandas-dev/pandas/pull/35323
This doesn't crash when just that test file is run in statsmodels
0.11.1-3 qemu-armel, but this isn't 100% proof that -4 (rather than a
dependency) caused it.
-4 (built locally in qemu) doesn't crash that way either, which suggests
this bug doesn't show up in qemu, and (given the lack of
Control: tags -1 - patch
That's not enough by itself: it does fix that particular error, but
exposes 16 other failures, some of the form
ValueError: The number of FixedLocator locations (8), usually from a
call to set_ticks, does not match the number of ticklabels (4).
and some datetime
Package: python3-statsmodels
Version: 0.11.1-4
Severity: serious
arm64 fail in TestZeroInflatedModel_probit.test_fit_regularized:
https://buildd.debian.org/status/fetch.php?pkg=statsmodels=arm64=0.11.1-4=1597051632=0
https://ci.debian.net/packages/s/statsmodels/testing/arm64/
From the CI
Package: python3-pandas
Version: 0.25.3+dfsg2-4
Severity: serious
One test fails on i386 with a 1-in-last-place difference, probably due
to different rounding (x87 extra precision?).
https://buildd.debian.org/status/fetch.php?pkg=pandas=i386=0.25.3%2Bdfsg2-4=1597048961=0
On 29/06/2020 20:59, Paul Gevers wrote:
Does this mean that numpy should add a Breaks relation on the old pandas
version to avoid upgrading numpy but not pandas on user systems?
Not really - the constant was replaced by its value, so the only
1.19-related change outside of tests is the
Is the above intended as a proposal to remove asynctest?
The rdeps in Debian are hypercorn, python-aioresponses, and (for
autopkgtest only) python-fakeredis.
hypercorn upstream have stopped using it:
https://gitlab.com/pgjones/hypercorn/-/commit/80e2ad5db107c42d42471ea64764d2b42202349c
The
Control: fixed -1 0.25.3+dfsg2-2
Control: tags -1 patch
This is fixed in unstable, and in Salsa's experimental branch. I didn't
consider it worth the buildd resources to upload in experimental,
without also doing some work on other issues such as #877419. (1.0 is
in experimental and not
The TestZeroInflatedModel_probit issue appears to be a failure to
converge: as it does trigger warnings of that, and it's already skipped
on i386, I intend to ignore it.
qemu-arm64:
>>> a
object at 0x4000d31130>
>>> a.res1.params
Traceback (most recent call last):
File "", line 1, in
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.
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 ->
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
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.
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
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,
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
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
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
I'm not aware of a fix for this, and beignet is abandoned upstream and
mostly useful for old hardware (on newer hardware it is replaced by
intel-opencl-icd). However, I may look at it more later (and at least
try llvm-toolchain-12, though I'd expect that to be worse if anything).
Hence, I'm
On 22/09/2021 07:32, Andreas Beckmann wrote:
We will proably still run into problems if different ICDs built against
different LLVM versions are going to be loaded at the same time (e.g.
pocl/llvm9 and intel/llvm1x) because the different llvm versions seem to
stomp on each others internal
Reproduced here; not obviously known upstream. Autopkgtest says it
started between 2021-08-30 and 2021-09-14 in unstable, between
2021-10-10 and 2021-10-18 in testing.
It might be easiest to upgrade to 0.13.0 (if it fixes this - I haven't
checked yet), given that we should do that anyway at
Control: tags -1 patch
This looks similar to #997026, and the same fix appears to work.
Control: tags -1 pending
(fixed in Salsa, as far as I consider it my bug)
It looks like both of these originate further down the stack, not in
libgpuarray:
The *ger error code is an OpenCL compile failure from inside clblast, so
likely either pocl or clblast.
The *gemv problem appears to
Package: python3-numexpr
Version: 2.8.6-2
Severity: serious
Justification: block testing migration of a known security hole
Tags: patch
numexpr 2.8.5 introduced a security check, which was initially buggy
enough to break pyfai and pandas (#1049326). Fixes for this were sent
upstream, but only
Source: openpyxl
Version: 3.0.9-2
Severity: serious
licensecheck -r --copyright . on openpyxl finds these:
./openpyxl/formatting/tests/data/conditional-formatting.xlsx: UNKNOWN
[Copyright: 2007 Apple Inc.]
./openpyxl/reader/tests/data/complex-styles.xlsx: UNKNOWN
[Copyright: 2007 Apple
numba also crashes on mips64el, mipsel and armhf (and s390x but that was
already known; not amd64, i386 or ppc64el). However, I agree that arm64
is a good place to start trying to fix this, given how common it is.
For examples, see the pandas 2.0.3+dfsg-3 / 1.5.3+dfsg-5 build logs.
Given the
On further thought, both of those probably should be fixed in numexpr -
I have pushed them to fix1049326.
With those changes to numexpr, the new pandas (1.5.3+dfsg-5) should
build; pytables will still also need its upstream fix.
stringToExpression() in this numexpr patch needs a default of True for
sanitize (like the others already have), because pytables calls that
directly:
https://salsa.debian.org/science-team/pandas/-/jobs/4571451/raw
(The other failure in there is one I plan to fix.)
The two pytables tests with
Numexpr upstream have what they think is a fix for the exception issue
(though not the overflow change), but it hasn't been tested yet:
https://github.com/pydata/numexpr/issues/442
I pushed this fix to Salsa as the 'fix1049326' branch - it isn't enough
to fix pandas by itself, but is plausibly an improvement.
Given that this is a security feature and we hence want it in quickly,
I'd consider that patch enough to xfail/disable the remaining issues in
pandas, but discussions with upstream are ongoing.
(It also won't do anything about the pytables breakage, known upstream
as #1044.)
Package: python3-numexpr
Version: 2.8.5-1
Severity: serious
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/54449
(actually they found it first)
I only have actual logs for 2.0.x, but I suspect 1.5.x is also affected.
As a short term fix, it may be possible to disable pandas'
This is the same test as #1014278 / upstream 8341, but now on amd64.
From the upstream discussion, it may be a numerically unstable test.
It doesn't fail everywhere: a test build on Salsa CI passed, as did the
last debci runs. (reproducible-builds FTBFS on the second build, on
amd64/sid
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.
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
(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
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}
This combination stopped failing on 2022-11-22/23 (without a dask
upload, suggesting it was fixed somewhere other than dask itself).
Hence, I suggest closing this bug.
Control: severity -1 grave
Control: merge -1 1024795
Control: retitle -1 llvmlite: uninstallable due to llvm-11 removal
It looks like closing and reopening this removed its "blocks"
relationship to 1000941 (the llvm-11 removal request). Hence, llvm-11
has now been removed, making llvmlite
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
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
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
Control: tags -1 pending
Looks like rounding error in a test; ignored in Salsa.
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.)
201 - 300 of 379 matches
Mail list logo
