Package: btlib
Version: 1.7.5+dfsg-2
According to tracker.debian.org the new version of btlib is
causing an autopkgtest regression in nthash, this is
preventing the new versions of btlib from migrating to
testing.
The new version of btlib is needed to fix a build-dependency
uninstallability issu
Package: python-cryptography
Version: 43.0.0-2
Severity: serious
Tags: patch, ftbfs
python-cryptography cannot be built in sid (and soon trixie) due to
an overly strict Debian build-dependency for the cc crate (the
upstream cargo dependency is fine).
A debdiff fixing this is attached.diff -Nru p
If preferred, a variant of the proposed changes with a default of "no" would
also be possible
I think the default (for bin packages) should be not to generate a multi-arch:
field at all.
This is behaviorally equivalent to multi-arch: no, but it IMO has different
implications, it implies "noone
Package: storm
Version: 1.0-1
Severity: serious
storm has binaries on 32-bit architectures (i386, armel, and armhf),
however it's build-dependencies cannot be satisified there
package: storm
version: 1.0-1
architecture: any
type: src
status: broken
reasons:
-
missing:
pk
The debdiff patch
is in the attachment.I have tested that locally,and it works well.Please
let me know whether this solution can be accepted.
You seem to have totally ignored the existing built-using.patch and added
a new patch, furthermore your new patch hardcodes the version number of
ring, so
On 15/04/2025 16:07, Jing Luo wrote:
X-Debbugs-Cc: debian-am...@lists.debian.org, debian-...@lists.debian.org,
debian-powe...@lists.debian.org, debian-ri...@lists.debian.org
I understand CC'ing the porters when you have an issue that is specific to the
port, but
if it's failing on every damn
Tags 1068418 +wontfix
After a bunch of back and forth the upstream maintainer of this crate has
stated.
The goal of this crate is to implement direct, memory safe bindings to OpenSSL
APIs. Some of those APIs are poorly designed, but that is frankly OpenSSL's
problem, not my problem.
Package: rust-pprof
Version: 0.13.0-5
Severity: serious
X-debbugs-cc: alexander.kj...@gmail.com
A soundness issue was reported in rust-prost 0.13,
https://rustsec.org/advisories/RUSTSEC-2024-0408.html
which is reported as causing real-world failures in
downstream applications.
I looked at updati
Package: pydantic
Version: 2.10.6-1
Severity: serious
After the update of pydantic-core to build against the new rust-url,
pydantic's autopkgtests are failing.
https://ci.debian.net/packages/p/pydantic/testing/amd64/59623497/
63s E Differing items:
63s E {'msg': 'Input should
On 19/03/2025 11:03, Adrian Bunk wrote:
It's easy to reproduce even with the binary package when you remove
openssl (see #1099669).
I've now reproduced the bug.
It seems the package will build successfully as long as /etc/ssl/certs
exits, but will fail if that directory does not exist. Install
Is there something I can improve on this front? In other words, how can
the design become smarter?
It's hard to answer this because I don't really understand exactly
how the scheduler works, but what I frequently see is.
1. The set of pins that britney chooses don't work.
2. The fallback depend
> ∙ ∙ Built-Using: rust-rebuildctl rust-rustls-native-certs (not considered)
rust-rustls-pemfile and friends have been trying to migrate to testing for
nearly a month, but a combination of a few real issues, a number of
well-intentioned
but poorly timed uploads, britney's autopkgtest scheduler b
Package: rust-skeptic
Version: 0.13.7-4
Severity: serious
rust-skeptic's dependencies are no longer satisfiable in unstable
after the upload of rust-cargo-metadata 0.15
(a removal request for this package has already been filed)
Package: rust-unzip
Version: 0.1.0-1
severity: serious
rust-unzip is no longer installable in unstable after the upload
of rust-zip 2.0
(a removal request for this package has been filed already)
Package: railway-gtk
Version: 2.7.3-1
Severity: serious
railway-gtk depends on librust-chrono-tz-0.8+default-dev but rust-chrono-tz
is now at version 0.10.
After relaxing the dependency I was able to succesfully build railway-gtk.
diff -Nru railway-gtk-2.7.3/debian/changelog railway-gtk-2.7.3/d
Package: pydantic-core
version: 2.27.2-1
I hope to update rust-idna soon to version 1.0.3 to fix CVE-2024-12224,
the Debian build-dependencies for your package allow the new version
but the Cargo dependency does not.
After relaxing the cargo dependency, I ran into some test failures,
I think the
Package: rust-hyper-rustls
Version: 0.27.5-1
Severity: serious
Tags: patch
Since version 0.26, upstream no longer provides an "acceptor" feature
(see
https://github.com/rustls/hyper-rustls/commit/e19a299b6b08c17bf8307b59b071caa7f6f5a83b
)
the acceptor feature was removed from debian/control in
On 18/03/2025 20:22, Jonas Smedegaard wrote:
Looks like it is best to wait until the current wave of changes related
rustls-pemfile has entered testing before stirring the dependency chain
more. As I understand it, that chain of dependencies currently awaits
axum til mature, and possibly other
On 15/03/2025 14:38, Jonas Smedegaard wrote:
Quoting Peter Green (2025-02-21 05:02:41)
Hi.
I've been looking at the various aspects of the rustls stack update, and I think
we probably want to semver-suffix tokio-rustls and hyper-rustls so reqwest 0.11.
can remain on the old rustls,
In addition to the new version of zbus, there is also now a new version of
tonic, which will
need to be dealt with if this package is to remain in trixie. I had a quick
poke in the
upstream git history and there seems to be a commit doing the update.
https://github.com/containers/netavark/commi
severity 1099728 important
retitle 1099728 unmaintained upstream since 2021
thanks
The crate yaml-rust have seen no upstream activity since 2001, and have
been flagged as unmaintained in RUSTSEC since 2004:
These dates are off by 20 years, rust didn't even exist in 2001.
I'm downgrading this
(assuming phzero is a typo for pgzero)
I was asked to help get pgzero into Debian, but I'm not
particularly a python expert and I don't use it personally.
Please feel free to update the package, modernize the packaging
and bring it into the python team, I'm already technically a
member of said t
Unfortunately we can't remove this patch yet (along with
downgrade-rustls.patch) until the following packages become available:
- librust-hyper-rustls-0.27+http1-dev
- librust-rustls-pemfile-2+default-dev
Opening this bug so it's documented.
I've just updated rustls-pemfile in sid.
The quest
On 22/02/2025 18:31, Jonas Smedegaard wrote:
Quoting Peter Green (2025-02-22 18:23:00)
Package: rust-rustls-native-certs
Version: 0.6.3-4
I hope to update rust-rustls-pemfile to version 2 soon, you expressed
in bug 1098278 that you would prefer the rustls-pemfile and
rustls-native-certs
I couldn't compile it because it rnetlink deps
are not satisfied. I tried to prepare an NMU today but the rnetlink
changes are beyond my rust skills.
For what it's worth, the attatched debdiff will make rust-if-watch
build and pass it's autopkgtests in current sid.
diff -Nru rust-if-watch-3.2
Package: mdevctl
Version: 1.4.0-1
Severity: serious
Your packages build-dependency for the env-logger crate is overly
specific and no-longer satisfiable. The attatched patch adjusts
it to match the Cargo dependency.diff -Nru mdevctl-1.4.0/debian/changelog mdevctl-1.4.0/debian/changelog
--- mdevct
Package: rust-ureq
I hope to update rust-rustls-pemfile soon. The version of rust-ureq
in Debian uses rustls 0.23 and rust-rustls-pemfile 2 upstream, but
is currently downpatched in Debian to rustls 0.21 and rustls-pemfile 1
Since both dependencies were downpatched by the same patch, and we
have
Package: rust-tonic
I hope to update rust-rustls-pemfile to version 2 soon. I have prepared
a patch for rust-tonic.
Unfortunately, the rust-tonic package can't be built in a clean sid
environment right now due to a dependency on an old version of axum.
but I tested in an environment with the axu
I have prepared a patch to make the doctests and examples for the
current version of rust-hyper-rustls build with the new rustls-pemfile.
diff -Nru rust-hyper-rustls-0.24.2/debian/changelog
rust-hyper-rustls-0.24.2/debian/changelog
--- rust-hyper-rustls-0.24.2/debian/changelog 2025-02-07 07:05
Package: rust-imap-client
Version: 0.1.5
Severity: serious
I recently introduced a semver-suffix package rust-tokio-rustls-0.24, and
updated the
main rust-tokio-rustls package to 0.26.
Unfortunately rust-imap-client's debian dependency is inconsistent with it's
cargo
dependency. The Debian dep
Package: rust-rustls-native-certs
Version: 0.6.3-4
I hope to update rust-rustls-pemfile to version 2 soon, you expressed
in bug 1098278 that you would prefer the rustls-pemfile and
rustls-native-certs updates to be handed seperately, so I have
prepared a patch for the old rustls-native-certs to u
It seems to me that you are lumping together two issues that can be
tackled independently. It makes me nervous to do too many changes at
once, especially when they require tight coordination like here: the
patch to support rustls-pemfile 2 removes support for rustls-pemfile 1,
which means the mi
Hi.
I've been looking at the various aspects of the rustls stack update, and I think
we probably want to semver-suffix tokio-rustls and hyper-rustls so reqwest 0.11.
can remain on the old rustls, while reqwest 0.12 moves to the new rustls.
tokio-rustls is a rust team package, so I can deal with
On 19/02/2025 05:49, Jonas Smedegaard wrote:
I would love to get rustls-native-certs upgraded, and am happy for help
doing it, but think that it will require fixing each reverse dependency
first - which was possibly also the exact thing you were doing here.
Yup, working through the reverse depen
I fixed the dependency installability issues with librust-ntp-proto-dev but
rust-ntp-os-clock seems to be incompatible with the new version of
ntp-proto and also seems to be abandoned upstream and has no rdeps
in Debian.
sylvestre, should we remove it?
On 18/02/2025 21:58, Jonas Smedegaard wrote:
Quoting Peter Green (2025-02-18 22:15:14)
Package: rust-mail-send
I hope to update rustls-native-certs to 0.8 soon.
I see that the version in experimental already uses rustls-native-certs 0.8
but it also uses a newer version of tokio-rustls, which
Package: rust-mail-send
I hope to update rustls-native-certs to 0.8 soon.
I see that the version in experimental already uses rustls-native-certs 0.8
but it also uses a newer version of tokio-rustls, which I think it makes
sense to keep as a seperate update.
I've prepared a debdiff against the
Package: rust-imap-client
I hope to update rustls-native-certs to version 0.8 soon.
The version of rust-imap-client currently in debian already
uses 0.8 upstream and the patched cargo dependency already
allows both versions, so I initially thought this would
just be a case of updating the debian
Package: rust-rustls
I hope to update rust-rustls-native-certs to version 0.8 soon
(after the new rust-rustls is in testing), I think it probablly
makes sense to update rust-hyper-rustls at the same time.
I looked though the upstream git history and it seems that the
changes for 0.7-0.8 are in a
Package: pushpin
I hope to update rustls-native-certs to 0.8 soon, pushpin needs
a small patch to build with the new rustls-native-certs.
While working on the patch I ran into and dealt with a couple
of unrelated build failures.
debdiff is attatched.diff -Nru pushpin-1.39.1/debian/changelog pus
Package: rust-rustls-0.21
I hope to update rustls-pemfile to version 2 and rustls-native-certs to
version 0.8 in unstable after the new rust-rustls migrates to testing.
The new versions have been in experimental
for some time.
rustls-0.21 uses these crates for it's examples and tests,
I looked
Package: librust-rustls-0.21-dev
Version: 0.21.12-12
Severity: serious
While attempting to update one of my development chroots I ran into the
following error.
> Unpacking librust-rustls-0.21-dev (0.21.12-12) ...
> dpkg: error processing archive
/var/cache/apt/archives/librust-rustls-0.21-dev_
Package: python-libcst
Version: 1.4.0-1.1
Severity: serious
Tags: patch
python-libcst's Cargo.toml asks for version 1.x of the thiserror
crate. Currently Debian has two versions of the crates, version
1.x in the librust-thiserror-1-dev package and version 2.x in
the librust-thiserror-dev package.
Tags 1095393 +path
thanks
With the attatched patch I was able to build sourmash succesfully.diff -Nru sourmash-4.8.14/debian/changelog sourmash-4.8.14/debian/changelog
--- sourmash-4.8.14/debian/changelog2025-01-20 10:50:45.0 +
+++ sourmash-4.8.14/debian/changelog2025-02-11 14
Looking at the version number, the offending package seems not to be
from debian/raspbian per-se, but from the packages raspberry pi add on
top of Debian/Raspbian to make "raspberry Pi OS".
On 06/02/2025 10:39, Andrew Maier wrote:
Hello,
Thanks for all these pointers.
For my Raspis, I usually
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-sqlx-core and rust-sqlx seem to be blocked by some autopkgtest snarlups,
particularly 3 autopkgtests seem to be stuck in "test in progress".
The test for rust-ognibuild with the new r
Package: rust-idna
Severity: important
It seems like it would be a good idea to upgrade the idna crate to version 1,
version 0.5 has a "security" issue and the new version of rust-url, which has
been requested by jonas needs version 1.
rust-idna 1 supports multiple backends with the backend bein
Package: rust-serde-yml
Severity: serious
(I will be cloning this bug against rust-libyml once I have a bug number)
rust-serde-yml is a fork of rust-serde-yaml and rust-libyml is
a fork of rust-unsafe-libyaml.
Serious concerns have been raised about the quality of code in
rust-serde-yml.
https
I tried to get this building with idna 0.4 but it seems like
a pain, so probablly better to do this as part of an idna 1
update.
Will look into what that entails, but not right now.
rust-serial-test version 3 depends on the scc crate which is
not currently in Debian.
Looking at the package descriptions I think html5ever, xml5ever and markup5ever
should probablly be updated as a group.
So either
html5ever 0.27, markup5ever 0.12, xml5ever 0.18
html5ever 0.28, markup5ever 0.13, xml5ever 0.19
html5ever 0.29, markup5ever 0.14, xml5ever 0.20
Looking at the
Package: rust-condure
x-debbugs-cc: j...@debian.org
rust-condure has not seen either a maintainer upload, or a new upstream
release in two years.
Furthermore, upstream recently archived the git repository with the
following message.
> UPDATE: This project has been merged into Pushpin and the re
I see that in addition to updating to 0.22, jamessan has restructured
the tree-sitter packaging in experimental to take it out of the rust
team and move to a single source package (tree-sitter) for all the
tree-sitter-* packages.
Looking through the reverse dependencies I see
sdml - maintained b
tags 1091017 +patch
thanks
A merge request addressing this issue can be found at
https://salsa.debian.org/debian/elan/-/merge_requests/1
Package: sccache
Version: 0.9.0-1
I am currently looking at updating rust-backtrace and related packages
to the latest version, backtrace itself is not semver-breaking but
a number of it's dependencies are.
backtrace 0.3.69 -> 0.3.74
addr2line 0.21.4 -> 0.24.2
object 0.32.3 -> 0.36.5
gimli 0.28.
Package: rust-cranelift
Version: 21.0.2+dfsg-1
I am currently looking at updating rust-backtrace and related packages
to the latest version, backtrace itself is not semver-breaking but
a number of it's dependencies are.
backtrace 0.3.69 -> 0.3.74
addr2line 0.21.4 -> 0.24.2
object 0.32.3 -> 0.36.
As the PTS page shows, rust-ognibuild has long failed to migrate to testing due
to broken depedencies. This, in turn, affects the migration of other packages.
Could you please look into this? Thanks!
Update, I have uploaded the latest version of rust-ognibuild, currently it's
testing migratio
Package: ftp.debian.org
Please remove rust-vm-memory and it's reverse dependencies rust-vhost,
rust-vhost-user-backend
and rust-virtio-queue on 32-bit architectures. The new version of
rust-vm-memory has a
build-dependeny on "architecture-is-64-bit" and the other packages in the list
all
build
Package: rust-lazy-regex
Version: 3.3.0+20241210-1
Severity: serious
rust-lazy-regex's autopkgtests are failing in most test
configurations due to lack of feature gates on tests.
The attatched debdiff adds said feature gates.
diff -Nru rust-lazy-regex-3.3.0+20241210/debian/changelog
rust-lazy-re
Package: dgit
mkdir test
dget -d http://ftp.debian.org/debian/pool/main/g/glib2.0/glib2.0_2.82.3-2.dsc
cd test
git init
dgit import-dsc ../glib2.0_2.82.3-2.dsc +workingbranch
results in
gpgv: Signature made Tue 10 Dec 2024 23:42:20 GMT
gpgv:using RSA key 7A073AD1AE694FA25BFF62E5
Package: rust-lazy-regex
Version: 3.1.0-6
Severity: serious
The no features autopkgtest for rust-lazy-regex is failing.
78s error[E0432]: unresolved import `regex`
78s--> src/lib.rs:203:9
78s |
78s 203 | self,
78s | no external crate `regex`
Doing some di
Package: fragments
Version: 3.0.1-3
Severity: serious
fragments has an overly-tight build-dependency on rust-regex, which is
unsatisifable since the upload of rust-regex 1.11
The attatched patch relaxes the build-dependency to match the cargo
dependency. I have tested that the package builds wit
Package: rust-leptonica-sys
The autopkgtests for rust-leptonica-sys are failing on i386 due to a bindgen
layout test failure. Doing some digging it seems the type involved is a
system type and appears to be built-in to gcc/clang rather than defined
in a header.
This issue has been around for a w
Package: rust-leptess
Version: 0.14.0-6
The autopkgtest for rust-leptess fails with rust-image 0.25,
preventing rust-image from migrating to testing.
https://ci.debian.net/packages/r/rust-leptess/testing/amd64/54239350/#S6
85s error[E0433]: failed to resolve: could not find `ImageOutputFormat
Package: jameica-datasource
Version: 2.8.1+dfsg-4
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
jameica-datasource build-depends on libmckoisqldb-java-doc which is
no longer built by t
Package: rust-tealdeer
Version: 1.7.0-1
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
tealdeer build-depends on versoin 0.5 of rust-yansi, but trixie/sid
now has version 1, so it is no
Package: libpdb-redo3
Version: 3.1.5-3
Severity: serious
libpdb-redo3 has a hard coded dependency on libcifpp5, so after
building aginst the new version it ends up with dependencies
on both libcifpp5 and libcifpp7
Please remove or update the dependency.
This bug affects both 3.1.5-3 in testing
Please upgrade to, or separately provide, branch v0.29.
I think I've pretty much worked through all the rdeps now.
Currently waiting for rust-findutils (hopefully my latest uploaded fixed it)
and rustc to get into testing before I go ahead and do the big block of
uploads to unstable.
aardvark-
Package: tuigreet
Version: 0.9.1-3
I hope to update rust-nix to version 0.29 soon. The Debian
build-dependency in your package allows the new version,
but the Cargo dependency does not.
After relaxing the Cargo dependency the package builds
successfully with the new version of nix. It is availab
Package: trippy
Version: 0.11.0+dfsg-2
I hope to update rust-nix to 0.29 soon.
For trippy, upstream uses 0.29, so this is just a matter of dropping
some patching and updating the Debian build-dependncy.
Debdiff is attatched. The new version of rust-nix is available in
experimental.diff -Nru tri
Package: meli
Version: 0.8.7+20241007+dfsg-1
I hope to update rust-nix to version 0.29 soon. For meli this means
dropping most of 2001_nix.patch, bumping the nix dependency in the
tools directory, making some minor adjustments to other packages
and bumping the debian build-dependencies.
A debdif
Package: greetd
Version: 0.10.3-1
I hope to update rust-nix to 0.29 soon. Greetd needs a small patch
to build with the new version.
Unfortunately the patch will break the build with nix 0.27, so
it will need to be uploaded after nix is updated. In the
meantime the new version of nix has been upl
Package: fragments
Version: 3.0.1-2
I hope to update rust-nix to 0.29 soon. After relaxing the dependencies
I was able to build fragments successfully against the new nix.
A debdiff is attatched, the new version of rust-nix is available in
experimental if you want to do further testing.diff -Nru
Package: bpftop
Version: 0.5.2.9.ga1b99d7-1
I hope to update rust-nix to version 0.29 soon, the Debian
build-dependencies for your package allow the new version
but the cargo dependencies do not. After relaxing the
Cargo dependency I was able to build bpftop succesfully
against the new version of
Package: aardvark-dns
Version: 1.12.2-1
I hope to update rust-nix to version 0.29 soon. I've prpared a patch
for aardvark-dns. The patch is pretty trivial but unfortunately the
nature of the API change made it impractical to support both old
and new versions in the patch.
I was able to succesful
Reading the upstream changelog it seems that a load of
"breaking changes" came in 0.10 with those since then
being relatively minor. I've taken a priliminary look
through the rdeps and most of the important ones seem
to have updated to at least 0.10 upstream.
So my gut feeling is to start prepari
Version: 0.7.0~beta.2-2
During a rebuild of all packages in unstable, your package failed to build:
This was fixed just before the bug was filed.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I am trying to get the new versions of rust-sqlx and
related packages into testing, this is a prerequisite for
getting the new version of rust-base64 into testing.
It's currently blocked b
I intend to remove this package:
* It has no rev dependencies
From what I can see, haskell-hopenpgp-tools build-depends on it.
It seems after jonas's revert of his debian/rules restructuring the vendored
libs
were no longer being located. Some small tweaks fixed that.
There has also been an update of rust-base64 recently which needed to be
accounted
for.
Debdiff is attatched.
diff -Nru matrix-synapse-1.116.0/debian/ch
Package: mricron
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
mricron build-depends on lazarus-src-3.0 which is no longer built
by the lazarus source package, it is
Please upgrade to branch v5.
I think it probablly makes more sense to go straight to version
6. I've uploaded that to experimental, can you prepare an update
to precious.
upstream changelog analysis:
nothing that looks too massive/scary, just msrv/dependency
bumps and some slight changes to er
The build-depends need to be changed from librust-cbindgen-dev to
librust-cbindgen-0+default-dev to properly reflect the cargo
dependency.
Package: rust-coreutils
Version: 0.0.26-3
Severity: serious
rust-coreutils fails to build on 32-bit architectures. I first noticed
this after uploading 0.0.26-4 to fix the build with the new version of
rust-half, but according to reproducible builds it also seems
to affect 0.0.26-3
> make[1]: En
On 26/09/2024 16:02, Paul Gevers wrote:
Hi Peter,
On 26-09-2024 16:24, Peter Green wrote:
Firstly britney is scheduling tests with the old
version of rust-sequoia-keystore and the new version of
rust-sequoia-keystore-tpm, despite the fact that the old
version of rust-sequoia-keystore does not
I tried in raspbian trixie changing the build-dependency to libhdf5-mpi-dev,
but the build
failed with.
/usr/bin/mpicc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/vtk9-9.3.0+dfsg1=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -D_LA
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-sequoia-keystore-tpm is blocked from migrating to testing
by two issues. I do not believe either of these issues represent
real issues in the rust-sequoia-keystore-tpm package and
ther
Package: sccache
Version: 3.3.1-3
I hope to upgrade itertools to 0.13 soon, I've uploaded
new version to experimental. sccache has a
dev-dependency on itertools which the debian packaging
translates to a build-dependency.
I looked at the upstream changelog and didn't see anything too
scary and a
Package: rust-test-case
Version: 3.3.1-3
I hope to upgrade itertools to 0.13 soon, I've uploaded
new version to experimental. rust-test-case has a
dev-dependency on itertools which the debian packaging
translates to build and autopkgtest dependencies.
I looked at the upstream changelog and didn'
Package: qtsystems-opensource-src
Version: 5.0~git20230712.81e08ee+dfsg-2
Severity: serious
libqt5publishsubscribe5 was renamed to libqt5publishsubscribe5t64 and
libqt5serviceframework5 was renamed to libqt5serviceframework5t64 as
part of the time64 transition, but the package names in the
corres
Package: libsis-jhdf5-java
Version: 19.04.1+dfsg-7
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable
libsis-jhdf5-java build-depends on libeclipse-jdt-compiler-apt-java
which is no longer built by the eclipse-jdt-core source package.
This package is still present in
Package: loupe
Version: 46.2-2
Severity: serious
loupe build-depends on librust-ashpd-0.8+default-dev but testing/unstable
has version 0.9.
Package: gnome-metronome
Version: 1.3.0-5
Severity: serious
gnome-metronome build-depends on librust-gtk4-0.8+v4-10-dev but
unstable has version 0.9.
Package: glycin-loaders
Version: 1.0.1+ds-3
Severity: serious
glycin-loaders build-depends on librust-gio-0.19+default-dev but
testing/unstable now has version 0.20.
Package: camlimages
Version: 1:5.0.5-1
Severity: serious
It seems that about a fortnight ago camlimages started to FTBFS
on the "reproducible builds" tests server. This seems contempory
with the upload of ocaml 5.2.0-3
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/camlimages
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-unicode-width is blocked from migrating to testing by
autopkgtest failures in rust-tui. rust-tui is abandoned
upstream and we intend to get rid of it (see bugs
1080293 and 1080400). Up
Package: gnome-metronome
Version: 1.3.0-4
Severity: serious
gnome-metronome's build-dependencies are unsatisfiable due to the recent
rust gtk stack update.
After bumping the build-dependencies and cargo dependencies I was able
to build the package and run it's (superficial) autopkgtest succesful
Please upgrade to, or separately provide, quick-xml branch v0.36.
Raising severity, since oxigraph needs the bugfixes, and is crippled by
being forced to patch to use an older branch.
The new version is in experimental.
I've started looking through the rdeps but it may take a bit of time.
I be
Package: rust-typenum
Severity: serious
rust-typenum is suffering from a failing test on i386, this
has been the case for some time as evidenced by debci and
reproducible builds test history but did not come to my
attention until a new version was uploaded and a "fails
to migrate to testing for a
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock rust-sqlx, it is currently blocked
by an autopkgtest "regression" of rust-debversion on
riscv64, which is caused by the fact that rust-debversion
is uninstable in testing on
1 - 100 of 1342 matches
Mail list logo
