On 11/11/2020 15:42, Norbert Preining wrote:
Hi Peter,
again, thanks a lot
I did some digging and was able to find an upstream commit fixing this issue.
https://github.com/JuliaLang/julia/commit/master?diff=unified_path=30dfa74
Are you sure this is the correct commit? This does some
retitle 928131 julia: FTBFS on armhf
thanks
Since version 1.4.0+dfsg-1 once again builds on arm64. On the other hand on
armhf is still failing.
/<>/src/debuginfo.cpp: In member function ‘virtual void
JuliaJITEventListener::_NotifyObjectEmitted(const llvm::object::ObjectFile&, const
reassign 973298 rust-failure
retitle 973298 rust-failure: Should rust-failure be removed from unstable?
thanks
As there was no objection (although admittely 2 weeks might be short),
but the upstream is officially end-of-life. So just reassigned the
bug to ftp.d.o for removal.
I've just
With a recent update, it broke bat:
The error is:
missing:
pkg:
package: librust-syntect+parsing-dev
version: 3.3.0-3
architecture: amd64
unsat-dependency: librust-onig-5+default-dev:amd64
depchains:
-
depchain:
-
package:
On 05/11/2020 17:32, peter green wrote:
I have whipped up a patch which changes the dependency generation in sdpa and
bumps the
build-dependency (so the new depedency generation won't be used with old mumps
packages).
I have built it and uploaded it to raspbian, no intent to NMU in Debian
source: sdpa
Version: 7.3.14+dfsg-1
Severity: serious
sdpa was recently rebuilt for the mumps transition, unfortunately the resulting
binary packages
depend on libmumps-seq-5.3.5 which does not exist. The package is now named
libmumps-seq-5.3.
It appears the versioning scheme for the mumps
severity 972478 serious
thanks
sorry forgot the severity when filing this bug.
Firstly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972432 needs to be
actioned by the ftpmasters.
This has been done, however checking the britney logs afterwards has revealed
another issue, for which
I
Package: cantor-backend-scilab
Version: 4:20.04.3-1
Severity: serious
As a result of swt dropping support for 32-bit targets, libjogl2-java can no
longer be built on i386 and armhf and the
existing binaries have been removed in unstable. This in turn has lead to the
removal of scilab on those
Package: rust-onig
Version: 5.0.0-3
Severity: serious
The autopkgtest for rust-onig fails with memory errors on i386 and armhf.
https://ci.debian.net/data/autopkgtest/testing/armhf/r/rust-onig/7843624/log.gz
Caused by:
process didn't exit successfully:
Severity 973387 normal
Retitle 973387 rust-bindgen cannot be built with "static" feature.
On 29/10/2020 19:44, Sylvestre Ledru wrote:
Hello,
Le 29/10/2020 à 20:39, peter green a écrit :
I was looking at an autopkgtest failure in rust-bindgen. The failure happened when whe
I was looking at an autopkgtest failure in rust-bindgen. The failure happened when when
testing with the "static"
feature. It appears the failure was caused by a lack of libclang.a
When looking at the file list of libclang-9-dev I noticed that there was no
libclang.a but there were a number of
Package: rust-bindgen
Version: 0.55.1-1
Severity: serious
rust-bindgen 0.55.1 introduced two new featuresets. The autopkgtests for these
featuresets are failing
For the "runtime" feature we have.
> test::commandline_multiple_headers stdout
> bindgen tests/headers/16-byte-alignment.h
do actually already do work in dpkg. You represent them as:
Build-Depends:
librust-foo-dev (>= 0.4),
librust-foo-dev (<< 0.6)
><--snip->
> Provides: librust-foo-dev = 0.4.2-1
>
> then the conjunctive, versioned Depends would be able to figure out how
> to satisfy it.
The problem is
Package: celery
Version: 4.4.6-1
Severity: serious
The autopkgtest for celery 4.4.6-1 is failing with the new python3-defaults.
https://ci.debian.net/data/autopkgtest/testing/amd64/c/celery/7741503/log.gz
=== FAILURES ===
severity 948105 serious
thanks
In #917104 uhttpmock has been filed for removal, but libgdata still
uses it.
uhttpmock has now been removed from testing/unstable, so libgdata's
build-dependencies are no longer satisfiable.
Package: rust-lldb
Version: 1.41.1+dfsg1-1~deb10u1
Severity: serious
rust-lldb in buster now depends on python3-lldb-7, however it does not appear
that this package has ever existed in Debian.
Tags 972478 -sid
thanks
On 19/10/2020 04:15, peter green wrote:
Package: libjogl2-java
Version: 2.3.2+dfsg-9
Tags: bullseye, sid
x-debbugs-cc: sci...@packages.debian.org
x-debbugs-cc: k...@packages.debian.org
Justification: rc policy: packages must be buildable in the same release.
libjogl2
Package: libjogl2-java
Version: 2.3.2+dfsg-9
Tags: bullseye, sid
x-debbugs-cc: sci...@packages.debian.org
x-debbugs-cc: k...@packages.debian.org
Justification: rc policy: packages must be buildable in the same release.
libjogl2-java can no longer be built on 32-bit architectures, specifically
Package: geoalchemy2
Version: 0.7.0-1
Severity: serious
geoalchemy2 build-depends on postgresql-12-postgis-3 and
postgresql-12-postgis-3-scripts,
which have been replaced by postgresql-13-postgis-3
postgresql-13-postgis-3-scripts, the
old packages are still present in unstable as cruft
I just looked at this issue.
rust-ncurses is a thin wrapper around ncurses. It exposes unsafe (in the rust
sense) C
APIs to safe rust code. The rust security team consider this to be a
vulnerability.
There is more discussion of this issue at
https://github.com/jeaye/ncurses-rs/issues/188
the
Package: libtickit-perl
Version: 0.71-1
Severity: serious
The libtickit-perl autopkgtest is failing on the unstable->testing migration
tests (the plain unstable tests are not
up to date enough to be useful). On i386 and amd64 this failure is a regression
(on the other architectures where
Package: vt
Version: 0.57721+ds-2
Severity: serious
Justification: rc policy: packages must be buildable within the same release.
vt build-depends on libcurl4-openssl-dev and libhts-dev. Libhts-dev recently
added a dependency on libcurl4-gnutls-dev.
Since libcurl4-openssl-dev and
Package: augustus
Version: 3.3.3+dfsg-3
Severity: serious
Justification: rc policy: packages must be buildable within the same release.
Augustus build-depends on libcurl4-nss-dev and libhts-dev. Libhts-dev recently
added a dependency on libcurl4-gnutls-dev.
Since libcurl4-nss-dev and
reopen 912941
thanks
On 24/09/2020 06:25, Andreas Metzler wrote:
On 2020-08-28 peter green wrote:
Tags 966904 +patch
thanks
The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.
[...]
I would argue that is a bug in imagemagick and have filed bugs in both Debian
and upstream as
https
Source: rhythmbox
Version: 3.4.4-2
Severity: serious
rhythmbox 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: farstream-0.2
Version: 0.2.8-5
Severity: serious
farstream-0.2 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: clutter-gst-3.0
Version: 3.0.27-1
Severity: serious
clutter-gst-3.0 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: 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
501 - 600 of 2756 matches
Mail list logo
