Bug#1057780: fixed in gdb 15.1-1
FWIW, this change made rustc's (and notmuch's, see #1077911) build dependencies unsatisfiable. they both have/had a dependency on gdb, and a conflict on gdb-minimal, since the latter didn't provide all the features required. with the reversal of provides (gdb providing gdb-minimal instead of the other way round), this combination is now unsatisfiable. the new provides make more sense, so mainly leaving this here on zumby's request (and for any other packages using such a combination ;)), not asking for a revert or anything like that..
Bug#1074448: corrosion: fails to build with rustc >= 1.79
Source: corrosion
Version: 0.4.7-1
Severity: serious
Tags: ftbfs upstream patch
Justification: fails to build from source (but built successfully in the past)
hi!
rustc in version 1.79 and later doesn't allow dashes in lib names
anymore. corrosion's test cases executed as part of the build and later,
during autopkgtest, use such a now forbidden library name. the build and
autopkgtest run thus fail, which currently prevents rustc 1.79 from migrating
to testing (which is fine, and good that the test caught it :)).
upstream fixed this as part of 0.5:
https://github.com/corrosion-rs/corrosion/issues/501
with:
https://github.com/corrosion-rs/corrosion/commit/f85b2422d39fb2f7daca33aa6c2ee7647e9f9348
the linked commit applies cleanly to 0.4.7-1, so either cherry-picking
it or updating to 0.5 would be appreciated (ideally before end of July,
when I'll likely upload 1.80).
there seems to be one other issue related to cbindgen (and probably
related commits upstream):
> 4/69 Test #22: cbindgen_rust2cpp_build
> ..***Failed2.42 sec
> CMake Warning:
> Ignoring empty string ("") provided on the command line.
>
>
> CMake Warning:
> Ignoring empty string ("") provided on the command line.
>
>
> CMake Warning:
> Ignoring empty string ("") provided on the command line.
>
>
> CMake Warning:
> Ignoring empty string ("") provided on the command line.
>
>
> CMake Warning:
> Ignoring empty string ("") provided on the command line.
>
>
> -- TEST_BINARY_DIRECTORY:
> /<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp
> '/usr/bin/cmake' '-GUnix Makefiles' '-DRust_TOOLCHAIN=' '--log-level' 'Debug'
> '-DRust_CARGO_TARGET=x86_64-unknown-linux-gnu'
> '-DCMAKE_C_COMPILER=/usr/bin/cc' '-S'
> '/<>/test/cbindgen/rust2cpp' '-B'
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> -- The C compiler identification is GNU 13.3.0
> -- The CXX compiler identification is GNU 13.3.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Using Corrosion 0.4.7 with CMake 3.29.6 and the `Unix Makefiles` Generator
> CMake Warning at /<>/cmake/FindRust.cmake:197 (message):
> CMake variable `Rust_TOOLCHAIN` specified, but `rustup` was not found.
> Ignoring toolchain and looking for a Rust toolchain not managed by rustup.
> Call Stack (most recent call first):
> /<>/cmake/Corrosion.cmake:63 (find_package)
> /<>/CMakeLists.txt:73 (include)
>
>
> -- Parsed Target triple: arch: x86_64, vendor: unknown, OS: linux, env: gnu
> -- Parsed Target triple: arch: x86_64, vendor: unknown, OS: linux, env: gnu
> -- Determining required link libraries for target x86_64-unknown-linux-gnu
> -- Required static libs for target x86_64-unknown-linux-gnu:
> gcc_s;util;rt;pthread;m;dl;c
> -- Found Rust: /usr/bin/rustc (found version "1.79.0")
> -- Using Corrosion as a subdirectory
> -- Found 1 targets in package rust-lib
> -- TARGET rust_lib produces byproducts librust_lib.a;;
> -- Corrosion created the following CMake targets: rust_lib
> -- rust target is rust_lib
> -- Output directory property (target rust_lib): ARCHIVE_OUTPUT_DIRECTORY dir:
> output_directory-NOTFOUND
> -- Setting IMPORTED_LOCATION for target rust_lib-static to
> `/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp/librust_lib.a`.
> -- Adding command to copy byproducts `librust_lib.a` to
> /<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp/librust_lib.a
> -- Configuring done (0.8s)
> -- Generating done (0.0s)
> -- Build files have been written to:
> /<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp
> '/usr/bin/cmake' '--build'
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[2]: Entering directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
> rule.
> gmake[3]: Entering directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Entering directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> [ 0%] Built target cargo-prebuild_rust_lib
> gmake[4]: Entering directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Entering directory
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
>Compiling rust-lib v0.1.0 (/<>/test/cbindgen/rust2cpp/rust)
> Finished `dev` prof
Bug#1069687: librust-bitflags-1-dev: fails to co-install
On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote: > Hi Matthias, > > On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > > This is the same situation as in #1040477. This is an issue wrt how we > > generate the semvers. I image rust-proc-macro-crate-1 would pose the same > > problem. Quoting you from 1040477: > > Right! > > > Is the only workaround dropping Ma:same here ? > > I see very little alternatives. We must choose: > > * Do not combine M-A:same + Provides: foo + Breaks: foo. > * Fix dose/apt/dpkg to agree on what this means. > > If we were to adapt dose and apt, they's simply arrive at the conclusion > that M-A:same would not work here so that really is not what you'd want > here. This amounts to fixing dpkg to allow this very combination in the > same way that apt and dose allow it. So yeah, changing dpkg could be an > option. Ccing dpkg-devel about it. > > The first alternative means that we must not combine them at the same > time. As we very much want M-A:same, we must not have this combination > of Provides and Brekas. Keep in mind that they serve slightly different > purposes. We have Breaks + Replaces and you can only replace a real > package but Provides introduce a virtual package. In effect we're > dealing with a package that sometimes is virtual and other times is > real. We can choose different names for these uses. The real package > could be renamed and also provide the virtual facility. All of them > would now provide the virtual one as virtual only and none of them would > have the virtual name. The Breaks and Replaces would be updated to match > the real name. we discussed this in the past already around bookworm's release, but haven't fixed the debcargo side generating these. see #1040477 and #1054156 IIRC the solution was to switch to Conflicts, and maybe stop providing librust-bitflags-dev and friends (those without any semver parts in the package name) in the semver-suffix variant, right? > This may not work for the in-archive situations right now as Breaks and > Replaces may still be necessary for upgrades, but it is something that > may work in future situations of the same kind. > > In the mean time, consider that M-A:same presently is a lie. Removing it > is better than continuing to lie. It's not like we must have everything > in perfect multiarch. Even for cross compilation, we often can get away > without M-A:same by only requiring a package for the host architecture. > M-A:same is not the goal. It's a tool and way may consider using other > tools. > > Helmut >
Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev
On Thu, Dec 07, 2023 at 01:02:58AM +, Peter Green wrote: > On the one hand I'm not at all convinced this bug is rc, on the other > hand I don't think shipping a four year old version of env-logger > in the next release of Debian is a great idea. > > So I decided to look at the reverse dependencies, I found three > > safe-vdash - this is a Jonas package, the dependency on rust-env-logger-0.7 > seems bogus, I filed a bug. > rust-tracing-log - the new version no longer depends on env-logger, I updated > it along with it's reverse dependency tracing-subscriber. > rspotify - this package is long term broken, noctis expressed an interest in > fixing it back in January but I don't know what if-any progress he has made > since then. (as always!) thanks for the analysis above. I agree that reducing the env_logger versions in testing is a good idea in any case. the question is whether we want to drop the unversioned provides in semver-suffixed packages altogether in debcargo - IIRC debcargo itself would never generate an unversioned dependency in d/control except if Cargo.toml itself has an unversioned dependency, which is not possible for crates on crates.io. that would only leave manually generated dependencies, or patched crates with very strong relaxation. and even so, the normal flow for semver-suffix packages would work just fine: - fork semver suffix package, upload to NEW/experimental - wait for NEW processing - bump regular package, upload both to unstable and any package that uses an unversioned dependency would stay on the non-suffixed package providing/containing the latest packaged version, while anything depending on the old semantic version would switch to the suffixed package. the only thing that wouldn't work anymore is having a versioned dep on the unversioned package where the version constraint would only be satisfied by the suffixed package. e.g., librust-env-logger-dev (<= 0.8)
Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev
On Fri, Oct 27, 2023 at 07:55:07PM +0300, Adrian Bunk wrote: > On Fri, Oct 27, 2023 at 05:07:12PM +0200, Fabian Grünbichler wrote: > > On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote: > > > Package: librust-env-logger-0.7+default-dev > > > Severity: serious > > > > > > https://buildd.debian.org/status/fetch.php?pkg=mdevctl&arch=arm64&ver=1.2.0-4%2Bb3&stamp=1697626199&raw=0 > > > > > > ... > > > Merged Build-Depends: ..., librust-env-logger+default-dev, > > > ... > > > The following NEW packages will be installed: > > > ... > > > librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev > > > ... > > > error: failed to select a version for the requirement `env_logger = > > > "^0.10.0"` > > > ... > > > > > > > > > This is due to: > > > librust-env-logger+default-dev reverse Provides: > > > librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4) > > > librust-env-logger-dev 0.10.0-2 (= 0.10.0-2) > > > > > > > > > I'll file a separate bug for mdevctl having a too loose build dependency. > > > > I am not sure why it shouldn't? librust-env-logger-0.7-dev does contain > > env_logger source code after all > >... > > Having two in the archive makes it unpredictable which version the > dependency solver uses when building a reverse dependency. yes. with the caveat listed below that having such a dep in the first place is non-standard. > Different architectures might end up being built with different versions. that's always true though since nothing forces builds on different archs to use the same set of packages? > A binNMU might change the version used, even switching from 0.10 to 0.7. yes. if the rdep is compatible with both versions, is that a problem? and this is also the case in general, a binNMU is not different than other builds in this regard, right? > rust-env-logger-0.7 (0.7.1-3) unstable; urgency=medium > * Release as versioned package for other rdeps that can't update to 0.9 > > This should really only be used after an explicit opt-in. it is. having an unversioned dependency is one way to say "I am fine with getting a version that might not be the most recent". the other is depending on (in this case) librust-env-logger-0.7-dev (or a variant thereof), which might be built by src:rust-env-logger (in version 0.7.X-Y) or by src:rust-env-logger-0.7 (in version 0.7.X-Y). the non-versioned variant should only be used if you want to build with a possible range of versions and don't care which one you get. the default behaviour (at least in Rust packaging) is to depend on the semver-prefix-containing variant, which entails exactly the behaviour you want, except for a possible short period of time where src:rust-env-logger in the newer version might not have hit the archive yet, but src:rust-env-logger-0.7 already has. in that case, the two should be functionally identical though, so it matters even less which one gets picked ;) > > >... > > depending on just librust-env-logger+default-dev without a > > version constraint says "I want env_logger with the default feature(s), > > but don't care about the version" - which in almost all cases isn't > > sensible. > >... > > > There are packages with > Build-Depends: librust-env-logger+default-dev (>= 0.9) > in the archive, if these were >= 0.7 it would be the same problem. yes, but if they were >= 0.7 they should be fine with 0.7? and if the new src:rust-env-logger (in version > 0.7) doesn't build yet on an arch, or is still waiting for some dependency to become available, or .. then changing the semver suffix package to not provide librust-env-logger-dev would break those rdeps, since they become unsatisfiable? or, if the old version is still around binary-wise, the builds might pick up different versions anyway on different architectures.. the only reason those semver-suffix packages even exist in the first place is to allow - seamless transitions - keeping older versions around for a time in case the upstream ecosystem hasn't upgraded fully yet, and doing it downstream is not feasible because the breaking changes are too big while the latter could be supported even with the non-versioned provides dropped, the former would not, at least not for rdeps that opt into relaxing the semver constraints. the only reason to have an unversioned dep is to not need an immediate rebuild: - upload package A with (build-)dep on env-logger >= 0.7 when 0.7 is in the archive -- expecting a compatible 0.8/0.9/.. - env-logger 0.8 gets uploaded at the same time as env-logger-0.7 semver varia
Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev
On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote: > Package: librust-env-logger-0.7+default-dev > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=mdevctl&arch=arm64&ver=1.2.0-4%2Bb3&stamp=1697626199&raw=0 > > ... > Merged Build-Depends: ..., librust-env-logger+default-dev, > ... > The following NEW packages will be installed: > ... > librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev > ... > error: failed to select a version for the requirement `env_logger = "^0.10.0"` > ... > > > This is due to: > librust-env-logger+default-dev reverse Provides: > librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4) > librust-env-logger-dev 0.10.0-2 (= 0.10.0-2) > > > I'll file a separate bug for mdevctl having a too loose build dependency. I am not sure why it shouldn't? librust-env-logger-0.7-dev does contain env_logger source code after all the expectation is that any rdep that requires a certain version (according to the semantic versioning rules employed by almost the entire rust ecosystem) would encode that information in the Debian package relationship (either by adding a version constraint, or depending on the virtual or real package encoding the appropriate version prefix in the package name/provides, or both). by virtue of those rules, depending on just librust-env-logger+default-dev without a version constraint says "I want env_logger with the default feature(s), but don't care about the version" - which in almost all cases isn't sensible. there's ongoing work on providing a command in debcargo that allows rdeps that don't use debcargo for the full packaging (e.g., because they are a rust component of a bigger project) to translate Cargo.toml into corresponding, version-constraint-preserving Debian package relationship stanzas: https://salsa.debian.org/rust-team/debcargo/-/merge_requests/49 signature.asc Description: PGP signature
Bug#1051815: [Pkg-rust-maintainers] Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68
> Peter Green hat am 13.09.2023 05:24 CEST geschrieben: > On 12/09/2023 23:30, Faidon Liambotis wrote: > > Control: reassign -1 rustc 1.68.2+dfsg1-1 > > Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression) > > > > On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote: > >> The autopkgtests for wasmedge fail with rustc 1.68, I have observed this > >> with > >> both testing and unstable's versions of wasmedge, and with both testing and > >> unstable's versions of wasi-lib. > > Thanks for the report. Actually, I think the WasmEdge autopkgtests are > > catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries > > that do not work with neither WasmEdge, nor Wasmtime (the latter is not > > in Debian). > And it seems the issue persists with rustc 1.69 :( > > https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37797497/log.gz this is most likely a regression in wasi-libc (it just got exposed once rustc switched to the new version). the last version enabled stack protection since upstream allegedly supports that now, seems it's still broken and I'll revert that change and report back.
Bug#1040837: [Pkg-rust-maintainers] Bug#1040837: Bug#1040837: rust-log: breaks API without coordination
On Sat, Jul 15, 2023 at 05:07:25PM +0200, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2023-07-15 09:55:04) > > Quoting Fabian Grünbichler (2023-07-12 19:53:08) > > > The feature in question is probably not a good candidate for packaging > > > though, given the lack of stability guarantees provided by upstream[0]: > > > > > > > This module is unstable and breaking changes may be made at any time. > > > > See the tracking issue for more details. > > > > > > The referenced tracking issue can be found here[1]. > > > > > > While the required crates (multiple ones from sval-rs/value-bag) are > > > being packaged (mostly done, pending a re-upload to NEW and review > > > there), I wonder whether enabling the feature was not a > > > mistake/premature in the first place. > > > > > > I did a quick test with ratt with the attached diff applied, and except > > > for rust-sequoia-net (which fails for other reasons which are already > > > fixed in experimental and just need a re-upload of the version there to > > > unstable), building at least worked fine. I am not too familiar with > > > either async-std, nor the kv feature of log to say whether this approach > > > would be feasible - I'd be happy to hear your thoughts though! IMHO > > > keeping this unstable aspect out of the archive for the time being would > > > save us all from periodic breakage, with log itself (without the KV > > > feature) being rather widely used. > > > > Makes sense. > > > > I will go through those of the reverse dependencies that I am involved > > in maintaining, to see if th unstable feature can be avoided - and might > > reach out for help if I cannot figure it out on my own. > > While I appreciate your suggested patch for rust-async-std, the main > obstacle to getting rid of the feature seems to not be rust-async-std > but instead rust-kv-log-macro which has 19 reverse dependencies: > > aardvark-dns > rust-ahash > rust-ahash-0.7 > rust-ashpd > rust-async-attributes > rust-async-std > rust-async-std-resolver > rust-async-tar > rust-erbium > rust-femme > rust-flume > rust-futures-timer > rust-oxilangtag > rust-oxiri > rust-rustls > rust-sequoia-net > rust-trust-dns-client > rust-trust-dns-resolver > rust-trust-dns-server > > I am not happy to create Debian-specific patches to somehow replace > rust-kv-log-macro, and even if you were kind enough to initially create > such patches there is still the headache of maintaining them. ack, that's fair enough, like I said, I am not all too familiar with that part of the ecosystem. IIRC this is the second or third time that it breaks in Debian via sval.. > If the feature in rust-log really is considered too unstable for use in > Debian, then it seems to me that we need to convince upstream projects > to acknowledge that and themselves avoid the feature. probably it would be best to push for stabilization :) do you want to file some issues or should I? ;)
Bug#1040837: [Pkg-rust-maintainers] Bug#1040837: rust-log: breaks API without coordination
On Tue, Jul 11, 2023 at 01:47:53PM +0200, Jonas Smedegaard wrote: > Source: rust-log > Version: 0.4.19-2 > Severity: serious > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > rust-log 0.4.19-2 apparently removed upstream feature kv_unstable > (according to inspection of source of that packaging release - > related changelog entry does not mention that feature). > > This change to upstream API was done without coordination with > reverse dependencies, and breaks at least librust-async-std-dev > and its 17 reverse dependencies. > > Yes, I am aware that changelog entry indicates this being a temporary > change, pending packages lingering in NEW queue. Please don't release > breaking changes without prior coordination with reverse dependencies > (e.g. the changes that cause bug#1040702), and in cases that is not > possible (e.g. when accidentally ending at bug#1040702) then please > notify reverse dependencies e.g. using a bugreport with tag "affects". This was by mistake, and not on purpose. The feature in question is probably not a good candidate for packaging though, given the lack of stability guarantees provided by upstream[0]: > This module is unstable and breaking changes may be made at any time. > See the tracking issue for more details. The referenced tracking issue can be found here[1]. While the required crates (multiple ones from sval-rs/value-bag) are being packaged (mostly done, pending a re-upload to NEW and review there), I wonder whether enabling the feature was not a mistake/premature in the first place. I did a quick test with ratt with the attached diff applied, and except for rust-sequoia-net (which fails for other reasons which are already fixed in experimental and just need a re-upload of the version there to unstable), building at least worked fine. I am not too familiar with either async-std, nor the kv feature of log to say whether this approach would be feasible - I'd be happy to hear your thoughts though! IMHO keeping this unstable aspect out of the archive for the time being would save us all from periodic breakage, with log itself (without the KV feature) being rather widely used. In a slightly related note, there will be two upcoming transitions that will affect (rust) packages of yours (bindgen to 0.65, and toml to 0.7) as part of updating rust-cargo to 0.70. Would you appreciate bugs with patches filed before the transition starts, or do you want to handle those on your own? You can find some details in the (WIP) tracking issue[2]. bindgen should be pretty straight-forward, for toml we will likely opt for a period of semver-suffixing since the versions do have breaking changes where breakage is not detected at compile time. 0: https://docs.rs/log/latest/log/kv/index.html 1: https://github.com/rust-lang/log/issues/328 2: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48 diff --git a/rust-async-std-1.12.0/debian/changelog b/rust-async-std-1.12.0-patched/debian/changelog index dfa43a8..5d6258f 100644 --- a/rust-async-std-1.12.0/debian/changelog +++ b/rust-async-std-1.12.0-patched/debian/changelog @@ -1,3 +1,9 @@ +rust-async-std (1.12.0-12.1) unstable; urgency=medium + + * Non-maintainer upload. + + -- Fabian Grünbichler Wed, 12 Jul 2023 13:43:22 +0200 + rust-async-std (1.12.0-12) unstable; urgency=medium * tighten autopkgtests diff --git a/rust-async-std-1.12.0/debian/control b/rust-async-std-1.12.0-patched/debian/control index 767ca01..84a3e66 100644 --- a/rust-async-std-1.12.0/debian/control +++ b/rust-async-std-1.12.0-patched/debian/control @@ -12,15 +12,12 @@ Build-Depends: librust-async-lock-2+default-dev , librust-async-process-1+default-dev , librust-crossbeam-utils-0.8+default-dev , - librust-femme-2+default-dev , librust-futures-0.3+default-dev , librust-futures-core-0.3+alloc-dev , librust-futures-core-0.3+std-dev , librust-futures-io-0.3+default-dev , librust-futures-lite-1+default-dev , - librust-kv-log-macro-1+default-dev , librust-log-0.4+default-dev , - librust-log-0.4+kv-unstable-dev , librust-memchr-2+default-dev , librust-once-cell-1+default-dev , librust-pin-project-lite-0.2+default-dev , @@ -53,9 +50,7 @@ Depends: librust-futures-core-0.3+alloc-dev, librust-futures-io-0.3+default-dev, librust-futures-lite-1+default-dev, - librust-kv-log-macro-1+default-dev, librust-log-0.4+default-dev, - librust-log-0.4+kv-unstable-dev, librust-memchr-2+default-dev, librust-once-cell-1+default-dev, librust-pin-project-lite-0.2+default-dev, diff --git a/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff b/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff new file mode 100644 index 000..33b5de9 --- /dev/null +++ b/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff @@ -0,0 +1,77 @@ +Index: rust-async-std-1.12.0/Cargo.toml +==
Bug#1034939: [Pkg-rust-maintainers] Bug#1040477: Bug#1040477: librust-syn-1-dev fails to coinstall
On Thu, Jul 06, 2023 at 04:39:08PM +0100, Peter Green wrote: > > I'd be very interested in knowing what this self-conflict is supposed to > > achieve. > > It is common upstream for there to be multiple semver-incompatible versions > of each rust crate in use at a given time. Incompatibilities can range from > minor corner cases that are easily patched away to complete redesigns > > We try to only package one version of each crate at a time, but sometimes > that isn't practical. When it becomes impractical we crate semver-suffix > packages. The convention in the rust team is that the un-suffixed packages > are used for the latest version and suffixed versions are used for any > older versions. > > When packaged crates are installed on a Debian system. They are installed > in a path that depends on the upstream version of a crate. > > This creates a problem though, if the same version is packaged as both > a non-suffixed and suffixed version. Something that happens fairly > frequently when a new version is introduced e.g. > > Before: > > librust-foo-dev version 1.23-1 > > After: > > librust-foo-1-dev version 1.23-2 > librust-foo-dev version 2.34-1 > > This doesn't always happen, indeed it didn't happen in the case of syn, > because a new upstream release of syn 1.x at the same time at the same > time the semver suffix was introduced. However debcargo works on one > crate at a time. so it doesn't know if this has happened or not. > > When this happens, it leads to a file conflict. In an attempt to fix > this breaks+replaces were added. Unfortunately these proved to be > insufficient because while breaks against virtual packages work, > replaces apparently don't. We are in the process of considering > several options to fix this, but overall switching to conflicts+replaces > seems the least likely to be problematic. > > Do you encounter the same problem if you replace the breaks with > conflicts? if so we would need to do something about it. I think > the easiest would probablly be to put a version constraint on the > conflicts/replaces. It would mean we would have to take care that > semver-suffixed packages had a higher Debian revision than their > un-suffixed counterparts, but I think that is managable. and, with a bit of unexpected delay (sorry), the result of a discussion Helmut and me had in parallel on IRC: the issue with Conflicts arises in combination with M-A:same, since dpkg and apt don't agree on which one of those two "angles" has higher priority. to sort that out would require a release cycle or two. it seems like this leaves the other alternative from #1034939 [0, CC-ed], namely, switching the breaks and replaces to point at the real package (version guarded), so that upgrading from "old" non suffixed package (for which a newer version should exist by definition if a suffixed package of the same version exists) while installing the suffixed package of the same "old" version at the same time works. the main downside (and reason why we preferred the Conflicts-based variant) is that this means that two suffixed packages with different versions are no longer co-installable (since the one with the higher version would break the older one). thankfully, such issues should seldomly matter in practice. or we could investigate just switching the replaces, and keeping the breaks as is. 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034939
Bug#1034939: [Pkg-rust-maintainers] Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye
On Fri, Apr 28, 2023 at 08:42:07PM +0100, Peter Green wrote: > On 28/04/2023 18:58, Fabian Grünbichler wrote: > > I see no practical issue with 2 meaning we can't have multiple semver > > suffix packages variants of a single crate installed - having the > > unversioned and one semver suffix package in one suite at any given time > > should already be the exception, having more than that should be even > > more rare, > > In an ideal world I would agree, the transition from semver > "n" to semver "n+1" would be complete before the transition > from semver "n+1" to semver "n+2" starts. > > I've certainly seen cases where that didn't happen though. > clap springs to mind as a currently ongoing one where we > have versions 2, 3 and 4 of clap in bookworm and clap 2 > still has more users than clap 3 and 4 combined. in the archive, yes. in one transitive build dep tree that requires them to be co-installed? there are only a few crates that come my mind that bump that often and are that widely used that we might run into it. clap ticks the first box, but since it's mainly used by binaries directly (it's for argument parsing after all ;)). nom would be a realistic use case where a big project might transitively pull in 3 versions at some point (we currently have 3.x, 4.x and 7.x (unversioned) in the archive, but 3.x and 4.x seem to be cruft and removable. I did a quick check (obviously, this is only a point-in-time snapshot!), right now we have rust binaries with the following 18 semver suffix dependencies in their transitive build dep tree in unstable (according to X-Cargo-Built-Using): rust-ahash-0.7 (= 0.7.6-11) rust-arrayvec-0.5 (= 0.5.2-2) rust-blake2b-simd-0.5 (= 0.5.11-1) rust-block-buffer-0.9 (= 0.9.0-1) rust-cfg-if-0.1 (= 0.1.10-2) rust-clap-2 (= 2.34.0-3) rust-clap-3 (= 3.2.23-4) rust-digest-0.9 (= 0.9.0-2) rust-env-logger-0.7 (= 0.7.1-3) rust-foreign-types-0.3 (= 0.3.2-1) rust-foreign-types-shared-0.1 (= 0.1.1-1) rust-md-5 (= 0.10.1-1) rust-mio-0.6 (= 0.6.23-2) rust-semver-0.9 (= 0.9.0-3) rust-semver-parser-0.7 (= 0.7.0-1) rust-sha-1-0.9 (= 0.9.8-1) rust-sha2-0.9 (= 0.9.9-2) rust-sha3-0.9 (= 0.9.1-1) of these, only three are (transitively) depended on in both semver suffix and unversioned variants by any one package according to X-Cargo-Built-Using: rust-cfg-if is used in two versions by: qwertone alacritty bat fd-find libslirp-helper rust-code-analysis-cli sniffglue rust-mio by: alacritty libslirp-helper rust-semver by: grcov rusty-tags keep in mind that this possible misses some additional dependency trees that are not resulting in any binary crate binary packages (e.g., packaging efforts that are not yet finished). > >and there should be no need to have them *installed* at the > >same time since these packages are only used as build deps. > > More than one semver of the same crate can be used in the same > build process. Also collapse_features means that crates often end > up in the transitive build-dependency graph of a package even > though they are not actually used in the build. > > I feel this is the kind of thing that would rarely cause problems, > but when it does cause problems they would be of the > "painted into a corner" type that are very difficult to deal with. well, dealing with boils down to either: - delay the crate update until more users of the outdated version have upgraded upstream and we can drop an old version - write the patches for doing that upgrade and submit them upstream - fork the oldest version in Debian to give a new name and patch its users (meh) - manually dropping the Breaks+Replaces after ensuring that the offending combination of versions doesn't exist in the archive anymore the first two are valid options IMHO, and decrufting an old version before introducing a second old version into the archive seems desirable in almost all cases that I can think of, regardless of whether it is *needed* or not. that being said - I now did some practical tests: - install librust-mio-dev from bullseye - install librust-mio-extras-dev from bookworm (which depends on mio 0.6) now do a regular dist-upgrade, no problem, since librust-mio-dev gets unpacked first (old files for 0.6.23 gone) and only then librust-mio-0.6-dev gets unpacked (new files for 0.6.23 are not conflicting) - that might just be luck though? or the Breaks guiding the ordering, even though technically it only ensures that the broken package is deconfigured, not that it is upgraded? I see no practical difference when repeating the experiment with librust-mio-0.6-dev patched + bumped to switch the B+R to librust-mio-dev (<< 0.6.24~), the upgrade works just as fine. with Replaces + Conflicts on librust-mio-0.6.23-dev, the upgrade works as well. attempting to install the librust-mio-dev package from
Bug#1034939: [Pkg-rust-maintainers] Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye
On Fri, Apr 28, 2023 at 07:58:35PM +0200, Fabian Grünbichler wrote: > 2) if the "fork point" corresponds to the version in the soon-to-be-old > stable release, and the semver suffix package is still in testing when > that becomes the stable release (as then the unversioned package in > (old)stable and the semver suffix package in (new)stable ship the same > path) > > is 2) actually true for any of the filed bugs at the moment? if not, > then IMHO we can ignore this until bookworm is out the door, decide on > and ship the fix in debcargo, and ease out the problematic packages by > updating them (basically option 5). like Peter noted below, these are > packages almost certainly only installed on developer machines (or the > odd programmer's who doesn't use the stock, upstream way of doing rust > developement) and in 'unclean' build environments, not on regular > servers or end user machines. I guess I could have checked that myself before writing - rust-block-buffer is in bullseye with version 0.9.0-4, and rust-block-buffer-0.9 is in bookworm with version 0.9.0-1, so yeah, this affects bullseye->bookworm upgrades, although with all the caveats Peter and I mentioned, which might still be an argument for not "hotfixing" this in bookworm now.
Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye
as reference, the (simplified) problematic combination: rust-foobar in version X.Y.Z-A ships librust-foobar-dev which provides librust-foobar-X-dev, librust-foobar-X.Y-dev and librust-foobar-X.Y.Z-dev (all in version X.Y.Z-A) is what I call the "unversioned" package in the rest of this mail (it doesn't have any part of the upstream version encoded in either the source package name or its binary package names. like all rust crates, it does have the prefixes of the upstream version encoded in virtual package names). rust-foobar-X in version X.Y.Z-B ships librust-foobar-X-dev which provides librust-foobar-dev, librust-foobar-X.Y-dev and librust-foobar-X.Y.Z-dev (all in version X.Y.Z-B) is the "semver suffix" package (because its source package name and the binary package name(s) contain a suffix with the first part semver component of the upstream version) - it provides both the unversioned package name and the prefixes that are no already in its actual package name. note that A and B don't have to be identical at any point of these packages' lifecycle, although they might be. so exact matching based on the full package version is not possible. there's the special case of X being 0 that change some details, but not in a way that matter. there might also be more librust-foobar[-X]+F-dev binary packages with corresponding provides, or additional provides without their own binary package, where F is some feature of the crate. AFAICT this also shouldn't change anything about the analysis below, provided the set of features is identical across the two source packages, so I am going to ignore this as well :) On Fri, Apr 28, 2023 at 04:21:08PM +0100, Peter Green wrote: > On 28/04/2023 06:05, Helmut Grohne wrote: > > Can you go into more detail as to what you mean with "don't support > > version ranges"? > > You can place a lower bound on the version, place an upper bound > on the version or constrain to a precise version. But you can't > constrain to a range of versions. exactly, and since the conflict ist actually on an upstream-version specific path, and the debian revisions of the two involved source packages might not be related/identical, we can't do an exact match. so the only solution IMHO is to have an upper bound on the next upstream version, i.e. if the semver "fork point" is X.Y.Z, << X.Y.(Z+1)~ ? an unversioned librust-foobar-dev that contains crate version > X.Y.Z, even with the first two components identical, is okay, since the path in /usr/share/cargo/registry is different then. > > In principle, you could declare the Replacs to be > > slightly broader than necessary (i.e. instead of declaring against the > > specific range, you can replace all old packages). Do you agree that > > this is feasible? > It would indeed be feasible to continue declaring the breaks > against the virtual package, while declaring the replaces > against the physical package. > > My only concern is this may bring in bug reports complaining > about a replaces without a matching breaks. Tehcnically I > don't see anything in policy actually forbidding such but > it goes against the norm. the question is whether switching just the Replaces as opposed to both B+R to the unversioned package has any advantage in the way apt and co handle it? if not, then switching the B+R to have the same dependency might be a good idea if just for consistency's sake. > > 5. In a different bug, Samuel Thibault observed that the target package > > was not part of bullseye. As such, an upgrade scenario involving it > > was unlikely. All of the 6 affected librus-*-dev packages are not > > part of bullseye. We could argue that the risk of these effects > > showing up in practice is not big enough to warrant an invasive fix. > > Rather, we'd downgrade them to important (and upgrade to serious > > when we see them in the wild) and close them after bookworm (since > > we don't support skip upgrades). > > While the target packages aren't part of bullseye, they could well end up > pulled > in as part of an upgrade, since the purpose of these packages is to continue > providing older versions of a crate when the main package of the crate is > upgraded. semver suffix packages are problematic at two points: 1) when they are initially created in sid, where for a time (until the unversioned package is updated) both source packages and their binary packages might co-exist in sid and/or testing this could be avoided by always updating the unversioned first, but one common reason is avoiding breaking half of the archive when doing such a transition, so.. 2) if the "fork point" corresponds to the version in the soon-to-be-old stable release, and the semver suffix package is still in testing when that becomes the stable release (as then the unversioned package in (old)stable and the semver suffix package in (new)stable ship the same path) is 2) actually true for any of the filed bugs at the moment? if not, the
Bug#1031745: gdb: breaks rustc gdb debuginfo tests
Hi!
I extracted one of the failing tests and the corresponding gdb commands
so that you can more easily (and quicker) reproduce the issue:
https://salsa.debian.org/fg/rustc-gdb-1031745
instructions are contained within as well. changing the triggering
function (multiple_arguments) to either just have the tuple as argument,
or making the signature
fn multiple_arguments((oo, pp): (isize, isize), (qq, rr): (isize, isize)) {
(and adapting the call accordingly) makes the problem go away.
just having multiple_arguments with the call as standalone test case
also doesn't trigger the issue.
Bug#1031745: gdb: breaks rustc gdb debuginfo tests
Package: gdb Version: 13.1-1 Severity: serious Control: affects -1 src:rustc Justification: breaks unrelated software While preparing an update to rustc 1.65 for experimental, we noticed that the recent gdb update in sid makes rustc FTBFS by causing 5 of its gdb-integration test cases fail. test [debuginfo-gdb] src/test/debuginfo/destructured-fn-argument.rs ... FAILED test [debuginfo-gdb] src/test/debuginfo/function-arguments.rs ... FAILED test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-stack-closure.rs ... FAILED test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-unique-closure.rs ... FAILED test [debuginfo-gdb] src/test/debuginfo/unsized.rs ... FAILED command did not execute successfully: "/<>/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/<>/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/<>/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/<>/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/<>/src/test/debuginfo" "--build-base" "/<>/build/x86_64-unknown-linux-gnu/test/debuginfo" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "debuginfo" "--mode" "debuginfo" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-15/bin/FileCheck" "--optimize-tests" "--linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath -Cdebuginfo=0 -Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -Cdebuginfo=0 -Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" "src/tools/tidy" "--verbose" "--llvm-version" "15.0.7" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker dwp engine executionengine extensions filecheck frontendopenacc frontendopenmp fuzzercli fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interfacestub interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto m68k m68kasmparser m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts objcopy object objectyaml option orcjit orcshared orctargetprocess passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils ve veasmparser vecodegen vectorize vedesc vedisassembler veinfo webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86targetmca xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--channel" "stable" our rustc build uses an (arch-dependent) cut-off for the number of "allowed to fail" tests - for amd64 it is 8, the current version of rustc in testing/sid (1.63.0+dfsg1-2) had 2 such failing tests when it was initially built, a rebuild with gdb from unstable causes the fail count to go to 8 - while not failing the build itself, the errors look problematic enough to me that it should likely be looked at more closely *before* gdb ends up in testing/bookworm. it does also prevent us from getting through the backlog of rustc upstream releases in experimental, since the baseline for rustc 1.65 test failures is 4, and the 6 additional ones caused by gdb push it over the threshold. the same tests are failing for - rustc 1.65 (not yet uploaded, MR on salsa[0] which successfully bui
Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On May 1, 2022 7:28 pm, Peter Michael Green wrote: > > On 01/05/2022 14:00, Fabian Grünbichler wrote: >> currently progress is blocked on >> - itoa/serde_json transition (anybody working actively on that?) > > I just uploaded the new itoa to experimental and took a quick look > through the reverse dependencies. > > rust-cssparser - already broken and not in testing. > rust-csv - built/tested fine after patching to use itoa 1, upstream also > has an unreleased change switching to itoa1 with no code changes. > rust-http - fixed version in debcargo-conf (semver breaking, but all > rdeps are broken right now anyway) > rust-hyper - already broken and not in testing. > rust-num-format - already broken and not in testing. > rust-serde-json - fixed version in debcargo-conf (not semver breaking) > rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps > are broken right now anyway) > rust-time - fixed upstream (not semver breaking) > > I'm not seeing any reason not to go ahead with pushing this to unstable, > anyone have any comments before I go ahead? LGTM - wasn't me who prepared those (itoa / serde_json) though ;) Carlos did, but they seem to not hang out on IRC atm.
Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On April 20, 2022 11:39 am, Fabian Grünbichler wrote: > On April 20, 2022 12:33 am, Peter Michael Green wrote: >> Package: rust-h2 >> Version: 0.1.26-1 >> X-debbugs-cc: d...@jones.dk >> >> I noticed that Jonas had set a number of bugs about broken rust packages as >> blockers of 900928, so I decided to take a look at some of them. I fixed up >> bytemuck, image and related packages. >> >> I then started looking at reqwest which lead me to h2 (which has been broken >> since the tokio 1.x transition but noone ever got around to filing a >> bug) which >> lead me to http which jonas recently NMU'd. >> >> I feel I need to comment on the technical details of the NMU, I should >> preface >> this by saying that I don't think it's unreasonable to 0-day NMU a minimal >> fix for a long term RC issue, even if (as was not the case here but was the >> case for some of the other NMUs noone ever bothered to actually file the >> RC bug). >> >> However, this NMU did considerably more than just add a minimal fix for >> the rc issue. Most painfullly, the "orig" tarball for the new upstream >> version >> appears to have been derived from upstream git rather than from crates.io >> and this breaks our workflow. If you are going to 0-day stuff please keep >> your uploads minimal. If you want to do more invasive NMUs please give >> the maintainers a chance to respond. >> >> Fortunately it seems the answer is to move to an even newer upstream >> version. The only reverse dependencies of rust-http seem to be the >> h2/hyper stack which badly needs an update to move away from tokio >> 0.x. I have already committed the http update to debcargo-conf and may >> upload it at some point. >> >> Unfortunately moving back up the stack I ran into another issue. h2 and >> hyper have grown a new dependency on tracing. While I am I am happy to >> help with fixing existing rust packages, I am reluctant to take >> responsibility >> for a new package unless it's something I personally use. >> >> So this is where I personally tap out on h2/hyper until/unless someone >> packages tracing. > > we use this stack (h2/hyper) downstream, I can take care of it over the > coming weeks. tracing is unfortunately still rather in-flux, so it will > likely see frequent upgrades. okay, just pushed the following to debcargo-conf: - update of hyper - update of httparse - update of http-body - switch of http to iota 1.x currently progress is blocked on - itoa/serde_json transition (anybody working actively on that?) - tracing being uploaded (capitol?) - tower-service being uploaded (NEW, RFS, please upload!) once all of the above is in the archive, the current version of h2 also builds fine ;)
Bug#999507: [Pkg-rust-maintainers] Bug#999507: Bug#999507: rust-tokio-signal, (build-)dependencies unsatisfiable, abandoned upstream, should this package be removed.
On November 12, 2021 1:11 pm, Henry-Nicolas Tourneur wrote: > > > Le ven 12 nov 2021 à 10:18, Fabian Grünbichler > a écrit : >> On November 12, 2021 6:38 am, Peter Green wrote: >>> Package: rust-tokio-signal >>> Version: 0.2.7-2 >>> Severity: serious >>> >>> rust-tokio-signal (build-)depends on version 0.1 of rust-futures. >>> Upstream seems to >>> have abandoned the project, there was an alpha release supporting >>> futures 0.2, but >>> the code appears to have been removed from the tokio git >>> repository. So I presume >>> it is abandoned upstream. >>> >>> There are no reverse dependencies in testing, there is a single >>> reverse dependency >>> in unstable which is rc buggy and also appears to be abandoned >>> upstream. >>> >>> If there are no objections in a few weeks, I intend to file a >>> removal request. >> >> same here, tokio-signal is now tokio+signal ;) accordingly, it can be >> RMed with the rest of the legacy tokio 0.1 crates once tokio 1.0 has >> been uploaded >> > > I would not even wait for tokio 1.0 upload and request removal of > tokio-signal could be done right away. > > As it stands, it is broken due to unsastifiable build dependencies and > it has no reverse dependencies, as Peter explained. > > Fabian, I see no point in keeping tokio-signal in the archive in its > current state and the package is going away anyway as you mentionned it > being superseeded by tokio+signal. > > Do you see any reasons to keep it until tokio 1.0 upload? no, the RMs can be filed now as well of course, I just figured it's easier to see which ones (also third-party related crates) go into the RM pile once the successors are packaged, which means less effort for all involved parties. but doing the first batch (those part of the original tokio 0.1 release itself - see the tokio-process bug) now is fine as well, we can always do a second batch post-uploads for any remaining stuff.
Bug#999507: [Pkg-rust-maintainers] Bug#999507: rust-tokio-signal, (build-)dependencies unsatisfiable, abandoned upstream, should this package be removed.
On November 12, 2021 6:38 am, Peter Green wrote: > Package: rust-tokio-signal > Version: 0.2.7-2 > Severity: serious > > rust-tokio-signal (build-)depends on version 0.1 of rust-futures. Upstream > seems to > have abandoned the project, there was an alpha release supporting futures > 0.2, but > the code appears to have been removed from the tokio git repository. So I > presume > it is abandoned upstream. > > There are no reverse dependencies in testing, there is a single reverse > dependency > in unstable which is rc buggy and also appears to be abandoned upstream. > > If there are no objections in a few weeks, I intend to file a removal request. same here, tokio-signal is now tokio+signal ;) accordingly, it can be RMed with the rest of the legacy tokio 0.1 crates once tokio 1.0 has been uploaded
Bug#974606: [Pkg-rust-maintainers] Bug#974606: should rust-tokio-process be removed?
On November 12, 2021 6:47 am, peter green wrote: > In addition to the (build-)dependency on an old version of > rust-crossbeam-queue, > rust-tokio-process (build-)depends on version 0.1 of rust-futures. Upstream > seems to > have abandoned the crate, there was an alpha release supporting futures 0.2, > but > the code appears to have been removed from the tokio git repository. it was moved from a separate crate to a 'process' feature in the main tokio crate. there are a few more like this[1], and they can all be RMed once we upload tokio 1.x (plus the remaining related/supporting crates tokio-util, tokio-macros, tokio-stream, bytes, mio, tracing, ..). > > There are no reverse dependencies in testing or unstable > > If there are no objections in a few weeks, I intend to file a removal request. 1: see https://tokio.rs/blog/2019-11-tokio-0-2 and the diff between 0.1 and 0.2, AFAICT the following were dropped altogether as standalone crates: tokio-async-await tokio-buf tokio-codec tokio-core tokio-current-thread tokio-executor tokio-fs tokio-io tokio-process tokio-reactor tokio-signal tokio-sync tokio-tcp tokio-threadpool tokio-timer tokio-udp tokio-uds
Bug#975191: [Pkg-rust-maintainers] Bug#975191: Bug#975191: re: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101
On August 31, 2021 9:16 pm, Wolfgang Silbermayr wrote: > On 8/31/21 4:25 PM, Bastian Germann wrote: >> On Wed, 2 Dec 2020 02:46:36 + peter green wrote: >>> > 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 >>> rust-webpki >> >> Hey, >> >> I would like to get rustls migrating to bookworm but this is a blocker for >> it. >> Can you please state if you want to fix this or would like help with it? I >> guess importing the current version will do it. > > Hi Bastian, > > I'd be happy to support getting rustls to migrate as well. > > After taking a look, "just" updating rust-js-sys to the latest version also > requires an update of the wasm-bindgen related crates to the latest version > (which currently is 0.2.76 across all of them): > > wasm-bindgen-shared > wasm-bindgen-backend > wasm-bindgen-macro-support > wasm-bindgen-macro > wasm-bindgen > > I did a quick test run updating all of these, and it basically works, once > `syn` got updated. For `syn`, we have an RFS note indicating that autopkgtests > don't work yet with the updated version and need some other packages such as > `insta` uploaded before. I didn't dig too deeply into that part, but we might > need to invest some additional work here. > > Within the wasm-bindgen* group, I also stumbled over a few autopkgtest > problems: > > wasm-bindgen-macro-support has a few features that fail their tests, but I > expect that these tests simply aren't intended to be run with only a single > feature enabled. Would require some investigation and either fixing or marking > them as broken. The rest of the tests succeeds. > > wasm-bindgen-macro requires wasm-bindgen to be available for the autopkgtest, > but it should be possible to handle that. In addition, it requires > wasm-bindgen-futures 0.4, some more about that below. > > wasm-bindgen requires js-sys 0.3 to be available for the autopkgtest, but > again that can be handled. > > js-sys requires wasm-bindgen-futures 0.4 for the autopkgtest as well. > > Regarding wasm-bindgen-futures, that one has a dev dependency on > futures-channel-preview in a 0.3 alpha version. We can basically handle that, > but that crate received its last update about two years ago. At a quick look, > it seems to be a bootstrapping crate that might be intended to be replaced by > futures-channel which is available by now, but that didn't happen yet for > whichever reason. Might be a topic to investigate upstream. That one pulls in > futures-core 0.3, and thus requires an update of the futures ecosystem from > 0.1 to 0.3 which by itself is a topic that is much larger than the > wasm-bindgen topic that I describe here. There was already some preparation > done by another team member, but I'm not sure when it was the last time > somebody took a thorough look at what they prepared. yeah, the -preview crates are relicts from a time when the futures/async stuff was not yet written in stone. they are all replaced by the non-preview version, in this case futures-channel. I plan on pushing forward the futures 0.3 (and related tokio 1.x and hyper/... ecosystems) update this fall, but it will be a process spanning months ;) > > I'd love to work on untangling these issues, but once I start working on such > a group of problematic packages, I usually discover blockers which stop my > undertaking, and due to being a DM, I need a DD to either grant me upload > access for the affected crates, or sponsor the upload for me, so it's quite > tedious to finish such a group of packages, with all the inconveniences that > come from the delays, such as packages failing to migrate for some time or > autopkgtests failing until the required dependencies become available. If it > was for me, we could go forward and upload the updates, but in the past it > didn't take long until we collected many reports about failing or skipped > autopkgtests. the same applies to me modulo not even being a DM yet ;) > That's what I can tell upfront from my quick evaluation, but speaking from > experience, I'd expect some unforeseen roadblock to show up when working on > it. > > I hope this quick analysis gives you some insight into the overall state, and > some idea where and how you would like to proceed. In case you need some > support working on a specific crate, let me know. > > Best regards, > Wolfgang. > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers >
Bug#988729: [Pkg-rust-maintainers] Bug#988729: CVE-2021-21299
On May 18, 2021 8:42 pm, Moritz Muehlenhoff wrote: > Source: rust-hyper > Severity: grave > Tags: security > X-Debbugs-Cc: Debian Security Team > > CVE-2021-21299: > https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf > https://rustsec.org/advisories/RUSTSEC-2021-0020.html FWIW, (rust-hyper) doesn't have any rdeps in bullseye AFAICT[1], so it could either be ignored there or removed from bullseye without consequences. for bullseye+1, I plan on updating it as soon as sid is unfrozen again, but the dependency chain needed for that update is quite big so it might take a bit to pass through NEW etc (which was also the reason why it didn't get updated in time pre-freeze). there are no affected rdeps in unstable either though, as they are all using hyper as client, not server. 1: dev/list-rdeps.sh from debcargo-conf agrees
Bug#919167: tmuxp FTBFS and completely broken with python-click 7.0-1
FWIW, this was reported upstream[0], and fixed[1], and released as part of 1.5.0a. Either backporting the relevant changes from PR 434 or updating to 1.5.0(a) seems like a good idea. 0: https://github.com/tmux-python/tmuxp/issues/433 1: https://github.com/tmux-python/tmuxp/pull/434 2: https://github.com/tmux-python/tmuxp/releases/tag/v1.5.0a
Bug#909092: tmuxinator: missing dependency on ruby-xdg
Package: tmuxinator Version: 0.12.0-1 Severity: serious Justification: Policy 3.5 any tmuxinator command prints the following trace: /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- xdg (LoadError) from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/vendor_ruby/tmuxinator.rb:6:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/bin/tmuxinator:5:in `' /usr/lib/ruby/vendor_ruby/tmuxinator.rb:6 is require "xdg" but the tmuxinator package does not declare a dependency on "ruby-xdg". after manually installing ruby-xdg, tmuxinator works as expected. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tmuxinator depends on: ii ruby 1:2.5.1 ii ruby-erubis 2.7.0-3 ii ruby-thor0.19.4-1 ii tmux 2.7-1+b1 tmuxinator recommends no packages. tmuxinator suggests no packages. -- no debconf information
Bug#899047: zfs-test: outdated B+R for files taken over from zfsutils-linux
Package: zfs-test Version: 0.7.9-2 Severity: serious commit 2c29cd95fd0e5fccc035bf7dead27a4b73708f12 moved the following files from zfsutils-linux to zfs-test, without updating zfs-test's versioned Breaks+Replaces relation accordingly: /sbin/ztest the following files are now also installed in zfs-test, in addition to being installed in zfsutils-linux: /usr/share/man/man1/ztest.1 /usr/share/man/man1/raidz_test.1 /usr/share/man/man1/test-runner.1 this leads to failed apt runs with messages like the following: Unpacking zfs-test (0.7.9-2) over (0.7.6-1) ... dpkg: error processing archive /var/cache/apt/archives/zfs-test_0.7.9-2_amd64.deb (--unpack): trying to overwrite '/sbin/ztest', which is also in package zfsutils-linux 0.7.6-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Unpacking zfs-test (0.7.9-2) over (0.7.6-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-jpbbT5/15-zfs-test_0.7.9-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/raidz_test.1.gz', which is also in package zfsutils-linux 0.7.9-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) I suggest explicitly listing the man (1) pages to be installed in zfsutils-linux in debian/zfsutils-linux.install (instead of the whole /usr/share/man/man1 directory) to get rid of the duplicate files, and bumping the versioned B+R for zfs-test accordingly (because of the duplicate files, zfs-test now Breaks and Replaces zfsutils-linux <= 0.7.9-2, and only -3 should move to buster be backported IMHO. thanks for your consideration!
Bug#884706: zfs-linux: make distclean deletes commands.cfg, which is not regenerated
On Mon, Dec 18, 2017 at 02:49:48PM +0100, Andreas Beckmann wrote: > Source: zfs-linux > Version: 0.7.3-3 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Hi, > > zfs-linux fails to build twice in a row. The first build succeeds, the > subsequent 'debian/rules clean' runs 'make distclean' which deletes > tests/zfs-tests/include/commands.cfg, but that file is not regenerated > during the second build: > > Making all in include > make[5]: Entering directory '/build/zfs-linux-0.7.3/tests/zfs-tests/include' > make[5]: *** No rule to make target 'commands.cfg', needed by 'all-am'. Stop. > make[5]: Leaving directory '/build/zfs-linux-0.7.3/tests/zfs-tests/include' > Makefile:544: recipe for target 'all-recursive' failed > > The full buildlog from pbuilder --twice is attached. > > > Andreas fixed upstream in b1490dd43e3c98649c7d23928d908f5bb019411b , which applies cleanly on top of 0.7.4 (but upstream should probably be poked to include it in 0.7.5)
Bug#880902: [Pkg-zfsonlinux-devel] Bug#880902: zfs-test: fails to upgrade from 'testing' - trying to overwrite /usr/share/zfs/common.sh
On Sun, Nov 05, 2017 at 03:18:57PM +0100, Andreas Beckmann wrote:
> Package: zfs-test
> Version: 0.7.3-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
>
> From the attached log (scroll to the bottom...):
>
> Selecting previously unselected package zfs-test.
> Preparing to unpack .../38-zfs-test_0.7.3-1_amd64.deb ...
> Unpacking zfs-test (0.7.3-1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-RL6UMz/38-zfs-test_0.7.3-1_amd64.deb (--unpack):
>trying to overwrite '/usr/share/zfs/common.sh', which is also in package
> zfsutils-linux 0.6.5.11-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>/tmp/apt-dpkg-install-RL6UMz/38-zfs-test_0.7.3-1_amd64.deb
>
>
> cheers,
>
> Andreas
attached patch should fix the issue in this bug, proposal for related
bug #880907 will follow.
>From 0baa850ec48a66ecdc5daba9c45d5448df12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabian=20Gr=C3=BCnbichler?=
Date: Thu, 16 Nov 2017 13:33:41 +0100
Subject: [PATCH] zfs-test: add proper Breaks+Replaces
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
on zfsutils-linux, which used to contain some of the ZFS test suite
files.
Closes: #880902
---
debian/control.in | 2 ++
debian/control| 2 ++
2 files changed, 4 insertions(+)
diff --git a/debian/control.in b/debian/control.in
index 18d2417cc..1eef7e734 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -155,6 +155,8 @@ Package: zfs-test
Section: contrib/admin
Architecture: linux-any
Depends: ${misc:Depends}, ${shlibs:Depends}, zfs-modules | zfs-dkms, zfsutils-linux, parted, lsscsi, mdadm, bc, ksh, fio, acl, sudo, sysstat, python
+Breaks: zfsutils-linux (<= 0.6.5.11-1)
+Replaces: zfsutils-linux (<= 0.6.5.11-1)
Description: OpenZFS test infrastructure an support scripts
The Z file system is a pooled filesystem designed for maximum data
integrity, supporting data snapshots, multiple copies, and data
diff --git a/debian/control b/debian/control
index 18d2417cc..1eef7e734 100644
--- a/debian/control
+++ b/debian/control
@@ -155,6 +155,8 @@ Package: zfs-test
Section: contrib/admin
Architecture: linux-any
Depends: ${misc:Depends}, ${shlibs:Depends}, zfs-modules | zfs-dkms, zfsutils-linux, parted, lsscsi, mdadm, bc, ksh, fio, acl, sudo, sysstat, python
+Breaks: zfsutils-linux (<= 0.6.5.11-1)
+Replaces: zfsutils-linux (<= 0.6.5.11-1)
Description: OpenZFS test infrastructure an support scripts
The Z file system is a pooled filesystem designed for maximum data
integrity, supporting data snapshots, multiple copies, and data
--
2.14.2
Bug#858252: unix domain socket forwarding broken for root user
Package: openssh-server
Version: 1:7.4p1-1
Severity: critical
Tags: patch upstream
Commit b737e4d7433577403a31cff6614f6a1b0b5e22f4 disabled unix domain
socket forwarding when privsep is disabled. Unfortunately, privsep is
always "disabled" for the root user, so this completely broke unix
socket forwarding for the root user (instead of forwarding, an error
message "administratively prohibited" is printed).
Upstream (openssh-portable) already has a fix for this in commit
51045869fa084cdd016fdd721ea760417c0a3bf3 (see below).
Please cherry-pick accordingly - thanks in advance.
(Note: severity set to critical as this breaks unrelated software which
uses SSH's socket forwarding feature, but of course feel free to
downgrade to >= serious as you see fit..)
>From 51045869fa084cdd016fdd721ea760417c0a3bf3 Mon Sep 17 00:00:00 2001
From: "d...@openbsd.org"
Date: Wed, 4 Jan 2017 05:37:40 +
Subject: [PATCH] upstream commit
unbreak Unix domain socket forwarding for root; ok
markus@
Upstream-ID: 6649c76eb7a3fa15409373295ca71badf56920a2
---
serverloop.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/serverloop.c b/serverloop.c
index c4e4699..bdb944f 100644
--- a/serverloop.c
+++ b/serverloop.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: serverloop.c,v 1.189 2016/12/14 00:36:34 djm Exp $ */
+/* $OpenBSD: serverloop.c,v 1.190 2017/01/04 05:37:40 djm Exp $ */
/*
* Author: Tatu Ylonen
* Copyright (c) 1995 Tatu Ylonen , Espoo, Finland
@@ -468,6 +468,10 @@ server_request_direct_streamlocal(void)
Channel *c = NULL;
char *target, *originator;
u_short originator_port;
+ struct passwd *pw = the_authctxt->pw;
+
+ if (pw == NULL || !the_authctxt->valid)
+ fatal("server_input_global_request: no/invalid user");
target = packet_get_string(NULL);
originator = packet_get_string(NULL);
@@ -480,7 +484,7 @@ server_request_direct_streamlocal(void)
/* XXX fine grained permissions */
if ((options.allow_streamlocal_forwarding & FORWARD_LOCAL) != 0 &&
!no_port_forwarding_flag && !options.disable_forwarding &&
- use_privsep) {
+ (pw->pw_uid == 0 || use_privsep)) {
c = channel_connect_to_path(target,
"direct-streamlo...@openssh.com", "direct-streamlocal");
} else {
@@ -702,6 +706,10 @@ server_input_global_request(int type, u_int32_t seq, void
*ctxt)
int want_reply;
int r, success = 0, allocated_listen_port = 0;
struct sshbuf *resp = NULL;
+ struct passwd *pw = the_authctxt->pw;
+
+ if (pw == NULL || !the_authctxt->valid)
+ fatal("server_input_global_request: no/invalid user");
rtype = packet_get_string(NULL);
want_reply = packet_get_char();
@@ -709,12 +717,8 @@ server_input_global_request(int type, u_int32_t seq, void
*ctxt)
/* -R style forwarding */
if (strcmp(rtype, "tcpip-forward") == 0) {
- struct passwd *pw;
struct Forward fwd;
- pw = the_authctxt->pw;
- if (pw == NULL || !the_authctxt->valid)
- fatal("server_input_global_request: no/invalid user");
memset(&fwd, 0, sizeof(fwd));
fwd.listen_host = packet_get_string(NULL);
fwd.listen_port = (u_short)packet_get_int();
@@ -762,9 +766,10 @@ server_input_global_request(int type, u_int32_t seq, void
*ctxt)
/* check permissions */
if ((options.allow_streamlocal_forwarding & FORWARD_REMOTE) == 0
|| no_port_forwarding_flag || options.disable_forwarding ||
- !use_privsep) {
+ (pw->pw_uid != 0 && !use_privsep)) {
success = 0;
- packet_send_debug("Server has disabled port forwarding.");
+ packet_send_debug("Server has disabled "
+ "streamlocal forwarding.");
} else {
/* Start listening on the socket */
success = channel_setup_remote_fwd_listener(
Bug#806273: Patch for disabling kernel mounts when grub-mount is available
On Wed, Nov 16, 2016 at 12:30:52PM +0100, Emmanuel Kasper wrote: > On 11/15/2016 06:25 PM, Ben Hutchings wrote: > > On Tue, 2016-11-15 at 15:33 +0100, Emmanuel Kasper wrote: > >> The included patch disables read_only mounts when grub-mount is available. > > > > Why not require that grub-mount is available, and disable the other > > path entirely? > > > > Ben. > > makes sense > > I had a look at the platforms where grub-mount is available > > and it seems only > mips64el s390x > are missing from the list > > now do these platforms need os-prober ? > I don't think so as most OSes detected by os-prober are x86. > > I noticed that the osprober udeb already limits itself to the platform > where grub-mount is available so requiring grub-mount to be available > should be a relative conservative change. > FWIW, Ubuntu just pushed the following update[1] to xenial's os-prober that disables mounting using "mount" completely: %< diff -Nru os-prober-1.70ubuntu3/debian/changelog os-prober-1.70ubuntu3.1/debian/changelog --- os-prober-1.70ubuntu3/debian/changelog 2016-03-11 13:43:46.0 + +++ os-prober-1.70ubuntu3.1/debian/changelog 2016-12-06 15:05:22.0 + @@ -1,3 +1,10 @@ +os-prober (1.70ubuntu3.1) xenial; urgency=critical + + * os-probes/common/50mounted-tests: don't mount filesystems with mount for +probing as that can cause corruption in some cases. (LP: #1579609) + + -- Eric Desrochers Tue, 06 Dec 2016 10:05:22 -0500 + os-prober (1.70ubuntu3) xenial; urgency=low * Check for MSDOS extended partitions and skip any further tests which diff -Nru os-prober-1.70ubuntu3/os-probes/common/50mounted-tests os-prober-1.70ubuntu3.1/os-probes/common/50mounted-tests --- os-prober-1.70ubuntu3/os-probes/common/50mounted-tests 2015-11-20 10:07:43.0 + +++ os-prober-1.70ubuntu3.1/os-probes/common/50mounted-tests 2016-12-06 15:05:22.0 + @@ -58,26 +58,8 @@ type=fuseblk fi else - ro_partition "$partition" - for type in $types $delaytypes; do - if mount -o ro -t "$type" "$partition" "$tmpmnt" 2>/dev/null; then - debug "mounted as $type filesystem" - case "$type" in - btrfs) - if [ -x "$tmpmnt/@/lib" ] && \ - ! mount --bind "$tmpmnt/@" "$tmpmnt"; then - warn "failed to mount btrfs subvolume @ on $partition" - if ! umount $tmpmnt; then - warn "failed to umount $tmpmnt" - fi - mounted= - fi - ;; - esac - mounted=1 - break - fi - done + echo "Failed to probe for filesystem type" >&2 + exit 1 fi if [ "$mounted" ]; then >% 1: https://launchpad.net/ubuntu/+source/os-prober/1.70ubuntu3.1 > -- > To unsubscribe, send mail to 806273-unsubscr...@bugs.debian.org. >
