Package: kmymoney
Version: 5.1.2-1
Severity: serious
While working on completing the kde transition in Raspbian bookworm I ran into
a build
failure of kmymoney.
http://buildd.raspbian.org/status/fetch.php?pkg=kmymoney=armhf=5.1.2-1=1633154962
In file included from
Package: magit-annex
Version: 1.7.1+git20200427.01.ef5dce62-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid
magit-annex build-depends on the dash-el binary package which is no longer
built by the
dash-el source package. It
Package: ht-el
Version: 2.3-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid
ht-el build-depends on the dash-el binary package which is no longer built by
the
dash-el source package. It is still present in unstable as a
Package: epl
Version: 0.9-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
epl build-depends on the dash-el binary package which is no longer built by the
dash-el source package. It is still present in unstable as a cruft package but
is
Package: wine
Version: 5.0.3-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid
wine build-depends on unicode-data (< 14) but testing/unstable has 14.0.0-1,
therefore your
packages build-dependencies are unsatisfiable in
Package: utf8proc
Version: 21.0.0-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid
utf8proc build-depends onunicode-data (< 13.1) but testing/unstable has
14.0.0-1, therefore your
packages build-dependencies are
Package: libxmlada
Version: 21.0.0-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid
libxmlada build-depends onunicode-data (< 14~) but testing/unstable has
14.0.0-1, therefore your
packages build-dependencies are
Hi
I see a fix for this issue has been uploaded to mentors, do you want me to
sponsor it?
It passes when run with only packages from testing.
This is not entirely correct, the version of rust-utf-8 in testing
has no autopkgtests at all. So this is a case of a newly added
(by a newer version of debcargo) test failing, not a case of an
existing test regressing.
Investigating, it
Source: user-mode-linux
Version: 5.10um3
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
Tags: bookworm, sid
user-mode-linux build-depends on linux-source-5.10 which is no longer built by
the linux
source package. It is still present in
package: python-librtmp
version: 20.9.0-2
severity: serious
tags: bookworm, sid
python-librtmp build-depends on python3-cffi-backend-dbg, which has been
dropped by the
python-cffi source package. It is still present in unstable as a cruft package
but is uninstallable due to version constraints.
package: python-gevent
version: 20.9.0-2
severity: serious
tags: bookworm, sid
python-gevent build-depends on python3-cffi-backend-dbg, which has been dropped
by the
python-cffi source package. It is still present in unstable as a cruft package
but is uninstallable due to version constraints.
Tags 993832 +patch
thanks
I found a fix in the upstream git repo and was able to apply it to the Debian
package and build sucessfully in raspbian bookworm-staging. A debdiff is
available at
https://debdiffs.raspbian.org/main/s/synfig/synfig_1.4.0+dfsg-2+rpi1.debdiff
no intent to NMU in Debian.
tags 993698 +patch
thanks
I was able to apply the upstream fix to the Debian hacktv packaging and
build the result successfully in a rasbian bookworm-staging environment,
and I have uploaded the package to Raspbian. A debdiff can be found at
Tags 993699 +patch
thanks
I was able to grab the upstream fix and apply it to the libxtrx package.
I also had to tweak the packaging itself to refer to soapysdr 0.8
instead of 0.7. Note that this involved a package rename, so would
have to go through new if uploaded to Debian.
I have uploaded
Package: golang-github-pkg-sftp
Version: 1.13.2-1
Severity: serious
The autopkgtests for the new version of golang-github-pkg-sftp are failing on
i386 and armhf
(the only 32-bit architectures for which regular tests are currently run). This
is a regression
compared to the version currently in
was
+already using libswresample ( Closes: 971319 ).
+
+ -- Peter Michael Green Thu, 09 Sep 2021 18:11:53 +
+
aubio (0.4.9-4) unstable; urgency=medium
* debian/tests/control: remove py2 tests
diff -Nru aubio-0.4.9/debian/control aubio-0.4.9/debian/control
--- aubio-0.4.9/debian/control 2020-01
+++ e-antic-0.1.8+ds/debian/changelog 2021-09-05 22:14:10.0 +
@@ -1,3 +1,11 @@
+e-antic (0.1.8+ds-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply patches from https://github.com/flatsurf/e-antic/commits/master0
+for flint 2.7 and above.
+
+ -- Peter Michael Gree
Source: sdl-kitchensink
Version: 1.0.9-2
Severity: serious
Tags: bookworm, sid
The ffmpeg package no longer builds libavresample-dev, it is completely gone
from testing and while it is present in unstable as a cruft package, it is
uninstallable there due to dependency versions. So this package's
Source: sdl-kitchensink
Version: 1.0.9-2
Severity: serious
Tags: bookworm, sid
The ffmpeg package no longer builds libavresample-dev, it is completely gone
from testing and while it is present in unstable as a cruft package, it is
uninstallable there due to dependency versions. So this package's
Hello
thanks for your work to get Timeshift working again
After update to 20.11.1-1.1 the problem is now that scheduled backups are not
being completed at all.
There are others finding that this is a problem too.
https://github.com/teejee2008/timeshift/issues/785
thanks
regards
pjnsmb
Sent
Source: shut-up
Version: 0.3.3-1
Severity: serious
Tags: bookworm, sid
shut-up build-depends on the s-el binary package which has been dropped
by the s-el source package. It is still present in unstable as a
cruft package but is completely gone from testing.
Since this package was previously an
Package: node-matrix-js-sdk
Version: 9.3.0+~cs9.9.16-2
Severity: serious
Tags: bookworm, sid
node-matrix-js-sdk build-depends on node-olm, afaict this was previously a
virtual package
provided by libjs-olm but is no longer provided. From reading the changelog it
looks like
the replacement
package: lizzie
version: 0.7.4+dfsg1-2
severity: serious
lizzie build-depends on libjuniversalchardet-java-doc which is no longer built
by the
libjuniversalchardet-java source package. It is still present in unstable as a
cruft
package but is completely gone from testing.
Source: epl
Version: 0.9-3
Severity: serious
Tags: bookworm, sid
epl build-depends on the s-el binary package which has been dropped
by the s-el source package. It is still present in unstable as a
cruft package but is completely gone from testing.
Since this package was previously an empty
Package: debian-parl
Version: 1.9.27
Severity: serious
Tags: bookworm, sid
Debian-parl has a build-dependency on boxer-data (< 10.9) but testing and
unstable
have version 10.9.1
Package: debian-design
Version: 3.0.22
Severity: serious
Debian-design has a build-dependency on boxer-data (< 10.9) but testing and
unstable
have version 10.9.1
Package: rust-thread-local
Version: 1.1.3-2
Severity: serious
Rust-thread-local's autopkgtests are failing and blocking it's migration to
testing.
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-thread-local/14765623/log.gz
Running `CARGO=/usr/bin/cargo
bably debhelper should not move generators to /usr until systemd also
checks that tree for generators. Or I'm missing something else.
Cheers,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org
binary produced by the buildds has the systemd files in
/usr/lib/systemd while my own builds have them in /lib/systemd as
expected. Hm.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' O
On Sat, Jul 03, 2021 at 04:03:07PM +0300, Peter Pentchev wrote:
> Control: tag -1 confirmed upstream patch pending
>
> On Sat, Jul 03, 2021 at 01:39:49PM +0200, xiscu wrote:
> > Package: kakoune
> > Version: 2020.01.16-2
> > Severity: grave
> > Justif
ry already exists and will not attempt
to recreate it. Even after you restart your computer, the problem will
only show up if you run Kakoune through su *before* running it from your
own user account.
...and I will indeed upload a bugfix version in the next couple of days.
Thanks for using
y
Depends: @, python3, python3-ddt, python3-six, tmux
Restrictions: allow-stderr
Features: test-name=upstream
This should be enough to get the donkey package up and building again.
G'luck,
Peter
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (990, 'testi
fixed in two upstream commits:
https://gitlab.com/ppentchev/feature-check/-/commit/ed0da5159562fa37cf32386a1baf2a1114562822
https://gitlab.com/ppentchev/feature-check/-/commit/59e618baff6836f281697561f5a9cfa22ccd28df
The changes in these commits may be applied directly as patches to the
Debian so
Found 932172 17
Thanks
While preparing a stable update for a rust package to fix a FTBFS I discovered
that this
bug also affects buster, meaning that attempts to update rust packages in
buster (e.g. to fix
FTBFS introduced by rustc updates) result in rejections.
The fix applies cleanly to the
During a rebuild of the package, it is seen that the package fails in
one of the tests, commonly on 32 bit systems. So far, I can see it fails
on armhf and i386.
The package is arch all.
While I don't think it's explicitly spelled out anywhere, my understanding
is that it has never been a
On 08/05/2021 17:36, Adrian Bunk wrote:
On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote:
On 04/05/2021 12:28, Santiago Vila wrote:
On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:
This was automatically closed by ftpmaster because the package was
removed from unstable
On 04/05/2021 12:28, Santiago Vila wrote:
On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:
This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.
Unfortunately I don't think a proper fix
This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.
Unfortunately I don't think a proper fix will be forthcoming, upstream
has abandoned the crate in question.
Afaict the only purpose this package
upload.
+ * Apply upstream patch to fix build with newer rustc.
+(Closes: 988025)
+
+ -- Peter Michael Green Tue, 04 May 2021 09:27:11 +
+
rust-rustyline (3.0.0-2) unstable; urgency=medium
* Package rustyline 3.0.0 from crates.io using debcargo 2.2.10
diff -Nru rust-rustyline-3.0.0
go.
I hope this was useful in some way - I thought I'd make things a bit
clearer for people who are not familiar with the tool itself.
If somebody still decides that the "build" tool's default mode of
operation makes it unsuitable for Debian, well, I guess that would be
a valid viewpoint, b
On 12/04/2021 23:54, peter green wrote:
Hi.
The stackvector crate does not appear to be maintained upstream. The upstream
bug underlying this
issue was reported back in February and has received no response from the
upstream maintainer.
Update: the upstream maintainer has now responded
Hi.
The stackvector crate does not appear to be maintained upstream. The upstream
bug underlying this
issue was reported back in February and has received no response from the
upstream maintainer.
It seems the only user of the stackvector crate in Debian is the lexical_core
crate.
The
On 25/03/2021 01:17, peter green wrote:> The second is to fix the autopkgtest. It's currently
"neutral"> due to a dependency on rust-boxxy which is not present in> Debian. From taking a
quick look it looks to me like any> tests that rely on boxxy could probablly be pat
I've prepared a patch that allows additional syscalls on some
architectures and pushed it to a branch in the debcargo-conf repo.
Rust-sniffglue is not a key package, so as I see it you have two
possible ways forward here.
The first is to upload the package as-is and file an unblock
request
Package: rust-libnotcurses-sys
Version: 2.1.8-1
Severity: serious
After spotting a FTBFS on my ddpo page, I also decided to check the ddpo page
for the rust team.
A number of packages were marked as FTBFS, most appeared to be false positives
either resource
exhaustion on the reproducible
(0.1.26-3) UNRELEASED; urgency=medium
+
+ * Apply upstream changes to replace asm with llvm_asm and hence
+fix FTBFS on arm (Closes: ?).
+
+ -- Peter Michael Green Wed, 24 Mar 2021 05:09:17 +
+
rust-compiler-builtins (0.1.26-2) unstable; urgency=medium
* Team upload.
diff -Nru rust
On 07/03/2021 02:30, plugwash-urgent wrote:
my tentative conclusion is that the insert_many
operation in rust-arrayvec does not seem to actually be used.
While I can't find any applications that uses the broken function
in rust-smallvec (saying arrayvec above was a brainfart), I
still think we
2020-09-12 08:10:17.0 +0100
+++ xscorch-0.2.1/debian/changelog 2021-02-18 20:50:52.0 +
@@ -1,3 +1,11 @@
+xscorch (0.2.1-1+nmu6) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove build-dependency on libreadline-gplv2-dev
+(Closes: 982559)
+
+ -- Peter
Package: ehcache
Version: 2.6.11-4
Severity: serious
ehcache build-depends on libgeronimo-jta-1.0.1b-spec-java which is no longer
available in testing. The physical package was removed back in september
but it remained available as a virtual package provided by
libgeronimo-jta-1.1-spec-java
Package: openms
Version: 2.6.0+cleaned1-2
Severity: serious
openms build-depends on seqan-dev which was built by the sequan source
package, which was removed from unstable and testing recently. The person
requesting the removal stated that "There are no other users of seqan 1.x
in Debian." but
2020-08-05 04:00:19.0 +
+++ xscorch-0.2.1/debian/changelog 2021-02-11 21:53:35.0 +
@@ -1,3 +1,10 @@
+xscorch (0.2.1-1+nmu5) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove build-dependency on libreadline-gplv2-dev
+
+ -- Peter Michael Green Thu, 11
Package: kodiplatform
Version: 20180302-1
Severity: serious
kodiplatform build-depends on kodi-addons-dev which is not currently available
on mips64el, mipsel or s390x. However it appears that in the past
kodi-addons-dev
was an arch all package and hence available on these architectures
This test has never passed, it failed back in December 2019, then was
neutral for some time, before returning to failure recently/
Unfortunately debci doesn't keep logs long-term, but I suspect that
the test was neutral due to unsatisfiable test dependencies.
The first error in the log is
Addendum:
The fix is to install nvidia-driver 460.27.04-1
No freezes happened since then:
system boot 5.10.x Fri Jan 8 15:20 still running
Cheers
Seegras
--
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." -- Benjamin Franklin
"It's
tags 977248 +patch
thanks
The issue is a change in opencv4.pc, 4.2 has
includedir_old=${prefix}/include/opencv4/opencv
includedir_new=${prefix}/include/opencv4
But 4.5 has
includedir=${prefix}/include/opencv4
I whipped up a patch for this, soon after doing so I noticed that upstream
had also
Version: 0.3.3-6
Sorry forgot to close this bug in the changelog.
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
Looking at
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rand/9312542/log.gz
It looks like the packed_simd feature test passes with unstable's
version of rust-packed-simd
but the all features test is still failing with
error[E0433]: failed to resolve: use of undeclared crate
On 17/12/2020 10:29, Craig Small wrote:
Hi Peter,
I would, but the problem is the system is terrible.
No disagreement there. Having to do an upload with binaries, then wait for the
ftpmasters to get around to approving it, then come back and make a source
-only upload is a PITA. I didn't
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-s
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
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
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':
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
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
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
> 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
rgency=medium
+
+ * Non-maintainer upload.
+ * Apply upstream patches to fix missing includes (Closes: #957079)
+ * Clean up etc/sysctl/90-ceph-osd.conf in clean target.
+
+ -- Peter Michael Green Sun, 22 Nov 2020 10:56:08 +
+
ceph (14.2.9-1) unstable; urgency=high
* [dc4e7cf] Update upstrea
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 >
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
Package: chromium
Version: 84.0.4147.105-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team
Versions in Debian, even that in experimental have 100+ open unfixed CVE listed
in the tracker.
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
Thanks for your upload. Real life took over again. :-(
Want to take over the package? :-)
Peter
> On Tue, 2020-08-25 at 17:30 -0400, Peter S Galbraith wrote:
>
> > I am on vacation so *should* have time to look into this soonish.
>
> Did you get a chance to look at the libfo
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
on
Monday, however the CI system has not run the tests yet.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
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
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.
401 - 500 of 3615 matches
Mail list logo
