Because of this bug, rust-protobuf is now marked for autoremoval
together with the following packages:
rust-erbium, rust-erbium-core, rust-pprof, rust-prometheus,
rust-protobuf-codegen, rust-protobuf-codegen-pure, rust-protoc-rust,
rust-ttrpc, scaphandre.
scaphandre was already decoupled fro
I decoupled handlebars from the rest and filed [1] to also decouple
prometheus: erbium (its only (transitive) reverse dependency
application) doesn't use protobuf's functionality. This however is not a
small change, so it needs consensus from the team (hence the MR). Pros
and cons are detailed
On 25/04/25 07:05, Jonas Smedegaard wrote:
Scaphande is now (pending upload) patched to no longer build-depend on
the protobuf crate. Turns out it was optional and already unused for
other reasons (will file a bug about that upstream).
Thanks Jonas!
As for erbium (via erbium-core), it looks l
Source: rust-protobuf
Followup-For: Bug #1103833
X-Debbugs-Cc: noisyc...@tutanota.com, jel...@debian.org, infini...@debian.org,
d...@jones.dk
Control: forwarded -1 https://github.com/stepancheg/rust-protobuf/issues/763
I looked into this, I will try to summarize the situation to the best of my
kn
Source: lsp-plugins
Followup-For: Bug #1102592
X-Debbugs-Cc: noisyc...@tutanota.com, s...@debian.org
Hi there,
I think migration of lsp-plugins to testing is currently blocked because a
removal from armel was not requested?
Current excuses says:
```
- Migration status for lsp-plugins (1.2.16-1
Source: scaphandre
Followup-For: Bug #1102386
X-Debbugs-Cc: noisyc...@tutanota.com
Control: tags -1 + patch
Came across this while doing other work, you will find a patch in attachment.
Cheers!
mdbook-fix.patch
Description: application/mbox
Source: rust-pyo3
Followup-For: Bug #1103894
X-Debbugs-Cc: noisyc...@tutanota.com
Control: tags -1 + pending
It looks like the fix [1] can be easily backported to v0.22, so we can avoid
a transition to v0.24 late in the trixie freeze. Fixed in VCS, waiting for
upload.
Thanks!
[1] https://github
This is due to rust-tiny-skia and rust-tiny-skia-path now building in
unstable with rustc 1.85.0+dfsg2-3, which reintroduced a number of
packages on i386, including resvg. resvg builds fine in unstable/i386
[2] with that version of rustc. When rustc migrates to testing this bug
will solve itsel
Package: asahi-audio
Version: 3.1-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: noisyc...@tutanota.com
After upgrading from 3.0-3 to 3.1-1, volume cannot be turned down (or up, but
the default is almost full volume so this is less of an issue) on an M1 Mini
Package: oss4-dev
Version: 4.2-build2020-3
Severity: serious
Justification: Policy 3.9
X-Debbugs-Cc: noisyc...@tutanota.com
Dear Maintainer,
While discussing the new 'missing-breaks' Salsa CI job [1], one of the kernel
maintainers stated that oss4-dev's soundcard.h must not be installed under
/us
Package: rustup
Version: 1.27.1-2+b1
Followup-For: Bug #1095964
X-Debbugs-Cc: noisyc...@tutanota.com
Control: tags -1 + pending
Fixed in git, waiting for upload.
Thanks!
Package: reprepro
Version: 5.4.6-2
Followup-For: Bug #1095493
X-Debbugs-Cc: noisyc...@tutanota.com
I got the same error after updating a 'mesa-asahi' package. After running
translatelegacyreferences [1] and doing the update, my packagenames.db
contains a single item,
[(b'mesa-asahi\x00', b'mesa-a
l, making
tests uninstallable; 2. two of resvg's examples should be gated behind the
correct features. The patches in attachment, to be applied to the debian
packages in no precise order, fix both of them.
Cheers!
>From 4983a9ca52e2d9bd378ebadea5524b4a3eeaf185 Mon Sep 17 00:00:00 2001
From: NoisyCoil
No problem, thanks a lot!
Package: alsa-ucm-conf
Version: 1.2.13-1
Followup-For: Bug #1092257
X-Debbugs-Cc: noisyc...@tutanota.com, jo...@debian.org
Hi Jordi,
Should we NMU this?
Thanks
Source: llvm-toolchain-19
Version: 1:19.1.7-1
Severity: serious
Tags: ftbfs patch
Justification: RT
X-Debbugs-Cc: noisyc...@tutanota.com
Dear Maintainer,
starting from 2.43.90.20250202-1, binutils now suggests binutils-gold instead
of depending on it [1]. As a consequence llvm must now depend exp
with async-std),
showing that the underlying issue is in fact the same as Bug #1094483.
>From 475f2bf42e577d93ed524848d7862d6afd857a6f Mon Sep 17 00:00:00 2001
From: NoisyCoil
Date: Fri, 7 Feb 2025 19:59:52 +0100
Subject: [PATCH] Add a `no-lock` option to `cargo package`
---
src/bin/cargo/
Package: dh-rust
Version: 0.0.10
Followup-For: Bug #1094199
X-Debbugs-Cc: noisyc...@tutanota.com, jo...@jones.dk, ben...@debian.org
Hi Jonas,
Just putting some ideas out there, not sure they will actually help but at
least I tried.
Why should dependencies be installed in the correct order in th
Control: retitle -1 dh-rust: fails to build packages with profile `nocheck` and
B-Ds
Control: severity -1 important
Control: affects -1 + src:rust-async-std
Third time's the charm, they say.
Control: reassign -1 dh-rust
Control: retitle -1 dh-rust: fails to build packages with profile
`nocheck` and B-Ds
Control: severity -1 important
Control: affects -1 + src:rust-async-std
This is a dh-rust bug. When the build is done with the `nocheck`
profile, `cargo package` is still called i
Control: retitle -1 dh-rust: fails to build packages with profile
"nocheck" and B-Ds
Control: severity -1 important
Control: affects -1 + src:rust-async-std
BTS control server was apparently unhappy with the retitling format,
trying again.
Package: dh-rust
Version: 0.0.10
Followup-For: Bug #1094199
X-Debbugs-Cc: noisyc...@tutanota.com, jo...@jones.dk
Hi Jonas,
Has there been any progress on this bug? It is currently blocking the bindgen
transition (via oxigraph) and may possibly block other updates to come (some
evidence of this in
Package: m1n1
Version: 1.4.19-1
Severity: critical
Tags: upstream sid
Justification: breaks the whole system
X-Debbugs-Cc: noisyc...@tutanota.com
Version 1.4.19 [1] of m1n1 makes M2 Pro/Max Macbook Pros unbootable [2].
[1] Actually, >= 1.4.18, <= 1.4.20, but testing currently has 1.4.17 and
stall due to bug #1094737. And of
course, FTBFS means I could not *actually* test the package with the new
bindgen.
>From 3f599130570d95583a429665ee861920eb60c60c Mon Sep 17 00:00:00 2001
From: NoisyCoil
Date: Sat, 25 Jan 2025 21:11:00 +0100
Subject: [PATCH] Update to bindgen v0.71
---
debia
Source: oxigraph
Version: 0.4.7-2
Severity: serious
Tags: ftbfs
Justification: RT
X-Debbugs-Cc: noisyc...@tutanota.com
Hi,
rust-bindgen v0.71 was just accepted in unstable. At this time src:oxigraph
(both v0.4.5-1 in unstable and v0.4.7-2 in experimental) depends on v0.70. Due
to the current FTBF
> It seems you are reusing a bugreport about one build failure for
another bug about a differently caused build failure.
No, I'm not. If you read my previous email to the BTS:
> Sorry, yesterday I didn't notice 0.4.7-2 is in exp, so downgrading
severity to normal. I will retry with 0.4.5-1 whe
Control: severity -1 normal
Hi Jonas,
Sorry, yesterday I didn't notice 0.4.7-2 is in exp, so downgrading
severity to normal. I will retry with 0.4.5-1 when I find some time.
Best.
Package: alsa-ucm-conf
Followup-For: Bug #1092257
X-Debbugs-Cc: noisyc...@tutanota.com,
Hello,
Has there been any progress on this bug? Since the upstream bug was opened in
November and there haven't been new releases yet, perhaps it could be fixed
by applying the patch? Watching this closely as
Control: tags -1 + pending
Fixed in git, will ask to upload.
Control: tags -1 + pending
Hi Holger,
I've already fixed this in Salsa together with a number of related bugs,
will ask someone from the Rust Team for sponsorship soon (a large
migration is expected in the next few hours, so I'm trying to avoid
interferences).
Cheers!
FWIW, just to add half a data point, I recently tried backporting
rustc-1.83 to bookworm (that is, using the source from unstable), and
this bug didn't show up neither on amd64 nor on arm64. My logs look
exactly the same as Fabian's.
Cheers!
Source: rust-cargo
Followup-For: Bug #1090298
X-Debbugs-Cc: noisyc...@tutanota.com
Control: merge -1 1090296 1090297 1090299 1090301
Hi,
These are all the same bug, fixed by yesterday's upload of
librust-gix-credentials-dev 0.24.3-2. I'll wait for the latter to migrate to
testing and then I'll cl
, I'm attaching a patch to decouple
rust-rust-ini from it. The patch is to be imported with quilt.
Cheers!
>From 19548da2f8b520d5b8177e801503aac18d9204c4 Mon Sep 17 00:00:00 2001
From: NoisyCoil
Date: Sun, 15 Dec 2024 12:46:33 +0100
Subject: [PATCH] Temporarily patch-out trim_in_place
Avoid
Package: librust-lazy-regex-dev
Followup-For: Bug #1089204
X-Debbugs-Cc: noisyc...@tutanota.com
Jonas,
Are you sure you are not mixing up bugs? This one is for an autopkgtest failure
that existed in v3.1, but currently (v3.3) there are other autopkgtest failures
which were just introduced upstrea
> Indeed I totally missed it. And your proposed patch (if working, which
> I am testing right now, restructered to instead extend existing feature
> fencing patch) is more elegant than giving up and skipping the test.
>
Thanks and I agree, it could be worth it not to disable the test. This is t
Source: rust-coreutils
Severity: serious
Justification: RT
X-Debbugs-Cc: noisyc...@tutanota.com
Dear Maintainer,
As agreed with you in [1], I'm about to file a removal request for rust-users
(see security Bug#1051808). rust-coreutils is the only package in the archive
that still depends on rust-u
Package: librust-lazy-regex-dev
Followup-For: Bug #1089204
X-Debbugs-Cc: noisyc...@tutanota.com, d...@jones.dk
Hi Jonas,
I think you missed this bug, which was filed before plugwash's #1089813. This
is RC too, so it will prevent migration. Feel free to close it.
Best.
Source: librust-lazy-regex-dev
Followup-For: Bug #1089204
X-Debbugs-Cc: noisyc...@tutanota.com
Control: reassign -1 librust-lazy-regex-dev
Source: librust-lazy-regex-dev
Version: 3.1.0-6
Severity: serious
Tags: patch upstream
Justification: RT
X-Debbugs-Cc: noisyc...@tutanota.com
Hi,
Even after the changes in your last upload, lazy-regex failed the test with all
features disabled. I'm attaching a patch to be imported with quilt that
Source: rust-leptonica-sys
Followup-For: Bug #1088237
X-Debbugs-Cc: noisyc...@tutanota.com
Hi,
The bug should be fixed in v0.4.9.
Cheers.
Source: rust-leptonica-sys
Followup-For: Bug #1088237
X-Debbugs-Cc: noisyc...@tutanota.com
Control: forwarded -1 https://github.com/ccouzens/leptonica-sys/issues/29
Having spent some more time debugging this issue, I now see I looked at the
wrong autopkgtest run for leptonica-sys. The one I linked
Source: rust-leptonica-sys
Severity: serious
Tags: upstream
Justification: RT
X-Debbugs-Cc: noisyc...@tutanota.com
Control: affects -1 + src:rust-tesseract-sys
Hi,
The recent bindgen update uncovered an i386 bug which was already present in
leptonica-sys, namely, the one described in [1]. It mani
Hi Samuel,
Although I am not the maintainer of this package, from what I can see
librust-version-ranges-dev is an actual dependency of pep440-rs [1],
which has been stuck in the NEW queue for more than two weeks now [2].
Cheers
[1] https://github.com/konstin/pep440-rs/blob/main/Cargo.toml
[
ipten-core/emscripten/discussions/22656
[2] https://salsa.debian.org/NoisyCoil/emscripten/-/commits/3.1.66-3
[3] https://salsa.debian.org/NoisyCoil/binaryen/-/commits/119-1
> Sorry, I still don't understand: If my patch effectively does nothing, then
> why do the tests now succeed when they failed without the patch applied?
What "fixed" the tests is the changes in d/tests/control, not the patch. Tests
passing is the expected behavior if the patch does nothing, beca
Yes, I think you misunderstood. Your patch, as it is, will *always* build code
for i386 when cross compiling, because the `cfg` check in build.rs applies to
the build machine and the empty main function (via #[cfg(not(target_arch =
"x86"))]) will always be compiled instead of the top one. CI suc
I think you have MRs disabled in the rust-wide repo. You can cherry-pick this
commit from my fork:
https://salsa.debian.org/NoisyCoil/rust-wide/-/commit/c68a2e54b6bd231206a85a290b4da4e01ca72fbe.
Confusingly, while the `cfg` target checks run on the build machine, the
`CARGO_CFG_TARGET_
> Also, would be neat if the patch was improved to not fail but lower
> optimization level and emit a warning.
I liked the idea so I started playing around a bit. While I haven't found a way
to achieve that yet (simply setting environment variables doesn't seem to work
and there doesn't seem to
Hi Jonas,
Thanks for the fix. On a second thought yes, given that you're building the
package as "Architecture: all" your build.rs patch probably is the right thing
to do.
> I think that patch is generally usable, not only for Debian but also sensible
> for upstream to adopt.
I agree. They ar
In the light of the recent discussion upstream, it looks quite clear that the
test failures are due to the lack of SSE2 in Debian's i686 rust target (and
resulting unsound floating point behavior). The failures themselves were
triggered by your switch from dh-cargo to dh-rust, which caused autop
Some data points:
1. I was able to reproduce the failures on an amd64 build machine running and
compiling i386 code as early as v0.7.11-2 (see logs at [1]). To reproduce, on
Debian Testing, within said version's source code:
```
sbuild-createchroot --include=eatmydata --arch=i386 testing
/srv/
only one I'm aware of being rust-tiny-dfr).
Best,
NoisyCoil
52 matches
Mail list logo
