i imagemagick 8:6.9.10.23+dfsg-2.1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1
ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1
ii libwmf-bin 0.2.8.4-12
ii python3-lxml 4.5.0-1.1
ii python3-numpy1:1.18.2-2
ii python3-scour0.37-4
Versions of packages inkscape suggests:
pn dia
pn inkscape-tutorials
pn libsvg-perl
pn libxml-xql-perl
pn pstoedit
pn python3-uniconvertor
ii ruby 1:2.7+1
-- no debconf information
--
Peter
machines right now...
Peter
On Sat, May 16, 2020 at 2:22 PM Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> it seems the patch applied does not work for 32bit architectures.
>
> Kind regards
>
> Andreas.
>
The small patch on this pull request ought to solve the immediate Debian
testing issue for biopython:
https://github.com/biopython/biopython/pull/2890
Peter
On Wed, May 6, 2020 at 3:06 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
> Thank you for the additional inform
Source: python-pybedtools
Version: 0.8.0-3
Severity: serious
bedtools is no longer available in testing on armel, armhf or mipsel (or i386
but python-pybedtools never seems to have built there) which makes the
build-dependencies of python-pybedtools unsatisfiable on those architectures.
On 10/05/2020 21:44, Adrian Bunk wrote:
On Sun, May 10, 2020 at 09:29:23PM +0100, peter green wrote:
2. file a bug against ftp.debian.org asking for the removal of
rust-packed-simd on armel/mips64el/mipsel/s390x
That isn't really a workable option. It would just push the problem down
2. file a bug against ftp.debian.org asking for the removal of
rust-packed-simd on armel/mips64el/mipsel/s390x
That isn't really a workable option. It would just push the problem down the
line to other packages. Taken to it's conclusion, solving this through the
removal request route
ild system doesn't like building python3
+only packages.
+
+ -- Peter Michael Green Thu, 30 Apr 2020 21:43:30 +
+
python-funcsigs (1.0.2-4) unstable; urgency=medium
* Team upload.
diff -Nru python-funcsigs-1.0.2/debian/control
python-funcsigs-1.0.2/debian/control
--- python-funcsigs-1.
Thanks for the heads up, logged as:
On Tue, May 5, 2020 at 7:40 PM Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> with the upload of ncbi-blast+ version 2.10 Biopython test is running
> into failures (see
>
>
Thanks for the heads up, logged as:
https://github.com/biopython/biopython/issues/2863
Peter
On Tue, May 5, 2020 at 7:40 PM Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> with the upload of ncbi-blast+ version 2
Package: orthanc-dicomweb
Version: 1.1+dfsg-1
Severity: serious
x-debbugs-cc: node-axios
My self-contained buildability check script detected that armel binaries for
orthanc-dicomweb were present in testing, but the build-dependencies for
orthanc-dicomweb could not be satisified on armel.
upload.
+ * Change build-dependency from obsolete libecore-dev to libefl-all-dev
+(Closes: 950619)
+
+ -- Peter Michael Green Thu, 30 Apr 2020 17:10:39 +
+
dbus-c++ (0.9.0-8.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dbus-c++-0.9.0/debian/control dbus-c++-0.9.0
On 29/04/2020 17:47, Jochen Sprickerhof wrote:
What I found up to now:
- pkg-config=0.29.2-1:
$ pkg-config --cflags-only-I libzmq
-isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.2
- Whereas pkg-config=0.29-6 (or pkgconfig):
$ pkg-config --cflags-only-I libzmq
Package: ignition-transport
Version: 8.0.0+dfsg-3
Severity: serious
It seems that ignition-transport fails to build in testing with the following
error.
CMake Error in src/CMakeLists.txt:
Imported target "ZeroMQ::ZeroMQ" includes non-existent path
"-isystem"
in its
On 21/04/2020 22:20, Thomas Goirand wrote:
So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.
Yes, whichever approach is taken to dealing with funcsigs, unittest2
Source: hypercorn
Version: 0.9.4-1
Severity: serious
hypercorn build-depends on python3-uvloop which is not available in testing due
to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950165 . Either uvloop
needs to be fixed, hypercorn needs to be modified to not build-depend on uvloop
or
On 23/04/2020 17:07, Ximin Luo wrote:
close 958547
thanks
See
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-January/009512.html
Just be patient and wait a few days, the issue usually resolves itself.
I have read that thread and I am aware of the issue that testing
Source: beautifulsoup4
Version: 4.9.0-1
Severity: serious
The autopkgtest for beautifulsoup4 is failing in both plain unstable tests and
testing migration tests, but not in plain testing tests.
ERROR: test_dangling_combinator (bs4.tests.test_tree.TestSoupSelector)
Package: rust-curl-sys
Version: 0.4.30-2
Severity: serious
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-curl-sys/5114465/log.gz
autopkgtest [15:59:42]: test librust-curl-sys+http2-dev:
[---
crate directory not found:
Source: python-cobra
Version: 0.14.2-2
Severity: serious
(this issue affects both 0.14.2-2 from testing and 0.18.0-1 from unstable)
python-cobra's build-dependencies are not satisfiable in testing/unstable on
mipsel, it build-depends on python3-sbml5 and libsbml5 which are built by the
Package: rust-xdg
Version: 2.2.0-2
Severity: serious
rust-xdg's autopkgtest is failing
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/rust-xdg/4759045/log.gz
test_runtime_good stdout
thread 'test_runtime_good' panicked at 'called `Result::unwrap()` on an `Err` value: Os {
On 20/04/2020 08:57, Thomas Goirand wrote:
Option 1: fix all four packages to be python 2 free.
Option 2: Remove python2 stuff from traceback2, python-funcsigs and
numba. Break the dependencies of nipype in sid.
Option 3: Remove python2 stuff from traceback2, modify python-funcsigs
so it still
python-fontforge has been removed from testing, so fonts-ebgaramond (which is a
key package thanks to texlive) can no longer be built in testing.
This bug was tagged as pending over 5 months ago. Is there something blocking
an upload or did it simply get missed?
(using -quiet aliases where multiple involved packages have the same maintainer
listed.
Hi
I have just been running some self-contained buildability tests on bullseye and
these tests indicated that the python-linecache2 and python-traceback2 source
packages have been unbuildable in testing
Tags 955440 +patch
Thanks
The offending code is.
#if defined(__APPLE__) || defined(__SOLARIS__) || defined(__arm__)
// File descriptor passing macros (CMSG_*) seem to be broken
// on 64-bit MacOS X. This structure works around the problem.
The backport of arm64 support to FPC 3.0.x has been found to be somewhat shaky
in the past.
Given that fpc 3.2.x has now reached the release-candidate stage and I would
hope it will be available in time for the bullseye freeze I would suggest we
mark this is flaky for the time being and than
Version: 0.2.68-2
The autopkgtest is now passing.
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-libc/4955258/log.gz
(that is an unstable to testing migration test, but I'd be surprised if the
plain unstable test was different).
@@ -1,3 +1,11 @@
+rust-core-arch (0.1.5-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add feature custom_inner_attributes to src/lib.rs to fix FTBFS
+(Closes: 952228)
+
+ -- Peter Michael Green Sun, 12 Apr 2020 10:03:51 +
+
rust-core-arch (0.1.5-2) unstable; urgency=mediu
https://rustsec.org/advisories/RUSTSEC-2019-0031.html was issued to flag that
rust-spin development stop. I suppose that means it should not enter bullseye
/ get removed.
This bug is currently one of several blockers for getting rust-cbindgen back
into testing and thus making the
--force
The input file is here (plain text with no extension):
https://github.com/biopython/biopython/blob/master/Tests/Fasta/f002
Peter
On Fri, Apr 10, 2020 at 6:29 AM Andreas Tille wrote:
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> the log that is linked to below
Source: rust-unicode-width
Version: 0.1.7-1
Severity: serious
librust-unicode-width+std-dev and librust-unicode-width+rustc-dep-of-std-dev
are not installable as they depend on
librust-rustc-std-workspace-std-1+default-dev which does not seem to exist in
debian.
This is blocking the
notfound 955997 0.22-6-1
found 955997 0.2.66-1
found 955997 0.2.68-1
thanks
The autopkgtest is still failing with rust-libc 0.2.68-1 and rustc 1.42-1
Is it possible to enable/disable (or make non-fatal) autopkgtests on a per-featureset
basis? if so should the test for the "dep-of-std"
Package: rustc
Version: 1.41.1+dfsg1-1
Severity: serious
rustc build-depends-indep on wasi-libc (<= 0.0~git20191220.a280fea++) but
unstable (and soon if not already testing) has version 0.0~git20200114.1fad338-1
Package: mydumper
Version: 0.9.5-1
Severity: serious
(note on versioning, this failure was seen with 1.1 I strongly suspect this
also affects -1, however -1 is currently unbuildable in testing due to a
missing build-dependency. The history on the reproducible builds site shows
failures on
Package: mlpy
Version: 3.5.0+ds-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: iptables-converter
Version: 0.9.8-1.1
Severity: serious
x-debugs-cc: z...@debian.org
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: rust-libc
Version: 0.22-6-1
Severity: serious
rust-libc's autopkgtest failure is failing, this is happening in both the
unstable->testing migration tests and the plain unstable tests and seems to be
a blocker for getting rust-cbindgen back into testing.
[libc 0.2.66] thread 'main'
Package: rust-env-logger
Version: 0.7.1-1
Severity: serious
Tags: patch
The rust-env-logger source package build-depends on and the
librust-env-logger+default-dev and librust-env-logger+humantime-dev binary
packages depend on librust-humantime-1+default-dev which is no longer provided
by
Package: librust-cargo-dev
Version: 0.41.0-2
Severity: serious
Tags: fixed-upstream
librust-cargo-dev depends on librust-humantime-1+default-dev but rust-humantime
in debian is now at version 2.0.0. This seems to have been fixed upstream.
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.
Package: kodi
Version: 2:18.6+dfsg1-1
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
Updating Kodi to 18.6
* What exactly did you do (or not do) that was effective (or
ineffective)?
Removing set up DLNA server
:51.0 +
+++ cracklib2-2.9.6/debian/changelog2020-03-31 04:24:12.0 +
@@ -1,3 +1,11 @@
+cracklib2 (2.9.6-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ [Helmut Grohne]
+ * Fix FTBFS with missing python.mk. (Closes: #951101)
+
+ -- Peter Michael Green Tue
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
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.
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
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)
ngelog 2020-03-07 18:21:22.0 +
+++ alsa-lib-1.2.2/debian/changelog 2020-03-10 15:12:02.0 +
@@ -1,3 +1,10 @@
+alsa-lib (1.2.2-2.1+rpi1) bullseye-staging; urgency=medium
+
+ * Modify python 3.8 patch so builds with 3.7 still work.
+ * Fix clean target.
+
+ -- Peter Michael
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
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.
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
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
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
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.
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
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
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
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
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
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
reopen 950172
close 950170 0.2.4-1.1
thanks
Sorry I copy/pasted the wrong bug number into the changelog.
) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream patch to add a missing #include and hence
+fix build with new exiv2 (Closes: 950172).
+
+ -- Peter Michael Green Wed, 05 Feb 2020 23:52:20 +
+
gimplensfun (0.2.4-1) unstable; urgency=medium
* New upstream release
diff
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
bus errors on
+some arm setups with memcpy calls.
+ * Disable test-rank-md, test-solve-full and test-solve on mips/mipsel,
+they fail to build with an out of memory error from the assembler on
mipsel.
+ * Fix clean target.
+
+ -- Peter Michael Green Sat, 01 Feb 2020 15:52:03 +
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
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
Same for thunderbird, same on different debian unstable machines since
(yesterdays?) upgrade.
(gdb) run
Starting program: /usr/bin/firefox
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x777ff700 (LWP
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
rts commit 424ea9b82f956daa8fa9c0539d0752ccfdc7caf6.
Closes: #949528
Thanks: peter green
(this message was generated automatically)
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
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
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
led.
+(thanks to Bernhard Übelacker for the fix)
+
+ -- Peter Michael Green Sat, 18 Jan 2020 00:37:31 +
+
navit (0.5.3+dfsg.1-2) unstable; urgency=medium
* New patch gpsd-7.patch to support the new gps_read implementation
diff -Nru navit-0.5.3+dfsg.1/debian/patches/gpsd-9.patch
na
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
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
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
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
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
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
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
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
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
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
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
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
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
+++ freedv-1.4/debian/changelog 2020-01-07 10:09:41.0 +
@@ -1,3 +1,10 @@
+freedv (1.4-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Put x86 specific code behind ifdefs (Closes: 947828).
+
+ -- Peter Michael Green Tue, 07 Jan 2020 10:09:41 +
+
freedv (1.4-1
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
.
+
+ -- Peter Michael Green Sat, 04 Jan 2020 11:09:15 +
+
webtest (2.0.32-1) unstable; urgency=medium
[ Ondřej Nový ]
diff -Nru webtest-2.0.32/debian/control webtest-2.0.32/debian/control
--- webtest-2.0.32/debian/control 2018-12-29 21:14:13.0 +
+++ webtest-2.0.32/debian/control
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.
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.
601 - 700 of 3622 matches
Mail list logo
