Package: librust-plist-dev
Version: 0.5.1-1
Severity: serious
Tags: fixed-upstream
librust-plist-dev depends on and the rust-plist source package build-depends on
librust-humantime-1+default-dev , which is no longer available. Upstream seems
to have moved to humantime 2 which should fix this.
Since this bug had no maintainer response for a month I decided to go ahead
with a NMU, the debdiff is attatched (same as helmuts other than changelog
tweaks).
diff -Nru cracklib2-2.9.6/debian/changelog cracklib2-2.9.6/debian/changelog
--- cracklib2-2.9.6/debian/changelog2019-11-19 15:14:51
If my understanding is correct I see two possible ways forward.
1. Rebuild python3.8 against the new glibc.
2. Remove the stropts include from samba, it doesn't seem to actually be used
for anything (at least I can't find any other references to HAVE_STROPTS_H in
the code).
I am currently t
The samba FTBFS is blocking the python 3.8 transition in raspbian bullseye, so
I decided to take a look.
error: Unable to determine origin of type `struct cli_credentials'
I don't think this is the error that is causing the build failure. The same error can be seen
in succesful build logs. e.
On 30/03/2020 14:01, Felix Lechner wrote:
I suggest excluding CamelCased words from the spelling check.
I have not seen a lot of GUI items in camel case (which would cause
more legitimate strings like it to appear in binaries) and do not
perceive 'aCount' as a false positive.
In delphi-style o
Package: pyregion
Version: 2.0-8
Severity: serious
pyregion fails to build from source in bullseye/sid, I first noticed this on a
raspbian autobuilder,
but it's also happening on the reproducible builds service, so it's not
raspbian specific.
Running Sphinx v1.8.5
/usr/lib/python3/dist-packag
Package: ruby-rspec-puppet
Version: 2.7.8-1
Severity: serious
ruby-rspec-puppet depends on "puppet-common", this has been a transitional
package since stretch and has now been dropped by the puppet source package.
Please change your dependency to puppet.
Package: puppet-module-aboe-chrony
Version: 0.2.4-2
Severity: serious
puppet-module-aboe-chrony depends on the puppet-common transitional package
which is no longer built by the puppet source package. Please update your
dependencies.
Source: rust-cookie-factory
Version: 0.3.0-1
Severity: serious
error[E0432]: unresolved import `io_compat`
--> src/lib.rs:32:21
|
32 | pub use io_compat::*;
| ^ help: a similar path exists:
`crate::io_compat`
|
= note: `use` statements
Source: wine-development
Version: 5.2-3
Severity: serious
wine-development build-depends on unicode-data (<< 13) but the version of
unicode-data in testing is 13.0.0-1 and the version in unstable is 13.0.0-2
Source: rust-signal-hook
Version: 0.1.12-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing. Please make a source-only upload so your package can migrate.
...
The following packages have unmet dependencies:
python3-vtk7 : Depends: python3 (< 3.8) but 3.8.2-1 is to be installed
Unable to resolve dependencies! Giving up...
...
This was a result of the python 3.8 transition, vtk7 has now been rebuilt on
most architectures (mips is still building)
Package: dgit
Hi.
I just ran into the following error:
['dgit', 'import-dsc',
'/build/workingrepo/pool/main/g/gtk+3.0/gtk+3.0_3.24.14-1.dsc',
'+workingbranch']
Dgit metadata in .dsc: specified git info (debian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro debian:
Package: alsa-lib
Version: 1.2.2-2.1
Severity: serious
Tags: bullseye, patch
I just ran into the following build failure in raspbian bullseye, checking on
reproducible builds confirmed that the failure is not raspbian specific.
http://buildd.raspbian.org/status/fetch.php?pkg=alsa-lib&arch=armhf
Package: gyoto
Version: 1.4.4-1
Severity: serious
gyoto is failing to build on armel, armhf, mipsel and mips64el
the error in the arm build logs seems to be:
Test reference counting ... SEVERE: Cannot convert to seconds as metric is not
set!
SEVERE: Cannot convert to seconds as metric is not
Relevant packages and bugs:
943107 git-buildpackage: Python2 removal in sid/bullseye
This bug is not marked as rc.
Nevertheless I believe that this bug report is in-fact a false positive. From
what I can tell git-buildpackage, even in buster, does not (build-)depend on
python 2 or any python
Package: xcffib
Version: 0.8.1-0.7
Severity: serious
x-debbugs-cc: cairoc...@packages.debian.org
The last two uploads of xcffib (-0.7 and -0.8) both failed to build on s390x
because of a testsuite timeout. This is preventing the fix for the broken
build-depends from migrating to testing.
test
Source: spectral-cube
Version: 0.4.5-1
Severity: serious
Astropy was recently updated to support the new version of wcslib.
Unfortunately this fix is being blocked from migrating to testing by an
autopkgtest failure in spectral-cube, this is happening in both in migration
tests and in plain un
Source: python-csa
Version: 0.1.10-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing, please make a source-only upload so your package can migrate.
Package: python3-whiteboard
Version: 1.0+git20170915-3
Severity: serious
python3-whiteboard depends on python3-cwiid, however I can't find any evidence
of this package existing, it's not in debian, it doesn't appear to be in new
(at least searching new for cwiid doesn't show anything) and my go
Package: stimfit
Version: 0.16.0-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing. Please make a source-only upload so your package can migrate (and
preferablly fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948020 at the
same t
I just found my Debian arm64 Pi and tested this, it seems to work after setting
"iomem=relaxed" on the kernel command line.
More than enough time has passed since my last mail where I said I would NMU
after testing, so I have gone ahead with the upload.
Package: raspi-firmware
Hi,
Sometimes it is necessary to add parameters to the kernel command line, for example
rpi.gpio requires "iomem=relaxed".
In the current setup there is no good way to do this, editing cmdline.txt
directly will result in changes being overwritten on the next kernel upg
Source: webdis
Version: 0.1.4+dfsg-1
Severity: serious
Tags: bullseye, sid
webdis build-depends on the python-msgpack binary package, which is no longer
built by the python-msgpack source package. It is still present in unstable as
a cruft package, but is completely gone from testing.
As I mentioned in a previous mail to debian-release the dependency tracking in
auto-removals seems to be buggy, this has resulted in britney trying and
failing to remove rust-rand. This in turn blocks any attempt to migrate the new
(and fixed) rust-rand.
I am bumping this bug report to get the
Severity 946150 serious
Thanks
The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and libiptc0
binary packages. The content is included now in either libip4tc or libip6tc.
Such change comes from upstream.
It also dropped the iptables-dev package, which miniupnpd build-depends on
Package: keepalived
Version: 1:2.0.19-1
Severity: serious
keepalived build-depends on iptables-dev, which is no longer built by the
iptables source package. It is still present in unstable as a cruft package,
but is completely gone from testing.
Before it's removal iptables-dev was a transitio
Package: iproute2
Version: 5.4.0-1
Severity: serious
iproute2 build-depends on iptables-dev, which is no longer built by the
iptables source package. It is still present in unstable as a cruft package,
but is completely gone from testing.
Before it's removal iptables-dev was a transitional dum
Package: collectd
Version: 5.9.2.g-1
Severity: serious
collectd build-depends on iptables-dev, which is no longer built by the
iptables source package. It is still present in unstable as a cruft package,
but is completely gone from testing.
Before it's removal iptables-dev was a transitional d
Source: volume-key
Version: 0.3.12-2
Tags: bullseye, sid, patch
Severity: serious
volume-key currently fails to build because of a missing build-dependency on
dh-python, please add it.
tags 950402 +patch
thanks
This build failure is fixed by upstream commit
faaa552de9ec099184d131c08b76ae0b1ce4f5ec , I adapted it to apply to the debian
package and was able to sucessfully build the patched package in a raspbian
bullseye-staging environment.
I have uploaded the fixed package t
tags 950172 +patch
thanks
This build failure was a simple case of a missing #include "exiv2/error.hpp" ,
I fixed it in raspbian, a debdiff should appear soon at
https://debdiffs.raspbian.org/main/g/gpscorrelate no intent to NMU in debian.
tags 950310 +patch
thanks
This build failure is caused by missing "#include " in a couple of
files. I would guess that in the past the header was pulled in indirectly.
I fixed this in raspbian, a debdiff should appear soon at
https://debdiffs.raspbian.org/main/n/nomacs
tags 950171 +patch
tags 950171 +fixed-upstream
thanks
exiv2 started a transition and I scheduled binNMUs. However, your
package failed. Please investigate.
Upstream fixed this in commit 1ecee9a47717e36cb8a3925d011d1a6de11d631c
I applied that commit (minus the changes to the upstream changelog
reopen 950172
close 950170 0.2.4-1.1
thanks
Sorry I copy/pasted the wrong bug number into the changelog.
I think this is fixed
byhttps://github.com/seebk/GIMP-Lensfun/commit/ca4511c1a4dd8edabe86e4a943861fda07b7e86c
Feel free to 0day NMU, I don't have much time right now.
I did a test build with that commit added as a quilt patch and it built
successfully, so I went ahead with the 0-day NMU. Debdi
libm4ri is in NEW
I would guess that the maintainer uploaded libm4ri and libm4rie to the new
queue together, but the ftpmasters only released the latter and not the former.
The question I guess is whether it is worth doing a source only upload of
libm4rie now, only to have to get it rebuilt ag
tags 950433 +patch
tags 944055 +patch
thanks
As has been reported linbox is currently blocked from migrating to testing by
build failures on armhf and mipsel autobuilders.
In some armhf environments (notablly on Debian porterboxes and buildds with
arm64 kernels), linbox fails to build with bus
On 01/02/2020 18:04, Ian Jackson wrote:
peter green writes ("Bug#950326: dgit: can't import binutils
2.33.90.20200122-2"):
Package: dgit
Version: 9.9~bpo10+1
When trying to import binutils 2.33.90.20200122-2 I get the following.
['dgit', 'import-dsc'
Package: haproxy
Version: 2.0.12-1
Severity: serious
haproxy build-depends-indep on python-mako, which is no longer built by the
mako source package, it is still present in unstable as a cruft package, but is
completely gone from testing.
Package: linbox
Version: 1.6.3-1
Severity: serious
Since I was looking at the linbox failure on armhf, I figured i'd have a look
at the mipsel one too. Based on past experiences with other packages, I was
expecting it to also be related to alignment issues.
However I was wrong! It seems it is
Package: dgit
Version: 9.9~bpo10+1
When trying to import binutils 2.33.90.20200122-2 I get the following.
['dgit', 'import-dsc',
'/build/workingrepo/pool/main/b/binutils/binutils_2.33.90.20200122-2.dsc',
'..workingbranch']
Dgit metadata in .dsc: NO git hash
using existing binutils_2.33.90.2020
Package: uwsgi-plugin-rados
Version: 2.0.18-7
The ceph maintainer has now managed to get the package building on mipsel
again. Please consider reinstating rbd support on mipsel in your package.
Package: tcmu-runner
Version: 1.5.2-4
The ceph maintainer has now managed to get the package building on mipsel
again. Please consider reinstating rbd support on mipsel in your package.
Severity 949638 normal
Thanks
On 24/01/2020 19:16, Stefan Weil wrote:
As far as I know all Linux distributions use the autoconf based build,
Debian certainly does appear to be using the autoconf based build.
The default autoconf build uses -march=native only if it is supported by
the compiler
Package: dgit
Severity: important
(I tested this with dgit 9.9, but i'm pretty sure the issue has been around for
ages, I even have vauge reccolections of reporting it before, but if I did I
can't find the report).
dget -d http://deb.debian.org/debian/pool/main/g/glibc/glibc_2.29-9.dsc
mkdir d
Package: tesseract
Version: 4.1.0-1
Severity: serious
Tags: patch
I recently discovered that tesseract 4.1.1-1 failed the armv7 contamination
check we run in raspbian.
Investigating shows that since version 4.1.0-1 tesseract started using
-march=native. This compiler option is totally inapprop
Package: src:ceph
Version: 14.2.6-4
Severity: serious
The good news is that the ceph source package now builds on mipsel. YAY
However when checking to see if things were fixed in testing I discovered that
the only binary package that emerged from the ceph 14.2.6-4 build on mipsel,
was python3-
Package: navit
Version: 0.5.4+dfsg.1-1
Severity: serious
x-debbugs-cc: librsvg2-...@packages.debian.org
x-debbugs-cc: pkg-rust-maintain...@alioth-lists.debian.net
Thank you for fixing the navit build with the new libgps.
Unfortunately the new version failed to build on ppc64el,
it seems rsvg is
There's another kind of issue
Yeah, sadly the transition tracker only looks at unstable, so packages that are
fixed in unstable but haven't migrated to testing for some reason won't show up.
; here is an example :
- sagemath builds only for Python 3.7, so some of this subpackages
don't load un
I just took a look at the "add python3.8 transition tracker", and split the remaining
"bad" packages into categories.
Key package, rc bug with patch.
* gpgme1.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944774
Not key package, but not marked for autoremoval from testing
* macs version i
Package: macs
Version: 2.2.6-3
Severity: serious
The new upload of macs to unstable failed to build on most release
architectures (curiously it built successfully on most debian-ports.org
architectures, though it's possible that some of them are building with
nocheck), it failed in several dif
tags 948388 +patch
thanks
yes, your fix is correct, just needs a ckeck if the api
version is >= 9.
Makes sense.
Maybe better would be to add following to navit to
allow building while qtbase5-dev is installed.
Building that way produces equal .deb packages.
Seems very sensible to me, it's no
On 07/01/2020 13:55, andred wrote:
On Tue, Jan 7, 2020 at 9:22 AM Peter Green wrote:
have either of you tested 0.7.0 on a Pi running Debian arm64
Yes, v0.7.0 (from pypi.org) works fine here on Debian arm64.
Thanks.
I have just prepared a package of 0.7.0, I would appreciate people testing
On 14/01/2020 10:24, Michael Tokarev wrote:
Control: severity -1 normal
Control: tag -1 + moreinfo
12.01.2020 18:37, peter green wrote:
Package: qemu-block-extra
Version: 1:4.2-1
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel
package: alfred
version: 2018.2.1
severity: serious
alfred failed to build when binnmu'd for the libgps transition.
alfred-gpsd.c:85:3: error: unknown type name ‘timestamp_t’
85 | timestamp_t now = timestamp();
| ^~~
alfred-gpsd.c:85:21: warning: implicit declaration of f
Package: gr-iqbal
Version: 0.38-3
Severity: serious
Tags: patch
gr-rds FTBFS due to a missing build-dependency on dh-python,
dh clean --with python3
dh: unable to load addon python3: Can't locate
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the
Debian::Debhelper::Sequ
Package: gr-fcdproplus
Version: 3.8~20190817-2
Severity: serious
Tags: patch.
gr-fcdproplus fails to build due to a missing dh-python, I initially noticed
this on a raspbian autobuilder, but it's also happening on the reproducible
builds site, so it's not raspbian specific.
dh: unable to load
Package: gr-rds
Version: 3.8.0.0.f1c584a-2
Severity: serious
Tags: patch
gr-rds FTBFS due to a missing build-dependency on dh-python,
dh clean --with python3
dh: unable to load addon python3: Can't locate
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the
Debian::Debhel
Package: pyside2
Version: 5.13.2-2.2
Severity: important
Tags: patch
Doing a full build (architecture dependent and independent packages) of pyside2
fails on 32-bit architectures (a build that only builds architecture-dependent
packages seems to be fine). I noticed this while working on updatin
Package: pysph
Version: 1.0~b0~20191115.gite3d5e10-1
Severity: serious
The most recent upload got pysph building on amd64 on the autobuilders, but it
still failed for all the other release architectures (it succeeded for some
debian-ports architectures, but some of them may be building with noc
Package: uwsgi-plugin-rados
Version: 2.0.18-6
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on librados-dev and depends on librado
Package: tgt-rbd
Version: 1:1.0.79-2
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on librbd-dev and depends on librados2
and lib
Package: tcmu-runner
Version: 1.5.2-3
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on libradios-dev and librbd-dev and
depends o
Package: qemu-block-extra
Version: 1:4.2-1
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on libradios-dev and librbd-dev and
depe
Package: libvirt-daemon-driver-storage-rbd
Version: 14.2.5-3
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on librbd-dev and depen
Package: fio
Version: 14.2.5-3
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space during
the build. Your package build-depends on librbd-dev and depends on librbd1
which are built
Package: nfs-ganesha-ceph
Version: 2.7.6-3
Severity: serious
The ceph packages on mipsel were removed recently, due to the inability to
build the current version of ceph without running out of address space.
This means it is no longer possible to install the nfs-ganesha-ceph binary
package or
After consulting with upstream (who approved my patch and said they intend to
apply it upstream) I have gone ahead with the NMU. Final debdiff is attached.
diff -Nru freedv-1.4/debian/changelog freedv-1.4/debian/changelog
--- freedv-1.4/debian/changelog 2019-11-18 03:32:07.0 +
+++
It seems it is necessary to cherry pick change 129:03be41933c1b from
upstream.
While that would certainly be a possible route, i'm not sure it makes much
sense, at least for testing/unstable.
I don't have a Pi running Debian bullseye/sid arm64 handy, have either of you
tested 0.7.0 on a Pi run
unblock 938816 by 938407
block 938816 by 947887
thanks
My NMU for routes, eliminating the build-dependency on python-webtest was
accepted and built successfully. This leaves the only reverse dependency of
python-webtest in unstable as the cruft binary package python-pecan. The binary
package p
source: prometheus-process-exporter
version: 0.4.0+ds-1
severity: serious
tags: bullseye, sid, ftbfs
prometheus-process-exporter FTBFS in testing/unstable, I first noticed this on
a raspbian autobuilder, but it's also happening on the reproducible builds
tests, so it's not raspbian specific.
source: prometheus-squid-exporter
version: 1.4+ds-1
severity: serious
tags: bullseye, sid, ftbfs
prometheus-squid-exporter FTBFS in testing/unstable, I first noticed this on a
raspbian autobuilder, but it's also happening on the reproducible builds tests,
so it's not raspbian specific.
github
source: go-dep
version: 0.5.4-2
severity: serious
tags: bullseye, sid, ftbfs
go-dep FTBFS in testing/unstable, I first noticed this on a raspbian
autobuilder, but it's also happening on the reproducible builds tests, so it's
not raspbian specific.
make[1]: Entering directory '/build/1st/go-de
source: packer
version: 1.3.4+dfsg-4
severity: serious
tags: bullseye, sid, ftbfs
packer FTBFS in testing/unstable, I first noticed this on a raspbian
autobuilder, but it's also happening on the reproducible builds tests, so it's
not raspbian specific.
Note: I am aware there is an existing FTB
source: prometheus-varnish-exporter
version: 1.5-1
severity: serious
tags: bullseye, sid, ftbfs
prometheus-varnish-exporter FTBFS in testing/unstable, I first noticed this on
a raspbian autobuilder, but it's also happening on the reproducible builds
tests, so it's not raspbian specific.
githu
source: notary
version: 0.6.1~ds1-4
severity: serious
tags: bullseye, sid, ftbfs
notary FTBFS in testing/unstable, I first noticed this on a raspbian
autobuilder, but it's also happening on the reproducible builds tests, so it's
not raspbian specific.
github.com/theupdateframework/notary/util
source: prometheus-blackbox-exporter
version: 0.13.0+ds-2
severity: serious
tags: bullseye, sid, ftbfs
prometheus-blackbox-exporter FTBFS in testing/unstable, I first noticed this on
a raspbian autobuilder, but it's also happening on the reproducible builds
tests, so it's not raspbian specific.
source: golang-github-mailru-easyjson
version: 0.0~git20161103.0.159cdb8-1.1
severity: serious
tags: bullseye, sid, ftbfs
golang-github-mailru-easyjson FTBFS in testing/unstable, I first noticed this
on a raspbian autobuilder, but it's also happening on the reproducible builds
tests, so it's no
source: ncbi-entrez-direct
version: 10.9.20190219+ds-1
severity: serious
tags: bullseye, sid, ftbfs
ncbi-entrez-direct FTBFS in testing/unstable, I first noticed this on a
raspbian autobuilder, but it's also happening on the reproducible builds tests,
so it's not raspbian specific.
go build -
Source: etcd
Version: 3.2.26+dfsg-4
Severity: serious
Etcd FTBFS in testing/unstable, I first noticed this on a raspbian autobuilder,
but it's also happening on the
reproducible builds service for all architectures, so it's not raspbian specific
The only think I see in the log that looks like a
unblock 937648 by 936731
hi,
I have been working to get rid of cruft packages in testing, python-click is
the main thing holding the python-colorama cruft package in testing.
Looking at the remaining "blockers", rows and nipype are not in testing, so I
think we can disregard them (especially
Since there has been no maintainer response I have gone ahead and NMU'd this.
The debdiff (attatched) is the same as previously other than filling in the bug
number and target suite.
diff -Nru incremental-16.10.1/debian/changelog
incremental-16.10.1/debian/changelog
--- incremental-16.10.1/de
Package: freedv
Version: 1.4-1
Severity: serious
Tags: patch
Freedv 1.4 added support for the 2020 codec. This feature is only enabled if
avx support is detected. Comments in the source code claim that this is because
without avx support it will not be processed fast enough for realtime
opera
Are there any objections to dropping this build-dependency? if not I may NMU
this package.
I have gone ahead and uploaded a NMU to delayed/5 . The debdiff is attached.
diff -Nru routes-2.4.1/debian/changelog routes-2.4.1/debian/changelog
--- routes-2.4.1/debian/changelog 2017-07-20 18:35
tags 937552 +pending
thanks
svn-workbench has now been kicked out of testing, so I have decided to go ahead
with NMUing pysvn. During prep for the NMU I noticed the clean target was
broken, so I fixed that too.
debdiff is attatched, NMU is in delayed/5
diff -Nru pysvn-1.9.9/debian/changelog
reopen 941783
found 941783 1.39.0+dfsg1-4
thanks
I have just tested crossbuilding 1.39.0+dfsg1-4 in bullseye, it still fails in
the same way.
Package: python-incremental
Version: 16.10.1-3
Severity: serious
Tags: bullseye, sid, patch
python-incremental recommends, the incremental source package build-depends on
and the incremental autopkgtests depend on python-click. Python-click in turn
depends on the python-colorama binary package,
severity 937543 serious
thanks
pysph in testing build-depends on python-enthoughtbase, which has been removed
from testing and unstable.
This is fixed in unstable, but the fix is blocked from migrating to testing by
bug 945326
Severity 942907 serious
thanks
actor-framework build-depends on the python-pandocfilters binary package, which
is no longer built by the python-pandocfilters source package. It is still
present in unstable as a cruft package, but is completely gone from testing.
On 23/12/2019 04:15, Ximin Luo wrote:
I've set the severity of this bug to important, because it should not block
migration.
If this were a regression then it would be RC, but since sagemath is already
not in testing, it is not a regression. There is no reason or policy to block
migration bec
Hi
I have been working on trying to get rid of python cruft in testing.
python-webtest is the last remaining package depending on the cruft package
python-waitress. routes is only of only two source packages with
build-dependencies on python-webtest.
I just did a test build and it seems that
I just tried removing the build-dependency on python-autopep8 and other than
file date changes, there did not seem to be any changes in the resulting
packagse, so I decided to go ahead with a NMU.
While preparing the NMU I noticed that the clean target was not cleaning up
properly, so I fixed
severity 936730 serious
thanks
python-impacket depends on python-flask, which depends on the python-click
binary package, which depends on the python-colorama binary package, which is
no longer built by the python-colorama source package.
severity 936522 serious
thanks
python-flask depends on the python-click binary package, which depends on the
python-colorama binary package, which is no longer built by the python-colorama
source package.
severity 937307 serious
thanks
polenum depends on the python-colorama binary package, which is no longer built
by the python-colorama source package.
On 21/12/2019 02:33, peter green wrote:
The pure unstable test is failing to install python-statsmodels, I have no idea
why.
According to ginggs on IRC this is likely due to the arch all build failure in
numpy.
Severity 934870 serious
Thanks
statsmodels in testing build-depends on python-cvxopt, which is no longer
present in testing or unstable.
This is fixed in the unstable statsmodels package (by dropping the python 2
binary package), unfortunately that is failing to migrate due to an autopkgtest
Package: statsmodels
Version: 0.10.2-1
Severity: serious
Statsmodels autopkgtest is failing, both in the unstable to testing migration
tests, and in the pure unstable tests.
The migration test is failing with the following error (
https://ci.debian.net/data/autopkgtest/testing/amd64/s/statsmod
tags 946917 +patch
thanks
I whipped up a patch that makes this build, I have not tested it beyond that.
There were two main fixes, the first is that delete_fluid_synth no longer
returns an error code, the second is a few structures are now opaque and have
to be accessed through accessors.
I a
701 - 800 of 2788 matches
Mail list logo
