Source: spice-gtk
Version: 0.38-2
Severity: serious
spice-gtk build-depends on gstreamer1.0-doc which is no longer built by the
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely
gone from testing.
Source: python-magcode-core
Version: 1.5.4-2
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.
tags 925781 +patch +pending
tags 967177 +patch +pending
thanks
I have decided to take the Ubuntu fixes for mozjs52 and turn them into a NMU. I
also ran into some issues
with the clean target while preparing the NMU so I fixed those too.
mozjs52 has only one reverse-dependency: cjs which in
The debian python maintainers are trying to phase out python 2.
python 2 has been granted a stay of execution as some important software
requires it to build. However we should still
be attempting to get rid of use at runtime if at all possible. Also the "unversioned
python" packages have been
The libaccounts-glib package does not seem to be getting maintained in Debian,
it has had a rc bug (deprecated declarations
and -Werror) for 8 months with no maintainer response and has recently picked
up a second one (unversioned python removal).
It has not had an upload for 3 years.
Both of
On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote:
On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:
This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
The bootstrap happens with the upstream binaries as we've done in the past.
I have also avoided the bump to LLVM 9/10,
severity 942915 serious
thanks
The "python" binary package is no longer available in testing or unstable (in
unstable it's present as a cruft package
but uninstallable, in testing it's completely gone)
Source: aseba
Version: 1.6.0-5
Severity: serious
Tags: bullseye, sid
aseba build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to strictly
Source: flowcanvas
Version: 0.7.1+dfsg0-0.5
Severity: serious
Tags: bullseye, sid
flowcanvas build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due
severity 942960 serious
thanks
The "python" binary package has now been removed from testing, hence this bug
is now serious.
If there is still no maintainer response I may well NMU this later.
Source: avw.lv2
Version: 0.1.6~dfsg0-1
Severity: serious
Tags: bullseye, sid
avw.lv2 build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to
Source: pdf2djvu
Version: 0.9.17-1
Severity: serious
Tags: ftbfs, fixed-upstream
pdf2djvu's configure script fails to parse the poppler version with the newly
released poppler 20.
This results in a bunch of errors.
This is fixed upstream in version 0.9.17.1
It seems the recent upload of poppler 20 introduced further breakage.
Poppler changed the return type of Catalog::getDestNameTreeDest and
Catalog::getDestsDest
from LinkDest * to std::unique_ptr
If I am following the code correctly, it seems that extractpdfmark had a memory
leak,
previously,
Package: gnome-builder
Version: 3.36.0-3
Severity: serious
Tags: patch
The gnome-builder source package build-depends on libenchant-dev (source
package enchant)
which was recently removed from testing (see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956881 ).
However the gnome-builder
Package: python3-azure-cli
Version: 2.10.1-1
Severity: serious
python3-azure-cli depends on python3-cryptography << 3.0.0 . In unstable this
dependency is unsatisfiable
because python3-cryptography is now at version 3.1-1 .
In testing the dependency is strictly-speaking satisfiable because
:03PM +0100, peter green wrote:
tags 942965 +patch
tags 961839 +pending
The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.targ
tags 942965 +patch
tags 961839 +pending
The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.target=8" to
debian/ant.properties.
If I do
Lucas Nussbaum wrote:
> The following packages have unmet dependencies:
> sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not
installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.
Fixed in git.
Tagging this bug as pending
This
Package: sleef
Version: 3.4.1-4
Severity: serious
The most recent upload of sleef fixed the build on amd64, armhf, i386 and
ppc64el. Unfortunately
it is still failing on arm64, with the following error.
In file included from /<>/src/libm/sleefsimdsp.c:209:
/<>/src/arch/helpersve.h:94:27:
(note: this mail represents my opinions as an ordinary dd, I am not a member of
the release team)
due to the fact that it is supposed to (build-)depend on binutils-avr, which
FTBFS.
As I understand it "(build-)depends" should be interpreted as
"depends or build-depends"
The source package
Tags 957069 +patch
thanks
gcc-10 changed the behaviour around global variables defined in multiple
compilation units. Defined a variable in
multiple compilation units with the default compiler flags will now result in a
link failure.
However in this particular case the variable doesn't appear
Tags 966904 +patch
thanks
The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.
Note that generally only the first include of a header actually does anything
due to the presense of include gaurds.
Therefore if assert.h is included before Magick++.h then everything is
Package: libmagick++-6.q16-dev
Version: 8:6.9.11.24+dfsg-1+b1
This bug is based on testing related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966904
Compiling the following simple test program fails.
#include
#include
int main() {
assert(1==2);
}
g++ `pkg-config --cflags
tags 963290 +patch
thanks
I just took a look at this issue.
First I did some digging in the upstream git repo. Once I figured out their branch
structure (the "master0" branch is
apparently where current releases are made from) I was able to find two
relavent commits.
tags 968637 +patch
thanks
On 26/08/2020 06:04, peter green wrote:
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
I was able to succesfully apply the upstream change to the
Debian package and built it in Raspbian bullseye-staging .
I also bumped the build
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
I have prepared a patch for chromium addressing bugs 965960 and 967124
Bug 965960 (crash on 32-bit) was caused by lack of support in the sandbox for
the 64-bit time syscalls that
have recently been added to Linux/glibc. I added __NR_clock_gettime64,
__NR_clock_nanosleep_time64
and
tags 957816 +patch
thanks
The build failures are caused by a change to default behaviour in gcc-10,
previous versions of gcc defaulted to
-fcommon which allows a variable to be definined in multiple compilation units.
gcc-10 on the other hand defaults
to -fno-common.
There seem to be two
On 13/08/2020 19:53, peter green wrote:
thank you for packaging chromium.
after upgrading libc to 2.31, all available chromium: 80 and 83 are cashing.
the bug has been treated at redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1773289
and has been confirmed by upstream:
https
Package: mailutils
Version: 1:3.9-3.2
Tags: patch
I run a derivative called raspbian and I noticed that mailutils was getting
repeatedly
binnmu'd by our autobinnmuer because the binary packages were not installable.
I don't know what exactly triggered the first binnmu (our autobinnmuer does
Package: diffoscope
Version: 156
Severity: serious
Diffoscope has been removed from testing and cannot re-enter because it
build-depends on
gnumeric, which has been kicked out of testing due to a python2 dependency.
Since this build-dependency only appears to be used for testing I would
On 20/08/2020 06:50, Graham Inggs wrote:
For what it's worth, I tried building fpc including your debdiff and
running the autopkgtests in an Ubuntu PPA.
They passed on amd64,
Thanks for confirming (my local setup is far from the same as the test
infrastructure)
and failed on arm64 [1]
Source: haskell-gi-pango
Version: 1.0.22-1
Severity: serious
Tags: ftbfs
The most recent binnmus of haskell-gi-pango in sid failed with
GI/Pango/Objects/Font.hs:670:9: error:
parse error on input ‘HarfBuzz.FeatureT.feature_t’
|
670 | Ptr HarfBuzz.FeatureT.feature_t -> --
Package: ipe-tools
Severity: serious
Version: 1:7.2.7.2-4
Tags: patch
ipe-tools fails to build with poppler 0.85, there are multiple issues.
I whipped up a patch and uploaded it to raspbian, A debdiff should appear
soon at https://debdiffs.raspbian.org/main/i/ipe-tools
I notice it looks like
Package: popplerkit.framework
Version: 0.0.20051227svn-8
Severity: serious
Tags: bullseye sid patch
popplerkit.framework FTBFS with poppler 0.85 because globalParams is now a
std::unique_ptr
https://github.com/freedesktop/poppler/commit/759d190581f8ff069ecee9155313a8e69a2ca9c6
I have whipped
Package: extractpdfmark
Version: 1.1.0-1
Severity: serious
Tags: patch
extractpdfmark FTBFS with poppler 0.85
destname.cc:85:62: error: no matching function for call to ‘PDFDoc::findPage(int&,
int&)’
85 | pagenum = doc->findPage (page_ref.num, page_ref.gen);
Doing a bit of
On 11/08/2020 16:27, peter green wrote:
Package: fpc
Version: 3.2.0+dfsg-5
Severity: serious
The autopkgtest for fpc 3.2.0 is failing
Compiling utests.pp
PPU Loading
/usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.ppu
PPU Source: custapp.pp not available
Recompiling
thank you for packaging chromium.
after upgrading libc to 2.31, all available chromium: 80 and 83 are cashing.
the bug has been treated at redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1773289
and has been confirmed by upstream:
It has been said in the past by the release team that the current autobuilder
behaviour of only considering the first
option for a build-dependency is by design to improve the determinism of the
autobuilding process. I don't think you
will persuade them to change it.
The proper fix IMO would
Package: fpc
Version: 3.2.0+dfsg-5
Severity: serious
The autopkgtest for fpc 3.2.0 is failing
Compiling utests.pp
PPU Loading
/usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.ppu
PPU Source: custapp.pp not available
Recompiling CustApp, checksum changed for
On 11/08/2020 13:06, Graham Inggs wrote:
I've had a quick look at ddrescue [1], but I don't know how to fix
that. Does anyone have any suggestions?
Googling the error message took me to
https://wiki.freepascal.org/User_Changes_Trunk
which has an entry "Property field access lists no longer
On 11/08/2020 13:06, Graham Inggs wrote:
I've also looked at mricron [2][3], and changing '(**)' to '*)' in
both places fixes the compilation, but I have no idea what the '(**)'
means. Can anyone tell me?
(* and *) are comment delimeters
Borland style pascal traditionally handled comments
+#MISSING: 2.6+2.0.8+dfsg-1#
_ZN7QVectorI6QPointE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base
2.6~alpha
c++filt -n decodes this to
QVector::reallocData(int, int, QFlags)
This looks like an instantiation of a QT template that may or may not be
included in the library as a
notfound 967991 2.35-1
found 967991 2.32-1
close 967991 2.35-1
thanks
On 06/08/2020 13:20, Clint Adams wrote:
On Thu, Aug 06, 2020 at 11:20:00AM +0100, peter green wrote:
glirc can no longer be built in testing because haskell-regex-tdfa is no longer
present in testing. Ilias Tsitsimpis has
Ilias Tsitsimpis wrote:
We should make sure that anyone using this package has migrated to
skylighting and then remove it.
hi, highlighting-kate was just removed from testing at your request, but
carettah still build-depends on it in both testing and
unstable.
Should I go ahead and file a rc
Package: glirc
Version: 2.35-1
Severity: serious
Justification: rc policy: "packages must be buildable within the same release"
glirc can no longer be built in testing because haskell-regex-tdfa is no longer
present in testing. Ilias Tsitsimpis has filed a bug report against the package
saying
severity 942965 serious
thanks
closure-compiler build-depends on python-docutils which has now been removed
from testing.
severity 937009 serious
thanks
mercurial can no longer be built in testing because of a build-dependency on
python-docutils which has been removed.
This is fixed in unstable, but mercurial is blocked from migrating to testing
because it
declares a conflicts on mercurial-crecord (<=
On 27/07/2020 16:31, s...@debian.org wrote:
On Thu, 23 Jul 2020 at 18:01:55 +0100, peter green wrote:
dbus-python in testing build-depends on python-gi
which is no longer available in testing. This is fixed in
unstable but the fix is blocked from migrating to testing by
https://bugs.debian.org
Package: x264
Version: 2:0.159.2999+git296494a-2
Severity: serious
Tags: patch
Make 4.3 changed the escaping rules with the # symbol is used inside a
parameter to functions like $shell.
Previously it needed to be escaped, now it needs to *not* be escaped. A change
was applied to the debian
severity 936371 serious
thanks
dbus-python in testing build-depends on python-gi which is no longer available
in testing. This is fixed in
unstable but the fix is blocked from migrating to testing by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965308
notfixed 965298 1.16.2-2.2
tags 965298 +patch
tags 957314 +patch
thanks
gst-plugins-bad1.0 1.16.2-2.2 fails to build in both testing or unstable for
different reasons.
In unstable it fails to build because gcc-10 got stricter about multiple
definitions of global
variables. Upstream already
Last blockers for removal:
1. node-yarnpkg - #960120 - should be patched/fixed for 1.x or switch
to 'berry'/2.x (supports babel 7) in time for bullseye
2. libjs-webrtc-adapte - #959798 - browserify-lite can be replaced by
webpack
3. rainloop - #960021 - not in bullseye
Once the blockers are
I just went through the remaining items on the transition tracker for this
transition
filing bug reports where appropriate.
freewheeling:
sid-only, unrelated FTBFS bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946863
haskell-hopenpgp/haskell-hopenpgp-tools:
haskell-incremental-parser
Package: opendht
Version: 0.6.6-1
Severity: serious
x-debbugs-cc: msgpac...@packages.debian.org
tags: ftbfs
opendht cannot currently be built in unstable, there are two issues.
Firstly, the build can't even be attempted on armel or mipsel because
the build-dependencies are unsatisfiable. The
Package: ocamlnet
Version: 4.1.6-1
Severity: serious
Tags: FTBFS
When binnmu'd for the nettle transition ocamlnet failed to build on most
architectures
(it succeeded on mipsel, mips64el and armel) with the following error.
make[1]: Leaving directory '/<>'
dh_dwz -a
dwz:
Package: haskell-incremental-parser
Version: 0.4.0.2-1
Severity: serious
haskell-incremental-parser 0.4.0.2-1 added a build-dependency on
libghc-rank2classes-dev (>= 1.0)
however this package is only available on four out of the ten release
archictures.
Potential ways forward:
1. fix
Package: gst-plugins-bad1.0
Version: 1.16.2-2.1
Severity: serious
x-debbugs-cc: sramac...@debian.org, locutusofb...@debian.org
Neither version 1.16.2-2.1 (from bullseye) or version 1.16.2-2.2 (from sid) can
be built in testing.
1.16.2-2.1 cannot be built because libsrt-dev has been removed.
On 17/07/2020 08:42, peter green wrote:
On 17/07/2020 06:40, Sebastian Ramacher wrote:
Hi
On 2020-07-17 00:02:17 +0100, peter green wrote:
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2.
While
On 17/07/2020 06:40, Sebastian Ramacher wrote:
Hi
On 2020-07-17 00:02:17 +0100, peter green wrote:
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2.
While I have not tested, I am 99% sure your
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2.
While I have not tested, I am 99% sure your fix for make 4.3 will break the
build with make 4.2 in testing.
Since I wrote the post in response to
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for gst-plugins-bad1.0 (versioned as 1.16.2-2.2) and
uploaded it to DELAYED/2.
Hi, I tried adding your proposed NMU to raspbian as part of trying to get the
x265 transition to go through there.
Unfortunately it
Both the django-mailman3 and the hyperkitty build failures look like the same
issue
, my looking however was focused on the hyperkitty failure as that is the one I
became
aware of first.
First I looked at test history for hyperkitty on reproducible builds and
looking at when relavent
packages
Package: hypercorn
Version: 0.9.4-1
Severity: serious
Tags: patch
Justification: rc policy "packages must be buildable within the same release"
hypercorn build-depends on python3-asynctest, which is built from the
python-asynctest source
package.
According to bug 954554 python3-asynctest is
Package: oca-core
Version: 11.0.20191007-3
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.
severity 962877 serious
close 962877 11.0.20191007-3
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
The dependency is gone in unstable, but the fix is currently blocked from
migrating to testing.
A seperate bug report about that will follow.
severity 962886 serious
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
severity 962879 serious
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
severity 962878 serious
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
severity 962876 serious
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
severity 962880 serious
thanks
fonts-glewlwyd has now been dropped by the glewlwyd source package.
Retitle 964136 glewlwyd build-depedencies unsatisfiable on armel
Thanks
Build has been fixed for mipsel and mips64el
Thanks, retitling the bug report for the remaining issue.
but it remains impossible
on armel since nodejs isn't available on this platform.
The thing is nodejs is used
Package: glewlywd
Version: 2.3.1-2
Severity: serious
The new glewlywd package cannot be built on armel, mipsel or mips64el due to
unsatisfiable
build-dependencies. Specifically nodejs/npm on armel and librhonabwy-dev on
mipsel/mips64el
Generally there are three possible ways forward with this
> I am looking for a sponsor for my package "xscorch"
The main patch looks good, a couple of things needs to be addressed before I
will sponsor it.
Firstly you need to send a mail with the debdiff attached stating your intent
to NMU to the bug
report and giving the maintainer and
I cannot build debcargo currently. It fails with:
missing:
pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
unsat-dependency: librust-cargo-0.43+default-dev:amd64
Thanks
Sylvestre
The root cause (or at least one of the
severity 937442 serious
thanks
The cython binary package has been removed from testing. So pygame-sdl2 can no
longer be built in testing
Package: booth.
Version: 1.0-174-gce9f821-2
Severity: serious
Booth build-depends on libcrmservice-dev which is no longer built by the
pacemaker source package.
It is still present in unstable as a cruft package but is completely gone from
testing.
Since libcrmservice-dev was a transitional
Putting the Debian bug back in cc, for earlier mails please see
https://marc.info/?l=linux-xfs=159253950420613=2
Eric Sandeen wrote:
How does debian fix this for xfsprogs? Doesn't the same issue exist?
I'm not seeing any cases like xfsdump where a binary is located in /sbin but
symlinked
Putting the debian bug back in cc, previous mails are visible at
https://marc.info/?l=linux-xfs=159253950420613=2
On 19/06/2020 23:43, Dave Chinner wrote:
Isn't the configure script supposed to handle install locations?
Both xfsprogs and xfsdump have this in their include/builddefs.in:
This bug has now caused xfsdump to be kicked out of testing which is making
amanda unbuildable in testing.
Yes, what's really needed here is for a change to be merged upstream
(as all other deb packaging artifacts are) otherwise this will keep
getting lost in time.
To make it easier to
Package: qbittorrent
Version: 4.1.7-1
Severity: serious
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/qbittorrent.html
./../src/base/bittorrent/infohash.cpp: In constructor
'BitTorrent::InfoHash::InfoHash(const sha1_hash&)':
../../src/base/bittorrent/infohash.cpp:44:43:
I have now gone ahead with the NMU, the final debdiff is attatched (same as
previous debdiff apart from changelog tweaks)
diff -Nru vanguards-0.3.1/debian/changelog vanguards-0.3.1/debian/changelog
--- vanguards-0.3.1/debian/changelog2019-07-26 16:30:09.0 +
+++
Package: apper
Version: 1.0.0-2
Severity: serious
Tags: bullseye, sid, patch
http://buildd.raspbian.org/status/fetch.php?pkg=apper=armhf=1.0.0-2%2Bb4=1591727741
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apper.html
CMake Error at
Yes, that. I look regularly at
https://qa.debian.org/dose/debcheck/src_testing_main/ as we (the release
team) require packages to be buildable in testing (we have some
tolerance as the migration of build dependencies isn't guaranteed when
checking if a package may migrate). Please help the rust
Tags 959439 +patch
thanks
I was able to apply the upstream fixes to the Debian supercollider packaging,
in order to do so I had to make some formatting adjustments to the code(it
seems upstream reformatted their codebase since the version that is in Debian)
I did builds in Debian sid and
Some googling lead me to
https://svnweb.freebsd.org/ports/head/multimedia/mkvtoolnix/files/patch-boost-1.69?view=markup=482787
which suggests it is now necessary to manually convert from tribool to bool by
writing bool{value}
Unfortunately after doing that I get
In file included from
Package: pglogical
Version: 2.3.1-1
Severity: serious
Tags: ftbfs
It seems pglogical recently started failing to build.
http://buildd.raspbian.org/status/fetch.php?pkg=pglogical=armhf=2.3.1-1%2Bb1=1591473342
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pglogical.html
I downloaded the build logs and filtered them to show the missing symbols that
were not already marked as optional.
plugwash@thinkpad:~$ wget -O zimlib.log
'https://buildd.debian.org/status/fetch.php?pkg=zimlib=amd64=4.0.4-5%2Bb1=1591384179=0'
plugwash@thinkpad:~$ html2text -width 10
tags 961986 +patch
thanks
Some googling of the error message led me via a few links to an upstream patch
at
https://github.com/Abscissa/SDLang-D/pull/70/commits/90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
I extracted the commit as a patch, tweaked the paths so it would apply to the
Debian lix
On 04/06/2020 23:12, Thomas Goirand wrote:
On 6/4/20 10:33 PM, peter green wrote:
A few days ago Sandro Tosi uploaded the python-unittest2 and
python-funcsigs source packages. It seems that both of these were
effectively "team uploads" though they were not marked as such.
A few years
A few days ago Sandro Tosi uploaded the python-unittest2 and python-funcsigs source
packages. It seems that both of these were effectively "team uploads" though
they were not marked as such. The python-unittest2 upload dropped python 2 support while
the python-funcsigs package dropped python 2
Package: vanguards
Version: 0.3.1-2
Severity: serious
vanguards build-depends on pypy-pytest which depends on pypy-funcsigs which is
no longer built by the python-funcsigs source package. The pytest maintainer
has also said they would like to get rid of pypy support from pytest. Afaict
Source: libdr-tarantool-perl
Version: 0.45-2
Severity: serious
Tags: bullseye, sid
libdr-tarantool-perl build-depends on
tarantool-lts | tarantool (<< 1.6)
tarantool-lts has been removed from Debian and tarantool is now at version
1.9.1.26.g63eb81e3c-1.1
Package: picard-tools
Version: 2.18.25+dfsg-3
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 aufs package last saw a maintainer upload in September 2019 and was
last-updated (by a NMU) in October 2019. It has had broken build-dependencies
in testing for half a year now (since Linux 5.3.9-3 migrated to testing in
November 2019).
According to dak rm the aufs source-package has two
Source: user-mode-linux
Version: 5.5um1
Severity: serious
user-mode-linux build-depends on linux-source-5.5 which is no longer available
in testing.
Package: clang-9
Version: 9.0.1-12
using test.cpp consisting of the single line "#include " and on a system
with libgcc-10-dev installed but not libstdc++-10-dev I get the following failure:
root@thinkpad:/# clang++ -v -c test.cpp
clang version 9.0.1-12
Target: x86_64-pc-linux-gnu
Thread
Source: python-cobra
Version: 0.18.0-1
Severity: serious
Three of the last four builds of python-cobra on s390x have failed with.
=== FAILURES ===
___ test_model_summary_to_frame_with_fva[optlang-glpk-0.95]
Hi, I just had a raspbian user run into this bug.
https://www.raspberrypi.org/forums/viewtopic.php?f=66=274484
I notice that this bug report was tagged as pending 6-months ago. Is there some
blocker for uploading it?
I also wonder if a stable update should be considered for this since this is
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.
501 - 600 of 2728 matches
Mail list logo
