Package: greetd
I hope to update rust-nix to 0.30 soon. Greetd needs a small
patch to build with the new version.
Unfortunately the patch for 0.30 breaks building with 0.29, so
actual uploading to sid will have to wait until rust-nix hits
sid, but in the meantime you can test with the package fr
Package: hippotat
I hope to update rust-nix to 0.30 soon, nix 0.30 changes
the read and dup2 apis as part of the crate's gradual move
towards "io safety".
IIRC hippotat values compatibility with a wide range of
nix versions, and furthermore the code didn't seem
paritcularly orientated towards io
Package: glycin
I hope to update rust-nix to 0.30 soon, glycin needs it's
dependency relaxing to accomodate this.
A debdiff is attatched.diff -Nru glycin-2.0.0+ds/debian/changelog glycin-2.0.0+ds/debian/changelog
--- glycin-2.0.0+ds/debian/changelog2025-09-24 13:37:01.0 +
+++ gly
Package: fish
I hope to update the nix crate to 0.30.1 soon. I put together
a patch to make fish build with the new upstream version.
Debdiff is attached.diff -Nru fish-4.0.2/debian/changelog fish-4.0.2/debian/changelog
--- fish-4.0.2/debian/changelog 2025-04-20 17:01:54.0 +
+++ fish
I've prepared an update to the latest version of clap and uploaded it to
experimental,
the following packages are updated in expermental.
clap 4.5.23 -> 4.5.48
clap-derive 4.5.18-> 4.5.47
clap-builder 4.5.23 -> 4.5.48
pulldown-cmark 0.10.3 -> 0.13.0
pulldown-cmark-escape 0.10.1 -> 0.11.0
The cl
Package: rustup
I hope to update rust-pulldown-cmark soon. I have applied the upstream
commits upgrading pulldown-cmark to the version of rustup in Debian
and they build fine.
Debdiff is attatched, I intend to team upload this when I update
pulldown-cmark.diff -Nru rustup-1.27.1/debian/changelog
Package: rust-version-sync
I hope to update rust-version-sync soon (as part of the clap update)
rust-version-sync needs it's dependencies tweaking to accomodate this.
A debdiff is attatched.
diff -Nru rust-version-sync-0.9.5/debian/changelog
rust-version-sync-0.9.5/debian/changelog
--- rust-ve
Package: elan
I hope to update rust-pulldown-cmark to 0.13 soon. Elan needs
a small patch to build with the new version. I have written
the patch in such a way as to retain compatibility with the
old version.
diff -Nru elan-4.1.2/debian/changelog elan-4.1.2/debian/changelog
--- elan-4.1.2/debian
Please upgrade crate hostname to branch v0.4.
I've uploaded the new version to experimental
Please prepare an update for scaphandre and tell me
when you are ready for an upload to unstable.
Package: sccache
I hope to update rust-zip to the latest upstream version soon,
sccache needs some dependency adjustments
(both Debian and Cargo) to build with the new version.
debdiff is attatched, new version of rust-zip is available
in experimental.
diff -Nru sccache-0.10.0/debian/changelog s
I think we should be good to go with updating rust-zip to the latest
upstream pretty soon, the main blocker is we need to get rust-liblzma
availble on all release architectures.
reverse dependency analysis below.
elan - bug report filed with patch
gnome-authenticator - bug report filed with pat
Package: gnome-authenticator
I hope to update rust-zip to the latest upstream version soon,
gnome-authenticator needs some dependency adjustments
(both Debian and Cargo) to build with the new version.
Debdiff is attatched, I may NMU this later.
diff -Nru gnome-authenticator-4.6.2/debian/changelo
Package: python-maturin
I hope to update rust-zip to the latest upstream version soon,
python-maturin's Debian build-dependencies allow the new
version but it's Cargo dependencies do not. I patched the
Cargo dependency to remove the upper limit and also
updated the Debian dependency to match the
Package: elan
I hope to update the rust-zip package to the latest upstream version soon,
elan requires a tweak to it's cargo dependencies to build with the new
version.
While working on this I discovered that elan fails to build if
librust-semver-dev is installed. The debian dependencies of the
tags 1115342 +patch
thanks
Attatched is a patch to make sourmash work with the packages currently in sid
diff -Nru sourmash-4.9.4/debian/changelog sourmash-4.9.4/debian/changelog
--- sourmash-4.9.4/debian/changelog 2025-09-13 10:06:13.0 +
+++ sourmash-4.9.4/debian/changelog
Please upgrade crate rcgen to v0.14.2.
Uploaded to experimental.
There seem to be three reverse dependencies: rust-rustls,
rust-rustls-webpki and rust-parsec-tool.
I've prepared an update for parsec-tool, can you prepare updates
for rustls and rustls-webpki and tell me when you are ready for a
While hanging, it's consuming more and more memory, until all memory
(251 GiB + 148 GiB swap) is exhausted and the OOM-killer kicks in.
I've dug into this issue and found the following.
When passed a particular incorrect format string (I have not tested
if it happens for other incorrect forma
Severity 752 important
thanks
I've skipped the tests in question for now, keeping this bug open in-case
someone
wants to investigate deeper.
Package: rust-glib-0.18
Version: 0.18.5-4
Severity: serious
The autopkgtests for rust-glib-0.18 seems to be flaky which causes
delays to the migration of other rust packages.
Some architectures seem worse than others, amd64 and arm64
fail roughly half the time, armhf and i386 pass most
of the ti
There is the RUSTSEC-2025-0051 advisory for rust-xcb:
I feel calling this a "security" issue is a stretch.
https://rustsec.org/advisories/RUSTSEC-2025-0051.html
| xcb::Connection::connect_to_fd* functions violate I/O safety
The so-called "fixed version" doesn't seem to actually "fix"
anythin
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-tempfile is blocked from migrating to testing by an
autopkgtest "regression" in rust-debian-analyzer on s390x.
The root cause of this "regression" is that apt currently
fails to insta
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-rustls is blocked from migrating to testing by autopkgtest
"regressions" in rust-rustls-platform-verifier.
These are caused by the fact that both rust-rustls and
rust-rustls-platform-
Package: rust-ureq
Version: 3.1.0+~0.5.0-3
Severity: serious
Tags: patch
rust-ureq's autopkgtests are failing because the ureq-proto provides
were updated to 0.5 but the test dependencies were not, resulting in
dependency installation failure.
A debdiff fixing this is attatched.
diff -Nru rust-
Package: rust-rustls
Version: 0.23.31+ds-2
Severity: serious
rust-rustls's autopkgtest is failing due to missing test data.
73s error: couldn't read `src/client/../../../test-ca/rsa-2048/client.key`: No
such file or directory (os error 2)
73s--> src/client/test.rs:476:18
73s |
73s
Package: ftp.debian.org
Please remove rust-tower-http-0.4, all reverse dependencies have now
migrated to version 0.6.
Tags 242 +moreinfo
On 16/08/2025 03:47, Peter Green wrote:
Package: ftp.debian.org
Please remove rust-headers-0.3, all reverse dependencies have now
migrated to version 0.4.
oops, screwed up my reverse dependency checks, rust-warp still
uses this, tagging moreinfo for now (we do want to
Package: ftp.debian.org
Please remove rust-headers-0.3, all reverse dependencies have now
migrated to version 0.4.
Severity 1110778 important
Thanks
On 12/08/2025 18:58, Matthias Geiger wrote:
On Tue, 12 Aug 2025 15:12:27 +0100 Peter Michael Green
wrote:
severity 1110778 serious
thanks
I've fixed this package up so it doesn't block the rustls-webpki update
but I agree it should probably not be in forky,
(note: this is a reply to a post on bug 069 but bug 1096153
seems a more appropriate place to discuss this)
On 14/08/2025 14:05, Jonas Smedegaard wrote:
Seems to me that these are in need of a patch:
* pushpin (too optimistic Debian dependency declared)
Already FTBFS and is not in testi
I assume this to not be
worth handling since I expect this package to now be obsolete (see
bug#1110778),
Matthias Geiger noticed that librust-async-tungstenite-dev depends
on it, so while we may well still decide to get rid of rust-async-tls
in the medium term, it's not something that's likely t
During a rebuild of all packages in unstable, package "resvg"
failed to build due to the newer version of src:rust-zune-jpeg
which was uploaded on 2025-06-27.
Thank you.
A quick look suggests that other rdeps are ok, and this is just
an issue with resvg.
I have filed a bug about this upstream
Package: rust-indieweb
After the release of trixie, we would like to clean up the remaining users of
http 0.1. Part of that is updating rust-oauth2 from version 4 (which uses http
0.1 and reqwest 0.11) to version 5 (which uses http 1.0 and reqwest 0.12),
rust-ouath2 version 5 is currently availab
There is an upstream pull request addressing this issue at
https://github.com/bji/libs3/pull/115
I was able to take the patch from said PR and tweak it so it
could be used with the version of the code in Debian, debdiff
attatched.
diff -Nru libs3-2.0/debian/changelog libs3-2.0/debian/changelog
Package: git
Severity: important
X-Debbugs-CC: sanv...@debian.org, samuel...@debian.org, g...@vger.kernel.org,
pkg-rust-maintain...@alioth-lists.debian.net
When building against curl 8.14 git creates a whole bunch of compiler
warnings. We originally discovered this because of a package in Debian
> During a rebuild of all packages in unstable, your package failed to build:
It appears the function in question is a variadic function. The
documentation for curl_easy_setopt says.
"That parameter can be a long, a function pointer, an object pointer or a
curl_off_t, depending on what the spe
Backporting upstream PRs #103, #115, #117 and #127 should fix these issues.
The named maintainer of this package hasn't touched it since 2019, since then
it's been kept alive by team uploads, mostly by me, but there has been an
upstream a package split, and at least I'm personally very reluctant
Please upgrade crate matchit to at least v0.8.3 (in experimental only
for now, due to the freeze).
Done in experimenta, please get in touch when (post trixie) you are ready
for the upload to unstable.
The only reverse dependency seems to be your package rust-axum.
Please upgrade crate oauth2 to v5.
Done in experimental, please get in touch when (post-trixie)
you are ready for an upload to unstable.
The only reverse dependency seems to be rust-indieweb
which is one of your packages.
On 27/05/2025 20:13, Matthias Klose wrote:
Control: tags 1106609 -moreinfo
On 27.05.25 21:08, Peter Green wrote:
tags 1106609 +moreinfo
tags 1106609 +unreproducible
I was unable to reproduce this, I also note that the log fragment you posted
seems to
mention a rustc version from ubuntu
tags 1106609 +moreinfo
tags 1106609 +unreproducible
I was unable to reproduce this, I also note that the log fragment you posted
seems to
mention a rustc version from ubuntu.
Can you please post links to a full log, demonstrating a build failure (note:
I've seen
some crates that try building
Bugs 1101625 and 1101607 are fixed in unstable and on their way
to testing, but thanks to the need for some follow-up uploads
and thanks to the 20 day migration delay imposed by the release
team will not make it there before the current autoremoval dates.
I am thus sending a message to the bugs to
Package: rust-rustix
Version: 0.38.37-2
Severity: serious
The autopkgtests for rust-rustix are failing on i386.
1337s backend::vdso::test_vdso stdout
1337s
1337s thread 'backend::vdso::test_vdso' panicked at src/backend/linux_raw/vdso.rs:428:28:
1337s called `Option::unwrap()` on a
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
1 - 100 of 1384 matches
Mail list logo
