librust-cfg-if-0.1+default-dev (>= 0.1.9-~~) ,
(And a matching, hard-coded Depends line on the binary package)
However, this version of rust-cfg-if is now gone and replaced by 1.0
A new source package "rust-cfg-if-0.1" has been introduced which builds
the binary package librust-cfg-if-0.1-dev
ely because of these rules, no
other reason.
- Craig
On Wed, 16 Dec 2020 at 10:21, peter green mailto:plugw...@p10link.net>> wrote:
Package: wordpress
Version: 5.5.3+dfsg1-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer
migrate
On 16/12/2020 21:48, Thorsten Alteholz wrote:
Hi Peter,
are you sure about your bug report?
The control file of osmo-bsc/1.6.1+dfsg1-3 contains:
Build-Depends: debhelper-compat (= 12),
pkg-config,
libosmocore-dev (>= 1.4.0),
libosmo-sccp-dev
Package: wordpress
Version: 5.5.3+dfsg1-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.
Source: osmo-bsc
Version: 1.6.1+dfsg1-3
Severity: serious
Tags: ftbfs
osmo-bsc build-depends on libosmo-legacy-mgcp-dev, which has been dropped by
the osmo-mgw
source package. It is still present in unstable as a cruft package, but is
completely
gone from testing, meaning it is no longer possib
Package: golang-github-containers-buildah
Version: 1.16.6+dfsg1-1
Severity: serious
golang-github-containers-buildah fails to build with the latest version of
golang-github-containers-image-dev.
I initially saw this in raspbian, but it's also happening on the reproducible
builds test infrastruc
package: ruby-licensee
Version: 8.9.2-1
Severity: serious
Tags: bullseye, sid
The autopkgtest for ruby-licensee is failing with ruby-rugged 1.1.0.
GEM_PATH= ruby2.7 -e gem\ \"licensee\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1398:in `rescue in block in
activate_dependencies': Coul
package: ruby-gollum-rugged-apapter
Version: 0.4.4.2-2
Severity: serious
The autopkgtest for ruby-gollum-rugged-adapter is failing with ruby-rugged
1.1.0.
┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
Package: debcargo
Version: 2.4.3-2+bw
Severity: grave
After the recent binnmu of debcargo. debcargo update
(after deleting the cache) gives.
Updating crates.io index
Something failed: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
invalid version 0 on git_pr
On 05/12/2020 20:26, Andreas Tille wrote:
Control: tags -1 help
Hi,
I need to admit that I have no idea why this error occures on arm64.
According to reproducible builds, it's also happening on i386 and armhf,
it's showing a pass for amd64 but that could just be because it hasn't
been tested
severity 976572 normal
thanks
During a rebuild of all packages in sid, your package failed to build
on arm64 (I don't know if it also fails on amd64).
It's cool that you have expanded your rebuild tests to include arm64, but it
seems
your test workflow needs some work. arm64 is not on the arc
Package: rust-sha2
Version: 0.9.2-1
Severity: serious
The new version of rust-sha2 picked up a build-dependency on rust-cpuid-bool,
unfortunately that package is only available on i386 and amd64. Either the
dependency needs to become arch-specific (not sure if cargo/debcargo can support
that thou
> This will impact quite some other modules.
I agree that the current autoremoval list looks pretty scary, so I decided to
do some
dependency analysis. It seems there are 5 source packages with direct or
indirect hard
dependencies on rust-js-sys.
rust-www-sys
rust-ring
rust-rustls
rust-sct
rus
merge 972908 957079
tags 972908 +patch
tags 972908 +fixed-upstream
thanks
Matthias Klose wrote in bug 957079:
The full build log can be found at:
http://people.debian.org/~doko/logs/gcc10-20200225/ceph_14.2.7-1_unstable_gcc10.log
The last lines of the build log are at the end of this report.
U
Package: fprint-demo
Version: 20080303git-7
Severity: serious
fprint-demo build-depends on libfprint-dev and depends on libfprint0 which are
no longer built by the libfprint
source package.
(I know that there is a removal request filed with the ftpmasters, but there
still needs to be a rc bug
Package: pam-python
Version: 1.0.9-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.
Source: pam-python
Version: 1.0.8-1
Severity: serious
The autopkgtest for pam-python is broken, it tries to install a binary package
that does not exist.
Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on python-pam:amd64 < none @un H >
Re
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 spotted
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 D
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 bina
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 a
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:
`/tmp/tmp.p7bE9eMN2s/target/armv7-unkn
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 when
testin
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 -
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 ===
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.
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 packages
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
autopk
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 libcurl4-gnutls
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 libcurl4-gn
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 turn
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 t
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 versione
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 to
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 strictl
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, g
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 b
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 test
: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 not
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 bu
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: error
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 f
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.
10ed02f429f75a418ee41814af
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 __NR_utimens
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 seper
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 suggest
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] and
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 -> -- featu
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 at
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 up
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 pokin
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
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
/tmp/autopkg
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 al
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 in
+#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 s
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 b
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 he
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 x264
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 has
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
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 rea
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: debian/libocamlnet-o
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 haskell-
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.
1.
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.
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
(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 y
(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 lo
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 inc
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.
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 during
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
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 pa
Putting the Debian bug back in cc, for earlier mails please see
https://marc.info/?l=linux-xfs&m=159253950420613&w=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
symlink
Putting the debian bug back in cc, previous mails are visible at
https://marc.info/?l=linux-xfs&m=159253950420613&w=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:
PK
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 upstre
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: er
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 +
+++ vanguards-0.3.1/de
Package: apper
Version: 1.0.0-2
Severity: serious
Tags: bullseye, sid, patch
http://buildd.raspbian.org/status/fetch.php?pkg=apper&arch=armhf&ver=1.0.0-2%2Bb4&stamp=1591727741
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apper.html
CMake Error at /usr/share/cmake-3.16/Mod
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 m
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 Raspb
301 - 400 of 1842 matches
Mail list logo
